text:
bundle update can't resolve dependencies

Issue
Hi all! When I try to bundle update in my project - it can't continue. Resolving dependencies takes infinity time. When I removing gem shoryuken from my gemfile - bundle update can update my gems. But if I return him - bundle update can't update again.
Expected
Bundler updated my gems
Happened
Infinity resolving dependencies
Log
bundle update
Fetching https://github.com/refile/refile.git
Fetching https://github.com/bitbucket-rest-api/bitbucket.git
Fetching https://github.com/rails/webpacker.git
Fetching https://github.com/decioferreira/omniauth-linkedin-oauth2.git
Fetching https://github.com/seuros/activejob-stats.git
Fetching https://github.com/rollbar/rollbar-gem.git
Fetching https://github.com/kaize/validates.git
Fetching https://github.com/superpowr/ruby-sparkpost.git
Fetching https://github.com/stympy/faker.git
Fetching gem metadata from https://rubygems.org/......
Fetching gem metadata from https://rubygems.org/.
Resolving dependencies............................

Environment
Bundler       1.16.0.pre.3
  Platforms   ruby, x86_64-linux
Ruby          2.4.2p198 (2017-09-14 revision 59899) [x86_64-linux]
  Full Path   /usr/local/bin/ruby
  Config Dir  /usr/local/etc
RubyGems      2.6.13
  Gem Home    /usr/src/app/vendor/bundle
  Gem Path    /internal/.gem/ruby/2.4.0:/usr/local/lib/ruby/gems/2.4.0:/usr/src/app/vendor/bundle
  User Path   /internal/.gem/ruby/2.4.0
  Bin Dir     /usr/src/app/vendor/bundle/bin
Tools
  Git         2.14.1
  RVM         not installed
  rbenv       not installed
  chruby      not installed

Bundler Build Metadata
Built At          2017-10-05
Git SHA           d94616dd8
Released Version  true

Bundler settings
jobs
  Set for your local app (/usr/src/app/vendor/bundle/config): "3"
disable_shared_gems
  Set for your local app (/usr/src/app/vendor/bundle/config): true
silence_root_warning
  Set via BUNDLE_SILENCE_ROOT_WARNING: true
app_config
  Set via BUNDLE_APP_CONFIG: "/usr/src/app/vendor/bundle"
bin
  Set via BUNDLE_BIN: "/usr/src/app/vendor/bundle/bin"
path
  Set via BUNDLE_PATH: "/usr/src/app/vendor/bundle"

Gemfile
Gemfile
source 'https://rubygems.org'

git_source(:github) do |repo_name|
  repo_name = "#{repo_name}/#{repo_name}" unless repo_name.include?("/")
  "https://github.com/#{repo_name}.git"
end

gem 'rails'
gem 'shoryuken'
gem 'lograge'
gem 'configus'
gem 'rails-perftest'
gem 'ruby-prof'
gem 'dry-validation'
gem 'i18n-js'
gem 'rails-i18n'
gem 'responders'
# gem 'active_form'
gem 'pg'
gem 'less-rails'
gem 'sass-rails'
gem 'uglifier', '>= 1.3.0'
gem 'term-ansicolor'
gem 'cocoon'
gem 'simple_form'
gem 'mini_magick'
gem 'refile', github: 'refile/refile', require: ['refile/rails', 'refile/file_double']
gem 'refile-mini_magick'
gem 'refile-s3'
gem 'oj', '~> 3.1.4'
gem 'aws-sdk' #, '= 2.2.16'
# gem 'aws-sdk-rails'
gem 'pundit'
gem 'money-rails'
gem 'eu_central_bank'
gem 'enumerize'
gem 'ddtrace', '0.7.2'
# gem 'github-linguist'
# gem 'github-markup', require: 'github/markup'
gem 'commonmarker'
gem 'kaminari'
gem 'puma'
# gem 'seedbank'
gem 'video_info'
gem 'http_accept_language'
gem 'gravatarify'
gem 'docker-api', require: 'docker'
gem 'bitbucket_rest_api', github: 'bitbucket-rest-api/bitbucket', ref: '8373f38f08ce4682a17232e16362bfcf954d4a3f'
gem 'octokit', '~> 4.0'
gem 'simple_oauth'
gem 'childprocess'
gem 'rest-client'
gem 'rouge'
gem 'select2-rails'
gem 'breadcrumbs_on_rails'
gem 'sprockets-es6'
gem 'staccato'
gem 'reform-rails'
gem 'browser'
gem 'geocoder'
# gem 'react-rails'
gem 'connection_pool'
gem 'first_click_free'
gem 'webpacker', github: 'rails/webpacker'
gem 'bootsnap'

# See https://github.com/sstephenson/execjs#readme for more supported runtimes
gem 'therubyracer', platforms: :ruby
gem 'execjs'
gem 'state_machines'
gem 'state_machines-activerecord'
gem 'ransack'

gem 'jquery-rails'
gem 'hamlit-rails'
# gem 'autoprefixer-rails'
gem 'font-awesome-sass'
# gem 'premailer-rails'
gem 'nokogiri'
gem 'reverse_markdown'
gem 'bootstrap-datepicker-rails'

gem 'stripe'
gem 'omniauth'
gem 'omniauth-github'
gem 'omniauth-bitbucket'
gem 'omniauth-facebook'
gem 'omniauth-linkedin-oauth2', github: 'decioferreira/omniauth-linkedin-oauth2', tag: 'master'
gem 'dogstatsd-ruby', require: 'datadog/statsd'
# gem 'rails-observers'
gem 'sinatra'
gem 'activejob-stats', git: 'https://github.com/seuros/activejob-stats.git'
gem 'dry-container'
gem 'dry-auto_inject'

gem 'git'

gem 'rake'
gem 'rollbar', github: 'rollbar/rollbar-gem', tag: 'master'
gem 'js-routes'
gem 'russian'
# gem 'split', require: 'split/dashboard'
gem 'vanity'

# Use ActiveModel has_secure_password
gem 'bcrypt', '~> 3.1.7'

gem 'gon'
gem 'active_model_serializers'
gem 'draper'
gem 'validates', github: 'kaize/validates', tag: 'master'
gem 'virtus'
gem 'koala'
gem 'counter_culture'
gem 'traco'
gem 'mixpanel-ruby'

# gem 'analytics-ruby', require: 'segment/analytics'
gem 'smarter_csv'

gem 'sparkpost', github: 'superpowr/ruby-sparkpost', ref: 'c48a070ed6639aa882c2c9aa95d122fa9f2a10c9'

gem 'uri-ssh_git'

gem 'jbuilder'

gem 'diplomat'
gem 'rubyzip'

# Use Capistrano for deployment
group :development do
  gem 'foreman'
  # gem 'fake_sqs', github: 'plugin73/fake_sqs'
  gem 'bullet'
  # gem 'pry-rails'
  gem 'awesome_print'
  # gem 'quiet_assets'

  # gem 'web-console'
  # gem 'binding_of_caller', '~> 0.7.3.pre1'
  gem 'web-console', '>= 3.3.0'
  gem 'listen'
  # Spring speeds up development by keeping your application running in the background. Read more: https://github.com/rails/spring
  gem 'spring'
  gem 'spring-watcher-listen', '> 2.0.0'
end

group :development, :test do
  gem 'faker', github: 'stympy/faker'
  gem 'mocha'
  # gem 'database_cleaner'
  gem 'factory_girl_rails'
  gem 'capybara'
  gem 'poltergeist'
  gem 'selenium-webdriver'
  # gem 'chromedriver-helper'
end

group :test do
  # gem 'simplecov', require: false
  gem 'webmock'
  gem 'stripe-ruby-mock'
  gem 'wrong'
  # gem 'site_prism'
  gem 'launchy'
  # gem 'poltergeist'
  gem 'minitest', '> 5.10', '!= 5.10.2'
end

Gemfile.lock
GIT
  remote: https://github.com/bitbucket-rest-api/bitbucket.git
  revision: 8373f38f08ce4682a17232e16362bfcf954d4a3f
  ref: 8373f38f08ce4682a17232e16362bfcf954d4a3f
  specs:
    bitbucket_rest_api (0.1.7)
      faraday (~> 0.9.0)
      faraday_middleware (~> 0.9.0)
      hashie
      multi_json (>= 1.7.5, < 2.0)
      nokogiri (>= 1.5.2)
      simple_oauth

GIT
  remote: https://github.com/decioferreira/omniauth-linkedin-oauth2.git
  revision: 41dc98318e63b9789de34864c6a5d4a331508da7
  tag: master
  specs:
    omniauth-linkedin-oauth2 (0.2.5)
      omniauth (~> 1.0)
      omniauth-oauth2

GIT
  remote: https://github.com/kaize/validates.git
  revision: b9dc527cdb757d438eeb44497b570eddad896f9c
  tag: master
  specs:
    validates (1.0.0)
      activemodel (>= 3.0.0)
      activesupport (>= 3.0.0)

GIT
  remote: https://github.com/rails/webpacker.git
  revision: 3987c661895b6ab1b8061a48db042f2100e61b8f
  specs:
    webpacker (3.0.2)
      activesupport (>= 4.2)
      rack-proxy (>= 0.6.1)
      railties (>= 4.2)

GIT
  remote: https://github.com/refile/refile.git
  revision: 3dc5f524c831484a24fa4398194bee2a58a3bd1c
  specs:
    refile (0.6.2)
      mime-types
      rest-client (~> 1.8)
      sinatra (>= 2.0.0, <= 3.0.0)

GIT
  remote: https://github.com/rollbar/rollbar-gem.git
  revision: efe6468af071f0a37751033dc9e35dbec224be6c
  tag: master
  specs:
    rollbar (2.15.4)
      multi_json

GIT
  remote: https://github.com/seuros/activejob-stats.git
  revision: 07d62cc57208d2bf8a0e58a5330fe7ae683ae989
  specs:
    activejob-stats (4.2.0.alpha)
      activejob

GIT
  remote: https://github.com/stympy/faker.git
  revision: e68c031f490a86a9f48878e2da1a984f37e4596e
  specs:
    faker (1.8.4)
      i18n (~> 0.5)

GIT
  remote: https://github.com/superpowr/ruby-sparkpost.git
  revision: c48a070ed6639aa882c2c9aa95d122fa9f2a10c9
  ref: c48a070ed6639aa882c2c9aa95d122fa9f2a10c9
  specs:
    sparkpost (0.1.2)
      http (= 0.9.8)

GEM
  remote: https://rubygems.org/
  specs:
    actioncable (5.1.4)
      actionpack (= 5.1.4)
      nio4r (~> 2.0)
      websocket-driver (~> 0.6.1)
    actionmailer (5.1.4)
      actionpack (= 5.1.4)
      actionview (= 5.1.4)
      activejob (= 5.1.4)
      mail (~> 2.5, >= 2.5.4)
      rails-dom-testing (~> 2.0)
    actionpack (5.1.4)
      actionview (= 5.1.4)
      activesupport (= 5.1.4)
      rack (~> 2.0)
      rack-test (>= 0.6.3)
      rails-dom-testing (~> 2.0)
      rails-html-sanitizer (~> 1.0, >= 1.0.2)
    actionview (5.1.4)
      activesupport (= 5.1.4)
      builder (~> 3.1)
      erubi (~> 1.4)
      rails-dom-testing (~> 2.0)
      rails-html-sanitizer (~> 1.0, >= 1.0.3)
    active_model_serializers (0.10.6)
      actionpack (>= 4.1, < 6)
      activemodel (>= 4.1, < 6)
      case_transform (>= 0.2)
      jsonapi-renderer (>= 0.1.1.beta1, < 0.2)
    activejob (5.1.4)
      activesupport (= 5.1.4)
      globalid (>= 0.3.6)
    activemodel (5.1.4)
      activesupport (= 5.1.4)
    activemodel-serializers-xml (1.0.2)
      activemodel (> 5.x)
      activesupport (> 5.x)
      builder (~> 3.1)
    activerecord (5.1.4)
      activemodel (= 5.1.4)
      activesupport (= 5.1.4)
      arel (~> 8.0)
    activesupport (5.1.4)
      concurrent-ruby (~> 1.0, >= 1.0.2)
      i18n (~> 0.7)
      minitest (~> 5.1)
      tzinfo (~> 1.1)
    addressable (2.5.2)
      public_suffix (>= 2.0.2, < 4.0)
    after_commit_action (1.1.0)
      activerecord (>= 3.0.0)
      activesupport (>= 3.0.0)
    ansi (1.5.0)
    arel (8.0.0)
    ast (2.3.0)
    awesome_print (1.8.0)
    aws-sdk (2.10.62)
      aws-sdk-resources (= 2.10.62)
    aws-sdk-core (2.10.62)
      aws-sigv4 (~> 1.0)
      jmespath (~> 1.0)
    aws-sdk-resources (2.10.62)
      aws-sdk-core (= 2.10.62)
    aws-sigv4 (1.0.2)
    axiom-types (0.1.1)
      descendants_tracker (~> 0.0.4)
      ice_nine (~> 0.11.0)
      thread_safe (~> 0.3, >= 0.3.1)
    babel-source (5.8.35)
    babel-transpiler (0.7.0)
      babel-source (>= 4.0, < 6)
      execjs (~> 2.0)
    bcrypt (3.1.11)
    bindex (0.5.0)
    bootsnap (1.1.5)
      msgpack (~> 1.0)
    bootstrap-datepicker-rails (1.7.1.1)
      railties (>= 3.0)
    breadcrumbs_on_rails (3.0.1)
    browser (2.5.1)
    builder (3.2.3)
    bullet (5.6.1)
      activesupport (>= 3.0.0)
      uniform_notifier (~> 1.10.0)
    capybara (2.15.4)
      addressable
      mini_mime (>= 0.1.3)
      nokogiri (>= 1.3.3)
      rack (>= 1.0.0)
      rack-test (>= 0.5.4)
      xpath (~> 2.0)
    case_transform (0.2)
      activesupport
    childprocess (0.8.0)
      ffi (~> 1.0, >= 1.0.11)
    cliver (0.3.2)
    cocoon (1.2.10)
    coercible (1.0.0)
      descendants_tracker (~> 0.0.1)
    commonjs (0.2.7)
    commonmarker (0.17.4)
      ruby-enum (~> 0.5)
    concurrent-ruby (1.0.5)
    configus (0.0.5)
    connection_pool (2.2.1)
    counter_culture (1.8.2)
      activerecord (>= 3.0.0)
      activesupport (>= 3.0.0)
      after_commit_action (~> 1.0)
    crack (0.4.3)
      safe_yaml (~> 1.0.0)
    crass (1.0.2)
    dante (0.2.0)
    ddtrace (0.7.2)
      msgpack
    declarative (0.0.10)
    declarative-builder (0.1.0)
      declarative-option (< 0.2.0)
    declarative-option (0.1.0)
    descendants_tracker (0.0.4)
      thread_safe (~> 0.3, >= 0.3.1)
    diff-lcs (1.2.5)
    diplomat (2.0.2)
      faraday (~> 0.9)
      json
    disposable (0.4.3)
      declarative (>= 0.0.9, < 1.0.0)
      declarative-builder (< 0.2.0)
      declarative-option (< 0.2.0)
      representable (>= 2.4.0, <= 3.1.0)
      uber (< 0.2.0)
    docker-api (1.33.6)
      excon (>= 0.38.0)
      json
    dogstatsd-ruby (3.0.0)
    domain_name (0.5.20170404)
      unf (>= 0.0.5, < 1.0.0)
    draper (3.0.0)
      actionpack (~> 5.0)
      activemodel (~> 5.0)
      activemodel-serializers-xml (~> 1.0)
      activesupport (~> 5.0)
      request_store (~> 1.0)
    dry-auto_inject (0.4.4)
      dry-container (>= 0.3.4)
    dry-configurable (0.7.0)
      concurrent-ruby (~> 1.0)
    dry-container (0.6.0)
      concurrent-ruby (~> 1.0)
      dry-configurable (~> 0.1, >= 0.1.3)
    dry-core (0.3.4)
      concurrent-ruby (~> 1.0)
    dry-equalizer (0.2.0)
    dry-logic (0.4.2)
      dry-container (~> 0.2, >= 0.2.6)
      dry-core (~> 0.2)
      dry-equalizer (~> 0.2)
    dry-types (0.12.1)
      concurrent-ruby (~> 1.0)
      dry-configurable (~> 0.1)
      dry-container (~> 0.3)
      dry-core (~> 0.2, >= 0.2.1)
      dry-equalizer (~> 0.2)
      dry-logic (~> 0.4, >= 0.4.2)
      inflecto (~> 0.0.0, >= 0.0.2)
    dry-validation (0.11.1)
      concurrent-ruby (~> 1.0)
      dry-configurable (~> 0.1, >= 0.1.3)
      dry-core (~> 0.2, >= 0.2.1)
      dry-equalizer (~> 0.2)
      dry-logic (~> 0.4, >= 0.4.0)
      dry-types (~> 0.12.0)
    enumerize (2.1.2)
      activesupport (>= 3.2)
    equalizer (0.0.11)
    erubi (1.7.0)
    eu_central_bank (1.1.3)
      money (~> 6.9.0)
      nokogiri (>= 1.6.3, < 2.0)
    excon (0.59.0)
    execjs (2.7.0)
    factory_girl (4.8.1)
      activesupport (>= 3.0.0)
    factory_girl_rails (4.8.0)
      factory_girl (~> 4.8.0)
      railties (>= 3.0.0)
    faraday (0.9.2)
      multipart-post (>= 1.2, < 3)
    faraday_middleware (0.9.2)
      faraday (>= 0.7.4, < 0.10)
    ffi (1.9.18)
    first_click_free (1.0.0)
      rails (>= 3.1)
    font-awesome-sass (4.7.0)
      sass (>= 3.2)
    foreman (0.84.0)
      thor (~> 0.19.1)
    geocoder (1.4.4)
    git (1.3.0)
    globalid (0.4.0)
      activesupport (>= 4.2.0)
    gon (6.2.0)
      actionpack (>= 3.0)
      multi_json
      request_store (>= 1.0)
    gravatarify (3.1.1)
    grease (0.3.1)
    hamlit (2.8.4)
      temple (>= 0.8.0)
      thor
      tilt
    hamlit-rails (0.2.0)
      actionpack (>= 4.0.1)
      activesupport (>= 4.0.1)
      hamlit (>= 1.2.0)
      railties (>= 4.0.1)
    hashdiff (0.3.7)
    hashie (3.5.6)
    http (0.9.8)
      addressable (~> 2.3)
      http-cookie (~> 1.0)
      http-form_data (~> 1.0.1)
      http_parser.rb (~> 0.6.0)
    http-cookie (1.0.3)
      domain_name (~> 0.5)
    http-form_data (1.0.3)
    http_accept_language (2.1.1)
    http_parser.rb (0.6.0)
    i18n (0.8.6)
    i18n-js (3.0.1)
      i18n (~> 0.6, >= 0.6.6)
    ice_nine (0.11.2)
    inflecto (0.0.2)
    iso8601 (0.9.1)
    jbuilder (2.7.0)
      activesupport (>= 4.2.0)
      multi_json (>= 1.2)
    jmespath (1.3.1)
    jquery-rails (4.3.1)
      rails-dom-testing (>= 1, < 3)
      railties (>= 4.2.0)
      thor (>= 0.14, < 2.0)
    js-routes (1.4.1)
      railties (>= 3.2)
      sprockets-rails
    json (2.1.0)
    jsonapi-renderer (0.1.3)
    jwt (1.5.6)
    kaminari (1.0.1)
      activesupport (>= 4.1.0)
      kaminari-actionview (= 1.0.1)
      kaminari-activerecord (= 1.0.1)
      kaminari-core (= 1.0.1)
    kaminari-actionview (1.0.1)
      actionview
      kaminari-core (= 1.0.1)
    kaminari-activerecord (1.0.1)
      activerecord
      kaminari-core (= 1.0.1)
    kaminari-core (1.0.1)
    koala (3.0.0)
      addressable
      faraday
      json (>= 1.8)
    launchy (2.4.3)
      addressable (~> 2.3)
    less (2.6.0)
      commonjs (~> 0.2.7)
    less-rails (3.0.0)
      actionpack (>= 4.0)
      grease
      less (~> 2.6.0)
      sprockets (> 2, < 4)
      tilt
    libv8 (3.16.14.19)
    listen (3.1.5)
      rb-fsevent (~> 0.9, >= 0.9.4)
      rb-inotify (~> 0.9, >= 0.9.7)
      ruby_dep (~> 1.2)
    lograge (0.7.1)
      actionpack (>= 4, < 5.2)
      activesupport (>= 4, < 5.2)
      railties (>= 4, < 5.2)
      request_store (~> 1.0)
    loofah (2.1.1)
      crass (~> 1.0.2)
      nokogiri (>= 1.5.9)
    mail (2.6.6)
      mime-types (>= 1.16, < 4)
    metaclass (0.0.4)
    method_source (0.9.0)
    mime-types (2.99.3)
    mini_magick (4.8.0)
    mini_mime (0.1.4)
    mini_portile2 (2.3.0)
    minitest (5.10.3)
    mixpanel-ruby (2.2.0)
    mocha (1.3.0)
      metaclass (~> 0.0.1)
    monetize (1.7.0)
      money (~> 6.9)
    money (6.9.0)
      i18n (>= 0.6.4, < 0.9)
    money-rails (1.9.0)
      activesupport (>= 3.0)
      monetize (~> 1.7.0)
      money (~> 6.9.0)
      railties (>= 3.0)
    msgpack (1.1.0)
    multi_json (1.12.2)
    multi_xml (0.6.0)
    multipart-post (2.0.0)
    mustermann (1.0.1)
    net_http_timeout_errors (0.3.0)
    netrc (0.11.0)
    nio4r (2.1.0)
    nokogiri (1.8.1)
      mini_portile2 (~> 2.3.0)
    oauth (0.5.3)
    oauth2 (1.4.0)
      faraday (>= 0.8, < 0.13)
      jwt (~> 1.0)
      multi_json (~> 1.3)
      multi_xml (~> 0.5)
      rack (>= 1.2, < 3)
    octokit (4.7.0)
      sawyer (~> 0.8.0, >= 0.5.3)
    oga (2.11)
      ast
      ruby-ll (~> 2.1)
    oj (3.1.4)
    omniauth (1.7.1)
      hashie (>= 3.4.6, < 3.6.0)
      rack (>= 1.6.2, < 3)
    omniauth-bitbucket (0.0.2)
      multi_json (~> 1.7)
      omniauth (~> 1.1)
      omniauth-oauth (~> 1.0)
    omniauth-facebook (4.0.0)
      omniauth-oauth2 (~> 1.2)
    omniauth-github (1.3.0)
      omniauth (~> 1.5)
      omniauth-oauth2 (>= 1.4.0, < 2.0)
    omniauth-oauth (1.1.0)
      oauth
      omniauth (~> 1.0)
    omniauth-oauth2 (1.4.0)
      oauth2 (~> 1.0)
      omniauth (~> 1.2)
    pg (0.21.0)
    poltergeist (1.16.0)
      capybara (~> 2.1)
      cliver (~> 0.3.1)
      websocket-driver (>= 0.2.0)
    polyamorous (1.3.1)
      activerecord (>= 3.0)
    predicated (0.2.6)
    public_suffix (3.0.0)
    puma (3.10.0)
    pundit (1.1.0)
      activesupport (>= 3.0.0)
    rack (2.0.3)
    rack-protection (2.0.0)
      rack
    rack-proxy (0.6.2)
      rack
    rack-test (0.7.0)
      rack (>= 1.0, < 3)
    rails (5.1.4)
      actioncable (= 5.1.4)
      actionmailer (= 5.1.4)
      actionpack (= 5.1.4)
      actionview (= 5.1.4)
      activejob (= 5.1.4)
      activemodel (= 5.1.4)
      activerecord (= 5.1.4)
      activesupport (= 5.1.4)
      bundler (>= 1.3.0)
      railties (= 5.1.4)
      sprockets-rails (>= 2.0.0)
    rails-dom-testing (2.0.3)
      activesupport (>= 4.2.0)
      nokogiri (>= 1.6)
    rails-html-sanitizer (1.0.3)
      loofah (~> 2.0)
    rails-i18n (5.0.4)
      i18n (~> 0.7)
      railties (~> 5.0)
    rails-perftest (0.0.7)
    railties (5.1.4)
      actionpack (= 5.1.4)
      activesupport (= 5.1.4)
      method_source
      rake (>= 0.8.7)
      thor (>= 0.18.1, < 2.0)
    rake (12.1.0)
    ransack (1.8.4)
      actionpack (>= 3.0)
      activerecord (>= 3.0)
      activesupport (>= 3.0)
      i18n
      polyamorous (~> 1.3)
    rb-fsevent (0.10.2)
    rb-inotify (0.9.10)
      ffi (>= 0.5.0, < 2)
    ref (2.0.0)
    refile-mini_magick (0.2.0)
      mini_magick (~> 4.0)
      refile (~> 0.5)
    refile-s3 (0.2.0)
      aws-sdk (~> 2.0)
      refile (~> 0.6.0)
    reform (2.2.4)
      disposable (>= 0.4.1)
      representable (>= 2.4.0, < 3.1.0)
    reform-rails (0.1.7)
      activemodel (>= 3.2)
      reform (>= 2.2.0)
    representable (3.0.4)
      declarative (< 0.1.0)
      declarative-option (< 0.2.0)
      uber (< 0.2.0)
    request_store (1.3.2)
    responders (2.4.0)
      actionpack (>= 4.2.0, < 5.3)
      railties (>= 4.2.0, < 5.3)
    rest-client (1.8.0)
      http-cookie (>= 1.0.2, < 2.0)
      mime-types (>= 1.16, < 3.0)
      netrc (~> 0.7)
    reverse_markdown (1.0.3)
      nokogiri
    rouge (3.0.0)
    ruby-enum (0.7.1)
      i18n
    ruby-ll (2.1.2)
      ansi
      ast
    ruby-prof (0.16.2)
    ruby2ruby (2.4.0)
      ruby_parser (~> 3.1)
      sexp_processor (~> 4.6)
    ruby_dep (1.5.0)
    ruby_parser (3.10.1)
      sexp_processor (~> 4.9)
    rubyzip (1.2.1)
    russian (0.6.0)
      i18n (>= 0.5.0)
    safe_yaml (1.0.4)
    sass (3.5.2)
      sass-listen (~> 4.0.0)
    sass-listen (4.0.0)
      rb-fsevent (~> 0.9, >= 0.9.4)
      rb-inotify (~> 0.9, >= 0.9.7)
    sass-rails (5.0.6)
      railties (>= 4.0.0, < 6)
      sass (~> 3.1)
      sprockets (>= 2.8, < 4.0)
      sprockets-rails (>= 2.0, < 4.0)
      tilt (>= 1.1, < 3)
    sawyer (0.8.1)
      addressable (>= 2.3.5, < 2.6)
      faraday (~> 0.8, < 1.0)
    select2-rails (4.0.3)
      thor (~> 0.14)
    selenium-webdriver (3.6.0)
      childprocess (~> 0.5)
      rubyzip (~> 1.0)
    sexp_processor (4.10.0)
    shoryuken (3.1.12)
      aws-sdk-core (>= 2)
      concurrent-ruby
      thor
    simple_form (3.5.0)
      actionpack (> 4, < 5.2)
      activemodel (> 4, < 5.2)
    simple_oauth (0.3.1)
    sinatra (2.0.0)
      mustermann (~> 1.0)
      rack (~> 2.0)
      rack-protection (= 2.0.0)
      tilt (~> 2.0)
    smarter_csv (1.1.4)
    spring (2.0.2)
      activesupport (>= 4.2)
    spring-watcher-listen (2.0.1)
      listen (>= 2.7, < 4.0)
      spring (>= 1.2, < 3.0)
    sprockets (3.7.1)
      concurrent-ruby (~> 1.0)
      rack (> 1, < 3)
    sprockets-es6 (0.9.2)
      babel-source (>= 5.8.11)
      babel-transpiler
      sprockets (>= 3.0.0)
    sprockets-rails (3.2.1)
      actionpack (>= 4.0)
      activesupport (>= 4.0)
      sprockets (>= 3.0.0)
    staccato (0.5.1)
    state_machines (0.5.0)
    state_machines-activemodel (0.5.0)
      activemodel (>= 4.1, < 5.2)
      state_machines (>= 0.5.0)
    state_machines-activerecord (0.5.0)
      activerecord (>= 4.1, < 5.2)
      state_machines-activemodel (>= 0.5.0)
    stripe (3.3.2)
      faraday (~> 0.9)
    stripe-ruby-mock (2.5.0)
      dante (>= 0.2.0)
      multi_json (~> 1.0)
      stripe (>= 2.0.3)
    temple (0.8.0)
    term-ansicolor (1.6.0)
      tins (~> 1.0)
    therubyracer (0.12.3)
      libv8 (~> 3.16.14.15)
      ref
    thor (0.19.4)
    thread_safe (0.3.6)
    tilt (2.0.8)
    tins (1.15.0)
    traco (3.2.1)
      activerecord (>= 3.0)
    tzinfo (1.2.3)
      thread_safe (~> 0.1)
    uber (0.1.0)
    uglifier (3.2.0)
      execjs (>= 0.3.0, < 3)
    unf (0.1.4)
      unf_ext
    unf_ext (0.0.7.4)
    uniform_notifier (1.10.0)
    uri-ssh_git (2.0.0)
    vanity (2.2.8)
      i18n
    video_info (2.7)
      iso8601 (~> 0.9.1)
      net_http_timeout_errors (~> 0.3.0)
      oga (~> 2.7)
    virtus (1.0.5)
      axiom-types (~> 0.1)
      coercible (~> 1.0)
      descendants_tracker (~> 0.0, >= 0.0.3)
      equalizer (~> 0.0, >= 0.0.9)
    web-console (3.5.1)
      actionview (>= 5.0)
      activemodel (>= 5.0)
      bindex (>= 0.4.0)
      railties (>= 5.0)
    webmock (3.1.0)
      addressable (>= 2.3.6)
      crack (>= 0.3.2)
      hashdiff
    websocket-driver (0.6.5)
      websocket-extensions (>= 0.1.0)
    websocket-extensions (0.1.2)
    wrong (0.7.1)
      diff-lcs (~> 1.2.5)
      predicated (~> 0.2.6)
      ruby2ruby (>= 2.0.1)
      ruby_parser (>= 3.0.1)
      sexp_processor (>= 4.0)
    xpath (2.1.0)
      nokogiri (~> 1.3)

PLATFORMS
  ruby

DEPENDENCIES
  active_model_serializers
  activejob-stats!
  awesome_print
  aws-sdk
  bcrypt (~> 3.1.7)
  bitbucket_rest_api!
  bootsnap
  bootstrap-datepicker-rails
  breadcrumbs_on_rails
  browser
  bullet
  capybara
  childprocess
  cocoon
  commonmarker
  configus
  connection_pool
  counter_culture
  ddtrace (= 0.7.2)
  diplomat
  docker-api
  dogstatsd-ruby
  draper
  dry-auto_inject
  dry-container
  dry-validation
  enumerize
  eu_central_bank
  execjs
  factory_girl_rails
  faker!
  first_click_free
  font-awesome-sass
  foreman
  geocoder
  git
  gon
  gravatarify
  hamlit-rails
  http_accept_language
  i18n-js
  jbuilder
  jquery-rails
  js-routes
  kaminari
  koala
  launchy
  less-rails
  listen
  lograge
  mini_magick
  minitest (> 5.10, != 5.10.2)
  mixpanel-ruby
  mocha
  money-rails
  nokogiri
  octokit (~> 4.0)
  oj (~> 3.1.4)
  omniauth
  omniauth-bitbucket
  omniauth-facebook
  omniauth-github
  omniauth-linkedin-oauth2!
  pg
  poltergeist
  puma
  pundit
  rails
  rails-i18n
  rails-perftest
  rake
  ransack
  refile!
  refile-mini_magick
  refile-s3
  reform-rails
  responders
  rest-client
  reverse_markdown
  rollbar!
  rouge
  ruby-prof
  rubyzip
  russian
  sass-rails
  select2-rails
  selenium-webdriver
  shoryuken
  simple_form
  simple_oauth
  sinatra
  smarter_csv
  sparkpost!
  spring
  spring-watcher-listen (> 2.0.0)
  sprockets-es6
  staccato
  state_machines
  state_machines-activerecord
  stripe
  stripe-ruby-mock
  term-ansicolor
  therubyracer
  traco
  uglifier (>= 1.3.0)
  uri-ssh_git
  validates!
  vanity
  video_info
  virtus
  web-console (>= 3.3.0)
  webmock
  webpacker!
  wrong

BUNDLED WITH
   1.16.0.pre.3

bundler version - from stable to 1.16.0.pre.3

Hi, @PlugIN73 !
I investigated this issue and found the following:

it is not a bundler problem
dependency resolver goes through all the possible options to find a suitable version of aws-sdk, because it is set fairly widely in the Shoryuken gem - as ">= 2", and aws-sdk has a lot of releases above 2.0
you can fix the aws-sdk version as "~> 2" and enjoy with bundle update passed!

@v-kolesnikov thank you! 👍

repo: bundler/bundler


text:
ws.Trading.SubscribeToOrderUpdatesAsync doesn't seem to be working in v2.6.7

I upgraded to v2.6.7 and ws.Trading.SubscribeToOrderUpdatesAsync() seems to have stopped working.  It connects and says that it has a StreamId, but when orders are updated, nothing comes through.

Checking...

I've fixed this issue and will release tonight

Thank You,

New version has been released and issue fixed. Thanks for feedback. Regards.

source: gharchive/issue

authors: burakoner javedwahid

license: MIT

license_type: permissive

license_source: github-api


text:
JEP 18

Are there any plans to support JEP 18?

No, sorry. This library is not very actively developed and that looks like a significant amount of work. If someone contributed it I would not be against merging (but I think there may be one or two other things that need to be added to get up to date with where JMESPath is these days first).

authors: iconara spoerri

repo: burtcorp/jmespath-java

license_source: bigquery


text:
Interface methods return itself or another interface

How to deal with the case below?
// Bad.
type Doer interface { Do() Doer }
type IDoer struct{}
func New() Doer { return new(IDoer)}
func (d *IDoer) Do() Doer {/*...*/ return d }

// Good.
type Doer interface { Do() Doer }
type IDoer struct{}
func New() *IDoer { return new(IDoer)}
func (d *IDoer) Do() *IDoer {/*...*/ return d}

// Very Good (Verify Interface Compliance in compile time)
var _ Doer = (*IDoer)(nil)

The above won't compile because of the error:
cannot use (*IDoer)(nil) (value of type *IDoer) as Doer value in variable declaration: *IDoer does not implement Doer (wrong type for method Do)
		have Do() *IDoer
		want Do() Doer

This use case is quite common designing libraries. As an example, standard slog package has this interface, that's Handler methods return the Handler interface.
type Handler interface {
	Enabled(context.Context, Level) bool
	WithAttrs(attrs []Attr) Handler
	WithGroup(name string) Handler
}

closed as duplicate of https://github.com/butuzov/ireturn/issues/21

authors: butuzov drumsta

repo: butuzov/ireturn


text:
Add max-width checks for Grid

Reference: http://stackoverflow.com/questions/16637530/whats-the-maximum-pixel-value-of-css-width-and-height-properties

Browser
Max-width

Firefox
33554400px

Chrome
33554428px

Opera
33554428px

IE 9
21474836.47px

Add a check for sizes approaching this and print a warning.

Since this is browser-specific and may potentially change in the future, I'm going to close this and leave it up to client-users to decide how best to handle this edge-case.

repo: bvaughn/react-virtualized


text:
🛑 PSR Aster 1 is down

In 4a9e90b, PSR Aster 1 (https://cloud.tymly.in/status/1059) was down:

HTTP code: 521
Response time: 20239 ms

Resolved: PSR Aster 1 is back up in 44494ae.

repo: bvenkysubbu/tymlymonitor


text:
🛑 Trifecta Esplanade Multipurpose Hall is down

In 4599a8d, Trifecta Esplanade Multipurpose Hall (https://cloud.tymly.in/status/1169) was down:

HTTP code: 521
Response time: 20240 ms

Resolved: Trifecta Esplanade Multipurpose Hall is back up in 4237c63.


text:
🛑 Sterling Ascentia Tower 5 is down

In 36f891a, Sterling Ascentia Tower 5 (https://cloud.tymly.in/status/1143) was down:

HTTP code: 521
Response time: 227 ms

Resolved: Sterling Ascentia Tower 5 is back up in bdd8c26.


text:
🛑 Adithya Pristine KMC is down

In 479f06c, Adithya Pristine KMC (https://cloud.tymly.in/status/1028) was down:

HTTP code: 521
Response time: 20249 ms

Resolved: Adithya Pristine KMC is back up in 4f5064d.


text:
🛑 Trifecta Esplanade E Block is down

In c4dd551, Trifecta Esplanade E Block (https://cloud.tymly.in/status/1157) was down:

HTTP code: 521
Response time: 232 ms

Resolved: Trifecta Esplanade E Block is back up in 862b37d.


text:
🛑 SMR Vinay Cascade A Block is down

In 9c222a2, SMR Vinay Cascade A Block (https://cloud.tymly.in/status/1094) was down:

HTTP code: 521
Response time: 228 ms

Resolved: SMR Vinay Cascade A Block is back up in 7160033.


text:
🛑 SMR Vinay Cascade B Block is down

In 08f8169, SMR Vinay Cascade B Block (https://cloud.tymly.in/status/1093) was down:

HTTP code: 521
Response time: 231 ms

Resolved: SMR Vinay Cascade B Block is back up in 29eb003.


text:
🛑 Mahaveer Varna A1 is down

In 22e1040, Mahaveer Varna A1 (https://cloud.tymly.in/status/1083) was down:

HTTP code: 521
Response time: 20269 ms

Resolved: Mahaveer Varna A1 is back up in 9e55abd.


text:
🛑 SMR Vinay Cascade B Block is down

In 09ca8a1, SMR Vinay Cascade B Block (https://cloud.tymly.in/status/1093) was down:

HTTP code: 521
Response time: 20227 ms

Resolved: SMR Vinay Cascade B Block is back up in f547076.


text:
🛑 SMD Altezz Block B is down

In 29492d4, SMD Altezz Block B (https://cloud.tymly.in/status/1176) was down:

HTTP code: 521
Response time: 20220 ms

Resolved: SMD Altezz Block B is back up in 2dfd2db.


text:
🛑 Trifecta Esplanade Security is down

In b28e8af, Trifecta Esplanade Security (https://cloud.tymly.in/status/1168) was down:

HTTP code: 521
Response time: 266 ms

Resolved: Trifecta Esplanade Security is back up in b1a2351.


text:
🛑 Mahaveer Varna A4 is down

In 8e769be, Mahaveer Varna A4 (https://cloud.tymly.in/status/1084) was down:

HTTP code: 521
Response time: 20234 ms

Resolved: Mahaveer Varna A4 is back up in 5f81a93.


text:
🛑 SMR Vinay Cascade B Block is down

In c0297e9, SMR Vinay Cascade B Block (https://cloud.tymly.in/status/1093) was down:

HTTP code: 521
Response time: 20231 ms

Resolved: SMR Vinay Cascade B Block is back up in 903e24a.


text:
🛑 SBB Touchstone B Block is down

In 29177c4, SBB Touchstone B Block (https://cloud.tymly.in/status/1018) was down:

HTTP code: 521
Response time: 20220 ms

Resolved: SBB Touchstone B Block is back up in 7cd648e.


text:
🛑 Sowparnika Swastika 2 is down

In d08e496, Sowparnika Swastika 2 (https://cloud.tymly.in/status/1099) was down:

HTTP code: 521
Response time: 20226 ms

Resolved: Sowparnika Swastika 2 is back up in ddb189b.


text:
🛑 Trifecta Esplanade D Block is down

In 2d67765, Trifecta Esplanade D Block (https://cloud.tymly.in/status/1156) was down:

HTTP code: 521
Response time: 20249 ms

Resolved: Trifecta Esplanade D Block is back up in 20baeb9.


text:
🛑 Wilson Vintage 2 is down

In c6de8a2, Wilson Vintage 2 (https://cloud.tymly.in/status/1038) was down:

HTTP code: 521
Response time: 20239 ms

Resolved: Wilson Vintage 2 is back up in 392b3ed.


text:
🛑 Wilson Vintage 1 is down

In 5021399, Wilson Vintage 1 (https://cloud.tymly.in/status/1037) was down:

HTTP code: 521
Response time: 21006 ms

Resolved: Wilson Vintage 1 is back up in c32a974.


text:
disable bird service??

I've never nor do I ever plan on using iCloud or anything icloud related. In High Sierra if you disable com.apple.bird completely, by unloading and disabling it, High Sierra now gives some error message about how icloud drive doesn't work properly. No shit Sherf*ck. I don't want it to work properly. Sierra never gave this message. Any solutions? Thanks.

This doesn't really relate to this repo.
But to answer your question, you can backup and then delete the file,
/System/Library/LaunchAgents/com.apple.bird.plist

or look into launchctl

repo: bwesterb/blame-bird

license: mit


text:
AWS Connection Error

What issue do you have? Please be as thorough and explicit as possible.
Getting a not connected to AWS Error while using the credential auth method. I went to bed with the plugin working fine, and this morning I noticed no lights were working
Details of your setup.

Do you use (1) Homebridge UI-X (2) Homebridge CLI or (3) HOOBS?
Homebridge UI-X on a raspberry pi. All packages are updated as well as node.js

Which version of Homebridge/HOOBS do you have?

V1.6.0

Which platform do you run Homebridge/HOOBS on (e.g. Raspberry Pi/Windows/HOOBS Box)? Please also mention your version of Node.js/NPM if known.

Raspberry Pi

Which version of this plugin (homebridge-govee) do you have? Has the issue started since upgrading from a previous version?

npm 9.1.2

Which Govee devices do you have that are causing issues? Please include product models if applicable.

All devices, I have a set of twinkly brand christmas lights that are working fine on my homebridge setup.
Please paste any relevant logs below.

Log Errors ( They arent showing in the above post )
[29/11/2022, 14:44:34] [Govee] [Living Room Couch] not using AWS connection as not connected to AWS.
[29/11/2022, 14:44:34] [Govee] [Living Room Couch] could not be updated as no connection method available at file:///usr/local/lib/node_modules/homebridge-govee/lib/platform.js:1803:13.
[29/11/2022, 14:44:34] [Govee] [Living Room Couch] not using AWS connection as not connected to AWS.
[29/11/2022, 14:44:39] [Govee] [Living Room Couch] could not be updated as no connection method available at file:///usr/local/lib/node_modules/homebridge-govee/lib/platform.js:1803:13.

disregard, I see an issue opened already regarding this. Will monitor that ticket.

Closing, please see https://github.com/bwp91/homebridge-govee/issues/367


text:
Plug In has started Reporting a "not connected to AWS error"

What issue do you have? Please be as thorough and explicit as possible.
Plug In has worked fine for over a year with 5 Govee light strip devices.  No change to the devices or Homebridge configuration.  Really appreciate any guidance you can provide.
Details of your setup.

Do you use (1) Homebridge UI-X (2) Homebridge CLI or (3) HOOBS?

I had a HOOBS which is re-imaged to standard HomeBridge

Which version of Homebridge/HOOBS do you have?

currently at 1.6.1

Which platform do you run Homebridge/HOOBS on (e.g. Raspberry Pi/Windows/HOOBS Box)? Please also mention your version of Node.js/NPM if known.

Node.JS is 18.68.0, on a Raspberry PI

Which version of this plugin (homebridge-govee) do you have? Has the issue started since upgrading from a previous version?

currently on 9.1, but have back ported as part as 9.0 and the problem has not resolved itself.

Which Govee devices do you have that are causing issues? Please include product models if applicable.

5 Devices, all H6141
Please paste any relevant logs below.
[05/07/2023, 19:43:25] [Govee] [Right Front] could not find device [MAC ADDRESS].
[05/07/2023, 19:43:25] [Govee] [Right Front] could not be updated as no connection method available at file:///var/lib/homebridge/node_modules/homebridge-govee/lib/platform.js:1748:13.
[05/07/2023, 19:43:32] [Govee] [Right Front Wide] could not find device [MAC ADDRESS].
[05/07/2023, 19:43:32] [Govee] [Right Front Wide] could not be updated as no connection method available at file:///var/lib/homebridge/node_modules/homebridge-govee/lib/platform.js:1748:13.
[05/07/2023, 19:43:39] [Govee] [Back Wall] could not find device [MAC ADDRESS].
[05/07/2023, 19:43:39] [Govee] [Back Wall] could not be updated as no connection method available at file:///var/lib/homebridge/node_modules/homebridge-govee/lib/platform.js:1748:13.
[05/07/2023, 19:43:46] [Govee] [Right Rear] could not find device [MAC ADDRESS].
[05/07/2023, 19:43:46] [Govee] [Right Rear] could not be updated as no connection method available at file:///var/lib/homebridge/node_modules/homebridge-govee/lib/platform.js:1748:13.
[05/07/2023, 19:43:46] [Govee] [Left Front] could not connect as Error: Peripheral already connected.
[05/07/2023, 19:43:53] [Govee] [Left Front] could not find device [MAC ADDRESS].
[05/07/2023, 19:43:53] [Govee] [Left Front] could not be updated as no connection method available at file:///var/lib/homebridge/node_modules/homebridge-govee/lib/platform.js:1748:13.
[05/07/2023, 19:44:34] [Govee] [Right Front Wide] could not be updated as Promise timed out after 10000 milliseconds at Timeout._onTimeout (file:///var/lib/homebridge/node_modules/homebridge-govee/node_modules/p-timeout/index.js:79:64).
[05/07/2023, 19:44:34] [Govee] [Right Front Wide] could not find device [MAC ADDRESS].

Please can you show the logs from the plugin initialising after a restart of homebridge or any plugin bridge?
there is probably a reason why the aws is not working

Hi, thanks for your response.  Please see below everything I get from a home bridge restart.
[16/07/2023, 16:11:14] [Govee] [LAN] client enabled and found 0 device(s).
[16/07/2023, 16:11:17] [Govee] [BLE] client enabled.
[16/07/2023, 16:11:17] [Govee] [Back Wall] initialising with options {"adaptiveLightingShift":0,"aws":"enabled","ble":"enabled","brightnessStep":1,"colourSafeMode":false,"lan":"unsupported"}.
[16/07/2023, 16:11:17] [Govee] [Back Wall] initialised with id [MAC ADDRESS] [H6141].
[16/07/2023, 16:11:17] [Govee] [Right Rear] initialising with options {"adaptiveLightingShift":0,"aws":"enabled","ble":"enabled","brightnessStep":1,"colourSafeMode":false,"lan":"unsupported"}.
[16/07/2023, 16:11:17] [Govee] [Right Rear] initialised with id [MAC ADDRESS] [H6141].
[16/07/2023, 16:11:17] [Govee] [Left Front] initialising with options {"adaptiveLightingShift":0,"aws":"enabled","ble":"enabled","brightnessStep":1,"colourSafeMode":false,"lan":"unsupported"}.
[16/07/2023, 16:11:17] [Govee] [Left Front] initialised with id [MAC ADDRESS] [H6141].
[16/07/2023, 16:11:17] [Govee] [Right Front] initialising with options {"adaptiveLightingShift":0,"aws":"enabled","ble":"enabled","brightnessStep":1,"colourSafeMode":false,"lan":"unsupported"}.
[16/07/2023, 16:11:17] [Govee] [Right Front] initialised with id [MAC ADDRESS] [H6141].
[16/07/2023, 16:11:17] [Govee] [Right Front Wide] initialising with options {"adaptiveLightingShift":0,"aws":"enabled","ble":"enabled","brightnessStep":1,"colourSafeMode":false,"lan":"unsupported"}.
[16/07/2023, 16:11:17] [Govee] [Right Front Wide] initialised with id [MAC ADDRESS] [H6141].
[16/07/2023, 16:11:59] [Govee] [Right Front] not using AWS connection as not connected to AWS.
[16/07/2023, 16:12:06] [Govee] [Right Front] could not find device [MAC ADDRESS].
[16/07/2023, 16:12:06] [Govee] [Right Front] could not be updated as no connection method available at file:///var/lib/homebridge/node_modules/homebridge-govee/lib/platform.js:1748:13.

latest version appears to have solved the problem, thank you!


text:
Fix producer executor

backendActivityService gotta invoke failure of producer in case of any runnable failure.

Done

authors: alexander-branevskiy bwsw

repo: bwsw/t-streams


text:
Mailgun Tag

Can you tag the new maligun release so I can remove my old library and start using this?

Would love to, but I have had issues cloning from GitHub all day - when I get home, I will pull, test, then tag and release and announce on Slack. Sorry I couldn't get it done right away.

Oh no worries! Sounds good! 👍

authors: anthonycastelli bygri

repo: bygri/vapor-mail


text:
Nice features from other UTFs for Igor Pro

[ ] Random Seed was reset to a value of (1 / 32060) before each test function was called.
[x] Randomize test order in a test suite
[ ] Nice GUI (can readback JUNIT XML output e.g., or we create JSON output, see #191)
[x] Pass string into test assertion. This string is then outputted on a failed assertion.

https://github.com/byte-physics/igor-unit-testing-framework/issues/11

Pass string into test assertion. This string is then outputted on a failed assertion.

Isn't this done with the INFO() statement?

Pass string into test assertion. This string is then outputted on a failed assertion.

Isn't this done with the INFO() statement?

Yes!

Random Seed was reset to a value of (1 / 32060) before each test function was called.

Do we need this? The user can do this in the test begin hooks for each test case...

repo: byte-physics/igortest


text:
Stop generating the bindings file for projects without wit files and dependencies

Such as the case described in #314.
cc @calvinrp
close #314

Do you recommend a good way to test locally?

Sure, a common scenario is using wasi-rs directly to build wasm programs. In this case, we directly reference the bindings generated by wasi-rs and do not have our wit files. In this scenario, an "empty" bindings file should not be generated.
Another scenario is directly using a wasm http client library such as waki. We don't have our own wit files, but an "empty" bindings file is generated.
You can directly use the code of the above two examples to test it locally.

source: gharchive/pull-request

repo: bytecodealliance/cargo-component


text:
Unexpected execution in fast interpreter mode

Subject of the issue
The WAMR on faster interpreter mode has a wrong execution result on the test case.
Test case
tt2.zip
(module
  (type (;0;) (func))
  (type (;1;) (func (result i32)))
  (type (;2;) (func (param f32) (result f32)))
  (func (;0;)  (result i64)
    i32.const -1518330408
    i64.const 1022
    i64.const 904
    i64.add
    global.get 0
    i64.add
    global.set 0
    f32.const 0x1.01499cp+1 (;=2.01006;)
    call 1
    i32.const 0
    if (param f32) (result f32)  ;; label = @1
    end
    i64.trunc_f32_u
    return
    )
  (func (;1;) (type 2) (param f32) (result f32)
    f32.const inf (;=inf;))
  (global (;0;) (mut i64) (i64.const 858))
  (global (;1;) (mut f64) (f64.const 0x1.0370499c98398p+3 (;=8.10746;)))
  (export "_start" (func 0))
  (export "to_test" (func 0)))

Your environment

Host OS: Ubuntu 20.04
Commit Id: 835188cc53373159165423debc48242ad15548d6

Steps to reproduce

build WAMR in fast interpreter mode
execute the command

iwasm --heap-size=0 -f "to_test" <test_case>

Expected behavior
An exception indicating integer overflow (On the instruction i64.trunc_f32_u)
Actual behavior
0

@erxiaozhou thanks for reporting the issue, it is similar to #3386 when handling the if block in loader:
    if (param f32) (result f32)  ;; label = @1
    end

Please try #3404.

Close the issue since it was fixed.

authors: erxiaozhou wenyongh

repo: bytecodealliance/wasm-micro-runtime


text:
Fixing Minor Code Quality Issues

Cleaned up some minor issues which were triggering warnings for me:

Redundant nullability
Redundant unsafe contexts
Redundant ToString calls

Some other cleanup opportunities I did not include in this PR:
public static unsafe extern IntPtr wasmtime_caller_context(IntPtr caller);
This method (and many others like it) does not need unsafe. Should I remove all of them? I've avoided touching anything marked extern so far.
checked((int)name->size) (size is nuint)
There are many checked conversions from nuint to int. R# warns: Checked context is redundant: no operators or conversions with overflow checks. I'm pretty sure this is an incorrect warning (e.g. see this test here), but I just wanted to double check that before reporting it to Jetbrains.

Hi,

checked((int)name->size) (size is nuint)
There are many checked conversions from nuint to int. R# warns: Checked context is redundant: no operators or conversions with overflow checks. I'm pretty sure this is an incorrect warning (e.g. see this test here), but I just wanted to double check that before reporting it to Jetbrains.

I agree this seems to be an incorrect warning, because for nint and nuint (that are stored as IntPtr and UIntPtr), the checked context is respected by the C# compiler when emitting the conversion in the same way as for other integer types (that don't have user-defined cast operators); without the checked(...) context, no OverflowException would be thrown when the nuint value doesn't fit into an int value.
This is in contrast to UIntPtr and IntPtr, where the user-defined cast operators on these types always threw an OverflowException in such a case before .NET 7. Starting with .NET 7, user-defined operators can be defined as checked and as unchecked version, which is also done by UIntPtr and IntPtr. For example (on 64-bit):
IntPtr x = unchecked((nint)uint.MaxValue);
Console.WriteLine(x);

int y = unchecked((int)x);
Console.WriteLine(y);

int z = checked((int)x);
Console.WriteLine(z);

Output with .NET 6:
4294967295
Unhandled exception. System.OverflowException: Arithmetic operation resulted in an overflow.
   at System.IntPtr.op_Explicit(IntPtr value)
   at Program.Main()

Output with .NET 7 (notice the -1 from the unchecked((int)x) expression):
4294967295
-1
Unhandled exception. System.OverflowException: Arithmetic operation resulted in an overflow.
   at Program.Main()

However, when changing the type of x from IntPtr to nint, the output from .NET 6 will be the same as for .NET 7, because then it no longer uses the user-defined explicit operator int(IntPtr value).
Note, that e.g. UIntPtr only defines a cast to uint but not int, so when casting the UIntPtr to int, it seems to first invoke the user-defined explicit operator uint(UIntPtr value), and then does the conversion to int, so e.g. the following code doesn't throw an OverflowException in the cast fory even on .NET 6, because the UIntPtr can be converted to uint without losing information, and then the conversion to int is done with respecting the unchecked context:
UIntPtr x = (nuint)uint.MaxValue;
Console.WriteLine(x);

int y = unchecked((int)x);
Console.WriteLine(y);

int z = checked((int)x);
Console.WriteLine(z);

Output with .NET 6:
4294967295
-1
Unhandled exception. System.OverflowException: Arithmetic operation resulted in an overflow.
   at Program.Main()

public static unsafe extern IntPtr wasmtime_caller_context(IntPtr caller);
This method (and many others like it) does not need unsafe. Should I remove all of them? I've avoided touching anything marked extern so far.

👍 I agree the unsafe can be removed here because it uses IntPtr that doesn't need it.

authors: kpreisser martindevans

repo: bytecodealliance/wasmtime-dotnet


text:
failed to find a pre-opened file descriptor from WASM WASI module with standalone wastime

Test Case
smartcore_wasi_lib.wasm - https://easyupload.io/7l8u6z
test1.txt
Steps to Reproduce
Just run the wasm file in the same folder as test1.txt.
wasmtime run --dir=. smartcore_wasi_lib.wasm --invoke load_model test1.txt test2.txt
Expected Results
A new file inside ./ with the name test2.txt and the same contents as test1.txt.
Actual Results
$ wasmtime run --dir=. smartcore_wasi_lib.wasm --invoke load_model test1.txt test2.txt
error opening input test1.txt: failed to find a pre-opened file descriptor through which "test1.txt" could be opened

Versions and Environment
Wasmtime version or commit: 0.26.0
Operating system: Ubuntu 20.04
Architecture: x86_64
Extra Info
This is the example for WASI from https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-tutorial.md
Here's the code:
use std::fs;
use std::io::{Read, Write};
use std::env;

fn process(input_fname: &str, output_fname: &str) -> Result<(), String> {
    let mut input_file = fs::File::open(input_fname)
        .map_err(|err| format!("error opening input {}: {}", input_fname, err))?;
    let mut contents = Vec::new();
    input_file
        .read_to_end(&mut contents)
        .map_err(|err| format!("read error: {}", err))?;

    let mut output_file = fs::File::create(output_fname)
        .map_err(|err| format!("error opening output {}: {}", output_fname, err))?;
    output_file
        .write_all(&contents)
        .map_err(|err| format!("write error: {}", err))
}

#[no_mangle]
pub fn load_model() -> () {
    let args: Vec<String> = env::args().collect();
    let program = args[0].clone();

    if args.len() < 3 {
        eprintln!("usage: {} <input_file> <output_file>", program);
        return;
    }

    if let Err(err) = process(&args[1], &args[2]) {
        eprintln!("{}", err)
    }
}

And compiled via cargo build --target=wasm32-wasi --release

Does it work if you specify ./test1.txt and ./test2.txt?

Unfortunately not.. Same error:
$ wasmtime run --dir=. smartcore_wasi_lib.wasm --invoke load_model ./test1.txt ./test2.txt
error opening input ./test1.txt: failed to find a pre-opened file descriptor through which "./test1.txt" could be opened

Oh, I think I now what is going on. By using load_model as entry point, you are skipping wasi-libc's entry point which initializes libpreopen. As it isn't initialized, libpreopen doesn't know how to open files.

Hmm, this project was meant for another use-case, where it is used as a lib. I was hoping to quickly test it with wasmtime. Is this on purpose that invoked functions skip other necessary entry points?

Wasi has two execution models:

command: This is like an executable. There is a single entry point and after the entry point returns you must discard the whole instance. This entry point is the _start function declared in wasi-libc which in turn calls the user main.
reactor: This is like a library. There is first a call to _initialize declared in wasi-libc. After that it is possible to call any user defined function.

To compile a reactor with rustc you need to use the unstable -Z wasi-exec-model=reactor flag. I am not sure if wasmtime cli supports reactors, but the api does, though it may be necessary to manually call _initialize. (not sure if wasmtime already automatically does this for your)
https://github.com/WebAssembly/WASI/issues/13
https://github.com/rust-lang/rust/pull/79997

Thanks for your valuable input! That was new to me and actually solved the problem!
Compiling the project with cargo rustc --release --target wasm32-wasi -- -Z wasi-exec-model=reactor did the trick. Now wasmtime run --dir=. smartcore_wasi_lib.wasm --invoke load_model test1.txt test2.txt results in test2.txt.

I'm also getting a very similar error. I'm building a very simple Rust WASI binary not in reactor mode, that tries to opens a file.
I start it in command mode via Node - see code below.
I get the same failed to find a pre-opened file descriptor error, but I don't want to switch to "reactor" (why didn't they call this "library"?) mode. I don't understand why this still happens though because surely I am using the _start entry point which should initialise this libpreload library?
(Sorry to slightly hijack this issue, but there's not much on the internet about this.)
import { WASI } from "node:wasi";
import { readFile } from "node:fs/promises";
import { join } from "node:path";

async function main() {
	const wasm = await WebAssembly.compile(
		await readFile(join(__dirname, "server.wasm")),
	);
	const wasi = new WASI({
		env: {
			RUST_BACKTRACE: "1",
		},
		// This option is mandatory.
		version: "preview1",
	});
	const instance = await WebAssembly.instantiate(wasm, <WebAssembly.Imports>wasi.getImportObject());

	wasi.start(instance);
}

main();

Oh wait... you just need to do this:
	const wasi = new WASI({
		env: {
			RUST_BACKTRACE: "1",
		},
		// This option is mandatory.
		version: "preview1",
		preopens: {
			"/": "/",
		},
	});

Sorry for the noise!

For Windows you need this nonsense:
			"/": "/",
			"a:/": "a:/",
			"b:/": "b:/",
			"c:/": "c:/",
			"d:/": "d:/",
...

(Or I guess narrow it down to a specific directory if your application allows that.)

authors: Timmmm bjorn3 proohit

repo: bytecodealliance/wasmtime


text:
Numerous assert_malformed failures in test suite output in CI

Repro steps

cargo test --all --exclude lightbeam --exclude wasmtime-wasi-c --exclude wasmtime-py -- --nocapture

Expected results
The Wasm test suite tests should all pass.
Actual results
The Wasm test suites do pass, but most of the tests that check for malformed modules print error messages resulting from mismatched error strings (but otherwise pass).
In addition to looking like errors are being ignored by a non-failing assertion, the verbosity of these messages makes it hard to see which test suite tests ran in CI build logs.

FWIW the tests are actually passing here, but tests are run with --nocapture (I'm not entirely sure why myself) and neither assert_invalid nor assert_malformed will assert on their contents, they just print informational warnings. I think this is due to the fact that wasmtime's error messages are different than that of the spec test suite, and aligning them probably isn't exactly worth a lot of effort.
I'd be personally in favor of just removing --nocapture or removing the debugging print altogether.

--nocapture is useful for test-programs tests as when they fail due to a panic it'll go to the output and then a more generic "test program returned non-zero" failure will fail the generated test.
I agree that we could probably get rid of the debug print from the assert_* commands and just leave them as no-ops until such time as we can properly assert on matching error messages.

If a test fails though it should always print its own stdout/stderr in an isolated area dedicated to just that one test (Rust's test harness captures stdout/stderr by default), but if a test segfaults then --nocapture is the only way to see the output. In that sense I think we could probably still get by removing --nocapture?

Perhaps I'm not recalling correctly then, as I seem to remember having to use --nocapture to figure out what a test-program was really failing with 🤷♂ .
If that's the case then I'm totally 👍 on removing --nocapture.

FYI, my memory was indeed faulty and you're correct.  We don't need it for test programs.

Ok so I've got all the assert_invalid tests passing in wasmparser, so we can handle these in wasmtime with an update to our wasmparser dep and a little changes to our test generation in build.rs. (https://github.com/bytecodealliance/wasmparser/pull/186)
I've been poking at assert_malformed and this is a bit hairier. Basically, if a parser doesn't look exactly like the spec interpreter's parser, then getting all of these the same is going to be very difficult. There are lots of examples of things like hitting an EOF when parsing a value type and do you report that you have an invalid value type or that you hit an EOF? The spec chooses one or the other when neither is more correct (and sometimes it switches between them in seemingly arbitrary ways, that only make sense when you read its code!) and matching its behavior can be hard based on how the parser is structured and what kinds of helper functions you have. Also there are a bunch of things that I think are probably "bugs" in the spec interpreter's parser's error messages, where they report one thing but probably should report another.
Long story short, I don't think it is worth trying to match assert_malformed error messages. Instead, we should stop feeling guilty about not matching them, remove TODO comments in our build.rs, and stop printing these warnings in our tests. I'll start taking this course of action.

@fitzgen I would agree that wasmtime here should skip the assert_malformed test error messages. That's technically covered by the wat crate anyway since it's only testing *.wat parse errors, and afaik it has nothing to do with the binary format.
The wat crate already validates all of its error messages against the test suite's assert_malformed messages as well. It has a custom function to "adapt" from the expected error message to the actual error message. It's a pretty ugly function though and would be a bummer to duplicate here. (and probably not worth it)

This course of action sounds reasonable to me 👍.

That's technically covered by the wat crate anyway since it's only testing *.wat parse errors, and afaik it has nothing to do with the binary format.

Not quite right -- it constructs a bunch of wasm binaries that have various syntax errors (as opposed to validation errors, which assert_invalid covers) and then checks that parsing these binaries produces the expected error message. For example, it produces binaries that have LEB128s that don't satisfy the max length is ceil(N / 7) property, etc.
I don't think this is something that wat can cover, so I'm a little confused at what it does here.

Oh right sorry, I should read the code more closely. The wat crate tests all "quote" modules, but not those that are likely module binary "..." which would do things like leb128 encodings and such.
It may be the case though that skipping module quote tests (and leaving those to wat) may mean that the set of error messages we'd need to tweak and/or align would be manageable enough?
In any case starting out with assert_invalid sounds good, and we can tackle assert_malformed later.

and we can tackle assert_malformed later.

I don't think it is worth tackling these later though. After poking at this for a bit, I don't think we will get anything of value out of it, and it would just be busy work.

Oh right, sorry, I'm fine deferring to your judgment on that!

I don't think it is worth tackling these later though. After poking at this for a bit, I don't think we will get anything of value out of it, and it would just be busy work.

I mostly agree in that I think your argument for not fixing things on our end is compelling. At the same time, I'm a bit concerned about the risk of accidentally papering over real bugs here.
Would an alternative be to change the tests? Having spec tests that can't reasonably be tested against different implementations doesn't seem great. I remember similar issues with tc39's test262 suite, and IIRC the upstream tests were changed to have less implementation-specific behavior. (The difference is, of course, that tc39 doesn't maintain a spec interpreter. Given that the Wasm WG's spec interpreter is non-normative, that doesn't seem to change the picture.)

To be clear, we are testing (here and in wasmparser) that we never successfully parse a malformed module, we just aren't testing that the error messages are the same.
FWIW, I got through maybe a fifth of the test suite's assert_malformed, and did not discover any bugs.

To be clear, we are testing (here and in wasmparser) that we never successfully parse a malformed module, we just aren't testing that the error messages are the same.

Understood! And I know that you'd not be in any way cavalier about us passing tests we really should be failing :) I'm slightly concerned about whether there's a risk of us really getting things wrong and that not being caught, but I admit that the circumstances under which that could happen are quite unlikely: AFAICT it'd require that all tests that'd cover a certain type of malformed content to also fail because of another type of malformed content. This is very different from typical JS tests, where you often have a TypeError and a description, and the TypeError really could be about basically anything :)

FWIW, I got through maybe a fifth of the test suite's assert_malformed, and did not discover any bugs.

That, together with the above-described unlikeliness of anything concerning being papered over convinces me that there's nothing to do here once you've landed the patch to ignore the error messages. Thank you for the thorough explanation!

authors: alexcrichton fitzgen peterhuene tschneidereit


text:
Turbulent Round Jet

Hello author,
I couldn't find the runtime code for Turbulent Round Jet in the FLOWVPM case. It only contains its functions and simulation. Could you please provide me with its runtime code.

Duplicated


text:
🛑 Wodemo的一楼 is down

In 1263fb3, Wodemo的一楼 (https://bywhite.wodemo.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Wodemo的一楼 is back up in 55dd279.


text:
This PR adds PhysX examples that are equivalent to all existing examples in aframe-physics system

Most of these examples could be implemented without core code changes.
There are just a couple of bug fixes

rework of perf optimization, which turned out to have broken constraints
fix a typo siffness-> stiffness, though even with this fix, springs still don't work :-(

Most examples work fine.  The only exceptions are:

we have issues with scale.   Exhibited both in the sandbox example, and in the fact that I had to remove all scaling from the constraints example.
springs example doesn't work.  Soft linear constraints just don't seem to work correctly, and I don'y yet know why.

Those two problems might not be fast to solve, so I propose merging this PR as is, and raising separate issues to track those problems.

While this PR is under review, I've publsihed the source branch at GitHub Pages here:
https://diarmidmackenzie.github.io/physx/examples/
But note that links don't work - you'll need these instead:
https://diarmidmackenzie.github.io/physx/examples/basic/index.html
https://diarmidmackenzie.github.io/physx/examples/sandbox/index.html
https://diarmidmackenzie.github.io/physx/examples/compound/index.html
https://diarmidmackenzie.github.io/physx/examples/constraints/index.html
https://diarmidmackenzie.github.io/physx/examples/materials/index.html
https://diarmidmackenzie.github.io/physx/examples/spring/index.html
https://diarmidmackenzie.github.io/physx/examples/stress/index.html
https://diarmidmackenzie.github.io/physx/examples/ttl/index.html
https://diarmidmackenzie.github.io/physx/examples/pinboard/physx.html
https://diarmidmackenzie.github.io/physx/examples/pinboard/ammo-vs-physx.html

exciting! fantastic work, will try to look into this soon!

authors: diarmidmackenzie kylebakerio

repo: c-frame/physx


text:
Any version above 1.0.1 causes a crash when opening the Creative gui.

Title. Ping me on Discord when you're online.
https://pastebin.com/XpBMEG6b
Mods in report.
EDIT: This is caused by Already Decorating Fix.

EDIT: This is caused by Already Decorating Fix. See TCL's server, and ping him about this.
This is an erroneous notion. I have tried to explain it to you, but I feel the need to repeat myself here.
Already Decorating Fix has nothing to do with this crash - it consists of about 50 lines of code, and none of it touch anything to do with inventories.
From what I see, this crash is likely caused by the lack of a '!= null' check in the right place, but I'll leave this to Louis to figure out.

Fixed! It was a problem with an access transformer.


text:
🛑 cms2.alejtech.eu is down

In d0c4d9a, cms2.alejtech.eu (http://cms2.alejtech.eu/UserSystem/login/login.alej) was down:

HTTP code: 403
Response time: 304 ms

Resolved: cms2.alejtech.eu is back up in b1785d3.


text:
🛑 www.ozpsav.sk is down

In 5c2b5df, www.ozpsav.sk (https://www.ozpsav.sk/sk/Odborovy-zvaz.alej) was down:

HTTP code: 403
Response time: 1266 ms

Resolved: www.ozpsav.sk is back up in 5101186.


text:
🛑 www.hollen.sk is down

In 52ecb2d, www.hollen.sk (http://www.hollen.sk/sk/Home.html) was down:

HTTP code: 403
Response time: 307 ms

Resolved: www.hollen.sk is back up in bd58785.


text:
🛑 www.soi.sk is down

In 4dc877d, www.soi.sk (https://www.soi.sk/sk/Novinky-SOI.soi) was down:

HTTP code: 403
Response time: 606 ms

Resolved: www.soi.sk is back up in 931582d.


text:
🛑 www.ozpsav.sk is down

In 1995243, www.ozpsav.sk (https://www.ozpsav.sk/sk/Odborovy-zvaz.alej) was down:

HTTP code: 403
Response time: 2006 ms

Resolved: www.ozpsav.sk is back up in 348c815.


text:
🛑 www.soi.sk is down

In 96fb79e, www.soi.sk (https://www.soi.sk/sk/Novinky-SOI.soi) was down:

HTTP code: 403
Response time: 520 ms

Resolved: www.soi.sk is back up in 93d202c.


text:
🛑 www.garancnyfond.sk is down

In 5e9b86a, www.garancnyfond.sk (https://www.garancnyfond.sk) was down:

HTTP code: 0
Response time: 0 ms

Resolved: www.garancnyfond.sk is back up in bf21b03 after 14 minutes.


text:
Replace all expect(true).toBeTruthy() blocks with beforeEach blocks

See https://github.com/c3js/c3/issues/1843#issuecomment-304484663.

I've done this now but beforeEach seems to break things, there's some weird scoping considerations throughout all the unit tests.

Maybe we should use beforeAll instead of beforeEach in most places because each test cases are depenedent of the cases before it (This is not a good way to write tests IMO.). We need to keep the state of charts between test cases and setting data in beforeEach wipes the data in each case and breaks the tests (probably).


text:
🛑 CBTB Coffee House Shop is down

In 601b46b, CBTB Coffee House Shop (https://shop.cbtb.coffee/) was down:

HTTP code: 403
Response time: 1136 ms

Resolved: CBTB Coffee House Shop is back up in da66bb0.

repo: cachetech/service-status


text:
🛑 CBTB Coffee House Shop is down

In c12fad3, CBTB Coffee House Shop (https://shop.cbtb.coffee/) was down:

HTTP code: 403
Response time: 1071 ms

Resolved: CBTB Coffee House Shop is back up in 374dcf1 after 31 minutes.


text:
Rename a module.

How could I rename an existing module? Is it now possible in the latest version?

Update the namespace and manifest information, and then run module:optimize - should be good to go~

repo: caffeinated/modules


text:
Refactor the "is_streaming..." logic to be RPC centric

Currently a task class has an is_streaming_output_task method to determine the output-streamingess of a task. But tasks will now define unary + streaming flavors of their inputs and outputs, so the "streamingness" is now a property of each RPC that a task supports.
The CaikitRPC class should expose its own streamingness instead.

Should be fixed by https://github.com/caikit/caikit/pull/303

repo: caikit/caikit


text:
Propose RemoteModelInvocation ADR

What this PR does / why we need it:
This PR creates an ADR for remote model invocation. For a full list of reasoning and description of the proposed solution take a look at the ADR; however, the first paragraph of the description is copied here for convenience:

We propose implementing a system for remote model invocation directly in the Caikit core library.
This system will handle discovering and loading models from a remote runtime. These remote modules
will look and function like local modules, except any task or train invocation is forwarded to the
remote. The core components of this system will be a new ModelFinder named RemoteModelFinder and a
new ModelInitializer called RemoteModelInitializer.

Special notes for your reviewer:
This ADR assumes the functionality provided by PR590 and PR594
If applicable:

[ ] this PR contains documentation
[ ] this PR contains unit tests
[ ] this PR has been tested for backwards compatibility

@gabe-l-hart I'm planning to start working on the implementation of this ADR next week. Is this good to go? If so should this PR be merged or wait for implementation?


text:
feat: make loop section more complete

Make the loop section more complete by adding info regarding

Loops and recursion in Cairo
Understand loops used with arrays and avoiding variable moved errors
Good practices when working with loops

Hello, can I work on this?

Sorry, no, this is reserved for advanced Cairo devs

authors: enitrat kenkomu

repo: cairo-book/cairo-book


text:
🛑 XMR USA Servers is down

In 1067038, XMR USA Servers ($XMR_USA) was down:

HTTP code: 0
Response time: 0 ms

Resolved: XMR USA Servers is back up in 6ec2785 after 7 minutes.

repo: cake-tech/upptime-cakewallet


text:
Creating a migration dies in PHP 8 - stricter arguments don't like Util.php's usage of implode()

    public static function mapClassNameToFileName($className)
    {
        $arr = preg_split('/(?=[A-Z])/', $className);
        unset($arr[0]); // remove the first element ('')
        $fileName = static::getCurrentTimestamp() . '_' . strtolower(implode($arr, '_')) . '.php';

        return $fileName;
    }

In previous versions of PHP, you could do $array before $glue, but no longer. The implode() should now have the glue first.

Oops - using an old version of Phinx! Sorry, nvm me.

repo: cakephp/phinx


text:
PDO FETCH_MODE Support

I used this and faker to seed a benchmarking database. I needed to pull from multiple tables and restructure my data. When using fetchAll() there is no way of specifying the PDO FETCH_MODE, so I added a setter and getter to your PdoAdapter class:
    /**
     * @var integer
     */
    protected $fetchMode = \PDO::FETCH_BOTH;

...

    /**
     * Gets the PDO fetch mode
     *
     * @return integer the current PDO fetch mode
     */
    public function getFetchMode()
    {
        return $this->fetchMode;
    }

    /**
     * Sets the PDO fetch mode
     *
     * @param integer PDO mode or (int) representation
     */
    public function setFetchMode($mode)
    {
        $this->fetchMode = $mode;
    }

Now I can use it in my seed command:
$this -> getAdapter() -> setFetchMode(\PDO::FETCH_ASSOC);
Take it or leave it, it was useful for me.

Can you rebase the branch? There seem to be more commits that what you originally intended to send

Codecov Report

:exclamation: No coverage uploaded for pull request base (0.7.x-dev@3fd862b). Click here to learn what that means.
The diff coverage is 70.59%.

@@             Coverage Diff              @@
##             0.7.x-dev    #1103   +/-   ##
============================================
  Coverage             ?   72.13%
============================================
  Files                ?       35
  Lines                ?     5592
  Branches             ?        0
============================================
  Hits                 ?     4034
  Misses               ?     1558
  Partials             ?        0

Impacted Files
Coverage Δ

src/Phinx/Console/Command/Test.php
25% <ø> (ø)

src/Phinx/Db/Adapter/AdapterFactory.php
100% <ø> (ø)

src/Phinx/Console/Command/Breakpoint.php
39.28% <0%> (ø)

src/Phinx/Db/Adapter/SqlServerAdapter.php
0% <0%> (ø)

src/Phinx/Wrapper/TextWrapper.php
0% <0%> (ø)

src/Phinx/Config/Config.php
100% <100%> (ø)

src/Phinx/Console/Command/Init.php
69.23% <100%> (ø)

src/Phinx/Db/Table/Index.php
100% <100%> (ø)

src/Phinx/Console/Command/Create.php
69.38% <100%> (ø)

src/Phinx/Console/PhinxApplication.php
100% <100%> (ø)

... and 24 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 3fd862b...6a6ebc7. Read the comment docs.

I guess this needs to be rebased before it can be looked after again.

@ravage84
why you want to merge into 0.7.x-dev from master
I think this is not true PR

Closing due to inactivity. @crona2011 please put up a new PR towards the correct branch, if you want.


text:
Library for running JAGS over all species in parallel

I am proposing to merge this into main with minimal changes to the model currently in main.
When we eventually settle on the preferred form of the default model, then we can merge that into combined.R with the small changes needed to adapt it to the funtion(params) API.
Reviewers: please try your own test run and say whether it works or give feedback on the API.
When reading the code, I suggest setting the UI to ignore whitespace differences when looking at the diff.

That looks great! I think it might be worth looking into the specific model used, as I believe that the model in this PR is not the "latest and greatest." But changing the model should not be too difficult. Also, certain models use top1 instead of all of the data, so we might want to add the ability to change which csv the model_read_lib.R uses (that would also make it faster because reading top1 is much faster than the entire dataset).

Thanks for looking Mark.
On model selection, the design criterion I adopted here is "separation of concerns." Specifically, (A) define the model, (B) run the model with lots of different parameter settings, collect the results, and parallelize well.
In other words, this was designed to work for any "model," where "model" is just a function taking a params list and returning a jagsResult.
"changing the model shouldn't be too difficult" - yes. Any of the many copies of combined.R have been created could just make the analogous change to the one this has made in combined.R, i.e. wrap the model as a trialFn.
I totally agree with reworking model_read_lib.R to allow a parameter for selecting between top1 / top3 / threshold. I think R has some sort of categorical type, like what's called enum in other languages. (enum ScoreSpace { TOP_1, TOP_3, THRESHOLD }). Wouldn't it be great if the enum values could also take parameters (c++ std::variant, but I digress).
Then that scoreSpace could become a trial hyperparameter, like species and year are in this PR.
If we were looking for even more efficiency, both speed and memory, we could consider changing the signature of trialFns so that the data list from model_read_lib was also an argument (trialFn(params, fullData)). That way we wouldn't re-read separately for every trial, and it would be more RAM efficient when the executor is multiprocessing because that uses fork, and Linux fork is copy-on-write (shares RAM from the parent process until it changes). However, that would come at the cost of some rework and a breaking change to function signature of readCombined. It would add an extra step if trying to use readCombined independently of run_trials.R.

Ok, that sounds good.

If we were looking for even more efficiency, both speed and memory, we could consider changing the signature of trialFns so that the data list from model_read_lib was also an argument (trialFn(params, fullData)).

Regarding this change, I attempted to do this in the combined-input-function branch (with the amount of data, not species). If we make a list of length(nspecies) where each item in the list is a jagsinput for a different species, we can just loop through each of the items in the list as an input to the model function. It would still take a while to make the giant data_list, but we would not have to remake it every time we run the model (if we are running different models).

Something like this
data <- future_map(speciesCodes,
              ~ readCombined(
                  species = c(.x),
                  years = c(2021),
                  beginTime = dhours(6),
                  endTime = dhours(10),
                  visitLimit = aruVisitLimit,
                  visitAggregation = "file",
                  thresholdOptions = list(
                    value = threshold,
                    is.quantile = F
                  ),
                  squeeze = T
))

Using furrr allows for it to run more quickly, but ideally this should only have to be run one time as data can be reused.

authors: matt-har-vey mschulist

repo: calacademy-research/COMB


text:
Adding new language support

Thank you , may GOD bless you!
how can I add a new language support, such as chinese?

I would need to add support for the language on your behalf. However, note that I am only able to add support for languages which the YouVersion Bible supports. I'm assuming that Chinese is the language in question here, and so because I am not as familiar with the language, I would like to work with you to add support in a way that would make sense to you.
If you could please look through this list and tell me the particular supported language (from the list) that would work for you, I can begin working on adding it.

https://www.bible.com/zh-CN/versions/48-cunpss-xin-biao-dian-he-he-ben-shen-ban
CUNPSS  is the most popular version in Chinese christians. That is what I need. Thanks.

if you need me edit some language json file, please let me know.

Thanks, @wildplant, however there should be no need for that. I've just submitted a pull request with my additions for simplified Chinese (zh-CN). Please see issue #4 and let me know if any changes need to be made. :)
Caleb

I copied the 2 files to my workflow folder, it works. thank you.

Great, though I was still planning on updating the packaged workflow with the new language support.
Please download/install the packaged workflow on develop and let me know if everything still works.
Thanks,
Caleb


text:
Plugin conflicts with multilanguage site

While developing a site I installed many plugins and additional fields and so on. At some point I noticed my multilang site was not working properly.
Changing language was not working. I could change the language, the page was redirected (example.com/en), all the language variables were changed (for example $site->language() is changed correctly) and it was fine, but snippets fetching pages' content still fetched the default language content.
I finally found out it was caused by your plugin, this part:
// If the page doesn't exist yet, create it.
if(!site()->index()->findBy('intendedTemplate', 'content-viewer')) {
	site()->create('content-viewer', 'content-viewer', array(
		'title' => '',
		'text' => ''
	));
}

Not really sure how this affects multilang config, but it surely does. Just commenting this part and it works again.

As I understand this, that part of code shouldn't even run as I have got pages for the content-viewer plugin created.
Are you sure that you can negate site()->index()->findBy('intendedTemplate', 'content-viewer')? Because I changed the if to:
if(!site()->findBy('intendedTemplate', 'content-viewer')) {
And multilang works fine.

Uh-oh, that's strange. The reason why I have site()->index() is because findBy() only searches the root level otherwise. Unfortunately, I don't have time to look into this right now, but I'll put it near the top of my priority list.

So, I just released a hotfix for this problem by using your code. However, this change does mean that the content-viewer page must be in the root level of the content folder. This is probably not a big problem, as that is where the plugin stores it by default, but it would be nice to allow people to move it into another directory of they so desire without breaking the plugin.
Hence, I'll leave this issue open for now.

I may play a little bit with the original code to see what was happening. Maybe I'll find the reason for this. Will let you know if I do.

Gonna go ahead and close this issue, as no-one has said that having the content file for the plugin anywhere besides the root content folder is something important to them.

authors: CalebGrove calebgrove mciszczon

repo: calebgrove/content-viewer


text:
Refactor get_key

I had this diff laying around, finally took the time to split it up into several
commits. Thoughts and feedback are much appreciated.

Hey @mptre, nice work! To me, the code reads better this way. Looks good to merge!

authors: calleerlandsson mptre

repo: calleerlandsson/pick


text:
Item list or just lists

First: Amazing Job! Thanks so much.
Second: I can't find any reference to support for lists like https://www.google.com/design/spec/components/lists.html#lists-usage. Is this implemented ? It will be nice if lists are supported.
Again, thanks for an incredible job.

Thanks @lesterzone - I was just thinking about this on my drive home today. :)
It's definitely on the to-do list. We've got a few other things to get done first.

+1!
I ended up doing something manually like this https://github.com/killfill/chihuahua/blob/master/src/js/components/list.jsx
bye!

I think we really need to think about this. We need some love on lists :heart:

I actually have implemented this using the default usage (style wise). The only thing we need is an actionable right icon. I will submit a pull request today with the functionality built. The only thing I need to think on is whether the main action is fired on the secondary action click, or if they are fired separately. Inbox by google triggers both. I think this can be left to the user by change the calls passed into the props.

Any progress on this one ?

Hi guys, would you recommend any list by a 3rd-party-developer which makes it easy to integrate with material-ui?

any updates?

I have been using a custom implementation of @killfill's for a while. Feel free to use it as reference.
List
List Item

+1

+1
surprised that something basic as a list is still missing :/

+1

Added with #836 - should be released in the next day or so.

:+1: thanks!

authors: FoxxMD SkaveRat hai-cea killfill landabaso lesterzone luisrudge matiaslarsson moimael obieq troutowicz yhbrandon

repo: callemall/material-ui


text:
EdgeCloud LifecycleManagement API proposal

Hello everyone!
We propose this API definition as a first contribution to the EdgeCloud Lifecycle Management. This includes:

Application Management - Deploy and remove applications within artifacts
Application Artifacts Management - Management of application descriptors, binaries, charts and packages. The format of the artifact definition is based on the way the current Cloud providers (AWS, Azure, Google, etc.) are requesting for the creation of this element
MEC Platfform information - Retrieves all the Edge nodes available according to some defined parameters. Is to be discussed the way to incorporate the Edge Selection API. As there is an existing contribtion we did not include that query-response until we accept some points to be discussed in the meeting

The API is based also in the contributions done by other partners on this CAMARA group. We can further discuss this file in the next meetings.
Contributors: @javierlozallu, @crissancas, @sergiofranciscoortiz
Cheers!

New commit has been submitted regarding the last meeting we have (Minutes of meeting). Also previous comments have been answered. Hope API is ready to be merged!

@Kevsy , @gunjald ,@FabrizioMoggio As agreed during  19th December EdgeCloud Meeting, this PR  has evolve to a point where it should be merged as pending conversations could be treated in separated PRs to facilitate management. Please review if there is anything else to consider before approval.

authors: TEF-RicardoSerr sergiofranciscoortiz

repo: camaraproject/EdgeCloud


text:
[BUG] Candidate DNM VCF missing header

Combined candidate VCF missing header. Probably bug in summarize_denovo.

Glitched introduced in upgrade to DSL2. Chrfilt VCF not passed to summarizeDNM process.

Needed to adjust the name of the VCF file passed in the process. Putatively resolved in 1.2.0

repo: campanam/RatesTools


text:
Paypal window confusion

Hi Will, a couple of problems with paying via PayPal:

When I chose the PayPal option, a new Mozilla Firefox window opened in the center of my browser window.  (As you may infer, I am using Firefox.)  The new window had no content.  When I closed it, behind it was revealed the "Pay with PayPal" screen which the popup window had been covering.

I now cannot leave the "Pay with PayPal screen".  I can't hit back or Esc or click outside the popup or anything.  If I don't after all want to use PayPal, I have to find a way back to the main screen.  I did a force-reload, but many registrants will not know how to do that.  Suggestion: the PayPal window could open in a new tab so that people have a way back to the main screen.

Maybe this is the solution, I'll try it out:
https://stackoverflow.com/questions/71104248/paypal-javascript-sdk-button-opens-aboutblankblocked-window-in-django-template

repo: camphoric/camphoric


text:
fix: higher rock compatibility, build.lua typo

This PR adds two fixes:

Typo in build.lua (package.page -> package.path)
Properly search for both ?.lua files as well as ?/init.lua files in the package path

As it is said in the readme: An up-to-date Neovim nightly (>= 0.10) installation is a requirement.
Because luarocks.nvim does not target non-nightly neovim at the moment, commit 50b9f43 can be reverted.
luarocks.nvim does not work on non nightly neovim due to some other functions that are only available in nightly so there is no point in not using vim.fs.joinpath.
You certainly can create a fork that works on neovim 0.9.5 but I am not sure if this is your intention and nightly will eventually become released so there is no point in doing that unless we want to start using luarocks.nvim as the cure for all luarocks problems with lazy.nvim in plugins for older neovim versions before neovim 0.10 is released.
Unless of course you mean that vim.fs.joinpath will be removed on 0.10's release.

@jaredmontoya I realized that lowering the requirement down to the latest Neovim stable is actually quite trivial which is why I reverted that commit. I have another branch, more-fixes, which completely eliminates the nightly requirement.
The more people start using luarocks the better :)

That's awesome!

authors: jaredmontoya vhyrro

repo: camspiers/luarocks

license: Unlicense


text:
Enable basic auth for rest api from values.yaml

How can i enable basic auth for the rest-api in the values.yaml file?

The only solution I can see for you without building a new docker image and a new chart, is to use image.command https://github.com/camunda-community-hub/camunda-7-community-helm/blob/main/charts/camunda-bpm-platform/values.yaml#L22 to add a script that updates the WEB-INF.xml file and then make a ./camunda.sh.
But I can't include clean functionality in the chart because the docker image doesn't accept scripts on startup.

authors: sinannoureddine thecampagnards


text:
Enhance editing entries in new DMN modeler

Editing single cells could be more intuitive.

I think it would make sense to show the additional menu whenever the cursor has focus on an input cell.

At least one should be able to toggle the menu multiple times (see screenshot).

Pressing return should result in being able to edit the next line of the same column

Okay, so:

We decided to not open the context menu automatically on focus since that would be pretty obtrusive.

This is actually a bug. I've created an issue for it.

Do you mean pressing ENTER?

Thanks Phillip!

I mean pressing ENTER.

Adding to 1 you can open the context menu immediately by pressing CMD when clicking on a cell.
Regarding 3 do you mean pressing ENTER while a cell is focussed or while you are editing through the context menu?

1: cool, I didn't know 👍
3: after typing expressions (not using the context menu)

In what context are you using the DMN modeling? On ENTER the cell below should be selected, on ENTER + SHIFT the cell above should be selected.

Ah, sorry, I missed that this does not work on the last rule. I would have expected that pressing ENTER adds a new row. Don't know if that is a valid use case, but that's the reason why it didn't work when I tried it.

I totally agree with you, we've already thought about this.
I've created an issue for that: https://github.com/bpmn-io/dmn-js/issues/345

authors: benhoffmann philippfromme

repo: camunda/camunda-modeler


text:
Alternate package repos

At this point I fear this PR is rather large, so quick pretext that I am totally fine if you don't want all (or any) of this to be merged.
Resolves #17
Some notable things this PR does:

Creates a config.yaml in the base .webman dir, which is used to control things like refresh interval and package repositories

By default the refresh interval is set to 6h (same as current), and a single package repo is written (webman-pkgs)
Recipes are moved one layer deeper and are identified by their name in the config.
e.g. the default lives in ~/.webman/recipes/webman now
When any commands are processed, they now look through package repos to find a match, meaning the first to match wins.

I ran gofumpt, which is why some of the formatting is changed. gofumpt is just a stricter gofmt, so they are compatible.
I removed the refresh files and am instead simply checking the directory modtime. Since we remove the entire dir, the modtime is effectively the same as the last time we "refreshed".

For me, personally, the reason for wanting this is because I have some homegrown projects that I would love to benefit from the UX simplicity of webman, but I'm not sure make sense to add to the central webman-pkgs repo.
As well, this allows me to potentially use this in a work setting where, again, the tools used may not make sense to add to the central location.

Currently there aren't any dedicated tests, so I will report back after using this for a while and let you know if I run into any hiccups. (And also when I find time I will try to write some tests)

I'm gonna take some time to review this later today. Exciting work!

Just for future reference, separating out a formatting-type change that touches lots of files into its own PR makes it a lot easier to review. Less noise :)

Yeah, that's my bad. I'm so used to using gofumpt that it's muscle memory, and I included it in the commit.
Will try to keep it in mind next time. 👍


text:
SSDLC exploration task Software Bill of Material

Context
We want to learn more what is the effort for the given epic https://warthogs.atlassian.net/browse/KF-5511
What needs to get done

Explore details of this epic https://warthogs.atlassian.net/browse/KF-5511
Create all necessary tasks  needed to complete the epic

Definition of Done

Details documented in this issue
Tasks created in Jira

Discussed with the SSDLC team and the conclusion is:

we'll use the fetch service tool released by the SSDLC team to generate SBOMs for the mlflow bundle, the kubeflow bundle, the resource-dispatcher charm, and the dss snap. the tasks created are #1062 , #1061 , https://github.com/canonical/resource-dispatcher/issues/65 and https://github.com/canonical/data-science-stack/issues/176
mlflow bundle is our test SBOM, I have created it and requested a review from the team
For the OCI images and rocks, we will write a script using syft to scan them, more details are in the task #1078
the SBOMs will be stored in our team's drive in a dedicated directory SMOBs

authors: NohaIhab misohu

repo: canonical/bundle-kubeflow


text:
Deprecate the usage of /etc/hardware-exporter-config.yaml

The prometheus-hardware-exporter accept command line flags instead of config file. We should directly render the config file as the command line flag in the hardware-exporter.service.j2. This will reduce our effort to maintain two config files.

@chanchiwai-ray I suspect that most if not all changes would end up in the config file, and not in the systemd service (meaning that we already kind of are maintaining only one of those two). Why would it be better to move the config values to CLI options?

This was only to make the charm code cleaner: we don't need to explicitly render config -> render service -> start service when installing the exporter, but that's more of a refactoring

I'm afraid that we won't handle this one (priority is very low). I will close this request

authors: Pjack aieri chanchiwai-ray

repo: canonical/hardware-observer-operator


text:
Pin Indico to version 3.1

Pin Indico version to 3.1.*

Let's wait to see what the response is to https://github.com/indico/indico/issues/5471. If Indico are able to fix this before we need external users in production it feels reasonable to hold off to allow them to fix.

Won't merge. Encoding issues are solved through #86

authors: arturo-seijas mthaddon

repo: canonical/indico-operator


text:
Update Coordinator Functionality

For integration with the Coordinator from COS-Lib, the s3_bucket_name was removed from the Coordinator instantiation.
As part of this PR, the /v1/cert_handler charm lib needed to be updated.
/v0/kubernetes_compute_resources_patch was added.

Closing since PR#11 solves this PR


text:
feat: make ca-chain an optional parameter

Description
Make ca-chain an optional parameter.
Fixes #157
Rationale
It doesn't make much sense for ca-chain to be a required parameter. Especially in contexts of self-signed certificates.
Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that validate the behaviour of the software
[ ] I validated that new and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

Code-wise LGTM.
I'm not entirely sure why (or if) it makes sense to use the ca certificate if the chain isn't provided. Are we doing this because normally the chain includes the ca certificate, as well as any intermediaries, or because our implementation expects something here because of the way we've implemented it? I'm worried about the later, and that we're just shoving this in as the "chain" because it works.

The chain does include the ca certificate and if it is a chain of 1 item, it doesn't make sense to ask the user to provide it again. In the case of self-signed for example, our existing implementation would prevent from setting up a CA cert with openssl and signing certs with it.

My concern (which I didn't make clear at all) was about our code downstream from this change (set_relation_certificate, _add_certificate, and then ultimately what we put in the relations). Does it make sense to copy the ca certificate here as "chain", or should these all be written to handle a lack of a chain? -- It seems obvious, to me, that the top level CA would be included in the chain of trust, so it seems very odd to me that we duplicate it. But I'm also not familiar with the implementation.

l be written to handle a lack of a chain? -- It seems obvious, to me, that the top level CA would be included in the chain of trust, so it seems very odd to me that we duplicate it. But I'm also not familiar with the implementation.

I agree that we could make the CA chain parameter optional in all those methods and in the relation data too. But that's not the case right now. What do you recommend?

I think it's fine to avoid that for now, as long as we throw something in the backlog to follow up on it and clean it up. It's not a big deal, but it feels like one of those things that could continue to grow and get hacky over time.

authors: DanielArndt gruyaume


text:
yamllint the workflows

Recently, stray whitespace was introduced in a .github files.
This PR adds a "validate" step that runs yamllint on the entire .github folder.

@sed-i, please sign your commits and we'll merge it 👍🏼

authors: sed-i simskij

repo: canonical/observability


text:
test-branch/execute-job/wrong-commit-sha-on-pr/6b0588e2-b21d-43a1-8997-b2b05a4bdc1c

PR for testing 47bd8b174f42d3eb3e45eada0bbb4dcb25b31388

/canonical/self-hosted-runners/run-workflows 931ad21dd9ace68aaa0a7d341e94de96ad93fa6b

repo: canonical/repo-policy-compliance-tests


text:
test-branch/execute-job/wrong-commit-sha-on-pr/49e6e096-67d1-4fce-9afa-e155b0a81c63

PR for testing 69a081c869db6a42f1559b33c48e286ed9250001

/canonical/self-hosted-runners/run-workflows dd681039aa42ab32c8f29d991bb08cd5a2a164db

repo: canonical/repo-policy-compliance


text:
Add a manual testing playbook for the snap

To review the rendered output of the new document, you can see it at https://github.com/canonical/tailscale-snap/blob/manual-testing/docs/manual-testing-playbook.md

There are a few more things to test, but I think it's in a reviewable state now. We can always add more test cases later if needed too.

Note that I've been developing this document in parallel with testing tailscale. I can confirm I've run all the described commands and verified the work as described in the document - although there may be typos in the doc. Please run through the document, following the instructions and commands if possible to comprehensively review.
I think this is a useful document for now, both to demonstrate the features supported or not in the snap, and to be able to follow for reproducible manual testing. I do think we can iterate on this in the future to make it more usable - maybe by splitting into smaller documents, transforming into something interactive like a jupyter notebook, or using a mix of documents and cucumber-like tests.

repo: canonical/tailscale-snap


text:
Update README to use https in all links

Re-submitting against develop branch

49 commits? Can you rebase onto develop?

No need to close - just git rebase develop && git push -f

Never mind - I grabbed it and rebased it myself.
Thanks!

Turns out I need to set it up locally first, since there is no way to rebase it from github's web-ui that I'm aware of... so I decided to closed the PR until i figure it out.
Thanks! I'll do it properly next time :)

Aah fair enough. No worries.


text:
feat: support hybrid access for universal csn

universal csn  makes it possible to use structured and flat access to elements of the underlying entity.
the non-enumerable elements of an entity are marked as "already unfolded". This marker can be used to skip those elements from e.g. wildcard expansion but makes it possible to directly access them in the query.

looks like the topic is - for now- not further pursued, so this PR is on hold

repo: cap-js/cds-dbs