GoogleDataTransport.h file not found

Step 0: Are you in the right place?

For issues or feature requests related to the code in this repository
file a Github issue.

If this is a feature request please use the Feature Request template.

For general technical questions, post a question on StackOverflow
with the firebase tag.
For general (non-iOS) Firebase discussion, use the firebase-talk
google group.
For backend issues, console issues, and other non-SDK help that does not fall under one
of the above categories, reach out to
Firebase Support.
Once you've read this section and determined that your issue is appropriate for
this repository, please delete this section.

[REQUIRED] Step 1: Describe your environment

Xcode version: 12.4
Firebase SDK version: _____
Installation method: CocoaPods
Firebase Component: Analytics

[REQUIRED] Step 2: Describe the problem
Steps to reproduce:
Followed the install guide on https://firebase.google.com/docs/ios/setup but when run a build after pod install, I get an error:
...Pods/FirebaseCoreDiagnostics/Firebase/CoreDiagnostics/FIRCDLibrary/FIRCoreDiagnostics.m:20:9: 'GoogleDataTransport/GoogleDataTransport.h' file not found

Don't know whether it has something to do with the issue but when installing I also get the following warning:
[!] Unable to read the license file `LICENSE` for the spec `GoogleDataTransport (8.2.0)`

@wim07101993 Sorry about the trouble.  Please share the CocoaPods version from pod --version and the contents of the generated Podfile.lock file.

Hi,
No problem. In the meantime I got firebase working with swift packages but since the rest of the project works with cocoapods, I would prefer to add Firebase that way.
$ pod --version
1.10.1

podfile.lock
PODS:
  - AEXML (4.6.0)
  - Alamofire (5.4.1)
  - CryptoSwift (1.3.8)
  - Firebase/Analytics (7.6.0):
    - Firebase/Core
  - Firebase/Core (7.6.0):
    - Firebase/CoreOnly
    - FirebaseAnalytics (= 7.6.0)
  - Firebase/CoreOnly (7.6.0):
    - FirebaseCore (= 7.6.0)
  - FirebaseAnalytics (7.6.0):
    - FirebaseCore (~> 7.0)
    - FirebaseInstallations (~> 7.0)
    - GoogleAppMeasurement (= 7.6.0)
    - GoogleUtilities/AppDelegateSwizzler (~> 7.0)
    - GoogleUtilities/MethodSwizzler (~> 7.0)
    - GoogleUtilities/Network (~> 7.0)
    - "GoogleUtilities/NSData+zlib (~> 7.0)"
    - nanopb (~> 2.30907.0)
  - FirebaseCore (7.6.0):
    - FirebaseCoreDiagnostics (~> 7.4)
    - GoogleUtilities/Environment (~> 7.0)
    - GoogleUtilities/Logger (~> 7.0)
  - FirebaseCoreDiagnostics (7.6.0):
    - GoogleDataTransport (~> 8.0)
    - GoogleUtilities/Environment (~> 7.0)
    - GoogleUtilities/Logger (~> 7.0)
    - nanopb (~> 2.30907.0)
  - FirebaseInstallations (7.6.0):
    - FirebaseCore (~> 7.0)
    - GoogleUtilities/Environment (~> 7.0)
    - GoogleUtilities/UserDefaults (~> 7.0)
    - PromisesObjC (~> 1.2)
  - GoogleAppMeasurement (7.6.0):
    - GoogleUtilities/AppDelegateSwizzler (~> 7.0)
    - GoogleUtilities/MethodSwizzler (~> 7.0)
    - GoogleUtilities/Network (~> 7.0)
    - "GoogleUtilities/NSData+zlib (~> 7.0)"
    - nanopb (~> 2.30907.0)
  - GoogleDataTransport (8.2.0):
    - nanopb (~> 2.30907.0)
  - GoogleUtilities/AppDelegateSwizzler (7.2.2):
    - GoogleUtilities/Environment
    - GoogleUtilities/Logger
    - GoogleUtilities/Network
  - GoogleUtilities/Environment (7.2.2):
    - PromisesObjC (~> 1.2)
  - GoogleUtilities/Logger (7.2.2):
    - GoogleUtilities/Environment
  - GoogleUtilities/MethodSwizzler (7.2.2):
    - GoogleUtilities/Logger
  - GoogleUtilities/Network (7.2.2):
    - GoogleUtilities/Logger
    - "GoogleUtilities/NSData+zlib"
    - GoogleUtilities/Reachability
  - "GoogleUtilities/NSData+zlib (7.2.2)"
  - GoogleUtilities/Reachability (7.2.2):
    - GoogleUtilities/Logger
  - GoogleUtilities/UserDefaults (7.2.2):
    - GoogleUtilities/Logger
  - nanopb (2.30907.0):
    - nanopb/decode (= 2.30907.0)
    - nanopb/encode (= 2.30907.0)
  - nanopb/decode (2.30907.0)
  - nanopb/encode (2.30907.0)
  - ObjcExceptionBridging (1.0.1):
    - ObjcExceptionBridging/ObjcExceptionBridging (= 1.0.1)
  - ObjcExceptionBridging/ObjcExceptionBridging (1.0.1)
  - PromisesObjC (1.2.12)
  - SwiftKeychainWrapper (4.0.1)
  - SwiftyJSON (5.0.0)
  - SWXMLHash (5.0.1)
  - XCGLogger (7.0.1):
    - XCGLogger/Core (= 7.0.1)
  - XCGLogger/Core (7.0.1):
    - ObjcExceptionBridging

DEPENDENCIES:
  - AEXML
  - Alamofire (~> 5.2)
  - CryptoSwift (~> 1.3.8)
  - Firebase/Analytics
  - SwiftKeychainWrapper (~> 4.0.1)
  - SwiftyJSON (~> 5.0)
  - SWXMLHash (~> 5.0.0)
  - XCGLogger (~> 7.0.1)

SPEC REPOS:
  trunk:
    - AEXML
    - Alamofire
    - CryptoSwift
    - Firebase
    - FirebaseAnalytics
    - FirebaseCore
    - FirebaseCoreDiagnostics
    - FirebaseInstallations
    - GoogleAppMeasurement
    - GoogleDataTransport
    - GoogleUtilities
    - nanopb
    - ObjcExceptionBridging
    - PromisesObjC
    - SwiftKeychainWrapper
    - SwiftyJSON
    - SWXMLHash
    - XCGLogger

SPEC CHECKSUMS:
  AEXML: 2fbb73d8724797ed2cde888731e176fa4d44dd83
  Alamofire: 2291f7d21ca607c491dd17642e5d40fdcda0e65c
  CryptoSwift: 01b0f0cba1d5c212e5a335ff6c054fb75a204f00
  Firebase: e1e089d9aac215a52442583f818ab61de3c4581b
  FirebaseAnalytics: 9f8f4feab1f3fddf4e4515f8f022fe6aa9e51043
  FirebaseCore: 0a43b7f1c5b36f3358cd703011ca4c7e0df55870
  FirebaseCoreDiagnostics: ee1184d51da3293335b83355aad20f537acc24cf
  FirebaseInstallations: 6e4e77396559bc2ae0504823837ed737b1c7e47f
  GoogleAppMeasurement: c542a2feaac9ab98fd074e8f1a02c3585bbfbd47
  GoogleDataTransport: 1024b1a4dfbd7a0e92cb20d7e0a6f1fb66b449a4
  GoogleUtilities: 31c5b01f978a70c6cff2afc6272b3f1921614b43
  nanopb: 59221d7f958fb711001e6a449489542d92ae113e
  ObjcExceptionBridging: c30e00eb3700467e695faeea30e26e18bd445001
  PromisesObjC: 3113f7f76903778cf4a0586bd1ab89329a0b7b97
  SwiftKeychainWrapper: 807ba1d63c33a7d0613288512399cd1eda1e470c
  SwiftyJSON: 36413e04c44ee145039d332b4f4e2d3e8d6c4db7
  SWXMLHash: 9cc0c2e4807926c74377724aa8722ee5707a0485
  XCGLogger: 1943831ef907df55108b0b18657953f868de973b

PODFILE CHECKSUM: ecae01db27430f050077d168d18afd97e013336b

COCOAPODS: 1.10.1

Hi, no problem.
I currently have the integration working with swift packages but since the project uses cocoapods as mail package manager, I would like to add Firebase to that too...
$ pod --version
1.10.1

Thanks. Are you opening the xcworkspace versus the xcodeproj?  Does clearing DerivedData help? rm -rf ~/Library/Developer/Xcode/DerivedData/? Or pod deintegrate and pod install?

Same problem here. Did both. Also removed pod cache en did a clean install

m -rf ~/Library/Developer/Xcode/DerivedData/ worked for me

made one change to the pod file and same error came up...
This time clearing the DerivedDate or deintegrating the pod does not help

This is almost certainly an environment issue and we'll likely need a repro case to provide additional assistance.


Update README.md

Fixed minor typos

Thanks @vatsalya-vyas  can you please rebase and resolve the conflicts?


perf(es): Optimize memory layout of AST

Description:
I'll postpone this as this is a huge breaking change. I'll merge this when we are implementing TS 4.9 satisfies.

Perforamnce difference
minifier
Gnuplot not found, using plotters backend
Benchmarking es/minify/libraries/antd
Benchmarking es/minify/libraries/antd: Warming up for 3.0000 s

Warning: Unable to complete 10 samples in 5.0s. You may wish to increase target time to 6.2s.
Benchmarking es/minify/libraries/antd: Collecting 10 samples in estimated 6.1933 s (10 iterations)
Benchmarking es/minify/libraries/antd: Analyzing
es/minify/libraries/antd
                        time:   [620.86 ms 624.46 ms 628.66 ms]
                        change: [-22.841% -22.308% -21.758%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 1 outliers among 10 measurements (10.00%)
  1 (10.00%) high mild
Benchmarking es/minify/libraries/d3
Benchmarking es/minify/libraries/d3: Warming up for 3.0000 s

Warning: Unable to complete 10 samples in 5.0s. You may wish to increase target time to 7.6s or enable flat sampling.
Benchmarking es/minify/libraries/d3: Collecting 10 samples in estimated 7.6350 s (55 iterations)
Benchmarking es/minify/libraries/d3: Analyzing
es/minify/libraries/d3  time:   [129.75 ms 130.21 ms 130.61 ms]
                        change: [-15.798% -15.371% -14.986%] (p = 0.00 < 0.05)
                        Performance has improved.
Benchmarking es/minify/libraries/echarts
Benchmarking es/minify/libraries/echarts: Warming up for 3.0000 s
Benchmarking es/minify/libraries/echarts: Collecting 10 samples in estimated 9.7596 s (20 iterations)
Benchmarking es/minify/libraries/echarts: Analyzing
es/minify/libraries/echarts
                        time:   [485.80 ms 487.35 ms 488.88 ms]
                        change: [-23.405% -22.989% -22.583%] (p = 0.00 < 0.05)
                        Performance has improved.
Benchmarking es/minify/libraries/jquery
Benchmarking es/minify/libraries/jquery: Warming up for 3.0000 s
Benchmarking es/minify/libraries/jquery: Collecting 10 samples in estimated 6.5932 s (165 iterations)
Benchmarking es/minify/libraries/jquery: Analyzing
es/minify/libraries/jquery
                        time:   [39.674 ms 39.790 ms 39.888 ms]
                        change: [-7.4199% -6.9714% -6.5607%] (p = 0.00 < 0.05)
                        Performance has improved.
Benchmarking es/minify/libraries/lodash
Benchmarking es/minify/libraries/lodash: Warming up for 3.0000 s
Benchmarking es/minify/libraries/lodash: Collecting 10 samples in estimated 6.2038 s (110 iterations)
Benchmarking es/minify/libraries/lodash: Analyzing
es/minify/libraries/lodash
                        time:   [54.658 ms 54.983 ms 55.276 ms]
                        change: [-6.0030% -5.0606% -4.3268%] (p = 0.00 < 0.05)
                        Performance has improved.
Benchmarking es/minify/libraries/moment
Benchmarking es/minify/libraries/moment: Warming up for 3.0000 s
Benchmarking es/minify/libraries/moment: Collecting 10 samples in estimated 5.5915 s (220 iterations)
Benchmarking es/minify/libraries/moment: Analyzing
es/minify/libraries/moment
                        time:   [24.989 ms 25.056 ms 25.132 ms]
                        change: [-6.9642% -6.4017% -5.7664%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 1 outliers among 10 measurements (10.00%)
  1 (10.00%) high mild
Benchmarking es/minify/libraries/react
Benchmarking es/minify/libraries/react: Warming up for 3.0000 s
Benchmarking es/minify/libraries/react: Collecting 10 samples in estimated 5.0256 s (440 iterations)
Benchmarking es/minify/libraries/react: Analyzing
es/minify/libraries/react
                        time:   [11.304 ms 11.333 ms 11.348 ms]
                        change: [-4.0229% -3.4375% -2.8645%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 1 outliers among 10 measurements (10.00%)
  1 (10.00%) high mild
Benchmarking es/minify/libraries/terser
Benchmarking es/minify/libraries/terser: Warming up for 3.0000 s

Warning: Unable to complete 10 samples in 5.0s. You may wish to increase target time to 6.3s or enable flat sampling.
Benchmarking es/minify/libraries/terser: Collecting 10 samples in estimated 6.2739 s (55 iterations)
Benchmarking es/minify/libraries/terser: Analyzing
es/minify/libraries/terser
                        time:   [113.05 ms 113.25 ms 113.53 ms]
                        change: [-14.455% -13.868% -13.346%] (p = 0.00 < 0.05)
                        Performance has improved.
Benchmarking es/minify/libraries/three
Benchmarking es/minify/libraries/three: Warming up for 3.0000 s

Warning: Unable to complete 10 samples in 5.0s. You may wish to increase target time to 9.4s or enable flat sampling.
Benchmarking es/minify/libraries/three: Collecting 10 samples in estimated 9.3763 s (55 iterations)
Benchmarking es/minify/libraries/three: Analyzing
es/minify/libraries/three
                        time:   [168.85 ms 169.15 ms 169.52 ms]
                        change: [-19.905% -19.348% -18.833%] (p = 0.00 < 0.05)
                        Performance has improved.
Benchmarking es/minify/libraries/typescript
Benchmarking es/minify/libraries/typescript: Warming up for 3.0000 s

Warning: Unable to complete 10 samples in 5.0s. You may wish to increase target time to 13.6s.
Benchmarking es/minify/libraries/typescript: Collecting 10 samples in estimated 13.646 s (10 iterations)
Benchmarking es/minify/libraries/typescript: Analyzing
es/minify/libraries/typescript
                        time:   [1.3660 s 1.3703 s 1.3747 s]
                        change: [-20.914% -20.551% -20.250%] (p = 0.00 < 0.05)
                        Performance has improved.
Benchmarking es/minify/libraries/victory
Benchmarking es/minify/libraries/victory: Warming up for 3.0000 s
Benchmarking es/minify/libraries/victory: Collecting 10 samples in estimated 5.9296 s (20 iterations)
Benchmarking es/minify/libraries/victory: Analyzing
es/minify/libraries/victory
                        time:   [290.98 ms 293.52 ms 296.23 ms]
                        change: [-16.272% -15.458% -14.495%] (p = 0.00 < 0.05)
                        Performance has improved.
Benchmarking es/minify/libraries/vue
Benchmarking es/minify/libraries/vue: Warming up for 3.0000 s
Benchmarking es/minify/libraries/vue: Collecting 10 samples in estimated 6.7515 s (110 iterations)
Benchmarking es/minify/libraries/vue: Analyzing
es/minify/libraries/vue time:   [59.382 ms 59.627 ms 59.912 ms]
                        change: [-7.4172% -6.7056% -5.9969%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 1 outliers among 10 measurements (10.00%)
  1 (10.00%) high severe

parser
main
Gnuplot not found, using plotters backend
Benchmarking es/parser/colors
Benchmarking es/parser/colors: Warming up for 3.0000 s
Benchmarking es/parser/colors: Collecting 100 samples in estimated 5.0160 s (328k iterations)
Benchmarking es/parser/colors: Analyzing
es/parser/colors        time:   [15.162 us 15.185 us 15.204 us]
                        change: [-1.0265% -0.6399% -0.2362%] (p = 0.00 < 0.05)
                        Change within noise threshold.
Found 17 outliers among 100 measurements (17.00%)
  6 (6.00%) low severe
  8 (8.00%) low mild
  1 (1.00%) high mild
  2 (2.00%) high severe

Benchmarking es/parser/angular
Benchmarking es/parser/angular: Warming up for 3.0000 s
Benchmarking es/parser/angular: Collecting 100 samples in estimated 5.5823 s (700 iterations)
Benchmarking es/parser/angular: Analyzing
es/parser/angular       time:   [7.7625 ms 7.7777 ms 7.7936 ms]
                        change: [-1.2541% -1.0161% -0.7833%] (p = 0.00 < 0.05)
                        Change within noise threshold.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild

Benchmarking es/parser/backbone
Benchmarking es/parser/backbone: Warming up for 3.0000 s

Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 5.6s, enable flat sampling, or reduce sample count to 60.
Benchmarking es/parser/backbone: Collecting 100 samples in estimated 5.5766 s (5050 iterations)
Benchmarking es/parser/backbone: Analyzing
es/parser/backbone      time:   [1.0999 ms 1.1018 ms 1.1036 ms]
                        change: [-1.6594% -0.9178% -0.1876%] (p = 0.01 < 0.05)
                        Change within noise threshold.
Found 15 outliers among 100 measurements (15.00%)
  1 (1.00%) low severe
  10 (10.00%) low mild
  1 (1.00%) high mild
  3 (3.00%) high severe

Benchmarking es/parser/jquery
Benchmarking es/parser/jquery: Warming up for 3.0000 s
Benchmarking es/parser/jquery: Collecting 100 samples in estimated 5.4915 s (900 iterations)
Benchmarking es/parser/jquery: Analyzing
es/parser/jquery        time:   [6.0423 ms 6.0542 ms 6.0667 ms]
                        change: [-1.5858% -1.3284% -1.0887%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild

Benchmarking es/parser/jquery mobile
Benchmarking es/parser/jquery mobile: Warming up for 3.0000 s
Benchmarking es/parser/jquery mobile: Collecting 100 samples in estimated 5.7741 s (600 iterations)
Benchmarking es/parser/jquery mobile: Analyzing
es/parser/jquery mobile time:   [9.4662 ms 9.4848 ms 9.5045 ms]
                        change: [-1.6790% -1.4122% -1.1852%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 2 outliers among 100 measurements (2.00%)
  2 (2.00%) high mild

Benchmarking es/parser/mootools
Benchmarking es/parser/mootools: Warming up for 3.0000 s
Benchmarking es/parser/mootools: Collecting 100 samples in estimated 5.0629 s (1100 iterations)
Benchmarking es/parser/mootools: Analyzing
es/parser/mootools      time:   [4.5568 ms 4.5657 ms 4.5749 ms]
                        change: [-2.0553% -1.7762% -1.5099%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild

Benchmarking es/parser/underscore
Benchmarking es/parser/underscore: Warming up for 3.0000 s
Benchmarking es/parser/underscore: Collecting 100 samples in estimated 9.5302 s (10k iterations)
Benchmarking es/parser/underscore: Analyzing
es/parser/underscore    time:   [937.09 us 938.55 us 939.90 us]
                        change: [-2.2404% -1.5832% -0.9651%] (p = 0.00 < 0.05)
                        Change within noise threshold.
Found 6 outliers among 100 measurements (6.00%)
  3 (3.00%) low mild
  2 (2.00%) high mild
  1 (1.00%) high severe

Benchmarking es/parser/three
Benchmarking es/parser/three: Warming up for 3.0000 s
Benchmarking es/parser/three: Collecting 100 samples in estimated 5.4936 s (200 iterations)
Benchmarking es/parser/three: Analyzing
es/parser/three         time:   [27.085 ms 27.129 ms 27.174 ms]
                        change: [-2.4511% -2.2274% -2.0052%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild

Benchmarking es/parser/yui
Benchmarking es/parser/yui: Warming up for 3.0000 s
Benchmarking es/parser/yui: Collecting 100 samples in estimated 5.1639 s (1100 iterations)
Benchmarking es/parser/yui: Analyzing
es/parser/yui           time:   [4.6353 ms 4.6427 ms 4.6500 ms]
                        change: [-1.3978% -1.1575% -0.9441%] (p = 0.00 < 0.05)
                        Change within noise threshold.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild

heap stats:    peak      total      freed    current       unit      count
  reserved:  512.1 MiB  512.1 MiB  256.0 MiB  256.1 MiB                        not all freed!
 committed:  512.1 MiB  512.1 MiB  256.0 MiB  256.1 MiB                        not all freed!
     reset:   18.9 MiB  617.8 MiB  716.6 MiB  -98.8 MiB                        ok
   touched:      0          0       53.7 GiB  -53.7 GiB                        ok
  segments:     40        1.7 Ki     1.7 Ki       4                            not all freed!
-abandoned:      0          0          0          0                            ok
   -cached:      0          0          0          0                            ok
     pages:    1.9 Ki   950.5 Ki   950.4 Ki      28                            not all freed!
-abandoned:      0          0          0          0                            ok
 -extended:      0
 -noretire:      0
     mmaps:      0
   commits:      0
   threads:     10         10          0         10                            not all freed!
  searches:     0.0 avg
numa nodes:       1
   elapsed:      93.922 s
   process: user: 117.499 s, system: 1.368 s, faults: 0, rss: 348.1 MiB, commit: 512.1 MiB

new
Gnuplot not found, using plotters backend
Benchmarking es/parser/colors
Benchmarking es/parser/colors: Warming up for 3.0000 s
Benchmarking es/parser/colors: Collecting 100 samples in estimated 5.0511 s (343k iterations)
Benchmarking es/parser/colors: Analyzing
es/parser/colors        time:   [14.577 us 14.599 us 14.619 us]
Found 15 outliers among 100 measurements (15.00%)
  2 (2.00%) low severe
  8 (8.00%) low mild
  1 (1.00%) high mild
  4 (4.00%) high severe

Benchmarking es/parser/angular
Benchmarking es/parser/angular: Warming up for 3.0000 s
Benchmarking es/parser/angular: Collecting 100 samples in estimated 5.2742 s (700 iterations)
Benchmarking es/parser/angular: Analyzing
es/parser/angular       time:   [7.3220 ms 7.3385 ms 7.3574 ms]
Found 5 outliers among 100 measurements (5.00%)
  3 (3.00%) high mild
  2 (2.00%) high severe

Benchmarking es/parser/backbone
Benchmarking es/parser/backbone: Warming up for 3.0000 s

Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 5.3s, enable flat sampling, or reduce sample count to 60.
Benchmarking es/parser/backbone: Collecting 100 samples in estimated 5.3065 s (5050 iterations)
Benchmarking es/parser/backbone: Analyzing
es/parser/backbone      time:   [1.0401 ms 1.0424 ms 1.0449 ms]
Found 2 outliers among 100 measurements (2.00%)
  1 (1.00%) high mild
  1 (1.00%) high severe

Benchmarking es/parser/jquery
Benchmarking es/parser/jquery: Warming up for 3.0000 s
Benchmarking es/parser/jquery: Collecting 100 samples in estimated 5.1912 s (900 iterations)
Benchmarking es/parser/jquery: Analyzing
es/parser/jquery        time:   [5.6627 ms 5.6741 ms 5.6878 ms]
Found 3 outliers among 100 measurements (3.00%)
  1 (1.00%) high mild
  2 (2.00%) high severe

Benchmarking es/parser/jquery mobile
Benchmarking es/parser/jquery mobile: Warming up for 3.0000 s
Benchmarking es/parser/jquery mobile: Collecting 100 samples in estimated 5.4269 s (600 iterations)
Benchmarking es/parser/jquery mobile: Analyzing
es/parser/jquery mobile time:   [8.8280 ms 8.8448 ms 8.8632 ms]
Found 3 outliers among 100 measurements (3.00%)
  1 (1.00%) high mild
  2 (2.00%) high severe

Benchmarking es/parser/mootools
Benchmarking es/parser/mootools: Warming up for 3.0000 s
Benchmarking es/parser/mootools: Collecting 100 samples in estimated 5.2561 s (1200 iterations)
Benchmarking es/parser/mootools: Analyzing
es/parser/mootools      time:   [4.3202 ms 4.3263 ms 4.3338 ms]
Found 4 outliers among 100 measurements (4.00%)
  3 (3.00%) high mild
  1 (1.00%) high severe

Benchmarking es/parser/underscore
Benchmarking es/parser/underscore: Warming up for 3.0000 s
Benchmarking es/parser/underscore: Collecting 100 samples in estimated 9.0092 s (10k iterations)
Benchmarking es/parser/underscore: Analyzing
es/parser/underscore    time:   [885.26 us 885.94 us 886.73 us]
Found 15 outliers among 100 measurements (15.00%)
  6 (6.00%) high mild
  9 (9.00%) high severe

Benchmarking es/parser/three
Benchmarking es/parser/three: Warming up for 3.0000 s
Benchmarking es/parser/three: Collecting 100 samples in estimated 7.4926 s (300 iterations)
Benchmarking es/parser/three: Analyzing
es/parser/three         time:   [24.556 ms 24.601 ms 24.655 ms]
Found 10 outliers among 100 measurements (10.00%)
  5 (5.00%) high mild
  5 (5.00%) high severe

Benchmarking es/parser/yui
Benchmarking es/parser/yui: Warming up for 3.0000 s
Benchmarking es/parser/yui: Collecting 100 samples in estimated 5.3691 s (1200 iterations)
Benchmarking es/parser/yui: Analyzing
es/parser/yui           time:   [4.4508 ms 4.4587 ms 4.4672 ms]
Found 2 outliers among 100 measurements (2.00%)
  2 (2.00%) high mild

heap stats:    peak      total      freed    current       unit      count
  reserved:  512.1 MiB  512.1 MiB      0      512.1 MiB                        not all freed!
 committed:  512.1 MiB  512.1 MiB      0      512.1 MiB                        not all freed!
     reset:    7.6 MiB  992.8 MiB    1.0 GiB -111.6 MiB                        ok
   touched:      0          0       22.9 GiB  -22.9 GiB                        ok
  segments:     39        1.0 Ki     1.0 Ki       5                            not all freed!
-abandoned:      0          0          0          0                            ok
   -cached:      0          0          0          0                            ok
     pages:    1.9 Ki   436.0 Ki   436.0 Ki      28                            not all freed!
-abandoned:      0          0          0          0                            ok
 -extended:      0
 -noretire:      0
     mmaps:      0
   commits:      0
   threads:     10         10          0         10                            not all freed!
  searches:     0.0 avg
numa nodes:       1
   elapsed:      94.360 s
   process: user: 108.495 s, system: 1.196 s, faults: 0, rss: 255.0 MiB, commit: 512.1 MiB

little suggestion, you could use https://github.com/BurntSushi/critcmp, which could make your benchmark comparison more
neat.


Clarify what is meant by "worker" in the concurrency throttles section

Opening this issue ticket as per discussion on Microsoft Learn Q&A with @mike-urnun-msft and @davidmrdavid.
Please edit the concurrency throttles section and any other relevant parts to clarify that the worker in that context means a VM and not language worker.
See the discussion for more details, please.

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

ID: afd094d0-fb49-e206-2f99-c3fec27bb20f
Version Independent ID: 42fd1479-2478-3137-b43e-da13a4c10a48
Content: Performance and scale in Durable Functions - Azure
Content Source: articles/azure-functions/durable/durable-functions-perf-and-scale.md
Service: azure-functions
Sub-service: durable
GitHub Login: @cgillum
Microsoft Alias: azfuncdf

@Jan-Kowalik-mulberryrisk Thanks for opening this issue following our discussion on the MS Q&A post. We'll review the doc and update accordingly.
related: #47764


Doesnt work at all on fresh server

Describe the bug
For us the mod doesn't work at all. Just installed a 47.1.30 Forge server and get tons of errors that all the fabric stuff requires Forge 47.1.3
Steps to reproduce

Setup a fresh Forge server
Install connector and api
Enjoy your crash
...

Logs
https://pastebin.com/raw/bqbakike
Additional context
Apparently there is a problem with the fact that the server uses 47.1.30 instead of 47.1.3
However there is no version like this available on the Forge website.

  I didn't know .3 actually means 3, would have expected this to be 47.1.03 then.


Implement test number 7 of negotiateIncoming

Issue #6 explains 12 different tests.
Close this issue once test number 7 on the list has been implemented.

This should have been resolved automatically by the PR, but apperently this feature doesn't work for me. Anyway, this is solved now.


Content seems outdated, images and descriptions are incorrect

None of this seems to match what I see.  For example, steps 2/3 say to go to audit logs, but that's not listed.  Instead of what's in the screenshot, I see:
Usage metrics
Users
Tenant settings
Capacity settings
Embed Codes
Organization visuals
Workspaces

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

ID: a0e8bce0-95c1-07f7-d3a3-a1c22bd21f29
Version Independent ID: dddd1e30-4a88-1293-1264-3214cc4b6dc8
Content: Using auditing within your organization - Power BI
Content Source: powerbi-docs/service-admin-auditing.md
Service: powerbi
GitHub Login: @mgblythe
Microsoft Alias: mblythe

@jordanmills Thanks for your comment. We’ve forwarded your feedback to the writer, who should respond to this thread. Thanks!

@jordanmills - the screen is slightly out of date (Manage users should be Users) but mostly I just truncated the list on the left. Do you have the perms required to view audit logs: https://docs.microsoft.com/en-us/power-bi/service-admin-auditing#requirements?

@jordanmills - I confirmed that Audit logs tab should show up in the UI if you have Power BI admin perms. You might find a solution in the Power BI Community. If not, try our support page.


Setup gitter community

It would be good to have a few gitter channels for things such as support, general discussion, and what not.

I was thinking about doing this, but wasn't sure if there were enough users to bother. haha. but yeah, it's probably a good idea now that a few people are starting to contribute. I'll try to create one tonight.

I actually just went ahead and made it just now.
https://gitter.im/redux-most
We should add a link to it in the README soon.

@jshthornton looks like it forked the repo to add a badge or something, but I don't see the bade in their fork. do you know how that works?

You should just be able to use this
https://img.shields.io/gitter/room/nwjs/nw.js.svg
Then add a link to it.


Consider using the escalate verb for RBAC resources in the operator roles

In addition to the permissions the operator needs to run, the operator is currently also granted all the permissions that are needed by gatekeeper because the operator creates the RBAC resources for gatekeeper itself: https://github.com/font/gatekeeper-operator/blob/3c4a16d9356ec9bf8a4d738c86b1a28104c73a86/controllers/gatekeeper_controller.go#L96-L117
Without this, K8s issues a privilege escalation error.
Instead of granting all the same individual permissions that gatekeeper needs, we could explicitly allow specifying any permission in a Role or ClusterRole by giving the operator permission to perform the escalate verb on roles or clusterroles resources.

It's best to grant all the same individual permissions that gatekeeper needs and nothing more, instead of relying on the escalate verb that could pose more privilege escalation issues.


Update libp2p to 0.39 [WIP]

Summary of changes
Changes introduced in this pull request:

Update libp2p to 0.39
Refactor most of the project to use forest_libp2p instead of libp2p so it has to be changed in fewer places
... do something regarding bitswap, idk

Reference issue to close (if applicable)

Closes #1182
Other information and links

replaced by #1243


Enable channels and devices corresponding lists in backend

Currently devices connected to channels are kept in a channel entity list. It poses however the problem for apps and UI to get a list of channels to which one device is connected to, as devices do not keep corresponding list.

are we going to add things/{thing_id}/channels endpoint and  /things response will contain the channels as well?
As one thing can be connected with many channels, it may happen that the response is too big and in some cases contains not needed data. It would be nice if we add a parameter to all exposed apis which will define which entity fields should be contained in the response. I'll create an issue about this

I was thinking at one point maybe to have a separate entity connection that would be just a mapping table of things and channels that are inter-connected... But maybe this is an overkill.

I am not sure it is bug or not but i recently installed recent version i.e 0.7.0. I have created two users and channel information is exposed among different Users. Although user cannot add or delete devices from channel but I think it suppose to stick with user and should not expose to other users.

@drasko adding separate entity would be ok. IMO adding a separate endpoint like /connections/{thing_id} would be an overkill, except in cases where the user wants to get all his/hers connections.
I think most of the time the questions are: Which channels is this thing connected to? and Which are the zhings connected to this channel?
I think the best way to solve this is to add a new endpoint to the things and channels as follows:

/things/{thing_id}/connections
/channels/{channel_id}/connections


Bump Camel to 4.4.0.redhat-00002

We should align with the productized 4.4.0 release of camel-sap too.


rpm package please

rpm package please

:+1:

+1

I'd be glad to assist anyone willing to integrate my spec into the brackets build process, but since I don't use Brackets anymore, I have no interest in doing so myself.

+1

@jgillich what do you use instead? I am looking for something on Fedora with live preview

@fduraibi VS Code

@jgillich I will be glad to package it to Fedora (in my copr)


[Feature request] Menu features

New version mean maybe menu improvements

Subtitle with count of options
Trigger a callback when select an option

In vrpex I made something like :
local menudata = {}
menudata.name = "My Menu"
menudata.subtitle = "Subtitle"
menudata.css = {top = "75px", header_color = "rgba(0,255,0,0.75)"} -- exhaustive list

menudata.onclose = function(player)
  print("menu closed")
end

menudata.onselected = function(player,choice)
  print(choice ... "selected")
end

That's very usefull to preview clothes, tattoos and more.
Maybe add a new mod in 2 but not very cool because you are not always checking for mods.

Add list option on the right of the menu

local parentMenu = {
  name="Title",
  subtitle="Subtitle",
  css={top = "25%", header_color="rgba(255,125,0,0.75)"}
}

local items = {"Benjamin", "Daniel", "Joshua", "Noah", "Andrew", "Juan", "Alex"}
local father = 1

parentMenu["Item"] = {function(player,choice,mod)
  if mod == 1 then
    if father >= #fathersNames then father = 1
    else father = father + 1 end
  elseif mod == -1 then
    if father <= 1 then father = #fathersNames
    else father = father - 1 end
  end
  -- actualize every time the list on right
  vRPclient.actualizeMenuList(player,items[father])
end,"Description", {"list", items[1]}}

If it seems relevant to you, you probably find a better way to do that. Of course I changed HTML structure and more.
Sadly I do not have a screen with list example but the list is placed at the same place as the count of options. By default in the example this is displayed "< Benjamin >". If you press right "< Daniel >".

This is a vrpex menu.

If there is too much options like 8 or more hide the others and show an icon on the bottom of the menu to feedback there is more options

Best regards, continue your great work, as always!

Hi, the menu has already been reworked, you can see the new version in modules/gui.lua (dev).

subtitle: the menu system aim to be simple as possible, so I don't know about a subtitle option, but all string parameters are HTML, so you can actually make a subtitle using the menu title
options count: this is a client-side feature, it may be added to the default menu, but anyway the new version will allow to implement custom client-side menu so menu resources can be made without modifying the core files (using events and vRP.EXT.GUI methods)
select callback: easy to add, will probably be added, will not be a modulation, as you said this is more suited as a menu event and the new menu version already has an event system
list option: I don't understand the idea, can you clarify ?

Thanks for the answer.
Just like the GTA:Online list option :

Will be great if we can implement custom client-side menu.

The menu is not a key => value based, but action based, so this can't be done directly. But it may be done by updating dynamically options data.

Added some of the discussed features: https://github.com/ImagicTheCat/vRP/commit/b10c9894e19fdbc033766b9f70777200125773af

Very nice!  Thanks to take into consideration feedbacks/ideas/suggestions from vrp users.
Also I thought about something:
Add events when an item is added/removed from the inventory so you can actualize the inventory menu if open so you don't have to reopen it.
For further extensions (ex: drop item on the ground and someone else can take it).

Problem with this feature is that it can be annoying to look inside your inventory while harvesting something (and currently the inventory cursor is not saved).

Yeah true, didn't thought about that.


[BUG] analytical-java:

test_java.tar.gz
Describe the bug
I was verifying the process of a Java custom algorithm. Using the official graphscope-dev image, I compiled the Traverse code from the 0.26.0 version of grape-demo and successfully created a jar package. However, an error occurred when running it.
To Reproduce
Steps to reproduce the behavior:

Download attach file: test_java.tar.gz
prepare graphscope-dev docker
mvn clean install
run test.py

output message

Environment (please complete the following information):

GraphScope version: [0.26.0]
OS: [Linux--graphscope-dev:latest]

Additional context
Add any other context about the problem here.

Thanks for using GraphScope Analytical Java! Let me try to reproduce the problem.


DTS documentation

Re-work the introductory sections of the devicetree documentation, adding several figures and cross-references to other useful parts of the documentation.
If these changes are agreeable, I'd like to use them as a starting point to:

more formally specify the bindings+dts --> scripts --> C process. This is currently mostly documented by example in dts/binding-template.yaml and the end of doc/guides/dts/index.rst.
include API documentation for dtlib and edtlib in the docs themselves, similarly to https://docs.zephyrproject.org/latest/guides/west/west-apis.html#west-apis

My ultimate goal after that is to move on to make some changes to the way phandle+specifier-valued properties are currently managed by edtlib (and its gen_defines.py user).

Note that the figures are included in the docs via their .PNGs to ensure the presentation is as expected. I've included the .SVGs just to make it easier for future editors. These were all generated using draw.io.

I'm curious what issues you found that made you use .png files instead of just directly using the .svg drawings?

Thanks for the review @dbkinder!

I'm curious what issues you found that made you use .png files instead of just directly using the .svg drawings?

Unexpected line wrapping in lines of text inside boxes were a particular problem for me on Firefox.

Also, @mbolivar I think it would be good to add a bit more info about the following:

generated_dts_board.h, which is referred to in several places, does not really exist. Instead we have ./include/generated/generated_dts_board_fixups.h and ./include/generated/generated_dts_board_unfixed.h. This is very confusing to me and I feel we are lacking clarification.

The contents of generated_dts_board.h are not mentioned either. We should explain what kind of macros users should expect to be generated there, since this would help those users puzzled to see a build failure mention DT_INST_<> for example.

generated_dts_board.h, which is referred to in several places, does not really exist as a build product. Instead we have ./include/generated/generated_dts_board_fixups.h and ./include/generated/generated_dts_board_unfixed.h. This is very confusing to me and I feel we are lacking clarification.

@carlescufi I've tried to improve this in "input and output files".

The contents of generated_dts_board.h are not mentioned either. We should explain what kind of macros users should expect to be generated there, since this would help those users puzzled to see a build failure mention DT_INST_<> for example.

This is follow-up work under the "more formally specify the bindings+dts --> scripts --> C process" umbrella, so I'd like to defer it until after this PR.

@ulfalizer comments addressed, thanks again for review.


[QUERY] Possibility to Query Azure Blob in a Container with Page and Index

Library name and version
Azure.Storage.Blobs 12.2.0
Query/Question
Can I query blobs on a container to a specific page and length?
For instance, I want to go to the 5th page by taking only 10 rows of blobs.
Here is the current function I use on the SDK, but it seems to get all the pages from the beginning.
Pageable<BlobItem> results = containerClient.GetBlobs();
I'm also curious about how the blob is indexed in the container. Does it have any ordered numbers that I can use for indexing?
Environment
Environment: .NET 6.0 with Visual Studio 2022

@wlazuardi You could use the GetBlobsAsync() and AsPages() methods together to get pages one by one and loop over them (since they are iterable) until the page you need.
You can't go to a particular page by number but can do so if you have the continuation token for the page before it.

@PramodValavala-MSFT alright, thanks for the explanation. It would be great if I can go to a specific page by using the page number.


Fix decimal and negative numbers plural in French

In French (and many Latin-like languages),
0 is singular
0.5 is singular
-1 is singular
1.5 is singular
-4 is plural
So this PR fixes all those broken cases
If n is supposed to be integer and positive, please provide some advice about how to handle properly decimal number, such as:

Language
1
1.5
2

English
liter
liters
liters

French
litre
litre
litres

thanks! Sorry for the late merge. Will update dependent packages ASAP.

thanks! Sorry for the late merge. Will update dependent packages ASAP.

Versions for plural-forms, ttag, babel-plugin-ttag and ttag-cli are updated.

Versions for plural-forms, ttag, babel-plugin-ttag and ttag-cli are updated.


feature request

Have you looked at what it would take to run in docker swarm? has anyone tried yet?

I am running PostDock as docker swarm, it's easy to set up.
version: '3.6'
services:
pgmaster:
image:
environment:
REPLICATION_PASSWORD: replication_pass
CLUSTER_NAME: pg_cluster
CONFIGS_DELIMITER_SYMBOL: ;
REPMGR_WAIT_POSTGRES_START_TIMEOUT: '270'
CLUSTER_NODE_NETWORK_NAME: pgmaster
CLEAN_OVER_REWIND: '0'
REPLICATION_USER: replication_user
LOG_LEVEL: DEBUG
NODE_PRIORITY: '100'
REPLICATION_PRIMARY_HOST: pgmaster
POSTGRES_PASSWORD: pw
PARTNER_NODES: pgmaster,pgslave1,pgslave2
SSH_ENABLE: '1'
NODE_NAME: pgmaster
POSTGRES_DB: tvmid_core
NODE_ID: '1'
CONFIGS: listen_addresses:'*';max_replication_slots:5;max_connections:1000;log_destination:'stderr'
REPLICATION_DB: replication_db
POSTGRES_USER: user
ports:
- 5441:5432
volumes:
- pgmaster:/var/lib/postgresql/data
configs:
- source: postdock_ssh_entrypoint
target: /home/postgres/.ssh/entrypoint.sh
secrets:
- source: postdock_id_rsa
target: id_rsa
- source: postdock_id_rsa_pub
target: id_rsa.pub
networks:
- backend
logging:
driver: json-file
deploy:
placement:
constraints:
- node.hostname ==
  pgpool:
	image: <url>
	environment:
	  WAIT_BACKEND_TIMEOUT: '60'
	  CHECK_PGCONNECT_TIMEOUT: '3'
	  CHECK_PASSWORD: pw
	  REQUIRE_MIN_BACKENDS: '2'
	  PCP_USER: pcp_user
	  PCP_PASSWORD: pcp_pass
	  BACKENDS: '0:pgmaster:5432:1:/var/lib/postgresql/data:ALLOW_TO_FAILOVER,1:pgslave1:5432:::,3:pgslave2:5432:::'
	  SSH_ENABLE: '1'
	  CONFIGS: num_init_children:250,max_pool:4
	  CHECK_USER: user
	  DB_USERS: user:pwd
	ports:
	 - 5430:5432
	 - 9898:9898
	configs:
	  - source: postdock_ssh_entrypoint
	    target: /home/postgres/.ssh/entrypoint.sh
	secrets:
	  - source: postdock_id_rsa
	    target: id_rsa
	  - source: postdock_id_rsa_pub
	    target: id_rsa.pub
	networks:
	 - backend
	logging:
	  driver: json-file

  pgslave1:
	image: <url>
	environment:
	  CONFIGS_DELIMITER_SYMBOL: ;
	  CLUSTER_NODE_NETWORK_NAME: pgslave1
	  CLEAN_OVER_REWIND: '1'
	  LOG_LEVEL: DEBUG
	  REPLICATION_PRIMARY_HOST: pgmaster
	  PARTNER_NODES:  pgmaster,pgslave1,pgslave2
	  SSH_ENABLE: '1'
	  NODE_NAME: pgslave1
	  NODE_ID: '2'
	  CONFIGS: max_replication_slots:10;max_connections:1000;log_destination:'stderr'
	ports:
	 - 5442:5432
	volumes:
	 - pgslave1:/var/lib/postgresql/data
	configs:
	  - source: postdock_ssh_entrypoint
	    target: /home/postgres/.ssh/entrypoint.sh
	secrets:
	  - source: postdock_id_rsa
	    target: id_rsa
	  - source: postdock_id_rsa_pub
	    target: id_rsa.pub
	networks:
	 - backend
	logging:
	  driver: json-file
	deploy:
	  placement:
	    constraints:
	     - node.hostname == <MyHostName>

  pgslave2:
	image: <url>
	environment:
	  CONFIGS_DELIMITER_SYMBOL: ;
	  CLUSTER_NODE_NETWORK_NAME: pgslave2
	  CLEAN_OVER_REWIND: '1'
	  LOG_LEVEL: DEBUG
	  REPLICATION_PRIMARY_HOST: pgmaster
	  PARTNER_NODES: pgmaster,pgslave1,pgslave2
	  SSH_ENABLE: '1'
	  NODE_NAME: pgslave2
	  NODE_ID: '3'
	  CONFIGS: max_replication_slots:10;max_connections:1000;log_destination:'stderr'
	ports:
	 - 5443:5432
	volumes:
	 - pgslave2:/var/lib/postgresql/data
	configs:
	  - source: postdock_ssh_entrypoint
	    target: /home/postgres/.ssh/entrypoint.sh
	secrets:
	  - source: postdock_id_rsa
	    target: id_rsa
	  - source: postdock_id_rsa_pub
	    target: id_rsa.pub
	networks:
	 - backend
	logging:
	  driver: json-file
	deploy:
	  placement:
	    constraints:
	     - node.hostname == <MyHostName>

  backup:
	image: <url>
	environment:
	  BACKUP_SCHEDULE: '*/30 */5 * * *'
	  POSTGRES_DB: <db_name>
	  POSTGRES_PASSWORD: <pw>
	  POSTGRES_USER: <user>
	  REPLICATION_HOST: pgmaster
	  REPLICATION_PASSWORD: replication_pass
	  REPLICATION_USER: replication_user
	  SSH_ENABLE: '1'
	volumes:
	 - backup:/var/backups
	configs:
	  - source: postdock_ssh_entrypoint
	    target: /home/postgres/.ssh/entrypoint.sh
	secrets:
	  - source: postdock_id_rsa
	    target: id_rsa
	  - source: postdock_id_rsa_pub
	    target: id_rsa.pub
	networks:
	 - backend
	logging:
	  driver: json-file
	deploy:
	  placement:
	    constraints:
	     - node.hostname == <MyHostName>

	volumes:
	  pgmaster:
	  pgslave1:
	  pgslave2:

	configs:
	  postdock_ssh_entrypoint:
	    file: ./configs/psql/ssh/entrypoint.sh

	secrets:
	  postdock_id_rsa:
        file: ./secrets/id_rsa
 	  postdock_id_rsa_pub:
		file: ./secrets/id_rsa.pub`

Config file I use
`#!/usr/bin/env bash
set -e
cp -f /run/secrets/* /home/postgres/.ssh/ || echo 'No pre-populated ssh keys!'
chown -R postgres:postgres /home/postgres/.ssh/id_rsa
chown -R postgres:postgres /home/postgres/.ssh/id_rsa.pub
if [[ "$SSH_ENABLE" == "1" ]]; then
echo '>>> TUNING UP SSH CLIENT...'
if [ ! -f "/home/postgres/.ssh/id_rsa.pub" ] && [ ! -f "/home/postgres/.ssh/id_rsa" ]; then
echo ">>>  There are no ssh keys - SSH daemon can not be enabled!"
exit 1
fi
chmod 600 -R /home/postgres/.ssh/id_rsa

mkdir -p /var/run/sshd && sed -i 's/PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config
sed 's@session\s*required\s*pam_loginuid.so@session optional pam_loginuid.so@g' -i /etc/pam.d/sshd
echo "export VISIBLE=now" >> /etc/profile

cat /home/postgres/.ssh/id_rsa.pub >> /home/postgres/.ssh/authorized_keys

echo '>>> STARTING SSH SERVER...'
/usr/sbin/sshd 2>&1

else
echo ">>> SSH is not enabled!"
fi
`

Hi @paunin ,
Supporting swarm secrets would go a long way into facilitating this. Right now every configuration element has to be defined as an environment variable without any way to load anything from file (afaik).

I'd be interested in a simple example how to start a cluster in docker swarm with like 3 nodes or something. The PostDock looks like it is the best available thing and also well structured.


⚠ Bofrost.de has degraded performance

In d088cdc, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1573 ms

Resolved: Bofrost.de performance has improved in 7c60608 after 311 days, 21 hours, 42 minutes.


Adding npm update in update workflow

This updates transitive dependencies (even if direct dependencies did not change).

@fbasso Thank you for your review!


Doc fixes

Fixed INSTRUCTIONS.md to show how to get models in a systematic way.
Added env variable detection for GENEONTOLOGY_CATALOG and MINERVA_MAVEN_OPTS to deal with faster cached behavior and offline code.berkeleybop.org, respectively.
Added some scripts that might be helpful to future Minerva-nauts.
Enabled more logging.
Ensure that the tests respect the GENEONTOLOGY_CATALOG env var, which massively speeds up unit tests.
Adds --help and --version commands to CLI.

Adds Angular-based test for Minerva.

I'm all in favor for improvements of the tests and documentation.
But I don't like to pollute the batch handler. It's already a beast and adding yet another aspect makes it more complicated. It would like to see status (and maybe more management later) as a separate interface and implementation. This should also help to remove all the fake-id stuff and using the error code path to return the status result.

Agreed, Heiko. It's leftover from when I was doing memory testing. I think every webapp should have a /status endpoint, but this one belongs elsewhere. I will either remove it or relocate it (the m3BatchStatus endpoint). Don't merge the PR until I fix it.

I added a StatusHandler.java and moved the m3BatchStatus into there. I broke it up into two endpoints, a /status endpoint that returns TEXT and a /memstatus endpoint that returns JSON. In both cases, the actual content is just a pre and post-GC memory dump. I will expand upon this as needed (e.g., version, timestamp, config).

@DoctorBud We've been moving towards a more uniform format for our service statuses; not finished yet, but with an eye towards slotting into a general monitor later on and having possibly a uniform access/response library. For example:
http://noctua.berkeleybop.org/status
http://barista.berkeleybop.org/status
It would be nice to use those as a template, at least for /status.

What does standard mean here? The payload isn't very self-explanatory, no link to a schema.
Seems to be roughly the same json schema as:
http://monarchinitiative.org/status
But the schema is really just a property-value model.
If we're serious about having a standard payload, then shouldn't we either de-reify the properties so they are json properties, or have a standard ontology of annotation properties

@cmungall Yes, they're all related. I can't find all the discussion, but the start of adding it to monarch is here: https://github.com/monarch-initiative/monarch-app/issues/630
The idea would be to get /status more-or-less the same everywhere--a JSON blob of similar structure. When we first discussed this it was in the context of enabling easy uniform service monitoring with a little sugar. I think having an ontology of annotation properties would be overkill.

This PR is sort of non-essential and was motivated by my early attempts to debug and figure out Minerva. Now that I have grokked Noctua/Barista/Minerva and have a new place to put the WebPhenote customizations, I may just leave this hanging until I need to debug Minerva again. Some of the features that might be salvageable include:

Unit tests can now use a catalog.xml for faster throughput via an environment variable.
There's a /status endpoint
There's a --version and a --help option, but they don't do much.
The documentation is improved in some ways, but may be distracting in terms of how to obtain the proper mirrored OWL models. I've learned much since I wrote this stuff.

@DoctorBud I started refactoring the tests to use only minimal modules (removing dependency on loading go-lego over the wire), and a catalog #48
I'll take a look the doc stuff and see what can be moved over - docs are always welcome.
I'll leave it to you and @kltm and later @balhoff what is required re /status endpoint


Updated prettier formatting in all packages, and formatted code

added lint checks, which are failing
formatted code

Current dependencies on/for this PR:

main

PR #359

PR #360   👈

This stack of pull requests is managed by Graphite.


Added typings. Corrected bluetooth.ReadResult field name.

To package.json added "typings": "bluetooth.d.ts" line.
In bluetooth.d.ts, ReadResult type corrected: changed valueDecoded to valueRaw.

Sweet, much better!


Fix config overriding entire env object

What was changed

Change env key from interface{} to a map
Why?

starts adding keys to an env instead of overriding entire thing
Checklist

Closes

How was this tested:

Any docs updates needed?

adding tests in a separate PR


Bug 1981784: fix Deployment creates a huge number of ReplicaSets

backport of #50

/bugzilla refresh

/bugzilla refresh

(patch manager)
rare, but bad impact. 0.9


Mac OSX & Windows fixes, clean up default['ark']['tar'] setting

These same changes are on master and will ship with the 0.10 release


Support swapping out routers (IPFS react router, HashRouter...)

Have you read the Contributing Guidelines on issues?

[X] I have read the Contributing Guidelines on issues.

Description
I suggest that we explore ways to make Docusaurus deployment to IPFS possible.
At the moment, the main blocker is the baseUrl that cannot be precomputed before the website is deployed.
I tried using Piñata to deploy the build folder to IPFS and got an error

We suggest trying baseUrl = /ipfs/QmUsHzX.....BdPd/

Has this been requested on Canny?
No response
Motivation
IPFS is a decentralised and very price competitive storage system
API design
No response
Have you tried building it?
No response
Self-service

[X] I'd be willing to contribute this feature to Docusaurus myself.

Hi, Docusaurus uses the base URL to build your site and pre-generate certain static HTML, so it would be non-trivial to support this use-case. Could you tell me:

How does IPFS determine the base URL? Is it totally random, or is it a hash? Does it change per deployment, or is it only assigned once?
If we support dynamic base URL that can be injected post-build, what kind of API do you envision so you can actually inject the base URL into the built bundle, which is all HTML and minified JavaScript?

Note that as stated multiple times in the issue template, we expect the issue to be very detailed and well-thought, not a random feature request. Please use the Canny board for that.

Upon uploading content (in this case the build folder) to an IPFS node, the resulting URL is the hash of the uploaded files. Being an immutable filesystem, the hash works both as a pointer to the document and as an anti-tampering system. Deployment of the same exact file(s) will yield the same URL, as hashes are deterministic.
We could try to use ipfs-react-router module to take care of the base URL. Injecting the URL ex-post would not be doable as content on IPFS cannot be edited.

Note that we aren't using the React router basename feature yet and base URL is handled a bit hackily now, which has caused problems like #6462, #6315, and #6294. If we are to support an alternative router, we have to make sure basename is supported first. And that would probably be after we've migrated to React router v6.

Supporting swappable routers is probably a good way to support IPFS without introducing destructive changes to the codebase. I used the aforementioned react ipfs router in the past and it worked pretty well as a solution to deploying an app without knowing the URL beforehand.

Please assume I have 0 knowledge of IPFS (which is not totally untrue 😅)
Why do you want that?
How would it work?
Do you have examples of other open-source SSG SPAs being deployed to IPFS (Gatsby, Next, Jekyll, Eleventy, whatever...?) that we could inspect?

IPFS - the interplanetary file system - is a distributed network of independent nodes that offer data storage and replication for immutable data, it can be multimedia, PDFs or websites too.
For static website generators like the ones you mention, the build folder containing compiled artefacts is uploaded to an IPFS node and then served to the open public using its hash, called CID, as URL (in the form of ipfs://CID, or accessible using a public HTTP gateway like https://gateway.ipfs.io/ipfs/CID).
An example of apps deployed to IPFS is the Uniswap frontend

Note, you can see by yourself if you disable JS that the Uniswap app is not a static app. It is entirely generated on the client side

Business value of IPFS hosting is cheaper hosting price, redundancy and data immutability. Some people then use Cloudflare to connect a custom DNS to the IPFS route for better UX.
Uniswap frontend is a ReactJS app, it is dynamically generated as it interacts with the blockchain.
Considering your point it seems Docusaurus isn't fit for a content distribution system like IPFS

From what I researched, build for create-react-app does not work with IPFS too. But putting "homepage": "./", in package.json works. Thus, I think it's just about pathing.
So I did the same thing for build files for docusaurus. For example, I changed "/assets/..." to "./assets/..." and it worked. I'm not sure why putting "homepage": "./", in package.json does not make the build files to relative path though. So I had to do it manually.

@mrkvn There's a plugin to do this. See https://github.com/facebook/docusaurus/issues/3825#issuecomment-911593835

@Josh-Cena Thanks. That'd be a big help. I'll check it.

@Josh-Cena Looks like it's not there anymore. Page not found. :(

This helped. #448 (comment)


Xoptfoil2 does not open

Hi!
I am trying to run Xoptfoil2 on my computer however I cannot make it open. I extracted all onto my desktop and try to run it. When I do so I get the "Windows protected yoour PC" message and after clicking on "Run anyway" nothing happens. I have tried it on 2 different computers one Windows 11 and one with Windows 10 and both does the same. Am I doing it wrong?
Thanks in advance!

Hello,
... did you just double click on 'Xoptfoil2' in the explorer?
If yes, then probably everything is fine: As Xoptfoil2 is a command shell program it is started and immediately finished because the input file is missing.
What happens, if you double click on one of the example batch files ('make.bat')?
(see also: https://jxjo.github.io/Xoptfoil2/docs/getting_started )
Best  regards
Jochen

I have indeed tried multiple of the included examples and all did this . I have tried it on a third computer and interestingly it worked there. Does Xoptfoil2 require Python or other dependencies?

... if you open a command shell, change directory to the installation directory and run 'Xoptfoil2' - what does then happen?

Absolutely nothing. I can immediately write a new command, no error message or anything

... could you please post a screenshot of the command shell where you enter 'Xoptfoil2"?

Here you are

... this is strange.
It seems, Xoptfoil2 need admin rights (little admin icon in program icon)
Could you run the command shell 'as administrator' and try again?

This seems to be working so Ill have to do this every time? because even if I run one of your examples as admin from the windows GUI it doesnt work.

... ah - step by step ...
Could you check:
In explorer, right click on 'Xoptfoil2', select 'properties', select the 'compatibility' tab - and uncheck this check box ...

I have tried it checked in and out as well, exactly the same reaction, aka. Nothing


Reoder down method. Fixes rollback issue

Fixes the below error:
Rollback option is not working due to this error:
SQLSTATE[2BP01]: Dependent objects still exist: 7 ERROR:  cannot drop table blog_categories because other objects depend on it
DETAIL:  constraint blog_posts_blog_category_id_foreign on table blog_posts depends on table blog_categories
HINT:  Use DROP ... CASCADE to drop the dependent objects too. (Connection: pgsql, SQL: drop table if exists "blog_categories")

Thank you @Summonshr


Update latest base images versions

Change-type: patch
Signed-off-by: Trong Nghia Nguyen<EMAIL_ADDRESS>

Please make sure to read the CONTRIBUTING document before opening the PR for relevant information on contributing to the documentation. Thanks!

@balena-ci retest

Interesting that this update now says that Node12 is the minimum supported version, yet one of the CI checks is named ResinCI/npm/linux-alpine-x86_64-node10 :wink:

@balena-ci I self-certify!

@balena-ci rebase


[0.3 pick] Update Ray versions in a few sample configs.

Why are these changes needed?

PR against 0.3 branch, isolates config changes from https://github.com/ray-project/kuberay/pull/486/
Updates Ray versions in a few config examples to Ray 2.0.0.
Useful since we refer to the KubeRay configs in the 0.3 release branch in new Ray docs.
We can work out cleaner versioning later.
Related issue number

Checks

[ ] I've made sure the tests are passing.
Testing Strategy

[ ] Unit tests
[ ] Manual tests
[ ] This PR is not tested :(

The idea here is to just make sure that examples in the Ray docs like the one here
https://docs.ray.io/en/master/serve/production-guide/kubernetes.html#deploying-a-serve-application
point to a stable location, with a config specifying Ray 2.0.0.


Additional diagnostics for certificate errors

Fixes #178

I'd trust the openssl docs over some random project. The best way to know for certain would be to run the application under Valgrind and make sure all the heap allocations are certain.

Ignore my comment, I was looking at the wrong variable. It's actually freeing the char* in that project. Sorry!

Looks good.


Imagenet dataset ?

Hi, thanks for your great job.
I wonder to know how can I get the right imagenet dataset you used for strategy search on mobilenet?

We used the regular ImageNet dataset. You can find more information here: http://image-net.org/download

@tonylins Did you mean the whole ILSVRC2012 dataset of ImageNet. I see that it very large dataset (about 150Gb for both training set and validation set). However, It is said in your AMC paper that you used use 3000 images from the training set to evaluate the reward function. So I just need to download 3000 image of the dataset ?
Thanks.

@tonylins Did you mean the whole ILSVRC2012 dataset of ImageNet. I see that it very large dataset (about 150Gb for both training set and validation set). However, It is said in your AMC paper that you used 3000 images from the training set to evaluate the reward function. So I just need to download 3000 image of the dataset ?
Thanks.

Although the author used only 3000 images for reward evaluation, about 15000(300*50) images from training set is needed to do weights regression during pruning kernel. What's more, you need the whole training set to finetune the pruned model. Thus it is necessary to download the whole  ImageNet2012 dataset I think.


UI-UX: remove clutter from sidepanel

Remove clutter from the plan tab. There is too much information at first, it needs better organization and better hierarchy. User should be able to choose more information when needed. Otherwise, it's noise.
Example of how it could be below from Roadtrippers. It's not 1:1 suitable to take over as it takes too much place but the general idea is good and very easy to understand. If needed I can deliver UI-UX for that part.

You appear to have created this issue in the wrong repository. The furkot organisation is as: https://github.com/furkot


Synchronize all permissions from OpenSearch

Description
We've noticed there are some permissions in OpenSearch that are not included in the UX dropdown of the security-dashboards-plugin
Issues Resolved

Related https://github.com/opensearch-project/security/issues/1461
Related https://github.com/opensearch-project/security-dashboards-plugin/pull/1323

Check List

[ ] New functionality includes testing
[ ] New functionality has been documented
[X] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Looks like this will be fixed once an artifact with https://github.com/opensearch-project/security/pull/2433 merged is available.

@peternied Please remove the changes to the documentation links.

Codecov Report

Merging #1325 (f30bdb8) into main (8e9c4b7) will not change coverage.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@           Coverage Diff           @@
##             main    #1325   +/-   ##
=======================================
  Coverage   71.78%   71.78%
=======================================
  Files          88       88
  Lines        2027     2027
  Branches      274      274
=======================================
  Hits         1455     1455
  Misses        509      509
  Partials       63       63

Impacted Files
Coverage Δ

public/apps/configuration/constants.tsx
85.71% <ø> (ø)

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

Oops! Deleted this branch on my fork, recreated in this pull request https://github.com/opensearch-project/security-dashboards-plugin/pull/1333


Document how the code is generated from the OpenAPI spec

Confirm this is not a feature request for the underlying OpenAI API.

[X] This is not a feature request for the underlying OpenAI API

Confirm this is not a feature request for Azure OpenAI.

[X] This is not a feature request for Azure OpenAI

Describe the feature or improvement you're requesting
In the README, it is stated that the client is generated from the OpenAPI specification.
Please document the process for doing this.

Yes, I would also be interested to know about this. It's a different approach than Kiota and others I know of.
We also maintain our own fully generated OpenAI SDK for LangChain.NET (https://github.com/tryAGI/OpenAI) with a series of extensions for convenience, and are not yet sure about switching to this if there are delays in updates (which we don't have because it is updated based on GitHub Actions automatically in most cases if there are no breaking changes)

It looks like the client is generated from the OpenAPI spec using AutoRest (doc)


bazel: update rules_rust

Signed-off-by: Keith Smiley<EMAIL_ADDRESS>

https://github.com/bazelbuild/rules_rust/issues/1330

LGTM when CI passes

5.0 is out https://github.com/envoyproxy/envoy/issues/21435

I threw that in here, but it still doesn't fix our issue, there's an open pr for it over there

@keith is it worth a try with 0.6.0?
https://github.com/bazelbuild/rules_rust/releases/tag/0.6.0


onExit firing even on step completion

Hello @HiDeoo, we are building a platform tour using this wrapper however, the onExit method is firing even after properly completing the steps with onComplete working normally.
Expected behavior:

If the tour is closed midway, fire exit event
If the tour is completed normally i.e., all steps traversed, fire complete event

Thanks for the feedback.
It looks like I'm not doing anything fancy regarding these callbacks as they're directly used with the default intro.js callbacks (onexit & oncomplete) so the current behavior is the default one when using intro.js.
I don't like the idea of potentially changing the behavior of these callbacks and differ from the default behavior of intro.js (even tho I think I agree with your expected behavior), altho, I pass down the stepIndex in the onExit() callback (which is a difference between this wrapper & intro.js) so it's fairly easy to figure out if the tour is complete using only this callback.


Remove auth tokens from query params and allow redefine Stream url

Refers to https://github.com/StackStorm/discussions/issues/242
From now on, you can explicitly tell client not to put auth tokens into query strings and instead rely on cookies (which hopefully going to be supported starting ST2 2.4). The noQueryTokens option is disabled by default for backwards compatibility and should be used at your own discretion and a level of healthy paranoia.

What would it take to enable this feature by default in st2web? Any roadblocks expected?
See: https://github.com/StackStorm/k8s-st2/issues/11 and https://github.com/StackStorm/discussions/issues/242#issuecomment-395814678
The entire practice of having the token in GET is flawed. Best timing to eliminate that issue in the app entirely.


Remove tests for active LRAs for non participating resources

There are two tests:
TckLRATypeTests#mandatoryWithClosedLRA
TckLRATypeTests#requiredWithClosedLRA

that check whether or not an implementation prohibits calling an @LRA annotated method (of a non-participating resource) if the LRA is no longer active (note that the tests do not register a participant). This behaviour is problematic for the following reasons:

it is unnecessary because it does not guarantee that an LRA will be valid when the JAX-RS method executes since an LRA can be closed at any time before and during the method invocation. The only way to guarantee validity of an LRA during a method invocation is to enlist with it. If the LRA is no longer active then the attempt to enlist with it will fail with 412 and that is good enough to write correct business logic.
it is impossible to implement correctly in a distributed environment for the previous reason (enlisting as a participant is the correct approach)
it incurs an unnecessary performance penalty due to the extra network call to get the status.
it is not a spec requirement (the closest text is in the javadoc for the LRA and we could add a note there to say that an LRA which is active before method entry can become inactive at an arbitrary point in time and that an attempt to enlist with an inactive LRA will fail although I think we already state this elsewhere).

NB the tests do make sense as long as the invoked resource is a participant.

+1 this makes sense. We can remove these two tests but we should add one testing join failure.

+1
I would expect to see the join test added at the same time as it should be prevented. Would that need additional text too?

I can understand that the test TckLRATypeTests#requiredWithClosedLRA is incorrect and should be removed.
But TckLRATypeTests#mandatoryWithClosedLRA is testing something valid. When you annotated the JAX-RS method with @LRA(type=MANDATORY) than you need to call it with a valid LRA id in the header, otherwise HTTP Status 412 must be returned (defined in the JavaDoc for LRA.Type.MANDATORY)

If an entity wants to know if the LRA is active then he must enlist as a participant

This is not required, as LRA party (by just using @LRA) you can also enforce things like REQUIRED, MANDATORY, etc ..)

If he chooses not to enlist then he must be prepared to handle the consequences.

Do we have this somewhere in the spec? (explicitly, because this is a very important aspect of the spec)
This does also mean that defining @LRA(Type=REQUIRED) doesn't guarantee that an LRA is started when it is not enlisted as participant!

Another point is that handling the following scenario is very tricky:

the implementation sees that the LRA is active and is about to invoke the method
some other entity in the system call end on the LRA
the method is invoked

The same is true for a participant, between the moment the decision is made that the participant can be enlisted and that the method is invoked, the LRA can already be changed and closed.

If an entity wants to know if the LRA is active then he must enlist as a participant

This is not required, as LRA party (by just using @lra) you can also enforce things like REQUIRED, MANDATORY, etc ..)

I'm not sure what you mean.
All I am saying is that if the method needs to know whether or not the LRA is active then it should enlist with it. If the LRA is inactive then the method will not be entered (since the spec says that 412 is thrown). If the LRA becomes inactive whilst the method is executing and if a business operation needs to know if the LRA is still active then it just check whether or not its compensate/complete method has been invoked.

If he chooses not to enlist then he must be prepared to handle the consequences.

Do we have this somewhere in the spec? (explicitly, because this is a very important aspect of the spec)

I think you have misunderstood my points. What I am saying is that if the business logic needs to know the state of the LRA then he should register as a participant.

This does also mean that defining @lra(Type=REQUIRED) doesn't guarantee that an LRA is started when it is not enlisted as participant!

I never said that. The implementation always obeys the @LRA annotation regardless of whether or not the resource has any participant annotations.

Another point is that handling the following scenario is very tricky:

the implementation sees that the LRA is active and is about to invoke the method
some other entity in the system call end on the LRA
the method is invoked

The same is true for a participant, between the moment the decision is made that the participant can be enlisted and that the method is invoked, the LRA can already be changed and closed.

It is not the same. In your example:

The method is about to be invoked
The participant is registered
The LRA becomes inactive
The resource is told that the LRA is finishing (since it was enlisted)
The method executes. The business logic will know whether or not the LRA became inactive since his compensate/complete method will trigger (either immediately or eventually). If it triggers before the method is entered then it should not perform its business logic under the protection of an LRA. If it triggers during the method invocation then the business logic needs coordinate with the logic in its compensate/complete method according to its business goals.

The LRA spec is not like other specs such as XA and JTA. The goal of LRA is simplicity and ease of use: all we are doing is providing a set of trigger points such that distributed entities are able to reliably coordinate their activities even though they may have no knowledge of each other.

Now I'm confused with the answers.
If you have JAX-RS endpoint which is annotated with @LRA(type=MANDATORY), then the current spec indicates that when the endpoint is called without an active context, 412 is returned.
There is no mentioning about that this logic only is valid for a participant or not. And it also doesn't help to define a @Compensate and/or @Complete since the participant can never be enlisted and thus those callback will never be called.
So I still doesn't see why the TckLRATypeTests#mandatoryWithClosedLRA test needs to be removed because it is incorrect.

Maybe the error is in the spec wording, perhaps it could be updated to specify that 412 is returned if the business logic defines itself as enlisting a participant and that timed out transactions may propagate though business calss?
We would need to be careful in the future that if LRAClient is reintroduced and if it allows enlisting a resource programmatically 412 refers to preconditions failing. In that case it seems more like a 500

Initially we were discussing the fact that when the JAX-RS endpoint method it would know if the LRA is still valid or not.
And it is indeed correct that although at the point the implementation decides it is valid, the method has no way of knowing if that is still the case.
But that is also the case for the participant scenario, with indeed a small difference. The @Complete method is called when the LRA is cancelled. But this callback can occur later and without verifying that this @Complete method has maybe called, the JAX-RS endpoint method code on its own has no idea if it still active or not.
And I guess developers will just execute the JAX-RS endpoint method in the assumption that the LRA is active. And if there is a need to 'rollback' then they will define it as a participant and perform the required compensating actions.
So if the method needs to know whether or not the LRA is active then it should enlist with it is not entirely correct. If the JAX-RS resource (the class) needs to know when a LRA is no longer active, it must register as participant (that is obvious) but a method (using the appropriate @LRA) should always assume the LRA is active.

Maybe we should have a meeting on this as part of the confusion/problem is probably the limitations of a text based discussion on a ticket.
Can we schedule this for October 28th?  @mmusgrov @xstefank @tomjenkinson @ochaloup

I put it on the agenda for the 28th (which is nearly two weeks in the future). We don't need to meet on a Monday if your unavailable then.

Now I'm confused with the answers.
If you have JAX-RS endpoint which is annotated with @lra(type=MANDATORY), then the current spec indicates that when the endpoint is called without an active context, 412 is returned.

If the caller does not provide a context when invoking a mandatory method it will receive a 412.
If the caller does provide a context and the target resource is a participant then the implementation will attempt to register it with the LRA. If the registration fails then an HTTP error code is returned to the caller (if the spec is not clear in this respect then we should add some text).
If the caller does provide a context and the target resource is not a participant this means the resource is not interested in participating. If it invokes a "downstream" resource which is interested in participating then the LRA will be checked at that point and any failure to enlist will be propagated back to the caller.

Therefore there is no benefit in validating LRAs for non-participating resources.

There is no mentioning about that this logic only is valid for a participant or not. And it also doesn't help to define a @compensate and/or @complete since the participant can never be enlisted and thus those callback will never be called.

If the resource contains @compensate and/or @complete annotations then the caller is immediately notified there is a problem before method entry since an error code is returned and the mandatory method does not execute.

Initially we were discussing the fact that when the JAX-RS endpoint method it would know if the LRA is still valid or not.

It is impossible to know whether an LRA is active at any single point in time (physics dictates that fact). But it is possible to discover the outcome of an LRA and that is what participating in LRA is for.

And it is indeed correct that although at the point the implementation decides it is valid, the method has no way of knowing if that is still the case.
But that is also the case for the participant scenario, with indeed a small difference. The @complete method is called when the LRA is cancelled. But this callback can occur later and without verifying that this @complete method has maybe called, the JAX-RS endpoint method code on its own has no idea if it still active or not.

The business method is only interested in knowing whether it needs to compensate for any actions it performs. If it is a participant then it will be told reliably about the outcome. If your concern is about protecting against the compensate method being called while the business method is executing then the resource must be coded with this in mind (a naive solution would be for the compensate method to block until the business method has completed).

And I guess developers will just execute the JAX-RS endpoint method in the assumption that the LRA is active. And if there is a need to 'rollback' then they will define it as a participant and perform the required compensating actions.

Correct.

So if the method needs to know whether or not the LRA is active then it should enlist with it is not entirely correct. If the JAX-RS resource (the class) needs to know when a LRA is no longer active, it must register as participant (that is obvious) but a method (using the appropriate @lra) should always assume the LRA is active.

No it can never assume the LRA is active for the full duration of the method execution: the LRA can be cancelled by any component of the distributed system at any time. But this is not a problem if it is a participant since it will be told when the LRA is terminating.

See #244 which will introduce that implementation is no longer required to validate LRAs (only participant enlistments) but is still allowed to do it.

See #244 which will introduce that implementation is no longer required to validate LRAs (only participant enlistments) but is still allowed to do it.

+1

@mmusgrov @rdebusscher Since in the end we agreed in #244 that non-participant will be prohibited this issue is no longer relevant. The mentioned tests will now be enlisting at least the AfterLRA listener which means that the tests are correct. I would propose to close this issue.

But the tests are still wrong. They are calling a resource which is neither a participant nor a listener. But since the resource is annotated with @LRA the deployment should fail.
In other words both tests need removing from the TCK.

@mmusgrov Mike we will need to add one of the @Compensate or @AfterLRA to this resource because of #244.

But the tests are still wrong. The sooner we remove them the better chance implementations will have of passing the TCK.

So we need to remove the tests to resolve this issue and then create a new issue for the missing TCK tests that you have identified (which is different from this current issue).


adds reconcileWithKeys

Summary
A suggestion to add reconcileWithKeys that @katywings and I have requested in the past. In some situations you want to use reconcile with objects that have keys differently named to id.
       const [target, setStore] = createStore({
        c: {
          a: [
            { ida: 1, name: "1" },
            { ida: 0, name: "0" }
          ],
          b: [
            { idb: 1, name: "1" },
            { idb: 0, name: "0" }
          ]
        }
      });

      const ref = target.c.a[1];

      const source = {
        c: {
          a: [{ ida: 0, name: "0 modified" }],
          b: [{ idb: 0, name: "0 modified" }]
        }
      };

      /*
      setStore("c", reconcile(source.c));
      expect(target.c.a[0]).not.toBe(ref);
      */

      setStore(
        "c",
        reconcileWithKeys(source.c, {
          keys: {
            a: { _key: "ida" },
            b: { _key: "idb" }
          }
        })
      );
      expect(target.c.a[0]).toBe(ref);

      expect(target).toEqual({
        c: {
          a: [{ ida: 0, name: "0 modified" }],
          b: [{ idb: 0, name: "0 modified" }]
        }
      });

How did you test this change?
Hehe, Im running into an issue when trying to write tests for it, when I run npm run test I get this error:
solid-js:test:  FAIL  store/test/modifiers.spec.ts > reconcileWithKeys
solid-js:test: TypeError: Cannot assign to read only property 'Symbol(solid-proxy)' of object '#<Object>'
solid-js:test: ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[1/1]⎯

It works in the playground, so I'm lost at to whats going on, any ideas? 🙏🏼
https://playground.solidjs.com/anonymous/9167e413-e0b2-45bf-942a-3ca2153c0416
References
https://discord.com/channels/722131463138705510/780502110772658196/971305532034011156
https://discord.com/channels/722131463138705510/780502110772658196/1278247899616247808

Ah, I see what's going on, it's failing a test (as expected), but then its throwing an unrelated error, that put me off, and I wasn't understanding. I think I can continue writing tests..

It's a cool Idea. There have been a few design variations on this. Not completely sure which makes the most sense. Mostly wonder if the changes to Stores in 2.0 will have bigger bearing on what the design ultimately is.


feat!: recognize and activate accounts

BREAKING_CHANGE:

Account contains is_active field
AccountEvent::Created divides into Recognized and Activated
ValidationFail contains UnrecognizedAuthority and InactiveAuthority variants

Description
When an account is recognized,

it becomes able to hold assets, permissions, roles, and metadata
it cannot yet execute any queries or transactions

When an account is activated,

it becomes able to execute queries and transactions

Recognize and activate an account when targeted as:

Register<Account> object

Recognize an account when targeted as:

Register<Asset> object.account
Mint<Numeric, Asset> destination.account
Transfer<Account, DomainId, Account> destination See comment
Transfer<Account, AssetDefinitionId, Account> destination
Transfer<Asset, Numeric, Account> destination
Transfer<Asset, Metadata, Account> destination
SetKeyValue<Account> object
SetKeyValue<Asset> object.account
Grant<Permission, Account> destination
Grant<Role, Account> destination

Let me call these creative instructions in documentation
Linked issue

closes #4426

Benefits

who targets an account does not need to care if it has been registered or not
depending on use case, accounts can be registered implicitly/automatically or explicitly/manually

Checklist

[x] I've read CONTRIBUTING.md
[x] I've used the standard signed-off commit format (or will squash just before merging)
[ ] All applicable CI checks pass (or I promised to make them pass later)
[ ] (optional) I've written unit tests for the code changes
[ ] I replied to all comments after code review, marking all implemented changes with thumbs up

This is not how I would implement it. I would rather just control the access through executor as follows:

By default all instructions that target accounts are allowed:

this covers public use
requires no executor (public case shouldn't require executor)

Custom executor rejects instructions that target accounts that have not yet been registered:

this covers private use
should be part of our default executor

I also believe this approach reduces the implementation complexity

As I understand it, according to @mversic  your suggestion, the process when an account is targeted is as follows:

public use

the target is immediately registered no matter what domain the target belongs to

may be reasonable, since the domain boundaries may not make sense in public chains

private use

as before, only registered accounts can be valid targets

This means that no intermediate state is needed for account registration. If so, let's remove is_active flag and forget about recognize/activate terms.
Now, there are two possible approaches in terms of granularity of the account auto-registration policy:

core processes back to executor for auto-registering the target

executor is responsible for registering targeted accounts

returns uniform results regardless of authority of the instruction

chain level public/private characterization
needs a flag to indicate if Register<Account> is called back from core for auto-registration

each domain has a flag, and core determines whether to auto-register the target from its domain, without processing back to executor

core is responsible for registering targeted accounts
domain level public/private characterization
how should the flag be modified, if it should be?

Dealing with the concept of domains and public/private uses at the same time is new to me, and I seek further input

the target is immediately registered no matter what domain the target belongs to

wasn't that how you implemented, or was there something different?

as before, only registered accounts can be valid targets

yes

This means that no intermediate state is needed for account registration. If so, let's remove is_active flag and forget about recognize/activate terms.

yes

core processes back to executor for auto-registering the target

can't executor make sure account is registered before calling isi.execute() and handing over execution to the core

I don't think there is any need to support inactive accounts in private blockchains.

What about offline transactions? do you think they are required only in public case?
Is full registration even possible automatically?
I mean that executor/trigger might have not enough data to perform registration (i.e. metadata)

Requirement for auto registration emerge from our implementation details (account structs holds assets).
Shouldn't we reconsider this?
In this case we would allow isi where target account is not registered yet and if required we can prohibit this isi by checking if account is registered in the executor.

The feature might require the separate and relational entities after all.
As I understand it, an example where a new account "carol" comes to exercise its authority in public use is as follows:

the world has separate assets and accounts maps
- world:
  - numeric_assets:
    - rose:
      - alice: 13
  - accounts:
    - alice:
      - metadata:

(public use) alice transfers 3 roses to carol, who is not registered yet
- world:
  - numeric_assets:
    - rose:
      - alice: 10
      - carol:  3 # appeared
  - accounts: # not checked when carol is targeted
    - alice:
      - metadata:

(public use) carol registers herself
- world:
  - numeric_assets:
    - rose:
      - alice: 10
      - carol:  3
  - accounts:
    - alice:
      - metadata:
    - carol: # registered
      - metadata:

carol successfully transfers 2 roses to alice
- world:
  - numeric_assets:
    - rose:
      - alice: 12
      - carol:  1
  - accounts: # checked when carol is authority
    - alice:
      - metadata:
    - carol:
      - metadata:

I'll extend this idea to other ISIs and other entity maps and consider consistency.
For example, I can immediately see that SetKeyValue<Account> would be invalid before account registration

What about offline transactions? do you think they are required only in public case?

IMHO yes, but that should be confirmed. In private use-case it's expected users are registered before becoming entities in the network

So the idea is to deliberately introduce an inconsistency, the absence of a primary entity in ACCOUNTS in this diagram while other storages referencing it, and thereby represent a pre-registration state of accounts. I'll convert this to draft (and maybe close it) and work on it after #4792

Closed as the issue should be addressed by a different approach such as https://github.com/hyperledger/iroha/pull/4668#issuecomment-2165073957


[Feature Request]: kubectl-asdf could install helm

Requested Feature
Feature kubectl-asdf installs kubectl but not helm that is often needed, eg: by Visual Studio Code plugin GitOps Tools for Flux.

This project is not associated with the devcontainer project and appears to have been abandoned https://github.com/devcontainers-contrib/features/issues/628 . The official project has removed all devcontainer-contrib features from their listing. https://github.com/devcontainers/devcontainers.github.io/issues/451. There is a fork that is being worked on to update and maintain the features https://github.com/devcontainers-extra/features


Definition xrefs have disappeared from eco.obo

All definition xrefs appear to have disappeared in the 2017-07-07 release of eco.obo.
For example, this is ECO:0000001 in the 2017-06-02 release:
[Term]
id: ECO:0000001
name: inference from background scientific knowledge
def: "A curator inference that links the current annotation to a different evidence-based annotation via background knowledge of the curator." [ECO:go, ECO:MCC]
is_a: ECO:0000205 ! curator inference
and this is it in the 2017-07-07 release:
[Term]
id: ECO:0000001
name: inference from background scientific knowledge
def: "A curator inference that links the current annotation to a different evidence-based annotation via background knowledge of the curator." []
is_a: ECO:0000205 ! curator inference
property_value: IAO:0000119 ECO:MCC xsd:string
Is this deliberate?

Hi @tonysawfordebi -
With this release, we switched from providing definition sources as annotations on the definition with the database_cross_reference property (the xrefs) to using IAO's 'definition source' annotation property (what you're seeing as IAO:0000119). These were only changed for the definitions, and any xrefs to GO codes were left, e.g. as with 'physical interaction evidence'
[Term]
id: ECO:0000353
name: physical interaction evidence used in manual assertion
def: "A type of physical interaction evidence that is used in a manual assertion." []
synonym: "inferred from physical interaction" EXACT [GOECO:IPI]
synonym: "IPI" EXACT [GOECO:IPI]
xref: GOECO:IPI "inferred from physical interaction"
property_value: IAO:0000117 "mchibucos" xsd:string
property_value: IAO:0000119 ECO:MCC xsd:string

If this is an issue for your work, please let us know so we can get things sorted out.
cc @mchibucos

OK - this means that GO & ECO do things differently now, so I can't use a shared parser (although I'm in the process of switching to consuming the OBOGraph version of GO rather than OWL/OBO, so that's not a major consideration).
I'll modify my code to take account of this change.
Incidentally, was this change announced anywhere before you implented it?
Incidentally (2), do you have any plans to make ECO available in OBOGraph (JSON) form at any point?

@rctauber I've updated our parser so that it now handles the new way of dealing with definition xrefs, but I've noticed a problem with other xrefs, namely that if the id part of the xref itself contains a colon, then the colon is escaped. For example:
[Term]
id: ECO:0000052
...
xref: TAIR:TED:0000063
[Term]
id: ECO:0000005
...
xref: PSI-MI:MI:0415 "enzymatic study"
This is something that seems to have snuck in in this release.

Thanks for bringing this up @tonysawfordebi - I don't see this in the eco-edit.owl file or the eco.owl file, but it is an issue in eco.obo. I'll replace these on the eco.obo file for now and look into it. I'll be doing an unscheduled release in just a bit so that you have a live file to work with.

Thanks, @rctauber

@tonysawfordebi We noticed that we'd like to change the PSI-MI:MI:xxxx refs to simply be MI:xxxx (e.g. MI:0415) to be consistent with other annotations. Would that cause any issues? It would be live with the next release in August.

That's fine with me, @rctauber

Can you switch back to doing the definitions as axiom annotations? This is standard

Yes. We can. would be grateful if you would suggest some documents/refs/etc. about this standard, as I am trying to learn more. @rctauber

On Jul 17, 2017, at 6:32 PM, Chris Mungall<EMAIL_ADDRESS>wrote:
Can you switch back to doing the definitions as axiom annotations? This is standard
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@mchibucos / @rctauber Can you give me a heads-up when you're about to make this change, please, as I'll need to change my parser again.
Thanks.

Will do - and again, sorry for the inconvenience.

On Jul 18, 2017, at 2:57 AM, Tony Sawford<EMAIL_ADDRESS>wrote:
@mchibucos / @rctauber Can you give me a heads-up when you're about to make this change, please, as I'll need to change my parser again.
Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

No worries.

Thanks, @rctauber - I'll modify my parser accordingly.

@rctauber @mchibucos I've updated my parser to reflect your changes, and I've noticed that the problem of colons in the id part of xrefs being escaped has crept back into eco.obo.
For example:
`[Term]
id: ECO:0000200
...
def: "A type of sequence similarity evidence where a sequence alignment is the basis for making an annotation, but only when the alignment has been manually reviewed; or if the information is in a published paper, the authors have manually reviewed the evidence. Such alignments may be pairwise alignments or multiple alignments." [url:http\://www.geneontology.org/GO.evidence.shtml]
...
[Term]
id: ECO:0000226
...
xref: PSI-MI:MI\:0402 "chromatin immunoprecipitation assay"
`

Hi again @tonysawfordebi -
So sorry about that! I'll take care of that, and we will be doing another release on Monday. Thank you again so much for your patience.


Fix typos in links to original APIs

Well, that's embarassing! The delights of copy-pasting across large swatches of text.
Thank you!


Why this project named Meili

Sorry guys, it's not an issue.
i'm from china, i have spend some time on this project to study, and write some article share to other people.
Meili is a china words means beautiful 美丽, so some friends thought it was an open source project created by Chinese people.
I'm curious does it mean something else in other language or area?
;)

Hi, @botsphp!!!
Meili takes its name after a Norse god: https://en.wikipedia.org/wiki/Meili
The Icelandic historian Snorri Sturluson considers Meili to be ‘the god of oblivion,’ hence, the need to have a powerful search engine in order to find what we might have forgotten :)

Hi, @botsphp!!!
Meili takes its name after a Norse god: https://en.wikipedia.org/wiki/Meili
The Icelandic historian Snorri Sturluson considers Meili to be ‘the god of oblivion,’ hence, the need to have a powerful search engine in order to find what we might have forgotten :)


Add Possion Point Process for high-level representations

Add a prior and a proposal for high-level geometric representations.

PoissionPointProcess as a prior.
PoissonPointProposal as a proposal.

Fixed in https://github.com/mikkelbue/tinyDA/pull/39


GeniusHub incorrect value for hvac_modes

Home Assistant release with the issue:
0.96.5

Last working Home Assistant release (if known):
Operating environment (Hass.io/Docker/Windows/etc.):
Hass.io running on a NUC (Ubuntu server 18.04 & docker)

Component/platform:
GeniusHub
https://www.home-assistant.io/components/geniushub/

Description of problem:
I currently have the heating system turned off (via GeniusHub), so all the radiator valves set themselves to 4C. HA shows the correct temperature, but the climate entity state is set to "heat" and hvac_modes state is set to "off,heat", when it should just be "off".
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
geniushub:
  host: *.*.*.*
  username: !secret genius_username
  password: !secret genius_password

Traceback (if applicable):

climate.bedroom_2_spare | heat | hvac_modes: off,heat current_temperature: 22 min_temp: 4 max_temp: 28 temperature: 4 preset_mode: null preset_modes: boost status: {   "type": "radiator",   "temperature": 22,   "mode": "away",   "override": {     "duration": 0,     "setpoint": 20   } } friendly_name: Bedroom 2 spare icon: mdi:radiator supported_features: 17

Additional information:
@zxdavb - I haven't upgraded my GeniusHub, it is still on 5.2.10, so hopefully you have enough debug logs already from my previous issue to troubleshoot. If not, then just let me know what additional output you require.

@ianpra I have upgraded mine to 5.3.2 and it seems to be working OK.
There is an updated client, and a tweaked version of geniushub in the works (#25599)
I have had a look at your issue and can'tr reproduce it (and couldn't before, with v5.2.x) - is it still as you described?
If so, could you help me by providing a screen shot, and a cut-and-paste of the logs?  This is what I mean:
2019-07-31 16:07:59 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=climate.room_2_2, old_state=None, new_state=<state climate.room_2_2=off; hvac_modes=['off', 'heat'], current_temperature=24.5, min_temp=4.0, max_temp=28.0, temperature=4.0, preset_mode=None, preset_modes=['activity', 'boost'], status=type=radiator, mode=off, temperature=24.5, occupied=False, override=duration=3560, setpoint=7.5, friendly_name=Room 2.2, icon=mdi:radiator, supported_features=17 @ 2019-07-31T16:07:59.822051+01:00>>

It may help if I make clear that:

hvac_modes (note the 's') should always equal ['off', 'heat']
preset_modes=['activity', 'boost'] for rooms with a movement sensors, and preset_modes=['boost'], for those without (boost is advance).

Hi David,
I've just loaded 0.97.0b1 and the problem is fixed. Both the 'mode' and the 'state' are reported as 'off' and the Lovelace card no longer shows it as Heating.
Cheers
Ian

Thanks for letting us know @ianpra 👍

Yes, was solved by the updated client.  Thanks for sending me all those debug logs.


Recommend runtests-parallel in CONTRIBUTING

I think it's stable enough for everybody to use it now.

👍