Fastlane supply init fails to download release notes from production track

New Issue Checklist

[x] Updated fastlane to the latest version
[x] I read the Contribution Guidelines
[x] I read docs.fastlane.tools
[x] I searched for existing GitHub issues

Issue Description
When I run the fastlane supply init command, it is expected that all the current Google Play Store metadata will be downloaded to fastlane/metadata/android.
This is not the case as the command is having challenges retrieving the release notes but successfully retrieves the rest of the metadata.
It fails with this error: [!] Version '1.0.1' for 'com.thedancercodes.fastlanedroid.todoapp' does not seem to have any release notes. Nothing to download. (FastlaneCore::Interface::FastlaneError)  although the application is live, contains release notes and has been rolled out to the public. 🤷♂
I have also correctly followed all the steps to set up supply from the fastlane docs
Command executed
fastlane supply init
Complete output when running fastlane, including the stack trace and command used
 $ fastlane supply init --verbose
[✔] 🚀
Successfully loaded Appfile at path '/Users/xxx/Projects/Android/fastlane-droid/fastlane/Appfile'
- json_key_file: '/Users/xxx/Projects/Android/fastlane-droid/google-play-json-key-file.json'
- package_name: 'com.thedancercodes.fastlanedroid.todoapp'
-------
INFO [2020-06-02 13:02:26.29]: 🕗  Downloading metadata, images, screenshots...
DEBUG [2020-06-02 13:02:26.31]: Fetching a new access token from Google...
INFO [2020-06-02 13:02:28.27]: 📝  Downloading metadata (en-US)
INFO [2020-06-02 13:02:28.27]: Writing to fastlane/metadata/android/en-US/title.txt...
INFO [2020-06-02 13:02:28.27]: Writing to fastlane/metadata/android/en-US/short_description.txt...
INFO [2020-06-02 13:02:28.27]: Writing to fastlane/metadata/android/en-US/full_description.txt...
INFO [2020-06-02 13:02:28.27]: Writing to fastlane/metadata/android/en-US/video.txt...
INFO [2020-06-02 13:02:28.27]: 🖼  Downloading images (en-US)
INFO [2020-06-02 13:02:28.27]: Downloading `featureGraphic` for en-US...
DEBUG [2020-06-02 13:02:29.15]: Initial URL received: 'https://lh3.googleusercontent.com/qEII3X8zRL5m7kC-I6yoTz4bWG3GWnvcIOhte1y5FW7buygyXQhNBEKZlmGgzlxg1hU'
DEBUG [2020-06-02 13:02:29.15]: Removed params ('') from the URL
DEBUG [2020-06-02 13:02:29.15]: URL after removing params: 'httpslh3.googleusercontent.com443/qEII3X8zRL5m7kC-I6yoTz4bWG3GWnvcIOhte1y5FW7buygyXQhNBEKZlmGgzlxg1hU'
INFO [2020-06-02 13:02:30.07]:  Downloaded - fastlane/metadata/android/en-US/images/featureGraphic.png
INFO [2020-06-02 13:02:30.07]: Downloading `icon` for en-US...
DEBUG [2020-06-02 13:02:30.50]: Initial URL received: 'https://lh3.googleusercontent.com/38zBGzDcWZHH8-bEiZWhfzekPEdJHi2PsL2UDBqoJGNNCm5dwzllQaS6FCQCH9Ng1Tw'
DEBUG [2020-06-02 13:02:30.50]: Removed params ('') from the URL
DEBUG [2020-06-02 13:02:30.50]: URL after removing params: 'httpslh3.googleusercontent.com443/38zBGzDcWZHH8-bEiZWhfzekPEdJHi2PsL2UDBqoJGNNCm5dwzllQaS6FCQCH9Ng1Tw'
INFO [2020-06-02 13:02:31.40]:  Downloaded - fastlane/metadata/android/en-US/images/icon.png
INFO [2020-06-02 13:02:31.40]: Downloading `promoGraphic` for en-US...
INFO [2020-06-02 13:02:31.81]: Downloading `tvBanner` for en-US...
INFO [2020-06-02 13:02:32.21]: Downloading `phoneScreenshots` for en-US...
DEBUG [2020-06-02 13:02:32.69]: Initial URL received: 'https://lh3.googleusercontent.com/2qOVTpg2igQqgH4cSsFjD5YuYZfmKBJIgXoBaUdhx3UEsndURLLeQUvGv8qaY4T7sg'
DEBUG [2020-06-02 13:02:32.69]: Removed params ('') from the URL
DEBUG [2020-06-02 13:02:32.69]: URL after removing params: 'httpslh3.googleusercontent.com443/2qOVTpg2igQqgH4cSsFjD5YuYZfmKBJIgXoBaUdhx3UEsndURLLeQUvGv8qaY4T7sg'
DEBUG [2020-06-02 13:02:32.69]: Initial URL received: 'https://lh3.googleusercontent.com/jif4FKqJypy8ci6aHfk1047ho2f5GhWj3qEcG_1wqKjjC4NkGM8Uuob1gXb-Cp8rI6w'
DEBUG [2020-06-02 13:02:32.69]: Removed params ('') from the URL
DEBUG [2020-06-02 13:02:32.69]: URL after removing params: 'httpslh3.googleusercontent.com443/jif4FKqJypy8ci6aHfk1047ho2f5GhWj3qEcG_1wqKjjC4NkGM8Uuob1gXb-Cp8rI6w'
DEBUG [2020-06-02 13:02:32.69]: Initial URL received: 'https://lh3.googleusercontent.com/f-BIMQ_Ina8cIJkBow3zimo1Bx1a2HLxDS0OXL_fkMwbNyvql3yX_s-1nw2ymO9koF0'
DEBUG [2020-06-02 13:02:32.69]: Removed params ('') from the URL
DEBUG [2020-06-02 13:02:32.69]: URL after removing params: 'httpslh3.googleusercontent.com443/f-BIMQ_Ina8cIJkBow3zimo1Bx1a2HLxDS0OXL_fkMwbNyvql3yX_s-1nw2ymO9koF0'
DEBUG [2020-06-02 13:02:32.69]: Initial URL received: 'https://lh3.googleusercontent.com/XdchaDGjwZDA0NiFjC9kps-_-3NidT076I4wJIqD6cdh28EY1ZV6ZxVNygurTfOSTCw'
DEBUG [2020-06-02 13:02:32.69]: Removed params ('') from the URL
DEBUG [2020-06-02 13:02:32.69]: URL after removing params: 'httpslh3.googleusercontent.com443/XdchaDGjwZDA0NiFjC9kps-_-3NidT076I4wJIqD6cdh28EY1ZV6ZxVNygurTfOSTCw'
INFO [2020-06-02 13:02:33.35]:  Downloaded - fastlane/metadata/android/en-US/images/phoneScreenshots/1_en-US.png
INFO [2020-06-02 13:02:34.19]:  Downloaded - fastlane/metadata/android/en-US/images/phoneScreenshots/2_en-US.png
INFO [2020-06-02 13:02:34.83]:  Downloaded - fastlane/metadata/android/en-US/images/phoneScreenshots/3_en-US.png
INFO [2020-06-02 13:02:35.46]:  Downloaded - fastlane/metadata/android/en-US/images/phoneScreenshots/4_en-US.png
INFO [2020-06-02 13:02:35.46]: Downloading `sevenInchScreenshots` for en-US...
INFO [2020-06-02 13:02:35.83]: Downloading `tenInchScreenshots` for en-US...
INFO [2020-06-02 13:02:36.36]: Downloading `tvScreenshots` for en-US...
INFO [2020-06-02 13:02:36.76]: Downloading `wearScreenshots` for en-US...
INFO [2020-06-02 13:02:39.02]: Found '1.0.1' in 'production' track.
Traceback (most recent call last):
        17: from /Users/xxx/.rvm/gems/ruby-2.5.5/bin/ruby_executable_hooks:24:in `<main>'
        16: from /Users/xxx/.rvm/gems/ruby-2.5.5/bin/ruby_executable_hooks:24:in `eval'
        15: from /Users/xxx/.rvm/gems/ruby-2.5.5/bin/fastlane:23:in `<main>'
        14: from /Users/xxx/.rvm/gems/ruby-2.5.5/bin/fastlane:23:in `load'
        13: from /Users/xxx/.rvm/gems/ruby-2.5.5/gems/fastlane-2.148.1/bin/fastlane:23:in `<top (required)>'
        12: from /Users/xxx/.rvm/gems/ruby-2.5.5/gems/fastlane-2.148.1/fastlane/lib/fastlane/cli_tools_distributor.rb:111:in `take_off'
        11: from /Users/xxx/.rvm/gems/ruby-2.5.5/gems/fastlane-2.148.1/supply/lib/supply/commands_generator.rb:12:in `start'
        10: from /Users/xxx/.rvm/gems/ruby-2.5.5/gems/fastlane-2.148.1/supply/lib/supply/commands_generator.rb:60:in `run'
         9: from /Users/xxx/.rvm/gems/ruby-2.5.5/gems/commander-fastlane-4.4.6/lib/commander/delegates.rb:15:in `run!'
         8: from /Users/xxx/.rvm/gems/ruby-2.5.5/gems/fastlane-2.148.1/fastlane_core/lib/fastlane_core/ui/fastlane_runner.rb:76:in `run!'
         7: from /Users/xxx/.rvm/gems/ruby-2.5.5/gems/commander-fastlane-4.4.6/lib/commander/runner.rb:476:in `run_active_command'
         6: from /Users/xxx/.rvm/gems/ruby-2.5.5/gems/commander-fastlane-4.4.6/lib/commander/command.rb:153:in `run'
         5: from /Users/xxx/.rvm/gems/ruby-2.5.5/gems/commander-fastlane-4.4.6/lib/commander/command.rb:178:in `call'
         4: from /Users/xxx/.rvm/gems/ruby-2.5.5/gems/fastlane-2.148.1/supply/lib/supply/commands_generator.rb:54:in `block (2 levels) in run'
         3: from /Users/xxx/.rvm/gems/ruby-2.5.5/gems/fastlane-2.148.1/supply/lib/supply/setup.rb:27:in `perform_download'
         2: from /Users/xxx/.rvm/gems/ruby-2.5.5/gems/fastlane-2.148.1/supply/lib/supply/client.rb:251:in `release_listings'
         1: from /Users/xxx/.rvm/gems/ruby-2.5.5/gems/fastlane-2.148.1/fastlane_core/lib/fastlane_core/ui/ui.rb:17:in `method_missing'
/Users/xxx/.rvm/gems/ruby-2.5.5/gems/fastlane-2.148.1/fastlane_core/lib/fastlane_core/ui/interface.rb:141:in `user_error!': [!] Version '1.0.1' for 'com.thedancercodes.fastlanedroid.todoapp' does not seem to have any release notes. Nothing to download. (FastlaneCore::Interface::FastlaneError)

Whenever I run fastlane supply init, the step seems to be failing with the error:
[!] Version '3.0.1' for <myPackage> does not seem to have any release notes. Nothing to download.

Environment
✅ fastlane environment ✅
Stack

Key
Value

OS
10.15.4

Ruby
2.5.5

Bundler?
true

Git
git version 2.24.1 (Apple Git-126)

Installation Source
~/.rvm/gems/ruby-2.5.5/bin/fastlane

Host
Mac OS X 10.15.4 (19E287)

Ruby Lib Dir
~/.rvm/rubies/ruby-2.5.5/lib

OpenSSL Version
OpenSSL 1.1.1d  10 Sep 2019

Is contained
false

Is homebrew
false

Is installed via Fabric.app
false

Xcode Path
/Applications/Xcode.app/Contents/Developer/

Xcode Version
11.4

System Locale

Variable
Value

LANG
en_US.UTF-8
✅

LC_ALL
en_US.UTF-8
✅

LANGUAGE

fastlane files:
`./fastlane/Fastfile`
# This file contains the fastlane.tools configuration
# You can find the documentation at https://docs.fastlane.tools
#
# For a list of all available actions, check out
#
#     https://docs.fastlane.tools/actions
#
# For a list of all available plugins, check out
#
#     https://docs.fastlane.tools/plugins/available-plugins
#

# Uncomment the line if you want fastlane to automatically update itself
# update_fastlane

default_platform(:android)

platform :android do

  # Runs before all tasks
  before_all do

   # Add SLACK_URL & make it accessible to all lanes
   ENV["SLACK_URL"]
  end

  # This lane builds our app with specified buildVariant(buildFlavor + BuildType)
  desc "Assemble Build"
  lane :assemble_build do |options|
    gradle(
      task: "assemble",
      flavor: options[:build_flavor],
      build_type: options[:build_type]
    )
  end

  desc "Run unit tests with specified buildVariant(buildFlavor + BuildType)"
  lane :unit_tests do |options|
    gradle(
      task: "test",
      flavor: options[:build_flavor],
      build_type: options[:build_type]
    )
  end

  desc "Run Instrumented tests in Firebase Test Lab"
  lane :instrumentation_tests_firebase_testlab do |options|
    assemble_build(build_flavor:options[:build_flavor], build_type:"Debug")
    @app_apk = Actions.lane_context[SharedValues::GRADLE_APK_OUTPUT_PATH]

    assemble_build(build_flavor:options[:build_flavor] + "Debug", build_type:"AndroidTest")
    @android_test_apk = Actions.lane_context[SharedValues::GRADLE_APK_OUTPUT_PATH]

    run_tests_firebase_testlab(
      project_id: ENV["FIREBASE_PROJECT_ID"],
      app_apk: @app_apk,
      android_test_apk: @android_test_apk,
      devices: [
        {
            model: "Nexus6P",
            version: "27"
        }
      ],
      delete_firebase_files: true
    )
  end

  desc "Build a debug APK"
  lane :debug_build do
    gradle(task: "clean assembleDebug")
  end

 # Note: To run this locally, add flavor & update keystore.jks to ENV['KEYSTORE_PATH']
  desc "Build a signed release APK & deploy to slack"
  lane :slack_apk_build do
    gradle(
      task: "assemble",
      build_type: "Release",
      print_command: false,
      properties: {
        "android.injected.signing.store.file" => "keystore.jks",
        "android.injected.signing.store.password" => ENV['STORE_PASSWORD'],
        "android.injected.signing.key.alias" => ENV['KEY_ALIAS'],
        "android.injected.signing.key.password" => ENV['KEY_PASSWORD'],
      }
    )
    upload_to_slack()
    slack(message: ":rocket: *Build Successful!* :rocket:")
  end

  desc "Upload APK to Slack channel"
  private_lane :upload_to_slack do |options|
    file_path = lane_context[SharedValues::GRADLE_APK_OUTPUT_PATH]
    file_name = file_path.gsub(/\/.*\//,"")
    access_token = ENV["ACCESS_TOKEN"]
    channel_name = "apks"

    sh "echo Uploading " + file_name + " to Slack"
    sh "curl https://slack.com/api/files.upload -F token=\"" + access_token + "\" -F channels=\"" + channel_name + "\" -F title=\"" + file_name + "\" -F filename=\"" + file_name + "\" -F file=@" + file_path
  end

  # Runs after all tasks. This block is called only when the executed lane is successful
  after_all do |lane|

    # Slack action
    # slack(message: ":rocket: Successful Deployment! :rocket:")
  end

  error do |lane, exception|
    slack(
      message: exception.message,
      success: false
      )
  end

  desc "Deploy latest Beta build to Crashlytics Beta"
  lane :beta do
    gradle(task: "assembleRelease")
    crashlytics
  end

  # use like this `fastlane distribute group:only-me`
  desc "Deploy latest Beta build to Firebase App Distribution"
  lane :distribute do |options|
    if options[:group]
      build_android_app(
        task: "assemble",
        flavor: "prod",
        build_type: "release"
      )

      firebase_app_distribution(
          app: ENV['FIREBASE_APP_ID_ANDROID'],
          groups: options[:group],
          release_notes: "Fastlane Droid Release Notes Updated 1.0.1",
          firebase_cli_path: "/usr/local/bin/firebase",
          firebase_cli_token: ENV['FIREBASE_CI_TOKEN']
      )
    else
      UI.user_error!("Missing group name!")
    end
  end

  desc "Deploy latest version to Google Play"
  lane :playstore do |options|
    gradle(
      task: "assemble",
      flavor: options[:build_flavor],
      build_type: options[:build_type]
    )
    upload_to_play_store # Uploads the APK built in the gradle step above and releases it to all production users
  end
end

`./fastlane/Appfile`
json_key_file(ENV["GOOGLE_PLAY_JSON_KEY_FILE_PATH"]) # Path to the json secret file - Follow https://docs.fastlane.tools/actions/supply/#setup to get one
package_name("com.thedancercodes.fastlanedroid.todoapp") # e.g. com.krausefx.app

fastlane gems

Gem
Version
Update-Status

fastlane
2.148.1
✅ Up-To-Date

Loaded fastlane plugins:

Plugin
Version
Update-Status

fastlane-plugin-firebase_app_distribution
0.1.4
✅ Up-To-Date

fastlane-plugin-run_tests_firebase_testlab
0.3.1
✅ Up-To-Date

Loaded gems

Gem
Version

did_you_mean
1.2.0

executable-hooks
1.6.0

bundler-unload
1.0.2

rubygems-bundler
1.4.5

bundler
2.0.2

CFPropertyList
3.0.2

public_suffix
2.0.5

addressable
2.7.0

atomos
0.1.3

aws-eventstream
1.1.0

aws-partitions
1.322.0

aws-sigv4
1.1.4

jmespath
1.4.0

aws-sdk-core
3.97.0

aws-sdk-kms
1.32.0

aws-sdk-s3
1.67.0

babosa
1.0.3

claide
1.0.3

colored
1.2

colored2
3.1.2

highline
1.7.10

commander-fastlane
4.4.6

declarative
0.0.10

declarative-option
0.1.0

digest-crc
0.5.1

unf_ext
<IP_ADDRESS>

unf
0.1.4

domain_name
0.5.20190701

dotenv
2.7.5

emoji_regex
1.0.1

excon
0.73.0

multipart-post
2.0.0

faraday
1.0.1

http-cookie
1.0.3

faraday-cookie_jar
0.0.6

faraday_middleware
1.0.0

fastimage
2.1.7

gh_inspector
1.1.3

jwt
2.1.0

memoist
0.16.2

multi_json
1.14.1

os
1.1.0

signet
0.14.0

googleauth
0.12.0

httpclient
2.8.3

mini_mime
1.0.2

uber
0.1.0

representable
3.0.4

retriable
3.1.2

google-api-client
0.38.0

google-cloud-env
1.3.2

google-cloud-errors
1.0.1

google-cloud-core
1.5.0

google-cloud-storage
1.26.2

json
2.3.0

mini_magick
4.10.1

multi_xml
0.6.0

plist
3.5.0

rubyzip
1.3.0

security
0.1.3

naturally
2.2.0

simctl
1.6.8

slack-notifier
2.3.2

terminal-notifier
2.0.0

unicode-display_width
1.7.0

terminal-table
1.8.0

tty-screen
0.8.0

tty-cursor
0.7.1

tty-spinner
0.9.3

word_wrap
1.0.0

nanaimo
0.2.6

xcodeproj
1.16.0

rouge
2.0.7

xcpretty
0.3.0

xcpretty-travis-formatter
1.0.0

fastlane-plugin-firebase_app_distribution
0.1.4

fastlane-plugin-run_tests_firebase_testlab
0.3.1

generated on: 2020-06-02

I have updated Fastlane from 2.149.1 to 2.150.3 (the latest version) but I am still facing the same issue.
[!] Version '1.0.1' for 'com.thedancercodes.fastlanedroid.todoapp' does not seem to have any release notes. Nothing to download.

I have same problem. is there any solution?

@BurakDizlek I am still waiting on this as well.
None so far.


SSR compatibility patch for useId(...)

I'm evaluating @react-aria for use in NerdWallet's frontend stack.
First, I'd like to complement you all.  This project is incredible.  The semantics of the hooks have me hooked.  The documentation for this project is incredibly valuable: https://react-spectrum.adobe.com/react-aria
We need SSR support in order to use this package. When I came across the following comment, it made me want to test the waters of how responsive this project is to external contributions. If y'all are receptive, we'd love to contribute more patches for SSR compatibility.

Hey thanks for reporting this! SSR support is an area we’re actively working on. We’ve just started a test suite to ensure we catch all of these issues that result from running in a non-DOM environment. See #835. If you’d like to contribute tests/fixes for these issues it would be greatly appreciated! 😃

https://github.com/adobe/react-spectrum/issues/842#issuecomment-663893152

This PR patches the useId(id) hook to be SSR compatible. It removes the use of Math.random() to seed the ids it generates in order to keep the generated id consistent between server-response and client hydration.  It replaces the random number with the current package version of @react-aria/utils, in order to keep the spirit from the comment in that file of having something visible for devs to see that multiple instances of the module are in use.
I hooked up a local babel plugin to inject the package version during babel transpilation
This patch solves ~60% of the ssr tests that are currently failing.
yarn test:ssr before:
Test Suites: 26 failed, 9 passed, 35 total
Tests:       29 failed, 9 passed, 38 total
Snapshots:   0 total
Time:        135.882s

yarn test:ssr after:
Test Suites: 12 failed, 23 passed, 35 total
Tests:       12 failed, 26 passed, 38 total
Snapshots:   0 total
Time:        74.253s, estimated 129s

P.S. for anyone else reading, the discussion concerning isomorphic ids in this react issue helped with context of this kind of issue. https://github.com/facebook/react/issues/5867
✅ Pull Request Checklist:

[x] Included link to corresponding React Spectrum GitHub Issue.
[ ] Added/updated unit tests and storybook for this change (for new code or code which already has tests).
[x] Filled out test instructions.
[ ] Updated documentation (if it already exists for this component).
[x] Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:
yarn test:ssr
Related Issues:
https://github.com/adobe/react-spectrum/issues/760
https://github.com/adobe/react-spectrum/pull/835
https://github.com/adobe/react-spectrum/pull/899
https://github.com/adobe/react-spectrum/issues/842

Thanks for looking into this and sharing how much is fixed with just this little change!

Nice! I see two potential issues here, in addition to the multiple copies issue discussed above:

The id counter probably needs to be reset for each request on the server, otherwise it will continue to be incremented across multiple requests and won't match the counter on the client.
The order of calls to useId could be different, e.g. in the case of async loaded component trees. This could mean the ids wouldn't match.

On possibility is a context to store the value to increment. Applications would be required to wrap their app in a provider component, which would set the value to zero, and be incremented by each call to useId. This would solve the multiple copies issue and the id reset issue. To solve the ordering issue with async components, you'd also need to wrap each async boundary in a new context as well. This could have a different prefix so that the ids inside each async component remain consistent as well.
All that sounds pretty complicated though, and would expose a lot of implementation details to application authors, increasing the potential for bugs. An alternative we might be able to get away with would be to just return null from useId on the server, and set the id in a useEffect on the client after mounting. That would mean server rendered components wouldn't be completely accessible prior to hydration, but this would require a lot less work on the application authors part. Since our components already have so much client side functionality, they wouldn't be terribly useful without JS anyway, so this seems ok to me.
In the future, we should be able to use React's useOpaqueIdentifier hook which is designed to support this exact use case. It doesn't appear to be supported in the current version of react we have though, so will need to wait until our minimum requirement supports it.
What do you think of these options?

An alternative we might be able to get away with would be to just return null from useId on the server, and set the id in a useEffect on the client after mounting. That would mean server rendered components wouldn't be completely accessible prior to hydration, but this would require a lot less work on the application authors part. Since our components already have so much client side functionality, they wouldn't be terribly useful without JS anyway, so this seems ok to me.

This sounds like the best option to me, and that would allow the Math.random() usage to remain untouched

Added the change to useEffect instead of useMemo, and even more ssr tests are reported passing now :+1::
Test Suites: 8 failed, 27 passed, 35 total
Tests:       8 failed, 30 passed, 38 total
Snapshots:   0 total
Time:        37.39s, estimated 76s
Ran all test suites with tests matching "^((?!v2).)*$".

removed the local babel plugin from this implementation, so with useEffect instead of useMemo and keeping the Math.random() seed for the multiple instances protection, yarn test:ssr reports:
Test Suites: 16 failed, 19 passed, 35 total
Tests:       19 failed, 19 passed, 38 total
Snapshots:   0 total
Time:        55.756s
Ran all test suites with tests matching "^((?!v2).)*$".

the babel plugin was getting in the way of the build:icons step that runs at during yarn postinstalls.  Hopefully this build makes it into the circle ci tests with this latest change.

Lots of failing tests in the circle ci build.  This module runs deep.

I have a feeling you're going to run into a problem pretty quickly right here https://github.com/adobe/react-spectrum/blob/main/packages/%40react-aria/utils/src/useId.ts#L61
at least as one of the things causing failures

When I use useMeter with Next.js, I got an Error.
Warning: Prop id did not match. Server: "react-aria-2182254204-10" Client: "react-aria-1828557377-2"
Will this PR solve the problem?
import { useMeter } from "@react-aria/meter";

type Props = {
  label: string;
  value: number;
  minValue: number;
  maxValue: number;
};

export const Meter = (props: Props) => {
  const { label, value, minValue, maxValue } = props;
  const { meterProps, labelProps } = useMeter({
    value,
    label,
    minValue,
    maxValue,
  });

  const percentage = (value - minValue) / (maxValue - minValue);
  const barWidth = `${Math.round(percentage * 100)}%`;

  return (

        {label && {label}}
        {!!label && {meterProps["aria-valuetext"]}}

  );
};

import { Meter } from "../utils/Meter";

const Index = () => {
  return (

      <Meter label={"test"} value={40} minValue={0} maxValue={100} />

  );
};

export default Index;

@benjroy so, I did a bit of investigation here, and basically concluded that the returning null approach wasn't going to work, or at least not easily. As evidenced by the failing tests, too many things depend on useId always returning a string, and not waiting for an extra useEffect before its available.
I've gone ahead and implemented the other suggestion above in #992. Basically you'll need to wrap your application in an <SSRProvider>, which will ensure consistent ids. If an <SSRProvider> is not there, then id creation will work exactly how it does today. This will allow entirely client-rendered apps to support multiple instances via a random prefix, while server rendered apps will ensure consistent ids with a counter that resets on each request. Hopefully that approach works for you.
Feel free to provide your feedback on the PR! Thanks again for getting this started. 😄


QueryInst model link is invalid > > > > Hi @vealocia ,

Hi @vealocia ,
Thanks for the efforts. It is highly possible that we can make it in this month! Would you also like to add the configs/queryinst/README.md to add the bibetex and the performance of QueryInst just like the other methods? You may also update QueryInst in the model zoo and README.md pages.

Thanks for the cooperations from all your maintainers too. All pretrained models and logs are prepared and I will update the performance and models asap. But I don't know how to upload these models and logs to your custom server (download.openmmlab.com), can you help me?

Hi @vealocia , Would you like to put them to google drive or BaiduYUN for us to download and test the model?

The share link to queryinst checkpoints is https://pan.baidu.com/s/1TVuusygUX1M6YXEIwWR9tQ passwork: hbk0

QueryInst pretrained checkpoints can be downloaded here ⬆
Originally posted by @vealocia in https://github.com/open-mmlab/mmdetection/issues/6050#issuecomment-949358824
Hi, @vealocia
Thank you for the great work.
The baidu link is invalid now. Could you provide a new link, either google drive or baidu drive is OK.

BaiduDrive: https://pan.baidu.com/s/1BPYGM15u4ieuVu156hwTWg KeyCode: kka8
GoogleDrive: https://drive.google.com/drive/folders/1DMelfiwQ1pEc8pJRW096-BML6w3o2IFU?usp=sharing

@ZwwWayne Could you please update the download link of queryinst pretrained model in READM.md and metafile? Many thanks~

BaiduDrive: https://pan.baidu.com/s/1BPYGM15u4ieuVu156hwTWg KeyCode: kka8 GoogleDrive: https://drive.google.com/drive/folders/1DMelfiwQ1pEc8pJRW096-BML6w3o2IFU?usp=sharing

Thanks for your help.

@ZwwWayne Could you please update the download link of queryinst pretrained model in READM.md and metafile? Many thanks~

I will push this process.

@ljpadam Hi, I have a question, could you tell me that this checkpoint is trained based on our latest codebase?

@ljpadam Hi, I have a question, could you tell me that this checkpoint is trained based on our latest codebase?

No, this checkpoint is trained on mmdetection 2.15 and 2.17

The link is updated by #6460.


Use mechanism to dyanmically disable javadoc for non public modules.

I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.

Not tested in PR build


unresolved import for package in a git subfolder

main.rs
use rocket_contrib::json::Json; //unresolved import
cargo.toml
rocket_contrib = {git="https://github.com/SergioBenitez/Rocket/"}

Duplicate of #6407.


Don't split cells on pipe characters inside backticks.

This is for #86. As I said over there I'm not entirely sure whether this should be considered the correct behaviour, but if it is, then this addresses that.

Looks nice. Could you add one more test - what happens if backtick is opened but not closed?
This patch in theory can do something strange if i place url with backtick into table cell, but i don't think this ever happens in real life.

Oh that's a good point actually, I don't quite know what should happen there. GitHub is a bit weird in that case:
 A |  B  | C
---|-----|---
 1 | `| | 3

produces...

A
B
C

1
`

but
 A |  B  | C
---|-----|---
 1 | ` | | 3

(with extra space) produces...

A
B
C

1
`

I'll have a look and see if I can figure out the best way of dealing with that. I don't actually understand why the first case behaves as it does - I'd have thought it should behave like the second case both times.
If it comes to it, does it matter if the first case isn't treated exactly the same as how GitHub does it?

I think, it's not principle to do 100% as gothub does. IMHO, if backtick is not closed, it worth consider it as usual char (as for text without any table)

Ok then, I've got another change and test-case that I'll commit and push now

Also, it worth to properly handle escaping for that:
\\\`|\\\` => two rows "\`"

Ok, I added treatment for the unclosed-backtick case, as well as a test for the escaping example you mentioned

could you squash to single commit?

There, all squashed :)

Published. Thanks a lot for PR!


incorrect peer dependency

warning " ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>|| ^4.0.0 || ^5.0.0 || ^6.0.0".
I am using eslint^7.0.0

Also having this issue. Just added the fixed the peer dependency and sent in a PR

Can we have a new release then to reflect this changes?

Released in 0.2.1


ARROW-4036: [C++] Pluggable Status message, by exposing an abstract delegate class.

This provides less "pluggability" but I think still offers a clean model for extension (subsystems can wrap the constructor for there purposes, and provide external static methods to check for particular types of errors).

This also assumes subsystem codes don't map to top level codes (I think I would prefer they do, but I could see them going both ways).

Codecov Report

Merging #4484 into master will increase coverage by 21.25%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##           master    #4484       +/-   ##
===========================================
+ Coverage   67.96%   89.21%   +21.25%
===========================================
  Files         676      696       +20
  Lines       74307    91836    +17529
  Branches     1253        0     -1253
===========================================
+ Hits        50501    81934    +31433
+ Misses      23559     9902    -13657
+ Partials      247        0      -247

Impacted Files
Coverage Δ

cpp/src/arrow/status-test.cc
100% <100%> (ø)

cpp/src/arrow/status.cc
37.11% <100%> (+24.06%)
:arrow_up:

cpp/src/arrow/status.h
95.95% <100%> (+22.54%)
:arrow_up:

python/pyarrow/serialization.py
84.76% <0%> (-2.31%)
:arrow_down:

python/pyarrow/tests/test_serialization.py
89.3% <0%> (-1.69%)
:arrow_down:

cpp/src/arrow/compute/kernel.h
61.16% <0%> (-1.53%)
:arrow_down:

python/pyarrow/pandas-shim.pxi
64.83% <0%> (-0.69%)
:arrow_down:

python/pyarrow/parquet.py
92.21% <0%> (-0.02%)
:arrow_down:

cpp/src/arrow/flight/server.h
100% <0%> (ø)
:arrow_up:

cpp/src/gandiva/expression_registry.h
100% <0%> (ø)
:arrow_up:

... and 560 more

Continue to review full report at Codecov.

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

If you want me to try to cleanup one of the subsystem (python?) in this PR let me know and I can give it a shot.

I think this looks nice on the principle. It would be useful to validate this by migrating the Gandiva, Plasma... status codes.

Will give this a try with plasma

@pitrou this demonstrates using the the StatusDetail with Python and Plasma. This breaks some C++ and Python APIs, I'm not sure if we are OK with that.
If this approach is OK, I will do a follow-up PR to remove Gandiva codes as well.
CC @pcmoritz

putting back in WIP status until I can get CI green (python tests passed for me locally)

@pitrou after a lot of debugging I figured out why the builds were failing only to discover you had fixed with with your PR to provide better errors (there was a copy of Status in a macro that I did not find initally).  Thank you!  I think this is ready to review.  I'll file a follow-up JIRA once this is merged to migrade Gandiva away from this as well.

Will review, thank you :-)

I'm looking into the lint failure, but I'm guessing i wll need to make some changes anyways.

Yes, don't worry about the lint failure for now.

@emkornfield I think I'll update the Python parts directly in your branch.

@emkornfield I'm taking over the Python parts.

@emkornfield I think I'll update the Python parts directly in your branch.

@pitrou sounds good, hopefully it isn't too ugly :(  I could have swarn I recompiled after I made the lint fixes, sorry my attention to detail has been lacking in general lately.

@pitrou OK, I'll stop pusing

I've done my thing on Python. Let's wait for CI a bit.

@ursabot build test

@ursabot build

@ursabot build

The failed ursabot builds are unrelated, @kszucs is busy doing thins on BuildBot.
The failed AppVeyor build is a transient download failure
Travis-CI build: https://travis-ci.org/pitrou/arrow/builds/553376058
AppVeyor build: https://ci.appveyor.com/project/pitrou/arrow/builds/25698396

I'm going to merge once CI is green.


add profile pics to status board

If you have any ideas about the styling of this I'd love to hear them!

Just doing some cleanup, no hard feelings :)


Two small fixes for the Windows implementation

Thanks for the pull request @philix. Can you sign the Google CLA so that I can test/accept this?

Thanks for the pull request @philix. Can you sign the Google CLA so that I can test/accept this?

Oops - my bad. You're good to go.


Dashboard expression countGroups() result is always null

With two or more grouping levels, it is expected that a column containing countGroups() will output a tally of all level-two groups for each top-level group.
Instead, such a column is always empty.

The recent commit https://github.com/gchq/stroom/commit/6521f7bdcdde1298d27a09116f90b715783fa342 results in countGroups() returning the correct result. However sorting by a column containing this expression function doesn't work as expected (unlike count()).


Unit testing of randomness - callback from mock?

Would it be possible to have the fulfillRandomness fire from the mock during tests, so that the following behaviour can be tested in unit-tests? This does not seem to happen in my project. It does not in your starter either.
The contract I would like to create really depends on this random value as its starting point, without alternative public entrypoints to accomodate for testing (the random value not being manipulated from outside factors is crucial when the contract is deployed on a real chain).
How are people testing this today?

Yes. 100%
We have an issue asking to add callbacks here: https://github.com/smartcontractkit/hardhat-starter-kit/issues/67
But in the meantime, can you check this for an example of how to do it in typescript? It should be "about" the same in JS.
https://github.com/PatrickAlphaC/decentralized-raffle/blob/969bee4f5a1da41db32cd1dacb6bab4060f4048d/test/unit/raffle.spec.ts#L58

Yes. 100%
We have an issue asking to add callbacks here: #67
But in the meantime, can you check this for an example of how to do it in typescript? It should be "about" the same in JS. https://github.com/PatrickAlphaC/decentralized-raffle/blob/969bee4f5a1da41db32cd1dacb6bab4060f4048d/test/unit/raffle.spec.ts#L58

I think that looks good. That is very close to how my current code looks based on how I expected it to work, so if the test then executed the fulfillRandomness of the contract, it would be in a good spot I think! Let me know if you want help with testing anything down the line when you have added callbacks.

I have compiled something locally that works for my tests, by modifying the VRFCoordinatorMock to use import the base and then modify function to do a call using interface instead of abi+call:
    function callBackWithRandomness(
        bytes32 requestId,
        uint256 randomness,
        address consumerContract
    ) public {
        VRFConsumerBase(consumerContract).rawFulfillRandomness(requestId, randomness);
    }

Fixed in #80


Add a "Key" method to the signable interface.

This will be used to uniquely identity the artifacts we sign within
a storage system.

/lgtm

/approve


feat(iaviewer): Add "data-full" and "hash" commands

The first three commits are general cleanup that could be pulled out into one or more independent PRs, and the fourth is the motivator of this PR: new iaviewer commands for varying the amount of detail in output.

data-full outputs actual values rather than just their SHA-256 digests.
hash outputs a tree summary without including details about individual entries.

Summary by CodeRabbit

New Features

Improved command validation with the addition of a command validation map.
Enhanced tree loading to always fetch the latest version with better error handling.
Introduced a flag for printing full values in key printing.
Added functionality to handle binary data encoding.

Bug Fixes

Fixed potential issues with error handling and logging across various functions.
Improved encoding to manage non-ASCII data correctly.

Refactor

Restructured command line argument and error handling for better maintainability and readability.

@cool-develope Done.


lib/jenkins.rb self.plugins_dir needs to derive from $JENKINS_HOME not ~jenkins

File that needs to be reworked:
https://github.com/jenkinsci/puppet-jenkins/blob/master/lib/puppet/jenkins.rb
Plugins will continually be downloaded and installed if the $localstatedir is different than the jenkins users' home directory.  I'm not sure if it is possible, or even desireable to feed the $localstatdir to this file.  An option might be to parse the jenkins config file for $JENKINS_HOME to populate the self.plugins_dir instead of using self.home_dir.
The scenario that I found this in:  My jenkins user is in /home/jenkins, but my jenkins instance is installed to /var/lib/jenkins.

I just found out this is my issue. "facter -p jenkins_plugins" was always empty and the plugins have been downloaded and installed on EVERY puppet run.
After changing the line in jenkins.rb from
return File.expand_path('~jenkins')
to the actual user's home, facter works and the issue with the plugins is gone.

I'm not sure if it is possible, or even desireable to feed the $localstatdir to this file. An option might be to parse the jenkins config file for $JENKINS_HOME to populate the self.plugins_dir instead of using self.home_dir.
Yes, that'd be the proper solution IMHO. I can only think of a new fact which reads out $JENKINS_USER from $sysconfig/jenkins and uses this home directory later. Will try to implement this myself.

Yes, that'd be the proper solution IMHO. I can only think of a new fact which reads out $JENKINS_USER from $sysconfig/jenkins (if set) and uses this home directory later. Will try to implement this myself.

@robpou did you ever make any progress on this?


Add a generic "coming soon" page template [good first issue]

We currently have 2 buttons that lead to 404 pages as they have not been created yet.
Someone should create a "coming soon" page just so we don't have to show a 404 page.

we have already 2 issues on this :)
but having a coming soon page is nice to have

@FrancescoXX , please assign to my name

closed by #239


Spanish version - Button event

Describe the bug

The spanish version of the Blocks editor has a misspelling. The spanish name of the event "GotFocus" (button component) is "ObtenertFocus".
Affects

[ ] Designer
[x] Blocks editor
[ ] Companion
[ ] Compiled apps
[ ] Buildserver
[ ] Debugging
[ ] Other... (please describe)

Expected behavior
The name of the event must be call ObtenerFoco, without a T before F.
Steps to reproduce

I had noticed that all the events "GotFocus" have the same problem with the spanish name.

Hello my friends,
how are you doing and work?
I would like to translate as you do, but for Arabic, how can I do this? Can you explain the use? I tried a program that translates applications, but it does not translate the emulator, can you help me, knowing that I am a fast learner

Hello my friends,
how are you doing and work?
I would like to translate as you do, but for Arabic, how can I do this? Can you explain the use? I tried a program that translates applications, but it does not translate the emulator, can you help me, knowing that I am a fast learner

We would be delighted to have help with our Arabic translation. If you wish to do this, please contact me on our community forum https://community.appinventor.mit.edu
I can help you there.

I am in the community. Is there a special topic there for translation? I want to start translating everything with it. How do we get started can you help me

نعم يمكنكِ مساعدتنا في ذالك
سوف يفرح هذا الفريق الذي اقوم بجمعه بعد اكمال امتحانات طلبتنا
الطريقة جيدة يمكنك التعلم بسرعة لكن توجود شروط بعض الجمل صعبة اود ان تتركها
لان لدي مترجم يقوم بلاعمال الصعبة يمكنك ارسال الجميل الخاص بك لبدأ اعطاء
موافقة ايضا سوف ارسل اليك رابطا لموقع ويب الخاص بلترجمة و بعدها نرسل الى
mit طلب للموافقة
شكرا للمساعدة
و ايضا يوجد برنامج تعليمي سوف اقوم بأرساله
لدي سؤال ما امكانية لغتك الانكليزية من نسبة ١٠٠ %
في الجمعة، ١٦ يوليو ٢٠٢١ ٥:٤٤ م Evan W. Patton @.***>
كتب:

Closed #2504 https://github.com/mit-cml/appinventor-sources/issues/2504
via #2507 https://github.com/mit-cml/appinventor-sources/pull/2507.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mit-cml/appinventor-sources/issues/2504#event-5031353523,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ATGSKXDSWXXBKAUBGHT3X3DTYBAWLANCNFSM47G7IG7Q
.

https://youtu.be/VFwTn32MrBw
رابط البرنامج التعليمي
Tutorial link
في الاثنين، ٢٨ يونيو ٢٠٢١ ٥:٥٤ م Susan Rati Lane @.***>
كتب:

Hello my friends,
how are you doing and work?
I would like to translate as you do, but for Arabic, how can I do this?
Can you explain the use? I tried a program that translates applications,
but it does not translate the emulator, can you help me, knowing that I am
a fast learner
We would be delighted to have help with our Arabic translation. If you
wish to do this, please contact me on our community forum
https://community.appinventor.mit.edu
I can help you there.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mit-cml/appinventor-sources/issues/2504#issuecomment-869753322,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ATGSKXBH4C6LYURJAQWNAJLTVCEIZANCNFSM47G7IG7Q
.


How Do I Fix This?

Describe your problem here.
source/psychlua/CallbackHandler.hx:48: characters 18-33 : Class<llua.Lua_helper> has no field sendErrorsToLua
Are you modding a build from source or with Lua?
Source
What is your build target?
Windows x64
Did you edit anything in this build? If so, mention or summarize your changes.
Edited Project.xml to add Icon 24, 40, 48, 96, 128, 256, 512, 768

This helped me:
just delete this code from the file
(originally said by CrazyDany )
catch(e:Dynamic)
{
if(Lua_helper.sendErrorsToLua) {LuaL.error(l, 'CALLBACK ERROR! ${if(e.message != null) e.message else e}');return 0;}
trace(e);
throw(e);
}

This helped me: just delete this code from the file
(originally said by CrazyDany )
catch(e:Dynamic) { if(Lua_helper.sendErrorsToLua) {LuaL.error(l, 'CALLBACK ERROR! ${if(e.message != null) e.message else e}');return 0;} trace(e); throw(e); }

yea but like, you can’t use try without catch

okay nvm, turns out you can, but it’s not recommended

still cant fix


Find and document enclosure assumptions for commercial template model

Envelope options in Kalidescope Reviewed. 10 design options were selected for inclusion in the template model. Can be expanded at a later date, if we want, but this probably covers the bases pretty nicely. Existing design options in the M3.1 model are also included in this set.
Write up: https://docs.google.com/document/d/1gTB0hfQk5Ju7TlS70Rm5IwDwwgSS7QpY1yOIgRKxKJY/edit
Envelope spreadsheet: https://docs.google.com/spreadsheets/d/19uBDLrJPGaAQ9O9IHpaCr8Kv8n0Nij8Oub_FJzqEG_o/edit?gid=1465507455#gid=1465507455

awesome! this will be so useful :)


Icons and Flags are missing on the selected option of Dropdowns!?

Hey,
I wonder why there are no icons of the selected option in the dropdown like in the picture below:
semantic-ui:

semantic-ui-react: no icons

Can I somehow achieve this?

Duplicate https://github.com/Semantic-Org/Semantic-UI-React/pull/1172

See the original issue for more info and workarounds https://github.com/Semantic-Org/Semantic-UI-React/issues/1147


Fixup Autocomplete PRs (#1658 and #1727)

@wadethestealth
Sorry I just made a mistake and pushed this branch into master ...
Basically this PR was already ready for merging tho.
Ask me if you have something to be fixed around this PR.

Sorry I just made a mistake and pushed this branch into master

I just turned on 1 approval required for pushing/merging to master to help prevent that 😄

@aviatesk still says atom restart which isn't true.

@BenRussert

I just turned on 1 approval required for pushing/merging to master to help prevent that 😄

Cool ! Thanks !


Sort keys by file location rather than alphebetically to provide better context to translators

Since developing this I've learned that translators prefer things to be organized based on location in the game/files rather than alphabetically, this makes the context of the string easier to understand.
IIRC I implemented it alphabetically as a performance optimization, so it would be good to benchmark on a large test project with tons of dummy strings to make sure the performance cost isn't too high.

Hello! I have the same problem. It is much more convenient when the text is sorted not in alphabetical order, can you help solve this problem pls?


Redirecting to a different page

Describe the problem
I'm trying to make my Eel application be able to have multiple pages and not just be one HTML file.
How can I redirect the application to another HTML file?
Code snippet(s)
Here is some code that can be easily used to reproduce the problem or understand what I need help with.

[x] I know that if I don't provide sample code that allows someone to quickly step into my shoes, I may not get the help I want or my issue may be closed.

import eel

# Set web files folder
eel.init('web')

eel.start('file1.html')
... file 1:

<button onclick="window.location.href = 'file2.html'>file two</button>

... file 2:

hello world!

Desktop (please complete the following information):

OS: Windows 10
Browser Firefox
Version 0.14.0?

Your example works just fine, in principle, except you're missing a closing double-quote for the onclick attribute. It should be:
<button onclick="window.location.href = 'file2.html'">file two</button>

Eel presents as a standard webserver using basic HTML/CSS/JS, so you don't need to do anything unusual to support moving between pages in your app.

That was just an example, and I need to have it in a JavaScript submit() function, and the window.location.href = 'file2.html' snippet does not work

Seems that adding one slash before the file2.html worked!
Thanks for your help


SUPPORT CHINESE | 支 持 中 文

支 持 中 文
It a beautiful day outside
The birds are singing
The flowers are booming
On the days like this
The toys like this
SHOULD SUPPORT CHINESE
什么时候支持中文啊？

Closing as duplicate of https://github.com/microsoft/PowerToys/issues/199


Will Volume support be coming?

I was wondering if Volume support would be coming and if so if you had an ETA when to be expecting that? Thanks!

You probably want to check https://github.com/miracle2k/onkyo-eiscp


BUG: The Login button on hovering changes to Register

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
The Login button changes its text to Register on hovering mouse over it in index.html . Also the hovering effect of login in buy products is not consistent with all the other pages. I would like to fix this issue. Please assign me this under GSSoC'24.
Cursor not hovering:

On hover:

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

@Suchitra-Sahoo I have made a pull request for this issue. #1194


sensor_receiver.py error in python3

I am trying pair StreamerPV project on HoloLens with sensor_receiver.py on desktop. I am using Python 3.5.6 in order to use tensorflow, and the code gives error at this line "image_data += image_data_chunk" which results from python3 not able to implicitly convert bytes to strings. So I changed the line to "image_data += image_data_chunk.decode('utf-8')" but it still gives me error
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 1: invalid start byte
I tried codecs: utf-16, ascii, unicode-escape, etc.. and none of them work. If I used any error handling like "ignore, replace, backslashreplace", my image data gets corrupted.
Has anyone tried to implement this code in Python3, or should I just do it in Python2? Any suggestions would be appreciated.

May be a bit late, but I fixed the issue by changing line 155 from image_data = '' to image_data = bytes(). I hope this helps.

Hi, does the pairing between StreamerPV and sensor_receiver.py work for you now? I always get a
"ConnectionRefusedError: No connection could be made because the target machine actively refused it".
The same happens when I try the ComputeOnDesktop sample...

@cgsaxner  i have the same problem

@hankhhub  how did u install and launch the streamer on your hololens ?

@cgsaxner it works for me .
you should go to properties debugging remote machine after in the machine name put the ipv4 address of hololens .first launch the streamer PV on hololens after thatin your PC  in the cmd type sensor_receiver.py -a "address of hololens"

@jonah27798  Thanks for your solution it helped so much . One question is sensor_receiver.py saving data ?

@cyrineee I'm glad I could help. No, unfortunately it does not save data, but for example you can save the current frame by using openCV:
cv2.imwrite('current.jpg', image_array)
Please note that this overwrites the file after each frame.

Thanks a lot.so i add this code after cv2.imshow at line 87?
And does recorder_console.py save data ?
Thanks in advance.

From: jonah27798<EMAIL_ADDRESS>Sent: Sunday, April 28, 2019 8:29:34 PM
To: Microsoft/HoloLensForCV
Cc: Cyrine NABLI; Mention
Subject: Re: [Microsoft/HoloLensForCV] sensor_receiver.py error in python3 (#84)
@cyrineeehttps://github.com/cyrineee I'm glad I could help. No, unfortunately it does not save data, but for example you can save the current frame by using openCV:
cv2.imwrite('current.jpg', image_array)
Please note that this overwrites the file after each frame.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/HoloLensForCV/issues/84#issuecomment-487404025, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AKDCODWXZEIETT32ROIHQO3PSXUI5ANCNFSM4G3TNMCQ.

Thanks a lot. so ihttp://a lot.so i add this code after cv2.imshowhttp://cv2.imshow at line 87?
And does recorder_console.pyhttp://console.py save data ?
Thanks in advance.
Télécharger Outlook pour Androidhttps://aka.ms/ghei36

From: jonah27798<EMAIL_ADDRESS>Sent: Sunday, April 28, 2019 8:29:34 PM
To: Microsoft/HoloLensForCV
Cc: Cyrine NABLI; Mention
Subject: Re: [Microsoft/HoloLensForCV] sensor_receiver.py error in python3 (#84)
@cyrineeehttps://github.com/cyrineee I'm glad I could help. No, unfortunately it does not save data, but for example you can save the current frame by using openCV:
cv2.imwrite('current.jpg', image_array)
Please note that this overwrites the file after each frame.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/HoloLensForCV/issues/84#issuecomment-487404025, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AKDCODWXZEIETT32ROIHQO3PSXUI5ANCNFSM4G3TNMCQ.

@cyrineee Yes after cv2.inshow, but I believe its located in line 100 if you didn't edit the file.

@cyrineee Thank you, I finally can connect to the streamer now. My problem was that I always attempted to connect to the HoloLens via USB, but for some reason it only works via WiFi.
Concerning your question about recorder_console.py, it is essentially a tool for managing recordings you made with the Recorder tool. The Recorder stores recordings on your HoloLens, and the recorder_console.py provides a tool for downloading and extracting them to your computer, but you could also manually do that using the device portal.

@cgsaxner  i want to have the sensor data on my desktop but the recoder_console.py doesn't work for me .there is a problem of certificate security . it did work for you ?

@cyrineee yes, for me it worked.
I installed the Recorder on my HoloLens, then made recordings with it, then use the recorder_console to download them.
For this, I connected the HoloLens using USB, then the command is
python recorder_console.py  --dev_portal_username DEV_PORTAL_USERNAME --dev_portal_password DEV_PORTAL_PASSWORD  --workspace_path WORKSPACE_PATH
You have to insert your corresponding device portal username and password, and the workspace path is where the recorder will store the files. If you connect via WiFi, i think you also need to specify the IP of your HoloLens using --dev_portal_address DEV_PORTAL_ADDRESS.

the recorder is running but i get this error for the recorder_console.py (via wifi)

for future visitors:
when connecting the HoloLens via WiFii, recorder_console.py will fail with the above error. If you connect via USB, everything works just fine.
To solve the issue with WiFii:
"If you want to connect via WiFi you will need to disable SSL on the HoloLens device when not using a certificate. In case of production make sure SSL is enabled and you have downloaded and implemented the certificate which you can retrieve from the HoloLens Device. The settings for both SSL and the certificate can be found through the Device Portal -> Security Tab at the top" from (https://www.appzinside.com/2017/08/18/how-to-use-the-device-portal-api-of-hololens-take-a-picture/)


Scan Conversion

Hi!
I wanted to know whether anyone has scan conversion codes for the Clarius probes. I want to reconstruct the image and need to do a scan conversion so it will follow the shape of the probe.

sorry, we do not provide scan conversion code, there are some examples in Matlab, and possibly other languages: https://github.com/wme7/Aero-matlab/blob/master/K-wave/k-Wave/scanConversion.m


MARC::XMLWriter will generate invalid XML documents.

MARC::XMLWriter is used by MarcRecordWriterService and OaiMarcRecordWriterService to generate MARC XML documents from contributor supplied MARC records. The supplied MARC records can include invalid byte sequences, non-printing control characters, and other anomalies that are invalid in XML.
This ticket is a placeholder for determining what, if anything, we ought to do about this.
Interestingly, because we're using Nokogiri to produce OAI-PMH responses from documents containing XML record snippets, the OAI feed is valid XML because Nokogiri appears to remove data that would be invalid in XML. However, MARC XML formatted normalized full dumps and deltas served via the web app and ResourceSync may be invalid.

Do we know how Nokogiri handles the invalid data?  (Do they just remove invalid characters, or do they do something more than that?)  Might not hurt for us to do the same thing when normalizing, if that's easily done; it'd be a straightforward way to bring the different MARC XML views into sync.

In the case I observed Nokogiri removed the invalid bytes.


Add draft doc for aws cluster management via CRs

Towards https://github.com/giantswarm/giantswarm/issues/8609
That's a "draft" draft, but we need to start somewhere.

I want language corrections for sure. Missed to add sig-content

@marians @giantswarm/sig-content ptal

I'd like to do an overall grammar and sentence structure suggestion review once the other suggestions have been accepted. 👀
Right now there are a lot of individual suggestions already, so I will wait a bit till the dust has settled.

@oponder you can write your suggestions now

Sorry if I’m a blocker here! Tomorrow morning this is first thing on my list.

@oponder Please ping when you're done. I want to give it a read after you're through. Thanks!

ping @marians, done reviewing for now.
Might be best to wait for my suggestions to be merged, and then take a look then? (to avoid suggestions on suggestions)

I agree with @oponder's comment. The Rest API seems to play a big role here in the text. It would probably be more straightforward if we could ignore the fact that the Rest API exists. v4/v5 would not occur then.

I wanted to bring some reasoning regarding why do we even have this guide. Will think about dropping rest api references. Thanks a lot folks for review and suggestions!

I actually dropped some of the references, ptal wwhen you have a time @oponder @marians
Also what to do with failing CI? It reports about wrong links, which are actually valid

What to do with these alerts
URL        `https://www.vaultproject.io/docs/auth/github.html'
Name       `GitHub Vault authentication'
Parent URL http://docs:8080/basics/secured-access-to-clusters/, line 220, col 5
Real URL   https://www.vaultproject.io/docs/auth/github.html
Check time 0.074 seconds
Size       55.08KB
Result     Error: 404 Not Found

URL        `https://www.vaultproject.io/docs/secrets/ssh/signed-ssh-certificates.html'
Name       `Vault SSH certificate'
Parent URL http://docs:8080/basics/secured-access-to-clusters/, line 221, col 5
Real URL   https://www.vaultproject.io/docs/secrets/ssh/signed-ssh-certificates.html
Check time 0.269 seconds
Size       55.08KB
Result     Error: 404 Not Found
 2 threads active,    26 links queued,  493 links in 547 URLs checked, runtime 1 minute, 11 seconds

@marians maybe you can help?

@vol You can ignore the linkcheck, since the URLs in question haven't been added by your PR. Also @oponder has already fixed them in master. See https://github.com/giantswarm/docs/commit/11cb2cd5091ea123305086232377a2ffe313e36d#diff-55aee6ebaac1c17a95d1de4917973dc0L75-L79

Addressed the last comments from Joe. Merging today


Added -toolchain option to swiftc

What's in this pull request?
Added a -toolchain swiftc option. This works like clang/gcc's -B flag (which allows specifying an alternate toolchain location).  We need to be able to cross-compile executables in order to cross-compile the LLDB swift REPL. Since I believe it's only relevant for cross-compilers, I've made it a swiftc-only option (are there any use-cases for running the interpreter with an alternate toolchain?)
Currently, you can cross-compile with swift (assuming you've got a copy of the standard library compiled for the target), like so:
swiftc -target armv7-unknown-linux-gnueabihf -sdk ${sysroot} -resource-dir ${sdk-location} main.swift

However, this only works for modules (swiftmodules), not for executables. The host swift generates a link command to the system clang++ with -fuse-ld=gold (or whatever is the correct linker for the target platform), but there is currently no way to tell it where to find the cross-linker. Normally, you would put this information behind the -B switch, so we provide the same kind of functionality here.
Adding -toolchain ${gcc-toolchain-path} to the above command allows swift to cross-compile an executable.
This was previously suggested as -Blinker (#2483) and I thought it was resolved by the update to clang accepting absolute linker paths, however there are two reasons why that isn't true:

Swift's link commands go through the system clang, which might not support absolute linker paths
You might not know which linker to use. We recently switched all Linux targets to use gold. Maybe there are different options for different hosts. The Swift compiler already knows which linker to search for in the toolchain, so it's convenient not to have to say this again.

So in short a toolchain flag is more flexible, and more compatible.
Resolved bug number: (SR-)

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

Looks reasonable to me.  The change needs tests though.
CC @jrose-apple.

Swift's link commands go through the system clang, which might not support absolute linker paths

With this change, we are still going through the system Clang, right?  This does not sound right to me because the system Clang might not even know about our target.  (For example, if the toolchain for the target uses a fork of Clang.)

We're still going through system Clang, just passing the -B option as well. Nobody is shipping a system Clang that supports absolute paths in the --fuse-ld option yet, so we have to make to with that.
Without this change, this is what happens when trying to cross-compile any executable:
echo 'print("hello, world")' | ./swiftc -target armv7-linux-gnueabihf -sdk /Spring/Projects/3rdParty/OpenSource/Apple/cross-compile/sysroots/linux-armv7 -resource-dir ../../swift-linux-armv7/lib/swift -v  -
Swift version 3.0-dev (LLVM cb08d1dbbd, Clang 383859a9c4, Swift 767443ddc1)
Target: armv7--linux-gnueabihf
/Spring/Projects/3rdParty/OpenSource/Apple/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/bin/swift -frontend -c -primary-file - -target armv7--linux-gnueabihf -disable-objc-interop -sdk /Spring/Projects/3rdParty/OpenSource/Apple/cross-compile/sysroots/linux-armv7 -resource-dir ../../swift-linux-armv7/lib/swift -color-diagnostics -module-name main -o /var/folders/rc/b9h98gpx74j1hqp82wv7sd0h0000gn/T/--4f1b14.o
/Spring/Projects/3rdParty/OpenSource/Apple/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/bin/swift-autolink-extract /var/folders/rc/b9h98gpx74j1hqp82wv7sd0h0000gn/T/--4f1b14.o -o /var/folders/rc/b9h98gpx74j1hqp82wv7sd0h0000gn/T/--2df8d3.autolink
/usr/bin/clang++ -fuse-ld=gold -target armv7--linux-gnueabihf -Xlinker -rpath -Xlinker ../../swift-linux-armv7/lib/swift/linux ../../swift-linux-armv7/lib/swift/linux/armv7/swift_begin.o /var/folders/rc/b9h98gpx74j1hqp82wv7sd0h0000gn/T/--4f1b14.o --sysroot /Spring/Projects/3rdParty/OpenSource/Apple/cross-compile/sysroots/linux-armv7 -L ../../swift-linux-armv7/lib/swift/linux --target=armv7--linux-gnueabihf -lswiftCore @/var/folders/rc/b9h98gpx74j1hqp82wv7sd0h0000gn/T/--2df8d3.autolink ../../swift-linux-armv7/lib/swift/linux/armv7/swift_end.o -o main
clang: error: invalid linker name in argument '-fuse-ld=gold'
<unknown>:0: error: link command failed with exit code 1 (use -v to see invocation)

Note the call to /usr/bin/clang

I understand.  What I am saying is that the system Clang might not even know about the target, so we should prefer the Clang from the toolchain, if it exists.

You mean like this? (needs tests of course)

@karwa Yes, exactly!  Thank you!

@swift-ci Please test

Haven't had a chance to look at the code yet, but I'm concerned about overloading the term "toolchain". There's the classic compiler tools meaning, and then there's the Xcode meaning, which we've adopted on swift.org. They're related but refer to very different levels in the directory structure.

Fixed test.
@jrose-apple Why set PATH instead of doing this? Why is this not a good long-term solution? If Swift depends on a collection of tools from the host system, it makes sense to give an option to override them.

Sorry, I meant "I know setting PATH is not a good long-term solution". I just wanted to know how blocking this is.

Well, I only really only need it for LLDB (maybe swiftpm, too), and I'm only cross-compiling for armv7, where breakpoints don't work so LLDB is basically pointless. So I could technically live without it.
Since the only bit of binutils we need is the linker, and LLD seems to be making such great progress that we can imagine a day when we won't even need that, the clang lookup is probably the most long-term useful part. If even that isn't all that useful, I can drop it and keep the -B flag, maybe under some inconspicuous name where it won't disturb anybody. At least until out machines are shipping with newer versions of Clang.

I'm wondering about other binutils. dsymutil seems like it would also come from the toolchain, if it were more commonly used on Linux systems. Even if we do have a dedicated command-line flag, I'm not sure why we wouldn't want to affect every tool looked up by the driver, which is basically equivalent to setting PATH.

dsymutil isn't part of GNU binutils. It's not needed on Linux platforms as the debug symbols are embedded, so the only time you would need it is if you're cross-compiling to Darwin. In that case, the only supported build machine is OSX which has a dsymutil to handle everything (do we support Linux->OSX in any sense?).
Speaking of dsymutil on Linux: dsymutil was recently (10 months ago, http://llvm.org/viewvc/llvm-project?view=revision&revision=244270) added to LLVM, but it's called llvm-dsymutil. Since there aren't really expectations of what Swift does when it emits debug symbols, we could stop embedding debug information in the binaries on linux and standardise on dSYMs. In any case, that would be out of scope of this PR.

I guess my point is that if this is really just about the linker and it doesn't affect any other tools, maybe we should name it as such.
(BTW, the code comment about char * is still relevant.)

Random question, but did you consider having -toolchain point to a JSON file that describes the toolchain, rather than a path?  That seems like a more generally extensible and customizable design.

For example, I think it could be cool to be able to use something like:
swiftc --toolchain beagleboard ....
and have the compiler look for "beagleboard.toolchain" in a directory next to the swift executable (or some system location), then in your home directory, etc.  Of course an absolute path to a toolchain file should also work.  The toolchain file could have paths to all of the components that make up the toolchain as well as specify configuration options to specify the "kind" of component each is.

@ddunbar since he probably also has thoughts on this from the SwiftPM / llbuild perspective.

I think that's a bit overengineering. In the common case, people do organize their toolchains by directory; in the uncommon case, you can fake it with symlinks.

I agree... if it turns out we need more metadata about a toolchain to do nice things automatically, I think it would make more sense to establish a convention for embedding the metadata in a file inside the toolchain, so users can still refer to the toolchain by path. This is essentially what we already do on Darwin platforms (and then that metadata has identifiers we have convenient access to), and I could imagine Swift defining a convention for that for Linux along with associated tools to use them.
I agree with @lattner that the general features this enables are useful in the long run. For example, a current desired feature for SwiftPM that our users want/need is easy access to "cross compiling" to other toolchains, so they can use a newer swift build with sources designed for older Swift versions.

@lattner @ddunbar

Comprehensive cross-compiling support is something that is a (not-so-secret) desire of mine for Swift. We live in a multiple-device world - my laptop is Intel, my phone and tablet are ARM, the server I'm deploying to could conceivably be either, and the IoT platform I'm targeting may be something completely different (but probably ARM as well).
This was always a kind of expert feature in the past, but the proliferation of computing and rich, embedded, accessible devices makes it something the average user might desire to do. Cross-compiling for a Raspberry Pi (linux-armv7) is no more an "advanced" feature than cross-compiling for iOS; it's just easier because of Apple's well-structured toolchain and the fact you can only do it from OSX.
When it comes to "toolchain bundles" specifically, it is something we really should move to. I have actually been planning to introduce something like that for the build system, but of course the same challenge could be met with the same solution for cross-compiling other Swift code besides the standard library. Currently we have some... Undesirable things in CMake as a result - for example, we have include paths for Android hardcoded in AddSwift.cmake. This kind of stuff should go in a toolchain file (indeed, that's what I'm using so far for my own cross-compiling patch - a CMake toolchain file):
  if("${CFLAGS_SDK}" STREQUAL "ANDROID")
    list(APPEND result
        "-I${SWIFT_ANDROID_NDK_PATH}/sources/cxx-stl/llvm-libc++/libcxx/include"
        "-I${SWIFT_ANDROID_NDK_PATH}/sources/cxx-stl/llvm-libc++abi/libcxxabi/include"
        "-I${SWIFT_ANDROID_NDK_PATH}/sources/android/support/include")
  Endif()

The biggest challenges we have for cross-compiling right now:

[build-script]: Configuration is based on SDK, so you can't cross-compile for another architecture variant of the Host SDK. Cross-compiling the stdlib for linux on a linux host, for example, is not possible. I have some work to address this in #2835
[stdlib]: The standard library is not relocatable. Specifically, module maps contain absolute paths and must be hand-edited before redeploying. @rintaro had an interesting idea to address this using the recently-introduced VFS system in clang.

Ok, if pointing to a directory is the right path forward, then I can live with that.  However, that seems a lot more ugly then being able to define symbolic names.  The "-arch" flag on apple compilers has worked really well in practice, and uses an effectively (non-user-definable) symbolic short name.
That said, I'm not going to fight over it. :-)

Sorry if this is noise, but I'm curious how this discussion is progressing. Besides cross-compilation (which would be very cool), this would help me fix a wart I introduced in https://github.com/apple/swift/pull/1714#issuecomment-224401155. In short, running the Swift test suite on Android devices right now requires some ugly symlinking in order to use the correct linker for Android.
Is this discussion continuing on the mailing list somewhere? Is there anything someone like me could do to help this along? :)

I think the outstanding questions were:

should we be passing a directory or a config file (or config file name)?
does it matter that this only affects GenericUnix-based targets for now?
should this just affect the linker or all tools found relative to swiftc?
is -toolchain the right name? alternatives: -host-tools, -override-tools, -B, maybe -binutils?

And given that nothing moved forward, I think the answers are

directory, like Clang
no, we can add support for other targets later
it should affect all tools, but we don't need to implement that now
Jordan vetos "toolchain" because it's already in use in a Swift context, but doesn't want to pick an alternative.

There're also some minor outstanding code comments.

Jordan vetos "toolchain" because it's already in use in a Swift context, but doesn't want to pick an alternative.

Doesn't the Swift notion of downloadable toolchain match the one desired here?  The difference is that the Swift downloadable toolchain is incomplete, but otherwise it is the same concept, I think.

Unfortunately no—while they are similar concepts, the argument being passed here is a direct path to the bin/ directory, rather than a root.

If that's the only difference, can we change -toolchain to point to the root of the toolchain?

I think also no. Besides consistency with Clang, I don't think that these always come organized into a usr/bin/ directory structure. @karwa, @modocache?

@gribozavr I like your approach because it means that its much easier to move between clang and swiftc.  clang and gcc both have the -B option which is the "root" of the toolchain (i.e. the tool is expected to be found in that directory).  This basically would then amount to supporting the same switch set.

@compnerd Ha, at least one of us misunderstood Dmitri. My interpretation of the "root of the toolchain" is the directory containing usr/, not the directory containing ld.

I don't think we should constrain the design to what clang/gcc does.  The two worlds can coexist through the magic of symlinks.

I don't think we need to inherently match Clang/GCC, but it seems only polite to do something that works with existing cross-compilation toolchains.
New name proposals: -tools-directory or -binutils-directory.

I'd like to veto '-binutils-directory'.  There is no reason to assume that binutils are involved.  In fact, when cross-compiling (* to Windows) we only use LLVM tools.  I've been looking at more comprehensively changing tools to the LLVM set.  This would mean that swift would build using the LLVM tools just built.  This has some notable benefits including having a single toolchain, having more control over the tools that are used (so we don't run into silly issues like we did with ELF relocations), faster (LLVM tools have been shown to be faster) and a hermetic build, and possibly a reduced overall dependency on tools needed to get bootstrapped.

I originally was thinking of "binutils" as a generic term, but if it has strong connotations of GNU binutils then your objection makes sense. (I'm not happy that there doesn't seem to be a generic term, but that's less important.)

I think that the only general nomenclature that Ive heard of for this is toolchain.

-_- Great.

Back in June, the outstanding questions were:

should we be passing a directory or a config file (or config file name)?
does it matter that this only affects GenericUnix-based targets for now?
should this just affect the linker or all tools found relative to swiftc?
is -toolchain the right name? alternatives: -host-tools, -override-tools, -B, maybe -binutils?

The current answers appear to be:

directory, like Clang
no, we can add support for other targets later
it should affect all tools, but we don't need to implement that now
-toolchain, -binutils-directory, and -tools-directory were proposed as names. -tools-directory appears to be the only name so far that hasn't been vetoed.

If this PR were rebased and updated to take a -tools-directory option instead, would it be mergeable?

That, and the use of StringRef in InvocationInfo.

Hey, sorry I was busy with other projects.

I think we should do a directory, but not like Clang. I subscribe to Jordan's view of the toolchain being the thing containing 'usr' - or even a directory above that. Probably with a configuration file with some build flags. Basically, something similar to Apple's platform SDKs -- a package containing all of the header files, libraries and any native tools you need to compile Swift files (or the Swift compiler itself) for the platform.

My idea was that, as platform developers like Google ship an Android NDK, they could easily include a Swift toolchain with a collection of symlinks. Then you just compile like normal, passing the path to that bundle and that's all you need to do to cross-compile. When you look at what cross-compiling with Clang requires for them at the moment, you really feel like it should be easier with Swift, and we have a model for how easy it can be with the iOS toolchains.

It might not just affect GenericUnix-based targets. If we have toolchain bundles as an official Swift feature, we have a better cross-compilation interface in general to compilers such as Clang (see above)

As for the name, maybe something that riffs off of "sdk"?

Xcode actually separates the notion of "SDK", "platform", and "toolchain": the first contains headers and libraries (or stubs) to link against, while the last contains tools. (And the middle is mostly a fuzzy grouping around SDKs, but also has some run-time support that can be consistent across SDKs.) So "toolchain" would be the most appropriate Xcode-name for "the directory containing usr/". (Although it might get confused with the toolchain that Swift itself is in, if you're using a downloadable package.)
That said, I suppose one other option is to use the existing -sdk option, and search for tools in there as well. As far as I know Xcode doesn't do this (@ddunbar?) but now that you've brought it up it doesn't seem unreasonable to me. However, it does mean you can't pass a separate SDK and tools directory.
IIRC for Clang this is the difference between --sysroot (searches for tools) and -isysroot (does not search for tools). But that's a subtle point that I don't think people usually remember, or bother to follow, and we may even have overrides for one behavior or another depending on the platform.

@jrose-apple Ok I finally updated the PR. Reverts to using const char*, renamed the option -tools-directory, and made the driver also use it for looking up ld on Darwin platforms so everybody is included.

Okay, looking good! I have a few last comments (mostly about the tests) but I think we're ready to merge. @modocache, @compnerd, @ddunbar?

And for the heck of it:
@swift-ci Please test

Since there's still some feedback this won't be the final run of the tests, but we can probably just do smoke tests after this. Linux, OS X.

@jrose-apple Feedback addressed. -### is awesome, thanks for the tip - even though I typically prefer tests which execute something, this way we can test the toolchain substitutions on all targets on all hosts (which makes more sense, since this is envisioned for cross-compiling support).

@swift-ci Please smoke test

@swift-ci Please Python lint

Linux, OS X, Python.

The Linux tests failed, even though it's probably not related. Let's just run again.
@swift-ci Please smoke test

Merged. Thanks for sticking with this one, @karwa!


[FLOC-1638] Node certificate

Fixes FLOC-1638

This is OK to merge, if the comments above are addressed.


Image tool now functioning with new features on Strapi V4

I now have the image tool working. I've changed some code and added some comparing this code with the following tutorial: https://docs.strapi.io/developer-docs/latest/guides/registering-a-field-in-admin.html#creating-the-wysiwyg.
The following warning shows up in the console, which means that we may need to move this over to the BlockAPI in the future if and when we update EditorJS.
 «blocks.stretchBlock()» is deprecated and will be removed in the next major release. Please use the «BlockAPI» instead.

commit e07548c adds in width, height, size, mime and responsive data to the image tool. Here is a screenshot of the returned data.

Commit https://github.com/melishev/strapi-plugin-react-editorjs/commit/e07548ca71e7ffc211acb53e8aa556ef2fe660e6 adds in width, height, size, mime and responsive data to the image tool. Commits f318525 and 5949de0 cleaned up the responses. Here is a screenshot of the returned image data after being turned into a json object.

@melishev - For the most part, I believe that I am done with commits to this. Please check 6223702, as this a complete refactoring of Wysiwyg > index.js. I've removed the usage of @buffetjs. From everything that I can tell, with all of these changes, EditorJS is working perfectly in v4, with the exception of issues with the Link tool when working in strapi develop --watch-admin, and also Link tool issues when @strapi/mailgun-js is installed.

@melishev - For the most part, I believe that I am done with commits to this. Please check 6223702, as this a complete refactoring of Wysiwyg > index.js. I've removed the usage of @buffetjs.
1f2d9a7 fixes issue #5
From everything that I can tell, with all of these changes, EditorJS is working perfectly in v4 with the following exceptions:

Link tool doesn't work properly in strapi develop --watch-admin mode
Link tool doesn't work properly when @strapi/mailgun-js is installed.

@melishev I believe that all changes that you requested have been completed.

:tada: This PR is included in version 2.0.0-beta.2 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


focus should be focus-visible

The problem with focus is that it reacts on the mouse, which should not.
https://tailwindcss.com/docs/hover-focus-and-other-states#focus-visible
plugin(function ({ addVariant }) {
  addVariant("hocus", ["&:hover", "&:focus-visible"]);
  addVariant("group-hocus", [
    ":merge(.group):hover &",
    ":merge(.group):focus-visible &",
  ]);
}),

Ah yep, I've been thinking about this - I'll probably end up add extra variants (hocus-visible, group-hocus-visible to match base Tailwind.


Allow repeat calls to 'deploy' by forcing links and clearing build/bin

[skip ci]
Tested locally with:
make deploy && make deploy

🦑

I find this a little surprising. Can you explain this a bit more?

If you run make deploy and then run make deploy again, it'll fail.  I'm not as much a Make wizard as I wished sometimes, but it seems like it's unaware of the files created and just trying to re-do everything.  In order to do that, you can whack files and links, or try more subtle rules that would take more time to think about.
An alternative approach to this pull req. would be to add a new target, so, e.g., make clean-deploy would do all the whacking and you could then run it between calls to make deploy.
(Note: running make clean between subsequent make deploys is painful.)

AH, I understand.


Support macOS in KMT scenarios

What does this PR do?
Enable support for KMT native VMs in macOS, with the folllowing changes

Changing the hypervisor type to hvf in macOS
Relying on QEMU support of native virtualized networking in macOS (vmnet), instead of libvirt as it doesn't support it.
Domain IPs must be discovered dynamically from DHCP leases in macOS, this requires changing the type of the domain.ip variable to pulumi.StringOutput.
Updates pulumi-libvirt
Add a test.check-xslt task to easily test XSL transformations.
Change the path of the libvirt socket on macOS
Add remote/local working directories to the configuration, to allow for macOS hosts to launch both local and remote VMs.
Enable the NFS connection killer when the host system is macOS (see https://github.com/DataDog/ami-builder/pull/161)

Which scenarios this will impact?
KMT scenarios
Motivation
Support for local KMT VMs in macOS
Additional Notes

/merge


crypto/tls: unable to update some crypto/tls recorded tests

What version of Go are you using (go version)?

$ rhel8-7d32e1526b2a-0# ../../../bin/go version
$ go version devel +d2765de863 Thu May 2 15:38:36 2019 +0000 linux/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ rhel8-7d32e1526b2a-0# ../../../bin/go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/root/go"
GOPROXY="direct"
GOROOT="/go"
GOSUMDB="off"
GOTMPDIR=""
GOTOOLDIR="/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/go/src/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build126288050=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I attempted to update some of the recorded TLS tests using OpenSSL 1.1.1 built and configured according to the recommended way: ./config enable-weak-ssl-ciphers enable-ssl3 enable-ssl3-method.
What did you expect to see?
The test pass and a new recording generated.
What did you see instead?
OpenSSL failed to start due to a small key size:
=== RUN   TestRenegotiateTwiceRejected
=== RUN   TestRenegotiateTwiceRejected/TLSv12
--- FAIL: TestRenegotiateTwiceRejected (0.16s)
    --- FAIL: TestRenegotiateTwiceRejected/TLSv12 (0.16s)
        handshake_client_test.go:315: Failed to start subcommand: error connecting to the OpenSSL server: dial tcp <IP_ADDRESS>:24323: connect: connection refused (exit status 1)

            Using default temp DH parameters
            error setting certificate
<PHONE_NUMBER>63488:error:0909006C:PEM routines:get_name:no start line:crypto/pem/pem_lib.c:745:Expecting: DH PARAMETERS
<PHONE_NUMBER>63488:error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small:ssl/ssl_rsa.c:310:

@FiloSottile @agl

@FiloSottile I guess this didn't make 1.15, do you want a 1.16 milestone, or backlog?  Thanks.

Moving milestone to backlog.

I ran into similar problems with my custom-compiled version of openssl 1.1.1g, where I enabled enable-weak-ssl-ciphers. The problem turned out to be that the ./apps/openssl version was still loading my system's openssl libraries, instead of the ones I had just compiled. This was fixed by adding no-shared to the ./config command line.


[Backport 1.26] tracing: fix Datadog span name (#29932)

Commit Message:
tracing: fix Datadog span name
Backport c3646f994e0296ed44ecac2869fa65e7f58bf986 to 1.26
Additional testing:
Also, I ran the sources/extensions/tracers/datadog/demo both with and without these changes. Verified that the produced span's "operation name" before these changes is not as desired. Verified that the produced span's "operation name" after these changes is as desired.
Desired: "Operation name" is "envoy.proxy", and "resource name" is the operation_name passed to startSpan.
Risk Level: low
Testing: See the modified unit test.
Docs Changes: n/a
Release Notes: updated

thanks for raising this @florianmutter would you be able to do similar for 1.24,1.25, and 1.27 (if affected) ?

cc @dgoffredo

thanks for raising this @florianmutter would you be able to do similar for 1.24,1.25, and 1.27 (if affected) ?

I think only 1.27 is also affected. Will create a PR as well

Backport for 1.27 here: https://github.com/envoyproxy/envoy/pull/30186


How can I login and download your dataset?

I did not find a position to register a account...

Same issue. I'd like to download the dataset from "http://www.4seasons-dataset.com/dataset".
However, when I click the "form" link, I'm informed to log in "cvg.cit.tum.de" and I have no ideas about this.

Hi, sorry for the inconvenience.
Please check the download link. You can find all the related data here.


Prevent Identify when Dropping a Point

I would like to utilize this widget but when I add it to the viewer and attempt to drop a point the identify executes and seems to prevent the analysis from occurring.  The buffer draws but no features are returned.  Thanks in advance for any help you can provide!

I assume you are talking about the Nearby widget (issues in this repo are for all the widgets listed). Be sure to configure the widget with mapClickMode: true when including it in the CMV. That option should prevent map clicks from other widgets from being executed.

I am referring to the Nearby widget and thanks for the response!   I currently have the widget configured with  mapClickMode: true but the identify widget still executes when I drop the point.

kjnueller,
I solved the issue by adding the connectMapClick and disconnectMapClick functions to the widget, and modifying the activateMapPointDrop and handleDrawEnd functions. Also, require the "dojo/topic" module.
        disconnectMapClick: function () {
            topic.publish('mapClickMode/setCurrent', 'draw');
        },
        connectMapClick: function () {
            topic.publish('mapClickMode/setDefault');
        },

        activateMapPointDrop: function (evt) {
            this.disconnectMapClick();
            //            this.mapClickMode.current = 'draw';
            this.clearResults();
            this.dropPointButton.set('label', 'Waiting for point drop');
            this.dropPointButton.set('disabled', true);
            this.drawTool.activate(Draw.POINT);
        },

        handleDrawEnd: function (evt) {
            this.connectMapClick();
            //            this.mapClickMode.current = this.mapClickMode.defaultMode;
            this.droppedPoint = evt;
            this.drawTool.deactivate();
            this.showPoint(this.droppedPoint.geometry);
            this.dropPointButton.set('label', 'Change point location');
            this.dropPointButton.set('disabled', false);
            put(this.clearDropButton.domNode, '!off');

            // do the analysis
            this.doNearbyAnalysis();
        },

darinatch,
Thanks for responding! I haven't had a chance to dive in to this. Your improvement would make a great addition. Would you consider doing a pull request?

Brian,
Let me read the documentation of how to create a pull request, and I will do it. :)

Brian,
I did the pull request, but I am not sure I did it right. I chose to create a new branch, and I probably should have just committed to master. It is waiting to be merged. Please, let me know if I should do anything else.
Thank you!

Looks like you did the pull request on your own repository. You need to choose my repository when creating the pull request.

@darinatch I would still accept a PR for this issue, if you're willing.


No yolov3.weights file exist?

Hi:
try to run main.py but got error, could you please help to check?
D:\project\opencv\Proctoring-AI>python main.py
D:\python\3.7.7\lib\site-packages\numpy_distributor_init.py:32: UserWarning: loaded more than 1 DLL from .libs:
D:\python\3.7.7\lib\site-packages\numpy.libs\libopenblas.NOIJJG62EMASZI6NYURL6JBKM4EVBGM7.gfortran-win_amd64.dll
D:\python\3.7.7\lib\site-packages\numpy.libs\libopenblas.TXA6YQSD3GCQQC22GEQ54J2UDCXDXHWN.gfortran-win_amd64.dll
stacklevel=1)
2020-07-07 10:34:13.058164: W tensorflow/stream_executor/platform/default/dso_loader.cc:55] Could not load dynamic library 'cudart64_101.dll'; dlerror: cudart64_101.dll not found
2020-07-07 10:34:13.063303: I tensorflow/stream_executor/cuda/cudart_stub.cc:29] Ignore above cudart dlerror if you do not have a GPU set up on your machine.
2020-07-07 10:34:31.033803: W tensorflow/stream_executor/platform/default/dso_loader.cc:55] Could not load dynamic library 'nvcuda.dll'; dlerror: nvcuda.dll not found
2020-07-07 10:34:31.045068: E tensorflow/stream_executor/cuda/cuda_driver.cc:313] failed call to cuInit: UNKNOWN ERROR (303)
2020-07-07 10:34:31.052288: I tensorflow/stream_executor/cuda/cuda_diagnostics.cc:169] retrieving CUDA diagnostic information for host: DESKTOP-FCB4CGP
2020-07-07 10:34:31.056705: I tensorflow/stream_executor/cuda/cuda_diagnostics.cc:176] hostname: DESKTOP-FCB4CGP
2020-07-07 10:34:31.068621: I tensorflow/core/platform/cpu_feature_guard.cc:143] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2
2020-07-07 10:34:31.285820: I tensorflow/compiler/xla/service/service.cc:168] XLA service 0x1f307b30cf0 initialized for platform Host (this does not guarantee that XLA will be used). Devices:
2020-07-07 10:34:31.290499: I tensorflow/compiler/xla/service/service.cc:176]   StreamExecutor device (0): Host, Default Version
Traceback (most recent call last):
File "main.py", line 22, in
load_darknet_weights(yolo, 'yolov3.weights')
File "D:\project\opencv\Proctoring-AI\yolo_helper.py", line 35, in load_darknet_weights
wf = open(weights_file, 'rb')
FileNotFoundError: [Errno 2] No such file or directory: 'yolov3.weights'

Please refer to this article https://medium.com/analytics-vidhya/count-people-in-webcam-using-yolov3-tensorflow-f407679967d5?source=friends_link&sk=95ae7a010eeef429a407a7a2de2ff8ec
In this I have mentioned the way to download it you can follow that.

You can download them by running this code in python:
import wget
url = 'https://pjreddie.com/media/files/yolov3.weights'
yolov3 = wget.download(url, out='yolov3.weights')

Or you can download from here and place it in the working directory.