simplify setting epsilon

For PR #8710
@ozabluda I made the logic into a single line... what do you think?

I like this style more, since I like more compact code (more lines per screen), which is my prime goal, everything else (code clarity) being equal. Many lines can be saved like so:
if epsilon is None: epsilon = K.epsilon()
and there are many other ways in Python to squeeze more of it into a single line (including else)
self.epsilon = K.epsilon() if epsilon is None else epsilon
or
self.epsilon = (epsilon, K.epsilon())[epsilon is None]
even  a whole case/switch statement can be done this way.
However,

existing codebase almost always uses the original style, with (with rare exceptions using your style)  and maintaining consistency is very important.
my opinion doesn't matter, @fchollet is the keeper of the style, the original is his, I predict it won't be merged.

Another alternative is to modify K.epsilon() so that the following works:
self.epsilon = K.epsilon(epsilon)
but this would preclude combining K.epsilon getter and setter in the future (not likely to happen anyhow). On the plus side, K.epsilon(epsilon) could warn about nonsensical epsilon.

ok cool closing it then. thanks!


Update everyone and all projects to Cubemx 6.11

update version in firmware/readme
this may require an update to the Java version as well
To "update all projects", open each .ioc file in CubeMX 6.11 and select "Migrate" if prompted.

Obselete. Updated to 6.12 in #156


[DO NOT MERGE] Restore support for .NET 4.0

Added ReflectionHelper class which contains the ifdef statements.
Added 'do not merge' since I want to gather feedback on this. Is this something we want to do?

Won't be pulling this in.


[Feature Request] allow user to set secondDate for the range datepicker

Thank you for your nice work. It is truly a wonderful library. It would be nice if one can set the secondDate prop to set the second datepicker component's default date in the range type datepicker. Something like
    const [firstDate, setFirstDate] = useState<dayjs.Dayjs>(
        startFrom && dayjs(startFrom).isValid() ? dayjs(startFrom) : dayjs()
    );
    const [period, setPeriod] = useState<Period>({
        start: null,
        end: null
    });
-   const [secondDate, setSecondDate] = useState<dayjs.Dayjs>(nextMonth(firstDate));
+   const [secondDate, setSecondDate] = useState<dayjs.Dayjs>(
+     endIn && dayjs(endIn).isValid()
+       ? dayjs(endIn)
+       : nextMonth(firstDate)
+   );

Hello @kyarame 👋
Thank you for using our package.
So sorry for the delay. Thanks for the feature request. Rest assured that we will implement it very soon.
RPs are always welcome 🎉.


ECONNRESET at TLSWrap.onStreamRead issue impacting Azure extensions zip deploy (related to Node v16?)

Does this issue occur when all extensions are disabled?: No

VS Code Version: VS Code 1.66.0
OS Version: macOS 12.3 Monterey

The zip deploy feature present in the Azure Functions and Azure App Service extension broke in production as a result of the 1.66.0 VS Code release. It does not reproduce on 1.65.2.
The zip deploy feature uses the yazl package to create a .zip archive of app files and then sends a POST request streaming the archive. The code related to archiving lives here.
On version 1.66.0, the following error is thrown after initiating the POST request.
Error: read ECONNRESET\n at TLSWrap.onStreamRead (node:internal/stream_base_commons:220:20)\n at TLSWrap.callbackTrampoline (node:internal/async_hooks:130:17)
We're able to reproduce the issue consistently. During our investigation, we noticed that launching the extension with NODE_DEBUG=stream fixes the issue and allows for a successful zip deploy. This is really strange to me and any insight into why this might be happening is greatly appreciated. Does anyone know of specific changes to the Node.JS stream module, and how they could be effecting this?
We know that VS Code has upgraded from Node.JS v14 to v16 in 1.66.0. And suspect that this upgrade is related to this issue. Were there any other changes that could be impacting this?
Steps to Reproduce:
Use the Azure Functions or Azure App Service extensions and use the Zip Deploy method of deploying to an app.
Related issues:
https://github.com/microsoft/vscode/issues/146470
https://github.com/microsoft/vscode-azurefunctions/issues/2844
https://github.com/microsoft/vscode-azureappservice/issues/2191

Same here. https://github.com/microsoft/vscode/issues/146470#issuecomment-1086157357

There were quite some changes in node between 14 and 16. I remember at least https://github.com/nodejs/node/pull/33035 which caused problems in Hapi.
FWIW upload fails for me with 1.65.2 if I set NODE_DEBUG=stream. Just now I was able to upload with 1.66 without setting anything (once).
Best guess here is that this is a timing issue. Maybe server ends connection fast for some reason and depending on node version, debug logging this connection reset arrives earlier or later on client side and is ignored in some cases but not in others.

FWIW upload fails for me with 1.65.2 if I set NODE_DEBUG=stream. Just now I was able to upload with 1.66 without setting anything (once).

Are you debugging the extension from source? Or running VS Code with NODE_DEBUG=stream?

Best guess here is that this is a timing issue. Maybe server ends connection fast for some reason and depending on node version, debug logging this connection reset arrives earlier or later on client side and is ignored in some cases but not in others.

We are thinking along those lines as well. Hasn't been easy to pin down. Thank you for pointing me to https://github.com/nodejs/node/pull/33035, I will look into that.

I executed VS Code with NODE_DEBUG=stream (tried also NODE_DEBUG=http) as I have no idea how to execute the individual commands issued by the extension.

Merging to https://github.com/microsoft/vscode/issues/146470, please subscribe to that issue for updates.


On IdP creation JIT Provisioning Configurations defaults to PRIMARY userstore

Describe the issue:
When creating an IDP (any kind of template) the JIT provision config always defaults to PRIMARY user store when we send it with a different user store.
How To Reproduce:

Create an IDP via the API. (Initially make isEnabled to false)

"provisioning": {
    "jit": {
      "isEnabled": false,
      "scheme": "PROVISION_SILENTLY",
      "userstore": "CUSTOMER-DEFAULT"
    },

Check the saved model from the request's response.
It has saved as userstore: PRIMARY

Expected behavior:
Should preserve "userstore": "CUSTOMER-DEFAULT"  when the model is created initially. It should not modify any subfields.
Notes
The PUT call of jit provisioning working as expected. But not the POST call

@lashinijay Can we close this issue?


Create a method that repeatedly fits base learners on different feature subsets for tabular data

Issue #, if available:
Description of changes: Created fit_with_prune method for AbstractModel that repeatedly alternates between model fitting and feature selection using permutation feature importance score until the validation score performance drops. This functionality can be tentatively accessed by providing a dictionary argument with key fit_with_prune to TabularPredictor's ag_args.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

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

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

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

I made all the changes but made it so that if the pruned refit performance is equal to original performance we don't use the pruned model since in certain cases, we can over-prune but have same validation set performance (ex. small dataset where validation set is also small).

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

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

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

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

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

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

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

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

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

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


epic: esl-core-2.0 basic updates

In bounds of this update:

extend CSSClassUtils with has method
add esl-utils with attr helpers
extend ESLBaseElement with $$attr and $$cls shortcut
update attributes decorators with ability to work on Element instances or objects with {$host: Element} representative

:tada: This PR is included in version 3.14.0-beta.1 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 3.14.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


tektoncd-cli: 0.22.0 -> 0.23.0

Description of changes

bump tkn to 0.23.0
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[X] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[X] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[X] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[X] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 163450 run on x86_64-linux 1

1 package built:

tektoncd-cli


Update bubble_sort.cpp

bubble_sort.cpp: Add BubbleSort Algorithm
This adds BubbleSort Algorithm which return the sorted array with the elements selected by the user.
// Sorry if I didn't understand the commit guidelines correctly.

For short term contributors: we understand that getting your commits well
defined like we require is a hard task and takes some learning. If you
look to help without wanting to contribute long term there's no need
for you to learn this. Just drop us a message and we'll take care of brushing
up your stuff for merge!
Fixes #{ISSUE_NUMBER}
By submitting this pull request I confirm I've read and complied with the
below declarations.

[x] I have read the Contribution guidelines and I am confident that my PR reflects them.
[x] I have followed the commit guidelines for this project.
[x] My code follows the standard code structure.
[x] This pull request has a descriptive title. For example, {Tag}: Add {Algorithm/DS name} [{Language}], not Update README.md or Added new code.
[x] This pull request will be closed if I fail to update it even once in a continuous time span of 7 days.
[x] This pull request shall only be reviewed and merged once all the checks passes. No maintainer or supporter shall be obliged to review it before this condition is met.
[x] I have mentioned the issue number correctly (with hyperlink) in this pull request description.

After you submit your pull request, DO NOT click the 'Update Branch' button.

Hey @lumendesp,
Something went wrong with the build.
TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.
View build log
TravisBuddy Request Identifier: 4c360530-0dc1-11eb-9111-f326d0cb7f09


fix: jumpy bottom tab bar when keyboard pops up

This PR resolves []
Description
Fixes a regression that was introduced in https://github.com/artsy/eigen/pull/10953. The issue was reported by @dblandin in slack (see thread)
Before Login

Before
After

Device has
Light Theme

Device has
Dark Theme

After Login
|Before|After|
|Device has|Light Theme|
|||
|Device has|Dark Theme|
|||

PR Checklist

[x] I have tested my changes on iOS and Android.
[x] I hid my changes behind a feature flag, or they don't need one.
[x] I have included screenshots or videos, or I have not changed the UI.
[x] I have added tests, or my changes don't require any.
[x] I added an app state migration, or my changes do not require one.
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added a changelog entry below, or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

jumpy bottom tab bar when keyboard pops up - gkartalis

Dev changes

Need help with something? Have a look at our docs, or get in touch with us.

This PR contains the following changes:

Android user-facing changes (jumpy bottom tab bar when keyboard pops up - gkartalis - gkartalis)

  Generated by :no_entry_sign: dangerJS against 5816e437a7b364607108485dd51aaf4aa0e3bf20

Looks like the screenshots and/or screen recordings references in the PR description failed to upload. Happy to test out a build on my Android device if it's helpful!

@dblandin unfortunately as I was recording screenshots / videos I realized that this fixes the issue you encountered but the status bar on android is really broken everywhere.
ended up creating a ticket in sapphire board  and we will treat it as a launch blocker for the release in order to fix both your issue and the status bar issues.
Let me know if you have any thoughts


US21: Upon succesful registration, the user is redirected to the menu screen.

Closed with commits: 17d6b3356f10d16670394d80c9e4f8562c55e7e6 & sopra-fs24-group-34/sopra-fs24-group-34-server@3dc509249188848c4f975643109e7e76bfc203cf


circleci: coverage.sh: 改善内存消耗

这个 PR 实现什么功能/修复什么问题:
circleci: coverage.sh: 改善内存消耗
是否需要 backport 到之前的 release 分支:

release/2.10.0

/area util
/cc @Zexi  @swordqiu

Codecov Report

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

@@          Coverage Diff           @@
##           master   #2216   +/-   ##
======================================
  Coverage    7.07%   7.07%
======================================
  Files         451     451
  Lines       71092   71092
======================================
  Hits         5029    5029
  Misses      65651   65651
  Partials      412     412

Flag
Coverage Δ

#aFlag
7.07% <ø> (ø)
:arrow_up:

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 c60913e...4749dd9. Read the comment docs.

/lgtm

/approve


Cleaning all DRC rules from unnecessary polygons and extended commands and making sure all values are in um

Cleaning all DRC rules from unnecessary polygons and extended commands and making sure all values are in um

Thanks @FaragElsayed2


user login via SSLCLIENT_LOGIN_URL works but not via LOGIN_URL giving username, password

I am able to run the code and login via ssl client verification (using nginx/gunicorn etc). But when using the login without ssl client verification, (using LOGIN_URL from settings.py) I get the username/password entry page, but the user login does not go through.
In base.py, process_request() calls authenticate in SSLClientAuthBackend() which in turn calls USER_DATA_FN. But that is wrong as it is again getting the username from the cert instead of the form entry

Configuration error! In settings.py, the AUTHENTICATION_BACKENDS should have both ModelBackend and SSLClientAuthBackend


Upgrade to latest CDT

It'd be great to upgrade these examples to use the latest CDT so when people copy / paste into their latest environments they don't get build errors.
I'd be happy to help if that's a thing you're interested in doing.

Hi Kevin, thank you for reaching out. This is definitely something I'm looking into and I'd really appreciate the help. I haven't had the time, and won't for another 4 weeks. But if you'd like to start contributing, I'd be happy to review and merge your changes in. I'll send you an email now as well to touch base. Thanks again!


HADOOP-17808. ipc.Client to set interrupt flag after catching InterruptedException

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 34s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
30m 43s

trunk passed

+1 :green_heart:
compile
21m 12s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
18m 24s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
1m 10s

trunk passed

+1 :green_heart:
mvnsite
1m 37s

trunk passed

+1 :green_heart:
javadoc
1m  9s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
1m 41s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
2m 25s

trunk passed

+1 :green_heart:
shadedclient
15m 37s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 55s

the patch passed

+1 :green_heart:
compile
20m 26s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javac
20m 26s

the patch passed

+1 :green_heart:
compile
18m 28s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
javac
18m 28s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
1m  9s

the patch passed

+1 :green_heart:
mvnsite
1m 34s

the patch passed

+1 :green_heart:
javadoc
1m  7s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
1m 42s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
2m 33s

the patch passed

+1 :green_heart:
shadedclient
15m 40s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
17m  4s

hadoop-common in the patch passed.

+1 :green_heart:
asflicense
0m 57s

The patch does not generate ASF License warnings.

176m 41s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3219/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/3219

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux 69781cbc9b9b 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 1cd3ad1fcc626adf064d6cd35fe979827c15bced

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3219/1/testReport/

Max. process+thread count
1328 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common U: hadoop-common-project/hadoop-common

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3219/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

@jojochuang @aajisaka Could you please take a look? Found this as part of a test in TestRPC, thought it's worth fixing.
Thanks

Thanks for the review @jojochuang. Could you please help merge this change?
Thanks

@virajjasani Thanks for contribution, @jojochuang Thanks for review!
Merged  to trunk

I just compiled trunk and formatted a namenode locally. Now anytime I run a client command I am getting this output:
$ hadoop fs -ls /test
2021-08-04 15:51:28,532 INFO ipc.Client: Interrupted while waiting to retrieve RPC response.
java.lang.InterruptedException
	at java.lang.Object.wait(Native Method)
	at org.apache.hadoop.ipc.Client$Connection.waitForWork(Client.java:1053)
	at org.apache.hadoop.ipc.Client$Connection.run(Client.java:1100)

Which points to this change, as it is catching, logging and re-throwing the exception. I am not sure yet if I am doing something wrong, but it feels like this change is not doing the correct thing. Is this expected?

Thanks for reporting this @sodonnel. I believe the change of setting interrupt flag whenever Client receives InterruptedException should be done (we are doing it at all other places in ipc.Client) but perhaps logging at INFO level is too much because interruption is expected to happen while awaiting RPC response.
Let me create an addendum to remove logging from the cached Exception.

Thanks for the explanation. I guess removing the log message is probably the correct thing to do.

Sure thing, let me create an addendum PR right away.
Thanks


Fix tranform matmul test failure on AArch64

Use a wirdcard regex to match non x86 targets in
transform_dialect/cpu/matmul.mlir test.

I was about to update the patch but noticed you already adjusted it, thanks! FYI I've done the request to be added to the Arm CLA so that issue should be fixed soon (probably not today though).

I was about to update the patch but noticed you already adjusted it, thanks! FYI I've done the request to be added to the Arm CLA so that issue should be fixed soon (probably not today though).

Done

Hi @benvanik , I believe @nicolasvasilache has fixed the issues you highlighted in your review. Does this PR look good now? Do I need to merge the latest IREE main branch into my branch?
Best regards,
Thomas

Dropping pull request since it has been fixed by aac4d646189def01fe04d1650593a252deaf7f9f


Remove infinite retries from sendMessage.

Remove infinite reties in case we get a ChannelPoolClosedException. We try re-sending a message maxRetries amount of times.

LGTM


Edge-case Handling and Test Enhancements in yamlhelper

PR Type:
Bug fix

PR Description:
This PR focuses on improving the robustness of the yamlhelper package by handling edge cases that could lead to index out of range errors or other unexpected behaviors. It also adds several edge-case tests to ensure the correctness of these changes. The main changes include:

Adding checks to prevent index out of range errors in various functions.
Modifying some functions to handle edge cases such as negative indices or empty slices.
Adding new test cases to yamlhelper_test.go to verify the correct handling of these edge cases.

PR Main Files Walkthrough:
 files:

core/pkg/fixhandler/yamlhelper.go: Added checks to prevent index out of range errors in functions like adjustContentLines, adjustFixedListLines, enocodeIntoYaml, indentContent, getNodeLine, getFirstNodeInLine, and removeLines. Also, modified the getFirstNodeInLine function to return -1 when the given line is not found in the list.
core/pkg/fixhandler/yamlhelper_test.go: Added new test cases to verify the correct handling of edge cases in adjustContentLines, adjustFixedListLines, enocodeIntoYaml, indentContent, getNodeLine, isSameNode, getFirstNodeInLine, and removeLines. These tests ensure that the changes made in yamlhelper.go work as expected.

/describe

/improve

@sulemaanhamza what do you think about AI suggestions?

@sulemaanhamza what do you think about AI suggestions?

Quite reasonable suggestions. My test cases are still passing if we proceed with AI suggestions.

Quite reasonable suggestions. My test cases are still passing if we proceed with AI suggestions.

Please do it in one commit

@matthyx Done!!


populate_db: Increase entropy of messages generated

We have a new generate_test_data framework for generating test messages, which is great in that it includes a bunch of rich syntax now, but it definitely still needs work to increase the variability in the messages it generates.

A pretty straightforward way would be to use itertools.permutations-- in load_generators we could use a random int i from 0 to n! and then choose the i-th permutation to be the one which itertools.cycle is applied to.

I think the issue here is that we're caching a fixed set of messages to pick from, theoretically for performance reasons, but given the actual speed, I think we might want to just have the default mode not use that cache by default (I think only if we're making ~1M messages do we want the cache).

Sure, would we be substituting the cached messages for just random strings? random strings with randomized flair?

Yeah, I was thinking we just use an iterator against zerver/lib/generate_test_data.py with random flair, rather than using the cache.  Might make sense to lave the current behavior available under an option; I can imagine it being useful for certain debugging tasks.


Help Wanted - Request Signature We Calculated Does Not Match

"AWS": {
"Region": "Value Entered is:  us-east-1",
"UserPoolClientId": "Value Entered is: User Pool -> My Pool -> App Client Id",
"UserPoolClientSecret": "Value Entered is: User Pool -> My Pool -> App Client Secret",
"UserPoolId": "Value Entered is: General Settings - Pool Id"
},
"AllowedHosts": "*"
} Run the register postback. I get this error.
An unhandled exception occurred while processing the request.
HttpErrorResponseException: Exception of type 'Amazon.Runtime.Internal.HttpErrorResponseException' was thrown.
Amazon.Runtime.HttpWebRequestMessage.GetResponseAsync(CancellationToken cancellationToken) in HttpRequestMessageFactory.cs, line 539
AmazonCognitoIdentityProviderException: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.
Amazon.Runtime.Internal.HttpErrorResponseExceptionHandler.HandleException(IExecutionContext executionContext, HttpErrorResponseException exception) in HttpErrorResponseExceptionHandler.cs, line 60
I have looked pretty closely.  Can't see anything wrong with the implementation.  It seems like I have the correct credentials entered.  My next step is to download the source for this provider code and start digging through the source code.
Before I go down that road, any suggestions would be appreciated.  Am I missing something?

The values you entered look correct.

When I fill out the register (new account) form and submit the form.  Occurs on page Register.cshtml.cs:
When the userManager.CreateAsync function is called.
No white spaces in the settings.
public async Task OnPostAsync(string returnUrl = null)
{
returnUrl = returnUrl ?? Url.Content("~/");
if (ModelState.IsValid)
{
var user = _pool.GetUser(Input.UserName);
user.Attributes.Add(CognitoAttribute.Email.AttributeName, Input.Email);
user.Attributes.Add(CognitoAttribute.PhoneNumber.AttributeName, Input.Phone);
            var result = await _userManager.CreateAsync(user, Input.Password);

It's a brand new ASPNetCore 2.1.1 Web Application with your sample code ported in.  Not sure what AWS Cli (is installed on this dev box) has to do with this issue as that is not called during the DotNetCore code execution.
Installed
Identity.Cognito 1.0.0
Extensions.CognitoAuthentication 1.0.3
ASPNETCore.App 2.1.1
ASPNETCore.Razor.Design 2.1.2
NETCore.App 2.1.0
VisualStudio.Web.CodeGeneration.Design 2.1.7

I have not added any of the other AWS DotNet SDKs yet as this is a blank (standard DotNet Core template) project and I was first trying to get it to substitute Cognito for the normal DotNet db/authentication before adding anything else in.

The code that is being executed is ported in verbatim from:
So created a brand new project, ported in "all" code/references/libraries/etc.
https://github.com/aws/aws-aspnet-cognito-identity-provider/tree/master/samples/Samples

I would just like to get it to work.  I can upload the entire project for you if you like.  What I did is a newer update from your original sample project with regards to the DotNet version used.   I could simply delete the Cognito accounts and create new ones afterwords.  If we get it to work you could post this as a "new/updated" working sample for the community.

I tried loading/running your Samples.sln project.  It does compile but it errors out when you try to run it.
An unhandled exception occurred while processing the request.
UriFormatException: Invalid URI: The hostname could not be parsed.
System.Uri.CreateThis(string uri, bool dontEscape, UriKind uriKind)
TargetInvocationException: Exception has been thrown by the target of an invocation.
System.RuntimeMethodHandle.InvokeMethod(object target, object[] arguments, Signature sig, bool constructor, bool wrapExceptions)
UriFormatException: Invalid URI: The hostname could not be parsed.
System.Uri.CreateThis(string uri, bool dontEscape, UriKind uriKind)
System.Uri..ctor(string uriString)
Amazon.Runtime.ClientConfig.GetUrl(RegionEndpoint regionEndpoint, string regionEndpointServiceName, bool useHttp, bool useDualStack) in ClientConfig.cs
Amazon.Runtime.ClientConfig.DetermineServiceURL() in ClientConfig.cs
Amazon.Runtime.Internal.DefaultRetryPolicy..ctor(IClientConfig config) in DefaultRetryPolicy.cs
Amazon.Runtime.AmazonServiceClient.BuildRuntimePipeline() in AmazonServiceClient.cs
Anyway mines initializes just fine.  Only seems to have an issue with the credentials.

I did put in the appsettings.json settings similar to my own project as they are missing in the sample of course.

Hi,
This definitely looks like a credentials issue.
You don't need to add any other SDK, they are already referenced by the NuGet packages.
Sorry for not responding earlier, I have been pulled into various other issues.
Can you follow the instructions here:
https://github.com/aws/aws-aspnet-cognito-identity-provider/blob/master/docs/1-Setup.md
Especially around setting up the Visual Studio Toolkit and a default AWS Profile.
While working on a development environment, the SDKs need access to credentials. This is done by setting up a profile using the AWS CLI:
https://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/setup.html
https://docs.aws.amazon.com/sdk-for-net/v3/ndg/welcome.html
This is not required in a production environment as the credentials will be retrieve from the EC2 instance metadata.
Feel free to upload the project for me, I can have a look, just make sure to obfuscate any secrets.
It may work on my machine as I have the CLI installed with a default profile, I will let you know once the project is uploaded.

Thanks for the reply.  I do appreciate the kind offer.  I have already moved back to Azure for this particular project.  I ran through my allocated time budget for R&D on the AWS stack and it appeared that many more hours could be burned before I even got to a productive eval stage.  Had to move on.
Regards,
Les Baker
From: Hamza Assyad<EMAIL_ADDRESS>Sent: Wednesday, April 17, 2019 12:44 PM
To: aws/aws-aspnet-cognito-identity-provider<EMAIL_ADDRESS>Cc: biznearme<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [aws/aws-aspnet-cognito-identity-provider] Help Wanted - Request Signature We Calculated Does Not Match (#96)
Hi,
This definitely looks like a credentials issue.
You don't need to add any other SDK, they are already referenced by the NuGet packages.
Sorry for not responding earlier, I have been pulled into various other issues.
Can you follow the instructions here:
https://github.com/aws/aws-aspnet-cognito-identity-provider/blob/master/docs/1-Setup.md
Especially around setting up the Visual Studio Toolkit and a default AWS Profile.
While working on a development environment, the SDKs need access to credentials. This is done by setting up a profile using the AWS CLI:
https://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/setup.html
https://docs.aws.amazon.com/sdk-for-net/v3/ndg/welcome.html
This is not required in a production environment as the credentials will be retrieve from the EC2 instance metadata.
Feel free to upload the project for me, I can have a look, just make sure to obfuscate any secrets.
It may work on my machine as I have the CLI installed with a default profile, I will let you know once the project is uploaded.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/aws/aws-aspnet-cognito-identity-provider/issues/96#issuecomment-484192237 , or mute the thread https://github.com/notifications/unsubscribe-auth/ACGHY727NQRJCDTELNPKEYDPQ5OXZANCNFSM4HDXEMTQ .  https://github.com/notifications/beacon/ACGHY74IANWCVJWOUZ46R53PQ5OXZANCNFSM4HDXEMTQ.gif

This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Might be related to: https://github.com/aws/aws-aspnet-cognito-identity-provider/issues/80


Predict_image versus predict_tile documentation.

Users will need guidance about when to use one versus another
predict_image, the entire image file is passed into the network. This is good when:

The image fits into memory. For very large images, such as the 1km images passed by NEON, there were will be oom errors.
The anchor sizes match the image size. This needs explaining to the users.

Starting to outline this, https://deepforest.readthedocs.io/en/master/getting_started.html#predict-a-single-image


SQLite Helpz

Added SQLite support use in EventFlow testing of upcoming SQLite Migrations support.
New pull request to see if AppVeyor will build it.

@JC008 Let me know when the PR is ready for a review

Ready for review.

@JC008 Sorry for the delay, but thanks for the effort. I have some comments and some general stuff

"Warnings as errors" on new projects (both Release and Debug)
The "main" package is referenced but the resulting NuGet package doens't have a dependency
The Helpz.SQLite package is missing a NuGet dependency to System.Data.SQLite.Core

Good job!

@rarmus How do I add a Dependency on Helpz.dll in fake? I added the Sqlite portion - see below:
Target "CreatePackageHelpzSQLite" (fun _ ->
    let binDir = "Source/Helpz.SQLite/bin/"
    CopyFile binDir (binDir + buildMode + "/Helpz.SQLite.dll")
    NuGet (fun p ->
        {p with
            OutputPath = dirPackages
            WorkingDir = "Source/Helpz.SQLite"
            Version = nugetVersion
            ReleaseNotes = toLines releaseNotes.Notes
            Dependencies = [
                "Helpz"
                "System.Data.SQLite.Core",  GetPackageVersion "./packages/" "System.Data.SQLite.Core"
            ]
            Publish = false })
            "Source/Helpz.SQLite/Helpz.SQLite.nuspec"
    )

@JC008 Thats right regarding the NuGet dependencies, but its not in the PR, did you push it?

@JC008 I'll merge it and finish it up asap


Vagrant passes conformance tests at HEAD

@erictune - ran conformance tests at HEAD and updated the tick mark which passes after the update to the one test in service.go which requires Node.ExternalIP to function.
Fixes https://github.com/GoogleCloudPlatform/kubernetes/issues/9681

I think I am going to change this PR to update the vagrant cloud provider to not use LegacyHostPort and instead just return the Node.ExternalIP

Forget the above comment.  I want to keep this PR as is.

Actually, this change lets the test skip properly except when running conformance because conformance sets a KUBERNETES_PROVIDER="".  I will update this to use the skipUnless syntax to the set of clients that purport to support SSH (aws, gce, gke)

@erictune - so this was a new test that was added, but it brought up an interesting nugget to me in the conformance test suite, where you appear to properly not allow KUBERNETES_PROVIDER to be set, and therefore, if a test is in the suite that has a skipProviderIf syntax, it will always run, but if you use skipUnless it will be ignored.  Something to keep in mind if we add tests in conformance areas.

Updated the document with a link to the gist of my results.
I cannot pass conformance at HEAD right now without the change to service.go in this PR.
I would like to run conformance on a weekly basis going forward.
Thanks again @erictune for putting this subset together.

Shippable flaked on a mesos related matter for go 1.3, rebased PR and poked Shippable to run again.

I give up on Shippable.  Please review at your convenience since its a simple change.

LGTM.
Note that this change would need to be cherry-picked to the upstrea/conformance-test-v1 branch, not upstream/master, so that subsequent runs can benefit from it.  Do you want me to do that?  Also, did you happen to run the conformance test from the branch for your passing run?

using skipUnless is fine.  Adding to list of skips in conformance-test.sh is also fine.  That makes it clearer that we aren't in general expecting providers to have ExternalIP support for v1 conformance.

LGTM.


SqlServer FK between two schemas doesn't show on UI

System information:

Operating system: Windows 10 Version 21H1 Build 19043.1023
DBeaver version <IP_ADDRESS>105300349 Community
Additional extensions
DBeaver Git support	<IP_ADDRESS>106012023	org.jkiss.dbeaver.git.feature.feature.group	DBeaver Corp
DevStyle (includes Darkest Dark Theme)	<IP_ADDRESS>105260439	com.genuitec.eclipse.theming.core.feature.feature.group	Genuitec, LLC

Connection specification:

Database name and version: SqlServer Express Microsoft SQL Server 2017 (RTM-GDR) (KB4583456) - 14.0.2037.2 (X64)   Nov  2 2020 19:19:59   Copyright (C) 2017 Microsoft Corporation  Express Edition (64-bit) on Windows 10 Pro 10.0  (Build 19043: ) (Hypervisor)
Driver name SQL Server
Do you use tunnels or proxies (SSH, SOCKS, etc)?  No

Describe the problem you're observing:
Creating foreign keys between two tables on two different schemas via UI or SQL Script does not show it on Foreign Keys Tab/SubGroup neither on the DDL source tab.
Steps to reproduce, if exist:

Create a SQL Server database
Create two schemas
Create TableOne on schema1
Create TableTwo on schema2
Create FK from TableTwo to TableOne
If you create FK with UI from the Foreign Keys tab when click persist the FK disappear (but is still present on DB)
Execute the query select * from sys.objects to verify that the object is successfully created

Thanks for the report.

verified


How to use flux to pass parameters to helm？

How to use flux to pass parameters to helm？
Such as using the helm hook.

Hi; can you give more detail about what you're trying to do?

When I submit yaml to the repository, The flux will execute helm install to deploy the application, but I want to use helm preinstall to deploy.

As I understand it from https://github.com/helm/helm/blob/master/docs/charts_hooks.md, pre-install hooks will be run as usual by Tiller, when the helm operator does the equivalent of helm install.
Did you try it out and find that it didn't work?

Closing to take off the radar. Please feel free to re-open if it turns out my understanding was wrong all along ..


Exporting Config should have a more descriptive name.

When exporting a config from a stack, the downloaded file is called compose.zip, it should be more descriptive, e.g. stackname.zip

In my opionion this would be a small but fine little upgrade for the export function.
My Downloadfolder is full of files named "compose(x).zip".
Maybe "date-stackname.zip" would be even better.


Vectorized fix java-udaf couldn't get jar core dump

Proposed changes
If be couldn't get jar, when  call agg create function will be failed, so exec_place is nullptr cause core dump
Issue Number: close #xxx
Problem summary
Describe your changes.
Checklist(Required)

Does it affect the original behavior:

[ ] Yes
[ ] No
[ ] I don't know

Has unit tests been added:

[ ] Yes
[ ] No
[ ] No Need

Has document been added or modified:

[ ] Yes
[ ] No
[ ] No Need

Does it need to update dependencies:

[ ] Yes
[ ] No

Are there any changes that cannot be rolled back:

[ ] Yes (If Yes, please explain WHY)
[ ] No

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 35.55 seconds
load time: 430 seconds
storage size:<PHONE_NUMBER>5 Bytes
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20221118120916_clickbench_pr_48700.html

Should do the check and return error Status in create function be called !


Randomly getting Timeout of 60000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.

Hi,
I am using Directline3  and I am randomly getting  following error.
Error: Timeout of 60000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (C:\Users\--\AppData\Roaming\npm\node_modules\botium-cli\src\run\mocha.spec.js)

I experienced the same several times, but I haven't found a solution yet. From what I found out so far, this is not a Botium problem, and not a problem with the Chatbot, but with Directline itself - sometimes it just doesn't respond. I will have to investigate in detail, but it takes some time.

First, please get the latest version of Botium-CLI. When running in verbose mode, you should now see the Directline connection status, maybe this provides some hints.
Furthermore, have you tried to set the capability "DIRECTLINE3_WEBSOCKET" to false ? Sometimes, there are problems with HTTP proxies when running websocket connection.


Roll engine 29998f07faf9..fd240d0d532a (2 commits)

git@github.com:flutter/engine.git/compare/29998f07faf9...fd240d0d532a
git log 29998f07faf9..fd240d0d532a --first-parent --oneline
2019-12-06<EMAIL_ADDRESS>Roll src/third_party/skia 3e01360677b2..aa4f7f55829d (3 commits) (#14153)
2019-12-06<EMAIL_ADDRESS>Roll src/third_party/skia cc92b27c78a0..3e01360677b2 (2 commits) (#14152)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

Auto-roller completed checks. About to merge.


proposal: Go Memory Model clarifications

Russ Cox has written well on the need to include the concept of atomics in the Go Memory Model: here.  This proposal assumes an understanding of atomics and understanding the statement of the Go Memory Model (as opposed to understanding the memory model's implementation).
My proposal is to define a certain set of native data types (maybe as few as bool, byte, and int) that are intrinsically and always safe for single-writer, multi-reader applications.
Specifically, if initially variable v = v1 and several routines are concurrently reading variable v while a single routine concurrently assigns v = v2, then it is guaranteed that no reader will see any value other than either v1 or v2 and that after the assignment is done, all routines will only see the value v2.
Importantly, this proposal makes no guarantee about serializing multiple concurrent writers and as such it does not represent a complete implementation of atomic.Load* and atomic.Store*  While the implementation may ultimately require a true atomic Store, that should be an implementation detail and a possible expansion of the definition of the type.  I believe the benefit of this proposal is entirely realized just by defining the behavior of a single-writer for certain types.
This does not change the expression of the language, and in fact guarantees that some simple, straightforward code will work as expected.  For instance, it allows a variable running=true to be used by many routines containing a "for running { doStuff() }" block such that they can all be canceled by a single routine setting running=false.
Additionally, while this does not change the Go Memory Model Advice at all, this does enable some very powerful and simple (no atomic package) high-performance lock-free programming where the Advice is impractical.
By defining these types in the Memory Model document, it would also explicitly acknowledge that other types are not safe for single-writer multi-reader code.
While I suspect the cost of implementing byte, bool, and int are low and would cover a great number of use cases, someone would have to consider the cost of other primitive data types across platforms.
Specifically for each primitive type under consideration, what is the run time cost of implementation?  We should probably weigh the cost for each platform against the popularity of the platform.  For instance, (and I'm not saying this is true), but if bytes are already atomic on all platforms except s/390 we should consider the benefit of the implementation against any narrow run time cost on s/390.

It's not clear to me how this differs from the current Go memory model, which says "Reads and writes of values larger than a single machine word behave as multiple machine-word-sized operations in an unspecified order."

it allows a variable running=true to be used by many routines containing a "for running { doStuff() }" block such that they can all be canceled by a single routine setting running=false.

Ah, that would be a difference.  But it's not clearly related to a specific type.  What matters there is how a loop like for running {} is compiled.  Is that required to be a busy wait that continually reloads the value of the variable running?  Or is the compiler permitted to observe that nothing in the loop changes running, and as such can be compiled into an infinite loop?
I believe that the current memory model does not require the compiler to generate code that reloads running each time through the loop.

Ian,
As far as I can tell both a goroutine closure with "for running {}" and a goroutine function with "for *running {}" work correctly.
Playground Example
If you are saying that this is expected reliable behavior, then I think that is wonderful and I humbly submit it needs to be clarified in the memory model.  Perhaps it seems clear to you because you already know the answer.
I completely understand your perspective in pointing out the quote about multi-word writes.  The quote does explicitly say that multi-word writes are not atomic, but it does not actually say that single-word writes are safe.
If the behavior I've suggested is already expected, then I propose adding another sentence something like this:

Reads and writes of values the size of single machine word or smaller behave as a single operation.  Concurrent readers observing a value of this size while it is being written by another goroutine will always see the new value in its entirety after the write.

In defense of clarifying this, I will say that before posting this proposal I read the "Happens Before" section over and over it did not seem clear.  I posted on Go Forum, and no one was confident that unsynchronized single-writer multi-reader was safe.  Funny thing: One person said they would not feel comfortable with it, said maybe I would lose writes, and suggested I read the memory model.  Another suggested it is working for me because I'm on x86.
With all that said, I really think this is a super important guarantee, and it should be clear to Go users.

You generally need some sort of synchronization to guarantee that accesses see up-to-date contents of memory. It is true that currently we don't optimize unsynchronized loops completely away. But strange things will happen in such loops, see for example #15635. They are definitely not recommended.

Specifically, if initially variable v = v1 and several routines are concurrently reading variable v while a single routine concurrently assigns v = v2, then it is guaranteed that no reader will see any value other than either v1 or v2

I think we're ok with guaranteeing this no-out-of-thin-air property.

and that after the assignment is done, all routines will only see the value v2.

All the trickiness is hidden under the word "done". When is an assignment done? It can't be when the instruction issues, or retires, because in fact there are processors which will still give you the old value on another processor for a while. I think the best you could say is "eventually"? But that's not much of a guarantee. And as we can see in #15635, we don't actually obey that today. Writes can be delayed indefinitely.

Ok, I see that possibly implied in this:

When multiple goroutines access a shared variable v, they must use synchronization events to establish happens-before conditions that ensure reads observe the desired writes.

I read that as: "you should use synchronization because your program won't work correctly if you don't know the order things are happening." which is completely different from "without synchronization, there is no guarantee a given goroutine will ever observe changes written by another concurrent goroutine."
I do however see that down at the bottom in the examples:

there is no guarantee that the write to done will ever be observed by main, since there are no synchronization events between the two threads

No one has said this, but reading between the lines, it sounds like the "no corruption" guarantee of concurrent reads and writes does extend to multi-writer.  I don't know of any scenario where that is good programming, but bad code aside, how about this:

Concurrent reads and writes of a value the size of a single machine word or smaller behave individually as a single operation, and as such do not conflict with each other.  However, regardless of the size of the value, without synchronization, there is no guarantee that a given goroutine will ever observe a new value written concurrently by another goroutine.

Is that accurate?

Concurrent reads and writes of a value the size of a single machine word or smaller behave individually as a single operation, and as such do not conflict with each other. However, regardless of the size of the value, without synchronization, there is no guarantee that a given goroutine will ever observe a new value written concurrently by another goroutine.

Is that accurate?

The second sentence is correct. The first sentence is correct in spirit, but I think uses terms that aren't really defined well: what does "behave individually" or "do not conflict" mean?
(Are you quoting a source for that, or did you write it?)

The general issue of atomics and the memory model is #5045.  The general intent is https://github.com/golang/go/issues/5045#issuecomment-252730563.

OK, thanks, that helps a lot.  I'd like to narrow this proposal down to adding the following two guarantees to the Memory Model.  Not necessarily these exact words, but these guarantees.

a) Concurrent reads and writes of a value the size of a single machine word or smaller behave as single operations, and will not corrupt each other.

b) All goroutines observing a shared variable will observe values written to the variable by other goroutines after the write.

Based on the discussion, I think we already have the first item.  I think we should include this because it is a very important feature, and we need to guarantee it rather than leave it ambiguous.  It defines a basic and critical operation that is otherwise unknown.
The second would necessitate a change in Go (probably only in a few compiler optimizations). I don't think we need to define what "after the write" really means given existing text of the Memory Model, but in principle, it means Go will not optimize away writes to variables that can be observed in other goroutines.
I think we need this second item for two reasons:
If we don't do this, the alternative is ugly: 1) I believe we must make explicitly clear the lack of guarantee on shared writes because it is unusual and is a big problem if you don't know about it, and 2) we must then define the minimum requirement for "synchronizing events" needed to guarantee writes to shared variables... both of which are ugly.
On the other hand, if we do this, it makes things clear and expected: Programs work as they appear they should even if that means including general software quality problems associated with unsynchronized access.  Any problems are in the hands of the programmer as opposed to being introduced by the compiler.

The memory model already says

r is guaranteed to observe w if both of the following hold:

w happens before r.
Any other write to the shared variable v either happens before w or after r.

I don't understand how your suggestion "All goroutines observing a shared variable will observe values written to the variable by other goroutines after the write" differs from that.

The memory model has this in the examples:

Worse, there is no guarantee that the write to done will ever be observed by main, since there are no synchronization events between the two threads. The loop in main is not guaranteed to finish.

That would change with this guarantee.
More importantly, I'm with you 100%.  It seems super weird that this is not a fundamental guarantee already.

If there are no synchronization events between two threads, then the notion of "after" is not well defined.  You suggested earlier that we don't have to define "after the write."  If "after the write" means something other than "a write, then a happens-before relationship, then a read", then I think we very much do have to define it.  In a highly parallel world there is no such thing as "after" without some sort of synchronization.

I agree that without synchronization, the exact "when" is unknown, but this guarantee is really about the difference between "after" and "never".  It is saying "never" is not an option.
The point is that sometimes a program can have valid communication between threads just knowing: this shared variable's newly assigned value can be observed elsewhere after this assignment whenever that happens".   This is the basis of lock-free programming.
The referenced example in the memory model where main never finished is a great example of lock-free programming. It would be normal to expect that done does in fact get observed by the main eventually ("after") but the example also points out the risk of lock-free programming regarding the order of operations in the assignment of variable a.
While it is easy to debate the pit-falls of lock-free, and lock-free is definitely NOT the Go way, Go has never seemed to intrinsically preclude programming outside the Go way, and philosophically, in some ways, the sync and atomic packages are evidence that the pure way of "share by communicating" is not the only way.
I continue to believe the downside of this "possibly never" anti-guarantee as stated in a prior post, far outweigh the benefit of just making it simple and straightforward.
Ultimately, I don't think this guarantee would even need to be stated because of the other guarantees you pointed out.  We just need to remove the "maybe never" anti-guarantee.

In a concurrent language like Go, "never" is always an option.  If I start a million goroutines some of them may never run.
Also, if two different goroutines both write to a variable with no synchronization, what does it mean to say that other goroutines will eventually observe both writes?
If I understand you correctly (which I may not) I think you are trying to say two things: all stores to non-local variables must actually be performed, and all reads of non-local variables must actually be performed.  This would be roughly equivalent to saying that in C all variables are volatile.  It would mean that a loop like
var Count int
func Loop(n int) {
    for i := 0; i < n; n++ {
        Count++
    }
}

can't be optimized into Count += n.  Or, if it doesn't mean that, what does it mean?

i++

@andig Thanks, edited.

The point is that sometimes a program can have valid communication between threads just knowing: this shared variable's newly assigned value can be observed elsewhere after this assignment whenever that happens". This is the basis of lock-free programming.

I could quibble about whether that is really what lock-free programming, but more importantly I think this goal is somewhat misguided.  Go tries hard to make it easier to write correct concurrent code.  One of the way it does so it by stressing that you should always communicate through communication mechanisms, not through simply setting a variable in one place and reading it in another place without synchronization.  If I could easily make such programs break, I would.  Because I believe that programs should use explicit synchronization, and should not rely on the fact that on a shared memory system a store to memory will eventually be observable if nothing else happens.

Your message about the optimized loop is very close to what I'm saying, but I don't think the optimization is the problem, nor should the compiler be required to execute every read and write of non-local variables. I'll use your example to try to make clear the distinction in what I'm saying.
The optimization is good because the effect of the unsynchronized writes in the loop exactly the same whether it is optimized or not.  Even if that loop did actually execute every write, but did so with all the resources, no other goroutine would ever see any intermediate writes. They would see the final result.
Here is what I think is not OK: We are saying that the final result (Count+=n) may never be observed.  Saying that is not the same as optimizing away individual writes.  If you tell me it may never be observed then as a programmer I really need to understand what is going on so I can avoid it.
My position has been that we need to either a) clearly and precisely document what "synchronizing events" are required to ensure a write will not never be observed, or b) Don't say it may never be observed.
Here is my concrete and real situation (leaving aside the debate on why I do this): Multiple goroutines are looking at the same []byte data, and one goroutine changes a byte to communicate with other goroutines.  I was told that the write may never be observed by other goroutines.  After the "Whaaat??!", then reading the Memory Model over and over, I said, "Dang, it really does say that."
I think maybe the Memory Model could mean all writes (including writes to shared variables) are cached in the goroutine's local memory, then either never flushed if there is no synchronizing event, or delayed for a very very long time until the next synchronizing event occurs (whatever that is).
Of course, I'm sure you can imaging that after lots of hardcore testing, I can't get this to break. As far as I can tell, it does work as expected, but the Memory Model is explicitly telling me I can't trust it which is bad and is raising weird possibilities like the one above about caching.
That brings me back to the idea of the two guarantees which when applied to my concrete situation mean:

I need to know the write of a single byte will not be corrupted by concurrent reads or writes to neighboring bytes.  The fact that this is currently true is a really big deal that people should know about.
I need to know the write will actually happen and be observable (thus my attempts at the second guarantee).

Is that making the disconnect more clear?

My position has been that we need to either a) clearly and precisely document what "synchronizing events" are required to ensure a write will not never be observed, or b) Don't say it may never be observed or c) of course, as you said, we could just declare all communication by sharing in Go to be broken.

I agree, and the existing Go memory model picks option a): it documents the exact set of synchronizing events that are required to ensure that a read will observe a write.  (Modulo #5045, which we all agree should be addressed.)

I need to know the write of a single byte will not be corrupted by concurrent reads or writes to neighboring bytes. The fact that this is currently true is a really big deal that people should know about.

This is definitely true given the current memory model for reads/writes to a []byte, as each element of that slice is a separate variable according to the model. Given a set of writes to b[0] that are observable given the happens-before relationship, any read of b[0] must return one of them. It cannot suddenly decide to return something else if someone writes to b[1].
You previously asked about a similar, but somewhat different property:

Concurrent reads and writes of a value the size of a single machine word or smaller behave as single operations, and will not corrupt each other.

I interpreted this as if there are two writes to v, a read of v can't get half its data from one write and half its data from another. Like if there's a write of 0xaaaa and a write of 0xbbbb to a uint16, you might get 0xaabb from a read. This is also forbidden by the current memory model.

I need to know the write will actually happen and be observable (thus my attempts at the second guarantee).

I'm not sure if this guarantee is enough for you, but it is the case that the compiler can't throw away writes unless it can prove that a goroutine will never again execute a synchronizing operation. If a synchronization event is possible somewhere in the goroutine's future, all writes must be preserved in case that synchronization makes all those writes visible to another goroutine. I.e., the compiler can only throw away writes in compile-time provable infinite loops (or at known goroutine exits).

Keith, Thank you so much for being clear on this.  This is super helpful.
I'm really sorry for asking so many questions.  I'm on the outside (as a Go programmer... not Go contributor) not knowing what is really happening under the covers.
You clearly answered my question about the []byte writes.  I think you have also already answered a generalization of that, but I'd like to be sure I understood you.  I assumed incorrectly from the context of some of the conversations, that multi-writer was also safe.  Dialing that back to single-writer, may I please confirm that,  given a machine word of 16 bits or larger, if v =0xaaaa then a single writer sets v = 0xbbbb, then concurrent readers will never see anything except either 0xaaaa or 0xbbbb?
On the second item, your last paragraph makes sense.  Thank you again for taking the time to write it.
My question may come down to when the compiler can throw away writes to unsynchronized share variables "at know goroutine exists."
Specifically, the memory model says the following code may never finish.  Is that really true? And if so, what is going on?  Like... is the write to done being thrown away, or is it the racey loop, or some other specific optimization?
  package main

  var done bool

  func setup() {
  	done = true
  }

  func main() {
  	go setup()
  	for !done {
  	}
  	print("Done")
  }

Dialing that back to single-writer, may I please confirm that, given a machine word of 16 bits or larger, if v =0xaaaa then a single writer sets v = 0xbbbb, then concurrent readers will never see anything except either 0xaaaa or 0xbbbb?

Correct.

Specifically, the memory model says the following code may never finish. Is that really true? And if so, what is going on? Like... is the write to done being thrown away, or is it the racey loop, or some other specific optimization?

It is really true that the memory model says that program can run forever.
Our current implementation will always make it terminate. We do not currently have any optimizations that throw away writes at the end of goroutines (because the compiler doesn't know what function is the root of a goroutine). But one day it could.
This program will currently run forever:
package main

var done bool

func setup() {
	for {
		done = true
	}
}

func main() {
	go setup()
	for !done {
	}
	print("Done")
}

Because the compiler does remove the write from inside the infinite loop. (The compiler can prove that the memory state with done modified is unobservable.)

OK, that is very clear.   Thank you.  I understand that.
I'm totally comfortable with someone just closing this out as a bad proposal for any number of reasons, but just to be unambiguous I will leave the proposal as follows:

We commit to the safety of unsynchronized single-word sized, single-writer, multi-reader concurrency.

We remove these two sentences from the Memory Model: "Worse, there is no guarantee that the write to done will ever be observed by main since there are no synchronization events between the two threads. The loop in main is not guaranteed to finish."

I'm not suggesting any new guarantee for the second item.  I just think those two sentences create a huge anti-guarantee without explaining it.  It can be absolutely true while also being so broad that it just creates problems because is not clear.  Sort of like the difference between saying, "Writes to variables may not happen", and saying "We may optimize away writes that are unobservable."
Again, thanks to everyone for their patience.

Would it be also possible to add a guarantee that it is safe (not a data race) for multiple writers to concurrently write the same value to the same location, even if these values may be more than one machine word, provided that there are no concurrent readers?

@DemiMarie If I understand what you are saying, then, no, it would not be possible.  It would be a significant performance loss if writers were required to ensure that a reader will always see a multi-word value as entirely written by either one writer or another.  It would in effect require a lock around all reads and writes of multi-word values.

@ianlancetaylor that is not what I meant :smile:.  The specific exemptions I am thinking of are as follows:

If both writers write bitwise-identical values, two writers can concurrently write to the same location, regardless of the size of the value.
If a writer writes a value that is bitwise-identical to the value already present, concurrent reads do not introduce a data race.

My reasoning is that in both cases, all possible orderings of the writes are safe, including the writes being interleaved.  This is because if two writers are writing the same value, it does not matter who wins, and writing the same value as the one already in a location is a no-op.

That would dramatically complicate the race detector for a case that is accurately described as performing duplicated or useless work. To take advantage of such a guarantee, you would need to know enough about the program that you could just not do that.

That would dramatically complicate the race detector for a case that is accurately described as performing duplicated or useless work. To take advantage of such a guarantee, you would need to know enough about the program that you could just not do that.

I believe there are some algorithms where avoiding the duplicate work would require costly synchronization that would hamper overall system performance.  I have never implemented such an algorithm, and would be fine with the race detector producing false positives for such an algorithm.

would be fine with the race detector producing false positives for such an algorithm.

Hi @DemiMarie, FWIW, I think avoiding false positives is an explicit goal of the race detector:
https://go.dev/blog/race-detector

@thepudds good point

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Regarding https://github.com/golang/go/issues/50590#issuecomment-1014835669, we are not going to make those changes. They may seem innocent enough, but the implications are the compiler removing very important optimizations all for the sake of racy programs. The better way is to use atomics (or channels or mutexes or ...) when you want to actually share something between goroutines.
Or, as the saying goes, "Don't communicate by sharing memory, share memory by communicating."
We already restrict the compiler quite a lot compared to C/C++, and I think justifiably so, to limit the possible damage done by races. But races are races. What you are proposing is to make them not races anymore, which would require much less efficient code in a variety of settings, slowing down the extant body of entirely-race-free Go code for no benefit to that code.
It may be that at some point in the future we might want to add weak atomics - although I suspect not, the jury is still out on that. But if we did, we would do it by having special types, not by redefining the behavior of basic types and slowing down all programs that use them.

@rsc It looks like you are referring back to my comment.  I'm assuming you are referring to the first item. That is not intended to have any change to the compiler at all.  It should only be a clarification to the memory model.  The specific details are just above that post and in a few posts above that.  The scope of the clarification is here:

Dialing that back to single-writer, may I please confirm that, given a machine word of 16 bits or larger, if v =0xaaaa then a single writer sets v = 0xbbbb, then concurrent readers will never see anything except either 0xaaaa or 0xbbbb?

Correct.

@rsc I can only submit my personal experience.  For the two items listed, I could not find any documentation of the behavior, and after asking in the Go Forum I got confusing and actually wrong feedback as other people did not understand these issues either.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group


#2641 Award Configurations - PT BCAG (Net)

Updated provincialAwardNetBCAGAmount logic
Added unit tests in parttime-assessement files
Added federalAwardBCAGAmount in assessment.model.ts file

Screenshot

Please fix the PR title. We follow the pattern of #<Ticket_no> - <PR Description> for title

Great job @lewischen-aot. Appreciate the quick learning and contribution in Camunda.
Please have a look at the comments.

LGTM. Sorry for the delayed review.


feat: add captcha page

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


Fix issue of tenant logs file not geting created

Fix https://github.com/wso2/api-manager/issues/3016

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


M+ Stories logo

Hi @rdunk — can you provide us with an M+ Stories logo in both mobile and desktop lock-ups as an AI file?

Both .AI files attached here. Web ready SVGs also available in this repo:  single line, stacked.


drag and drop folder to terminal no longer works

Issue Type: Bug
In the past, you could drag a file/folder from the Explorer to the Terminal to get the path and it would work.
Now, the path is enclosed with a single quote on either end, which causes it to fail in bash. You end up having to delete the quotes, which is cumbersome since it is used so frequently.
VS Code version: Code 1.53.2 (622cb03f7e070a9670c94bae1a45d78d7181fbd4, 2021-02-11T11:45:54.515Z)
OS version: Darwin x64 18.7.0
A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstry914:30256638
pythonvsdeb440:30248342
pythonvsded773:30248341
pythonvspyt875:30259475

Duplicate of #116583


fix: Solving the problem of fine-tuning Bert and DistilBert

This pull request enables us to fine-tune Bert and DistilBert on the Clone-detection-POJ-104 task. Solving IndexError: tuple index out of range.
Key Improvements and Changes Include:

Changed the model config in run.py: To finish this task, we should use BertModel and DistilModel instead of BertForMaskedLM and DistilBertForMaskedLM. This task does not involve filling in missing tokens in text, which is the primary purpose of the Masked Language Modeling task (BertForMaskedLM and DistilBertForMaskedLM). Instead, the task involves returning Top K codes with the same semantic as the input code, which requires the model to have a good understanding of the semantic relationship between different pieces of code. BertModel and DistilBertModel are trained on a broader range of tasks, including tasks that require understanding of semantic relationships between different pieces of text, such as the Sentence Similarity task. Therefore, BertModel and DistilBertModel are better suited for this task of returning codes with similar semantics.

Resolved the issue of accessing output elements out of bounds: For DistilBert fine-tuning, the original model.py has some issues. Specifically, the code attempts to access the second output element of the model by using the following line in model.py:
outputs = self.encoder(input_ids, attention_mask=input_ids.ne(1))[1]

This works for the Bert and CodeBert models, which have a pooled_output concept in their outputs. However, since DistilBERT was not pre-trained on the Next Sentence Prediction task, its output does not include the pooled_output concept. Instead, its output only includes hidden states and attention distributions. To make the code compatible with DistilBert, we can make the following modifications: first, we obtain all of the encoder outputs. Then, if the output length is greater than 1 (for Bert or CodeBert), we use the second output (pooled_output). Otherwise, if we are using DistilBert, we take the first token ([CLS]) of the first output (sequence_output) as the representation of the entire sequence (since the Transformer's self-attention mechanism allows the [CLS] token's vector to capture information about the entire sequence, although this is not equivalent to the pooled_output of BERT, it is a common practice).
outputs=self.encoder(input_ids,attention_mask=input_ids.ne(1))
if len(outputs) > 1:
	outputs = outputs[1]
else:
	outputs = outputs[0][:, 0, :]

log: This pull request aim to solve the problem of fine-tuning Bert and DistilBert.

@microsoft-github-policy-service agree [company="Huazhong University of Science and Technology"]

@microsoft-github-policy-service agree company="Huazhong University of Science and Technology"


Update compute_stats_by_span_kind documentation

What does this PR do?

Updates documentation for compute_stats_by_span_kind based on changes from https://github.com/DataDog/datadog-agent/pull/22163. Also adds clarification in previous release note to address similar config options.
Motivation

Clarification on top-level spans update.
Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge


Import custom JSON based on file system hierarchy?

I am building a bookmark manager and would like to include your project, but when I generate custom JSON and try to convert it, it messes everything up.
I have a feeling this comes from the IDs, which appear to determine folder hierarchy.
Would there be a way to generate custom IDs to auto-generate the hierarchy? The folder stack appears completely correct, but the final output is unable to be imported without looking messed up.
I have attached a few example files for reference.
bookmarks_troubleshooting.zip

I am building a bookmark manager and would like to include your project, but when I generate custom JSON and try to convert it, it messes everything up.

how do you generate the custom JSON? from an .html? another .json?
to which format are you trying to convert it? and what do you mean by "it messes everything up" ?

I have a feeling this comes from the IDs, which appear to determine folder hierarchy.

The IDs do not determine folder hierarchy, they are just there as a way to identify the node (folder or url).
If the imported file is a .json or .db and it contains IDs then they are used as is, the only exception being chrome, where the ID of each node is incremented by 1.
If the imported file is .html then the IDs are generated as the node are being parsed since the HTML bookmarks file doesn't have any IDs.
The index attribute is what decides what the order of the nodes within a folder node will be.

Would there be a way to generate custom IDs to auto-generate the hierarchy? The folder stack appears completely correct, but the final output is unable to be imported without looking messed up.

You again mention messed up, but that unfortunately doesn't explain what exactly is going wrong.
As I mentioned, the index attribute dictates the order of element within its parent node, the hierarchy of the generated custom .json file depends on the input file.

If the input file is .html the nodes are parsed from the top of the file to the bottom, which leads to a depth first traversal. This causes the IDs of the items to increase as you go deep into the tree first and then along its breadth.
If the input file is .json the nodes are parsed just as provided in the .json file, and if the file is a chrome .json the ID is incremented by 1.

I have attached a few example files for reference.
bookmarks_troubleshooting.zip

Unfortunately I do not know what I am looking for in the files to be able to help you. I did however notice that the structure of the nodes in the custom_bookmarks.json looks like this:
"bookmark_bar": {
      "absolute_path": "Bookmarks bar",
      "absolute_path_hash": "37a7f9537fd3576a27d67628f43eb33d",
      "absolute_parent_path": "/",
      "absolute_parent_path_hash": "6666cd76f96956469e7be39d750cc7d9",
      "relative_path": "Bookmarks bar",
      "guid": "63ebc7d8-94dd-4fc8-8f64-1d62384d763c",
      "title": "Bookmarks bar",
      "type": "folder",
      "id": 980,
      "date_added":<PHONE_NUMBER>,
      "date_modified": 0,
      "children": [...],
}

I see that there are extra fields absolute_path, absolute_path_hash, absolute_parent_path, absolute_parent_path_hash, relative_path and guid, these are not fields in the bookmarks_converter library. If you are modifying the source code, I can't know what issues might arise as a side effect of these changes.

Never mind. The easiest method was for me to convert the file system hierarchy to a sqlite database and then convert that database to HTML.  The part that was so hard was setting the indices correctly, and I did not realize that it is enforced by the code that url types must take index precedence over folder types.
Everything appears to be working correctly now.  If I have time, I will fork and update with my code so that it can convert file system hierarchy automatically in case anyone is interested in that sort of thing, but I figure I'm probably the only one, so I don't guess it's something I need to prioritize at the moment.


Fix/per page option issue

This PR is fix for the issue when per page all option active is not been selected because it is null but the first option selected instead

Sorry, I don't understand the problem this solves?

Sorry, I don't understand the problem this solves?

You can check the problem by choosing the select all option of per page the refresh the page
You will see the selected option of per page is the first option instead of all option
this PR solve this problem

The issue is that the wire:model on the select doesn't mark the All option as selected, since it's value is null (which converts to an empty string).

<option value="{{ $option ?? 'null' }}">{{ $option ?? __('tables::table.pagination.fields.records_per_page.options.all') }}</option>

Ok thanks
but I think my solution do the same as you say but using the string "*" instead of "null"

Using a string like 'all' or an integer value -1 would be an easy fix, though potentially kind of breaking now. I'd prefer if we could keep null for All. Any idea how we can get that working?

Using a string like 'all' or an integer value -1 would be an easy fix, though potentially kind of breaking now. I'd prefer if we could keep null for All. Any idea how we can get that working?

No idea right now  😢
https://datatables.net/examples/advanced_init/length_menu.html
look at this it use -1 as value for all option and another library use 9999999 as all value

We could use -1. What do you think, @danharrin?

Or 0


Generated hotword doesn't work

I executed script_recording.py and recorded my hotword. Snips generated folder with three wav files and config.json. After that I modified assistant.json when replaced "personal_hotword" with my "new_hotword" and copied model files to custom_hotword folder.
But when I run it on my android device I get next results in logcat:
`
02-26 13:06:50.274 8820-8836/ I/SnipsPlatform: Connecting to remote Snips processing service
02-26 13:06:50.354 8820-8820/ I/SnipsPlatform: Snips processing service connected, starting the platform
02-26 13:06:50.470 8820-8820/ E/SnipsPlatform: Snips processing service disconnected, attempting a reconnect
02-26 13:06:50.470 8820-8820/ D/SNIPS: Error: Remote service died
02-26 13:06:51.545 8820-8820/ I/SnipsPlatform: Snips processing service connected, starting the platform
02-26 13:06:51.668 8820-8820/ E/SnipsPlatform: Snips processing service disconnected, attempting a reconnect
02-26 13:06:51.668 8820-8820/D/SNIPS: Error: Remote service died
`

Hey @bymet! Did you solve this? I am having a similar error.


Fix 494 wcs 200 tests

A fix for failing test in the WCS 2 classes. The service used now is a reference implementation and as such should not change location etc.

Failures due to #496.

@doclements merged. Thanks :)


bug(tooltip): Change Detection Error When Not in Production Mode

When not in productionMode() the following error is logged to the console:
EXCEPTION: Expression '{top: top, left: left, display: display} in TooltipContainer@1:5' has changed after it was checked. Previous value: '-1000px'. Current value: '-19px' in [{top: top, left: left, display: display} in TooltipContainer@1:5]
Currently using 1.0.7
<button class="btn btn-secondary" tooltip="Some Tooltip">Miep</button>

—
import {Component} from 'angular2/core'
import {TOOLTIP_DIRECTIVES} from 'ng2-bootstrap/ng2-bootstrap';

@Component({
    …
    directives: [TOOLTIP_DIRECTIVES]
})
export class SomeComponent {
    …
}

+1
Do you understand what's going on here? I still don't understand how ChangeDetection works, but I tried setting ChangeDetectionStrategy.OnPush on tooltip holder's component (as suggested by others in angular project page). No luck.

+1  same issue in 0.12
I think what's happening is that the lib is trying to apply the changes after it was checked and before the next render...

I just issued a pull request fixing this #331

I am still getting the same issue with the latest version (1.0.10).
Using ChangeDetectorRef.detectChanges() rather than ChangeDetectorRef.markForCheck() in a timeout solved it for me.

I have the same error when mouseovering my button..

angular2 version\ng2-bootstrap version\browser\system.js or webpack?

got exactly same bug in the modal, I'm using ng2-bs3-modal.


Project video presentation

Completed

As a result of being part of the design thinking process as well as being an active contributor to my team,I was able to put together a video presentation detailing the idea behind the name of our price comparison website to listing its features as well as the tools we employed to execute the project among many other details
https://drive.google.com/file/d/1ry2N86IMsa2NLKwraihAOI0LWl3P_zfN/view?usp=drivesdk


Debugger evaluates this wrong after using call on an arrow function

I know that an Arrow functions this can't be set via call(). Nevertheless this is evaluated wrong in this example:

Note: This could be a Node Debugger issue as well.

VSCode Version: 1.3.1
OS Version: macOS 10.11.6

Steps to Reproduce:

Execute the following code in VSCode.

function * fn () {
  this.foo = 'bar'
  yield fn2.call(this)
}

var fn2 = () => {
  const ctx = this
  const equal = ctx == this
  debugger;
  return new Promise((resolve, reject) => {
    console.log(this.foo)
  })
}

(function () {
  fn().next()
})()

@dj-hedgehog node-inspector shows the same behaviour:

Since both VS Code and node-inspector rely on the same v8 debugger protocol, this is a strong indication that the problem is not a VS Code but a node.js issue.
I suggest that you file a bug against node.js.


fixed FIXME color; added bundle to the list of ignored directories

The FIXME color was outputting like:
  * [ 58] [{:foreground=>"magenta"}FIXME] po_parser includes \000 chars that can not be turned into Symbols

Also created an IGNORED_DIRS variable and added 'bundler' to it so I don't have to see all of the TODOs in my gems.

Hey, since we got a new PR the other day, can you grant me the ability to cut a new gem please?
email is<EMAIL_ADDRESS>:)

Hey @kuzmik, have you registered on Rubygems with that email? I'm not able to add you there:
$ gem owner rake-notes --add<EMAIL_ADDRESS>Removing<EMAIL_ADDRESS>Owner could not be found.

woops! i forgot to signup with my new email.
account created on rubygems, sorry about that

Sorry for the delay! You should be set up now :D


Issue with init_file using anyhow instead of thiserror

Currently init_file does use anyhow which does not implement std::error::Error.
Thus it is impossible to directly convert from this type or use ? on it when using anything else than anyhow.
In my case this is stable_eyre for backtraces.
the trait std::error::Erroris not implemented foranyhow::Error``
I'd suggest using thiserror which as stated per docs is more suited to libs versus applications.
See also https://github.com/yaahc/eyre/issues/31
and https://github.com/dtolnay/anyhow/pull/28

@0xpr03 I agree that in general thiserror is more suitable for libs. In our case, we actually cannot enumerate all of our errors since we have a plugin interface that allows people to extend log4rs (such as using syslog). So, unfortunately, it's not possible to use thiserror.

Ah wait, I just realized my error, I mixed up another issue. I guess we'd have to somehow add the StdError trait ? I'll re-investigate this tomorrow hopefully and try to come up with a better solution. Meanwhile I'll close this prevent further noise.

What I mean was to use an std:error, fixed size approach like thiserror

thiserror supports having an error case of an unknown error type, can just box an stderror or take a reference to it if its possible in that situation (rarely).