[web] Erratic text selection behavior

Text selection/mouse gestures do not work as expected when compiling for web. Selection behavior is completely off. Selection using keyboard controls works as expected; this is purely mouse controls.

Selecting text on a line in a TextField with multiple lines selects text from all other lines
Select all/CMD+A doesn't select anything at all
Selection/cursor is flickering when selecting text
When using the mouse to create a selection on one line, it might end up selecting one or many other lines instead or in addition

This is happening on both  dev and master and both in debug and release mode
Video of behavior (Vimeo)
Steps to Reproduce

flutter create --web
Add a TextField or TextFormField

Target Platform: Web
Target OS version/browser: Chrome / macOS Catalina 10.15.1
Devices: MacBook Pro 15-inch, 2019
Logs (Xcode logs omitted)
Running "flutter pub get" in test_project...                        0.3s
arne ~/dnb/test_project flutter run -d chrome -v
[  +20 ms] executing: [/Users/bruker/flutter/] git -c log.showSignature=false log -n 1 --pretty=format:%H
[  +36 ms] Exit code 0 from: git -c log.showSignature=false log -n 1 --pretty=format:%H
[        ] 459c7fb884d9234c45b353087e0ec8a33dde90d1
[        ] executing: [/Users/bruker/flutter/] git describe --match v*.*.* --first-parent --long --tags
[  +14 ms] Exit code 0 from: git describe --match v*.*.* --first-parent --long --tags
[        ] v1.12.15-0-g459c7fb88
[   +6 ms] executing: [/Users/bruker/flutter/] git rev-parse --abbrev-ref --symbolic @{u}
[  +10 ms] Exit code 0 from: git rev-parse --abbrev-ref --symbolic @{u}
[        ] origin/dev
[        ] executing: [/Users/bruker/flutter/] git ls-remote --get-url origin
[   +9 ms] Exit code 0 from: git ls-remote --get-url origin
[        ] https://github.com/flutter/flutter
[  +53 ms] executing: [/Users/bruker/flutter/] git rev-parse --abbrev-ref HEAD
[  +11 ms] Exit code 0 from: git rev-parse --abbrev-ref HEAD
[        ] dev
[   +5 ms] executing: sw_vers -productName
[  +16 ms] Exit code 0 from: sw_vers -productName
[        ] Mac OS X
[        ] executing: sw_vers -productVersion
[  +16 ms] Exit code 0 from: sw_vers -productVersion
[        ] 10.15.1
[        ] executing: sw_vers -buildVersion
[  +16 ms] Exit code 0 from: sw_vers -buildVersion
[        ] 19B88
[  +36 ms] Artifact Instance of 'AndroidMavenArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'AndroidGenSnapshotArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'AndroidInternalBuildArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'IOSEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterWebSdk' is not required, skipping update.
[   +4 ms] Artifact Instance of 'WindowsEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxFuchsiaSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSFuchsiaSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterRunnerSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterRunnerDebugSymbols' is not required, skipping update.
[  +36 ms] executing: /Users/bruker/Library/Android/sdk/platform-tools/adb devices -l
[   +6 ms] Exit code 0 from: /Users/bruker/Library/Android/sdk/platform-tools/adb devices -l
[        ] List of devices attached
[  +13 ms] executing: /Users/bruker/flutter/bin/cache/artifacts/libimobiledevice/idevice_id -h
[  +79 ms] Error getting attached iOS device: ideviceinfo could not find device:
           No device found with udid 00008027-0005114922E3002E, is it plugged in?
           . Try unlocking attached devices.
[   +4 ms] executing: /usr/bin/xcode-select --print-path
[   +9 ms] Exit code 0 from: /usr/bin/xcode-select --print-path
[        ] /Applications/Xcode.app/Contents/Developer
[   +1 ms] executing: /usr/bin/xcodebuild -version
[ +272 ms] Exit code 0 from: /usr/bin/xcodebuild -version
[   +3 ms] Xcode 11.2.1
           Build version 11B500
[   +2 ms] /usr/bin/xcrun simctl list --json devices
[  +96 ms] Artifact Instance of 'AndroidMavenArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'AndroidGenSnapshotArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'AndroidInternalBuildArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'IOSEngineArtifacts' is not required, skipping update.
[   +2 ms] Artifact Instance of 'WindowsEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxFuchsiaSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSFuchsiaSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterRunnerSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterRunnerDebugSymbols' is not required, skipping update.
[ +167 ms] Generating /Users/bruker/dnb/test_project/android/app/src/main/java/io/flutter/plugins/GeneratedPluginRegistrant.java
⣽[  +31 ms] executing: [/Users/bruker/dnb/test_project/ios/Runner.xcodeproj/] /usr/bin/xcodebuild -project /Users/bruker/dnb/test_project/ios/Runner.xcodeproj -target Runner
-showBuildSettings
[   +2 ms] executing: [/Users/bruker/dnb/test_project/ios/Runner.xcodeproj/] /usr/bin/xcodebuild -project /Users/bruker/dnb/test_project/ios/Runner.xcodeproj -target Runner
-showBuildSettings
[EXCLUDED IOS LOGS]
[  +68 ms] Launching lib/main.dart on Chrome in debug mode...
[        ] Building application for the web...
[+7323 ms] Starting daemon...
[ +135 ms] Initializing inputs
[  +11 ms] Reading cached asset graph...
[ +150 ms] Reading cached asset graph completed, took 147ms

[ +184 ms] Checking for updates since last build...
[ +433 ms] Checking for updates since last build completed, took 433ms

[   +8 ms] Initializing inputs
[   +2 ms] Reading cached asset graph...
[        ] Reading cached asset graph completed, took 147ms
[        ] Checking for updates since last build...
[        ] Checking for updates since last build completed, took 433ms
[ +117 ms] Serving DevTools at http://<IP_ADDRESS>:52573

[ +534 ms] About to build [web]...
[   +3 ms] Running build...
[ +124 ms] Running build completed, took 65ms

[   +1 ms] Caching finalized dependency graph...
[   +6 ms] Caching finalized dependency graph completed, took 81ms

[   +3 ms] Succeeded after 152ms with 0 outputs (0 actions)

[   +8 ms] Building application for the web... (completed in 9.0s)
[        ] Attempting to connect to browser instance..
[+2186 ms] Debug service listening on ws://<IP_ADDRESS>:52613/m7BgCH1Kag4=

[  +18 ms] Attempting to connect to browser instance.. (completed in 2.5s)
[   +1 ms] Warning: Flutter's support for web development is not stable yet and hasn't
[        ] been thoroughly tested in production environments.
[        ] For more information see https://flutter.dev/web
[        ] 🔥  To hot restart changes while running, press "r". To hot restart (and refresh the browser), press "R".
[   +1 ms] For a more detailed help message, press "h". To quit, press "q".
[  +10 ms] Debug service listening on ws://<IP_ADDRESS>:52613/m7BgCH1Kag4=

flutter analyze
arne ~/dnb/test_project flutter analyze
Analyzing test_project...
No issues found! (ran in 1.5s)

flutter doctor -v
arne ~/dnb/test_project flutter doctor -v
[✓] Flutter (Channel dev, v1.12.15, on Mac OS X 10.15.1 19B88, locale en-NO)
    • Flutter version 1.12.15 at /Users/bruker/flutter
    • Framework revision 459c7fb884 (4 days ago), 2019-11-26 17:04:51 +0000
    • Engine revision e136d637a8
    • Dart version 2.7.0

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
    • Android SDK at /Users/bruker/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-29, build-tools 29.0.2
    • Java binary at: /Users/bruker/Library/Application Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/191.5791312/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 11.2.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.2.1, Build version 11B500
    • CocoaPods version 1.8.4

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 3.5)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 41.1.2
    • Dart plugin version 191.8593
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)

[✓] Android Studio (version 3.5)
    • Android Studio at /Users/bruker/Library/Application Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/191.5791312/Android Studio.app/Contents
    • Flutter plugin version 41.1.2
    • Dart plugin version 191.8593
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)

[✓] IntelliJ IDEA Ultimate Edition (version 2019.1.3)
    • IntelliJ at /Applications/IntelliJ IDEA.app
    • Flutter plugin version 38.1.3
    • Dart plugin version 191.8369

[!] IntelliJ IDEA Ultimate Edition (version 2019.2.1)
    • IntelliJ at /Users/bruker/Applications/JetBrains Toolbox/IntelliJ IDEA Ultimate.app
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
    • For information about installing plugins, see
      https://flutter.dev/intellij-setup/#installing-the-plugins

[✓] VS Code (version 1.40.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.6.0

[✓] Connected device (2 available)
    • Chrome     • chrome     • web-javascript • Google Chrome 78.0.3904.108
    • Web Server • web-server • web-javascript • Flutter Tools

! Doctor found issues in 1 category.

this could help you: https://github.com/flutter/flutter/issues/45510#issuecomment-558313671

Thanks for the tip @Ahmadre
The problems might very well be related but unfortunately, the proposed fix does not work in my case

/cc @mdebbar

Thanks for reporting fix is on the way.

The problem is still there. How can I make sure he's fixed
[√] Flutter (Channel master, v1.14.7-pre.98, on Microsoft Windows [Version 10.0.18362.592], locale zh-CN)

[√] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[√] Chrome - develop for the web
[√] Visual Studio - develop for Windows (Visual Studio Professional 2019 16.4.2)
[√] Android Studio (version 3.4)
[√] Connected device (3 available)

• No issues found!

Hi @jlcool thanks for the comment.
This issue is confirmed to be fixed on December. Can you please file another issue?
Can you also please share which browser and OS you are working on?
Best,

Thanks I will continue on this one: https://github.com/flutter/flutter/issues/50101

Thank you. https://github.com/flutter/flutter/issues/50101 That's what I want to say. I will pay attention to his follow-up status


Add space between input field and button

I would like to work on this issue.

Thank you for raising the issue 😄
Assigned it to you 👍🏻


Look for the nddscpp CMake module

Testing here: http://<IP_ADDRESS>:8080/job/ros2_batch_ci_test_linux/28/console

Now we get a meaningful error w.r.t. pkg-config:
CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108 (message):
  Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
Call Stack (most recent call first):
  /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:315 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-2.8/Modules/FindPkgConfig.cmake:106 (find_package_handle_standard_args)
  /usr/share/nddscpp/cmake/nddscppConfig.cmake:8 (find_package)
  cmake/Modules/FindConnext.cmake:220 (find_package)
  CMakeLists.txt:8 (find_package)

-- Configuring incomplete, errors occurred!

I'll run again with pkg-config installed, the deb should be updated to depend on it. I think @esteve may already be away of that since we talked about it this morning.

New job: http://<IP_ADDRESS>:8080/job/ros2_batch_ci_test_linux/29/console

New problem:
http://<IP_ADDRESS>:8080/job/ros2_batch_ci_test_linux/32/console
It doesn't find all of the required libraries. That job is with the four rti binaries (excluding the rti tools deb), NDDS_HOME is not set, pkg-config is explicitly installed, and this pull request's branch is being used.

THe ros2_batch_ci_linux job now finds RTI Connext: http://<IP_ADDRESS>:8080/view/ros2/job/ros2_batch_ci_linux/15/console

@dirk-thomas @tfoote @wjwwood please review

+1

So, are we going to make an adjustment to this or is it good to go? I don't mind either way, just wondering.

@wjwwood I'm waiting for @tfoote 's review.

+1


text_on_image Creator - Web design #81

https://images01.nicepagecdn.com/page/12/40/html-template-124023.jpg Design a text_on_image like the above image
Create a file "text_on_image_NUM_by_(YourName).html" in the modules/text_on_image folder.
Use simple HTML and CSS and JAVASCRIPT to create the text_on_image animation. You can use the interface development https://kwickerhub.com/ (This project) or you can write the lines of code yourself.
Step by Step Guide.
Fork this project(Use the 'fork' button in the top right corner) and Clone your Fork.
git clone https://github.com/YOUR_USERNAME/frontend
Open your code Editor and Create a file "text_on_image_NUM_YOUR_NAME_.html" in the "modules/text_on_image" folder of this project you just cloned. No need to create head, title and body tags, Just Add a div tag with some embedded style(i.e use the style tag) and the script tag where necessary.
If you want to add an image resource, please add it in the folder ••
"modules/text_on_image/images_and_icons"
We recommend you use an svg for your image/icon.
Push your Code: You need to push your recent changes back to the cloud. Use the command below in the main directory of this Repository
git push origin dev
or use a GUI tool to avoid mistakes or complexity. LOL.
Then make you Pull Request...
Below is a example of the code structure we need:
<div>
    <!---YOUR CODE---->
</div>

<style>
    /* YOUR STYLE */
</style>

<script>
    // YOUR SCRIPT if any
</script>

The goal of this issue is to create modules that other people/dev/designers can use or easily import into their projects. Avoid the desire to style all elements in the page by using codes like:
<style>

*{

}
/* OR */

div, a, h1, pre{

}

</style>

use classes or id to style the elements to avoid a collision of styles.
Remember to make your module usable across different screens(Make your design responsive).
For more examples:
modules->buttons
modules->cards
for examples of contributions or Pull request accepted in to the project.
And please do not wait for this issue to be assigned to you as we have limited hands but have a lot to do/cover. Please send in your PR.
Good-luck and thank you.

Hey @NtemKenyor Can you assign this to me, I am working on it.

@NtemKenyor I have commited the code, can you review the code


[4.2] Implement NSArray's customMirror

Let's kicking CI.
@swift-ci Please test.

swift-4.2-branch is limited to pull requests for bug fixes which are already landed on master. Could you target this  on master?
See https://forums.swift.org/t/announcing-swift-4-2-2-and-monthly-swift-4-2-x-dot-releases-for-linux/20148 for the details.

@noppefoxwolf swift-4.2-branch is limited to pull requests for bug fixes which are already landed on master. Could you target this  on master?
See https://forums.swift.org/t/announcing-swift-4-2-2-and-monthly-swift-4-2-x-dot-releases-for-linux/20148 for the details.

@ikesyo Thank you for your comment!
I changed target and resolved conflict.

@swift-ci Please test

@ikesyo Thank you!
I resolve comments issues.

@swift-ci Please test

@swift-ci Please test

@ikesyo @spevans Thank you for checking.
Is there anything else to do?

@swift-ci test and merge

@swift-ci test and merge


crow-translate: Use portable settings

crow-translate/crow-translate#74
Investigate if there is possible to migrate settings from registry into conf file, otherwise add standalone portable manifest.
It is common qt portable mode, which is recreating files instead of changing it, so unisntaller/installer combo is needed.

Looks like it is possible to migrate things from the registry,
https://devblogs.microsoft.com/scripting/use-powershell-to-enumerate-registry-property-values/
However, it might be a pain to format this stuff for use in Set-Content for the settings.ini portable file.

It would also have to be done on each Sub-key as well.

Do you want to save user settings after switching from the registry to portable settings?


⚠ Cioos Pacific CKAN Sitemap has degraded performance

In 3d9a440, Cioos Pacific CKAN Sitemap (https://catalogue.cioospacific.ca/sitemap/sitemap-1.xml) experienced degraded performance:

HTTP code: 200
Response time: 13245 ms

Resolved: Cioos Pacific CKAN Sitemap performance has improved in a8805f9 after 17 minutes.


net/http: the Server.Shutdown listener polling interval causes shutdown delay

The fix for #33313 ensured that Shutdown waits for listeners to be closed but uses a fixed polling interval of 500ms. This causes Shutdown to almost always take at least 500ms which can be noticeable in interactive contexts.
It would be nice if the polling started with a small interval and backed off to 500ms or so.

/cc @mikioh


Html5 required error disabled with maskedinput

Hi guys,
When I mask a required field, the HTML5 error doesn't appear when my field is empty.
Here an example with maskedinput :
http://jsfiddle.net/sfvyo4wr/
Here an example without maskedinput :
http://jsfiddle.net/3bt48qx6/
You just have to click on "Send" to see the difference.
Does someone know how to fix it ?
Thanks.

Hi,
I have same problem.
I do the same question of the @pDc. Does someone know how to fix it?
Thanks

I have the same problem. Can somebody please help? @digitalBush @codeimpossible

Same problem


GitHub Packages

HI @jonorossi
Looks like Github has added a "packages" functionality. So you can push packages to github.
Could it be interesting for prereleases etc? Now that the team city = gone.
Something to look into for the build?

Yep, GitHub Packages has been there since last year but I've not played with it yet. Definitely something to look to replace the AppVeyor NuGet feed. I already started writing a GitHub Actions "workflow" to move from AppVeyor, that can be a separate step afterwards.


update google-auth-library to 0.17.2

Codecov's coverage seems incorrect here

Yes, I don't think codecov is accurate to 4 significant digits. We should probably loosen that check a bit.


Auto-formatting a function call with a lambda parameter truncates space before parameter

When I write an expression which invokes a function that accepts a function as a parameter, and I use lambda syntax for the function parameter, VS eliminates the space after the comma and before the lambda expression when it performs an auto-format.
What should be this:
function test<T>(list: T[], predicate: (value: T) => boolean) {
    ...
}

test([1, 2, 3], (x: number) => x > 2);

becomes this:
function test<T>(list: T[], predicate: (value: T) => boolean) {
    ...
}

test([1, 2, 3],(x: number) => x > 2);

Using function () syntax does not cause a truncation of the space.
There does not appear to be a formatting options regarding spacing between parameters, let alone for using lambda syntax.
This appears to have been introduced with VS 2015 CTP 5, as opposed to VS 2015 preview which behaved as expected.

This is a known issue that was already fixed in the latest bits and should be available once 1.5 is released.


Extra Constructor Parameter for Properties Using field Keyword

C# 13 (preview) introduced a new field keyword to allow accessing the compiler backing field in a property accessor, eliminating the need to declare an explicit backing field in most cases. See documentation
Currently, AutoCtor generates a constructor parameter for properties using the field keyword, where it previously only generated parameters for fields. This behavior leads to an extra constructor parameter being created for properties that use the field keyword.
Example with field
[AutoConstruct]
public sealed partial class AndsOperations
{
   #region fields
   readonly IMapperFactory<Func> _mapperFactory;
   #endregion

   #region properties
   [field: AllowNull] [field: MaybeNull] IMapper ForCreates => field ??= _mapperFactory.GetMapper(Create);
   #endregion
}

Example before refactoring
[AutoConstruct]
public sealed partial class AndsOperations
{
   #region fields
   readonly *InternalNamespace*.IMapperFactory<*InternalNamespace*.Func> _mapperFactory;
   IMapper?                      _forCreates;
   #endregion

   #region properties
   IMapper ForCreates => _forCreates ??= _mapperFactory.GetMapper(Create);
   #endregion
}

Expected output
partial class AndsOperations
{
    [global::System.Runtime.CompilerServices.CompilerGeneratedAttribute]
    [global::System.CodeDom.Compiler.GeneratedCodeAttribute("AutoCtor", "<IP_ADDRESS>")]
    public AndsOperations(global::*InternalNamespace*.IMapperFactory<global::*InternalNamespace*.Func> mapperFactory)
    {
	    this._mapperFactory = mapperFactory;
    }
}

Actual output
partial class AndsOperations
{
    [global::System.Runtime.CompilerServices.CompilerGeneratedAttribute]
    [global::System.CodeDom.Compiler.GeneratedCodeAttribute("AutoCtor", "<IP_ADDRESS>")]
    public AndsOperations(global::*InternalNamespace*.IMapperFactory<global::*InternalNamespace*.Func> mapperFactory, global::AutoMapper.IMapper forCreates)
    {
	    this._mapperFactory = mapperFactory;
	    this.ForCreates = forCreates;
    }
}

Suggested Fix
The constructor should not include the ForCreates property as a parameter, as the field keyword is already handling the backing field internally. AutoCtor should be updated to detect and handle properties using the field keyword differently from regular properties.

This should be fixed in version 2.4.4.
The test example for this is here https://github.com/distantcam/AutoCtor/blob/5b29b832fdb8039a42dfc1b1ee22f7dfbb84477f/src/AutoCtor.Tests/LangExamples/PropertiesTest.cs#L22
And the test result here
https://github.com/distantcam/AutoCtor/blob/5b29b832fdb8039a42dfc1b1ee22f7dfbb84477f/src/AutoCtor.Tests/LangExamples/Verified_4/PropertiesTest.ExamplesGeneratedCode%23PropertiesTest.g.verified.cs

Perfect, verified in my project as well. Thanks for the speedy fix!

I was working on integrating this in another project and came across a similar scenario:
public string ConnectionString
 {
    get
    {
       if (field.IsNullOrWhiteSpace())
          field = ((_context.Connection as EntityConnection)?.StoreConnection as SqlConnection)?.ConnectionString ?? throw new InvalidOperationException("Unknown database connection string");

       return field;
    }
 }

This also did not generate a parameter for the constructor prior to refactoring to use the field keyword.

Great, thanks for your work on this issue!


event not triggered for the first slide

I'm trying to add "animated" to all the SPAN within the active LI
but the event onBeforeSlide/onAfterSlide is not triggered for the first slide
i cannot use onBeforeStart because at that point the LI does not have the "active" class on it
any ideas?

I'm not sure if this is related to the problem or something else, but there is another small bug with the first slide in which if you move all the way to the last, and then move into the first, the next click for next does not trigger. It seems to be some delay when moving from the cloned slide into the first slide. If you wait long enough before clicking this doesn't happen.


chore: fix controllers after dep updates

Signed-off-by: Rudraksh Pareek<EMAIL_ADDRESS>This fixes CI failures due to https://github.com/kubearmor/KubeArmor/commit/b576fda3ce9083c16ccf652394533a5f0ad0e84f

Codecov Report

Merging #888 (cd89200) into main (b576fda) will decrease coverage by 3.25%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #888      +/-   ##
==========================================
- Coverage   38.93%   35.67%   -3.26%
==========================================
  Files          31       31
  Lines        9703     9703
==========================================
- Hits         3778     3462     -316
- Misses       5418     5769     +351
+ Partials      507      472      -35

Impacted Files
Coverage Δ

KubeArmor/core/crioHandler.go
0.00% <0.00%> (-63.87%)
:arrow_down:

KubeArmor/core/containerdHandler.go
3.33% <0.00%> (-49.26%)
:arrow_down:

KubeArmor/core/kubeArmor.go
46.46% <0.00%> (-3.54%)
:arrow_down:

KubeArmor/monitor/processTree.go
94.62% <0.00%> (-1.08%)
:arrow_down:

KubeArmor/common/common.go
42.47% <0.00%> (-0.78%)
:arrow_down:

KubeArmor/core/kubeUpdate.go
36.21% <0.00%> (-0.41%)
:arrow_down:

KubeArmor/feeder/policyMatcher.go
41.60% <0.00%> (-0.35%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Added tests for controllers in PRs - https://github.com/kubearmor/KubeArmor/actions/runs/3014685822


[Issue 91] Workaround missing frames for ffmpeg

Addresses issue https://github.com/webdriverio-community/wdio-video-reporter/issues/91
Fix incomplete videos by inserting missing screenshots (copied from the last known good screenshot) before calling ffmpeg
Adopt a different helpers.sleep() strategy, this time leveraging Atomics.wait() so that it's compatible with being called via process.on
Also, revisit where allure.addAttachment() is called to help avoid the video being misassigned or
buried within multiple screenshot substeps in the Allure report.

@christian-bromann, I think all the code review items are now addressed

All good @christian-bromann !


Create a new pull request by comparing changes across

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

15 of 15 (100.0%)  changed or added relevant lines in 2 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.02%) to 95.758%

Files with Coverage Reduction
New Missed Lines
%

js/src/tooltip.js
1
95.99%

Totals

Change from base Build<PHONE_NUMBER>:
0.02%

Covered Lines:
2025

Relevant Lines:
2077

💛  - Coveralls


update pull-level to get sync option

update pull-level to get {sync: true}
which will enable solving this https://github.com/dominictarr/level-memview/issues/1 easily

I started this and thought it would be easy, but then I realized I had created a race condition, because log stream does the lookup after reading the live value.
This means that a write to a view cannot be up to date until some (async) time after the callback to the write has fired. Such behavior is not very useful for views, because we want views to be consistent.
The solution was to make a special case for createLogStream it basically does what pull-level does but it uses the log index for the old part of the stream.
This means indexes can be rebuilt in the correct order, but still keeps everything very simple!

oh looks like this is failing a test...

okay this is fixed now.

merged into 10.1.9


Open source

@sandinmyjoints
Set up for us to open source this module.
@swoloszynski @CarsonBanov

A few comments. BTY.

@sandinmyjoints Updated based on your comments, BTY

One more comment. Approved once it's addressed.


[k8s-keystone-auth] Fix authorization error

Signed-off-by: bevisy<EMAIL_ADDRESS>
What this PR does / why we need it:

Add user authorization information existence judgment
Repair request authorization error without namespace

Which issue this PR fixes(if applicable):
fixes #1308
Special notes for reviewers:

Release note:

[k8s-keystone-auth] Fix authorization error

/ok-to-test

@Bevisy please follow the template of PR (you can refer to other PRs) to fix the issue of non-label

What issue are you fixing? Could you please submit an issue for that and add that reference in the PR?
/hold

@lingxiankong
Issue link has been added, please review.

/retest

/unhold

Change looks good, please add some tests to cover the issue you are fixing.

/retest

We need to cover the test cases below to cover the issue submitted:

A user can't access the namespace scoped resources when no namespace is specified in the request.
If no users defined in a policy, the resource access should be denied.

/retest

/retest

@lingxiankong already new test cases to cover the issue.

/lgtm
/approve


Add file from iRODS fails on beta release candidate

Testing the composite resource type I receive "Validation Error: folder" when attempting to add a file from iRODS (after the resource has been created).  Note that this works on www (1.9.6) and that I am testing using a small file from data.iplantcollaborative.org.  Note that adding a file from iRODS works during the create process, but not when a resource already exists and a file is being added.

@hyi, could you take a look at this one? I'm unable to test iRODS at the moment.

@dtarb @mauriel133 I tested on beta and found this error only happens with composite resource, and works fine with generic resource. @pkdash You may take a look first to see if you can fix this issue first, since it appears to be a composite resource specific issue. Let me know if you cannot find a quick fix.Then  I can take a look tomorrow.

@dtarb Were you trying to add the file to a specific folder when you got this error?

@pkdash I tried on beta, and this happens when adding files from irods to a composite resource, not within a folder. What I did is to create a composite resource without uploading any files, then from resource landing page, login to irods and add a file to this empty composite resource, then I got an error. This does not happen to other resource types such as generic resource type. You can use hsproxy irods user account credential in local_settings.py to test and debug, should be easily reproducible.

@hyi I added some unit tests to reproduce this error. But unit tests do not fail. I am running local irods. But I don't know how to reproduce this locally using the UI. Can you give me some instructions?

@pkdash I think you can just create an empty composite resource, then login to irods using hsproxy irods account credential (if you don't already have other irods accounts) or use your irods account if you have created a corresponding iRODS account in user zone from your profile page, and browse and select any file under that irods account to add to this empty composite resource, and you should be able to reproduce this error. Have you tried this?

@hyi I tried using the information from the local_settings.py file to login into iRODS. Login failed. Then I tried to create iRODS account in my profile page. The account got created. Then when I tried to use that account to login to iRODS login failed. I am not doing something right I guess.

@hyi I was able to login using the info from settings file.

@hyi I am able to reproduce the error. Thanks for your help.

@hyi I am looking at this function.
https://github.com/hydroshare/hydroshare/blob/develop/irods_browser_app/views.py#L150
Is it not possible to upload a file from IRODS to a specific folder? I need to pass a folder parameter to the file pre_add and post_add signal call.  The file add view function that we have in hs_core allows a folder to be specified.

@pkdash I believe iRODS browser has not been updated to allow users to add a file from iRODS to a specific folder. I know the file add view function allows to do that, but we need front end UI change to specify the folder to add files from iRODS to in order to allow adding files from iRODS to a specific folder. Perhaps @mauriel133 can work with you to help with front end changes to make this happen? I don't think this can be done for release 1.10 though, so it'd be good just to fix this error and worry about adding files to specific folder later? I'll leave it up to you on what you can do for release 1.10 regarding this.

@hyi Sounds good. I will just fix the error.

tested on beta and found fixed loading files from iplant.


76 create database models

General
Created models #76
Type

ℹ  What types of changes does your code introduce?

👉 Put an x in the boxes that apply

[ ] Fix
[x] Feature

Describe the changes here (summarized)

Close because select the wrong branch.


Changed the tier text to an image/button

Replaces the "Tier ??" with a button that matches the level's tier. If the level is unrated or the data isn't fetched yet, the button sprite will be the mod icon/unrated image. All images are source directly from the GDDL Discord server.
When the button is clicked, it will create a pop-up that displays the level's tier and enjoyment up to 2 decimal precision. It will also show the total amount of submissions.
-Diversion, developer of gdladder.com

Might need to align the button to the demon face and not just the entire sprite tho

Oh my god, this is amazing

I encountered a crash while testing this, but I wasn't able to recreate it afterwards and the log didn't point to the mod being at fault so everything looks good to me, I'll merge it into main (I should add a dev branch or sth tbh) and edit about.md to mention your contributions

This was my hello world c++ project so it's entirely possible there is a bug somewhere


Feature/hadouken balancer lqty

Created nervosLiquidityFetcher, fetches additional liquidity and outputs it in aggregated_liquidity.json.

Created nervosLiquidityFetcher, fetches additional liquidity and outputs it in aggregated_liquidity.json.
simulations/runner_nervos.py now takes aggregated_liquidity as input to compute usd volume for slippage.
Validated new usd volume for slippage by comparing yokaiswap data with new aggregated data = only significant change is USDT


Machines in osx.1200.amd64.open differ in MacOS versions

macOS-12.4

dci-mac-build-103
dci-mac-build-104
dci-mac-build-107
dci-mac-build-108
dci-mac-build-109
dci-mac-build-109
dci-mac-build-110
dci-mac-build-111
dci-mac-build-112
dci-mac-build-113
dci-mac-build-125
dci-mac-build-129
dci-mac-build-129
dci-mac-build-130
dci-mac-build-131
dci-mac-build-132
dci-mac-build-134
dci-mac-build-135
dci-mac-build-135
dci-mac-build-149
dci-mac-build-149
dci-mac-build-150
dci-mac-build-151
dci-mac-build-152
dci-mac-build-153
dci-mac-build-154
dci-mac-build-155
dci-mac-build-156
dci-mac-build-158
dci-mac-build-294.local
dci-mac-build-295.local
dci-mac-build-296.local
dci-mac-build-297.local
dci-mac-build-298.local
dci-mac-build-298.local
dci-mac-build-299.local
dci-mac-build-300.local
dci-mac-build-301.local
dci-mac-build-302.local
dci-mac-build-303.local
dci-mac-build-304.local
dci-mac-build-304.local
dci-mac-build-306.local
dci-mac-build-308.local
dci-mac-build-308.local
dci-mac-build-309.local
dci-mac-build-309.local
dci-mac-build-310.local
dci-mac-build-310.local
dci-mac-build-311.local
dci-mac-build-312.local
dci-mac-build-313.local
dci-mac-build-314.local
dci-mac-build-315.local
dci-mac-build-315.local
dci-mac-build-316.local
dci-mac-build-316.local
dci-mac-build-317.local
dci-mac-build-318.local
dci-mac-build-319.local
dci-mac-build-320.local
dci-mac-build-321.local
dci-mac-build-323.local
dci-mac-build-325.local
dci-mac-build-326.local
dci-mac-build-327.local
dci-mac-build-328.local
dci-mac-build-329.local
dci-mac-build-330.local
dci-mac-build-330.local
dci-mac-build-331.local
dci-mac-build-332.local
dci-mac-build-333.local
dci-mac-build-334.local
dci-mac-build-335.local
dci-mac-build-336.local
dci-mac-build-337.local

macOS-12.6

dci-mac-build-105

macOS-12.6.6

dci-mac-build-053
dci-mac-build-054
dci-mac-build-055
dci-mac-build-057
dci-mac-build-058.local
dci-mac-build-059
dci-mac-build-068
dci-mac-build-133
dci-mac-build-136
dci-mac-build-137
dci-mac-build-138
dci-mac-build-138
dci-mac-build-139
dci-mac-build-139
dci-mac-build-140
dci-mac-build-142
dci-mac-build-142
dci-mac-build-143
dci-mac-build-147
dci-mac-build-148
dci-mac-build-169
dci-mac-build-170
dci-mac-build-170
dci-mac-build-171
dci-mac-build-171
dci-mac-build-172
dci-mac-build-173
dci-mac-build-173
dci-mac-build-174
dci-mac-build-176
dci-mac-build-177
dci-mac-build-177
dci-mac-build-178
dci-mac-build-178
dci-mac-build-180
dci-mac-build-181
dci-mac-build-181
dci-mac-build-183
dci-mac-build-184
dci-mac-build-184
dci-mac-build-185
dci-mac-build-185
dci-mac-build-186
dci-mac-build-187
dci-mac-build-189
dci-mac-build-189
dci-mac-build-190
dci-mac-build-191
dci-mac-build-191
dci-mac-build-192
dci-mac-build-193
dci-mac-build-194
dci-mac-build-195
dci-mac-build-195
dci-mac-build-197
dci-mac-build-197
dci-mac-build-198

macOS-12.6.7

dci-mac-build-052
dci-mac-build-052
dci-mac-build-212
dci-mac-build-213
dci-mac-build-213
dci-mac-build-214
dci-mac-build-215
dci-mac-build-215
dci-mac-build-216
dci-mac-build-216
dci-mac-build-217
dci-mac-build-218

macOS-12.6.9

dci-mac-build-106

Created https://portal.microsofticm.com/imp/v3/incidents/incident/427455165/summary to have DDFUN bring all these systems to macOS 12.7.

All the macs listed above have been updated to 12.7


modify generator inside fit_generator during training

Hi,
model.fit_generator takes a generator as input. This generator is used to feed the batches to train the model.
Is it possible to modify this generator during training? I am aware that some training parameters can be modified using callbacks, but it seems that the generator is not possible, am I right?
I imagine that I could create my own fit_generator but I was wondering if there is an easier way.
Thanks in advance!

If you use a keras.utils.Sequence, you can implement on_epoch_end and modify the object between the epoch.

Thanks for response Dref360, it seems to be working properly! Is it possible to access the model you are training from on_epoch_end?
I tried to read it from disk (saved using ModelCheckpoint callback after each epoch) but there are issues with both functions trying to access the file at the same time.
Thanks!

Unfortunately, the Sequence's on_epoch_end call happens in another thread so it won't be thread-safe to load the model. You could re-implement ModelCheckpoint to make it thread-safe with your Sequence object, but it would be complicated.
The Sequence API was not designed to interact with the training loop.


Contrib-ads still enters postroll mode when ima is initialized without an adTagUrl

I was trying to setup IMA without an adTagUrl so that I can reuse the player for different content (some monetized in a playlist fashion) but I kept running into the situation that the ended event was being converted to adended by videojs-contrib-ads.
I think the reason is this line:
https://github.com/googleads/videojs-ima/blob/b53876568356fed47b586631e29e35da99a0721b/src/sdk-impl.js#L533-L537
If there is no AdManager instance, the library will not tell videojs-contrib-ads to skip the postroll so it enters postroll mode and waits until the postRollTimeout period (5 seconds by default) before (re)emitting the original ended event.
My gut tells me that we should be instructing videojs-contrib-ads to skip postrolls when adsManager is null or undefined but I don't know if that would have some other consequences.

Hello @imbcmdth ,
Thanks for bringing this up. I am working on pr #979 to solve this. Seems like a pretty straight forward fix. Once I publish a new version of the plugin, please test and let me know if it resolves the issue.
Jackson
IMA SDK Team

This should be solved with the latest version of the plugin, v1.10.0.


⚠ St. Lawrence Global Observatory CKAN has degraded performance

In 81d3e48, St. Lawrence Global Observatory CKAN (https://catalogue.ogsl.ca/en/) experienced degraded performance:

HTTP code: 200
Response time: 8818 ms

Resolved: St. Lawrence Global Observatory CKAN performance has improved in f1c539f after 58 minutes.


Light advertised as Dimmable by Emulated Hue

Home Assistant release (hass --version):
0.65.5
Python release (python3 --version):
3.5.3
Component/platform:
Emulated Hue
KNX
Description of problem:
Lights are advertised to Alexa as dimmable when in fact they are not. This causes Alexa / Echo to try to set brightness when he can't. Often commands are as such not understood by Alexa.
Here is an example of http://<IP_ADDRESS>/api/pi/lights from emulated Hue
"4": {"modelid": "HASS123", "name": "Applique Salon", "state": {"bri": 255, "on": true, "reachable": true}, "swversion": "123", "type": "Dimmable light", "uniqueid": "light.applique_salon"}
Expected:
Non dimmable lights should be advertised as switchable only. Also the Alexa App should be able to control lights (it fails today).
Problem-relevant configuration.yaml entries and steps to reproduce:
  listen_port: 80
  host_ip: <IP_ADDRESS>
  expose_by_default: true
  exposed_domains:
    - light

EDIT: remove KNX piece as this is about Emulated Hue only and will do so for any type of light.

Changing to Emulated Hue impact only as after looking at the code, lights being advertised as "Dimmable" is actually hardcoded...
Line 353 'type': 'Dimmable light', from home-assistant/homeassistant/components/emulated_hue/hue_api.py
This shouldn't be the case as Alexa tries to control brightness on something that can't do that. I don't know if the API supports other values.
Thanks

Philips hue engineers confirm this is possible. Type for non dimmable lights (or switches) for instance should be 'On/off light' or 'On/Off plug-in unit'
Example of JSON are actually provided by Hue support: https://developers.meethue.com/content/whats-json-value-light-type-onoff-light
I have no knowledge of coding so can't really help, but this would be awesome.
Thanks

Commenting to keep this open.
The issue is still present (0.70.1). We should definitely make the integration better.
Thanks

By looking at the code it seems it's been implemented, however I cannot find a way to set my lights to non-dimmable. (I'm using rfxtrx lights)
That's why they appear dimmable in hue

I have this issue currently. I use to trigger a shelly over REST and of MQTT
For both types it states:
{   "modelid": "HASS123",   "name": "Schlafzimmerlampe",   "state": {    "bri": 0,    "hue": 0,    "on": false,    "reachable": true,    "sat": 0   },   "swversion": "123",   "type": "Dimmable light",   "uniqueid": "switch.schlafzimmerlampe"  }
I don't know why it is advertised as dimmable light, because there is nothing dimmable at all.


Fixing typeclass arguments (and removing syntax for array literals)

This makes typeclass arguments work more uniformly. They were previously only parsed in patterns for letbidings (so let f #a [| deq a |], etc) but not in arrow types nor val declarations.
This PR makes them work more uniformly, but requires removing the syntax for array literals, which conflicts with this one ([| a1; ...; an |]). We can of course change either syntax instead of just removing the array one, but since FStar.Array is in ulib/legacy, maybe we could just deprecate its syntax?
No strong opinion though, I would be fine with changing the syntax for tc args.
cc @msprotz @denismerigoux

I am fine with deprecating the array literal syntax, especially since this is no longer considered a prime module and no longer lives in ulib.

Thanks @mtzguido ! I didn't know you could use the OCaml-like syntax in F* to write arrays, I've never used them.

So we chatted today about this in the meeting. Arrays are indeed deprecated, but we were worried about closing the door on some possible future implementation-- it would be nice to use OCaml syntax too if we had them in the future.
How about we change typeclass arguments from [| ... |] to {| ... |}?
cc @nikswamy @aseemr

I've updated this PR to use braces for tcargs.


WIP: AKS credentials for ACR

Azure Kubernetes Service (AKS) nodes' kubelet can use the cluster's
service principal to fetch images from Azure Container Registry (ACR).
If azure.json is projected into the Flux pod, consume the service
principal credentials when authenticating to azure container registry.
Note that this method may eventually be deprecated, possibly replaced
by Managed Identity + OAuth, similar to the GCP implementation.
See https://github.com/kubernetes/kubernetes/issues/58034
Prompted by discussion with @squaremo on slack

I can confirm this is working by adding these changes to the deploy/flux:
        volumeMounts:
        xxx
        - mountPath: /etc/kubernetes/azure.json
          name: acr-credentials
        xxx
      volumes:
      xxx
      - hostPath:
          path: /etc/kubernetes/azure.json
          type: ""
        name: acr-credentials

I can confirm this is working

Splendid, thank you very much for trying it out @4c74356b41

Awesome!
Let me fix the formatting and docs....

ACR user here...
Just so I understand, does this PR remove the need to provide imagePullSecrets along with your k8s resources in order to enable the registry scanning to work?
Oddly enough, that method works for me, unlike what people are reporting in #1396.  But this method looks nicer :-)
Also, will this help with ACR Helm authentication at all?

In my experiments using imagePullSecrets doesnt work if you grant AKS permissions to ACR, so you have to strip AKS permissions on ACR and after that it will work with imagePullSecrets.
Not sure what do you mean about helm and ACR. helm is a client side tool

@4c74356b41
The SP my cluster is using has AcrPull role assignment, and I'm using a different SP (also with AcrPull) for the credentials used in the imagePullSecrets.  It seems to work.
Re: the ACR Helm thing - sorry I wasn't clear.  ACR can also host Helm charts (i.e. it's a Helm repository), but since it's private it requires authentication.
https://docs.microsoft.com/en-us/azure/container-registry/container-registry-helm-repos
I'm guessing nobody has tried this or looked at it.  I tried briefly using the method described here, but it didn't work.  It's not an urgent requirement for us at the moment so I haven't made time to investigate further.  The authentication method shown in the docs uses an OAuth token which expires after an hour, so not sure this will work.
However when using ACR as a container registry, you can authenticate directly using a service principal (i.e. with docker login), so I was wondering if this would work with the Helm repo authentication somehow.

I'm well aware of that, what I dont understand, with flux all your templates are in the repo already, doesnt matter you have them in a private repo as well? also, if you have acr pull for AKS sp it wont even use imagePullSecrets

I'm well aware of that, what I dont understand, with flux all your templates are in the repo already, doesnt matter you have them in a private repo as well? also, if you have acr pull for AKS sp it wont even use imagePullSecrets

The reason I needed imagePullSecrets was not for AKS to pull images, but for Flux to poll/scan the repositories.  Unless I'm mistaken, Flux doesn't use the AKS SP credentials to do this.
So back to the my original question: my guess is that this PR will provide those same credentials (via the host mount) to Flux, so we don't need the imagePullSecrets.  Does this sound right?
We currently have some internal Helm charts published to ACR, so I wanted to see if Flux could install those.  However we don't need to do this, rather we can just install them from Github instead.
I'm not sure what you mean by your templates are in the repo already.  What repo?  The Helm charts are in separate repos, not in the flux one.  The Flux repo only has the HelmRelease resources that reference these charts.

oh, ok. I didnt knew you can do that. I thought it needed charts in the same repo.
indeed flux doesnt use aks sp credentials (this is why this PR exists), but what I'm telling you is that the solution worked for you because you didnt have ACRpull for the AKS sp, if you did - it wouldnt.

oh, ok. I didnt knew you can do that. I thought it needed charts in the same repo.
indeed flux doesnt use aks sp credentials (this is why this PR exists), but what I'm telling you is that the solution worked for you because you didnt have ACRpull for the AKS sp, if you did - it wouldnt.

I have ACR pull on both the AKS SP and the one I use for imagePullSecrets' and everything works fine.  I guess what you're saying is you need to use imagePullSecrets` both for polling the registry and pulling images?
Before I added imagePullSecrets to my Flux resources AKS could pull images fine using the usual SP role assignment on ACR.  I only had to add it for the registry scan bit.

@squaremo corrected whitespace (via gofmt) in 3cb2179, un-Exported two methods in df5ca66, added docs to faq.md in cf30277, and plumbed hostPath mount into helm chart (disabled by default, always readOnly) in 0ce0668. I think that's all the requested changes.

@alanjcastonguay cool, didnt think about readOnly, makes a lot of sense.
@timwebster9 ok, i guess you are special :)

@alanjcastonguay This is a thorough job, thank you very much!


Release 3.5.0 prevents usage of .jsdocrc configuration files

This might well be a deliberate design decision, but I just wanted to draw your attention to the breaking change introduced in 3.5.0 around configuration file handling. Our repositories were using files named .jsdocrc to store JSON configuration for JSDoc; this worked for 3.4.x, but this commit released in 3.5.0 only allows for files with a .js or .json extension to be accepted.
You explicitly specify those extensions in the documentation now, but previously there seems to have been a reasonably widespread (if informal) convention for using .jsdocrc file. A quick search to confirm suggests there are around seven hundred mentions found, so it's likely to have a reasonable impact.
We're about to start updating our JSDoc configuration files to have .json extensions anyway, but I just wanted to make sure you were aware of this as a side effect. Regardless, thanks for your work on a very useful project!

Thanks for the heads up. I'll update JSDoc to assume that the config file is in JSON format if there's no file extension (which is the behavior we should have used in the first place).
Because there's an easy workaround for this issue, I'll wait for some more bugs to trickle in before I release a new version of JSDoc with the fix.

Cheers @hegemonic. We had jsdoc pinned to "^3.4.0", so a bunch of our CI pipelines that generate documentation have gone a little bit red on a few of our core libraries; it's something we need to workaround immediately regardless, but we figured it might save someone else some headaches further down the line!

Fixed on master and releases/3.5. The fix will be included in JSDoc 3.5.1, which I'll probably release later today.

Thanks for quick reaction!

Superbly quick turn around - thank you, @hegemonic !


Naming issue

Dear author,
the name is nice-slam,
How does the follower of this work name? Better-slam or very nice-slam?

Hi,
haha, these two suggestion sounds good!


"node" instead of "deno"

The usage of Deno there is correct, why do you propose change it to Node?


Update to latest miniz (version 2)

https://github.com/richgel999/miniz/releases
Currently this crate uses an old version v1.16, which is quite old.
See also #143.

Thanks for the pointer to the upstream release!


integrate KConfig header generation

I dived into this. See my notes under https://github.com/basejumpa/pr-review-notes/blob/main/avengineers/spl/pull-13.rst


[devtools] Add new pkg-config dependency to dockerfiles

Add new pkg-config dependency to dockerfiles
Attempting to build an image from the devtools Dockerfiles currently fails when executing ./autogen.sh.
As is documented in https://github.com/memcached/memcached/issues/932 memcached, and as such also the images, does not build without pkg-config.
The arch base image path seems to have changed - the latest image is now found under archlinux:latest.
 What process is there for this to be merged?

Sorry, you don't need to do anything. I'm just really behind on verifying patches.


This will be out-of-band, but I'm going to build and push this image to quay.io/aptible/debian:wheezy and aptible/debian:wheezy so that customers get a more friendly error message:
FROM debian:wheezy

ONBUILD RUN echo "All images based on Debian Wheezy are now deprecated. Please use Debian Jessie instead." && false


Rotation of Individual Images in PDF

Is your feature request related to a problem? Please describe.
I would like to rotate my images as some of images come rotated.
Describe the solution you'd like
A feature on the images to pdf page where I can individually rotate each image.
Describe alternatives you've considered
Manually rotating each image in my photos app but this is too time consuming and annoying.

After some investigations i can say that for now there is only a way just rotating needed pictures manually


Call expression's leading comments are removed when assigned to a explicitly typed variable

The leading comment of a call expression should be kept when removeComments: false. And indeed, it is kept in the majority of cases, except when it is in an assignment statement that also has an explicit type annotation.
My use case for this is to keep /** @__PURE__ */ annotations in some assignments that are side-effect free, so terser and uglify can remove them if unused.
There are some similar issues here already but they are closed and I suspect this is an edge case that was not accounted for.
TypeScript Version: 4.1.0-dev.20201005
Search Terms:  comments, pure, annotation, uglify
Code
const var1 = /* comment1 */ foo(bar);
const var2: any = /* comment2 */ foo(bar);

Expected behavior:
const var1 = /* comment1 */ foo(bar);
const var2 = /* comment2 */ foo(bar);

Actual behavior:
const var1 = /* comment1 */ foo(bar);
const var2 = foo(bar);

Playground Link: https://www.typescriptlang.org/play?ts=4.1.0-dev.20201005#code/MYewdgzgLgBAbgQwE4EYYF4YHoBUNQC2BApmFGjljAGYggAUARsgJQDcAUKJLIkgEwAuGAjABPDNjyESZfjEo06TVpyA
Related Issues: #17606 #16727

function foo(x: number = /* comment1 */ 1, y = /* comment1 */ 1,) {
}

// .js
"use strict";
function foo(x = 1, y = /* comment1 */ 1) {
}

Playground

The same issue with the parameters
function foo(x: number = /* comment1 */ 1, y = /* comment1 */ 1,) {
}

// .js
"use strict";
function foo(x = 1, y = /* comment1 */ 1) {
}

Playground
https://github.com/microsoft/TypeScript/blob/14c731689ed37b8d100b8325d0e9c21dc4659de3/src/compiler/emitter.ts#L2897-L2898
ʻEmitter.tsshouldn't print thetype annotation, so the type property is in ʻundefined. The node has original property (node was updated), which refers to the original node with the type, not sure, maybe make sense to try to get the end position from it. Or is it useless?
node.type ? node.type.end : getOriginalNode(node, isVariableDeclaration).type?.end || node.name.end

@weswigham @rbuckton What do you think?

The same issue with the parameters
function foo(x: number = /* comment1 */ 1, y = /* comment1 */ 1,) {
}

// .js
"use strict";
function foo(x = 1, y = /* comment1 */ 1) {
}

Playground
https://github.com/microsoft/TypeScript/blob/14c731689ed37b8d100b8325d0e9c21dc4659de3/src/compiler/emitter.ts#L2897-L2898
emitter.ts shouldn't print the type annotation for this case, so the type property is undefined. The node has original property (node was updated in transformers), which refers to the original node with the type, not sure, maybe make sense to try to get the end position from it. Or is it useless?
node.type ? node.type.end : getOriginalNode(node, isVariableDeclaration).type?.end || node.name.end

@weswigham @rbuckton What do you think?


11910 builder issue

Related ticket in Builder: https://github.com/CartoDB/cartodb/issues/11910.
Trying to fix the problem above ^^^, we discovered that action parameters were not working properly when a layer was added or removed. So we have reviewed that and here we go!
CR: @alonsogarciapablo

VAAAAMOS!


Get game state from contract

Task
Implement a getter function to retrieve the current game state (board incl flags, players, winner).
Associated story
Story: #39

In completed, but no pull request?

code doesn't work, but is fixed in branch 'feature/chessboard-frontend'.

TODO: Add better for documentation for flags to the Wiki (espacially return values)

Is this still open? We have these functions now.

TODO: Add better documentation for flags to the Wiki (espacially return values)

Still missing

I see. @lisasi could you do that? :)


Feature backend/453 load base data

This pr closes #453.

Seems good to me! Good work again Kasper! Could you just provide a little doc in this PR why you chose to change the Id generation type.

By setting the id generation type to identity, we let postgres generate the id's instead of spring. This makes it possible for us to insert data using the data.sql file without manually needing to specify id's.


Upgrade Resource Detector version in Distro

Description
Upgrade Distro to new VM Resource detector. Requires OTel 1.21/0.42b0 and exporter 1.0.0b21.
Relies on https://github.com/Azure/azure-sdk-for-python/pull/33865
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

API change check
API changes are not detected in this pull request.


[Bug] [doc] The configuration of truncate is not supported when save mode is update, but it's written on the doc

Search before asking

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

What happened
The configuration of truncate is not supported, but it's written on the doc
SeaTunnel Version
2.0.5-snapshot
SeaTunnel Config
none

Running Command
none

Error Exception
none

Flink or Spark Version
No response
Java or Scala Version
No response
Screenshots
No response
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Fixed #1412


Add dynamic Sku and compute mode. Add accepted as option for swapslot

Hi @naveedaz, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

It looks like you're working at Microsoft (naveeda). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;


Make code a bit more PEP8 compatible

Would be great if the code could be a bit more PE8-friendly, having static-checkers and PyCharm not warn on too many lines.
BTW, i already have this ready and would love to push it as a PR for you to review/pull if you want. At the moment your Repo is locked for pushing new branches/PRs :(.

See #4 .

See #4 .


Background Job for Desktop app

Is there a way to do Background job for fetching data from Rest Service .?

Hi @VarmaTech
This issue doesn't seem to describe a bug or a feature request. Please see https://flutter.dev/community for resources and asking questions like this,
you may also get some help if you post it on Stack Overflow and if you need help with your code, please see https://www.reddit.com/r/flutterhelp/
Closing, as this isn't an issue with Flutter itself. If you disagree, please write in the comments and I will reopen it.
Thank you


always failed at 	err = unix.Connect(s, remoteSocket)

Do you have any document about your project?
I have read your codes, but I don't understand, Thanks.
Now I always fail a go-linux-tproxy.go:200

@jannson Hey, I do not have any special document since it's an advanced subject. While I am not that expert I do not understand where do you get the error from since my code doesn't have line 200 in it..
But you should know that the code requires couple things from the linux kernel.
If you can gist some of your code and also the details about your linux machine it would be pretty good to understand it.

Sorry, I changed your code and I forgot it. I will test it again in a VPS and give your more information about my environment.
Thank you for reply.

#jDepends on your VPS you might not have the required kernel modules for example AWS Linux doesn't have anything that supports tproxy but you can use Ubuntu on AWS which contains tproxy support.
For other providers you would need to verify the list of modules or kernel core to know that.
You can use "panic(err)" and print the backtrace.
Also

Of course, If I fix some bugs and make it work, I will share all about code. But now I just use your code, and I don't understand more about tproxy, so it can not work now. I think your code is ok.
My big goal is make udp redirect  work in tproxy by using golang, than my ps4 can use a udp proxy to play games.
Now I am creating a VPS in linode using ubuntu. I will check it out later.

My evironment:
A: The server running tcpproxy1, ip: <IP_ADDRESS>, ubuntu 14.04, linode, golang 1.5.2 from official website
B: The client just for test, centos 6.4
Idea of test is:

Run a tcp echo server at A by <IP_ADDRESS>:8080, any connection to the echo server, the echo server will print information of connection
Catch all :8080 to tproxy by command: iptables -t mangle -A PREROUTING -p tcp --dport 8080 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 9090
tcpproxy1 run at <IP_ADDRESS>:8080
setup a http_proxy at B and use curl to request, than request will connect to  <IP_ADDRESS>:8080, which catch by tproxy, then tcpproxy1 send request to echo server, at last echo server print the info of connection.

B:
export http_proxy=http://<IP_ADDRESS>:8080
curl -XGET http://aria2.me
echo server is: https://gist.github.com/jannson/26cbc1f03e3ae0dc0545
tproxy.sh:
echo 1 >/proc/sys/net/ipv4/ip_forward
iptables -t mangle -N DIVERT
iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
iptables -t mangle -A DIVERT -j MARK --set-mark 1
iptables -t mangle -A DIVERT -j ACCEPT
ip rule add fwmark 1 lookup 100
ip route add local <IP_ADDRESS>/0 dev lo table 100
iptables -t mangle -A PREROUTING -p tcp --dport 8080 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 9090
Steps :
Run tproxy at A host
Run echo server
Run tcpproxy1
Set http_proxy at B host and make request
The log of B:
root@li562-220:~/workspace-go/src/github.com/elico/go-linux-tproxy/examples# ./tcpproxy1 -d=1 -l=:9090
Maximum FD per process: {1024 4096}
starting connection from: <IP_ADDRESS>:41561, to: <IP_ADDRESS>:8080
Before peeking
216
This is probably a PROXY connection
After peeking
<IP_ADDRESS>:41561
<IP_ADDRESS>:8080
starting connection from: <IP_ADDRESS>:41571, to: <IP_ADDRESS>:8080
Before peeking
connection timed out
remote dial failed: %v
connection timed out
echo server has nothing log, means that nothing connection is request to echo server.

The timed out maybe occur at line of go-linux-tproxy.go
180         err = unix.Connect(s,remoteSocket)
Please give me your email, and my email is<EMAIL_ADDRESS>I'll send you my root/password of the linode server, if you need it for more information.
Thanks for your great project ^.^

I will send you an email.. but it is not clear to me yet why are you using tproxy?

Check your email please :)

My test is wrong, and here is some information:
http://wiki.squid-cache.org/ConfigExamples/UbuntuTproxy4Wccp2


Mounted App this.get('root') == '/'?

Maybe it's too early for bug reports regarding express 3.x but I found that the root of a mounted app doesn't seem to add the route name (as defined by this code).
This has the side effects that the view lookup requires me to 'hard code' the view paths of the mounted app.
See this little test:
var express = require('express')
  , assert = require('assert');

var child = express();
child.mounted(function(parent){
  assert.equal(parent.get('root'), '/')
  assert.equal(this.route, '/child')
  assert.equal(this.get('root'), '/child') // => AssertionError: "/" == "/child"
})

var parent = express();
parent.use('/child',child)

But I'm uncertain if this is the expected behaviour, in which case you can just close this issue...

Another side effect I just noticed is that res.redirect() does not work as advertised either.
Also, if an app is nested further it's still set as '/', as this test shows:
var express = require('express')
  , assert = require('assert');

var grandchild = express();
grandchild.mounted(function(parent){
  assert.equal(this.route, '/grandchild')
  // assert.equal(parent.get('root'), '/child') // => AssertionError: "/" == "/child"
  // assert.equal(this.get('root'), '/child/grandchild') // => AssertionError: "/" == "/child/grandchild"
})

var child = express();
child.mounted(function(parent){
  assert.equal(this.route, '/child')
  assert.equal(parent.get('root'), '/')
  // assert.equal(this.get('root'), '/child') // => AssertionError: "/" == "/child"
})
child.use('/grandchild',grandchild)

var parent = express();
parent.use('/child',child)

it's not done

closing for now i have a different issue open for this


Height Stuck at 0

Not sure what to say about this. The test version from a few days ago had the same issue. We may be without a timelord.

Nothing else happens

The timelord has been running but the challenge stops every 10-20 mins, no idea why...

If you are running the fast algorithm, its very unstable.
Also, you should be running a i9 9900k at a minimum for the TL.

If you are running the fast algorithm, its very unstable.
Also, you should be running a i9 9900k at a minimum for the TL.

I have AMD Ryzen Threadripper 3960X

You can make discord comunity ?

If you are running the fast algorithm, its very unstable.
Also, you should be running a i9 9900k at a minimum for the TL.

I have AMD Ryzen Threadripper 3960X

Windows 10

If you are running the fast algorithm, its very unstable.
Also, you should be running a i9 9900k at a minimum for the TL.

I have AMD Ryzen Threadripper 3960X

Windows 10

Afaik, windows TLs don't actually work as the vdf generating timelords.

Вс, 11 июля 2021 г. в 15:24, inan0812 @.***>:

If you are running the fast algorithm, its very unstable.
Also, you should be running a i9 9900k at a minimum for the TL.
I have AMD Ryzen Threadripper 3960X
Windows 10
Afaik, windows TLs don't actually work as the vdf generating timelords.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Kale-Network/kale-blockchain/issues/13#issuecomment-877790734,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUN7MCG3GKSBRNGIZNUTP4TTXGEQTANCNFSM5AEWYWUQ
.

does it mean that your program does not work on windows?

Thank you for sharing, will try to add another powerful TL.

Вс, 11 июля 2021 г. в 15:24, inan0812 @.***>:
If you are running the fast algorithm, its very unstable. Also, you should be running a i9 9900k at a minimum for the TL. I have AMD Ryzen Threadripper 3960X Windows 10 Afaik, windows TLs don't actually work as the vdf generating timelords. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUN7MCG3GKSBRNGIZNUTP4TTXGEQTANCNFSM5AEWYWUQ .
does it mean that your program does not work on windows?

No, chia never finished implementing windows timelords.

The chain is running now. Thank you guys again for sharing and supports. The discord channel will be available later. Feel free to reopen this issue and start a new one.


Are related posts being used?

Force/martsy have been completely migrated to use the new Articles/Positron infrastructure, over gravity's posts.
I am in the process of removing all post code and associated API's from Gravity, and noticed in Papertrail that something is still requesting 'related posts'.
The API call is something like /api/v1/related/posts?artist[]=vito-acconci . Is that happening from Eigen? I can't tell from the logs, somehow the UserAgent isn't listed.

Yes it is, https://github.com/artsy/eigen/blob/828a695838b2a536d27e068ae5589b4ba529620c/Artsy/Classes/View Controllers/ARArtworkViewController.m#L129 and https://github.com/artsy/eigen/blob/95b4473388dead96a6d48e02b88a53a3f94a1f19/Artsy/Classes/View Controllers/ARArtistViewController.m#L200.

Oy vey.
@orta @craigspaeth - how/can/who should update Eigen?

Removing it completely means that Eigen 1.8 will no longer function for 100%, which is the last version to target iOS 7 (and thus some devices). It shouldn’t stop working, but finding related work is a central feature, so that needs to be given some thought as to whether or not we find this ‘legacy’ support important.

Hmm, to just keep that API around for you, it might suffice to rip out everything we were intending, and do a redirect to the related Positron url? That definitely seems really hacky, and Eigen would have to be able to follow redirects.
Would returning a 404 (or worse, some sort empty array/response) be alright? Effectively removing the functionality but not in a 'breaking' way.
I haven't been too involed in posts/articles, but just in case this endpoint/issue was overlooked I opened https://github.com/artsy/eigen/issues/432 to switch to articles, since I think that's the new standard.

After thinking it over for a bit, reading through the source, and testing the app out without related posts, I think this is fine. There's very little impact in discovering artworks, which is the more important part, so :+1:
The only current issue is sprint planning. Is there need to remove it now or is another ~8 weeks a possibility?

We can definitely wait to remove server-side Post stuff, as it's part of a more general clean up effort, but if it's ok to return either a 404 or en empty response (whichever), we'd probably do that and remove stuff sooner.

@mzikherman Ok that sounds good. So to summarise, it will keep working for a bit more and then to conclude the general cleanup the endpoint will 404. :+1:

moving any further discussion to #432.


C++11 as new minimum language standard. No turning back.

C++11 means that our new minimum compiler requirements are:

clang >= 3.4, and using -std=c++11
gcc >= 4.8, and using -std=c++11
MSVS 2015 or newer

No more USE_CPP11 option.
We also allow C++14 compilation (make USE_CPP=14) and test it in Travis. (Note that we changed the name in order to be better positioned for new standards.)
Needless to say, this is master (future 1.8), and will not be backported to RB-1.7. The 1.7 family of releases will continue to be buildable as C++03.

LGTM!


[release-1/starbucks] fix(filebeat): update filebeat version to v6.8.6

What this PR does / why we need it:
Add your description
Which issue(s) this PR is related to (optional, link to 3rd issue(s)):
Fixes #
Reference to # https://github.com/caicloud/prod-issue/issues/1130

Special notes for your reviewer:
/cc @your-reviewer

Release note:

NONE

/cc @lichuan0620

/lgtm


Group & Scene error - Hassio / Kodi  TV error

 is a comment.
You will see these throughout the issue template. Make sure you do not type your comments
between these characters or we will not be able to see what you wrote!

4. Links
To create a hyperlink, type the [text you want to link](followed by the url in parenthesis)
-->
Describe the bug
I am trying to sync the lights I have configured in HASSIO to be used under KODI using the HUE integration that both have.

Steps to Reproduce
Installing a clean version of stable or develop on Home Assistant 2021.8.8 on a RPi4.
Trying to manually add the HUE integration in HASSIO, when activating the link mode I always get an "Unexpected error".
The same on KODI TV 19.1 I install Hue Service and end up with a common message "Hue bridge not found".
Other times it just works and discovers the bridge on both sides but the integration starts duplicating objects and my 9 lights (lifx and xiaomi) end up turning out to be over 500.

Expected behavior

Logs
021-08-24 21:30:33,519 DEBUG emulated_hue.api -- [<IP_ADDRESS>] GET /api/aEe56Ad6C446F4f6fbC304acf11F7dbD88D5DA73/
2021-08-24 21:30:33,590 ERROR aiohttp.server -- Error handling request
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/aiohttp/web_protocol.py", line 422, in _handle_request
resp = await self._request_handler(request)
File "/usr/local/lib/python3.9/site-packages/aiohttp/web_app.py", line 499, in _handle
resp = await handler(request)
File "/app/emulated_hue/api.py", line 92, in wrapped_func
return await func(cls, request)
File "/app/emulated_hue/api.py", line 494, in get_full_state
"scenes": await self.async_scene_to_full_state(),
File "/app/emulated_hue/api.py", line 478, in async_scene_to_full_state
scenes_group = scene_data["group"]
KeyError: 'group'

Hardware Info:

Architecture (Ex: x86, ARM):
Addon version (Ex: stable or dev):

Value of "tag_commit_or_branch" if using dev:

OS (Ex: Windows 10, Ubuntu Buster):
Hardware (Ex: PC, Raspberry Pi 1/2/3/Zero):

Additional context

It is obviously going to duplicate things in Hass if you add the emulator because the emulator gets the lights from Hass. So you created an infinite loop.

That makes more sense... adding just the HUE bridge in KodiTV I still have errors.
2021-08-24 22:28:01,910 DEBUG emulated_hue.api -- {'lights': ['1'], 'name': 'HOME_THEATER', 'recycle': False, 'type': 'LightScene', 'transitiontime': 100}
2021-08-24 22:28:06,594 DEBUG emulated_hue.api -- [<IP_ADDRESS>] GET /api/config
2021-08-24 22:28:06,600 DEBUG emulated_hue.api -- [<IP_ADDRESS>] GET /api/B119D4Cb97D90F3f2a1C3c8FDce8eb6266cA8Db2/config
2021-08-24 22:28:06,680 WARNING emulated_hue.api -- Invalid/unknown request: <Request GET /api/B119D4Cb97D90F3f2a1C3c8FDce8eb6266cA8Db2/sensors/1> >
2021-08-24 22:28:08,801 DEBUG emulated_hue.discovery -- Serving SSDP discovery information to ('<IP_ADDRESS>', 55940)
2021-08-24 22:28:34,385 DEBUG emulated_hue.discovery -- Serving SSDP discovery information to ('<IP_ADDRESS>', 5464)
2021-08-24 22:28:34,386 DEBUG emulated_hue.discovery -- Serving SSDP discovery information to ('<IP_ADDRESS>', 5464)
2021-08-24 22:29:08,802 DEBUG emulated_hue.discovery -- Serving SSDP discovery information to ('<IP_ADDRESS>', 55940)
2021-08-24 22:32:09,869 DEBUG emulated_hue.api -- [<IP_ADDRESS>] GET /api/config
2021-08-24 22:32:09,908 DEBUG emulated_hue.api -- [<IP_ADDRESS>] GET /api/B119D4Cb97D90F3f2a1C3c8FDce8eb6266cA8Db2/config
2021-08-24 22:32:09,982 WARNING emulated_hue.api -- Invalid/unknown request: <Request GET /api/B119D4Cb97D90F3f2a1C3c8FDce8eb6266cA8Db2/sensors/1>.

#50


⚠ Bofrost.be has degraded performance

In 8218842, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1192 ms

Resolved: Bofrost.be performance has improved in 8d5a67c after 8 minutes.


Design Spec

I propose that we write a design spec in Google Docs where features and standards for v1 can be discussed and documented easily. @heldyboy @brandonbarry123 @peterbogdan @Melvin-Thomas-Dev what do you guys think?
Right now it's really hard for new contributers to dive in, as there's no clear documentation. The projects are a great start but it makes sense to formalize some things.
IMO, the doc should include stuff like

the routes

e.g. /user/<userid> or /chapter/event/<eventid>
this needs some thought as we should stay consistent over time and prevent dead-ends in the future
dedicated API routes to fetch data or authenticate with other systems

database models

should be concretely defined
right now contributers have to dive into the branches to find out how our models look like

proposed tech stack for core tech

database (postgres, mongo, neo4j?)
containerization with docker
caching (redis)
webserver (nginx, apache)

hosting and server setup

what service providers could we use?

there's a bunch of really good cheap ones, like netcup

email stuff

templates

register
reminders for events?

what services could we use?

e.g. AWS SES is the cheapest and also the most developer-friendly option imo

cronjobs

Of course we would split this up into multiple documents as the project grows but for now I think a single document definitely makes sense to form consensus on some important decisions and help new contributers (or old ones like myself) to get a clearer picture of the project.

I agree with this, maybe we can discuss it in the next meeting?

Really good idea.. we have some existing cards to define items (i.e. roles, databases), where the output of those really needs to belong in a design document. Is this something you could help me with @chrsengel?
BB

@brandonbarry123 Sure! I also talked to John and had a look at the existing docs in the drive. There's good stuff already. I'll also participate in the call on Wednesday :+1:


Suggest separate parameters for diffuse and metal colours instead of "base_color"

In the OpenPBR specification, the diffuse albedo and the metallic F0 both share the base_color parameter, with base_metalness providing the control to mix between the dielectric-base and metal substrates.
We have found it to be useful to have these parameters specified independently as we typically paint these maps separately. Having them shared would make it difficult for us to use OpenPBR.
When Brent Burley chose this parameterisation, his aims were to make a simpler interface for BSDFs, primarily targeted at feature animation pipelines. We have found that for photo-realistic look development, having control of the diffuse separately from the metallic specular gives more artistic control.
Having these colours linked was one of the main barriers that prevented us from adopting Autodesk Standard Surface internally, as well.
Would it be possible to break base_color into metal_color and diffuse_color?

It must be true that the existing approach with a single base_color is less expressive than having separate colors, since obviously both the metal and diffuse base albedo must be scalar multiplies of this single color. If this impacts the ability to use the model for certain assets, that seems really serious to me.
So in principle I'm in favor of changing this. Just I wish we had thought about this earlier as it's quite late to make such a change.
I'm wondering what the minimal change we can make to the parameter set is to achieve it.
Possibly keeping base_color to mean non-metal base color, and adding a new parameter base_metal_color? If metalness is zero, in the UI this could be greyed out. At least then we are only adding 1 new parameter, with obvious meaning, that is consistent with the existing prefixes.

I noticed this slide in the Unreal Substrate presentation. Is this "metalness limitation" the same issue?

To test the effect of constraining the metal and diffuse base colors to be equal, I did renders with OpenPBR of "rust on top of shiny metal" in two ways:

by making the base_color a blend of blue/rust weighted by metalness
by altering the shader so that the metal F0 color (blue) is independent from the diffuse color (rust)

In both cases the specular_weight is driven by the base_metalness, so that the rust has a diffuse look.
The resulting renders are below.  It seems the blending does have a fairly obvious effect in this case, i.e. it creates a halo around the rust, instead of a crisp transition:

Base blend
Separate diffuse/metal-F0

The base_metalness map used is close to a binary map, so the intermediate metalnesses (where the halo occurs) are presumably only due to texture filtering  (in this case, though a map with larger areas of intermediate metalness is allowed of course in theory).

It seems there isn't any way to effectively get the version of the render without the halo currently in OpenPBR. This could be an issue in practical cases, since this use case of rendering a blend of diffuse on metal must be quite common (for e.g. rusty/painted metal) and the halo may not be wanted.
That said, there are other cases where such a halo occurs due to texture filtering (e.g. sharp transitions in roughness), so it could  be considered to be a limitation fixed by higher texture resolution.
If we want to fix this, we need to be careful since we don't want to over-complicate the shader. We certainly don't want to disturb the very common "metalness" PBR workflow, where the base color is explicitly designed to contain both the dielectric and diffuse colors. (Which is obviously standard in various asset libraries etc.).
A possible approach then would be to add a specific override section for separate control over the metal F0, which would be opt-in (i.e. disabled by default). This could amount to a new metal_override checkbox (defaulting to off) and metal_color parameter (the particular names can be debated obviously).  They could be seen as more advanced parameters for cases needing specific control over the metal F0 independent of the dielectric base. This would be minimally disruptive since it is strictly additive to the current model, and makes no difference by default. Though as noted, this does add some complexity to the parameter set, so we need to discuss it and agree it makes sense before moving forward.
We should also think about whether there are other such limitations introduced by the parametrization, that could similarly cause problems. For example to get the renders above, I had to make specular_weight equal to the base_metalness,  as we want it to be 1.0 for metal, but 0.0 for dielectric, so the "rust" looks diffuse not shiny.  In the transition region though, we will unavoidably get a blend of shiny metal and "shiny rust". Fixing this could be as simple as stipulating that if metal_override is on, the specular_weight does not apply to the metal (or alternatively, adding a metal_specular parameter).

I was aware of this limitation of the metal-roughness parametrisation, but I thought this was a generally accepted caveat.
If this happens to be a barrier to adoption, we should indeed address it, but remain very careful of not introducing another barrier (additional complexity and/or rendering cost) to other users in doing so.
I agree with your observations, and a strictly override type of control could be a solution indeed. That being said, it's not obvious how to define such a solution. In comparison, the F-82 tint model for example has the benefit of behaving like a Schlick model with a default value that makes sense with regard to that behaviour.

@andre-ilm
For an extension to OpenPBR to allow for the use cases you describe, a minimal suggestion is to add parameters:
metal_override      // opt-in, false by default
metal_weight        // metal F0 multiplier
metal_color         // metal F0 color
metal_edge_tint     // metal F82 tint

Where metal_override is false by default, in which case all the metal_ params are ignored, and the metal is driven by F0=base_weight * base_color and F82-tint=specular_color as usual. (base_metalness drives the mix weight of the metal in all cases).
Would that be sufficient for the model to be usable in your studio, in your view?
It could be argued that if we do that, we might as well add these as well, so the metal roughness/NDF is independent from dielectric also:
metal_roughness
metal_anisotropy
metal_rotation

So basically completely decouple the metal properties from the dielectric base (only if opted-in).
This would be strictly additive to the current model, i.e. it behaves exactly the same as now unless metal_override is enabled. It would be artistically intuitive I think as it just makes the control over the metal more explicit and lifts a constraint. (Indeed some artists may prefer to always work with the metal override on?).

What it does is pretty trivial to implement, though it does add parameters and checks which has some perf/memory cost (perhaps fairly negligible if opted-out though?).
Or is there some other scheme you can think of that would achieve what you need?

Same experiment with a metalness map that has a more gradual transition. In this case, the result with separate metal and base looks like the rust "thinning" in the transition region (i.e. partial coverage of the rust),  while the blend alters the brightness in the transition which looks considerably less realistic (as a rusty metal).

Base blend
Separate diffuse/metal-F0

By the way, I think metal_weight would need to be an overall multiplier of the metallic Fresnel, not just the F0. As otherwise there is no way to completely turn off the metal reflection (as making both the F0 metal_color and the F82-tint metal_edge_tint black does not turn off the grazing Fresnel).  We will say the same about specular_weight.

@portsmouth All of your reasoning makes sense. Thanks for thinking about this in depth.
I have a few questions about the details of your proposals.

It could be argued that if we do that, we might as well add these as well, so the metal roughness/NDF is independent from dielectric also:

Is there evidence that this would also be useful to eliminate artifacts? If not, it would be nice to avoid adding these parameters because they complicate the implementation. Specifically, when all specular lobes share an NDF, they can be implemented as a single microfacet surface with a reflection/transmission coefficient that takes both the dielectric and metal properties into account (which is done in the current Adobe implementation for example).

metal_weight

What would be the purpose of adding a metal_weight parameter? Could base_metalness be used for the same purpose? If metal_weight is a more consistent name, could we simply rename base_metalness to metal_weight? That new name might suggest that metal is not part of the base but instead a separate component, however that actually seems more consistent with transmission and transmission_weight (which also share the same NDF).
Considering all of this, my tentative modified proposal would be this:

rename base_metalness to metal_weight
add metal_override (bool, false by default)
add metal_override_color
add metal_override_edge_tint

+1 to keeping a single NDF for now
I like the metal_weight idea too, it does seem more consistent with transmission.

Is there evidence that this would also be useful to eliminate artifacts? If not, it would be nice to avoid adding these parameters because they complicate the implementation. Specifically, when all specular lobes share an NDF, they can be implemented as a single microfacet surface with a reflection/transmission coefficient that takes both the dielectric and metal properties into account (which is done in the current Adobe implementation for example).

For example, the case of rust on shiny metal, where the rust is represented as a "glossy-diffuse" dielectric with a rough spec.
In the transition region between the metal and rust, the roughness has to ramp from some low value to high value. So in the middle of the transition band, with a single NDF we get a 50-50 blend of medium roughness metal and dielectric (i.e. the metal and dielectric are constrained to have the same roughness). That will look different to the result of a 50-50 blend of the totally smooth metal and the rough dielectric.
I don't have a render (we should do some), but I expect it looks similar to the halo artifact due to tying the base colors, though possibly a bit more subtle since it will only affect the spec. If it's subtle enough, we might consider it reasonable to avoid the extra parameters. My thought was just that if we're decoupling the metal, we might as well decouple all its properties to fully avoid these artifacts.
If you're implementing the base as a single microfacet model sharing an NDF, I think it would be valid as an approximation to just blend the metal and dielectric roughnesses internally. At least then you're making a renderer-specific choice to ignore this roughness blending artifact, rather than us requiring all renderers to make that approximation.

What would be the purpose of adding a metal_weight parameter? Could base_metalness be used for the same purpose? If metal_weight is a more consistent name, could we simply rename base_metalness to metal_weight? That new name might suggest that metal is not part of the base but instead a separate component, however that actually seems more consistent with transmission and transmission_weight (which also share the same NDF).

I like the metal_weight idea too, it does seem more consistent with transmission.

 As without it, setting both metal_color and metal_edge_tint to zero doesn't kill the grazing highlight (i.e. Fresnel still goes to 1 at the edge). As per the discussion in the current PR #157  here.

I think it's clearer to retain the top-level "base" section, which is the default convenient way to control both metal and dielectric color in one place, i.e.:

base_weight:  overall kill factor of base metal/dielectric at non-grazing
base_color: color of base metal/dielectric at non-grazing
base_color: overall roughness of base metal/dielectric
base_metalness: transition between the very different Fresnels of metal/dielectric

I would not want to mess with that basic, well-known parametrization.
I prefer to reserve the metal_ parameters only for the more advanced, non-default workflow where the rule is simply that the metal BRDF completely ignores the specular_ params in favour of the corresponding metal_ ones.
Then the change is strictly additive to the current model, and could reasonably be hidden away in an "advanced" rollout or tab. It could also reasonably just be a no-op or omitted in an implementation, which will fall back to the current behaviour (i.e. metal_override is just always false).

Technically the metal_weight is needed to be able to kill the metal lobe completely to zero (as mentioned in a https://github.com/AcademySoftwareFoundation/OpenPBR/issues/140#issuecomment-2023817200above). As without it, setting both metal_color and metal_edge_tint to zero doesn't kill the grazing highlight (i.e. Fresnel still goes to 1 at the edge). It would be the analogue/counterpart of specular_weight...

Makes sense. However it seems like base_metalness and metal_weight are redundant and that metal_weight could be used for both purposes.
For now, should we at least consider renaming base_metalness to metal_weight and considering the Metal component to be separate from the Base component?
That would leave the door open for adding more metal_ parameters in the future without changing the current behavior. It could also reduce the confusion about the base_roughness not affecting metals.

However it seems like base_metalness and metal_weight are redundant and that metal_weight could be used for both purposes.

WIth the proposed override parametrization, you need both the metal mix weight (called base_metalness currently), and an overall weight for the metal lobe to be able to kill the lobe (what I called metal_weight).
So I don't see how we could rename base_metalness  to metal_weight, unless we rename metal_weight to something else (metal_tint perhaps?).
I see the point on the naming convention, but it does roughly follow the idea of the material structure (as in the diagram above) composed of:

a base "substrate", composed of a mixture of metal and dielectric. The base_metalness is the mix weight which defines the area fraction of metallic base and dielectric base.

the dielectric base is further composed of a "translucent base", and an "opaque base". The transmission_weight is the mix weight which defines the area fraction of translucent base versus opaque base.

opaque base is a mix of subsurface, and diffuse (both embedded/bounded by the dielectric base).

I think in that picture, "base metalness" makes sense as a name. base_color * base_weight controls both the metal F0 and the diffuse albedo, being the color one sees if the medium is opaque.  This color/metalness parametrization was designed (I assume) to correspond to the standard metalness/metallic workflow.
Agreed that base_roughness is a bit out of place, since this only applies to the diffuse lobe (being the Oren-Nayar surface roughness). While the specular_roughness controls the NDF of both the metal and dielectric base. (This would need to be overridden by metal_roughness, if we do the override).
Arguably, base_roughness could be rebranded as e.g. diffuse_roughness, but it would be a bit strange to have a single parameter with the diffuse_ prefix. Better would be base_diffuse_roughness which makes it explicit that this controls only diffuse. We're discussing the rough diffuse model on Slack, and it seems that the effect of base_roughness is quite useful to add a more realistic "flat" dusty diffuse look, but only if energy-compensation is added to the Oren-Nayar model, otherwise it tends to just darken the material too much.
Lambert:

Uncompensated Oren-Nayar:

Compensated Oren-Nayar:

Apologies again for taking so long to get this published. Production pressures aren't giving me much time to spend on this:
Overview
The suggestion we have isn't very different from @portsmouth's suggestion above in regard to decoupling.
Where ours differs, is that instead of having a metal_override parameter, we pull the base_color/base_metalness behaviour out into a separate sub-network that can optionally drive the new interface. This shouldn't be too difficult and it would allow people to keep the older interface, if necessary, but the new surface definition wouldn't carry around this history directly.
Details
Currently base_metalness mixes between the metallic and dielectric bases.
Referring to the MaterialX underpinnings we have (roughly):
dielectric base (base_metalness = 0)

oren_nayar_diffuse_bsdf
weight    = base_weight
color     = base_color
roughness = base_diffuse_roughness

dielectric_bsdf
tint      = specular_color
roughness = open_pbr_anisotropy(specular_roughness, specular_roughness_anisotropy)
ior       = modulated_eta(specular_weight, specular_ior, coat_ior)

metallic base (base_metalness = 1)

generalized_schlick_bsdf
color0    = base_weight*base_color
color82   = specular_weight*specular_color
roughness = open_pbr_anisotropy(specular_roughness, specular_roughness_anisotropy)

We would like to propose the following changes:
Renamed parameters:
base_metalness         → metalness
base_weight            → diffuse_weight
base_color             → diffuse_color
base_diffuse_roughness → diffuse_roughness

New parameters:
metal_weight
metal_color
metal_edge_color
metal_roughness
metal_roughness_anisotropy

With the following parameters driving the lobes, (*) denotes the changes:
dielectric base (metalness = 0)

oren_nayar_diffuse_bsdf
weight    = diffuse_weight (*)
color     = diffuse_color (*)
roughness = diffuse_roughness (*)

dielectric_bsdf
tint      = specular_color
roughness = open_pbr_anisotropy(specular_roughness, specular_roughness_anisotropy)
ior       = modulated_eta(specular_weight, specular_ior, coat_ior)

metallic base (metalness = 1)

generalized_schlick_bsdf
color0    = metal_weight*metal_color  (*)
color82   = metal_weight*metal_edge_color (*)
roughness = open_pbr_anisotropy(metal_roughness, metal_roughness_anisotropy) (*)

Justification
Our thinking is that this new interface will make more sense from the point of view of surface definition since the parameters will now map to the underlying lobe topology more directly, which should hopefully lead to less confusion and more artistic control. Putting the existing base_color / base_metalness parameter mixing behaviour into a separate sub-network will give those who desire this parameterisation the option to use it, without compromising the principals of the underlying model. These changes would also give ILM the confidence to adopt it for lookdev internally, and based on our experiences exchanging assets with external vendors, it should make that easier as well.
This does feel like more of an OpenPBR 2.0 level change, and we can certainly understand that there will likely be resistance to making modifications this fundamental, but it is our belief that this will result in a more capable and stronger standard.

Some observations about this proposed new parametrization:

there is no reference to a "base" layer, so it's potentially a bit confusing how the metalness works (i.e. being the mix weight between metallic and dielectric base). diffuse_weight and metal_weight are not mix weights, but essentially just tints applied to the albedo. Maybe it's reasonably understandable though. I'm not sure where metalness should live in the UI after this change though, since it pertains to both the diffuse and the metal sections. Unless we have all these diffuse/metal parameters under an "opaque base" section, where the metalness lives also.

I assume specular_weight, specular_color, specular_roughness and specular_roughness_anisotropy would only apply to the dielectric base now. The naming "specular" is then a bit pointless/confusing I think, as the parameters apply only to dielectric (not the metal which also specular), so we should really make the prefix dielectric_ instead (i.e. dielectric_weight, dielectric_ior, dielectric_roughness, etc.), which makes more sense.

I assume the proposed connection between the simplified interface and the underlying parameters would be something like the following:

If assets are shared there would also need to be some conventions, e.g. is the network provided with the material, or perhaps the network is implied if the underlying parameters can be represented by the network (of the above form).

I think would it would also be clearer to rename the "weights" which are simply reflectivity modulations, to "reflectivities". Then the simplified parameters remain "lobe-centric" (i.e. control base/spec lobes), while the underlying parameters are closer to the material structure.

@portsmouth, I really like your idea about renaming specular to dielectric. I'll definitely include that in the PR.