Change target of FAQs displayed in app to coronawarn.app//faq/ which is under project control

Currently, the target of the FAQ link in the apps is the Bundesregierung's FAQs at: https://www.bundesregierung.de/breg-de/themen/corona-warn-app/corona-warn-app-faq-1758392
I consider this subideal, because this page is:

noisy
not very well designed
not under direct project control
doesn't include the detail of the project FAQs
doesn't answer many important questions

It would be better, if the FAQ link in the apps targeted the project website FAQs at coronawarn.app/en/faq/ (and German equivalent). These FAQs are cleaner, more up to date, under project control etc.

Closing as this issue is a duplicate of issue 289

This is related to #289 but it's not an exact duplicate. #289 wants to have a unified FAQ, I ask no such thing. I ask for the Bundesreg FAQ to be replaced as target with the coronawarn.app.
So I kind of disagree with the simple statement "duplicate" - may still make sense to unify but please offer better reasoning in the future.
I add this as an example to my #IssueClosurePolicy list.

@corneliusroemer Just to clarify: My focus in #289 was on the problem and not so much on any particular solution.
My reading of the developers’ responses there and here is that they acknowledge the FAQs need improvement and are working to consolidate the FAQs into a new version that will become accessible from the app. The closure of this issue as a duplicate probably means nothing more than that they consider your contribution as pertinent to the same task and try to keep their to-do list tidy. Closure does not imply rejection unless stated otherwise and “duplicate” merely means they are asking you to check progress elsewhere. Perhaps we can just wait and see what they will come up with, and then evaluate their solution.

Thanks @sventuerpe for clarifying! Your explanation makes a lot of sense. I may be prejudiced by bad examples of premature closures I've observed in the past here on this project.


libbitcoin

Motivation for this change
Provides the bx program (#18644)
Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

It looks like all of these should work on darwin, you should add it to the platforms.

Yep, everything works fine https://gist.github.com/LnL7/84eb84b2cac42a818e13a3d7334d6385.

Okay, I'll change it


Bump to net6

Bump to .NET 6 and remove morelinq dependency, as DistinctBy is now natively supported by Sytem.Linq.
Tested with dotnet build and Visual Studio 2022.

Thanks for the contribution. This is definitely something that we want to do, but there are a few teams internally that consume Component Detection, and we'll need to check that they are ready and able to consume a .NET 6 dependency.

Closing this in favour of #288


error when updating to 4.50

Before opening, please confirm:

[X] I have installed the latest version of the Amplify CLI (see above), and confirmed that the issue still persists.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

How did you install the Amplify CLI?
npm install -g @aws-amplify/cli@latest
If applicable, what version of Node.js are you using?
v12.18.3
Amplify CLI Version
4.48.0
What operating system are you using?
mac
Amplify Categories
auth, function, api, hosting
Amplify Commands
push
Describe the bug
I started out with amplify cli 4.48. I am working with another dev who is using version 4.50. If I update to 4.50 and then try to amplify push I get the following error: Cannot read property 'length' of undefined
After reverting to 4.48 I can amplify push again.
Additionally, I set up amplify frontend hosting with github ci before I noticed this problem. I went to check those frontend environments and it looks like after the other developer pushed to the github branches that those frontend environments are connected to, they stopped building successfully.
Looking at the errors on those environments, they are having the same problem I ran into when I tried to update my amplify CLI to 4.50.
2021-05-01T03:41:34.837Z [WARNING]: ✔ Initialized provider successfully. 2021-05-01T03:41:35.009Z [WARNING]: ✖ An error occurred when pushing the resources to the cloud 2021-05-01T03:41:35.010Z [WARNING]: ✖ There was an error initializing your environment. 2021-05-01T03:41:35.013Z [INFO]: TypeError: Cannot read property 'length' of undefined
Expected behavior
I should be able to update my amplify vli and then amplify push without running into an error.
Also, my amplify frontend envs should be able to build.
Reproduction steps

Pull an amplify project while using amplify cli 4.48
update amplify cli to 4.50
try to amplify push

GraphQL schema(s)

# Put schemas below this line

Log output

# Put your logs below this line
Cannot read property 'length' of undefined
TypeError: Cannot read property 'length' of undefined
    at /usr/local/lib/node_modules/@aws-amplify/cli/node_modules/amplify-provider-awscloudformation/src/utils/consolidate-apigw-policies.ts:121:99
    at Array.forEach (<anonymous>)
    at ApiGatewayAuthStack.createPoliciesFromResources (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/amplify-provider-awscloudformation/src/utils/consolidate-apigw-policies.ts:120:13)
    at /usr/local/lib/node_modules/@aws-amplify/cli/node_modules/amplify-provider-awscloudformation/src/utils/consolidate-apigw-policies.ts:94:16
    at Array.forEach (<anonymous>)
    at /usr/local/lib/node_modules/@aws-amplify/cli/node_modules/amplify-provider-awscloudformation/src/utils/consolidate-apigw-policies.ts:84:31
    at Array.forEach (<anonymous>)
    at new ApiGatewayAuthStack (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/amplify-provider-awscloudformation/src/utils/consolidate-apigw-policies.ts:62:23)
    at createApiGatewayAuthResources (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/amplify-provider-awscloudformation/src/utils/consolidate-apigw-policies.ts:205:17)
    at Object.consolidateApiGatewayPolicies (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/amplify-provider-awscloudformation/src/utils/consolidate-apigw-policies.ts:201:10)
    at Object.createEnvLevelConstructs (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/amplify-provider-awscloudformation/src/utils/env-level-constructs.ts:22:5)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at Object.run (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/amplify-provider-awscloudformation/src/push-resources.ts:97:5)
    at async Promise.all (index 0)
    at providersPush (/usr/local/lib/node_modules/@aws-amplify/cli/src/extensions/amplify-helpers/push-resources.ts:99:3)
    at AmplifyToolkit.pushResources [as _pushResources] (/usr/local/lib/node_modules/@aws-amplify/cli/src/extensions/amplify-helpers/push-resources.ts:75:7)
    at Object.executeAmplifyCommand (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/amplify-category-function/src/index.ts:240:3)
    at executePluginModuleCommand (/usr/local/lib/node_modules/@aws-amplify/cli/src/execution-manager.ts:175:3)
    at Object.executeCommand (/usr/local/lib/node_modules/@aws-amplify/cli/src/execution-manager.ts:28:5)
    at Object.run (/usr/local/lib/node_modules/@aws-amplify/cli/src/index.ts:139:5)
An error occurred when pushing the function resource

Additional information
No response

Thanks for reporting this @jhaddock385. I'm going to close this as a duplicate of https://github.com/aws-amplify/amplify-cli/issues/7190. Please see the linked issue for a workaround. There should also be a fix in the next release.


fix for referencing merged list/map entries

Unfortunately I found a bug in my new merge handling in combination with reference evaluation.
I added the tests for those cases and provide the fix.
Entries overridden by an inline merge should be referenced with the
overridden value, but so far the original value is used
---
foo:
  <<: (( merge ))
  bar: 42
ref:
  bar: (( foo.bar ))

merged with
---
foo:
  bob: added!
  bar: overridden

should resolve ref to overridden not 42.
problem occurs for all variants of inline merges

May be there is another case hat should be discussed.
I played a little bit with the redirecting merge.
Let's have a look at the following scenario:
foo:
  <<: (( merge alt ))
  bar:
    <<: (( merge ))
    alice: alice

merged with
foo:
  alice: not merged!
alt:
  bar:
    alice: overwritten
    bob: added!

What should be a useful behaviour of the nested unqualified merge (in foo.bar), if there is an outer redirecting merge? The actual behaviour does not take the outer merge into account.
What I expected without further thinking about the implementation was that missing fields from the stub are inserted. But it didn't happen, because the merge implictly uses the acutal path meta.bar not the implied redirected path alt.bar.
Basically I could explicitly  write merge alt.bar. But my impression is that intuitively the expectation would be to implicitly take the redirection into account and use the implied redirection path.
This could easily be changed, because all the information is there, but I want to discuss this with you, before adding this commit.
Thanks
Uwe

In branch lambda there are the additional functions split and trim and the support of lambda expressions to define additional functions as part of the yaml document. May be you want to have a look. The commits are based on the ones here, but I don't want to bundle new functionality with the fixes provided by this PR.

In the case of
foo:
  <<: (( merge alt ))
  bar:
    <<: (( merge ))
    alice: alice

merged with
foo:
  alice: not merged!
alt:
  bar:
    alice: overwritten
    bob: added!

I'd probably expect the output to be
foo:
  bar:
    alice: overwritten
    bob: added!

Yepp, this is exactly what I would expect, too. I added the fix for this to this PR in 00960dd

There was a couple of small typos, and some tabs in the example in the README which we removed as tabs are not valid yaml. I fixed these in a commit.
Thanks for the PR.


more things in tox

Codecov Report

Merging #15 (e181482) into master (ddfb48b) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head e181482 differs from pull request most recent head add64f8. Consider uploading reports for the commit add64f8 to get more accurate results

@@            Coverage Diff            @@
##            master       #15   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            5         5
  Lines          242       242
=========================================
  Hits           242       242

Continue to review full report at Codecov.

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


refactor(at_onboarding_flutter): Add modular support to at_onboarding_flutter

Many components and workflows in at_onboarding_flutter are not or reusable.
I want to refactor at_onboarding_flutter into 3 layers:

Pages

the existing option / interface

Widgets

the buttons and stuff currently hard coded into the pages, so parts can be embedded

Libraries

at_onboarding doesn't contain any of the keychain / platform dependent code
so we must make an interface available in at_onboarding_flutter which wraps
the behavior underlying each of the widgets

With this change there are a few other considerations I've thought about:

Make it possible to control which widgets are included in the pages as a
configurable list

I've experimented with closures in the past, but they don't update when
hot reloading flutter apps, so I'll see if I can come up with something
static that also propogates state efficiently
(maybe I lacked passing keys to the widgets, which is why the tree wouldn't
update properly, it's been a while)

Adding the APKAM widgets, with a more modular design they can be developed in
parallel without dealing with the troubles of the nested widget code.

I may consider starting with a blank slate, porting the old code into the new
design piece by piece, simplifying behavior as I go.

I chose to delay the rest of this work, extracting the file picker into a service, which is the minimum required amount of work needed by the NoPorts desktop app. I will backlog this ticket for now, and we can pull it into another sprint if we need more work done for something else.


Product portfolio

integrating product porfolio features:

[x] Product Porfolio management
[x] Product Assessment visualization

Estimated Effort: 20 hours

Real effort: 11 hours


/help not working properly? (Narrowing down my issue.)

So, I have set this customtext #help with a custom message. I added the alias in commands.yml, and made /help ---> customtext #help. So the problem is, recently it has been reverting to Essentials /help. I thought that commands.yml auto overrides everything by default. I reached out to the people developing EssentialsX to see if they knew a cause. If you could help me narrow this down or provide an explanation that would be great!
Thanks <3
(I am using the latest builds.)

This is not the appropriate place for this issue. Please use either the Aquifer forums or the Paper server issue tracker.
This tracker is for the launcher system, it is unrelated to your issue.

Oh ok. Sorry.


AIR Dependency: Fixup channel hoisting issue with having parent nested for loops

I just ran into the bug solved by this, can we merge it?

Sure. Will merge it soon today after CI build and test passes.


v2 - Rewrite to TypeScript with generated types

Related Issues & PRs
closes PR #44
fixes issues #47, #48, #51
Proposed Changes

Adds types for requests and responses generated from the Swagger schema
Uses Vite for build
Removes need for babel in favor of ts-jest in tests
Added countries as there is (to my knowledge) no endpoint to get all available countries

Hey, is there any progress? Currently dealing with an error in my Remix app regarding missing declaration files. Thanks

Hey, is there any progress? Currently dealing with an error in my Remix app regarding missing declaration files. Thanks

had the same issue, you can use @lilianaa/nordigen-node for now, which is what's in this PR

@lilianalillyy alright, will give that a shot, thanks!

@lilianalillyy I tried to by running npm install git+git@github.com:lilianalillyy/nordigen-node.git, but that only resulted in this being installed, any idea why?


Update CONTRIBUTING.md

Title and Issue number

Title: Enhancement of Contributing.md
**Issue No.: #311 **
Close:[#311 ]

Screenshots/Video (mandatory)

Checklist:

[x] I have mentioned the issue number in my Pull Request.
[x] I have commented my code, particularly in hard-to-understand areas.
[ ] I have created a helpful and easy-to-understand README.md if it's a new page/tech stack.
[x] I have gone through the contributing.md file before contributing.

Additional context (Mandatory):
Are you contributing under any Open-source programme?

[x] I'm a GSSOC-EXT contributor
[x] I'm a HACKTOBERFEST contributor

@Anuj3553 I have done the changes. Please kindly check once. If all the changes are fine please kindly merge the PR. Also please attach the gssoc extend and level label.

Well done @milansamuel609


Please invite me to the GitHub Community Organization

Name
samkoba
Discord Username (if applicable)
samkoba
Additional Context
Please invite me to this organization. Thank you

Please invite me to this organization. Thank you


add a workflow to create a pr from main to deployment

Tracking Info
Add a workflow that can deploy from main to deployment. Since we now have access to xcode cloud, it will be useful to have a deployment branch for pushing app to xcode cloud for previews occasionally.
Resolves #
Make sure your branch name conforms to: <feature|staging|bugfix|...>/<username>/<3-4 word description separated by dashes>. Otherwise, please rename your branch and create a new PR.
Changes
What changes did you make?

Add a github workflow

Testing
How did you confirm your changes worked?

Not tested yet cauz can't test until merged in main

Confirmation of Change
N/A

Not needed anymore because deployment being handled by #154


[C/PyTorch] Removed MPI dependence in Userbuffers

Description
This PR splits off the userbuffers MPI-dependence removal from PR #760.
With these changes, userbuffers is now bootstrapped via callbacks to torch.distributed collectives. In the absence of the MPI dependence, userbuffers is always compiled as part of the PyTorch extension and no longer requires the NVTE_WITH_USERBUFFERS=1 flag.
The old MPI-based bootstrapping can be re-activated via UB_MPI_BOOTSTRAP=1 at compile time.
Type of change

[ ] Documentation change (change only to the documentation, either a fix or a new content)
[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Changes

TE build no longer supports the NVTE_WITH_USERBUFFERS=1 option and Userbuffers is now always compiled into the PyTorch extensions module.
MPI collectives in Userbuffers bootstrapping are replaced with callbacks to torch.distributed collectives.
New UB_MPI_BOOTSTRAP=1 option in the TE build activates the old Userbuffers bootstrapping via MPI collectives.
transformer_engine.pytorch.module.base.initialize_ub(...) is now more conveniently accessible via transformer_engine.pytorch.initialize_ub(...).
Userbuffer communicators can now be cleaned up via transformer_engine.pytorch.destroy_ub(...).
transformer_engine.pytorch.initialize_ub(...) now requires the tensor-parallel process group instead of just the tensor-parallel size.
Added comm+GEMM overlap example with te.LayerNormMLP.

Checklist:

[x] I have read and followed the contributing guidelines
[x] The functionality is complete
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

/te-ci pytorch

/te-ci pytorch


update from PR 205

Docs Build status updates of commit c08873d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

rd/amit-bansal.yml
:white_check_mark:Succeeded

rd/dwight-goins.yml
:white_check_mark:Succeeded

rd/index.yml
:white_check_mark:Succeeded

rd/map.yml
:white_check_mark:Succeeded

rd/media/profiles/dwight-goins.jpg
:white_check_mark:Succeeded

rd/nishith-pathak.yml
:white_check_mark:Succeeded

rd/paula-januszkiewicz.yml
:white_check_mark:Succeeded

rd/reza-rad.yml
:white_check_mark:Succeeded

rd/sebastian-fyda.yml
:white_check_mark:Succeeded

rd/toc.yml
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


CLOUDP-262297: Default namespace for 'atlas kubernetes config generate'

Proposed changes
This PR addresses the issue where the kubernetes config generate command was being executed without specifying a namespace, causing it to error. This bug fix ensures that the command examples provided by the CLI, which previously omitted the namespace, no longer result in an error due to an unset namespace. Now, if a namespace is not explicitly set, it defaults to `` and it passes the validation so the config can actually get exported.
Jira ticket: CLOUDP-262297

Closes #CLOUDP-262297
Checklist

[x] I have signed the MongoDB CLA
[x] I have added tests that prove my fix is effective or that my feature works
[x] I have added any necessary documentation in document requirements section listed in CONTRIBUTING.md (if appropriate)
[x] I have addressed the @mongodb/docs-cloud-team comments (if appropriate)
[x] I have updated test/README.md (if an e2e test has been added)
[x] I have run make fmt and formatted my code

Further comments

Seek also approval from someone from CLI

Cool!
It now works as expected, no namespace beign set when --targetNamespace is not passed in.
% bin/atlas kubernetes config generate --projectId=66a230c5417c2e4cc32b9687
---
apiVersion: atlas.mongodb.com/v1
kind: AtlasProject
metadata:
  creationTimestamp: null
  labels:
    mongodb.com/atlas-resource-version: 2.4.0
  name: exporttest
spec:
...


api: Remove unused functions

Found while refactoring.

Leave in code base in case they will be used in the future


Any chance for <IP_ADDRESS> support?

Never shows up in the menu, even with the latest forks.

Thanks, updated the readme


Bug Report - Blank page after click ERC20 token.

name: Bug Report
about: Using AlphaWallet, but it's not working as you expect?

Describe the bug
A clear and concise description of what the bug is.
Steps to reproduce (REQUIRED)
Steps to reproduce the behavior

Tap Wallet tab
Tap token Detail

After open the USDT on ETH network i have this page in blank, anothers token have a same problem.

Aware of this one. Will hunt it down. Thanks.

I try check find the bug, but i dont have experience in swift a lot, but the problem is exclusive for erc20, probole problem in constraint.

Fixed


Impossible to display full article

Hello everyone,
I want to see details of current news displayed with notification ARTICLE_MORE_DETAIL or ARTICLE_TOGGLE_FULL notification, but this is not functionnal (just display black screen)
Logs
0 | mm
(node:26811) electron: Failed to load URL: https://XXX  with error:ERR_BLOCKED_BY_RESPONSE

I think this is because the website block iframe to avoid click-jacking (https://stackoverflow.com/questions/48668767/error-when-loading-an-external-url-in-an-iframe-with-electron), so there is no possibilities in this case ?
Thank you for your help !

This should be possible since https://github.com/MichMich/MagicMirror/pull/2850
Can this be closed? @josselynL

This should be possible since #2850
Can this be closed? @josselynL

Thank you for this information.
I will try and come back to you soon with the result

@khassel
MM freshly updated, but problem is still the same with same error.
Does I need to do something ?
Thank you.

Does I need to do something ?

you have to add the line httpHeaders into your config.js as provided below:
let config = {
	address: "localhost",
	port: 8080,
	httpHeaders: { contentSecurityPolicy: false, crossOriginOpenerPolicy: false, crossOriginEmbedderPolicy: false, crossOriginResourcePolicy: false, originAgentCluster: false, frameguard: false },
	...
}

	httpHeaders: { contentSecurityPolicy: false, crossOriginOpenerPolicy: false, crossOriginEmbedderPolicy: false, crossOriginResourcePolicy: false, originAgentCluster: false, frameguard: false },

Thank you for your replay.
But still the same issue.
0|mm  | (node:27973) electron: Failed to load URL: https://actu.fr/occitanie/toulouse_31555/***********.html with error: ERR_BLOCKED_BY_RESPONSE

can you provide your config.js with the related module config so we can reproduce this error?
Please remove all private information as e.g. apikeys before ...

Thank you.
Here is. I've delete all modules configuration, I think you don't need it :)
`js
/* Magic Mirror Config Sample
*

By Michael Teeuw https://michaelteeuw.nl

MIT Licensed.

For more information on how you can configure this file

see https://docs.magicmirror.builders/getting-started/configuration.html#general

and https://docs.magicmirror.builders/modules/configuration.html
*/
let config = {
address: "<IP_ADDRESS>", 	// Address to listen on, can be:
// - "localhost", "<IP_ADDRESS>", "::1" to listen on loopback interface
// - another specific IPv4/6 to listen on a specific interface
// - "<IP_ADDRESS>", "::" to listen on any interface
// Default, when address config is left out or empty, is "localhost"
port: 8080,
httpHeaders: { contentSecurityPolicy: false, crossOriginOpenerPolicy: false, crossOriginEmbedderPolicy: false, crossOriginResourcePolicy: false, originAgentCluster: false, frameguard: false },
basePath: "/", 	// The URL path where MagicMirror is hosted. If you are using a Reverse proxy
// you must set the sub path here. basePath must end with a /
ipWhitelist: [], // Set [] to allow all IP addresses
// or add a specific IPv4 of <IP_ADDRESS> :
// ["<IP_ADDRESS>", "::ffff:<IP_ADDRESS>", "::1", "::ffff:<IP_ADDRESS>"],
// or IPv4 range of <IP_ADDRESS> --> <IP_ADDRESS> use CIDR format :
// ["<IP_ADDRESS>", "::ffff:<IP_ADDRESS>", "::1", "::ffff:<IP_ADDRESS>/28"],
useHttps: false, 		// Support HTTPS or not, default "false" will use HTTP
httpsPrivateKey: "", 	// HTTPS private key path, only require when useHttps is true
httpsCertificate: "", 	// HTTPS Certificate path, only require when useHttps is true
language: "fr",
locale: "fr",
logLevel: ["INFO", "LOG", "WARN", "ERROR"], // Add "DEBUG" for even more logging
timeFormat: 24,
units: "metric",
// serverOnly:  true/false/"local" ,
// local for armv6l processors, default
//   starts serveronly and then starts chrome browser
// false, default for all NON-armv6l devices
// true, force serveronly mode, because you want to.. no UI on this device
modules: [
{
module: 'MMM-ModuleScheduler',
},
{
module: 'MMM-Carousel',
},
{
module: 'MMM-Remote-Control',
// uncomment the following line to show the URL of the remote control on the mirror
// position: 'bottom_left',
// you can hide this module afterwards from the remote control itself
config: {
customCommand: {},  // Optional, See "Using Custom Commands" below
showModuleApiMenu: true, // Optional, Enable the Module Controls menu
secureEndpoints: true, // Optional, See API/README.md
// uncomment any of the lines below if you're gonna use it
// customMenu: "custom_menu.json", // Optional, See "Custom Menu Items" below
apiKey: "***", // Optional, See API/README.md for details
// classes: {} // Optional, See "Custom Classes" below
}
},
{
module: "alert",
},
{
module: "updatenotification",
position: "top_center",
},
{
module: "clock",
position: "top_left"
},
{
module: "calendar",
},
{
module: "weather",
},
{
module: "weather",
},
{
module: "MMM-VigilanceMeteoFrance",
},
{
module: 'compliments',
//position: 'lower_third',
position: 'middle_center',
config: {
morningStartTime:5,
morningEndTime:12,
afternoonStartTime:12,
afternoonEndTime:19,
remoteFile: 'compliments.json'
}
},
{
module: 'MMM-Jeedom',
 },
 {
 	module: 'MMM-Jeedom',
 },
 {
     module: 'MMM-Jeedom',
 },
 {
 	module: 'MMM-Jeedom',
 },
 {
 	module: "newsfeed",
 	position: "bottom_bar",
 	config: {
 		feeds: [
 		/*	{
 				title: "La depeche",
 				url: "https://www.ladepeche.fr/rss.xml"
 			},*/
 			{
 				title: "Actu Toulouse",
 				url: "https://actu.fr/toulouse/rss.xml"
 			},
 			{
 				title: "Netflix News",
 				url: "https://www.netflix-news.com/feed/"
 			},
 			{
 				title: "Cookomix : Les dernières recettes publiées",
 				url: "https://cookomix.com/feed/"
 			}
 		],
 		showSourceTitle: true,
 		showPublishDate: true,
 		broadcastNewsFeeds: true,
 		broadcastNewsUpdates: true,
 		ignoreOldItems: true,
 	}
 },
 {
     module: 'MMM-Jeedom',
 },
 {
 	module: 'MMM-Jeedom',
 },
 {
     module: 'EXT-Screen',
 },

]
};

/*************** DO NOT EDIT THE LINE BELOW ***************/
if (typeof module !== "undefined") {module.exports = config;}
`

you can remove the httpHeaders stuff from above, this is for another usecase (embedding mm in another website).
As a first hack you can edit modules/default/newsfeed/newsfeed.js at about line nr. 150 and replace
	getActiveItemURL: function () {
		return typeof this.newsItems[this.activeItem].url === "string" ? this.newsItems[this.activeItem].url : this.newsItems[this.activeItem].url.href;
	},

with
	getActiveItemURL: function () {
		const urlPrefix = location.protocol + "//" + location.host + "/cors?url=";
		return typeof this.newsItems[this.activeItem].url === "string" ? urlPrefix + this.newsItems[this.activeItem].url : urlPrefix + this.newsItems[this.activeItem].url.href;
	},

Let me know if this works.

Hi,
Yeah, this works better now ! Thank you 👍
ARTICLE_MORE_DETAILS or ARTICLE_TOGGLE_FULL have the same result.
ARTICLE_MORE_DETAILS again and the page scroll down, but I can't go to the end of the page. It is blocking before, but I think this is another issue.
pm2 logs when I request ARTICLE_MORE_DETAILS for the first time
0|mm  | [08.10.2022 12:07.39.753] [LOG]
0|mm  | cors url: https://actu.fr/occitanie/toulouse_31555/bal-concerts-gratuits-expo-vide-dressing-10-sorties-a-faire-a-toulouse-ce-week-end_54337049.html
0|mm  | [08.10.2022 12:07.40.660] [LOG]
0|mm  | cors url: https://actu.fr/occitanie/toulouse_31555/top-14-un-stade-toulousain-en-grande-forme-recoit-clermont-pas-en-reussite-a-l-exterieur_54350507.html
0|mm  | [08.10.2022 12:07.41.208] [ERROR]
0|mm  | (node:28856) electron: Failed to load URL: https://actu.fr/checksso.html#error=login_required&state=d54f557c-e474-441c-8e02-eac37782bf62 with error: ERR_BLOCKED_BY_RESPONSE

The displayed article is the second URL, I don't know why the URL of previous article is in log.

So, this issued can be closed now?

can't scroll down is probably the main.css overflow:hidden

So, this issued can be closed now?

not yet, have to create a PR for this ...

Hello
@khassel TY for the PR
@sdetweil How can I check this ?

@josselynL  find a big article and cause that to be displayed. did it get clipped at the bottom?
will u have a mouse?  if so, scroll down with overflow:hidden turned off(commented out)

@josselynL find a big article and cause that to be displayed. did it get clipped at the bottom? will u have a mouse? if so, scroll down with overflow:hidden turned off(commented out)

Just tried with Remote Control (and so a mouse).
When the scroll down is blocked with "ARTICLE_MORE_DETAILS", I can continue to scroll down with the mouse, until the end of the page.
Comment or uncomment the overflow has no impact.

html {
  cursor: none;
/*  overflow: hidden;*/

the main issue is solved with release v2.22.0.

ARTICLE_MORE_DETAILS again and the page scroll down, but I can't go to the end of the page. It is blocking before, but I think this is another issue.

If this is still a problem please open a new issue, thanks.


Fix broken builds due to Fortran_MODULE_DIRECTORY

Description
Fixes the build issue preventing #638.

merge when ci passes


Could not find gem 'cocoapods-xcode-patch'

Could not find gem 'cocoapods-xcode-patch' in rubygems repository http://rubygems.pkg.github.com/dreampiggy/ or installed locally.
The source does not contain any versions of 'cocoapods-xcode-patch'

This gem is not uploaded to rubygems.org. It use the GitHub RubyGems Package.
See my local result:
➜  temp bundle install
Fetching gem metadata from https://rubygems.pkg.github.com/dreampiggy/...
Fetching gem metadata from https://gems.ruby-china.com/..........
Fetching gem metadata from https://rubygems.pkg.github.com/dreampiggy/..
Resolving dependencies...
Using CFPropertyList 3.0.1
Using concurrent-ruby 1.1.5
Using minitest 5.11.3
Using thread_safe 0.3.6
Using atomos 0.1.3
Using cocoapods-deintegrate 1.0.4
Using bundler 1.16.6
Using cocoapods-downloader 1.2.2
Using nap 1.1.0
Using claide 1.0.3
Using fuzzy_match 2.0.4
Using cocoapods-search 1.0.0
Using cocoapods-stats 1.1.0
Using netrc 0.11.0
Using cocoapods-try 1.1.0
Using colored2 3.1.2
Using nanaimo 0.2.6
Using tzinfo 1.2.5
Using i18n 0.9.5
Using molinillo 0.6.6
Using ruby-macho 1.4.0
Using escape 0.0.4
Using cocoapods-plugins 1.0.0
Using xcodeproj 1.12.0
Using cocoapods-trunk 1.4.0
Using gh_inspector 1.1.3
Using activesupport <IP_ADDRESS>
Using fourflusher 2.3.1
Using cocoapods-core 1.7.5
Using cocoapods 1.7.5
Fetching cocoapods-xcode-patch 0.2.0
Installing cocoapods-xcode-patch 0.2.0
Bundle complete! 2 Gemfile dependencies, 31 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

My local have't GitHub ruby gems package, even CI.
just download the gem file and gem install local *.gem


session not created from no such execution context: loader has changed while resolving nodes

Team,
I am facing below issue very frequently, I am running my test on Edge browser and I am having 30% Failures due to this.
Failures are random sometime  browser gets launched some it is getting failed.
session not created from no such execution context: loader has changed while resolving nodes
Could not start a new session. Response code 500. Message: session not created from no such execution context: loader has changed while resolving nodes (Session info: MicrosoftEdge=114.0.1823.51) Build info: version: '4.2.0', revision: '86eb611648' System info: host: 'XXXXX ip: 'XXXXXX', os.name: 'Windows 10', os.arch: 'x86', os.version: '10.0', java.version: '1.8.0_201' Driver info: org.openqa.selenium.edge.EdgeDriver Command: [null, newSession {capabilities=[Capabilities {browserName: MicrosoftEdge, ms:edgeOptions: {args: [--remote-allow-origins=, enable-automation, disable-gpu, unexpectedAlertBehaviour, ignore], extensions: [], useAutomationExtension: false}}], desiredCapabilities=Capabilities {InPrivate: true, browserName: MicrosoftEdge, ms:edgeOptions: {args: [--remote-allow-origins=, enable-automation, disable-gpu, unexpectedAlertBehaviour, ignore], extensions: [], useAutomationExtension: false}}}]
Simple Code-->
System.setProperty("webdriver.edge.driver", driverpath);
EdgeOptions edgeOptions = new EdgeOptions();
edgeOptions.addArguments("--remote-allow-origins=*");
edgeOptions.addArguments("enable-automation");
edgeOptions.addArguments("disable-gpu");
edgeOptions.setExperimentalOption("useAutomationExtension", false);
edgeOptions.addArguments("unexpectedAlertBehaviour", "ignore");
edgeOptions.setCapability("InPrivate", true);
driverobj=  new EdgeDriver(edgeOptions)

Dears, any feedback


Can ordering feature cross relations?

Hi there!
I used searching feature and was pleased to notice that search fields can cross relationships, for example with:
@searching(Searching, search_fields=["owner__first_name", "owner__last_name"])

However, I'm wondering how to have a similar behaviour with ordering feature.
As of now, it seems that it is considered to be a wrong field. For example, something like this will have no effect on ordering:

How can I do? Thanks a lot.

@ddahan you mean you want searching query for and ordering action?

Nope, I just want to be able to "order_by" across relation.
For example, this would work in a shell:
Badge.objects.order_by("owner__first_name")

But would not work (no effect on ordering) with my api call to :
http://localost:8000/api/badges?page=1&ordering=owner__first_name

Oh okay I see what you mean. I will take a look and revert

Has this bug been fixed?
I've added foreign key related fields to ordering_fields, so I can implement sorting for them.
However, this requires me to write all sortable fields into ordering_fields.
@router.get('/', response=List[SalarySchemaOut], summary='获取研发人员工资-分页')
@paginate(MyPagination)
@ordering(Ordering, ordering_fields=['research_staff_item__item_paper__name'])
def listData(request, filters: SalaryFilterSchema = Query(...)):
    """ 获取研发人员工资 """
    queryset = ResearchSalary.add_annotate()
    queryset = queryset.filter(research_staff_item__research_staff__company=request.company)\
        .prefetch_related("research_staff_item", "research_staff_item__research_staff", "research_staff_item__item_paper")
    queryset = filters.filter(queryset)
    return queryset


Add support for content script and popup window

Possible approach: because scala-js can only compile to one js file (along with a dependency js file), I think the content script and popup window should be different sbt projects - bringing the total to three.
The content script and popup projects can be normal scala-js projects and only require the ScalaJSPlugin.
In the scala-js-chrome project, the build.sbt will specify the the two other projects. The ChromeSbtPlugin will compile the content and popup projects and move their outputted js files to the correct build directory. The manifest.json will have to be modified as well.
I made a poc of creating three different projects and manually copying over the necessary files with an ugly shell script https://github.com/kramer425/scala-js-chrome-extension-example

I like the general idea of that. Do you think it would be possible instead of referencing the whole project to only reference a task that results in a file and have that potentially from another project? This would still leave the possibility of referencing the same project if someone wants to include everything in one.

It would be great if it could be one project. Though, I have limited knowledge of sbt - are you suggesting that one task that calls chromeBuildOpt on a directory, and two that call fastOptJS/fullOptJS on other directories?

Currently we have something like val fullOptJsLib = TaskKey[Attributed[File]]("fullOptJsLib") which can be set to a task that produces a file. I think it may be possible to also set it to reference a task from another project to pull in that file during building. So i think we could provide additional settings for content scripts and such which the user can set to whatever task he wants including from different projects.


Upgrade Supported ArgoCD Chart Version

what and why

Argo versions 0.1.0 through 2.10.0-rc1, v2.9.3, v2.8.7, v2.7.15 are affected by CVE-2024-22424, a CSRF attack when the attacker has the ability to write HTML to a page on the same parent domain as Argo CD.
Propose that we update the default values for Argo's chart from:

argo/argo-cd	5.19.12      	v2.5.9

to an unaffected version patched after 2.10-rc2, 2.9.4, 2.8.8, 2.7.16
notable changes

Argo CD 2.10 upgraded kubectl from 1.24 to 1.26. This upgrade introduced a change where client-side-applied labels and annotations are no longer preserved when using a server-side kubectl apply
Note that bundled Helm version has been upgraded from 3.13.2 to 3.14.3
Starting with Argo CD 2.10.11, the NetworkPolicy for the argocd-redis and argocd-redis-ha-haproxy dropped Egress restrictions. This change was made to allow access to the Kubernetes API to create a secret to secure Redis access

testing

This version has been tested and verified to work with the existing component configuration

references

Argo Upgrade Docs

💯


On Windows (Firefox), typing 'type Footballer' or 'class dist' removes ' ' from search text box

On Windows 10 (Firefox), typing the query 'type Footballer' or 'class dist' removes ' ' from search text box, so that you end up with 'typeFootballer' and 'classdist'.
This does not happen with Microsoft Edge nor Chrome.

The highlighter appears to output correct code:
highlightQuery('type Footballer')
"type Footballer"

So it probably has something to do with the input field mangling it.

This issue was moved to clean-cloogle/cloogle.org#210


Image carousel buttons

If we decide to keep the images in the carousel sliding off vertically, it makes little sense to have horizontally-oriented arrows in the image selector. These should be vertically oriented as well.

committee consensus to remove the arrows.


Pinout for the xv11?

Is there a pinout on where and how to attach the xv11 lidar? (jetson tx1) Is it connected to the teensy or the jetson gpio?
Also is there an easy way to configure both an xv11 and a kinect to work together?
Thank you, this is an amazing project!

Adrian

Hey Adrian,
Can you post your questions here instead as we use this mostly for bug tracking. https://groups.google.com/forum/#!forum/linorobot
Cheers! :)

my bad! please delete!
Adrian Stucker
513.341.LENS
On Wed, Mar 20, 2019 at 9:11 PM Juan Miguel Jimeno<EMAIL_ADDRESS>wrote:

Hey Adrian,
Can you post your questions here instead as we use this mostly for bug
tracking. https://groups.google.com/forum/#!forum/linorobot
Cheers! :)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/linorobot/linorobot/issues/23#issuecomment-475108286,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AktDIci1f4XgMtqY4SZfbLbCyesEGR6pks5vYwZ0gaJpZM4cAro8
.

Closing this. Thread posted here for reference: https://groups.google.com/forum/#!topic/linorobot/DRcIVR6aPFw


Cleanup and tests

a bit of cleanup and new tests
Utilities class: does not have a state and therefore can have static methods
UtilitiesTest: new
ErrorScanner/Test: cleanup, getting rid of unneccessary org.hamcrest stuff

aw man, and I pulled this morning ;-)
Well, I'll integrate my changes tomorrow. Also I saw that Ardesco stopped using pull requests so I'll just push without one.

Sorry looks like I had make quite a substancial number of changes before the pull request came in.
In regards to the Hamcrest changes I disgree, personally I think the hamcrest stuff looks much cleaner as it turns it into a sentance that makes the intent of the test very obvious.  It's not fully utilised in the current tests, but I prefer something a bit more verbose that has a very clear intent.

No worries about the refactorings mate, keep it coming!
About Hamcrest:
That's weird, the main reason why I removed it was because I think that it clutters the code and reduces readability. ;-)
when using specialized asserts like
assertTrue
assertFalse
assertNull
assertNotNull
...
you can immediately see what the test ist trying to accomplish, especially when a test method call is long like this one where you have to try to find the hamcrest method call and then read the test again:
assertThat(scanner.lineContainsForErrors("<httpSample t="44" lt="44" ts="1303959710655" s="true" lb="/energy/mets/day/{endDate}/{StartDate} Reversed Dates" rc="400" rm="Bad Request" "), is(equalTo(false)));
instead of this where you can see from the assert what the test does:
assertFalse(scanner.checkLineForErrors("<httpSample t="44" lt="44" ts="1303959710655" s="true" lb="/energy/mets/day/{endDate}/{StartDate} Reversed Dates" rc="400" rm="Bad Request" "));

When checking ranges or list contents for example, it really makes sense to use the hamcrest library:
assertThat(5 , allOf(greaterThan(1),lessThan(3)));
doing that with plain junit would be very hard indeed.

What we really should do, is pass an error message to the assert that are displayed on a test failure and make the intent of the test more clear.
Having said all that, how do we proceed here?
Cheers,
Arne

I think what we have here is just a simple difference of opinion on the readability of tests.  I prefer using the slightly longer Hamcrest syntax and you prefer the standard jUnit syntax.
I've pushed an update up that changes the format slightly to make it easier to read in the JMeterArgumentsArrayTest, what do you think of this format?
Irrespective of which style we use I agree with all of the other changes suggested and I agree that we should pass clear error messages back.  There is a distinct lack of tests at the moment IMHO so adding more is good.
Probably worth having some dicsussions about arcitecture moving forwards as well so that we don't end up stepping on each others toes by mistake (I'd suggest doing that on<EMAIL_ADDRESS>rather than cluttering up the issue list).


Additional PowerToys Run Color Option

Description of the new feature / enhancement
Short version: I would love if PowerToys Run could use the opposite of my system theme.
Scenario when this would be used?
I find that the PT Run text input can be lost when the underlying windows match the same color.  I was experimenting to see about adding an outline/frame around it, but I noticed that one simply fix seems to be just inverting it.  When Windows is in dark mode, PT Run in light style is easier to jump to.
Before:

After:

Supporting information
I use Windows in both light and dark mode, depending on ambient light. In the daytime it is VERY bright in my office and I can't use dark mode comfortably.  At night I really prefer dark mode and even have extra dark-mode extensions in my browser to darken every possible website by force.

https://github.com/microsoft/PowerToys/issues/4794

/dup https://github.com/microsoft/PowerToys/issues/4794


"tanzu context use

Bug description
Expected behavior
Steps to reproduce the bug / Relevant debug output
Output of tanzu version
Environment where the bug was observed (cloud, OS, etc)

What happened here?  I didn't ever realize this got opened.  Sorry.


Hello from kubeclient, kubernetes-client :wave:

Hi, I was happy to discover a 3rd ruby client besides https://github.com/abonas/kubeclient and https://github.com/kubernetes-client.  You have great momentum :clap:
I wanted to reach out to ask if you see aspects on which we should collaborate.
Specifically, I feel it could be nice to extract the best parts of parsing kubeconfig and obtaining auth to a separate gem, and get all 3 client gem to use it.

This functionality requires catch-up to the reference Go implementation...
The interfaces have a lot of arbitrary details like "how is the param for custom CA called?", which unfortunately have no de-facto standard in Ruby ecosystem.
A single good config interface could make it easier for users to learn/switch between the client gems.

On similar discussion in https://github.com/kubernetes-client/ruby/issues/20#issuecomment-487362902 some people expressed support.  What do you think?

I think it's a good idea as it doesn't make sense to waste efforts in reinventing the wheel and the whole config / initialization interface of k8s-client I think is too complex currently anyway and needs some simplification (as  noted in #121) and the current dry-struct based approach to parse the kubeconfig file is probably a bit overkill, as the config file structure is rather simple and extra dependencies in a client library is a major annoyance (as noted in #129 #137 and #80).

Related: there is now a community fork of kontena/k8s-client in github/k8s-ruby


Pressing enter with realPress inside should-callback is ran twice

Hey!
Trying to figure out if the issue is with Cypress or the real-events.
Following code gives enter-event twice:
cy.focused().should(() => {
  cy.realPress('enter');
  expect(someAssertion).to.be(true);
});

I am aware that this callback includes side effects, and is intentional in this case.

You should not initiate actions within should callback as it may be retried by cypress itself https://github.com/dmtrKovalenko/cypress-real-events#1-why-cyrealhover-hovering-state-does-not-show-in-the-visual-regression-services


Fix initial npm setup

After installing NpmBootstrap, the update to a recent npm version fails without any visible error. But subsequent installed npm packages complain about the old npm.

Maybe the npm module can be called directly via a setup script for NpmBootstrap without using the CLI wrapper.

Resolved by 20e90759940d9b2cb4d00b2ddfeec1495da6ff4a


non-boost version support ?

Hi,
As you know, boost is a large dependency (in my own case), so I'm looking to see if there's a winstl for non-boost, as non-boost Asio has done.
Note that the minimum supported version is C++14, so any boost dependencies on boost-wintls itself can be replaced with STL.
I have now implemented a non-Boost version of winstl. If you think it's appropriate, I can create a PR and further discuss the specific details :)

Hi @windowsair,
I would definitely be interested in that. Some effort in to doing exactly that has been tried previously but for some reason it was never finished.
I don't think there's much in the actual code that really depends on other boost libraries than boost.asio. If there is, then that should hopefully be fairly trivial to remove/rewrite and I definitely wouldn't mind that.
If I'm no mistaken one of the main issues is mostly the tests. I make use of the custom test_stream class from boost.beast and I would of course still very much like to not only keep the tests but also have them enabled for a non-boost dependent version of the library.
Not sure if it might be worth it to try and implement our own test_stream class or if a non-boost version would simply still depend on boost for the tests. Implementing a test_stream for asio is not trivial but definitely not impossible either.
But first of all feel free to open a PR and let's take it from there.
Thanks a lot.


BUG: Error modifying the local storage size of pod

Sealos Version
sealos-desktop-frontend: eb2f0aed
How to reproduce the bug?
Modify the size of local storage

What is the expected behavior?
No response
What do you see instead?
No response
Operating environment
- Sealos version:
- Docker version:
- Kubernetes version:
- Operating system:
- Runtime environment:
- Cluster size:
- Additional information:

Additional information
No response

default localpath storageclass not support resize


Ensure files and database represent same state

If the jobs are run at different times, the two backups may not correspond to the same version of the site.
Put site in maintenance mode while jobs are run?

Could combine the two jobs into one 'automated job'.


Consider having polling an error represent the final Stream value

Consider having polling an error represent the final value. In other words, a poll that returns an error means that poll should never be called again. In the case of a Stream, this means that an error indicates the stream has terminated.
This issue is a placeholder for the associated discussion.
cc @aturon

@alexcrichton and I debated this initially, and the two options are equally expressive, in that a given stream can be set up to behave either way in either approach (e.g. by using Result in the Item type). So the question is what is the most convenient/straightforward default.
I tend to think that it's much more common for stream errors to be "fatal" than recoverable, so I agree with @carllerche that we've probably chosen the wrong default here.

I also think that this is largely a question of what the combinators do. For example the TCP listener probably won't fuse itself once an error happens but rather will continue to keep accepting sockets. The combinators, however, would be able to assume that when an error happens or Ok(None) happens that everything is terminated.
Sounds reasonable to switch to errors == "end of stream"

Terminating a stream on an error would simplify the life of implementers of the
Stream trait, as they wouldn't have to ensure any particular behaviour of
further polls after returning an error (presuming that behaviour of poll after
termination is still left unspecified).
The main question seems to be indeed, what combinators would do in that case.
They could be overspecified with respect to errors, and continue to behave
exactly the same as they currently do (probably with exception of fuse). In
this case the difference would not be particularly important.

I the world with streams terminating on an error, would there still be a place
for combinators that recover from errors like or_else and then?
They could recover from one error, but what next? Their only option seems to be
to terminate the stream, as otherwise they would be breaking the Stream
contract. Notice that it is the combinator that would be breaking the contract
on continued polling, not a downstream consumer.
This seems to be a weak point of stopping on errors. Error recovery is
possible, but only once. Alternatively, those combinators could have stronger
preconditions to work only with streams that permit further polling on errors.

Hm yeah that's a very good point about the combinators. I think this would remove basically all of the "chaining" combinators like and_then, or_else, and then. More specifically:

or_else would only allow for recovery of one error, which seems odd
then similarly would only allow catching one error, which seems odd
and_then would maybe generate errors from futures, not the stream. This error would enter the stream and then oddly terminate it even though the original stream is just fine.

That... may slightly change my opinion here. @carllerche @aturon thoughts about the effect on these chaining combinators with streams?

IMO this is an argument in favor of having the Stream error terminate the stream.
There are two different error classes with streams:

A stream of values that are either OK or errors.
An error in the production of values, which means that no further values may be produced due to that error.

The current behavior of stream errors implies the first category which makes the second class of errors difficult to model.
If, however, the stream error terminates the stream, this implies that a stream error follows under group #2.
TcpListener::incoming is group #1, in which case, I believe this is modeled much better with a Stream<Item = Result<T, E>, E2>
This lets you differentiate between producing an error value, and an error in value production (you can have potentially two different error types).
As pointed out, combinators like or_else, and_then, then, etc.. don't make sense anymore, but a different set of combinators do:
incoming
  .map(my_or_else_fn)
  .take_while(Result::is_ok)

For example would provide similar behavior as the current or_else

I would also favour the approach of termination of stream on errors. I find that an error which terminates the stream is much more common than one which is an "expected value" and is recoverable from.
(FYI Rx also does this and it has error handling "operators" if you want to check how and_then et. all can be modelled in the new system).

Hm I wonder if we'd perhaps have:
fn and_then<F, R>(self, f: F) -> impl Stream<Result<R::Item, R::Error>, Self::Error>
    where F: FnMut(Self::Item) -> R,
          R: Future,

That is, @carllerche I agree that if we had these semantics then a TCP listener would be that form of a stream. I find and_then to be a very useful combinator, however, and it'd be a shame to lose it. If, however, and_then just transformed the Item type then perhaps that could work.
I'm still a little uneasy about the composition story though, it doesn't feel quite right...

You could do something like this, which would have the additional benefit of being able to have different have different error types for the different category of errors:
fn and_then<F, T, E, U, R>(self, f: F) -> impl Stream<Result<U, E>, Self::Error>
    where Self: Stream<Item = Result<T, E>> + Sized,
          F: FnMut(T) -> R,
          R: IntoFuture<Item = Result<U, E>, Error = Self::Error>
{
    // ...
}

... it is a lot of generics though...

I think this PR is relevant to the discussion: https://github.com/alexcrichton/futures-rs/pull/199/files
Aka, if an error is passed through without terminating the stream it is unclear if it should count as an element or not.

If we go with this (which it seems like we will) we should update stream::iter to take an iterator of items, not an iterator of results.

Shouldn't this be encoded by type? Currently Stream::poll takes &mut self, which indicates self is always in correct state after execution of poll. The other case would be encoded by move.
Maybe we could have two traits (names invented just for now):
enum StreamAsync<S: FallibleStream> {
    Ready(S::Item, S),
    NotReady(S),
}

trait FallibleStream {
    type Item;
    type Error;

    fn poll(self) -> Result<StreamAsync<Self>, Self::Error>;

    // combinators
}

trait InfallibleStream {
     type Item;
     // We don't need error here.

    fn poll(&mut self) -> Async<Self::Item>;
}

// This bridges the two:
impl<S: FallibleStream> InfallibleStream for Result<S, S::Error> {
    type Item = Result<S::Item, S::Error>;

    fn poll(&mut self) -> Async<Self::Item> {
        // Too lazy to write actual code, but the idea is to replace Self::Ok with Err if stream fails.
    }
}

I admit it'd somewhat complicate the API but it might express constrains more clearly and it'd be checked by compiler.
What do you think?

@Kixunil yes that was considered long ago in the initial early design stages of this library, but unfortunately it suffers a few problems.

Usage of such an interface isn't always the most ergonomic. With so many types always moving there's lots of variable binding and inability to store values in structures.
The Stream trait is no longer object safe, precluding type erasure and creating trait objects.
Performance can decrease sometimes as moves aren't free and if everything is always moving it can cause unnecessary overhead.

Good points. What exactly do you mean by "With so many types always moving there's lots of variable binding and inability to store values in structures."? I somehow can't imagine, what do you mean.
Also, isn't 3 optimized by compiler? I thought that internally it avoids copying where possible.

It basically means that every function consumes the receiver and then optionally returns it. That means that if you try to store partial state in a struct, for example, you'll have to deconstruct and reconstruct the struct frequently or have a lot of Option fields.

Thank you!
With all this problems, I prefer to keep the semantics as is. Maybe provide some other interface to specify whether error is final. (e.g. is_err_final(&self) -> bool method.)

@Kixunil could you explain why you would like the semantics to stay as is? If the semantics are changed, you can get the original semantics by having a stream over Result.

@carllerche I think mutable reference expresses "the value will stay valid". If error indicated end of stream, what should happen when poll is called again? Panic? Return same error?
Keeping it this way has another advantage of not breaking existing code. :)
Also, one interesting example would be writing to file. The write can fail because of full disk but later it can succeed. On the other hand, I can imagine fatal error.
I'd prefer if the semantics could be defined by implementor. Just single fn is_err_final() may be fine. Or we may require Stream::Error: IsFatal too. Or create other associated type ErrorSemantics with one of Fatal, Restartable, Mixed (Mixed would require Stream::Error: IsFatal) I'm not sure what's best approach here.
I'd love if the constraint could be encoded in type system somehow. To give an example, I dislike the way io::{Read, Write} hard-code error type, so there's no way to statically enforce that writing to Vec always succeeds. I'd love if we could avoid creating similar issue in case of Futures.

I've played with streams in other languages, and found the idea of "errors that don't terminate the stream" odd. Not bad, just odd. I agree with the comments above that you could get the same effect with a stream of Result, so the current behavior of making every item an implicit Result just complicates the common case.

@robey we have these cases:

Stream can never fail
Stream can fail (no future operations are possible)
Stream can temporarily fail producing a value but it might be able to produce later. The decision whether to terminate it is up to the caller

Same with Sink.
How would you model all of these?

@Kixunil I think @alexcrichton's idea from here would let all three cases work: https://github.com/alexcrichton/futures-rs/issues/206#issuecomment-253606465
The first two cases would be the new behavior, and the third case would be handled by making the stream be explicitly of type Stream<Result<A, E>> -- a stream of things that can each be an item or an error.

@robey That sounds reasonable. The problem I see there is someone could accidentally mistake one for the other but that is probably unavoidable anyway.
Anyway, I think my comment still holds: we should specify exactly, what should happen when someone calls poll() even if the stream itself failed?

After implementing my own transport for use with tokio-proto, I agree that having an error terminate the stream makes the most sense, and that as @robey said, a non-fatal error can be handled with Stream<Result<A, E>>.
Regarding @Kixunil's question about poll() on a failed stream, the most robust way to handle would be to have poll() take self instead of &mut self as proposed in @Kixunil 's comment.  I know that @alexcrichton said that this was considered and ruled out, but that approach would make implementing a stream that can fail much nicer.  As it stands right now, my implementation has to save any fatal error so that it can continue to return Ok(None) after an error occurs.  The same would be true if the semantics were that calling poll() on a failed stream panics - it would still be necessary for me to maintain state to know that the panic should happen.  My implementation would be much simpler if poll() could just consume the stream on completion/failure.
I understand the concern about the performance cost of the moves, but a very basic attempt seems to indicate that the necessary code changes wouldn't be that onerous.  As an experiment I created a gist containing an implementation of ForEach::poll() when Stream::poll() takes self instead of &mut self and the necessary changes weren't terribly drastic.  Perhaps other cases are less simple though.

@living180 Thank you for considering my suggestion!
I'd like to revisit my suggestion again since I got into this very recently. I'm implementing an application where correctness > speed (but still it needs to be fast enough).
This is related to Future trait though. Currently, Future takes &mut self and I'd like to have one future produce other (different!) future. However they need to pass non-clone "bus". So the only way to implement it is something like this:
fn poll(&mut self) -> Poll<...> {
    match self.bus.take() {
        Some(bus) => match bus.poll() {
            Ok(Async::Ready(result)) => Ok(Async::Ready(MyNewFuture::new(result, bus)),
            Ok(Async::NotReady) => {
                 self.bus = Some(bus);
                 Ok(Async::NotReady)
            }
            Err(e) => Err(e)
        },
        None => panic!("poll() called twice")
}

This is weird, involves copying from/to Option<T> anyway (it probably can't be optimised away because of panic safety; similar problem as with std::mem::replace_with() - see it's RFC) and also risks panics that could've been statically type checked. It would be much simpler to do with self instead of &mut self.

@living180 note that using &mut self instead of self isn't purely for performance, the consumer ergonomics (e.g. being able to store in a struct field) and object safety (being able to create a trait object) are also quite important!
I do agree though that implementations would be easier with self, there's a number of combinators which have "empty" statements which just panic intended for temporary state.

@alexcrichton I feel like it's repeating pattern. It begins to make more and more sense to me to use two traits and a glue between them. So implementors could use self version and consumers &mut self version. I'm not sure about naming right now, though.
Also I'm not sure about what consumers are. I feel like it's only reactor etc. Could you clarify it?

@Kixunil that's imposing the Option-style cost at all layers of the stack vs only where necessary, though?

@alexcrichton I guess it would be only used at top layer (so you can spawn the future on reactor). It's difficult to tell without actually trying. Of course, my implementation would have to add it's own (optimized) combinators.

I think I figured out how to restore "object safety". I guess this is needed for reactors. The basic idea is that users could create instance of FutureObject<I, E> which would take care of dynamic dispatch. It involves a bit of unsafe inside but it provides completely safe interface for users.
This would completely eliminate panics, usage mistakes without cost of branching (match glue).
The cost of moving would remain but I guess it could be optimised by inlining. Even if not, it might be good choice for people who prefer safety over performance.
I'll post implementation example later.

So, I did it. As I've written previously, if user wants a "trait object" of future, he can use FutureObject<I, E>. It allows all things trait objects do (storing in array, not caring about implementation details, ...) while still being type safe.
As I mentioned, it involves bit of unsafe. The unsafe is hidden behind safe abstraction (idiomatic Rust) and not even public. Also, I believe it's simple enough to be correct. (The reasons are explained in comments in great details.)
The interesting thing is that the abstraction allows putting type unsafe futures into FutureObject too. Another thing I noticed is that fuse() is not needed anymore because the implementation statically prevents accidental poll of resolved future.
The more I play with that code, the more I like it. I'm not saying it's the only good solution but I'm confident it might be useful. I think that having both approaches would be useful. Especially if they function well together.

I'm probably daft, but what IS the primary difference between Box<Future<Item=I, Error=E>> and FutureObject<I,E>?

@ArtemGr  Future as defined in futures-typesafe crate is not object safe because it takes self and obviously requires Self: Sized. Trait objects aren't Self: Sized. Thus, such trait can't be put inside box like Box<Future<Item=I, Error=E>>.
Future as defined in this, "type unsafe", crate is object safe because it uses only references. However, it's not type safe (it doesn't prevent users using it incorrectly; that may lead to panics etc).
Object safety is required for some use cases, as far as I understand, mostly reactors. FutureObject solves this by encapsulating Box<UnsafeFuture<Item=I, Error=E>>. behind safe abstraction. It provides safe interface for it. UnsafeFuture is almost same as Future in this crate with one exception: calling poll() on resolved future is undefined behaviour (UB).
In other words, Box<futures_typesafe::Future<Item=I, Error=E>> is invalid, while FutureObject<I,E> is valid and provides same functionality as one would expect.

@Kixunil Thanks, I've mistaken futures_typesafe::Future with futures::Future for a moment.

@Kixunil if the implementation panics here or if poll is called twice here isn't that UB?

@alexcrichton panic is not UB because there is a call to take() which is identical to std::mem::replace(&mut self.0, None), so after panic, drop is called on None and that is fine. Also, after panic, the implementation of futures_typesafe::Future for FutureObject doesn't return, so there is no self to call that function again.
The whole point of FutureObject is that it encapsulates UnsafeFuture in a way to guarantee that double poll won't happen. It implements futures_typesafe::Future and that mandates consuming self so it can't be called incorrectly by caller. The implementation itself could be incorrect but that's the point of unsafe blocks:

Rust doesn't end unsafety, it just builds a strong, high-visibility fence around it, with warning signs on the one gate to get inside. As opposed to C's approach, which was to have a sign on the periphery reading "lol good luck".

And I'm confident that my implementation is correct, because:

unsafe poll() is called exactly one in whole function
the function consumes self
the function returns self if and only if the unsafe poll() returned Async::NotReady (that accounts for panics)

Ah yes I see now. If you'd like to pursue this I'd recommend moving it to a separate issue thread, as it's much more far reaching than just the title of this issue.

@alexcrichton yeah, I felt like it's becoming OT. I've created a new issue.

Just so I understand - if I'm impl'ing futures v0.1 Stream for a data structure today, and given how existing combinators like or_else work, I must allow poll() to be called after it has returned an Err ?
That is, poll() cannot panic in this situation and must return Ready(None) ?

@Arnavion that's mostly right yeah. It's valid for streams to have poll called again even after they return an error, and the stream must not panic. (or at least not because of that)
Note though that you're allowed to do w/e you'd like after that. Once you return an error you can terminate the stream with Ready(None), you could yield more errors, more items, etc.

I tend to think that it's much more common for stream errors to be "fatal" than recoverable, so I agree with @carllerche that we've probably chosen the wrong default here.

Very often chain stream.op1(...).op2(...).op3(...) will have tiny and simple functions/closures that go into opN(...).
Above else it makes code simple to read. :1st_place_medal:
But this also means that a closure in op1 is not equipped to deal with, say 3, possible conditions besides a normal event. However trivial those runtime conditions can be on a big scale, from a point of view of a small section, their are fatal. Of cause, on a big scale, i.e. on the level of constructing process shaping operations, developer just adds appropriate catch and retry, where desired.

Above point is expressed around 13:20 in a C++ talk about observables. Judgment about error is done downstream, at the most opportune and clean place. Again, clean code theme is here.

For the record, I have changed my mind since I opened this PR and I believe that the current behavior is the best.

@carllerche why? However short you comment is, I cannot read your mind, and I'd love you to share an experience, that made you change your mind.

There can be a middle ground here!

Rx style close-all on error, can be handled by Stream::Error.

The less dangerous errors, on which stream merely "skips the beat" but doesn't close, can be accommodated via Stream::Item being a Result<T> instead of bare T.

A stream returning a Result<Item> should not terminate.
However when the resource underlying the stream returns an Err, the stream should be terminated. If the stream terminated, combinators on it can only return Err unless some action re-establishes the stream's live state (such as jumping the data pointer back to 0 for a stream made from a file resource).
I believe I lean towards handling Err outside of the stream, as it is the only clean way to escalate a problem to something that can fix it. A stream gets closed when its lifetime ends; it is not necessary to close when it becomes invalid and returns Err.

So to clarify, streams should be terminated (by the user), when the stream itself produces Err. The user can choose to allow object lifetimes to close the stream. They can also, if they know the cause, fix the problem and resume normal use of the stream.

streams should be terminated (by the user), when the stream itself produces Err.

Consider the following life example from use of rx.
I use library, or module, written by someone else, of cause. This library let's me to introduce a section of my streams.
Now Err comes from that section. How do I know, if 3rd party code will be ok with me skipping this error, treating it as a "skipped beat", instead of treating it like "big error", for which I may drop the stream and restart its processing from scratch. How am I to know this?

I thought about the form. How about the following formulation.
Let's have completion with error and a natural one. And let's have an event that is either ok, or is a lost-beat error.

If a combinator has a bad error, it does a completion with error.
If a combinator has an error condition, but it may continue working with new events, then it produces a lost-beat error, continuing its operation as normal.
When following combinator gets a lost-beat error, it knows itself if such thing is tolerated by its own algorithm. Tolerated lost-beat error is passed down stream. Else, completion with error is done.
When lost-beat error comes to end, developer can do her own logical decision about it, as usual.

@3n-mb Very good question! I'm big believer in the type system and I believe we should have different types/traits for different behaviors. That way the compiler can check our code.

Hi,
just my $0.02. I'm new to Rust, but I've used to work with RxScala and a little bit with another Scala library, Monix (better designed IMO) in the past. Both strive to be compatible with the Reactive Streams spec. I'm not really sure how similar  futures streams are or want to be to the Reactive Streams spec, but the spec considers the reactive stream done with after encountering an error, no more items are emitted after an error, so I'm used to this behavior.
I'm not sure if this is relevant to the discussion as I'm VERY new to Rust and futures streams. Still, I wanted to mention Reactive Streams in case somebody finds it useful.

Sounds like Reactive Streams deal with non-blocking backpressure.
This overflow notes that streams are pull-based, while observables (rx, or Reactive Extensions) are push-based.
How much tokio streams are pull-based, i.e. include backpressure control, versus observables?
Or, were do tokio streams fit between reactive streams and observables?

@3n-mb I think this is off-topic. Streams are pull-based and sinks are push-based (but they still have backpresure). There's also unbounded channel, which has push-based non-blocking end.

@cramertj was there any particular decision here?

This has been resolved.

(the resolution was to not change the behaviour - a stream returning an error is not terminated and can yield further items or errors)


refine My Profile page

This page is currently OOTB from the Filament Breezy package.  It needs done:

[ ] Compatability with Gravatar
[ ] Addition of Location field

Location field added.  I've removed the Avatar for now


Unknown type

Sometimes I get an Unknown type error. I have 0 explicit types included in the schema types so they're all lazy loaded.
query {
	user {
		reservations {
			... on CourtReservation {
				id
			}
			... on ClassReservation {
				id
			}
		}
	}
}

Error: Unknown type "ClassReservation".
reservations is a list of ReservationInterface, which has implementations CourtReservation and ClassReservation.
It seems the interface doesn't know that until resolveType. Did I set it up wrong? I'm using InterfaceType and ObjectType classes.
I could add ClassReservation to the schema types, but I don't like not knowing why that would be necessary. The entire schema is pretty big, so I like the lazy loading.
When I listen to the type registry, it loads several irrelevant types (fields and args of relevant types), but not ClassReservation...

I guess I understand why it happens. An interface doesn't know its implementations. And there's no name-to-type registry. But how do I fix it without preloading all types in the schema?

I suppose that's exactly what types is for...

Most often it happens when the object type is never referenced in fields directly but is still a part of a schema because it implements an interface which resolves to this object type in its resolveType callable.

So lazy loading is not what I expected. It's not lazy-only-when-needed. It's more lazy-in-the-right-order.
Sorry! Carry on.

You could define types as a closure (which is called when such situation happens). If it doesn't happen, then those types won't be loaded. But yeah, this is an edge case which is hard to combine with lazy-loading.


Fixed S3 bucket URL modifying

Description
Fixes #3139.

TODOs
Read the Gruntwork contribution guidelines.

[ ] Update the docs.
[ ] Run the relevant tests successfully, including pre-commit checks.
[ ] Ensure any 3rd party code adheres with our license policy or delete this line if its not applicable.
[ ] Include release notes. If this PR is backward incompatible, include a migration guide.

Release Notes (draft)

Added / Removed / Updated [X].
Migration Guide

@yhakbar thank you so much for the review!

Resolved in v0.58.8 release.


[docs] TaskLocal APIs from non-Task code

Clarify and add more examples how task locals work in non-Task code -- i.e. that they DO work as expected.
cc @amartini51 for a review after the break

@swift-ci please smoke test


torch_sparse.SparseTensor.size causing problems in Data and graphSAINT

🐛 Bug
It appears that torch_sparse.SparseTensor causes problems when calling torch_geometric.data.Data.num_nodes. I get the following error:
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-6-7db7380be762> in <module>
----> 1 data.num_nodes

~/local/miniconda3/envs/gnn/lib/python3.8/site-packages/torch_geometric/data/data.py in num_nodes(self)
    201             return self.__num_nodes__
    202         for key, item in self('x', 'pos', 'norm', 'batch'):
--> 203             return item.size(self.__cat_dim__(key, item))
    204         if hasattr(self, 'adj'):
    205             return self.adj.size(0)

~/local/miniconda3/envs/gnn/lib/python3.8/site-packages/torch_sparse/tensor.py in size(self, dim)
    212
    213     def size(self, dim: int) -> int:
--> 214         return self.sizes()[dim]
    215
    216     def dim(self) -> int:

TypeError: list indices must be integers or slices, not tuple

I would like to use this because my graph nodes do not have features, so I did the standard thing and put in an identity matrix. The graphs are pretty big, so I want to use sparse matrices here, otherwise, I'll run out of GPU memory pretty quick. The same error occurs in graphSAINT, because it tries to access data.num_nodes.
I'm pretty new to this field and torch_geometric in general, so I was surprised this wasn't working and that this issue doesn't seem to have been reported before. Am I using this incorrectly, or is this something that just isn't supported yet?
To Reproduce
import torch
import torch_sparse
import torch_geometric as pyg

edge_index = torch.tensor([
    [1, 0, 3, 1, 2, 0],
    [0, 1, 1, 3, 0, 2],
])

num_nodes = len(edge_index.unique())

x = torch_sparse.SparseTensor.eye(num_nodes)

data = pyg.data.Data(edge_index=edge_index, x=x)

data.num_nodes  # causes error

Environment

OS: Ubuntu 16.04
Python version: 3.8.3
PyTorch version: 1.6.0
PyTorch geometric: 1.6.1
PyTorch sparse: 0.6.7

It is also worth mentioning that I had run graphSAINT successfully using torch.sparse.FloatTensor instead of torch_sparse.SparseTensor, in which case getting num_nodes works, but in that case graphSAINT failed because torch.sparse.FloatTensor doesn't support proper indexing. I implemented a fairly simple workaround by monkey-patching GraphSAINTSampler.__collate__  to properly index sparse matrices.
However, I'm now playing around with RGCNs, where torch.sparse.FloatTensor raises errors, and there doesn't appear to be a straightforward way to fix this. Hopefully, it will work with torch_sparse.SparseTensor, if I can somehow deal with the bug above.

Hi and thanks for this issue. Using sparse node features is an interesting idea but it currently isn't officially supported in PyG, and most GNN operators require to operate on dense feature representations.
Furthermore, I do not think that using sparse identity matrices as input features doesn't help in reducing memory complexity of your model since your weight matrices in the first GNN will have a memory complexity of O(N) nonetheless.
An alternative solution is to simply use random node features of low-dimensionality, e.g.,
data.x = torch.randn(data.num_nodes num_features)

or to use a trainable embedding layer, e.g.:
data.n_id = torch.arange(data.num_nodes)
loader = GraphSAINT(...)

embedding = torch.nn.Embedding(data.num_nodes, num_features)

for data in loader:
   x = embedding(data.n_id)

I see. I was under the impression that using an identity matrix was standard practice when nodes don't have features.

Furthermore, I do not think that using sparse identity matrices as input features does help in reducing memory complexity of your model since your weight matrices in the first GNN will have a memory complexity of O(N) nonetheless.

I don't know how it would affect the model, but it would certainly help in general, right? If I have a graph of e.g. 100k nodes, forming a dense 100k by 100k matrix is really expensive, so I can run out of memory (not GPU memory) before we even get to modeling. On the other hand, if I formed a sparse 100k by 100k matrix, that's just 300k numbers, which is easy to handle.
I suppose a very easy workaround is to just convert the sparse chunks to dense matrices before passing them to the model, after graphSAINT generates smaller graphs. But that still requires graphSAINT to support sparse matrices.

An alternative solution is to simply use random node features of low-dimensionality, e.g.,

That's interesting. Is this more standard than using the identity matrices? I am fairly new to the field, so I am still trying to figure out what is ok and what isn't.

or to use a trainable embedding layer

I am doing link prediction in the hopes of getting good node embeddings, and it seems to work well. But I take these embeddings at the last layer of the auto-encoder, before they are passed into the decoder. Do you think getting embeddings in this way would be a better way?
Thanks for the quick response!

Yes, it is standard practice when nodes do not have features (at least for transductive learning), but it's actually equal to learning an embedding matrix. Here, you would still use the last layer to perform link prediction - it's just that an embedding matrix is equal to performing I @ weight.
Using random node features isn't so common, but it is sufficient to learn structural features.
I see what I can do to support sparse matrices for Data though :)

Yeah, I don't know how not having node-features would work in an inductive learning scenario.

it's just that an embedding matrix is equal to performing I @ weight

That makes a lot of sense. So technically, we're adding a linear transformation to the identity matrix before passing it through any convolutions. This does increase the number of parameters I guess, but should also increase model capacity?

Using random node features isn't so common, but it is sufficient to learn structural features.

I tried this, and it seems to be working somewhat well.
Thanks a bunch, you've been very helpful!


Fix typo in watch doctstring

Thank you for your work.

Fixed a small doc typo.
Added indentation to the nested list in  force_polling decision logic (it was flattened by HTML rendering)

Great, thanks so much.


Adding the Watson Developer Cloud package to my Anaconda Python 64-bit 3.5 environment

I'm trying to add the Watson Developer Cloud package to my Anaconda Python 64-bit 3.5 environment. I got this error trace.
[Window Title]
Python Tools for Visual Studio
[Main Instruction]
An unexpected error occurred
[Content]
Please press Ctrl+C to copy the contents of this dialog and report this error to our issue tracker.
[^] Hide details  [Close]
[Expanded Information]
System.Runtime.InteropServices.COMException (0x8000FFFF): Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at Microsoft.VisualStudio.ErrorHandler.ThrowOnFailure(Int32 hr, Int32[] expectedHRFailure)
at Microsoft.VisualStudioTools.Project.OutputWindowRedirector.b__11_0()
at Microsoft.VisualStudioTools.UIThread.Invoke(Action action)
at Microsoft.VisualStudioTools.Project.OutputWindowRedirector.ShowAndActivate()
at Microsoft.PythonTools.InterpreterList.InterpreterListToolWindow.PipExtensionProvider_OperationStarted(Object sender, ValueEventArgs`1 e)
at Microsoft.PythonTools.EnvironmentsList.PipExtensionProvider.OnOperationStarted(String operation)
at Microsoft.PythonTools.EnvironmentsList.PipExtensionProvider.d__52.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.PythonTools.EnvironmentsList.PipExtension.<InstallPackage_Executed>d__12.MoveNext()

It turns out that I get this error trying to add anything in the pip.

See whether opening the Output window (View, Output) and then trying again helps. The problem seems to be activating that window, so if it's already active, it should work better.
I believe we have fixed this for our next version though.


Why train_input_fn outputs 3 values

In this function you outputs 3 values [x_train, x_len_train, y_train]:
def train_input_fn():     dataset = tf.data.Dataset.from_tensor_slices((x_train, x_len_train, y_train))     dataset = dataset.shuffle(buffer_size=len(x_train_variable))     dataset = dataset.batch(100)     dataset = dataset.map(parser)     dataset = dataset.repeat()     iterator = dataset.make_one_shot_iterator()     return iterator.get_next()
However, in Google document, they say:

The return value must be a two-element tuple organized as follows: :

The first element must be a dict in which each input feature is a key, and then a list of values for the training batch.

The second element is a list of labels for the training batch.

So I don't really understand that how custom Estimator can work with a tuple of 3 values
Thanks in advance

The dataset API has functional-like interface for chaining operation on the input pipeline. In this case we are using the map method with the parser argument that takes the tuple of three arrays into the two-element structure that you describe


"window.nativeTabs": true - Not working.

"window.nativeTabs": true - Not working for me.
Mac OS 10.12.6
VSCode 1.17

same here, had to disable it, cos it just always shows the last window u open and no way to go to another one.
VSCode 1.17
OSX 10.13.1


Option to Enable/Disable MX Records Check

We encountered an issue with the CheckMX functionality as it currently lacks a configurable option for disabling this check. It would be highly beneficial to have a similar functionality to that of CheckSMTP, which already implements an option to enable or disable SMTP checks using a bool variable:
func (v *Verifier) CheckSMTP(domain, username string) (*SMTP, error) {
    if !v.smtpCheckEnabled {
        return nil, nil
    }
    // ...
}

To address this limitation, I propose introducing a new field specifically for enabling or disabling MX checks in the Verifier. This approach would align with the existing implementation in CheckSMTP.
For example, the modified code snippet could look like this:
func (v *Verifier) CheckMX(domain string) (*Mx, error) {
    if !v.mxCheckEnabled {
        return nil, nil
    }
    // ...
}

I think it makes sense to set mxCheckEnabled value to true by default, so it won't change current behavior.
I am enthusiastic about contributing to this enhancement if my proposal aligns with your vision.

Hi  @fabl3ss
Thanks for the business scenarios and suggestions you mentioned, your suggestions are very useful！ Feel free to PR 😃


Suggestion: There should be a Link / href option in table cells

Hello @rdunk,
Currently I have a requirement of adding Links inside the table cells (User can add link to the content inside the table similar to sanity portable text functionality).
It would be good if you have a look in this feature as request :)

Same here. @MrFarhan what did you end up doing?

unfortunately no :(

Does anyone have any workarounds to solve this?

Unfortunately no.


CLI Metadata Foundations

WHY are these changes introduced?
To answer:

How to gather data from plug-ins when from centralised functionality like metadata logging
How to track transient runtime metadata during a command's execution
How to be extremely careful about sensitive & public data re: Shopify Monorail

This doesn't include tracking of any new data, and doesn't touch Bugsnag metadata.

WHAT is this pull request doing?

changes how reporting of Shopify Monorail events is performed
adds hooks for capturing plug-in wide metadata
adds a container for runtime metadata

How to test your changes?

yarn shopify app info --verbose --path=<your project> , will include the analytics payload (but won't submit it) in the output.

planning to add metadata for any plugin soon?

Yep! This PR would get too big with the instrumentation added though I think.


PowerToys.Awake use of --pid results in no Info messages being displayed

Microsoft PowerToys version
0.70.1
Installation method
PowerToys auto-update
Running as admin
No
Area(s) with issue?
Awake
Steps to reproduce
Example showing Info messages being displayed

Open Windows Command Prompt terminal window.
Enter this command:
"C:/Program Files/PowerToys/modules/Awake/PowerToys.Awake.exe" --time-limit 5

Example showing Info messages not being displayed

Open Windows Command Prompt terminal window.
Enter this command:
"C:/Program Files/PowerToys/modules/Awake/PowerToys.Awake.exe" --time-limit 5 --pid 123

In this 2nd case, a PowerToys.Awake console isn't opened.  There is no display of Info messages.  The program detaches from the Command Prompt and runs in the background.  It can be viewed in Task Manager.
✔ Expected Behavior
A PowerToys.Awake console to be opened, inside which Info messages are displayed, just as they are when --pid is not used.
❌ Actual Behavior
No PowerToys.Awake console is opened.  No Info messages are displayed.
Other Software
No response

Are you still experiencing this issue? /needinfo


[Facelift] Touch multiple visual features of the mod for a fresh look

UI Facelift Ideas
Follow a list of suggestions below, apply changes to make the mod look better and fix some usability issues. This should take short time and produce outstanding visual improvements without major changes to the code:

[ ] Main panel

[ ] Larger buttons, square
[ ] Larger icons
[ ] Color coding buttons for 🟥TL, 🟦junction control, 🟩traffic types control
[ ] Clear/despawn buttons - replace with some visually distinct controls also color coded 🟪

[ ] Priority tool (investigate: improvements without overhaul)
[ ] Junction restrictions tool (investigate: improvements without overhaul)
[ ] Lane arrows tool: Larger arrows on buttons, without overhaul
[ ] Speed Limits UI: tweak numbers to make it more compact
[ ] Lane Connectors tool has terrible curve visibility especially when cars are on the crossing. Update it to render a contrast thicker curve first and then colored thinner curve over it for better visibility.
[ ] When route connectors, custom arrows, speed limits? prio signs and limits are destroyed as a part of road UPGRADE (not bulldoze), show floating text above the cursor.

I think we should also consider removing two buttons from the main menu bar:

Toggle despawn

The despawn option is more of a gameplay thing, not a tool. There's already an option on Gameplay tab in mod options to toggle it.

Clear traffic

Clear traffic is more of a maintenance thing, it would be better as a button on the Maintenance Tab.

Toggle despawn is popular with streamers though. Clear traffic does indeed belong to options.

Can you upload the icons as 50% grey on transparent background (so they can be easily colorised in-game) and I can work on getting the UI done.

Adding another note to facelift EPIC above
The icons used for traffic type restrictions are all red/white and can be oriented left-right or right-left, i.e. when not paying attention and for example clicking only last and one before last, it is very easy to edit an rotated road segment and click wrong icons.
Suggestion:
Use different color groups for traffic, public transport, emergency.

From user perspective, my needs are:

Clear, distinct and disambiguated icons
Clear distinction between 'allow' and 'disallow' states
Visual feedback showing which lane is being edited
Smaller footprint (particularly to avoid overlap with overlay icons on nearby roads)

Some ideas...
Glyphs:

Taxi looks almost identical to car icon, but could also be mistaken for a police car (is that a flashing light on top?)

first concept - calling for a taxi, but would be too disruptive visually
second concept - hailing / "flagging down" a taxi, but visually heavy
third concept - traveller hailing a taxi, clean and extremely disambiguous

suitcase looks naff, maybe mashup with this one?

SOS is too wide and not emotive enough; and does it mean anything in asian cultures? Also the restriction only applies when responding to emergency calls, right? When the lights are flashing...

first concept
second concept
third concept

Background:
Remove the red/green border - wastes space and obfuscates glyphs.
Charcoal color (eg: #999) background, then:

Off-white (eg. #ccc) glyph = disallowed
Colored glyph (relevant to service, eg. yellow for taxi) = allowed

Would need more than just color to distinguish - maybe a thin line under or around the glyph or something?

Could we depict it a bit like a narrow toolbar? Might be too visually cumbersome though?
Lane feedback
Making buttons / toolbar (whatever) follow the curvature of road would look bad and impair usability. So maybe just the tried and tested 'lane sausages' as per #391 ?
If we take toolbar approach with background, then we'd have single consistent mouse-over/out areas with which to show/hide the lane sausages.
Smaller footprint
Glyphs could be about 75% of their current size maybe?
Removal of the red/green border lines will save a lot of space.

Toolbar approach is bad because we do not want to rotate it, remember the experiment with rotating lane arrows panel, which worked great but was confusing for some. And then if we do not rotate, it becomes just as confusing as lane arrows.
I will play with icons and colors and try making something

For background color what about the charcoal color that is used in some parts of Blender:

Doesn't bother me, that is a fine colour to use.
We need to create the palette for the UI. I will also be using it in all new forms.
And style guidelines, but noone taught me how to do that, I'd just follow something pre-existing like Material design (by Google, Android) https://material.io/design/