Expand --version command

Currently the version command just returns the CLI version and one commit hash for the binary which is hardcoded in the package.json - not the actual hash that the binary returns when asked for it.
Ideally the CLI would request the version from all the binaries version endpoints and output something like this:
<EMAIL_ADDRESS>All binaries are on the same commit : 9sfhshfjdhfjsdhfs....`

Or in the case they differ (due to the usage of env vars to point to local binaries)
<EMAIL_ADDRESS>The binaries are on different commits:
 Introspection-Engine : 9fadsfsdfsdf...
 Query-Engine : 5j245h45kk2hhgfsfsdf...
 Migration-Engine : 92047254hsfs7s8fs02f...

Relevant https://github.com/prisma/prisma-engines/issues/521

The new output will look as follows:
Prisma CLI Version<EMAIL_ADDRESS>Current platform     : darwin
Query Engine         : version (at /.../.../, resolved by PRISMA_QUERY_ENGINE_BINARY)
Migration Engine     : version (at /.../.../)
Introspection Engine : version (at /.../.../)

Thanks a lot for reporting 🙏
This issue is fixed in the latest alpha version of prisma2.
You can try it out with npm i -g prisma2@alpha.
In case it’s not fixed for you - please let us know and we’ll reopen this issue!

There is a corresponding PR https://github.com/prisma/prisma/pull/4458

Fixed by https://github.com/prisma/prisma/pull/4458


Items are not being distributed into columns appropriately

I see lots of available space in one column, but extra items are still added to another column

Here is my impl:
<ResponsiveMasonry
  columnsCountBreakPoints={{ 350: 1, 750: 2, 1100: 3 }}
>
  <Masonry>
    ...
  </Masonry>
</ResponsiveMasonry>

tested it and it's works fine for me

Check the source of lib, there are simple logic for elem distribution and working not as you expect

I see this happening as well especially as the dataset grows through an infinite scroll type fetch pattern.  A couple columns end up growing much longer (FWIW our content is different sized which may contribute to the issue)

I have the same issue when the dataset grows in a infinite scroll. If you call to an API and the array of elements grows with differents heights, the items are not being distributed appropriately.

PR's are welcome if you want to help improving the distribution algorithm

Published in 2.4.0


Add mesh properties onto glTF extras when decompiling

Add mesh properties onto glTF extras when decompiling
Things like targetname and classname can now be seen from anything which uses the glTF models.
This is helpful to determine dynamic entities and things that change between game modes (i.e. the extra barriers for wingman maps)

Seems simple enough. Does this get exposed in Blender or any other tools?

Is there something that prevents putting entity properties on the model itself (ModelRoot), and not meshes? Meshes are cached, so this could have issues (and multiple meshes will have same props).


Avoid intermittent test failures in constrained-generators

Description
Use QC.discardAfter instead of QC.within in prop_univSound. This treats a timeout as a discard rather than a failure. If the test consistently times out, the discard limit will be reached and the test will then fail.
Checklist

[x] Commit sequence broadly makes sense and commits have useful messages
[ ] New tests are added if needed and existing tests are updated
[ ] All visible changes are prepended to the latest section of a CHANGELOG.md for the affected packages.
New section is never added with the code changes. (See RELEASING.md)
[ ] When applicable, versions are updated in .cabal and CHANGELOG.md files according to the
versioning process.
[ ] The version bounds in .cabal files for all affected packages are updated.
If you change the bounds in a cabal file, that package itself must have a version increase. (See RELEASING.md)
[x] Code is formatted with fourmolu (use scripts/fourmolize.sh)
[x] Cabal files are formatted (use scripts/cabal-format.sh)
[x] hie.yaml has been updated (use scripts/gen-hie.sh)
[x] Self-reviewed the diff

The main reason why within is used is to catch infinite loops. Discarding a test failure that leads to an infinite loop would effectively hide that bug.

I wondered about that, but as I said in the description, "If the test consistently times out, the discard limit will be reached and the test will then fail." However, that wouldn't catch the case where the loop is infinite only sometimes.

We've discussed this issue today in the meeting and more sensible solution is just double the time limit. Such solution has less dangers associated with it.

OK, I'll change that.

However, that wouldn't catch the case where the loop is infinite only sometimes.

That is precisely the kind of bugs that we want to catch.
If a test case always results in an infinite loop then it is extremely easy to discover such problem without any special approaches.


Accept various types of messages in assertions

Expand all assertions to accept various types of messages to emit as
output when the expression evaluates to false.  This changes permits
unit tests to use any assertion call for returning a message instead of
just IsTrue() and IsFalse().
The change from accepting only strings to any value allows for
simplification of unit tests that just print the error string.
This allows replacing:
if err != nil {
        g.Fail(err.Error())
}

With:
g.Assert(err != nil).IsTrue(err)

The logic to format the messages into output relies upon fmt.Sprintf().
It simply concatenates the messages together with one exception:
messages that are only whitespace.  In this case, it wraps the
whitespace with square brackets to make it more obvious that a message
was provided albeit unseen.
Correct spelling and remove trailing spaces.

Ouch.  It appears strings.Builder is from Go 1.10, so this code will not work with Go 1.6.3 used in the CI build.

Sounds good to bump the tests against > 1.12 versions. I like this PR as well. Do you want to bump circle versions in this PR as well?

Thank you.  I really like Goblin and tend to push it to the limit in my tests.  Oh, the horrors I do to it!  :grin:
I bumped the CI version to 1.12 (oldest supported at this time).  I presume "circle versions" meant CI version.

Thank you for contributing. I'll be merging this since test pass and it doesn't break any backwards compatibility API.
Eventually I guess we'll have to add go modules support so we do proper versioning.


Account creation using NEP-2

Create a single account using NEP-2 (password is needed)

Summary or problem description
Account creation is not using the method proposed on NEP-2.
Do you have any solution you want to propose?
Account creation should follow the standardized passphrase-protected private key format. This requirement should cover the private key generation and encryption steps detailed here.
Additional contextual information

In Neo, the account is the smart contract and the address represents a contract script. The below flow diagram shows how to derive the public key from the private key and then to the address:
https://docs.neo.org/v3/docs/en-us/basic/concept/wallets.html#accounts


Typo

Hello,
There is a small typo in two files where it reads plugnis instead of plugins, though it doesn't seem to alter the expected functioning of Bob.
The files are :
ControlPanel/CreateWikis.tid:title: $:/plugnis/OokTech/Bob/CreateWikis
ControlPanel/ManageWikis.tid:<<tabs "[[$:/plugins/OokTech/Bob/Wiki Listing]][[$:/plugnis/OokTech/Bob/CreateWikis]]

I am running (check any that apply, put an x inside the [ ] to check a box, like this: [x]):

[ ] Windows
[ ] OSX
[x] Linux
[ ] Other

and using

[ ] The nodejs version
[x] The single file executable

Before posting I read issue guidelines and:

[x] I am using the newest version
[x] The answer to my question isn't listed in the documentation or this isn't
a question
[x] This is not a duplicate issue
[x] I have not done anything that required me to set acceptance to
I Will Not Get Tech Support For This

Thank you for the correction!
I updated the names, the typo will be fixed in the next version.


Building for android fails on OSX. (Could not find firebase-app-unity.jar (com.google.firebase:firebase-app-unity:6.0.0))

Please fill in the following fields:
Unity editor version: 2018.2.21f1
Firebase Unity SDK version: 6.0.0
Firebase plugins in use (Auth, Database, etc.): Auth, Messaging, Crashlytics
Additional SDKs you are using (Facebook, AdMob, etc.): IronSource
Platform you are using the Unity editor on (Mac, Windows, or Linux): Mac
Platform you are targeting (iOS, Android, and/or desktop): Android
Please describe the issue here:
Using Play Services Resolver v 1.2.117. Build fails with the following:
`CommandInvokationFailure: Gradle build failed.
/Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/bin/java -classpath "/Applications/Unity/PlaybackEngines/AndroidPlayer/Tools/gradle/lib/gradle-launcher-4.2.1.jar" org.gradle.launcher.GradleMain "-Dorg.gradle.jvmargs=-Xmx4096m" "assembleRelease"
stderr[
FAILURE: Build failed with an exception.

What went wrong:
Could not resolve all files for configuration ':releaseCompileClasspath'.

Could not find firebase-app-unity.jar (com.google.firebase:firebase-app-unity:6.0.0).
Searched in the following locations:
file:/[...]/Assets/Firebase/m2repository/com/google/firebase/firebase-app-unity/6.0.0/firebase-app-unity-6.0.0.jar
Could not find firebase-auth-unity.jar (com.google.firebase:firebase-auth-unity:6.0.0).
Searched in the following locations:
file:/[...]/Assets/Firebase/m2repository/com/google/firebase/firebase-auth-unity/6.0.0/firebase-auth-unity-6.0.0.jar
Could not find firebase-crashlytics-unity.jar (com.google.firebase:firebase-crashlytics-unity:6.0.0).
Searched in the following locations:
file:/[...]/Assets/Firebase/m2repository/com/google/firebase/firebase-crashlytics-unity/6.0.0/firebase-crashlytics-unity-6.0.0.jar
Could not find firebase-messaging-unity.jar (com.google.firebase:firebase-messaging-unity:6.0.0).
Searched in the following locations:
file:/[...]/Assets/Firebase/m2repository/com/google/firebase/firebase-messaging-unity/6.0.0/firebase-messaging-unity-6.0.0.jar
Could not find gpgs-plugin-support.jar (com.google.games:gpgs-plugin-support:0.9.62).
Searched in the following locations:
file:/[...]/Assets/GooglePlayGames/Editor/m2repository/com/google/games/gpgs-plugin-support/0.9.62/gpgs-plugin-support-0.9.62.jar

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
Get more help at https://help.gradle.org
BUILD FAILED in 5s
]
stdout[
:preBuild UP-TO-DATE
:Firebase:preBuild UP-TO-DATE
:Firebase:preReleaseBuild UP-TO-DATE
:Firebase:checkReleaseManifest
:Firebase:processReleaseManifest
:GooglePlayGamesManifest.plugin:preBuild UP-TO-DATE
:GooglePlayGamesManifest.plugin:preReleaseBuild UP-TO-DATE
:GooglePlayGamesManifest.plugin:checkReleaseManifest
:GooglePlayGamesManifest.plugin:processReleaseManifest
:IronSource:preBuild UP-TO-DATE
:IronSource:preReleaseBuild UP-TO-DATE
:IronSource:checkReleaseManifest
:IronSource:processReleaseManifest
:unity-android-resources:preBuild UP-TO-DATE
:unity-android-resources:preReleaseBuild UP-TO-DATE
:unity-android-resources:checkReleaseManifest
:unity-android-resources:processReleaseManifest
:preReleaseBuild UP-TO-DATE
:Firebase:compileReleaseAidl
:GooglePlayGamesManifest.plugin:compileReleaseAidl
:IronSource:compileReleaseAidl
:unity-android-resources:compileReleaseAidl
:compileReleaseAidl UP-TO-DATE
:Firebase:packageReleaseRenderscript NO-SOURCE
:GooglePlayGamesManifest.plugin:packageReleaseRenderscript NO-SOURCE
:IronSource:packageReleaseRenderscript NO-SOURCE
:unity-android-resources:packageReleaseRenderscript NO-SOURCE
:compileReleaseRenderscript UP-TO-DATE
:checkReleaseManifest UP-TO-DATE
:generateReleaseBuildConfig UP-TO-DATE
:prepareLintJar UP-TO-DATE
:generateReleaseResValues UP-TO-DATE
:generateReleaseResources UP-TO-DATE
:Firebase:compileReleaseRenderscript
:Firebase:generateReleaseResValues
:Firebase:generateReleaseResources
:Firebase:packageReleaseResources
:GooglePlayGamesManifest.plugin:compileReleaseRenderscript
:GooglePlayGamesManifest.plugin:generateReleaseResValues
:GooglePlayGamesManifest.plugin:generateReleaseResources
:GooglePlayGamesManifest.plugin:packageReleaseResources
:IronSource:compileReleaseRenderscript
:IronSource:generateReleaseResValues
:IronSource:generateReleaseResources
:IronSource:packageReleaseResources
:unity-android-resources:compileReleaseRenderscript
:unity-android-resources:generateReleaseResValues
:unity-android-resources:generateReleaseResources
:unity-android-resources:packageReleaseResources
:mergeReleaseResources
:createReleaseCompatibleScreenManifests UP-TO-DATE
:processReleaseManifest
/[...]/Temp/gradleOut/src/main/AndroidManifest.xml:24:9-31:50 Warning:
activity#com.google.firebase.auth.internal.FederatedSignInActivity@android:launchMode was tagged at AndroidManifest.xml:24 to replace other declarations but no other declaration present
:splitsDiscoveryTaskRelease UP-TO-DATE
:Firebase:platformAttrExtractor
:GooglePlayGamesManifest.plugin:platformAttrExtractor
:IronSource:platformAttrExtractor
:unity-android-resources:platformAttrExtractor
:Firebase:generateReleaseBuildConfig
:Firebase:prepareLintJar UP-TO-DATE
:Firebase:javaPreCompileRelease
:Firebase:processReleaseJavaRes NO-SOURCE
:GooglePlayGamesManifest.plugin:generateReleaseBuildConfig
:GooglePlayGamesManifest.plugin:prepareLintJar UP-TO-DATE
:GooglePlayGamesManifest.plugin:javaPreCompileRelease
:GooglePlayGamesManifest.plugin:processReleaseJavaRes NO-SOURCE
:IronSource:generateReleaseBuildConfig
:IronSource:prepareLintJar UP-TO-DATE
:IronSource:javaPreCompileRelease
:IronSource:processReleaseJavaRes NO-SOURCE
:unity-android-resources:generateReleaseBuildConfig
:unity-android-resources:prepareLintJar UP-TO-DATE
:unity-android-resources:javaPreCompileRelease
:unity-android-resources:processReleaseJavaRes NO-SOURCE
:compileReleaseNdk NO-SOURCE
:mergeReleaseShaders UP-TO-DATE
:compileReleaseShaders UP-TO-DATE
:generateReleaseAssets UP-TO-DATE
:Firebase:mergeReleaseShaders
:Firebase:compileReleaseShaders
:Firebase:generateReleaseAssets
:Firebase:mergeReleaseAssets
:GooglePlayGamesManifest.plugin:mergeReleaseShaders
:GooglePlayGamesManifest.plugin:compileReleaseShaders
:GooglePlayGamesManifest.plugin:generateReleaseAssets
:GooglePlayGamesManifest.plugin:mergeReleaseAssets
:IronSource:mergeReleaseShaders
:IronSource:compileReleaseShaders
:IronSource:generateReleaseAssets
:IronSource:mergeReleaseAssets
:unity-android-resources:mergeReleaseShaders
:unity-android-resources:compileReleaseShaders
:unity-android-resources:generateReleaseAssets
:unity-android-resources:mergeReleaseAssets
:mergeReleaseAssets
:mergeReleaseJniLibFolders UP-TO-DATE
:Firebase:compileReleaseNdk NO-SOURCE
:Firebase:mergeReleaseJniLibFolders
:Firebase:transformNativeLibsWithMergeJniLibsForRelease
:Firebase:transformNativeLibsWithStripDebugSymbolForRelease
:Firebase:transformNativeLibsWithIntermediateJniLibsForRelease
:GooglePlayGamesManifest.plugin:compileReleaseNdk NO-SOURCE
:GooglePlayGamesManifest.plugin:mergeReleaseJniLibFolders
:GooglePlayGamesManifest.plugin:transformNativeLibsWithMergeJniLibsForRelease
:GooglePlayGamesManifest.plugin:transformNativeLibsWithStripDebugSymbolForRelease
:GooglePlayGamesManifest.plugin:transformNativeLibsWithIntermediateJniLibsForRelease
:IronSource:compileReleaseNdk NO-SOURCE
:IronSource:mergeReleaseJniLibFolders
:IronSource:transformNativeLibsWithMergeJniLibsForRelease
:IronSource:transformNativeLibsWithStripDebugSymbolForRelease
:IronSource:transformNativeLibsWithIntermediateJniLibsForRelease
:unity-android-resources:compileReleaseNdk NO-SOURCE
:unity-android-resources:mergeReleaseJniLibFolders
:unity-android-resources:transformNativeLibsWithMergeJniLibsForRelease
:unity-android-resources:transformNativeLibsWithStripDebugSymbolForRelease
:unity-android-resources:transformNativeLibsWithIntermediateJniLibsForRelease
:processReleaseJavaRes NO-SOURCE
:validateSigningRelease
:Firebase:mergeReleaseConsumerProguardFiles UP-TO-DATE
:Firebase:transformNativeLibsWithSyncJniLibsForRelease
:Firebase:mergeReleaseResources
:Firebase:verifyReleaseResources
:GooglePlayGamesManifest.plugin:mergeReleaseConsumerProguardFiles UP-TO-DATE
:GooglePlayGamesManifest.plugin:transformNativeLibsWithSyncJniLibsForRelease
:GooglePlayGamesManifest.plugin:mergeReleaseResources
:GooglePlayGamesManifest.plugin:verifyReleaseResources
:IronSource:mergeReleaseConsumerProguardFiles UP-TO-DATE
:IronSource:transformNativeLibsWithSyncJniLibsForRelease
:IronSource:mergeReleaseResources
:IronSource:verifyReleaseResources
:unity-android-resources:mergeReleaseConsumerProguardFiles UP-TO-DATE
:unity-android-resources:transformNativeLibsWithSyncJniLibsForRelease
:unity-android-resources:mergeReleaseResources
:unity-android-resources:verifyReleaseResources
:unity-android-resources:processReleaseResources
:unity-android-resources:generateReleaseSources
:unity-android-resources:compileReleaseJavaWithJavac
:unity-android-resources:transformClassesAndResourcesWithPrepareIntermediateJarsForRelease
:unity-android-resources:extractReleaseAnnotations
:unity-android-resources:transformResourcesWithMergeJavaResForRelease
:unity-android-resources:transformClassesAndResourcesWithSyncLibJarsForRelease
:unity-android-resources:bundleRelease
:unity-android-resources:compileReleaseSources
:unity-android-resources:assembleRelease
:Firebase:processReleaseResources
:Firebase:generateReleaseSources
:Firebase:compileReleaseJavaWithJavac
:Firebase:transformClassesAndResourcesWithPrepareIntermediateJarsForRelease
:Firebase:extractReleaseAnnotations
:Firebase:transformResourcesWithMergeJavaResForRelease
:Firebase:transformClassesAndResourcesWithSyncLibJarsForRelease
:Firebase:bundleRelease
:Firebase:compileReleaseSources
:Firebase:assembleRelease
:IronSource:processReleaseResources
:IronSource:generateReleaseSources
:IronSource:compileReleaseJavaWithJavac
:IronSource:transformClassesAndResourcesWithPrepareIntermediateJarsForRelease
:IronSource:extractReleaseAnnotations
:IronSource:transformResourcesWithMergeJavaResForRelease
:IronSource:transformClassesAndResourcesWithSyncLibJarsForRelease
:IronSource:bundleRelease
:IronSource:compileReleaseSources
:IronSource:assembleRelease
:GooglePlayGamesManifest.plugin:processReleaseResources
:processReleaseResources
:generateReleaseSources
:GooglePlayGamesManifest.plugin:generateReleaseSources
:GooglePlayGamesManifest.plugin:compileReleaseJavaWithJavac
:GooglePlayGamesManifest.plugin:transformClassesAndResourcesWithPrepareIntermediateJarsForRelease
:javaPreCompileRelease FAILED
126 actionable tasks: 106 executed, 20 up-to-date
]
exit code: 1
UnityEditor.Android.Command.WaitForProgramToRun (UnityEditor.Utils.Program p, UnityEditor.Android.Command+WaitingForProcessToExit waitingForProcessToExit, System.String errorMsg) (at <2e1ceb8be418466c8b86169240ad22b1>:0)
UnityEditor.Android.Command.Run (System.Diagnostics.ProcessStartInfo psi, UnityEditor.Android.Command+WaitingForProcessToExit waitingForProcessToExit, System.String errorMsg) (at <2e1ceb8be418466c8b86169240ad22b1>:0)
UnityEditor.Android.AndroidJavaTools.RunJava (System.String args, System.String workingdir, System.Action1[T] progress, System.String error) (at <2e1ceb8be418466c8b86169240ad22b1>:0) UnityEditor.Android.GradleWrapper.Run (UnityEditor.Android.AndroidJavaTools javaTools, System.String workingdir, System.String task, System.Action1[T] progress) (at <2e1ceb8be418466c8b86169240ad22b1>:0)
Rethrow as GradleInvokationException: Gradle build failed
UnityEditor.Android.GradleWrapper.Run (UnityEditor.Android.AndroidJavaTools javaTools, System.String workingdir, System.String task, System.Action1[T] progress) (at <2e1ceb8be418466c8b86169240ad22b1>:0) UnityEditor.Android.PostProcessor.Tasks.BuildGradleProject.Execute (UnityEditor.Android.PostProcessor.PostProcessorContext context) (at <2e1ceb8be418466c8b86169240ad22b1>:0) UnityEditor.Android.PostProcessor.PostProcessRunner.RunAllTasks (UnityEditor.Android.PostProcessor.PostProcessorContext context) (at <2e1ceb8be418466c8b86169240ad22b1>:0) UnityEditor.BuildPipeline:BuildPlayer(BuildPlayerOptions) BuildControl:BuildPlatform(String[], String, BuildTargetGroup, BuildTarget, BuildOptions) (at Assets/Scripts/Editor/[...]/Build/BuildControl.cs:307) BuildControl:BuildAndroidAdHoc() (at Assets/Scripts/Editor/[...]/Build/BuildControl.cs:97)

Hi @gabetoth-dgh,
Thanks for reporting this issue! Can you tell me if you're using a custom gradle template?
Also, a couple things to try off the bat:

can you try manually resolving your android dependencies vis the play services resolver
can you upgrade to the latest plugin (currently 6.1.1)
are you able to reproduce this issue in one of the sample apps?

--Patrick

Hi @patm1987,
Yes, I am using custom gradle template. But, as it turns out we had something messed up in our project, after reimporting everything the issue fixed itself.


How to replace entire document with nested fields

I'm trying update object
entity
{
  code: "123",
  items: [{ quantity: 1, price: 2, propToChange: Math.random() }],
  summary: { itemsCount: 1, total: 2, propToChange: Math.random() }
}

const result = await collection.updateOne({ _id }, data);

const result = await collection.updateOne({ _id }, {  $set: data });

const result = await collection.updateOne({ _id }, {  $set: { $replaceWith: data } });

const result = await collection.updateOne({ _id }, {  $replaceWith: data });

const result = await collection.updateOne({ _id }, {  $replaceRoot: { newRoot: data } });

I tested all these possibilities, but I was unsuccessful. all results return modifiedCount: 0
sometimes return matchedCount: 0 but the filter is ok
On mongo documation has a method replaceOne, is there a possibility to add this method?

I'm facing the same issue. Fortunately, I was able to find a workaround by specifying all the properties of the object and iterating with the spread operator instead of passing the single variable. Try this:
{ $set: {
        code: data.code,
        items: [ ...data.items ],
        summary: { ...data.summary }
    }
}

On mongo documation has a method replaceOne, is there a possibility to add this method?

I agree, it would be a good addition


Python SDK sample code out-dated for summarization

On this page: https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/cognitive-services/language-service/summarization/includes/quickstarts/python-sdk.md
The sample code is legacy tasks format
            "tasks": [
                {
                    "taskName": "analyze 1",
                    "kind": "ConversationalSummarizationTask",
                    "parameters": {
                        "summaryAspects": ["Issue, Resolution"]
                    }
                }
            ]

The legacy format still works for back compat, but no longer recommended.
Please update to the latest format in this document:
https://learn.microsoft.com/en-us/azure/cognitive-services/language-service/summarization/quickstart?tabs=conversation-summarization&pivots=rest-api#conversation-issue-and-resolution-summarization
  "tasks": [
    {
      "taskName": "Conversation Task 1",
      "kind": "ConversationalSummarizationTask",
      "parameters": {
        "summaryAspects": ["issue"]
      }
    },
    {
      "taskName": "Conversation Task 2",
      "kind": "ConversationalSummarizationTask",
      "parameters": {
        "summaryAspects": ["resolution"],
        "sentenceCount": 1
      }
    }
  ]

Split aspects into multiple tasks is better to control the parameters, for example only resolution summary support sentenceCount parameter since 2022-10-01-preview.
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: acf1d359-23da-2f07-af0d-d16284f738ba
Version Independent ID: eba6f1fd-cfe9-d038-b139-f02c0b48f4e0
Content: Quickstart: Use Document Summarization (preview) - Azure Cognitive Services
Content Source: articles/cognitive-services/language-service/summarization/quickstart.md
Service: cognitive-services
Sub-service: language-service
GitHub Login: @jboback
Microsoft Alias: aahi

@wangyuantao
Thanks for your feedback! We will investigate and update as appropriate.

@jboback
Could you please review this and update as appropriate.

@wangyuantao
Thanks for your feedback! I've assigned this issue to the author who will investigate and update as appropriate.

Can you please sync doc with this python SDK fix? https://github.com/Azure/azure-sdk-for-python/pull/27122

#please-close


[Docs] Improvements in Documentation

Hi @lovettchris,
I've revised all the documentation with the following improvements:

Improved readability
Fixed grammar issues
Added necessary words
Removed unnecessary words

How to Test this PR

Read the revised docs thoroughly.
Check for any errors.
Request changes if you find any issues.

Thanks for all this, but I can't see the real edits for the word wrapping.  I pushed a change that sets word wrapping column at 120 which is my preference (it makes side by side code reviews easier) and so please reformat your changes with that same setting, thanks.  Then I should be able to see the difference more easily.

I will take a look in 7 days

I manually merged most of your edits, thanks.


Cap protobuf version in text/automm

Issue #, if available:
Description of changes:
Cap protobuf version to help solve https://github.com/awslabs/autogluon/issues/1762
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-1802-1 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-1802/1/index.html


Image container strange behaviour

Hello,
(1)
I'm experiencing an issue where uploaded image doesn't fit the image container and is roughly a third of its width. This is random as I could upload the same photo again and it would be fine. The only CSS I've overwritten for the cropper was #upload-image-container. I have set a max-height and min-width but that shouldn't matter as I've tested without it and I was getting the same result. Please see attached screenshots.
(2)
I'd like my cropper-crop-box to be bigger (while retaining its aspect ratio) and I'm not sure how to do it. Could you please advise?
Screenshots
(1)

(2)

Additional context
cropper options
$scope.$cropper = new Cropper($scope.cropperElement, {
    aspectRatio: $scope.aspectRatio,
    dragMode: 'move',
    cropBoxMovable: false,
    cropBoxResizable: false,
    zoomOnTouch: false,
    zoomOnWheel: false,
    toggleDragModeOnDblclick: false,
    strict: true,
    disabled: true
});

Duplicate of a ton of issues.

img {
  width: 100%;
}

Don't initialize the cropper before you see the image place in the right position.


Removes reference to ACM

Fixes #107. Renames "ACM Member" -> "Student" and "Non-ACM Member" -> "Non-Student" to remove reference to ACM.
Please take a look and deploy after merging.

Looks good @tnaumann !


ability to change SuiteBarBrandingElementHtml

Details of the scenario you try and problem that is occurring:
My customer wants to be able to change the "SharePoint" branding text at the web application level. This is a set by the SuiteBarBrandingElementHtml property of the web application.
I want to add this to SharePointDSC, but just want to get a consensus if this should be an additional, optional property of SPWebAppGeneralSettings, or if a new resource should be started for it?
The DSC configuration that is using the resource:
none yet
Version of the Operating System and PowerShell the DSC Target Node is running:
Windows Server 2012R2 / Windows Server 2016
Version of the DSC module you're using:
1.9

OK so this is just a property off the SPWebApplication object, so it's easy enough for us to implement in either the SPWebApplication resource or the SPWebAppGeneralSettings resources (I don't think I'm massively fussed on which, I think I would rather the SPWebApplication one though since the "general settings" one was designed to mimic the settings layout of the central admin UI and this property isn't surfaced through a UI anywhere).
A part of me also looks at this as with my "I don't wanna do UI customisation in DSC" glasses and wants to back away from it though - but then it's literally just a property on the web app, which makes me totally fine with it it too, so I've got some mixed emotions on it. But I think if we make it a property to go on the SPWebApplication resource that it should be fine.
@ykuijs You got any thoughts on this one dude?

I did some checking of this property (never used it before :-)) and it looks like it is SP2013 only. In SP2016 there are some more properties/possibilities:
https://sharepoint.stackexchange.com/questions/177733/sp2016-change-suite-bar
In SP2013 you have to specify HTML code and in SP2016 there are multiple text only properties. So if we are going to implement this, we need to take this into account which makes it more complex. Both to implement and in use (multiple properties, one 2013 only and multiple 2016 only properties).
So I am a bit in doubt. If we can come up with a nice way to implement which is user friendly, I am all for it.

Good catch @ykuijs that does make things more interesting.
We could put in a resource that has all the individual properties from both versions, and then throw errors if you use one that doesn't suit the version you have installed? It's not super graceful but it would do the trick.
We could also just use the text properties from SP2016 and assume the HTML needed to replicate that in 2013 so that we build the HTML based on the properties and update it accordingly on the fly if that makes sense? That's a little more use friendly but more leg work on our end to make it work - but doable I think.

My vote goes out to having the resource accept all possible properties, and have internal logic throw an error if the property does not belong to that SP version. Otherwise we would be making an assumption on behalf of the user, which is not the way to go.

so it sounds like a dedicated resource that works on both 2013/2016 is the way to go? Or roll the properties in with SPWebApplicaiton ?

If we are gonna have to put version specific logic in it, my vote goes to an independent resource. And I agree with Nick there on how to implement it as well.

@ykuijs assign that one to me.

@MikeLacher448 Fixed in PR #662

Merged in PR662


End-of-line (EOL) character being displayed despite file does not end with newline

Bug Description
The end-of-line character (lcs-eol, $ by default) is displayed at the end of file (EOF), no matter if the file actually ends with a newline.
To Reproduce

Create a file without a newline at EOF echo -n foo > bar
Run vim --clean bar
Enable list mode :set list

Neither disabling the fixeol setting (:set nofixeol), nor starting Vim in binary mode (vim --clean -b bar) affects this behavior.
Expected behavior (edited)
There should be no EOL character (i.e. $)  being displayed.

There should be a lcs-eof item (eof:c) added to listchars
that is not set by default and
that will replace the eol:c character on a file's incomplete last line,
if and only if

a character for eof:c was configured (e.g. set to ~) and
the eol option is false and

( the fixeol option is false, or
the binary option is true )

Screenshots

Environment:

Vim version:

$ vim --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled May 12 2020 02:37:13)
Included patches: 1-716
Modified by<EMAIL_ADDRESS>Compiled by<EMAIL_ADDRESS>Huge version with GTK3 GUI.

Additional context
The presence of a trailing newline character can be of importance especially in binary mode.

On 2020-05-22, dirdi wrote:

Bug Description
The end-of-line character (lcs-eol, $ by default) is displayed at the end of
file (EOF), no matter if the file actually ends with a newline.
To Reproduce

Create a file without a newline at EOF echo -n foo > bar
Run vim --clean bar
Enable list mode :set list

Neither disabling the fixeol setting (:set nofixeol), nor starting Vim in
binary mode (vim --clean -b bar) affects this behavior.
Expected behavior
There should be no EOL character (i.e. $) being displayed.

While I appreciate your point of view, ":help lcs-eol" says:
eol:c         Character to show at the end of each line.  When
              omitted, there is no extra character at the end of
              the line.

It says that the eol character appears at the end of the line;
it does not say that the eol character represents the EOL sequence.
In the case of the last line of a file that does not end with an EOL
sequence, the eol character shows where the text of that line,
including white space, ends.  By not having the eol character at the
end of the last line, the user would lose that information.
So I think it's a feature and the intended behavior, not a bug.
As for being able to visualize that distinction, as you would like,
I'm afraid I can't think a solution at the moment that uses the
existing capabilities of Vim.
Regards,
Gary

In addition to what Gary said, I'd mention that binary files (files read
with e.g. :e ++bin filename.ext) and files where ":setlocal nofixeol" has
been set (which is not the default) will be written with an incomplete last
line if 'noeol' was set either at read-time (because no EOL was found on
the last line) or later (e.g. manually). No matter whether or not 'tist' is
set or whether or not 'listchars' includes a visible EOL (the default is
eol:$, I use eol:¶) or a blank EOL (set e.g. by eol:\  with a
backslash-escaped space, or by omitting the eol: suboption altogether):
'list' and 'listchars' are only for display purposes, and, as Gary said,
they are one possible way to notice that there is whitespace at the end of
a line.
Best regards,
Tony.

P.S. One possible way to have Vim display if a given editfiles ends with an EOL or not is by means of a custom 'statusline' (q.v.) — e.g. by having somewhere in the value of the 'statusline' option something like
%{&eol?"":"[noeol]"}

FWIW, my own 'statusline' is
%<%f %h%m%r%=%k[%{(&fenc==''?&enc:&fenc)}%{(&bomb?',BOM':'')}][U+%04B] %-14.(%l,%c%V%) %P

You may want to use only part of it, and remember that in a :set command, any space (or vertical bar or backslash) in the option value must be backslash-escaped.
Best regards,
Tony.

Thank you both for your fast response!

Gary wrote:
It says that the eol character appears at the end of the line;
it does not say that the eol character represents the EOL sequence.

My point is that the line does not end, but the file. Therefore, the behavior does - to my understanding - not comply to :help lcs-eol.

Gary wrote:
In the case of the last line of a file that does not end with an EOL sequence, the eol character shows where the text of that line, including white space, ends. By not having the eol character at the end of the last line, the user would lose that information. So I think it's a feature and the intended behavior, not a bug.

Is not the lcs-trail setting responsible for indicating trailing spaces?
						*lcs-trail*
trail:c	Character to show for trailing spaces.  When omitted,
	trailing spaces are blank.  Overrides the "space"
	setting for trailing spaces.

E.g. setting it to a dot :set listchars:eol:$,trail:. gives:

My (maybe wrong?) intention is that the window content should represent what will be written to disk, when one executes the write command. Hence, the lcs-eol character should be displayed, iff it would be written to disk (i.e. if it is present or if the fixeol setting is set).
Best, dirdi

On 2020-05-22, dirdi wrote:

Thank you both for your fast response!
Gary wrote:
It says that the eol character appears at the end of the line;
it does not say that the eol character represents the EOL sequence.

My point is that the line does not end, but the file. Therefore, the behavior
does - to my understanding - not comply to :help lcs-eol.

That's an interesting perspective.  I would have said that the line
ends at the end of the file, as the programs I've seen that don't
end the last line of the file with an EOL nevertheless intend that
the line end there.  That's not how "cat file1 file2" would handle
it, though, for example, if file1 didn't end with an EOL.

Gary wrote:
In the case of the last line of a file that does not end with an EOL
sequence, the eol character shows where the text of that line, including
white space, ends. By not having the eol character at the end of the last
line, the user would lose that information. So I think it's a feature and
the intended behavior, not a bug.

Is not the lcs-trail setting responsible for indicating trailing spaces?

That would work, too.

                                            *lcs-trail*

trail:c Character to show for trailing spaces.  When omitted,
trailing spaces are blank.  Overrides the "space"
setting for trailing spaces.
E.g. setting it to a dot :set listchars:eol:$,trail:. gives:
2020-05-23-021102_90x52_scrot
My (maybe wrong?) intention is that the window content should represent what
will be written to disk, when one executes the write command. Hence, the
lcs-eol character should be displayed, iff it would be written to disk (i.e. if
it is present or if the fixeol setting is set).

I don't think you're wrong:  you have a good point.  I think there's
more than one way to present this information.  Vim (vi?) chose one
way and you would have chosen another.
I suppose it could be an option [ducks].  There are some issues with
the way that some other listchars are handled (notably lcs-extends),
but no solution yet, so there might be an opportunity to make
lcs-eol work either as you would like or as it does now.
Regards,
Gary

I want to add two more thoughts:

Gary wrote:
I think there's more than one way to present this information.

Currently there is no representation of this information at all. Always and independent of a buffer's state displaying the lcs-eol character, does not provide any information to the user. But of course you are right: Not representing it, is in some way a representation.
If one wants to have a character at each EOL, the ~ character - which is already used to represent the EOF - would be a more consistent choice. However, I would prefer to just not display the lcs-eof character.

Tony wrote:
One possible way to have Vim display if a given editfiles ends with an EOL or not is by means of a custom 'statusline'

In my eyes, the right place to indicate how a file ends, would not be the statusline, but the end of the file. Further, Tony's proposed statusline enhancement would not reflect what will be written, but what was read.
On the other hand, changing the current behavior to the behavior I suggested (and to the documented behavior, as I read it), would most probable not break anything, since - to the best of my knowledge - it is currently not possible to query the presence of the lcs-eol character at the EOF and hence no vimscript/plugin/etc. is able to rely on it.
Best, dirdi

One thing to keep in mind is that Vim is a product of the Unix world, where every line of a file, including the last one, should have an end-of-line marker. This is why the normal behaviour of Vim is to add an end-of-line at the end of a non-binary file if it is missing, and why it will sometimes display a ^M at the end of every line except the last one if every line except the last one end in a CR+LF pair.
Similarly, the cat (concatenate) program will concatenate the files just as they are, and if one of the files (other than the last one) lacks an EOL on its last line, that line and the first line of the following file will become a single line in the output.
Some programs, and in particular some programs stemming from the DOS/Windows world, regard (erroneously IMHO but I'm not going to enter a flame war about it) the end-of-line sequence not as a line terminator but as a line separator, and if they get a file whose last line is properly terminated they will add an empty line just after that. This is in any case IMHO a lesser evil than failing to separate the last line of one file and the first line of the next file in case of concatenation because the last line of the first file wasn't properly ended.
In any case, it is possible to query Vim for the presence of a proper end-of-line terminator at the end of the present file:

If the 'endofline' (or 'eol') local option is unset, no EOL character was found on the last line when reading the file. This can be tested with if !&eol ….
Normally however (i.e. if 'binary' is off and 'fixeol' on  for that file, both of which are the default) Vim will disregard the 'eol' setting when writing and add a proper EOL anyway. The opposite condition can be tested with if &bin || !&fixeol ….
A binary file should be read-in with the ++bin modifier (see :help ++opt) to set 'binary' locally for this file, thus telling Vim that it is a binary file and that it must not add an EOL at the very end if there isn't one there yet.
If for any reason a text file should not get an additional EOL at the end, the old way of doing it (in versions of Vim compiled before the 'fixeol' option was defined) was to declare that file as binary but that was regarded as "abusing the system". Nowadays it is possible to use :setlocal nofixeol on that file to tell Vim that a possible missing EOL should not be "fixed".
All of the above behaviours are deterministic and it is quite possible for a plugin to test for them. OTOH, it is not possible for a plugin to test for the presence or absence, at any point, of a specific 'listchars' character: the $ (or other character) representing the end of a line cannot be checked for by if something == "$"; but the fact that Vim won't write an EOL at the end of the file can be tested by if !&eol && (&bin || !&fixeol) …; or the fact that Vim will only write an EOL at the end of the file if it was already there is the condition inside the parenthesis in this last if statement.

Best regards,
Tony.

The main purpose of showing $ after the line is to be able to spot any trailing white space.  That's an old vi mechanism, it's not going to change.
Since many users find the $ look bad, Vim has added other ways to show trailing spaces.
Having a file not end in a line break is uncommon, Vim considers this a special case and has the 'endofline' option for that.  That doesn't show in the text though.  Perhaps we can add an item in 'listchars' to show a different character instead of "eol:" when 'endofline' is set.

The main purpose of showing $ after the line is to be able to spot any trailing white space. That's an old vi mechanism, it's not going to change.
Since many users find the $ look bad, Vim has added other ways to show trailing spaces.
Having a file not end in a line break is uncommon, Vim considers this a special case and has the 'endofline' option for that. That doesn't show in the text though. Perhaps we can add an item in 'listchars' to show a different character instead of "eol:" when 'endofline' is set.

…or perhaps rather when it is unset, since with 'eol' set the last line ends just the same way as any other line of that file.

Bram wrote:
The main purpose of showing $ after the line is to be able to spot any trailing white space. That's an old vi mechanism, it's not going to change.
Since many users find the $ look bad, Vim has added other ways to show trailing spaces.
Having a file not end in a line break is uncommon, Vim considers this a special case and has the 'endofline' option for that. That doesn't show in the text though. Perhaps we can add an item in 'listchars' to show a different character instead of "eol:" when 'endofline' is set.

I understand that - and please correct me if I am wrong - it is not possible to change the default behavior, because this would "break userspace", so to speak. But it would be possible to add an option to customize the default behavior.
How about this:

Adding a lcs-eof item (eof:c) to listchars
that is not set by default and
that will replace the eol:c character on a file's incomplete last line,
if and only if

a character for eof:c was set (e.g. ~) and
the eol option is false and

the fixeol option is false, or
the binary option is true

This would not conflict with current behavior nor break anything, but enable one to visualize a missing EOL sequence at EOF by configuring the to be implemented lcs-eof item. Would that be acceptable? If so, I would propose to add the "feature-request" label to this thread.

so basically there is no way in Vim to display the actual newline characters that exist in the file
seems like an awful limitation

this is basically the same as the previous comment https://github.com/vim/vim/issues/6119#issuecomment-633044279
Perhaps propose a PR then?

not exactly the same... that comment is proposing to add an extra character to visualize a missing EOF EOL sequence
i'm proposing no visualization at all for a missing EOF EOL sequence. only visually display what actually exists in the data

@mmikeww regarding linefeeds, one is already able to "visually display what actually exists in the data" via eol:c, except for the very last line. If an eof:c item was implemented, like it was suggested by me earlier (https://github.com/vim/vim/issues/6119#issuecomment-633044279), this would also enable one to resemble the behavior you are asking for, by just setting eof:c to a blank or any other non-printing character.

@mmikeww regarding linefeeds, one is already able to "visually display
what actually exists in the data" via eol:c, except for the very
last line. If an eof:c item was implemented, like it was suggested
by me earlier
(https://github.com/vim/vim/issues/6119#issuecomment-633044279), this
would also enable one to resemble the behavior you are asking for, by
just setting eof:c to a blank or any other non-printing character.

That is in the 'listchars' option, which is only used when 'list' is
set.  The "eol:$" entry is mainly there for backwards compatibility.
In the old days with some terminals you couldn't tell whether the whole
text was displayed, thus an extra "$" was put after the line to tell the
user it's a complete line.  These days I don't expect users to need that
hint.
For 'endoffile' it's the other way around: It normally isn't set and
there is no need to tell the user that there is no CTRL-Z at the end.
If there is a CTRL-Z then very often it will just show up.  When using
Unix 'fileformat' then 'endoffile' won't even be set, the CTRL-Z is just
another text character.
Only when 'fileformat' is "dos" and 'endoffile' is set, then there is no
indication of this situation.  And the 'noendofline' state is actually
not visible either, the "$" is displayed after the last line anyway.
Again, this is backwards compatible with old days.
Since this is a special situation and it's only one place, I don't think
having the user set 'list' to see it makes sense.  Thus adding an
"eof:c" item to 'listchars' isn't very useful.
How about this: We show the unexpected state at the end of the last line
by default, and add items to the 'fillchars' option to do something else
than the default.  I would anticipate that most users would be satisfied
with the default, and those few who don't can choose something else.
For the missing EOL, with 'noendofline', perhaps an upside down
exclamation mark could indicate that?  Might be hard to spot though.
For the additional CTRL-Z, when 'endoffile' is set, we could just show
the text "CTRL-Z".
Both highlighted with NonText.
'fillchars' items:
noeol:¡
eof:CTRL-Z
Comments?
--
Seen it all, done it all, can't remember most of it.
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

I have no comment on the EOF character CTRL+Z (from a quick google, ascii 26?). I didn't even know that existed, and don't care how that is handled. Most text files dont have a trailing CTRL+Z from what I've seen.
As far as adding 'noeol' to 'fillchars', here is the problem: Vim does not keep track of the eol status as the file is edited. It only checks it once upon file open. Simply open up a noeol file, use :set eol? and you'll see 'noendofline', edit the file, save it, Vim auto adds the eol, then use :set eol? again and Vim will incorrectly report noeol still, even though it was changed and added. I believe Vim needs to keep track of the original eol state of the file, so that it can determine what to do for the existing 'fixeol/nofixeol' setting, and so that shouldn't be changed either I guess
If the 'eol' listchar cannot be changed for backwards compatibility with Vi, thats fine. My point is that then there is no visual way inside Vim to consistently display \n (LF) chars. And the only way to display \r (CR) is to set ff=unix and then you will see ^M displayed.
It just seems like the easiest and most non intrusive solution is to simply add CR and LF options to listchars and then people can visually see this data, independent of the chosen fileformat


Bugfix: fix with_cache implementation

This PR fixes #940 and #941.
with_cache is one of two places (there's also something going on in the convert module w.r.t cache handling) the current cache handling is slightly broken. This PR simplifies the scope of the function by requiring the user to have created the cache prior to calling with_cache. Currently, the lifetime of the cache proxy that is created in the removed cases is not associated with the lifetime of the cache.
It would be possible to retain the existing API by storing a reference to the proxy on the cache object, but this will break the assumption that the cache is populated exclusively for virtual materialisation.

Wait—the cache="new" and cache={} options are a necessary part of the `with_cache API. If there's something wrong with then, they need to be fixed, but they can't be removed.
The weak reference is a concession to the C++ layer that will be replaced with a regular reference when it's translated into Python. It prevents cyclic references through the C++ that Python's garbage collector is unable to identify. So for now, we have to live with the weak reference.
The way this is supposed to work is that any reference to the cache must be retained within the scope of the with_cache function, since the VirtualArray/ArrayCache isn't holding it. Before the function returns, it creates an ak.Array that does hold the reference, strongly.
If you were using the function with highlevel=False, that mechanism would have broken. Is that what happened? It could be that we have to disable highlevel=False in this function—it's just not going to work, considering how the reference is held only by the ak.Array object. The highlevel=False will have to wait until the C++ layer is translated into Python.
With highlevel=False, cache="new" and cache={} will fall, but so would cache=anything_constructed_on_the_spit(), since its reference only exists in the argument list and will be fine after the with_cache function returns.
With highlevel=False, you can still use this for making low-level layouts. You have to pull the layout out of the unwanted ak.Array, but that ak.Array has to live long enough for the final ak.Array to pick up strong references to the caches.

The way this is supposed to work is that any reference to the cache must be retained within the scope of the with_cache function, since the VirtualArray/ArrayCache isn't holding it. Before the function returns, it creates an ak.Array that does hold the reference, strongly.

Right

If you were using the function with highlevel=False, that mechanism would have broken. Is that what happened? It could be that we have to disable highlevel=False in this function—it's just not going to work, considering how the reference is held only by the ak.Array object. The highlevel=False will have to wait until the C++ layer is translated into Python.
Yes, this is likely the culprit.

OK, then I'll repush this branch with the fix for #940. I'll also update the documentation to reflect the support for "new".

@jpivarski OK, corrected my oversight. I've removed the highlevel argument, and I thinkthink fixed the cache handling so that it matches the docstring. Could you give that a quick once over?

Just removing the highlevel parameter should do it, but eventually somebody's going to ask, "Why doesn't this function have a highlevel argument? Here, I'll add one."
To ensure that it doesn't just look like an oversight, let's leave the argument in (in other words, revert almost everything in this PR) and just add an error message if highlevel is not True. That makes the highlevel argument useless, but it does communicate the fact that it was removed on purpose, and the error message would say, "ak.with_cache cannot allow highlevel=False because the only strong reference to caches are held by ak.Array objects; VirtualArrays only hold weak references, which would go out of scope with this function. This will be fixed in Awkward 2.0, when VirtualArrays are reimplemented in Python and can safely hold strong references to caches. For now, use highlevel=True and extract the layout from the high-level array" (with good formatting so that that long explanation isn't on one long line).
This PR then just becomes a prevention of highlevel=False with an explanation of why it is temporarily disabled.

@jpivarski is be tempted to just put this information in a comment, but as it is planned to support this in future, we might as well keep the API stable. I'll make the changes at some point :)

I just took care of it. Thanks for opening this!

@jpivarski from the do string, isn't the cache=None case supposed to unset the caches entirely?

I think you might be right about that. I might have just committed a mistake. I didn't look carefully enough at the logic of it, I assumed that the old logic was right.
Is it now in disagreement with the documentation?

Again, could be wrong - long week. The existing implementation has a case
for which the existing cache is left in place. As fair as I can tell, the
cache should either be replaced or removed, with no pass through condition.
On Sat, 19 Jun 2021, 16:08 Jim Pivarski, @.***> wrote:

I think you might be right about that. I might have just committed a
mistake. I didn't look carefully enough at the logic of it, I assumed that
the old logic was right.
Is it now in disagreement with the documentation?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/scikit-hep/awkward-1.0/pull/942#issuecomment-864418435,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJQZHLWZPP7G6MPLXK73A3TTSXF3ANCNFSM465STQYA
.


IE 11 cube effect

Using the vertical cube effect here: http://twofold.fuelthemes.net/
It's not working for me unless I drag the slide.

This was cause by "0" speed value.


update to release 2.4

Signed-off-by: liuwei<EMAIL_ADDRESS>

/lgtm

refer to https://github.com/open-cluster-management/backlog/issues/14513


fix: responsive video component

Sorry for the large PR. It also contains the migration of youtube embeds.
There are 2 files that are related to the new component:

website/src/components/YoutubeEmbed.js
website/src/theme/MDXComponents.js

The rest of the changes comprise of migrating all current youtube embeds. I used regex to find and replace them. I also checked through all the changes manually to verify nothing went wrong and no content was lost.
Changes

New responsive <YoutubeEmbed /> component with lazy loading. (Lazy loading improves initial time-to-interactive from >1.1s to 600-700ms).
Component added to Global MDX Scope so that it doesn't have to be imported in each markdown file.
Migration of existing embeds to new component

 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.

This looks wonderful from my end. The videos fit very well in all configurations and pages I sampled, and the border radius was a nice touch as well :) Here are new versions of the same kinds of screenshots I took the other day:

1080x1920 (vertical)

Mobile (Google Pixel 5)

Thank you @tejasahluwalia !

@jnikhila @spark-c Made a generic wrapper component VideoEmbed that can be extended in the future to support more hosts. No further functional/styling changes.


Inconsistent listing of closed practices

The lists of practices are not consistent in terms of stating which practices are closed/dormant. This example lists where they are closed: https://openprescribing.net/ccg/03N/measures/
...but this one doesn't: https://openprescribing.net/ccg/03N/
Additionally, it might be make things clearer in the below example to split the numbers into open and closed practices?

This has been fixed


HistologicGrade components "buried" in IG

The components of histologic grade are very easy to miss when looking at the FHIR IG. Is there a way to increase their visibility?

Probably not, since the IG pages are produced by the FHIR IG tool, which we have no control over.


Error importing index.js: TypeError: "i is null"

When opening the website on Firefox, nothing works and I'm getting the following error:
Error importing `index.js`: TypeError: "i is null"
	u https://sandspiel.club/1.bundle.js:1:19118
	he https://sandspiel.club/1.bundle.js:1:18834
	<anonymous> https://sandspiel.club/1.bundle.js:1:18600
	u https://sandspiel.club/bundle.js:1:493

breadcrumbs.ts:155:12
Sentry</Ie</t.prototype.instrumentConsole/</</<
breadcrumbs.ts:155:12
<anonym>
bootstrap.js:9:2

I'm using Firefox Version 64.0 (64-Bit), with uBlock Origin and HTTPS Everywhere Plugins, uBlock Origin however doesn't block any requests. My Firefox settings are adjusted a bit to increase my privacy.

would you be willing to try this using firefox with no plugins? I'd like to fix this but can't reproduce it as-is


Color to float conversion for directional albedo in generalized_schlick_bsdf

We use the color component average to convert directional albedo to a monochromatic value in generalized_schlick_bsdf.
Conversion is done to avoid getting complementary colors on the base layer. But the use of average may in some cases result in issues with energy conservation for separate color components, as noted in this PR: https://github.com/KhronosGroup/MaterialX/pull/1
A possible strategy to avoid this is to use the max value of the color components instead of the average.
We should here discuss the pros and cons of these strategies (or others?).

For now, I believe the averaging of directional albedo in layering computations is our best available option for generalized_schlick_bsdf, so I'll close out this original issue.
Feel free to reopen this, though, if a new proposal appears to have a significant advantage over our current one.
As a reference for future readers, here is the GLSL code where the averaging of directional albedo is currently used in layering for generalized_schlick_bsdf:
https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/pbrlib/genglsl/mx_generalized_schlick_bsdf.glsl#L42


Add repository url to package page

Initial work towards https://github.com/NuGet/NuGetGallery/issues/4941.
I wanted to get your take on the initial work to show repository url from the <repository> metadata in a package. I imagine there is follow up work. Open questions;

Is the RepositoryUrl column in nuget.org's Packages table currently empty? It doesn't look like this was beening populated on upload.
What should we do with the commit, branch, and type attributes? We could introduce some some inference. For example, if repository.url == https://github.com/natemcmaster/CommandLineUtils and repository.commit == 311673414d6530d97c70871a60c1a26f924f0d17, should the packages page could show this link: https://github.com/natemcmaster/CommandLineUtils/tree/311673414d6530d97c70871a60c1a26f924f0d17

@diverdan92 @anangaur

To make it easier to review:
Upload page
Verifying metadata:

Package page

/cc @spboyer

I verified, all packages on nuget.org have a null RepositoryUrl.

Can this be fixed retroactively? There's tons of Nuspecs that already have that field defined.

@skofman1 what's the path to getting this approved to merge?

Pinging this to keep this alive. Any timeframe to get this merged?

@natemcmaster , if you could do the following, it would make it look better:

If the URL is a github URL, use the GitHub icon instead.
Else, if the type is git, use the git icon
Else fall back to the default icon (that’s being used now).

It looks like there isn't an icon for these in the current icon set. The gallery is currently only imports Office UI Fabric 7.0, and there is nothing in that set that looks like a good fit for 'git' or GitHub repo types.
If we upgraded to Office UI Fabric 9, you could use one of these icons, but still no GitHub in this set.

Also, it looks like you have font-awesome 3.2 in your source code. That has the github icon in it, but it doesn't look like the gallery pages import font-awesome, only the admin pages.
So, how would you prefer I go about getting the right icons?

Looking at the release notes of Office UI Fabric, it seems like there is a lot of churn on icons. It seems reasonable to update to 9 but I am concerned about unexpected breaking changes. If we can assess that the update is safe, let's do it. Searching for all pages that use the Office UI Fabric CSS rules and manually testing them seems like the best approach.
For the GitHub icon, I think we should used their prescribed branding: https://github.com/logos. The "mark" zip has vector graphics. We should convert it to SVG and use that icon. Note that this is what we have for our Facebook and Twitter share icons.
The non-GitHub icons should be pulled from Fabric 9.

I think I'd rather skip the Fabric 9 update for now, but I've added the github icon.

Looks good Nate! You can add a git logo in the same way: https://git-scm.com/downloads/logos
Also, please add UTs.

Also, please add UTs.

Noobie question: what's that? My googling didn't help.

My guess - unit tests?

Added the git icon and a few unit tests. Not sure what kind of other coverage you would expect from automated testing.
Here's what the packages page looks like now.
Example: <repository url="https://github.com/aspnet/Mvc" />

Example: <repository url="https://bitbucket.com/aspnet/Mvc" type="git" />

Example: <repository url="https://bitbucket.com/aspnet/Mvc" type="tfs" />

LGTM 👍🏽

@anangaur I could do the "review required" but I'm a partial party to this PR. I'll let someone else do the final review before we can merge this. 😂

What's left to do before we can merge this?
I see a review required, I wonder who should do this. @anangaur?
I see a conflicting file. @natemcmaster?

@MaximRouiller I chatted a bit with @joelverhagen, and from what I'm told, this may take a little bit longer to merge, but it's still on the radar.

@natemcmaster , please apply the migrations again. We had other schema changes that were already merged and I'm getting this error:

Unable to update database to match the current model because there are pending changes and automatic migration is disabled. Either write the pending model changes to a code-based migration or enable automatic migration. Set DbMigrationsConfiguration.AutomaticMigrationsEnabled to true to enable automatic migration.
You can use the Add-Migration command to write the pending model changes to a code-based migration.

Thanks @skofman1! Are there any other changes you want me to make?

@natemcmaster , this is the spec @anangaur wrote: https://github.com/NuGet/Home/wiki/Show-source-repository-information-for-packages-on-nuget.org
The current PR takes care of most of the requirements. There are warnings we would like to show when a user uploads an invalid URL, but we will take care of this in a different PR.
For This PR: please improve the github URL check, and I will merge. If you can do this before tomorrow EOD we can release next week.

Thanks @anangaur and @skofman1!
I pushed a fix for the GitHub URL check. It does a proper System.Uri check now to ensure the domain is github.com or www.github.com.

Thanks @skofman1 and @loic-sharma !


add Tformer and LeNet baselines

This pull request adds support to run the Tformer and LeNet baselines shown in the paper

It adds two new arguments for the model flag in the parser (Tformer, LeNet)
adds two new files in baselines/models/ (tformer.py, LeNet.py) which contain the respective models
adds two new Datasets to the loader.py (each with the necessary elif case for instantiating the loader)
modified Train.py file for special cases when Tformer (estimate mean/stddev from ensemble members) and Tformer or LeNet (reshape the efi_tensor)

I did a test run for the Tformer & LeNet models running each run for 1 training & 1 testing epoch.

Now the code works (again), loader.py is adapted.

Great! Could you run each model for 1 batch to make sure everything works? If so, we are good to merge.

I did already :) (1 train & 1 test epoch each). It works as expected.


RESPONSIVENESS

RESPONSIVENESS
User Story
AS A bootcamp student
I WANT a portfolio of work
SO THAT a typical hiring manager’s can view my skills and talents
Acceptance Criteria
GIVEN my portfolio of work
WHEN the page is resized or viewed on various screens and devices
THEN the layout is responsive and adapts to my viewport
AND has clean  consolidated css

WHEN the page is resized or viewed on various screens and devices
THEN the layout is responsive and adapts to my viewport
AND has clean consolidated css

WHEN the page is resized or viewed on various screens and devices
THEN the layout is responsive and adapts to my viewport
AND has clean consolidated css


Use a permit messages for ERC20 approvals

This task will reduce number of transactions users need to submit to one by "pre approving" another contract with an erc20 via a signed message.
See: https://soliditydeveloper.com/erc20-permit
Spec: https://eips.ethereum.org/EIPS/eip-2612

@pgebheim review please. Based on previous discussion, permit messages do NOT reduce number of approvals. Right? If yes, then this doesn't need to be high priority.
cc: @Chwy5

Need a better effort estimate to determine priority.

@pgebheim review please. Based on previous discussion, permit messages do NOT reduce number of approvals. Right? If yes, then this doesn't need to be high priority.
cc: @Chwy5

The UX with and without permit messages is very similar on Polygon. In both cases, the user will be presented with two popups requiring their private key. With permit, one of those popups does NOT require a transaction to be committed to the blockchain.
The difference is meaningful on ethereum because it's slower and more expensive. I don't think we gain much from this on Polygon.
In terms of effort, the contract change is just to use OpenZepplin's draft ERC20Permit extension. I'm not sure how worried we need to be about it being a draft. Tests will also need to be added so the total effort is 1-3 days.
UI effort is likely to be a much bigger deal but I can only speculate.

Agree, sounds like little benefit to do on polygon....closing


Optional highlighting for "ix-menu-item"

Suggestion / feature request
Add option to color "ix-menu-item" the same way, as the "About and legal information" or "Settings" are colored (change background color and add the small colored stripe at the left.).

Hi @alexkielburger, I am not sure if I understand your request correct.
The ix-menu-item has a "selected" property. If set, the item will show up as you mentioned.

Is this what you are looking for?

Yes, that is, what I was looking for.


Consider renaming "args" to "applicationArgs" in launch.json

I've often struggled to know and remember which parameter in launch.json is the right one to pass to Node vs to my application ("args" / "runtimeArgs"). Today on Twitter I saw that I am not alone with this issue.
Both "args" and "runtimeArgs" are somewhat ambiguous. The word "runtime" has two meanings ("runtime environment" or "execution time") which make it prone for misunderstandings. On the other hand "args" has no prefix. As a solution I propose renaming "args" to "applicationArgs" (or at least aliasing it, to avoid breaking changes). applicationArgs is pretty unambiguous and intuitively means that these arguments will be passed into your app, and not to the Runtime Environment.
Explicitly prefixing both parameters has the extra benefit of making it easier to infer there are other types of -args that you may configure.
CC: @auchenberg

We have been there before: initially we had "programArgs" vs. "runtimeArgs". Before we shipped VS Code 1.0 we decided to use the shorter and more common "args" for the 95% case and the longer "runtimeArgs" for the 5% case.
Changing this again is no longer an option.
In addition all these launch attributes are not defined by VS Code but by the individual debug adapters. So we can only change this for node-debug. But all the other debug extensions that copied us, wouldn't follow us. So we would end up with more confusing inconsistencies.


Exclude more mocks

Coverage increased (+0.09%) to 66.924% when pulling 3a0e41d60acaa60f1aaaca37e0e1515fb588073d on exclude-mocks into 4200e936fdf2b1c9027a00aa775b3e0c3af4f421 on master.


fix fix mtmv statistics case failure

Proposed changes
Issue Number: close #xxx

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...

run buildall

run buildall


Review java documentation

@BraunMatthias I have resolved the merge conflicts that I caused with my parallel refactoring of index.data.js to .ts files.  Sorry for the confusion.
Please pull this PR + the internal repo and just should have a consistent state.
There are still a number of broken links, but that is you work in progress I guess.

Hm.. looking at it.. still too many diffs not caused by you.  I guess I need to go back to square one and do the merge from main again.  Sorry, stay tuned..

Alright, this should now be your intended state, i.e. only your changes.
→ Please pull the PR again.
Now, for all file moves and renames, this is quite incompatible to the current URLs.  You need to at least add redirect_from: <old-URL> frontmatter to be compatible.
Still, all links to the old URLs need to be adjusted as these need to use the new URL pattern.
We can also discuss how to handle this...

Yes, redirect links have to be added in a step afterwards. But I wanted just to see and discuss the result in a preview.


Appending words to the tail of the configmap's key field causes the old key been over written!

Rancher versions:
rancher/rancher:v2.0.4
rancher/rancher-agent:v2.0.4
Steps to Reproduce:
Edit the configmap, and paste a word at the end of the configmap key field
Results:
The old key is over written instead of appended!

Can you describe in more detail what steps you are executing (steps to reproduce), what you are expecting and what you are seeing instead? As asked in the template or https://rancher.com/docs/rancher/v2.x/en/faq/contributing/#bugs-issues-or-questions

Version - 2.0 master 7/30
Verified fixed


Should we also detect mounts of dockershim.sock which is being deprecated?

The tool currently does not detect resources that mount the dockershim.sock, which is being deprecated and removed. Customers might mount this socket for various cluster tools (e.g. https://github.com/aws/amazon-vpc-cni-k8s/issues/1397).

I guess this was done on this commit: https://github.com/aws-containers/kubectl-detector-for-docker-socket/commit/69289c80f80426cafad895a2de0900df8548aa8b

I think this has already been done but feel free to comment again if it's still a problem.


RaggedTensor raises error with Keras model

Please make sure that this is a bug. As per our
GitHub Policy,
we only address code/doc bugs, performance issues, feature requests and
build/installation issues on GitHub. tag:bug_template
System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):Windows 10
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
TensorFlow installed from (source or binary):pip installed
TensorFlow version (use command below):2.3.0
Python version:3.7.0
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version:
GPU model and memory:RTX 2060 6G/16G RAM

You can collect some of this information using our environment capture
script
You can also obtain the TensorFlow version with:

TF 1.0: python -c "import tensorflow as tf; print(tf.GIT_VERSION, tf.VERSION)"
TF 2.0: python -c "import tensorflow as tf; print(tf.version.GIT_VERSION, tf.version.VERSION)"

Describe the current behavior
I builded a lstm model for one to one word classification:
model = Sequential()
model.add(layers.Input(shape=(None, 512), ragged=True))
model.add(layers.LSTM(32, return_sequences=True, dropout=0.4))
model.add(layers.TimeDistributed(layers.Dense(13, activation='softmax')))
model.compile(loss='categorical_crossentropy', optimizer='adam')
model.summary()

I then generated my x_train as a tf.RaggedTensor, with shape [10000, None, 512], dtype='float32'.
y_train as a tf.RaggedTensor, with shape [10000, None, 13], dtype='float32'.
Now if run it with:
history = model.fit(x, y, epochs=10, verbose=1)
I'd get:

TypeError: Failed to convert object of type <class 'tensorflow.python.ops.ragged.ragged_tensor.RaggedTensor'> to Tensor. Contents: tf.RaggedTensor(values=Tensor("sequential_42/time_distributed_46/dense_54/Softmax:0", shape=(None, 13), dtype=float32), row_splits=Tensor("sequential_42/time_distributed_46/RaggedFromRowLengths/control_dependency:0", shape=(None,), dtype=int64)). Consider casting elements to a supported type.
Describe the expected behavior
TimeDistributed layer should support RaggedTensor if the underlying model can process slice of RaggedTensor and output dimension is matched.
Standalone code to reproduce the issue

import tensorflow as tf
from tensorflow.keras import layers, Model, Sequential
import numpy as np

x = tf.RaggedTensor.from_row_splits(np.ones((100, 512)), [0, 4, 20, 100])
y = tf.RaggedTensor.from_row_splits(np.ones((100, 13)), [0, 4, 20, 100])
print(x.shape)
print(y.shape)
model = Sequential()
model.add(layers.Input(shape=(None, 512), ragged=True))
model.add(layers.LSTM(32, return_sequences=True, dropout=0.4))
model.add(layers.TimeDistributed(layers.Dense(13, activation='softmax')))
model.compile(loss='categorical_crossentropy', optimizer='adam')
model.summary()
history = model.fit(x=x, y=y, epochs=10, verbose=1)

Was able to reproduce the issue with TF v2.3 and TF-nightly. Please find the gist of it here. Thanks!

@kuan0808 I guess the root-cause is the mismatch in input arguments (x and y) to model.fit. Please check what is supported by model.fit.
The error clearly says

TypeError: Failed to convert object of type <class 'tensorflow.python.ops.ragged.ragged_tensor.RaggedTensor'> to Tensor. Contents: tf.RaggedTensor(values=Tensor("sequential/time_distributed/dense/Softmax:0", shape=(None, 13), dtype=float32), row_splits=Tensor("sequential/time_distributed/RaggedFromRowLengths/control_dependency:0", shape=(None,), dtype=int64)). Consider casting elements to a supported type.

Can you please use supported types and let us know how it progresses. Thanks!

Do you mean the dimension mismatch?
I have check the dimension, and they should be matched. And both x, y are ragged tensors, which is supposed to supported by model.fit I think🤔

Note that supporting RaggedTensors as targets (e.g., in model.fit) is a frequent request, see #44988, #44112, #43591, #43093, #42320, #41810.
Some partial progress is in pull requests #45060 and #45015, which will allow using custom losses in Keras model (but existing losses like MSE or (S)CE will still not work).

Note that I created a new feature request #45403 to support RaggedTensors in standard Keras loss functions.

@kuan0808,
Issue has been resolved in TF Nightly (2.5.0-dev20210302). Please find the Gist of the working code. Thanks!


tests: net: tx_timestamp: Check max number of interfaces

Add checks so that we do not overflow the network interface
array.
Fixes #8715
Signed-off-by: Jukka Rissanen<EMAIL_ADDRESS>

Codecov Report

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

@@           Coverage Diff           @@
##           master    #8731   +/-   ##
=======================================
  Coverage   52.36%   52.36%
=======================================
  Files         195      195
  Lines       24696    24696
  Branches     5128     5128
=======================================
  Hits        12931    12931
  Misses       9695     9695
  Partials     2070     2070

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 414291c...7790f2c. Read the comment docs.


Add Serialized "Shape" Tests to Negotiation Card Model

I started added some tests for the "shape" of the serialized JSON produced by model serialization in negotiation/test_model.py. However, I decided to push ahead with artifact protocol development without implementing these tests for most of the sub-models. This should be done.

@krmaffey this might be of interest to you.


Update sums for firefoxdeveloperedition 57.0b1

Sourced from https://ftp.mozilla.org/pub/devedition/releases/57.0b1/SHA256SUMS

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} reports no offenses.
[x] The commit message includes the cask’s name and version.

Additionally, if updating a cask:

[x] sha256 changed but version stayed the same (what is this?).
I’m providing public confirmation below.

The source for the checksums can be found here: https://ftp.mozilla.org/pub/devedition/releases/57.0b1/SHA256SUMS

Thanks for the PR! Closing in favour of https://github.com/caskroom/homebrew-versions/pull/4477 (version bump)

No worries, should have been lazier ;)


But how to listen to saved-socked-id ?

It's easy to emit/broadcast from a different process to other by socket-id, but i couldn't figure out how to listen a socket -id from an another process ?
Should i maintain my own messaging layer with redis pub/sub to listen events from another process/cluster ?
Also what about redis pub/sub performance ? For example, what if i send transformation object of a rolling ball from unity client to server with 50 messages per second ?

Thank you.

Closed due to inactivity, please reopen if needed.


Bug only one point chart

Hi guys,
I have an issue with the Scatter chart when i have only one point in my data
it display nothing but a label like this : /2007, maybe a bug with the scale ?
here is a sample code to illustrate my problem
<!DOCTYPE html>
<html>
	<head>
		<script src="JS/vendor/jquery-1.11.3.min.js"></script>
		<script src="JS/Chart.Core.min.js"></script>
		<script src="JS/Chart.Scatter.js"></script>

	</head>
	<body>
		<div>
			<canvas id="MainMasterContainer_FundMasterContainer_dedicatedFundScatterChart_ChartJsScatter" width="555" height="283" style="width: 555px; height: 283px;"></canvas>
		</div>
		<script>
			Chart.defaults.global.responsive = true;
			Chart.defaults.global.animation = false;

			//<![CDATA[

			Chart.defaults.global.responsive = true;
			//<![CDATA[
			var dataMainMasterContainer_FundMasterContainer_dedicatedFundScatterChart_ChartJsScatter = [
			{label:"",fillColor: "#d2d2d2",strokeColor: "#d2d2d2",highlightFill: "#000",highlightStroke: "#000", data: [{x: new Date('2007-12-31T00:00:00'),y: 10053.7153826788}]}
			];

			var optionMainMasterContainer_FundMasterContainer_dedicatedFundScatterChart_ChartJsScatter = {
			scaleLineColor : "black"
			,scaleFontColor : "black"
			,scaleShowGridLines : false
			,tooltipFontColor : "#fff"
			,tooltipCornerRadius : 0
			,bezierCurve : false
			,scaleShowHorizontalLines : true
			,scaleDateTimeFormat : "dd/mm/yyyy"
			,scaleDateFormat : "dd/mm/yyyy"
			,scaleGridLineColor : "rgba(0,0,0,1)"
			,scaleType : "date"
			,scaleShowVerticalLines : true
			,scaleLabel : "<%= value %> "
			 };
			var myChart = new Chart(document.getElementById("MainMasterContainer_FundMasterContainer_dedicatedFundScatterChart_ChartJsScatter").getContext("2d")).Scatter(dataMainMasterContainer_FundMasterContainer_dedicatedFundScatterChart_ChartJsScatter, optionMainMasterContainer_FundMasterContainer_dedicatedFundScatterChart_ChartJsScatter);
			//]]>
		</script>
	</body>
</html>

I have the same issue. Any idea, how to fix this?

no idea how to fiw no, i've fix some scale issue with no results ....

Hi,
I'm sorry, that did not answer for a long time. I changed my job and I have very little free time now.
The error has been corrected. In the near future I will update minified files.

Thanks a lot!

Thanks a lot, I will test this


[Pulsar Functions] functions trigger request timeout

Describe the bug
The functions trigger request timeout
To Reproduce
Steps to reproduce the behavior:

bin/pulsar-admin functions create ....
bin/pulsar-client consumer ....
bin/pulsar-admin functions trigger ....
The error:

20:36:03.994 [AsyncHttpClient-7-1] WARN  org.apache.pulsar.client.admin.internal.FunctionsImpl - [http://localhost:8080/admin/v3/functions/test/test-namespace/example1/trigger] Failed to perform http post request: javax.ws.rs.ClientErrorException: HTTP 408 Request Timeout
Request Timed Out

Reason: Request Timed Out

But the consumer received this message correctly.
Expected behavior
The function trigger can be executed normally.
Screenshots

Desktop (please complete the following information):

OS: MacOs
Broker: 2.6.1

This seems to be caused by the network environment at that time, now everything is normal, will close this issue.


Copying imputation and soft-pretraining logic from experiments to main training script

added tests for data.load_dataframe

Coverage increased (+7.09%) to 50.551% when pulling d2afcbcbf8b6978328519520e928b752e9c1835f on move-imputation-to-training-script into 713707b3a01dfdd5ceb51eae7a7cb93f28d483bb on master.

Looks fine to me, but just noting that I don't see imputation stuff here if that was intended


sysctl prefetch fails with "no implicit conversion of Array into String"

On a FreeBSD 12.2-RELEASE-p10 system, when my puppet catalog tried to apply, I get the error message:
Debug: Prefetching augeas resources for sysctl
Error: Could not prefetch sysctl provider 'augeas': no implicit conversion of Array into String
/var/puppet/lib/puppet/provider/sysctl/augeas.rb:96:in `block in instances'
/var/puppet/lib/puppet/provider/sysctl/augeas.rb:95:in `each'
/var/puppet/lib/puppet/provider/sysctl/augeas.rb:95:in `each_slice'
/var/puppet/lib/puppet/provider/sysctl/augeas.rb:95:in `instances'
/var/puppet/lib/puppet/provider/sysctl/augeas.rb:143:in `prefetch'
/usr/local/lib/ruby/site_ruby/2.7/puppet/transaction.rb:378:in `prefetch'
/usr/local/lib/ruby/site_ruby/2.7/puppet/transaction.rb:260:in `prefetch_if_necessary'
/usr/local/lib/ruby/site_ruby/2.7/puppet/transaction.rb:115:in `block in evaluate'
/usr/local/lib/ruby/site_ruby/2.7/puppet/graph/relationship_graph.rb:120:in `traverse'
/usr/local/lib/ruby/site_ruby/2.7/puppet/transaction.rb:178:in `evaluate'
/usr/local/lib/ruby/site_ruby/2.7/puppet/resource/catalog.rb:240:in `block (2 levels) in apply'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util.rb:546:in `block in thinmark'
/usr/local/lib/ruby/2.7/benchmark.rb:308:in `realtime'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util.rb:545:in `thinmark'
/usr/local/lib/ruby/site_ruby/2.7/puppet/resource/catalog.rb:239:in `block in apply'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util/log.rb:161:in `with_destination'
/usr/local/lib/ruby/site_ruby/2.7/puppet/transaction/report.rb:148:in `as_logging_destination'
/usr/local/lib/ruby/site_ruby/2.7/puppet/resource/catalog.rb:238:in `apply'
/usr/local/lib/ruby/site_ruby/2.7/puppet/configurer.rb:193:in `block (2 levels) in apply_catalog'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util.rb:546:in `block in thinmark'
/usr/local/lib/ruby/2.7/benchmark.rb:308:in `realtime'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util.rb:545:in `thinmark'
/usr/local/lib/ruby/site_ruby/2.7/puppet/configurer.rb:192:in `block in apply_catalog'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util.rb:233:in `block in benchmark'
/usr/local/lib/ruby/2.7/benchmark.rb:308:in `realtime'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util.rb:232:in `benchmark'
/usr/local/lib/ruby/site_ruby/2.7/puppet/configurer.rb:191:in `apply_catalog'
/usr/local/lib/ruby/site_ruby/2.7/puppet/configurer.rb:433:in `run_internal'
/usr/local/lib/ruby/site_ruby/2.7/puppet/configurer.rb:248:in `block in run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/context.rb:62:in `override'
/usr/local/lib/ruby/site_ruby/2.7/puppet.rb:314:in `override'
/usr/local/lib/ruby/site_ruby/2.7/puppet/configurer.rb:218:in `run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/agent.rb:60:in `block (5 levels) in run'
/usr/local/lib/ruby/2.7/timeout.rb:95:in `block in timeout'
/usr/local/lib/ruby/2.7/timeout.rb:105:in `timeout'
/usr/local/lib/ruby/site_ruby/2.7/puppet/agent.rb:59:in `block (4 levels) in run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/agent/locker.rb:21:in `lock'
/usr/local/lib/ruby/site_ruby/2.7/puppet/agent.rb:53:in `block (3 levels) in run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/agent.rb:136:in `with_client'
/usr/local/lib/ruby/site_ruby/2.7/puppet/agent.rb:50:in `block (2 levels) in run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/agent.rb:101:in `run_in_fork'
/usr/local/lib/ruby/site_ruby/2.7/puppet/agent.rb:49:in `block in run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/application.rb:179:in `controlled_run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/agent.rb:47:in `run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/application/agent.rb:433:in `onetime'
/usr/local/lib/ruby/site_ruby/2.7/puppet/application/agent.rb:393:in `block in run_command'
/usr/local/lib/ruby/site_ruby/2.7/puppet/context.rb:62:in `override'
/usr/local/lib/ruby/site_ruby/2.7/puppet.rb:314:in `override'
/usr/local/lib/ruby/site_ruby/2.7/puppet/application/agent.rb:389:in `run_command'
/usr/local/lib/ruby/site_ruby/2.7/puppet/application.rb:382:in `block in run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util.rb:735:in `exit_on_fail'
/usr/local/lib/ruby/site_ruby/2.7/puppet/application.rb:382:in `run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util/command_line.rb:143:in `run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util/command_line.rb:77:in `execute'
/usr/local/bin/puppet:5:in `<main>'

Puppet Code
I do try to set a few sysctl values:
  sysctl {
    'security.bsd.see_other_uids':
      ensure => present,
      value  => '0';

    'security.bsd.see_other_gids':
      ensure => present,
      value  => '0';
  }

Versions
OS: FreeBSD 12.2-RELEASE-p10
Puppet version : 6.23.0
Module version: 2.6.1

@madelaney Can you try with the latest PR?

@trevor-vaughan Sure, let me see what I can do. I'll try with !59

@trevor-vaughan It doesn't appear to have helped.
Here is my Puppetfile.lock stanza for herculesteam-augeasproviders_sysctl:
GIT
  remote: https://github.com/trevor-vaughan/augeasproviders_sysctl.git
  ref: fix-target-idempotency
  sha: 6b79ea73208af6871f53694ffd03b1c80db8371a
  specs:
    herculesteam-augeasproviders_sysctl (2.6.1)
      herculesteam-augeasproviders_core (< 3.0.0, >= 2.4.0)

And the run still produces:
Debug: Prefetching augeas resources for sysctl
Error: Could not prefetch sysctl provider 'augeas': no implicit conversion of Array into String
/var/puppet/lib/puppet/provider/sysctl/augeas.rb:104:in `block in instances'
/var/puppet/lib/puppet/provider/sysctl/augeas.rb:103:in `each'
/var/puppet/lib/puppet/provider/sysctl/augeas.rb:103:in `each_slice'
/var/puppet/lib/puppet/provider/sysctl/augeas.rb:103:in `instances'
/var/puppet/lib/puppet/provider/sysctl/augeas.rb:167:in `prefetch'
/usr/local/lib/ruby/site_ruby/2.7/puppet/transaction.rb:378:in `prefetch'
/usr/local/lib/ruby/site_ruby/2.7/puppet/transaction.rb:260:in `prefetch_if_necessary'
/usr/local/lib/ruby/site_ruby/2.7/puppet/transaction.rb:115:in `block in evaluate'
/usr/local/lib/ruby/site_ruby/2.7/puppet/graph/relationship_graph.rb:120:in `traverse'
/usr/local/lib/ruby/site_ruby/2.7/puppet/transaction.rb:178:in `evaluate'
/usr/local/lib/ruby/site_ruby/2.7/puppet/resource/catalog.rb:240:in `block (2 levels) in apply'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util.rb:546:in `block in thinmark'
/usr/local/lib/ruby/2.7/benchmark.rb:308:in `realtime'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util.rb:545:in `thinmark'
/usr/local/lib/ruby/site_ruby/2.7/puppet/resource/catalog.rb:239:in `block in apply'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util/log.rb:161:in `with_destination'
/usr/local/lib/ruby/site_ruby/2.7/puppet/transaction/report.rb:148:in `as_logging_destination'
/usr/local/lib/ruby/site_ruby/2.7/puppet/resource/catalog.rb:238:in `apply'
/usr/local/lib/ruby/site_ruby/2.7/puppet/configurer.rb:193:in `block (2 levels) in apply_catalog'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util.rb:546:in `block in thinmark'
/usr/local/lib/ruby/2.7/benchmark.rb:308:in `realtime'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util.rb:545:in `thinmark'
/usr/local/lib/ruby/site_ruby/2.7/puppet/configurer.rb:192:in `block in apply_catalog'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util.rb:233:in `block in benchmark'
/usr/local/lib/ruby/2.7/benchmark.rb:308:in `realtime'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util.rb:232:in `benchmark'
/usr/local/lib/ruby/site_ruby/2.7/puppet/configurer.rb:191:in `apply_catalog'
/usr/local/lib/ruby/site_ruby/2.7/puppet/configurer.rb:433:in `run_internal'
/usr/local/lib/ruby/site_ruby/2.7/puppet/configurer.rb:248:in `block in run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/context.rb:62:in `override'
/usr/local/lib/ruby/site_ruby/2.7/puppet.rb:314:in `override'
/usr/local/lib/ruby/site_ruby/2.7/puppet/configurer.rb:218:in `run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/agent.rb:60:in `block (5 levels) in run'
/usr/local/lib/ruby/2.7/timeout.rb:95:in `block in timeout'
/usr/local/lib/ruby/2.7/timeout.rb:105:in `timeout'
/usr/local/lib/ruby/site_ruby/2.7/puppet/agent.rb:59:in `block (4 levels) in run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/agent/locker.rb:21:in `lock'
/usr/local/lib/ruby/site_ruby/2.7/puppet/agent.rb:53:in `block (3 levels) in run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/agent.rb:136:in `with_client'
/usr/local/lib/ruby/site_ruby/2.7/puppet/agent.rb:50:in `block (2 levels) in run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/agent.rb:101:in `run_in_fork'
/usr/local/lib/ruby/site_ruby/2.7/puppet/agent.rb:49:in `block in run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/application.rb:179:in `controlled_run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/agent.rb:47:in `run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/application/agent.rb:433:in `onetime'
/usr/local/lib/ruby/site_ruby/2.7/puppet/application/agent.rb:393:in `block in run_command'
/usr/local/lib/ruby/site_ruby/2.7/puppet/context.rb:62:in `override'
/usr/local/lib/ruby/site_ruby/2.7/puppet.rb:314:in `override'
/usr/local/lib/ruby/site_ruby/2.7/puppet/application/agent.rb:389:in `run_command'
/usr/local/lib/ruby/site_ruby/2.7/puppet/application.rb:382:in `block in run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util.rb:735:in `exit_on_fail'
/usr/local/lib/ruby/site_ruby/2.7/puppet/application.rb:382:in `run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util/command_line.rb:143:in `run'
/usr/local/lib/ruby/site_ruby/2.7/puppet/util/command_line.rb:77:in `execute'
/usr/local/bin/puppet:5:in `<main>'

@madelaney If you could try it again, I think I fixed the issue.

@trevor-vaughan , yeah, no problem. Give me about an hour or so.

@trevor-vaughan Success! 🥇  using sha1 edb0b2a976423d422f66ffa66e0fdeeffb152305 seems to have resolved it.

Closing as the pull-request !59 will resolve this.


Computed defaults shared with parent/sub charts

Helm version 3.5.2, fwiw.
I'm trying to write a helm chart for my application. This application uses database services for which other people have written helm charts, so I don't want to redo all they've done, and instead I'll add their helm charts as an optional dependency to mine (so that they can just run a database server externally if they so please, by setting a boolean to false and configuring a connection string somewhere).
This works, but there is a problem.
The subchart defaults to generating passwords (probably using randAlphaNum or one of its friends). I don't want to force the user to have to manually enter a password anywhere (because that would reduce randomness and therefore security).
Since the randAlphaNum value is not stored in the subchart's values.yaml file, there is no way for my parent chart to access the database password. This means I am limited to the following two options, all equally bad:

I can tell the user they have to generate a random password, and enter that as a hardcoded value, so that I can access it from anywhere;
I can create an initContainer that reads the password from the database chart's secret, and stores it into my configuration somehow

The first option reduces randomness in the password, and thus reduces security. I'd rather not do that.
The second option, apart from needlessly wasting CPU, means my parent chart is now depending on the internal names and organization of the child chart, which means that if those ever get changed, I now have to update my chart for no particularly good reason. This is a massive abstraction violation.
I think it should be possible to create defaults that can be accessed from parent charts without having to wait until everything has been deployed and hacking around using initContainers

this is still open...?

"github-actions[bot]" @.***> schreef op 24 september 2021 02:06:57 GMT+02:00:

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/helm/helm/issues/9457#issuecomment-926250014
The only reason this is stale is because nobody ever bothered to look at the suggestion, other than to put a label on the issue.
--
Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid.

Sorry for the lack of a response.
I'm not sure what you'd like us to do here, honestly. This question seems incredibly specific to the chart in question. you may have better luck asking the maintainers of the chart to accommodate your use case.
Additionally, it may be best to ask this question in the community slack channel. I'm sure there are others who have experienced similar issues in the past.
Hope this helps.

I'm facing the same issue. There are some scenarios where you need to generate a random string to be shared with the subcharts. But I have no idea how this could be achieved (maybe allowing use of functions in values.yaml?).

Still exists.

I'm not sure what you'd like us to do here, honestly. This question seems incredibly specific to the chart in question. You may have better luck asking the maintainers of the chart to accommodate your use case.

I can't imagine that having a chart which wants to use subcharts, and where data needs to be read from those subcharts, is a very unusual situation.
I also don't think that having a proper way for a subchart to export data to a parent chart is in any way strange. It seems like a standard feature of most programming languages, in fact. While I could update my chart to override the normally-generated variables in the sub chart (and ask the maintainer of the sub chart to declare that variable an API), it seems like a layering violation to do so; after all, if the format of the variable that I need to access needs to change in the future, then I'd have to update my chart in order for it to continue to work. This seems like it should not be necessary.


Add some text to the section on networking to make it a bit clearer.

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Ran into this on a support ticket recently - found that I had to add my private subnet in order for the Lambda to do a cross account role assumption (CARA).

Thanks! The wording of the rest of this section is a bit redundant so I'm going to do a pass on it as well.


Add unsupported eth_newPendingTransactionFilter

Description:
Adds the eth_newPendingTransactionFilter method which always returns an UNSUPPORTED json rpc error
Related issue(s):
Fixes #
Notes for reviewer:

Checklist

[ ] Documented (Code comments, README, etc.)
[ ] Tested (unit, integration, etc.)

Codecov Report
Patch coverage: 25.00% and project coverage change: -9.01% :warning:

Comparison is base (596f365) 78.60% compared to head (6ff88e2) 69.60%.

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

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1619      +/-   ##
==========================================
- Coverage   78.60%   69.60%   -9.01%
==========================================
  Files          36       36
  Lines        2674     2678       +4
  Branches      534      534
==========================================
- Hits         2102     1864     -238
- Misses        416      690     +274
+ Partials      156      124      -32

Files Changed
Coverage Δ

.../lib/services/ethService/ethFilterService/index.ts
94.28% <0.00%> (-5.72%)
:arrow_down:

...s/server/src/koaJsonRpc/lib/methodConfiguration.ts
100.00% <ø> (ø)

packages/server/src/server.ts
31.85% <50.00%> (-42.25%)
:arrow_down:

... and 8 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


react 0.14.0-rc1

wanted to check to see if the package.json could be updated to support react 0.14

package.json allows react 0.14.0-rc1