SNOW-1748403: Use Aggregare.aggregate_expressions to infer quoted identifiers

Which Jira issue is this PR addressing? Make sure that there is an accompanying issue to your PR.
<!---
In this section, please add a Snowflake Jira issue number.
<p>Note that if a corresponding GitHub issue exists, you should still include
the Snowflake Jira issue number. For example, for GitHub issue
https://github.com/snowflakedb/snowpark-python/issues/1400, you should
add "SNOW-1335071" here.
--->
Fixes SNOW-1748403

Fill out the following pre-review checklist:

[x] I am adding a new automated test(s) to verify correctness of my new code

[ ] If this test skips Local Testing mode, I'm requesting review from @snowflakedb/local-testing

[ ] I am adding new logging messages
[ ] I am adding a new telemetry message
[ ] I am adding new credentials
[ ] I am adding a new dependency
[ ] If this is a new feature/behavior, I'm adding the Local Testing parity changes.
[x] I acknowledge that I have ensured my changes to be thread-safe. Follow the link for more information: Thread-safe Developer Guidelines

Please describe how your code solves the related issue.
We can use Aggregare.aggregate_expressions directly for quoted identifiers

This looks great. Is there a way to quantify the impact of each of those improvements on the reduction of describe queries?

This looks great. Is there a way to quantify the impact of each of those improvements on the reduction of describe queries?

Yeah I was using sql counter on some modin tests to see the impact. For example, test_describe_numeric_only will reduce 6 describe query with this change. I also tried to run workload tests in https://github.com/snowflakedb/snowpark-pandas-internal, and I can use my own branch to check the number of describe queries.


Add documentation

Is your feature request related to a problem? Please describe
There is currently no documentation on the Hazel API and how to accomplish certain things in Hazel. This makes it harder for newer developers to both use and contribute to Hazel.
Describe the solution you'd like
Add documentation in the source code and public documentation on the repo wiki or hazel website.
Describe alternatives you've considered
n/a
Additional context
This is a feature that is and should be necessary for releases as well as helping new developers join the Hazel community

We started building our own hazel wiki at this point, we just need content to be written, without some basic content, we can't really publish (after testing). Content should be written in markdown.

Do you have a link to the wiki? I'd love to help write content if needed.

I have also started making a wiki but do not have the slightest idea of what to put in it. how should the hazel wiki be arranged?

If I had to guess, I'd say it should be organized by feature or how to achieve certain things using the engine like rendering a quad or particles. This can be done through basic examples so developers and users alike know what's supported and how to use it.

The wiki is located at https://github.com/TheChernoCommunity/HazelWiki. And I got a basic site working, we just need content to put on it: https://github.com/LovelySanta/HazelWiki and get github actions integrated in the deployment when pushing to master.
Our idea was to have an api-kinda look, so it acts like an api, with some additional documentation underneath each api class where needed.

It looks like the site is ready for content, I think before that happens we should define a format for everything so it doesn't become messy.

Maybe try creating an api for the event system as guidance? I do like how it is done here:
https://wiki.factorio.com/Prototype/AssemblingMachine
a condensed table of the full api, click on it to go to details below it

Sounds good I'll PR into https://github.com/LovelySanta/HazelWiki since https://github.com/TheChernoCommunity/HazelWiki is not up to date

We still have to figure out how to auto deploy when pushed into master, hence why it's not into https://github.com/TheChernoCommunity/HazelWiki yet.

there is an npm package gh-pages which combined with travis or github actions should be able to achieve this.

Feel free to setup a demo on your fork, so I can do it on my fork, and then push it to the community

I'll close this for now. The wiki has it's own issue page that can take reports.


Vector weirdness

Haven't dived too deeply into this, but I'm getting the feeling it isn't the intended behavior. There's a lot of weirdness that happens when multiplying a Pint Quantity by a modsim Vector(Quantity).
For example, this produces the expected result:

however accessing x or y produces an error:
distance_vector.x
# -> Neither Quantity object nor its magnitude ([ 0.5547002   0.83205029]) has attribute 'x'

here's a workaround:
acc = 1 * UNITS.m/UNITS.second**2
acc = (acc.m * Vector(2,3).hat()) * acc.units
acc.x
# -> 0.5547001962252291 meter/second**2 :)

Unrelated, there's a weird edge case that brakes Pint's TeX formatting:

Looks like there's some kind of superscript formatting going on in the TeX source? Might be a bug on Pint's end.

Thanks for letting me know (and sorry I didn't notice this issue sooner!).
This one is hard to fix.  I will have to think about it...

Yeah, this is really hard to fix.  I've explained it better in the book and the documentation.  That might be the best I can do.


[feat] Support sending byte data to the "data" event for child command's stdout and stderr

Describe the problem
See related issue: https://github.com/tauri-apps/tauri/issues/5309
Currently we receive type string for the the "data" event listener of child.stdout.on("data" ....) and child.stderr.on("data" ....). This is suitable for the vast majority of simple communication, but challenging to work-around for the cases in which binary data must be fed directly through for applications that use more complex communication formats.
In my specific case, I'm trying to read msgpack messages via the command output of a child process, and currently that is impossible without writing a workaround solution for several reasons:

The default operation if no encoding specified is to attempt a conversion to utf_8 using rust's built-in decoder, executed here
If there is an encoding, then it uses encoding_rs which correctly replaces invalid utf-8 with replacement characters.

In scenario 1, we observe the symptoms of https://github.com/tauri-apps/tauri/issues/5309, which is correct behavior. In scenario 2, encoding_rs eliminates unrecognized or invalid utf8 sequences entirely, which is also correct behavior.
Describe the solution you'd like
I would like a flag in SpawnOptions that allows for the output of the process to be sent directly to the front end, either as an array of numbers resembling a Uint8Array or an escaped string with control characters like \x... or \u....
Alternatives considered
I'm going to have to work around this for now by implementing a shim executable that can perform this translation beforehand, and then use that as my sidecar. I cannot change the message format of my current sidecar, so a work-around is required to get communication working properly.
Additional context
If you're interested, the sidecar application is neovim, and I'm trying to communicate with it using RPC directly. I have previously implemented this in Node and Electron. This is currently blocking development while I hack a solution into existence.

I tried to implement it. I got working prototype, however it doubt it can be merged as it is right now 😅. Here is my tarui branch with implementation and here is example app to show how it works.

@cymruu really good work, looking forward to the PR unfortunately since it is a breaking change, it will be scheduled for tauri@v2


command: az monitor alert-rules list -g 'Your_group' | grep operator produces mostly null operators

Description
Outline the issue here:
This is very bad.
I have all these alert-rules defined via the Web GUI
az monitor alert-rules list -g our_group'' | grep name
"name": "CPU Greater Than Rule",
"name": "Critical All Processor Time",
"name": "CriticalCPUIdleTime",
"name": "CriticalCPUIdleTime-2",
"name": "CriticalCPUPercent",
"name": "CriticalMemoryUsed",
"name": "CriticalProcesssorSystemTime",
"name": "CriticalProcesssorUserTime",
"name": "CrticalTotalLowDiskFreeSpace",
"name": "Disk Percentage Free",
"name": "Disk Read Bytes",
"name": "Disk Write Bytes",
"name": "Disk Write Operations Sec",
"name": "LogDiskTotAvgtReadQueueLength",
"name": "LogicalDiskLTotalFreeMegabytes",
"name": "LogicalDiskLTotPercentFreeSpace",
"name": "LogicalDiskTotalAvgtDisksecRead",
"name": "LogicalDiskTotalAvgtQueueLength",
"name": "LogicalDiskTotalDiskBytessec",
"name": "LogicalDiskTotalDiskReadssec",
"name": "LogicalDiskTotalDiskTransferssec",
"name": "LogicalDiskTotalPercentDiskTime",
"name": "LogicalDiskTotalPercentIdleTime",
"name": "LogicalDiskTotalWritessec",
"name": "LogicalPercentTotalDiskWriteTime",
"name": "LogicalTotalAvgtDisksecTransfer",
"name": "LogicalTotalAvgtDisksecWrite",
"name": "LogicalTotalDiskReadBytessec",
"name": "LogicalTotalDiskWriteBytessec",
"name": "LogicalTotalPercentDiskReadTime",
"name": "LogTotAvgDiskWriteQueueLength",
"name": "Memory Available Bytes",
"name": "MemoryAvailable Bytes",
"name": "MemoryCacheBytes",
"name": "MemoryCommittedBytes",
"name": "MemoryPageFaultssec",
"name": "MemoryPagesPerSec",
"name": "MemoryPool PagedBytes",
"name": "MemoryPoolNonpagedBytes",
"name": "NetInterPacketsOutboundErrors",
"name": "NetInterPacketsReceivedErrors",
"name": "Network In",
"name": "Network InterfaceBytesSentsec",
"name": "Network InterfacePacketssec",
"name": "Network Out",
"name": "NetworkInterfaceBytesReceivedsec",
"name": "NetworkInterfaceBytesTotalsec",
"name": "NetworkInterfacePacketsSentsec",
"name": "NetworkInterPacketsReceivedsec",
"name": "Percentage CPU",
"name": "ProcessorTotalPercentUser Time",
"name": "ProcessTotalThread Count",
"name": "ProcessTotalWorkingSet",
"name": "ProcessTotalWorkingSetPrivate",
"name": "ProcTotalFrequency",
"name": "ProcTotalHandleCount",
"name": "ProcTotalPercentPrivilegedTime",
"name": "System Up Time",
"name": "SystemContext SwitchesPerSec",
"name": "SystemProcesses",
"name": "SystemProcQueueLength",
"name": "Total Percent Processor Time",
"name": "WarningAll ProcessorTime",
"name": "WarningMemoryUsed",
"name": "WarningProcesssorSystemTime",
"name": "WarningProcesssorUserTime",
"name": "WarningSwapMemory",
"name": "WarningTotalLowDiskFreeSpace",
I try to list the JSON to see the rule and check out the operator.
The operator is mostly 'null'
And in the Azure GUI on the webpage - there are no null operators.
c5256381% az monitor alert-rules list -g 'our_group' | grep operator
"operator": null,
"operator": null,
"operator": "LessThan",
"operator": "LessThan",
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": "LessThan",
"operator": "LessThan",
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": "LessThan",
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": null,
"operator": "LessThan",
Would be great if this was fixed.

Environment summary
Install Method: How did you install the CLI? (e.g. pip, interactive script, apt-get, Docker, MSI, nightly)
Answer here:
curl -L https://aka.ms/InstallAzureCli | bash
CLI Version: What version of the CLI and modules are installed? (Use az --version)
Answer here:
az --version
azure-cli (2.0.5)
acr (2.0.3)
acs (2.0.5)
appservice (0.1.5)
batch (2.0.3)
cdn (0.0.1)
cloud (2.0.2)
cognitiveservices (0.1.1)
command-modules-nspkg (2.0.0)
component (2.0.3)
configure (2.0.5)
core (2.0.5)
dla (0.0.5)
dls (0.0.5)
documentdb (0.1.5)
feedback (2.0.2)
find (0.2.2)
interactive (0.3.0)
iot (0.1.5)
keyvault (2.0.3)
lab (0.0.4)
monitor (0.0.3)
network (2.0.5)
nspkg (3.0.0)
profile (2.0.4)
redis (0.2.2)
resource (2.0.5)
role (2.0.3)
sf (1.0.0)
sql (2.0.2)
storage (2.0.5)
vm (2.0.5)
Python (Darwin) 2.7.10 (default, Feb  6 2017, 23:53:20)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)]
Python location '/Users/c5256381/lib/azure-cli/bin/python'
OS Version: What OS and version are you using?
Answer here:
MacOS 10.12.4 Sierra
Shell Type: What shell are you using? (e.g. bash, cmd.exe, Bash on Windows)
Answer here:
csh

Hi @jefffall, I ran into this same issue while working on the overhauled alert commands. After creating an alert rule, the object returned has "null" as the operator. I believe this may be a service-side issue.
cc/ @johnkemnetz

This is a service bug.  I created an issue in the REST API specs since that has the most visibility with the service team. https://github.com/Azure/azure-rest-api-specs/issues/1211

Thank you Travis !!!!

On May 10, 2017, at 11:57 AM, Travis Prescott<EMAIL_ADDRESS>wrote:
This is a service bug. I created an issue in the REST API specs since that has the most visibility with the service team. Azure/azure-rest-api-specs#1211
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Also, I've observed this only occurs when the operation is "GreaterThan".  For the other operators, this value returns normally.  So, if >= makes sense for your case, I would encourage you to use that until the service fixes the bug.

This has been fixed in the service. Please re-open if the issue persists.

That took a year
:-)

On Mar 30, 2018, at 4:53 PM, Travis Prescott<EMAIL_ADDRESS>wrote:
Closed #3262.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Well I think it was fixed a while ago, but I just now saw this issue still open :D


Updated gradle configuration for gradle 3.0.0+

Further details on Gradle 3.0.0+ https://developer.android.com/studio/build/gradle-plugin-3-0-0-migration.html#new_configurations
Is there any other PR opened that does the same ?
No.
What issue is this PR fixing
https://github.com/react-community/react-native-maps/issues/2095
Also fixing installation.md which had the old gradle configuration and not the new one.

LGTM @alvelig 🐽

@rborn will this be updated in the next React Native Maps update? 0.20.2? How can I tell when it's included in a release version?

@MarkOSullivan94 usually @christopherdro includes a change log when he does a release.

@rborn can this PR be merged in?

@christocracy how does this influences/compares with your PR https://github.com/react-community/react-native-maps/pull/2047

As long as it uses the new $googlePlayServicesVersion, it's fine.

LGTM

@christocracy looks like it does, thank you
@alvelig thnx
@MarkOSullivan94 🎉

It can be simply reproduced:

install react-native-maps master branch over clean react-native 0.54.3 repository
set up react-native-maps for Android according to latest instructions
build result in gradle error:

A problem occurred evaluating project ':app'.
> Could not find method implementation() for arguments [project ':react-native-maps'] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.

The solution was to reverse this commit and install according to old instructions. Seems that react-native built-in gradle version is not compatible.
PS: Sorry for the message here rather than in issues.

@todorone post your android/build.gradle

@christocracy It's default react-native one with only change of react-native-maps:
// Top-level build file where you can add configuration options common to all sub-projects/modules.

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:2.2.3'

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        mavenLocal()
        jcenter()
        maven {
            // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
            url "$rootDir/../node_modules/react-native/android"
        }
    }
}

ext {
    compileSdkVersion   = 26
    targetSdkVersion    = 26
    buildToolsVersion   = "26.0.2"
    supportLibVersion   = "26.1.0"
    googlePlayServicesVersion = "11.8.0"
    androidMapsUtilsVersion = "0.5+"
}

gradle implementation is only available in Gradle 3.
buildscript {
    dependencies {
+        classpath 'com.android.tools.build:gradle:3.0.1'
    }
}

@christocracy maybe we should add a note in the docs (if it's not there already) about using gradle 3?

@todorone that would be a good PR 🤪

@rborn I've tried to use latest gradle version for building, but experienced that it somehow incompatible with another native dependency - react-native-vector-icons. I'll be glad to help you guys in testing or whatever but I'm not experienced enough here to make consistent PR adressing this issue. Sorry. 😊
BTW: Thanks for an amazing work of supporting react-native-maps!

react-native-vector-icons has an unusual build.gradle.  I don't think they need to specify the buildscript block.

@todorone, If you have your project open in Android Studio, edit react-native-vector-icons and delete the entire buildscript block and see if it builds.

@christocracy So the latest news. Everything started to work, even while not touching react-native-vector-icons.
That's the section of build.gradle:
buildscript {
    repositories {
        jcenter()
        // google() must be added to default react-native build.gradle
        google()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:3.1.0' // changed version to 3.1.0
    }
}

And also adjusted in gradle-wrapper.properties:
distributionUrl=https\://services.gradle.org/distributions/gradle-4.4-all.zip

This PR was completely unnecessary and it goes against default react-native template which is still using gradle 2. As result it makes this project incompatible with most rn plugin which use gradle 2. If you need one -  https://github.com/mauron85/react-native-background-geolocation/issues/176. Also PR is incomplete without updating installation instructions  how to update your project to gradle 2. Something like - https://medium.com/bam-tech/boost-compilation-time-of-your-react-native-or-android-app-with-the-latest-build-tools-a3d5d398ed33
I have also created new issue with more details https://github.com/react-community/react-native-maps/issues/2180
Please revert this PR.

No it was completely necessary for anyone wanting to use RN-Maps and is using Android Studio 3.x (the stable version is 3.1.1) otherwise they'll be unable to build the project successfully.
Perhaps more instructions will be required, I just changed what I changed within my project to get RN Maps to work on Gradle 3.x and updated the docs with the steps I had to do.

@MarkOSullivan94 I open all my RN gradle2 projects in Android Studio 3.1. Not sure what are you talking about.

Got the following build error after changing build.gradle. I've upgraded Android Studio to 3.1.1 and the Gradle plugin.
A problem occurred configuring root project 'xxxxxxx'.

Could not resolve all dependencies for configuration ':classpath'.
Could not find com.android.tools.build:gradle:3.1.0.
Searched in the following locations:
https://jcenter.bintray.com/com/android/tools/build/gradle/3.1.0/gradle-3.1.0.pom
https://jcenter.bintray.com/com/android/tools/build/gradle/3.1.0/gradle-3.1.0.jar
Required by:
:xxxxxx:unspecified

Post your android/build.gradle

@christocracy
// Top-level build file where you can add configuration options common to all sub-projects/modules.

buildscript {
    repositories {
        jcenter()

    }
    dependencies {
        classpath 'com.android.tools.build:gradle:3.1.0' // changed version to 3.1.0

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        mavenLocal()
        jcenter()
        maven {
            // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
            url "$rootDir/../node_modules/react-native/android"
        }
    }
}

To your repositories, add google()

@christocracy
That gives me this error...

Where:
Build file '/Users/dmesser/Develop/React-Native/xxxxxx/android/build.gradle' line: 6

What went wrong:
A problem occurred evaluating root project 'xxxxxx'.

Could not find method google() for arguments [] on repository container.

Replace it with:
maven {
          url 'https://maven.google.com'
}

@christocracy
Got me further. Now getting...
> Task :app:compileDebugJavaWithJavac FAILED
/Users/dmesser/Develop/React-Native/RetailApp/android/app/src/main/java/com/lifeway/christianstores/MainApplication.java:13: error: package com.airbnb.android.react.maps does not exist
import com.airbnb.android.react.maps.MapsPackage;
                                    ^
/Users/dmesser/Develop/React-Native/RetailApp/android/app/src/main/java/com/lifeway/christianstores/MainApplication.java:33: error: cannot find symbol
            new MapsPackage()
                ^
  symbol: class MapsPackage
2 errors

Now you circle back and verify your setup steps.

@christocracy
I followed all the steps. The only one that looks like it might be causing this error is...
include ':react-native-maps'
project(':react-native-maps').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-maps/lib/android')

But I did that.

No idea.  Load your app in Android Studio and look war errors / warnings.

Just had a look over the React Native PRs, it looks like the RN project will be updated to Gradle 3.x soon: https://github.com/facebook/react-native/pull/17747

this article helped me: https://medium.com/bam-tech/boost-compilation-time-of-your-react-native-or-android-app-with-the-latest-build-tools-a3d5d398ed33

Hi @MarkOSullivan94, could you please add documentation for this change?
The project does not work out of the box with the current documentation.
Thanks!

@lachenmayer are you having issues with getting it working? I'd look over your project setup and see if I can spot anything

Thanks a lot Mark, I have created a repro project here: https://github.com/lachenmayer/react-native-maps-gradle-repro
The repro
The repro contains detailed instructions for how to reproduce every step, and you can just click on every line item to verify the file changes. Note that I have left out all of the steps that I believe are irrelevant to this discussion, eg. setting up Google Maps API keys etc.
I did use react-native link contrary to the current documentation. However looking at the file changes, there should be no reason why that should not work - it adds all of the correct rules to app/build.gradle and settings.gradle, and adds MapsPackage to the main application file. I may have missed something here, please let me know if so.
You should hopefully be able to see that when the changes from this PR are removed, the project builds as expected.
The problem/goal
react-native-maps is currently extremely difficult to install, especially for developers who are not very experienced with native iOS and/or Android development.
The goal I would like us to strive towards is that the library can be installed just using a simple react-native link, like any other RN library with native dependencies. Whether that's achievable on iOS is debatable, but on Android this definitely should not be a problem.
This change has added significant complexity to the installation procedures when starting from create-react-native-app - a search for "compileOnly" in this repo's issues should confirm that our users are having a lot of trouble with this change.
Now, I am aware of the discussion in https://github.com/react-community/react-native-maps/issues/2180.
I understand your frustration that you are not able to use Gradle 3 by default - it is clearly superior, and I agree that React Native should be using it by default. However, at this point in time Gradle 3 is clearly a "power-user" feature which is mainly used by teams/individuals who are more likely to understand the intricacies of Android dependency management. I believe that the library should work out of the box for "everyone else" by default. In particular, we should not force people to have to upgrade the underlying tooling of their project just to get this particular dependency to build.
Since react-native-maps relies on React Native, we are unfortunately tied to their upstream decisions & release cycles. I am aware that you are contributing on the PR to upgrade the default React Native project to Gradle 3 (https://github.com/facebook/react-native/pull/17747), thanks a lot for that. Once that change lands, we will be able to safely upgrade to Gradle 3 without necessarily maintaining backwards compatibility, since the policy in this repo is to only maintain compatibility with the latest version of React Native.
Most importantly... The original bug report you submitted https://github.com/react-community/react-native-maps/issues/2095 - which this PR does fix, in a sense - is not a bug. In your screenshot, you show the deprecation warnings that get triggered when you have Gradle >3 installed. These are just warnings, the project will still compile just fine, even with these warnings. If you are not convinced of this, I can update the repro project above to use Gradle >3.
Possible solutions

Revert this PR and wait for https://github.com/facebook/react-native/pull/17747 to land.
This would allow us to massively simplify the installation documentation & to allow an easy installation experience for Android users. If you need Gradle 3 support in this scenario, I recommend using patch-package. This will let you easily make the required changes to react-native-maps to make it compatible with your own projects, as well as letting you keep up with the latest changes in the library without having to maintain a separate fork. Once https://github.com/facebook/react-native/pull/17747 lands, we can revisit the Gradle 3 change & break backwards compatibility.

Find a different backwards-compatible solution
I have noticed that (eg.) this PR https://github.com/Microsoft/react-native-code-push/pull/1219 claims to have a backwards-compatible solution for using Gradle 3. I don't really understand how this works, but this may also be a useful way to go.

Option 1 is obviously the least effort, but if you have the time to look into option 2 that would definitely be appreciated.
It would be great if some of the maintainers could chime in here, so that we can get the project building out of the box again. Thanks folks!

@lachenmayer absolutely fantastic work with that repo, so easy and clear to follow. I've forked your repo and made the necessary changes to get a successful build. The files changed are a bit misleading as the majority of the changes are done automatically within Android Studio whenever you update the Android projects gradle files.
https://github.com/MarkOSullivan94/react-native-maps-gradle-repro/blob/master/android/build.gradle#L11
This is were you specify that wish to use gradle 3.0.1 for the project. This will result on a knock on affect within Android Studio recommending you to upgrade other dependencies which are old and outdated in React Native projects. Everything is suggested in the errors / warning messages.
For example
* What went wrong:
A problem occurred evaluating project ':react-native-maps'.
> Could not find method compileOnly() for arguments [com.facebook.react:react-native:+] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.

This error message would indicate that your Android project doesn't have Gradle 3.0.
If you would like to try and upgrade it yourself, focus on the build.gradle files:
https://github.com/MarkOSullivan94/react-native-maps-gradle-repro/blob/master/android/build.gradle
https://github.com/MarkOSullivan94/react-native-maps-gradle-repro/blob/master/android/app/build.gradle
This is where you'll update dependencies until it will work with Gradle 3.0. Like I've said previously, Android Studio helps with recommendations on what to use, so I would recommend using it.

Most importantly... The original bug report you submitted #2095 - which this PR does fix, in a sense - is not a bug. In your screenshot, you show the deprecation warnings that get triggered when you have Gradle 3 installed. These are just warnings, the project will still compile just fine, even with these warnings. If you are not convinced of this, I can update the repro project above to use Gradle 3

Perhaps I didn't include it in the original issue report but I would try and build our project using Android Studio it would not build because our existing Android project was already using Gradle 3.0+.
It will produce a warning about the compile and provided keywords as shown by my screenshot in #2095 and unlike most other warnings in Android Studio, this one will cause it not to successfully build which is a big problem for anyone having similar issues.
I know some might suggest not to use Android Studio however that is impossible whenever you consider Android applications which have React Native components within them (which is what we do).

distributionUrl=https\://services.gradle.org/distributions/gradle-4.4-all.zip

Look it does, Thanks Man.!

@todorone, Thanks man, it really works.

buildscript {
repositories {
jcenter()
// google() must be added to default react-native build.gradle
google()
}
dependencies {
classpath 'com.android.tools.build:gradle:3.1.0' // changed version to 3.1.0
}
}

And also adjusted in `gradle-wrapper.properties`:
`distributionUrl=https\://services.gradle.org/distributions/gradle-4.4-all.zip`


Add version: BtbN.FFmpeg.LGPL.7.1 version 7.1-20241130 (2024-11-30-13-12)

Created by 🥟 Dumplings in workflow run #9929.

Log
Updated: 2024-10-31-12-59 → 2024-11-30-13-12
Submitting WinGet manifests
Creating manifests
Uploading manifests and making commits
Creating a pull request
Pull request created: New version: BtbN.FFmpeg.GPL version N-117967-g4de67e8746-20241130 (2024-11-30-13-12) - https://github.com/microsoft/winget-pkgs/pull/195396
Submitting WinGet manifests
Creating manifests
Uploading manifests and making commits
Creating a pull request
Pull request created: Add version: BtbN.FFmpeg.GPL.5.1 version 5.1.6-20241130 (2024-11-30-13-12) - https://github.com/microsoft/winget-pkgs/pull/195397
Submitting WinGet manifests
Creating manifests
Uploading manifests and making commits
Creating a pull request
Pull request created: Add version: BtbN.FFmpeg.GPL.6.1 version 6.1.2-20241130 (2024-11-30-13-12) - https://github.com/microsoft/winget-pkgs/pull/195398
Submitting WinGet manifests
Creating manifests
Uploading manifests and making commits
Creating a pull request
Pull request created: Add version: BtbN.FFmpeg.GPL.7.1 version 7.1-20241130 (2024-11-30-13-12) - https://github.com/microsoft/winget-pkgs/pull/195399
Submitting WinGet manifests
Cannot find path 'D:\a\Dumplings\Dumplings\winget-pkgs\manifests\b\BtbN\FFmpeg\GPL\Shared' because it does not exist.
Submitting WinGet manifests
Cannot find path 'D:\a\Dumplings\Dumplings\winget-pkgs\manifests\b\BtbN\FFmpeg\GPL\Shared\5\1' because it does not exist.
Submitting WinGet manifests
Cannot find path 'D:\a\Dumplings\Dumplings\winget-pkgs\manifests\b\BtbN\FFmpeg\GPL\Shared\6\1' because it does not exist.
Submitting WinGet manifests
Cannot find path 'D:\a\Dumplings\Dumplings\winget-pkgs\manifests\b\BtbN\FFmpeg\GPL\Shared\7\1' because it does not exist.
Submitting WinGet manifests
Creating manifests
Uploading manifests and making commits
Creating a pull request
Pull request created: New version: BtbN.FFmpeg.LGPL version N-117967-g4de67e8746-20241130 (2024-11-30-13-12) - https://github.com/microsoft/winget-pkgs/pull/195400
Submitting WinGet manifests
Creating manifests
Uploading manifests and making commits
Creating a pull request
Pull request created: Add version: BtbN.FFmpeg.LGPL.5.1 version 5.1.6-20241130 (2024-11-30-13-12) - https://github.com/microsoft/winget-pkgs/pull/195401
Submitting WinGet manifests
Creating manifests
Uploading manifests and making commits
Creating a pull request
Pull request created: Add version: BtbN.FFmpeg.LGPL.6.1 version 6.1.2-20241130 (2024-11-30-13-12) - https://github.com/microsoft/winget-pkgs/pull/195402
Submitting WinGet manifests
Found existing pull requests:
Add version: BtbN.FFmpeg.LGPL.5.1 version 5.1.6-20241130 (2024-11-30-13-12) - https://github.com/microsoft/winget-pkgs/pull/195401
Creating manifests
Uploading manifests and making commits
Creating a pull request

Microsoft Reviewers: Open in CodeFlow

Automatic Validation ended with:

No errors to post.

(Automated response - build 899.)


WIP fix: use canonical url for pages

Remove index.html from url of pages. Fixes #13. Based on https://github.com/pyyzcwg2833/hexo-generator-sitemap/commit/a92dbbb83cc39ff60d43faa5cd688a56574a3889 (credit @pyyzcwg2833).
Added test for pages. Updated the updated attribute of hexo.init() in the test for more predictable result.
The affected code uses ES6 syntax. Refactor everything else to ES6 should be in a separate PR.
Feel free to refactor .concat() and array-object-array conversion to something better.
Pull request tasks

[x] Add test cases for the changes.
[ ] Passed the CI test.

will not pass in Node 6 environment.

Coverage remained the same at 100.0% when pulling 5df7fe70e588f2cea8b766ebbe69c1dd01a98ea3 on weyusi:remove-index-html into 084138e8536bd0a5a2b54ebc99bb27a3c067ce3c on hexojs:master.

ecmaVersion needs to be set to 2018 in .eslintrc to support (...) spread operator, even though it's supported in the latest revision of ES6/2015.
Replace istanbul with nyc to support spread operator.

Superseded by #59


Pass chatbot latest prompt

Related Issue
Closes #245

Description

Pass query string to chatbot

How Has This Been Tested?
Locally
Screenshots (if applicable)

Type of Change

[x] Bug fix
[ ] New feature
[ ] Code style update
[ ] Breaking change
[ ] Documentation update

Its not query, add the initial prompt

LGTM


Out of date Release Notes

Today, 02/21/2019, The Release Notes for Identity Experience Framework is dated 10/13/2017. Where are the latest Release Notes?
I am particularly interested in the use of client_assertion to pass pre-population values for a user journey, but this is marked here as "will be deprecated", yet is still available today.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: a067ceb2-fe69-6b56-eafa-ffb7ebf1968e
Version Independent ID: 6fd66d79-08fa-b5ea-daf0-d92073269b64
Content: Developer notes on using custom policies in Azure Active Directory B2C
Content Source: articles/active-directory-b2c/active-directory-b2c-developer-notes-custom.md
Service: active-directory
GitHub Login: @davidmu1
Microsoft Alias: davidmu

@rollandjb Thanks for the feedback. I have assigned this to the author to provide an update regarding this and update the doc with any new changes.

The article has been updated today (3/25/19) with current information.
#please-close


unbound: 1.10.1 -> 1.11.0

Semi-automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/unbound/versions.
meta.description for unbound is: "Validating, recursive, and caching DNS resolver"
meta.homepage for unbound is: "https://www.unbound.net"
meta.changelog for unbound is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 1.11.0 with grep in /nix/store/srdq29man8yi9h161zcgqy7xzcsnijjy-unbound-1.11.0

directory tree listing: https://gist.github.com/53e5f64317f102c99e47d66fa1ea69c1

du listing: https://gist.github.com/a754a55dfaa1968db3781691d1641206

Rebuild report (if merged into master) (click to expand)

25548 total rebuild path(s)

9163 package rebuild(s)

9151 x86_64-linux rebuild(s)
7772 i686-linux rebuild(s)
1073 x86_64-darwin rebuild(s)
7552 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
AusweisApp2
DisnixWebService
EmptyEpsilon
Literate
MMA
OVMF
OVMF-CSM
OVMF-secureBoot
R
SDL
SDL2
SDL2_gfx
SDL2_image
SDL2_mixer
SDL2_net
SDL2_ttf
SDL_Pango
SDL_gfx
SDL_gpu
SDL_image
SDL_mixer
SDL_net
SDL_sound
SDL_stretch
SDL_ttf
Sylk
_20kly
_389-ds-base
_3mux
_90secondportraits
a2jmidid
abbaye-des-morts
abcde
abcl
abiword
abootimg
accountsservice
acoustidFingerprinter
acsccid
act
adapta-gtk-theme
adementary-theme
adlplug
adminer
adobe-reader
adom
adoptopenjdk-icedtea-web
adwaita-qt
aegisub
aeolus

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/srdq29man8yi9h161zcgqy7xzcsnijjy-unbound-1.11.0 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A unbound https://github.com/r-ryantm/nixpkgs/archive/0c609939fdb9c44ad26cc296e6ebc75c59fa9456.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/srdq29man8yi9h161zcgqy7xzcsnijjy-unbound-1.11.0
ls -la /nix/store/srdq29man8yi9h161zcgqy7xzcsnijjy-unbound-1.11.0/bin

Pre-merge build results
NixPkgs review skipped

Maintainer pings
cc @ehmry @fpletz @globin for testing.

@ofborg eval


WIP - infer resources and "enricher" changes

This is the start of #36 which will try to create missing resources, like services and deploymentConfigs if not specified
This is also connected to #14 which changes the way the resources files are enriched.

Coverage decreased (-1.07%) to 94.156% when pulling fd4d6811a0610a77a64fd298fcd5c79fdac09b9c on lholmquist:36-infer-resources into 4a039ba65b2076e73369066b8cd814ca8bce5ffe on bucharest-gold:master.

Coverage decreased (-5.4%) to 89.841% when pulling 87efdc9b4ee8590a65992b1f243d396dad41f318 on lholmquist:36-infer-resources into 4a039ba65b2076e73369066b8cd814ca8bce5ffe on bucharest-gold:master.

Coverage decreased (-6.7%) to 88.509% when pulling b06cba652c21c8a6646efd086794e0c669009489 on lholmquist:36-infer-resources into 4a039ba65b2076e73369066b8cd814ca8bce5ffe on bucharest-gold:master.

Coverage decreased (-5.6%) to 89.596% when pulling b4d943cba5a29c5daeda6468ecd265f88fe64908 on lholmquist:36-infer-resources into 4a039ba65b2076e73369066b8cd814ca8bce5ffe on bucharest-gold:master.

Coverage decreased (-3.8%) to 91.46% when pulling e15f87175a9bb541f48e89ad3d8ae749880b8782 on lholmquist:36-infer-resources into 4a039ba65b2076e73369066b8cd814ca8bce5ffe on bucharest-gold:master.

Coverage decreased (-3.8%) to 91.46% when pulling bd4d7d93ace0528453607cf856726bae3359aa6b on lholmquist:36-infer-resources into 4a039ba65b2076e73369066b8cd814ca8bce5ffe on bucharest-gold:master.

Coverage decreased (-3.8%) to 91.46% when pulling df45b583625b62629ba5605ba03fbd6bfe221ad3 on lholmquist:36-infer-resources into 4a039ba65b2076e73369066b8cd814ca8bce5ffe on bucharest-gold:master.

Coverage decreased (-1.1%) to 94.099% when pulling aad5c15cf83ddd976dd618f40279b12138c36447 on lholmquist:36-infer-resources into 4a039ba65b2076e73369066b8cd814ca8bce5ffe on bucharest-gold:master.

Coverage increased (+0.1%) to 95.342% when pulling 566781ec5b46556f98dbe31093e1084cbd1c9b49 on lholmquist:36-infer-resources into 4a039ba65b2076e73369066b8cd814ca8bce5ffe on bucharest-gold:master.

Coverage increased (+2.6%) to 97.826% when pulling 688da07b31687f699c853096cb5644004b2fb4e6 on lholmquist:36-infer-resources into 4a039ba65b2076e73369066b8cd814ca8bce5ffe on bucharest-gold:master.

Coverage increased (+2.6%) to 97.826% when pulling ce8e79455a42d8619b0c1c4d0d23c7afe9df8bc2 on lholmquist:36-infer-resources into 4a039ba65b2076e73369066b8cd814ca8bce5ffe on bucharest-gold:master.


If publish fails, version changes are committed

If for some reason the apm publish failes, like for example the one described in #16835, the changes are committed anyway to the repo.
This causes problem if this goes unnoticed as it may end up in unnecessary version bumps once the problem is resolved.
Versions:
$ atom-beta --version
Atom    : 1.25.0-beta1
Electron: 1.7.11
Chrome  : 58.0.3029.110
Node    : 7.9.0

$ apm-beta --version
apm  1.19.0
npm  3.10.10
node 6.9.5 x64
atom 1.25.0-beta1
python 2.7.10
git 2.14.3

Thanks for this followup issue - looks pretty related to https://github.com/atom/apm/issues/477 I think?  We'll go ahead and close as a duplicate and you can subscribe for updates if you'd like.

Because we treat our issues list as the Atom team's backlog, we close duplicates to focus our work and not have to touch the same chunk of code for the same reason multiple times. This is also why we may mark something as duplicate that isn't an exact duplicate but is closely related.
For information on how to use GitHub's search feature to find out if something is a duplicate before filing, see the How Can I Contribute? section of the Atom CONTRIBUTING guide.


Remove conflicts in the executable all-in-one JAR file

META-INF/INDEX.LIST and META-INF/versions/9/module-info.class have conflicted in the executable all-in-one JAR file. Gradle 7+ started to fail when there is a conflict in building a JAR file.
Better not to have a conflict in the JAR file, anyway.
They can be just removed while Embulk basically expects Java 8.

Thanks!


CASMHMS-5617: Remove WAR for bad SLS chassis data generation.

Also migrate to HSM v2 APIs
Summary and Scope
Summarize what has changed. Explain why this PR is necessary. What is impacted? Is this a new feature, critical bug fix, etc?
The verify_hsm_discovery.py script had a WAR in place for bad SLS chassis data generation, and the bug causing this was fixed in https://github.com/Cray-HPE/cray-site-init/pull/203 .
Is this change backwards incompatible, backwards compatible, or a backwards compatible bugfix?
Issues and Related PRs
List and characterize relationship to Jira/Github issues and other pull requests. Be sure to list dependencies.

Resolves CASMHMS-5617

Testing
List the environments in which these changes were tested.
Tested on:

Mug
Local development environment

Test description:
How were the changes tested and success verified? If schema changes were part of this change, how were those handled in your upgrade/downgrade testing?

Were the install/upgrade-based validation checks/tests run (goss tests/install-validation doc)? N/A
Were continuous integration tests run? If not, why? N/A
Was upgrade tested? If not, why? Y
Was downgrade tested? If not, why? N
Were new tests (or test issues/Jiras) created for this change? N

Mug testing
Ran the modified script on Mug, and 2 errors reports are expected (ncn-m001 BMC and the phantom Intel CMC).
HSM Cabinet Summary
===================
x3000 (River)
  Discovered Nodes:          19 (14 Mgmt, 1 Application, 4 Compute)
  Discovered Node BMCs:      18
  Discovered Router BMCs:     1
  Discovered Chassis BMCs:    0
  Discovered Cab PDU Ctlrs:   0
x3001 (River)
  Discovered Nodes:           5 (5 Mgmt, 0 Application, 0 Compute)
  Discovered Node BMCs:       5
  Discovered Router BMCs:     0
  Discovered Chassis BMCs:    0
  Discovered Cab PDU Ctlrs:   0

River Cabinet Checks
====================
x3000
  Nodes: PASS
  NodeBMCs: WARNING
    - x3000c0s1b0 - Not found in HSM Components; No mgmt port connection; BMC of mgmt node ncn-m001.
  RouterBMCs: PASS
  ChassisBMCs/CMCs: FAIL
    - x3000c0s19b999 - Not found in HSM Components; Not found in HSM Redfish Endpoints; No mgmt port connection.
  CabinetPDUControllers: PASS
x3001
  Nodes: PASS
  NodeBMCs: PASS
  RouterBMCs: PASS
  ChassisBMCs/CMCs: PASS
  CabinetPDUControllers: PASS

Mountain/Hill Cabinet Checks
============================
None Found.

Local testing
Simulated environment using hms-simulation-environment with a Hill system with CSI data generated from this PR https://github.com/Cray-HPE/cray-site-init/pull/203
HSM Cabinet Summary
===================
x3000 (River)
  Discovered Nodes:          13 (10 Mgmt, 2 Application, 1 Compute)
  Discovered Node BMCs:      13
  Discovered Router BMCs:     2
  Discovered Chassis BMCs:    0
  Discovered Cab PDU Ctlrs:   0
x9000 (Hill)
  Discovered Nodes:          64
  Discovered Node BMCs:      32
  Discovered Router BMCs:    16
  Discovered Chassis BMCs:    2

River Cabinet Checks
====================
x3000
  Nodes: PASS
  NodeBMCs: WARNING
    - x3000c0s1b0 - No mgmt port connection; BMC of mgmt node ncn-m001.
  RouterBMCs: PASS
  ChassisBMCs/CMCs: PASS
  CabinetPDUControllers: WARNING
    - x3000m1 - Not found in HSM Components; Not found in HSM Redfish Endpoints.
    - x3000m0 - Not found in HSM Components; Not found in HSM Redfish Endpoints.

Mountain/Hill Cabinet Checks
============================
x9000 (Hill)
  ChassisBMCs: PASS
  Nodes: PASS
  NodeBMCs: PASS
  RouterBMCs: PASS

Risks and Mitigations
Are there known issues with these changes? Any other special considerations?
Low risk.
Pull Request Checklist

[ ] Version number(s) incremented, if applicable
[ ] Copyrights updated
[ ] License file intact
[ ] Target branch correct
[ ] CHANGELOG.md updated
[ ] Testing is appropriate and complete, if applicable
[ ] HPC Product Announcement prepared, if applicable

@schooler-hpe has a PR in flight to make additonal changes to the ./verify_hsm_discovery.py script with a version bump. Going to let that one merge first, and then I'll fix the version for this PR to prevent conflicts: https://github.com/Cray-HPE/hpe-csm-scripts/pull/19

Rebased ontop of master after merging #21


flutter drive crashes

Attempted to just run flutter drive in examples/flutter_gallery to validate if https://github.com/flutter/flutter/issues/5800 was still a bug. :)
command
flutter drive
exception
NoSuchMethodError: The method '[]' was called on null.
Receiver: null
Tried calling:
dart:core                                                         Object.noSuchMethod
package:flutter_tools/src/ios/simulators.dart 807                 compareIphoneVersions
package:flutter_tools/src/ios/simulators.dart 129                 SimControl._findSuitableDeviceType.<fn>
dart:collection                                                   Object&ListMixin.sort
package:flutter_tools/src/ios/simulators.dart 129                 SimControl._findSuitableDeviceType
package:flutter_tools/src/ios/simulators.dart 102                 SimControl._createTestDevice
package:flutter_tools/src/ios/simulators.dart 65                  SimControl.boot.<async>
===== asynchronous gap ===========================
dart:async                                                        _Completer.completeError
package:flutter_tools/src/ios/simulators.dart 101                 SimControl.boot.<async>
===== asynchronous gap ===========================
dart:async                                                        Future.Future.microtask
package:flutter_tools/src/ios/simulators.dart                     SimControl.boot
package:flutter_tools/src/commands/drive.dart 224                 findTargetDevice.<async>
dart:async                                                        _SyncCompleter.complete
package:flutter_tools/src/device.dart 72                          DeviceManager.getAllConnectedDevices.<async>
===== asynchronous gap ===========================
dart:async                                                        _asyncThenWrapperHelper
package:flutter_tools/src/commands/drive.dart                     findTargetDevice
package:flutter_tools/src/commands/drive.dart 95                  DriveCommand.runCommand.<async>
===== asynchronous gap ===========================
dart:async                                                        Future.Future.microtask
package:flutter_tools/src/commands/drive.dart                     DriveCommand.runCommand
package:flutter_tools/src/runner/flutter_command.dart 148         FlutterCommand.verifyThenRunCommand.<async>
dart:async                                                        _SyncCompleter.complete
package:flutter_tools/src/dart/pub.dart 67                        pubGet.<async>
dart:async                                                        _SyncCompleter.complete
package:flutter_tools/src/base/process.dart 113                   runCommandAndStreamOutput.<async>
===== asynchronous gap ===========================
dart:async                                                        _asyncThenWrapperHelper
package:flutter_tools/src/runner/flutter_command.dart             FlutterCommand.verifyThenRunCommand
package:flutter_tools/src/commands/drive.dart 86                  DriveCommand.verifyThenRunCommand.<async>
===== asynchronous gap ===========================
dart:async                                                        Future.Future.microtask
package:flutter_tools/src/commands/drive.dart                     DriveCommand.verifyThenRunCommand
package:flutter_tools/src/runner/flutter_command.dart 119         FlutterCommand.run
package:args/command_runner.dart 194                              CommandRunner.runCommand.<async>
===== asynchronous gap ===========================
dart:async                                                        Future.Future.microtask
package:args/command_runner.dart                                  CommandRunner.runCommand
package:flutter_tools/src/runner/flutter_command_runner.dart 212  FlutterCommandRunner.runCommand.<async>
dart:async                                                        _SyncCompleter.complete
package:flutter_tools/src/cache.dart 73                           Cache.lock.<async>
===== asynchronous gap ===========================
dart:async                                                        _asyncThenWrapperHelper
package:flutter_tools/src/runner/flutter_command_runner.dart      FlutterCommandRunner.runCommand
package:args/command_runner.dart 109                              CommandRunner.run.<fn>
dart:async                                                        Future.Future.sync
package:args/command_runner.dart 109                              CommandRunner.run
package:flutter_tools/src/runner/flutter_command_runner.dart 150  FlutterCommandRunner.run
package:flutter_tools/executable.dart 124                         main.<async>.<fn>.<fn>.<async>
===== asynchronous gap ===========================
package:stack_trace                                               Chain.capture
package:flutter_tools/executable.dart 123                         main.<async>.<fn>
package:flutter_tools/src/base/context.dart 76                    AppContext._run.<async>

flutter doctor
[✓] Flutter (on Mac OS, channel master)
    • Flutter at /src/flutter
    • Framework revision e8c6d871fd (4 months ago), 2016-10-19 16:17:55
    • Engine revision cbf49d0652
    • Tools Dart version 1.22.0-dev.10.5

[✓] Android toolchain - develop for Android devices (Android SDK 23.0.2)
    • Android SDK at /Users/eseidel/Library/Android/sdk
    • Platform android-23, build-tools 23.0.2
    • Java(TM) SE Runtime Environment (build 1.8.0_91-b14)

[✓] iOS toolchain - develop for iOS devices (Xcode 8.2.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 8.2.1, Build version 8C1002
    • ios-deploy 1.9.1

[✓] IntelliJ IDEA Community Edition (version 2016.3.3)
    • Dart plugin version 163.11306
    • Flutter plugin version <IP_ADDRESS>

[✓] Connected devices
    • None

I think this is fixed (at least it just worked for me).
% flutter drive
Using device Android SDK built for x86.
Test file not found: /Users/gspencer/code/flutter/examples/flutter_gallery/test_driver/main_test.dart

Closing because I can't repro it.


bug: Dialog's closeOnOutsideClick no longer works with Svelte 5 update

Describe the bug
As title. Props like closeOnOutsideClick and closeOnEscape from the primitive code in bits-ui no longer works after migrating to Svelte 5.
Reproduction
<Dialog.Root closeOnOutsideClick={true}>
    <Dialog.Content>
        <Dialog.Header>
            <Dialog.Title>Title</Dialog.Title>
            <Dialog.Description>
                Description
            </Dialog.Description>
        </Dialog.Header>
        Content
    </Dialog.Content>
</Dialog.Root>

Logs
No response
System Info
System:
    OS: Windows 10 10.0.26100
    CPU: (16) x64 AMD Ryzen 7 5800H with Radeon Graphics
    Memory: 1.90 GB / 13.86 GB
  Binaries:
    Node: 22.11.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 10.8.2 - C:\Program Files\nodejs\npm.CMD
    pnpm: 9.12.3 - ~\AppData\Local\pnpm\pnpm.EXE
  Browsers:
    Edge: Chromium (130.0.2849.80)
    Internet Explorer: 11.0.26100.1882

Severity
annoyance

What @ieedan said 😃


Adding endpoint to switch entity

Hi, I fix name, undefined value and "if"s from it. And unblock rename on zbbridge if endpoint is not defined.

I fixed some things using the online editor. now it should be okay to merge...

Perfect, thank you. Will you propagate it to npm?

I’ve changed it a bit... 😀  The endpoint can be entered in the address field now because the separate endpoint field was too big. It is also (automatically) supported for other device types.
Published 0.12.2 few minutes ago.

:) it's fine, maybe I will use it in my new house :) Currently I have only 2 zigbee devices and need endpoint just for full control one of them.

:) it's fine, maybe I will use it in my new house :) Currently I have only 2 zigbee devices and need endpoint just for full control one of them.


Remove the reactor switch_block_header field

And replace it with storage reads.
Fixes #3852

I'll jump into review after we clarify if the failing test is not a regression.

bors try

@Boiethios @rafal-ch has this PR been abandoned, or is there a plan to get it mergeable?

@EdHastingsCasperLabs should be abandoned, @alsrdn took care of removing the switch_block_header in a different PR as a side-effect.


added euclidean gcd of 'n' numbers and fibonacci series(using dp) in C++

This PR implements Euclidean GCD for 'n' numbers in C++. As input, it takes n inputs and returns gcd as output. closes #67 #68

Thanks for contributing.


Consider using stronger randomness in BLS batch verification

I don't believe we genuinely need high quality randomness for performing batch verification. Any potential attacker is severely constrained in what they can attempt here, even if they can gain some knowledge of the RNG output. Nonetheless, a couple of people have raised this recently, and for the sake of a quiet life it may be worth improving the randomness.
We should validate whether the comment about SecureRandom still applies. If the performance impact is negligible, we should move over to using SecureRandom.
https://github.com/ConsenSys/teku/blob/d0bd4d06848fe62fc1ae5088e37b4dd62d949e33/bls/src/main/java/tech/pegasys/teku/bls/impl/blst/BlstBLS12381.java#L40-L48

SecureRandom can definitely block on lack of entropy even on the most recent JDKs but that is because it reads from /dev/random when creating its initial seed.  But as long as we are reusing a single instance of SecureRandom it shouldn't block and fortunately SecureRandom is thread safe, unlike the plain Random.


[SIL] Represent copies to and from @sil_weak values.

Introduce two new instructions:

strong_copy_weak_value
weak_copy_value

These are transformed by AddressLowering to, respectively:

load_weak
store_weak

The effect of strong_copy_weak_value %o : $@sil_weak Optional<T> is to
increment the strong reference count of the value in the .some if any.
The effect of weak_copy_value %o : $Optional<T> is to increment the weak
reference count of the value in the .some case if any.

@swift-ci please test

@swift-ci please test windows platform

@swift-ci please test linux platform

@swift-ci please test linux platform

@swift-ci please test linux platform

@swift-ci please test linux platform

@swift-ci please test

@swift-ci please test macos platform

@swift-ci please test

@atrick Added that verification in https://github.com/apple/swift/pull/67690/commits/2396f97410eade706a865adf98e940f85b80dbad since there was a conflict resolve anyway.

@swift-ci please test

@swift-ci please test


isUrl - host_whitelist array option - support array items containing regex/wildcard value

As the title says, it would be cool if I could do:
validator.isUrl(url, {host_whitelist: [
    /^.*slack\.com$/,
]});

This way I could allow dynamic sub-domains in url strings.
Thanks for sharing your work!

Happy to accept a PR :smile:


"pointerout" interaction event triggers after disableInteractive()

Version

Phaser Version:
3.55.2
Operating system:
Win 10
Browser:
Opera 78.0.4093.184 (only tested here)

Description
I have a polygon GameObject with setInteractive() and a few on() events.
Events trigger fine, except that the "pointerout" event still triggers once after I call disableInteractive().
This is probably easier to understand by looking at the code.
If I am missing something obvious then I am truly sorry.
Problem goes away if I call removeAllListeners() after disableInteractive().
Example Test Code
  const polyPoints = [cell.topLeft, cell.topRight, cell.bottomRight, cell.bottomLeft];
  const poly = this.scene.add
    .polygon(0, 0, polyPoints)
    .setOrigin(0)
    .setInteractive(new Phaser.Geom.Polygon(polyPoints), Phaser.Geom.Polygon.Contains)
    .disableInteractive()
    .setStrokeStyle(
      boardStrokeConfigs.DEFAULT.width,
      boardStrokeConfigs.DEFAULT.color,
      boardStrokeConfigs.DEFAULT.alpha,
    ).on("pointerover", () => {
      this.applyStrokeConfigToCellPoly(
        ...getCellRanks(c),
        boardStrokeConfigs.OVER_TARGET,
        true,
      );
    })
    .on("pointerout", () => {
// still triggers once after call to disableCellInteraction()
// doesn't matter how long I wait before I move the mouse
      this.applyStrokeConfigToCellPoly(
        ...getCellRanks(c),
        boardStrokeConfigs.VALID_TARGET,
        true,
      );
    });

  disableCellInteraction = () => {
    this.forEachCell((c) => {
      this.cellPolys[c.row][c.col].disableInteractive();
    });
  };

  enableCellInteraction = (onclick: (cell: BoardCell) => void) => {
    this.disableCellInteraction();
    this._activePawnAction?.getValidTargetCells().forEach((c) => {
      this.cellPolys[c.row][c.col]
        .setInteractive()
        .on("pointerup", () => onclick(c));
    });
  };

Reproducible even with such a simple example:
https://codesandbox.io/s/phaser-github-issue-5828-svk2z?file=/src/index.js

This issue also applies to at least POINTER_OUT, DRAG_END, DRAG_ENTER and DRAG_LEAVE events. I've updated CodeSandbox to reflect these events.

Thank you for submitting this issue. We have fixed this and the fix has been pushed to the master branch. It will be part of the next release. If you get time to build and test it for yourself we would appreciate that.


SSL problem

AbstractDecoder.php initFrom() should have additional parameters to ignore SSL problems
"ssl"=>array(                 "verify_peer"=>false,                 "verify_peer_name"=>false,             )
Or should it be possible to inject the $options variable.

The integration of the option to read data directly via URLs was a mistake. The task of this library is image manipulation. Reading data via HTTP should be done by a corresponding client. For this reason, Intervention Image Version 3 does not support reading URLs.


Better organizing the JuliaGeo efforts

Based on the how to create a leaner ecosystem discussion on Discourse, I think it would be beneficial for our organization if we could make more explicit somehow the main authors/maintainers of packages that are part of the organization. I see that we discuss some of these details in our Wiki pages here but that doesn't seem to preserve the power of the author/creator of the package to decide what is aligned with his/her original vision for the project, and what can be merged into the packages. I suggest that we brainstorm a guideline for acknowledging the leading author(s) for each package in the organization in a way that org members understand that this same authors will have the final word about proposed code changes. If we can achieve such guideline where contributors need to contact the leading authors before merging PRs, I think the organization will become a safe environment for more packages in the ecosystem. I am particularly considering moving the GeoStats.jl stack to JuliaGeo if that is seen as something useful here.
On a related topic, I think we need to review the current packages under the JuliaGeo umbrella, and update our Wiki pages or website to reflect which packages are maintained still and who are the leading authors. I personally think that the website should be the central point of communication and updates, and that our Wiki pages on GitHub could be moved therein. Particularly, we need to update the existing libraries page and migrate it to the website if it is not there yet.
Could you please share your thoughts on how we could proceed? Can we start by archiving dead projects or projects that authors don't have the intent to maintain and update? After we have a cleaned list of packages that are maintained, we can start brainstorming overlaping features, and mapping what features are missing the JuliaGeo ecosystem.
I appreciate your input on these issues, and I am looking forward to discussing them more.

Also do we have guidelines for the functions of each member in the organization? Unlike other organizations which I am part of like JuliaImages, the JuliaGeo organization has too many owners as opposed to members. Ownerwship of organizations could also be discussed here because they give too much power to the person in the organization.
I wonder if we can have a contributorship file stating the reasons for why each person was added to the org. Contributorship is a concept that is becoming popular in journals, and I think we will hardly improve the status quo without considering it carefully: https://www.mdpi.com/2304-6775/7/3/48/htm

Thanks for raising some of these points Júlio. Perhaps "Better organizing the JuliaGeo efforts" is a bit of a broad issue in a repo "For discussion centered around the JuliaGeo organization" ;)
I'll comment on a few points:
I think it may be good to explicitly mention the authors and current maintainers for the different packages. Note that these are not always the same person. I can understand your point about authors having the final word, and believe that in practice this already happens, but it's fine to make it more explicit.
Regarding the website, I agree that we should move the wiki pages to the website, it will probably be more visible there. There is a more recent existing libraries page already on the site, but it would be nice to update and expand it.
Which projects were you thinking about to archive dead projects? I don't see any under JuliaGeo.
Regarding JuliaGeo owners, I agree there are too many, there should probably be only a few. If you are one now and don't think you need to be, let us know and we can make you a regular member (doesn't seem like you can do it yourself). The main reason I think we have so many owners is because people need to be owner to move stuff in. But for this we should probably only make them a temporary owner. And perhaps we can make better use of the Teams feature. The other reason is probably because by now the majority is owner, it seems more in line with the rest... Probably a more pressing concern though is people not having 2FA enabled. Especially in combination with being an owner this is dangerous. So if you read this and don't have 2FA enabled, please do so now! We could move toward requiring two-factor authentication in JuliaGeo in the future.

Which projects were you thinking about to archive dead projects? I don't see any under JuliaGeo.

Thank you @visr , I don't have any specific project in mind, just saw some packages with little activity or packages that seemed redundant at a first glance.

If you are one now and don't think you need to be, let us know and we can make you a regular member (doesn't seem like you can do it yourself). The main reason I think we have so many owners is because people need to be owner to move stuff in. But for this we should probably only make them a temporary owner.

So only owners can move packages to the org? I understand why there are so many now. I agree this should be a temporary feature. Also, GitHub Teams are a great idea.

Probably a more pressing concern though is people not having 2FA enabled. Especially in combination with being an owner this is dangerous.

I fully agree. I got scared when I saw so many people without 2FA in the organization.

I've messaged people asking to enable 2FA. We should be able to enforce it quite soon.

I am particularly considering moving the GeoStats.jl stack to JuliaGeo if that is seen as something useful here.

Since there has been some discussion on scope recently in various threads, I attempted to summarize and clarify if now on https://juliageo.org/, see the "GitHub organizations" header. Geostatistics is particularly interesting, because it can both be seen as generally useful to other geoscience domains, as well as its own domain. So something could be said for moving it here, and for creating a geostatistics domain org. I'm fine with either. To control the rights better, we should probably set up a geostats team, and move away from the current single team setup.

Everybody now enabled 2FA, so I just made it a organization requirement in the settings. Thanks all!
Regarding the move of the GeoStats stack. Júlio created JuliaEarth and moved it in there. To prevent overlap between the two organisations, I now think it's best to focus on geospatial tools in this GitHub organization. JuliaEarth will focus on geoscience instead.
There are many issues raised here, but for further discussion on those it may be better to open dedicated issues.

So from @juliohm points and some added:

[ ] Create a contributors (as in https://help.github.com/en/github/building-a-strong-community/setting-guidelines-for-repository-contributors) for packages and the org
[ ] In the above, clearly define the role of the package owner, if any. Júlio can you weigh in about the research aspect of this, if any? Maybe create a citation (https://github.com/citation-file-format/citation-file-format) file as well?
[ ] Further migrate wiki to site and deprecate wiki.
[x] Enable 2FA for at least all owners
[ ] Archive all dead/non-maintained packages, although I think these are only the builders if we move to JuliaPackaging/Yggdrasil
[ ] Clean up owners and create teams, but this does require much care to get right

Good to have a clear list. Anyone, feel free to pick up something if you want.
Regarding 2FA, it is currently already enforced for everyone, not just the owners (only option).
And archiving projects is not really a TODO since there is nothing to archive at the moment. But yes, once we've switched over the other builders to Yggdrasil, we should archive them too.

Further migrate wiki to site and deprecate wiki.

I'm checking the box for migrating from the wiki, since it's been done in https://github.com/JuliaGeo/meta/pull/11 and subsequent PRs. Let me know if there's anything else to be done for it.

@yeesian that PR moved things from the wiki to files in the meta repo. Already an improvement, but I was thinking about moving it to juliageo.org.


[Meta] Add javadocs

Description
This is a meta issue to track javadoc progress for all modules that are currently missing javadocs. Once javadocs are added, we can enable missingJavadoc task as part of gradle checks, to enable strict javadoc validation.
How to reproduce
<Needs update once #721 is merged>

Clone the repo (default main branch) and switch to remote javadoc branch (Note: javadoc branch is deprecated now)
Run ./gradlew missingJavadoc
Check the javadoc-output.txt file for failures due to missing javadocs

Logs
* Where:
Script '/Users/setiah/projects/odfe/search/gradle/missing-javadoc.gradle' line: 260

* What went wrong:
Execution failed for task ':build-tools:missingJavadoc'.
> Javadoc generation failed for :build-tools,
    Options file at: /Users/setiah/projects/odfe/search/buildSrc/build/tmp/missingJavadoc/javadoc-options.txt
    Command output at: /Users/setiah/projects/odfe/search/buildSrc/build/tmp/missingJavadoc/javadoc-output.txt <--------

Subtasks
Currently most modules are failing javadoc validations due to missing javadocs.

[ ] :benchmarks
[ ] :build-tools
[ ] :build-tools:reaper
[ ] :client:benchmark
[ ] :client:client-benchmark-noop-api-plugin
[x] :client:rest
[ ] :client:rest-high-level
[x] :client:sniffer
[ ] :client:test
[ ] :client:transport
[ ] :distribution:tools:java-version-checker
[ ] :distribution:tools:keystore-cli
[ ] :distribution:tools:launchers
[ ] :distribution:tools:plugin-cli
[ ] :doc-tools
[ ] :example-plugins:custom-settings
[ ] :example-plugins:custom-significance-heuristic
[ ] :example-plugins:custom-suggester
[ ] :example-plugins:painless-whitelist
[ ] :example-plugins:rescore
[ ] :example-plugins:rest-handler
[ ] :example-plugins:script-expert-scoring
[ ] :libs:opensearch-cli
[ ] :libs:opensearch-core
[ ] :libs:opensearch-dissect
[ ] :libs:opensearch-geo
[ ] :libs:opensearch-grok
[ ] :libs:opensearch-nio
[ ] :libs:opensearch-plugin-classloader
[ ] :libs:opensearch-secure-sm
[ ] :libs:opensearch-ssl-config
[ ] :libs:opensearch-x-content
[ ] :modules:aggs-matrix-stats
[ ] :modules:analysis-common
[ ] :modules:geo
[ ] :modules:ingest-common
[ ] :modules:ingest-geoip
[ ] :modules:ingest-user-agent
[ ] :modules:lang-expression
[ ] :modules:lang-mustache
[ ] :modules:lang-painless
[ ] :modules:lang-painless:spi
[ ] :modules:mapper-extras
[ ] :modules:opensearch-dashboards
[ ] :modules:parent-join
[ ] :modules:percolator
[ ] :modules:rank-eval
[ ] :modules:reindex
[ ] :modules:repository-url
[ ] :modules:systemd
[ ] :modules:transport-netty4
[ ] :plugins:analysis-icu
[ ] :plugins:analysis-kuromoji
[ ] :plugins:analysis-nori
[ ] :plugins:analysis-phonetic
[ ] :plugins:analysis-smartcn
[ ] :plugins:analysis-stempel
[ ] :plugins:analysis-ukrainian
[ ] :plugins:discovery-azure-classic
[ ] :plugins:discovery-ec2
[ ] :plugins:discovery-ec2:qa:amazon-ec2
[ ] :plugins:discovery-gce
[ ] :plugins:discovery-gce:qa:gce
[ ] :plugins:ingest-attachment
[ ] :plugins:mapper-annotated-text
[ ] :plugins:mapper-murmur3
[ ] :plugins:mapper-size
[ ] :plugins:repository-azure
[ ] :plugins:repository-gcs
[ ] :plugins:repository-hdfs
[ ] :plugins:repository-s3
[ ] :plugins:store-smb
[ ] :plugins:transport-nio
[ ] :qa:die-with-dignity
[ ] :qa:os
[ ] :qa:wildfly
[ ] :rest-api-spec
[ ] :server (#3128, #3155, #3163)
[ ] :test:external-modules:test-delayed-aggs
[ ] :test:fixtures:azure-fixture
[ ] :test:fixtures:gcs-fixture
[ ] :test:fixtures:hdfs-fixture
[ ] :test:fixtures:old-elasticsearch
[ ] :test:fixtures:s3-fixture
[ ] :test:framework
[ ] :test:logger-usage

How to help
Please add javadocs for the module you work on. Validate the module using the missingJavadoc gradle task.
For example, if you are adding javadocs for :client:rest module, you can validate your changes using command ./gradlew :client:rest:missingJavadoc command.

Hi @setiah, do you have plan to add missing javadocs for this list of modules? how to track the progress?

Hey @anasalkouz adding javadocs for all modules is a behemoth effort which we need to divide and conquer with the help from community. Evaluating other priorities, we need to bring this in our sprint planning and conquer module-by-module and parallelize where possible. For some modules like server, which are huge in themselves, might need to be further  split this into sub-tasks. As we add javadocs, we need to remove those modules from the exclusion list for javadoc checks. Again, this is a behemoth task which might need to evaluated against other priorities, but definitely something we should be looking into.

Given that we have a number of plugins extending internal class functionality that shouldn't be extended, I am going to start pushing progress toward enabling the missingJavadoc gradle task so we can start enforcing documentation on public classes and methods.
This will also include two new javadoc annotations (@opensearch.internal and @opensearch.experimental) for documenting internal classes that should not be extended in external plugins.
NOTE: THIS SHOULD NOT ACT AS A SUBSTITUTE FOR USING GOOD CLASS/METHOD MODIFIERS (e.g., final, private, protected, and public).

@nknize how should we take this forward so that respective teams can pick up and we make progress on this meta issue?

Should we "javadocument" testcase or ignore them for now ?

@ker2x I would skip tests.


Silence errors by default, allow unsilencing them?

@mulimoen I had this idea for a while now, and most libraries actually do the same:
Errors should be silenced by default, and can be unsilenced purposefuly, e.g. when debugging something. We capture the entire error stack anyway on every error, so there's no need to dump stuff to console at the same time.
(also look at the readme example! would be nice to remove it from there)

There is tons of functionality regarding errors, we can definitely be a bit smarter about this, e.g.:

Extend the error type to grab the error stack on error, and let the user deal with the backtrace (this we partially do already)
Register a class to handle errors (forward to log?)

The first one we kind of already do (although it's very expensive because of the backtrace extraction; so if there's any logic relying on catching errors it will be very slow).
Adding an error handler sounds pretty cool, but you could do it yourself on the outside, no? If you have a Result<>, you can choose if you want to forward the error to log or not, yourself?
Whichever the case, I think that by default the errors should be silenced, unlike the current default.

I fully agree errors should be silenced by default, should be easy to hook up the /dev/zero handler in LIBRARY_INIT. I think a PR focusing on this should addiionally simplify ErrorStack a bit, instead of expanding it would be cheaper to pop off the error object (the hid) and expand at a later time.

@mulimoen in multi-threading scenarios, errors are still shown. This can be also seen e.g. during cargo test as cargo runs the tests in multiple threads.
Is there a way to silence the errors also when using multiple threads to access an hdf5 dataset?

@Rikorose The current stack is a thread local variable, and the error printer is not set for all error stacks. Could you try calling sync(||{}) before spawning threads and check if that silences the errors? Could be that we have to check TLS and call silence_errors for each thread and not just on the first we encounter

Does not seem to work. I am using the global rayon thread pool for multi threadding:
hdf5::sync::sync(|| {});
let mut poolbuilder = rayon::ThreadPoolBuilder::new();
poolbuilder = poolbuilder.start_handler(|_| hdf5::sync::sync(|| {}));
poolbuilder.build_global()?;

I am still seeing errors like:
HDF5-DIAG: Error detected in HDF5 (1.10.4) thread<PHONE_NUMBER>92736:
  #000: ../../../src/H5G.c line 470 in H5Gopen2(): unable to open group
    major: Symbol table
    minor: Can't open object
  #001: ../../../src/H5Gint.c line 318 in H5G__open_name(): group not found
    major: Symbol table
    minor: Object not found
  #002: ../../../src/H5Gloc.c line 422 in H5G_loc_find(): can't find object
    major: Symbol table
    minor: Object not found
  #003: ../../../src/H5Gtraverse.c line 851 in H5G_traverse(): internal path traversal failed
    major: Symbol table
    minor: Object not found
  #004: ../../../src/H5Gtraverse.c line 627 in H5G__traverse_real(): traversal operator failed
    major: Symbol table
    minor: Callback failed
  #005: ../../../src/H5Gloc.c line 378 in H5G__loc_find_cb(): object '8338192746772258105' doesn't exist
    major: Symbol table
    minor: Object not found


Increase MySQL wait_timeout value for SEGS on test servers

In the [mysqld] section of my.cnf or my.ini on the pair of test servers, set the wait_time (and optionally the interactive_timeout) value to 604800 (7 days.) It is currently set to 28800 (8 hours.) This requires a restart of the database server and can be validated with the following query:
SELECT @@global.wait_timeout, @@session.wait_timeout;

This will be an OK workaround while we wait for a permanent fix for the "MySQL server has gone away" issue.

Implemented and validated on both test servers (MySQL and SEGS services have also been restarted on both hosts):
SELECT @@global.wait_timeout, @@session.wait_timeout;
+-----------------------+------------------------+
| @@global.wait_timeout | @@session.wait_timeout |
+-----------------------+------------------------+
|                604800 |                 604800 |
+-----------------------+------------------------+
1 row in set (0.00 sec)


Support for BLE and BTP

Currently runs on Linux/BlueZ only, but adding support for another BLE stack should be easy (user needs to implement the GattPeripheral trait - and - we might add out of the box BLE/GATT box implementations to rs-matter over time, as we did for mDNS).
Keeping as Draft for now, as the code needs to be tested on MCUs (doing this just now with ESP-IDF + Bluedroid) and needs unit tests.

@kedars @andreilitvin I think this PR is ready for review.
Overall, I've been using this BTP implementation as my daily driver: primarily with Espressif's Bluedroid stack adaptation, but also with the Linux BlueZ stack which has wrappers as part of this PR.
The code has unit tests now. While I don't think these are anywhere near complete, I hope the foundation is solid, as with their framework in-place, we should be able to test most aspects of the BTP stack.
There's also a new demo - onoff_light_bt that does commissioning over BT (and a TODO to start merging "common" code between this new, and the pre-existing Ethernet examples).
In terms of issues, only two, hopefully neither of those a problem for merging (and both BlueZ-specific and non-existant with Bluedropid):

The Gatt MTU reported by BlueZ does not match the actual MTU reported in the BTP Handshake Request. Might, or might not be a bug in the bluer lib itself
During commissioning via Bluetooth I get a "pair" popup on my Android phone.

Forgot to say: this code is all new in that it does not touch/change pre-existing metaphors. Everything necessary to implement pluggable protocols (today - BTP, tomorrow - TCP) had been merged already.

@andreilitvin Many thanks for the code review so far!

For your convenience, I took the freedom to mark with "Resolved" all comments of yours where I took your suggestions with no or minimal changes. Feel free to "unresolve" them if you would like to additionally comment or you still have concerns after looking at the code I did check-in
I've left those comments where I'm pushing back - two - if I'm not mistaken, where we disagree a bit on what the naming stuff around the GattPeripheral abstraction should be

Oh - I also pushed-back on our favorite "Copyright headers" topic from before (and did mark it as "Resolved"), but really - let's first agree on what to do, and then do a one-pass regexp on all of it. Until then, I keep all headers the same, so the regexp has an easier time operating.

@andy31415 What do you think we might still need to do for this PR to land?
There are a few open items (primarily w.r.t. naming) that I feel we should not really address, but please push back if you feel otherwise. Anything else outstanding?
No rush, take your time, but just wondering where we are.

CSA member meeting caused a bit of a delay. I expect to get some time for one more pass tomorrow, expect it to check mark it then. Sorry for the delay.


Define rest/arm resource in TypeSpec

Background:
Take a look at the definition of resource:

A resource is an object with a type, associated data, relationships to other resources, and a set of methods that operate on it.

To declare a resource, we should have 1) a model, 2) several operations.
However, the existing decorator @resource we recommend to users only targets to model. It seems we don't have a way to mark "a model + its corresponding operations" as a resource.
From getArmResources, I could see the current behavior is: as long as a model is used in a template, it could be the resource model of a resource. It sounds a way to link model and operations. However, it cannot resolve the problem of https://github.com/Azure/typespec-azure/issues/1283
Proposal:

To mark a resource,

1.1 we might need something like @armResouorce(target: interface, resourceModel: Model) maybe called @restResource
@armResource(Site)
interface WebApps {
  get is ArmResourceRead<Site>;
}

@armResource(Site)
interface WebApps {
  getSlot is ArmResourceRead<Site>;
}

1.2 we might need something like
@resourceType("Microsoft.ContosoProviderHub/sites")
@resourceType("Microsoft.ContosoProviderHub/sites/slots")
model Site {}

Then when we got an operation, we could first calculate its resource type and then find out the model marked with this resource type.

To mark the hierarchy,

2.1 we might need something like @armParentResource(target: interface, parent: interface) <- pay attention the target is interface.
@armResource(Site)
interface WebApps {
  get is ArmResourceRead<Site>;
}

@armResource(Site)
@armParentResource(WebApps)
interface WebSlot {
  getSlot is ArmResourceRead<Site>;
}

2.2 we could also enable the nested interface like
@armResource(Site)
interface WebApps {
  get is ArmResourceRead<Site>;
  @armResource(Site)
  interface WebSlot {
   getSlot is ArmResourceRead<Site>;
  }
}

In ARM parlance, both Slot and Site are separate resources and should be modeled as such.  Why would they need to share a resource type?  Why are they not just two resources with similar properties?
Especially considering that both have operations, and not all are the same.
Also, can you clarify the priority of this?  Microsoft.Web jhas a GA SDK, so it should not be a prioritized conversion target in this phase.

This is related to these existing issues:

https://github.com/Azure/typespec-azure/issues/234
https://github.com/microsoft/typespec/issues/160

@markcowl the appservice site/slot case is only an example for the ambiguous relation between the model and its corresponding operations.
Our main concern right now is about "how typespec expresses the relationship between the model of a resource and the operations of the resource".
Right now, our resourcemanager related decorators/templates are not showing those explicitly. for instance, we might have this:
@resource
model Foo extends TrackedResource<FooProperties>
{
// omitted...
}

@armResourceOperations
interface Foos
{
get is ArmResourceRead<Foo>;
createOrUpdate is ArmResourceCreate<Foo>;
// etc
}

In this spec, there is no direct relationship between this model and those operations. We believe since a resource consists from a model and a few operations, this might need to be expressed explicitly.
Other language generators might not care this information, but dotnet generator needs this badly even for simplest RPs.

@markcowl the appservice site/slot case is only an example for the ambiguous relation between the model and its corresponding operations. Our main concern right now is about "how typespec expresses the relationship between the model of a resource and the operations of the resource". Right now, our resourcemanager related decorators/templates are not showing those explicitly. for instance, we might have this:
@resource("foos")
model Foo extends TrackedResource<FooProperties>
{
// omitted...
}

@armResourceOperations
interface Foos
{
get is ArmResourceRead<Foo>;
createOrUpdate is ArmResourceCreate<Foo>;
// etc
}

In this spec, there is no direct relationship between this model and those operations. We believe since a resource consists from a model and a few operations, this might need to be expressed explicitly.
Other language generators might not care this information, but dotnet generator needs this badly even for simplest RPs.

So I was told that we have an API getArmResources could provide the "model + operation association" information, which might be OK for us to use. But we kind of would like there could be decorators to show those information explicitly and/or provide compiler diagnostic if the author is mkaing a mistake, such as they define the operations that belong to the same resource into different interfaces.

Let's use https://github.com/Azure/typespec-azure/issues/234 to track. I have put some information to it.


Backplate texture affected by pixel filter

I am trying to render an image with a backplate texture to place some 2d graphics behind the 3d objects. I noticed that the background image gets blurred by the renderer's pixelFilter:
With pixelFilter set to OSP_PIXELFILTER_GAUSS:

With pixelFilter set to OSP_PIXELFILTER_POINT:

The backplate's resolution matches the framebuffer resolution and the texture filter is set to OSP_TEXTURE_FILTER_NEAREST. First, I thought the effect may be coming from the denoiser, but these pictures have been rendered without denoising filter.
Is there a way to leave the background image completely unaffected, but still get antialiasing of the rendered objects?

What would currently work is to blend the backplate in the application (e.g. while displaying OSPRay's framebuffer), using the alpha-channel of the framebuffer (which contains the "opacity" of the rendered scene).
A fix in OSPRay could look like this, essentially always using the PixelFilter POINT for the backplate:
diff --git a/modules/cpu/render/pathtracer/PathTracer.ispc b/modules/cpu/render/pathtracer/PathTracer.ispc
index 98208fe58..d86240944 100644
--- a/modules/cpu/render/pathtracer/PathTracer.ispc
+++ b/modules/cpu/render/pathtracer/PathTracer.ispc
@@ -205,7 +205,7 @@ static ScreenSample PathTracer_renderPixel(PathTracer *uniform self,

     screenSample.ray.t = min(screenSample.ray.t, tMax);

-    pathContext.screen = cameraSample.screen;
+    pathContext.screen = cameraSample.pixel_center;
     ScreenSample sample = PathTraceIntegrator_Li(
         pathContext, pathState, screenSample.ray, screenSample.rayCone, ffh);

Yet, the backplate will still be denoised as well when the denoiser is active, which however should be fine for text.
We'll think about changing backplate handling, implementing it as a blend step as part of the postprocessing pipeline. Here the drawback is that colored transparency affecting the background won't work with monochrome alpha blending.

Thanks a lot for the quick reply. Yes, it could be useful to have at least the option to exclude the background plate from the pixel filtering. That's what users of the map_backplate option want most of the time, I would guess.
I also considered doing the compositing in the application and not leaving it to the OSPRay renderer. However, this approach has its own pitfalls, which I was going to describe in a separate GitHub issue. Hope you don't mind if I hijack this thread now and describe two more related problems.
For one, the RGB components of the background color set on the renderer seem to always creep into the filtered pixels at the edges of an object, even if background alpha=0. The effect becomes quite pronounced when camera depth-of-field is used and the object edges are more blurry than usual:

The left picture rendered with the default backgroundColor=(0,0,0,0) looks good on a dark background, but on a light background the objects exhibit dark colors around their edges. So, my follow-up question would be, how can I render a picture with a transparent background such that it will look good when composited on any background, i.e., without knowing the background color a priori. In other words, I would like produce a rendering that can be saved as a PNG file and then placed on an arbitrary PowerPoint slide, for example.
Maybe you have a better suggestion, but a possible solution I discovered is to reinterpret the framebuffer content of OSPRay as premultipled alpha (even though it is straight alpha, I think) after rendering the image with backgroundColor=(0,0,0,0). For RGBA values with premultiplied alpha, different rules apply when combing the foreground image with the background. Here is how it looks like when treating the OSPRay framebuffer contents as premultiplied alpha:

Another thing I noticed when rendering images with a transparent background (0,0,0,0) is that the alpha channel of the framebuffer contains stochastic noise in semi-transparent object regions. I am using the path tracer backend:

While the noise in the RGB channels is successfully eliminated by the denoising filter, the noise in the alpa channel remains. This leads to a problem when composing the semi-transparent image with a white background in the application. The noise reappears in the visible RGB channels (left) - unlike in the image directly rendered on a white background by OSPRay:

Very elaborated post, thanks! I'll briefly comment

a fix for the original issue will come soon (backplate to ignore the pixelFilter)
yes, for compositing at the app side backgroundColor must be black+transparent and the correct blending mode be used (the documentation does not mention anything about pre-multiplied alpha, we should clarify that)
commit 5b053439025b2857c60a8da7222045edb2cee9f7 added a parameter to denoise the alpha channel as well
your last example also demonstrates the limitations of alpha-only blending I mentioned with respect to colored transparency: the brightness is different, because alpha is computed as a mix of the RGB transparency filter weights and thus cannot correctly regard the color of the background

the RGB components exceed the alpha component. This is not compatible with the pre-multiplied alpha interpretation

This is because alpha is computed as average of the "RGB opacity". Another view is that RGB is HDR and thus can be larger than 1.0.

the RGB components exceed the alpha component. This is not compatible with the pre-multiplied alpha interpretation

This is because alpha is computed as average of the "RGB opacity". Another view is that RGB is HDR and thus can be larger than 1.0.

Thanks for the explanation. Do you have a recommendation on how to clamp or normalize such color values for display or compositing? My observation is that a pre-multiplied alpha image in which the RGB components exceed alpha leads to “undefined behavior”, e.g. to unexpected colors of the affected pixels - depending on the software used to display the image.
My current solution is:
R' = R * alpha / max(R,G,B,alpha)
G' = G * alpha / max(R,G,B,alpha)
B' = B * alpha / max(R,G,B,alpha)

depending on the software used to display the image

If blending works in HDR (exceeding 1.0 is fine) then no adjustments are needed. Otherwise, your approach to renormalize the colors is reasonable (just exclude the alpha==0 case).

When I apply the pre-multiplied alpha scheme, they appear lighter (but still noisy due to the missing alpha channel denoising)

Here the same image rendered with OSPRay 3.2.0, alpha channel denoising, and highest-quality mode  - (looks a lot better, thanks!):


Etcd3 proxy can't get data from the same key twice.

etcd cluster: <IP_ADDRESS>:2379,<IP_ADDRESS>:2379,<IP_ADDRESS>:2379
proxy:<IP_ADDRESS>:2389
etcd version:V3.2.0
Here is the code:
 cli, _ := clientv3.New(clientv3.Config{
	Endpoints: []string{"http://<IP_ADDRESS>:2389"},
	Username:"name",
	Password:"password",
})

for i:=0;i<10;i++ {
	resp,_ := cli.Get(context.TODO(),"/warden/test")

	fmt.Printf(string(resp.Kvs[0].Value) + "\n")

	time.Sleep(1 * time.Second)
}

If i set the endpoints directly to the etcd cluster,the code works well,but if i set the endpoints to the proxy url,the code just can print one line data.

Could you provide exact steps to reproduce this issue? How did you set up etcd and proxy?

@gyuho
Here is the  etcd  flags
  etcd --name infra0 --initial-advertise-peer-urls http://<IP_ADDRESS>:2380   --listen-peer-urls http://<IP_ADDRESS>:2380   --listen-client-urls http://<IP_ADDRESS>:2379,http://<IP_ADDRESS>:2379   --advertise-client-urls http://<IP_ADDRESS>:2379   --initial-cluster-token etcd-cluster-1   --initial-cluster infra0=http://<IP_ADDRESS>:2380,infra1=http://<IP_ADDRESS>:2380,infra2=http://<IP_ADDRESS>:2380   --initial-cluster-state new
And here is the proxy flags
etcd grpc-proxy start --endpoints=<IP_ADDRESS>:2379,<IP_ADDRESS>:2379,<IP_ADDRESS>:2379 --listen-addr=<IP_ADDRESS>:2389
Thank you.

What do you mean by

code just can print one line data

Did you write the key /warden/test?

Looks like an auth bug in the proxy. I tried it and got etcdserver: user name is empty. /cc @mitake

@gyuho ,i had write the key /warden/test,and the value is 'data'
The code want print the value of the key /warden/test 10 times,but in proxy mode,the code just print the value once.

@heyitsanthony I found that current grpc proxy isn't dealing with tokens at all. We need a wrapper that extracts the token of client's connection (like https://github.com/coreos/etcd/blob/master/auth/store.go#L1000) and attach it to proxy's connection (like https://github.com/coreos/etcd/blob/master/clientv3/client.go#L330). Possibly the change would conflict with your WIP: https://github.com/heyitsanthony/etcd/commit/00b397d8a318e477c5cdcffd00309f57ebb3259d should I wait or can I work on first?
@zhuqunzhou sorry for the inconveniecne!

@mitake I've been revamping e2e so this can be caught in CI at http://github.com/heyitsanthony/etcd/tree/test-e2e-grpcproxy. Not too worried about conflicts with 00b397d8a318e477c5cdcffd00309f57ebb3259d but I'd like some way to use the client's auth so vauth  can be dropped into the proxy by replacing client.Auth.

@heyitsanthony OK, I'll try it. Thanks for the test.


New deposit verifier of vault should wait certain period to take effect

Why
In this doc: Upgradeable component and its security analysis
If I analyzed it correctly, new deposit verifier should wait some time to be able to take effect. (same issue as new vault)
The earliest time for new verifier to be able to take effect should be one min-finalization-period
Current design
It is using setDepositVerifier to directly and immediately swap the verifier to upgrade to new tx type.
Possible designs

Register verifier with version and then when time allows, upgrade to such version.
Register verifier with tx type. deposit function take tx type as input so it would knows which to use. Before calling verifier, the deposit function would check the min taking effect time.

Successful critieria
update both ERC20Vault and ETHVault

Implementer note about mentioned possible designs.
I took the 1st option, which is

when next (second, ...) deposit verifier is set on the Vault, it's registered along with its effectiveness time (now + MIN_EXIT_PERIOD)
when deposit is made after the effectiveness time new deposit verifier is swapped with currently in-force one.


Multiple clicks on feature can trigger infinite loop error

Tested this on our site and current Demo error on both. If a user clicks on a feature multiple times semi-rapidly before the GetFeatureInfo box is returned it will trigger an error that will infintly loom forcing the user to reload the page. Error displays the following message:

In the latest version of MapLoom (master branch), I'm unable to reproduce this. Is this still an issue?

@JJediny please let us know if you see this in latest build. We have not been able to reproduce this issue.


how can share all contact in telegram bot

Hi
i want sahre name and numberphone my contact whith telegram key
how can?

https://github.com/yagop/node-telegram-bot-api/blob/release/doc/api.md#TelegramBot+sendContact

i want user enter his contact from contact list in smartphone
sorry my languege is bad

How are you doing that?

Hi i want sahre name and numberphone my contact whith telegram key how can?

The Telegram Bot API don't allow you to add a contact in a smartphone, this thing is need to be done at user level.


Support adding user location in jail step

Not really sure if I should call it a bug since it's a recent addition to the jail step, but as a result, the current React frontend offers no way for a new user to add a location to the profile, which means they can't escape jail.
We currently ask the user's location during the sign up form, but it's not provided in the lat-lng format required by
rpc SetLocation(SetLocationReq) returns (JailInfoRes) {
    // Set the user's location
    // If you're not jailed, do this with api.UpdateProfile!
  }

Also it doesn't call the jail API to update the user's location.
I guess we should probably remove this in the sign up form and follow the same format as the alpha and have this as another jail step, since that field alone wouldn't allow the user to set a radius.

I am working on this currently. It's taking a while to fight with the map library :D

@lucaslcode Just had a glance at the code... did you have come up with all those trigonometry maths?!! Lol that stuff is gonna be fun to fix if there are any weird bugs in...

Some but not all! Not much to be done unfortunately. I tried to use the inbuilt project and unproject functions as much as possible.

Maybe a link to where you found those calculations or comment on how you come up with it would help in case we need to fix it in the future

Closed in #427