[Decompiler] Fixes for dma-disasm

Support the entire file being in (when *debug-segment*
Support bitfields, integer enums, and bitfields in more places (full support for all in static data)
Remove the stupid (none) at the end of the _disasm.gc files
Update some types.

Pull Request Test Coverage Report for Build 776157455

40 of 72 (55.56%)  changed or added relevant lines in 4 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.03%) to 69.276%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

common/type_system/defenum.cpp
9
13
69.23%

decompiler/util/data_decompile.cpp
29
39
74.36%

decompiler/analysis/final_output.cpp
0
18
0.0%

Files with Coverage Reduction
New Missed Lines
%

decompiler/analysis/final_output.cpp
2
14.06%

Totals

Change from base Build 775930402:
-0.03%

Covered Lines:
33768

Relevant Lines:
48744

💛  - Coveralls


[ERR_MODULE_NOT_FOUND] [ESM] Vite doesn't bundle internal dependencies

Pre-flight checklist

[X] I have read the contribution documentation for this project.
[X] I agree to follow the code of conduct that this project uses.
[X] I have searched the issue tracker for a bug that matches the one I want to file, without success.

Electron Forge version
7.4.0 or 7.5.0
Electron version
31.0.1 or 32.1.2
Operating system
Windows 11
Last known working Electron Forge version
No response
Expected behavior
No error in console
Actual behavior
With ESM, the electron-squirrel-startup dependency can't be found if it's in dependencies (it works if I move it into devDependencies):

require.resolve (Node < 20.6.0) example; src/main.ts file:
import { createRequire } from 'node:module'

const require = createRequire(import.meta.url)

try {
  // Handle creating/removing shortcuts on Windows when installing/uninstalling.
  require.resolve('electron-squirrel-startup/package.json')
  // OR require.resolve('electron-squirrel-startup/package.json', { paths: [import.meta.dirname] })
  app.quit()
} catch (error) {
  // Ignore
  console.log('Ignore error: ', error)
}

Console output:
  Ignore error:  Error: Cannot find module 'electron-squirrel-startup/package.json'
  Require stack:
  - C:\template-electron-vite\.vite\build\main.js
      at Module._resolveFilename (node:internal/modules/cjs/loader:1152:15)
      at s._resolveFilename (node:electron/js2c/browser_init:2:120699)
      at Function.resolve (node:internal/modules/helpers:190:19)
      at file:///C:/template-electron-vite/.vite/build/main.js:8:12
      at ModuleJob.run (node:internal/modules/esm/module_job:222:25)
      at async ModuleLoader.import (node:internal/modules/esm/loader:316:24)
      at async loadApplicationPackage (file:///C:/template-electron-vite/.yarn/unplugged/electron-npm-31.0.0-df97707901/node_modules/electron/dist/resources/default_app.asar/main.js:129:9)
      at async file:///C:/template-electron-vite/.yarn/unplugged/electron-npm-31.0.0-df97707901/node_modules/electron/dist/resources/default_app.asar/main.js:241:9 {
    code: 'MODULE_NOT_FOUND',
    requireStack: [ 'C:\\template-electron-vite\\.vite\\build\\main.js' ]
  }

import.meta.resolve (Node.js >= 20.6.0) example; src/main.ts file:
try {
  // Handle creating/removing shortcuts on Windows when installing/uninstalling.
  import.meta.resolve('electron-squirrel-startup/package.json')
  app.quit()
} catch (error) {
  // Ignore
  console.log('Ignore error: ', error)
}

Console output:
Ignore error:  Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'electron-squirrel-startup' imported from C:\template-electron-vite\.vite\build\main.js
    at packageResolve (node:internal/modules/esm/resolve:861:9)
    at moduleResolve (node:internal/modules/esm/resolve:934:18)
    at defaultResolve (node:internal/modules/esm/resolve:1164:11)
    at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:383:12)
    at ModuleLoader.resolveSync (node:internal/modules/esm/loader:365:17)
    at Object.resolve (node:internal/modules/esm/initialize_import_meta:30:25)
    at file:///C:/template-electron-vite/.vite/build/main.js:6:15
    at ModuleJob.run (node:internal/modules/esm/module_job:222:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:316:24)
    at async loadApplicationPackage (file:///C:/template-electron-vite/.yarn/unplugged/electron-npm-31.0.0-df97707901/node_modules/electron/dist/resources/default_app.asar/main.js:129:9) {
  code: 'ERR_MODULE_NOT_FOUND'
}

Note: I did a try with other dependencies such as react and solid-js and I got same issue.
Steps to reproduce
Repository: https://github.com/rtritto/template-electron-vite
Steps:

git clone https://github.com/rtritto/template-electron-vite.git
cd template-electron-vite
yarn
yarn start

Additional information
No response

@jdms754 what do you think about this issue?

@jdms754 what do you think about this issue?

I added import.meta.resolve('electron-squirrel-startup/package.json') anywhere in https://github.com/jdms754/forge-vite-bundler/blob/main/src/main.ts and was able to npm run start. I am on macOS Sonoma 14.5, but I am not sure that is the cause of the difference.

I've already tried with import.meta.resolve('electron-squirrel-startup/package.json') (issue description).
Maybe it's related to some settings in tsconfig.json:

https://github.com/rtritto/template-electron-vite/blob/master/tsconfig.json
https://github.com/caoxiemeihao/electron-vite-samples/blob/main/forge-esm-ts/tsconfig.json
https://github.com/jdms754/forge-vite-bundler/blob/main/tsconfig.json

I've already tried with import.meta.resolve('electron-squirrel-startup/package.json') (issue description). Maybe it's related to some settings in tsconfig.json:

https://github.com/rtritto/template-electron-vite/blob/master/tsconfig.json
https://github.com/caoxiemeihao/electron-vite-samples/blob/main/forge-esm-ts/tsconfig.json
https://github.com/jdms754/forge-vite-bundler/blob/main/tsconfig.json

Yes, looks like it's tsconfig.json. Why not set moduleResolution to node16 or bundler? You will also need to update module in the same file and you may have to make additional changes to your vite config files.

I used the template created by @caoxiemeihao

@caoxiemeihao should external constants in /packages/plugin/vite/src/config/vite.base.config.ts also include all dependencies in package.json?
Related code:
https://github.com/electron/forge/blob/420458bd2e6f34e4298c3a8d028c26e6e43ff90e/packages/plugin/vite/src/config/vite.base.config.ts#L8
FYI @erickzhao @MarshallOfSound

Maybe only dev dependencies should be exist because there is the build step.


⚠ Samsung has degraded performance

In 449f311, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2993 ms

Resolved: Samsung performance has improved in a3b8e4c.


Update plugins.md

add descriptions for the code so that the users can understand the meaning of the plugins more easily.
describe your changes...

[x] Read and sign the CLA. PRs that haven't signed it won't be accepted.
[x] Make sure your PR complies with the writer's guide.
[x] Review the diff carefully as sometimes this can reveal issues.
[x] Do not abandon your Pull Request: Stale Pull Requests.
Remove these instructions from your PR as they are for your eyes only.

@703jun Thanks for your contribution.


Adding term as an alias for bash

(Original issue 1016 created by None on 2014-07-10T16:01:21.684534+00:00)
Would be nice to add term (and possibly shell as an alias to bash.

(Original comment by birkenfeld on 2014-10-07T11:37:09.464308+00:00)
"term" is too generic, but I'll add "shell".

(Original comment by birkenfeld on 2014-10-07T11:37:55.566776+00:00)
Closes #1016: add "shell" alias for bash.
→ <<cset 9cce39bdfe51>>


Could not print custom messages on device connection failure

Hi Team,
It is not possible to print custom messages if the script could not connect to the device (through SSH/Netconf or ICMP reachability).
In the sample script get_system_information.pl , the below line doesn't work.
if(! $jnx ) {
       print STDERR "Unable to connect to Junos device \n";
       exit 1;
}

I would like to write a syslog message if the script wasn't able to connect to the device. But it is not working. It is not working in the sample script as well.
Waiting for your kind response.
Thank you.

Hi Team,
Is there any update on this?
Regards,
Bala

Hi @ankitjain093. Can you help @Balakrishnan-Easwaran


Rebase LDAP for internal communication

@kokosing I updated the spreadsheet with the correct branch. This is outdated we should use support_ldap_authentication_between_nodes from this repo

@anusudarsan Thanks


Allocate locations in descending order

This PR changes the allocation of location ids by Loc.make to be done in descending order. This should typically lead to slightly improved performance as it is typical that locations closer to the root of a data structure are allocated before locations further from the root.  So, when a data structure is traversed starting from the root, the resuling splay tree should be right leaning and slightly faster to construct and traverse from left to right.
This PR also adds a Loc.make_array function for allocating an array of locations.  The ids of the locations in the array are in ascending order.  This is because iterating over an array in descending order (i.e. a countdown to 0) is often slightly simpler.

Benchmarks show speed ups in cases like with the Hashtbl implementation that now perform accesses in an optimal order:
Benchmark 1: kcas-main/_build/default/test/xt_benchmark.exe 1 10000
  Time (mean ± σ):       6.8 ms ±   0.1 ms    [User: 5.8 ms, System: 0.6 ms]
  Range (min … max):     6.7 ms …   7.6 ms    436 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: kcas-this/_build/default/test/xt_benchmark.exe 1 10000
  Time (mean ± σ):       6.8 ms ±   0.1 ms    [User: 5.8 ms, System: 0.6 ms]
  Range (min … max):     6.7 ms …   8.1 ms    437 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  'kcas-main/_build/default/test/xt_benchmark.exe 1 10000' ran
    1.00 ± 0.02 times faster than 'kcas-this/_build/default/test/xt_benchmark.exe 1 10000'

Benchmark 1: kcas-main/_build/default/test/xt_benchmark.exe 2 10000
  Time (mean ± σ):      13.1 ms ±   0.1 ms    [User: 12.2 ms, System: 0.7 ms]
  Range (min … max):    12.9 ms …  13.7 ms    227 runs

Benchmark 2: kcas-this/_build/default/test/xt_benchmark.exe 2 10000
  Time (mean ± σ):      13.1 ms ±   0.1 ms    [User: 12.1 ms, System: 0.7 ms]
  Range (min … max):    13.0 ms …  13.6 ms    225 runs

Summary
  'kcas-this/_build/default/test/xt_benchmark.exe 2 10000' ran
    1.00 ± 0.01 times faster than 'kcas-main/_build/default/test/xt_benchmark.exe 2 10000'

Benchmark 1: kcas-main/_build/default/test/xt_benchmark.exe 4 10000
  Time (mean ± σ):      22.8 ms ±   0.2 ms    [User: 21.8 ms, System: 0.7 ms]
  Range (min … max):    22.6 ms …  23.8 ms    130 runs

Benchmark 2: kcas-this/_build/default/test/xt_benchmark.exe 4 10000
  Time (mean ± σ):      22.1 ms ±   0.2 ms    [User: 21.1 ms, System: 0.7 ms]
  Range (min … max):    21.9 ms …  22.7 ms    133 runs

Summary
  'kcas-this/_build/default/test/xt_benchmark.exe 4 10000' ran
    1.03 ± 0.01 times faster than 'kcas-main/_build/default/test/xt_benchmark.exe 4 10000'

Benchmark 1: kcas-main/_build/default/test/xt_parallel_cmp_bench.exe 100000
  Time (mean ± σ):      19.7 ms ±   1.5 ms    [User: 31.8 ms, System: 1.6 ms]
  Range (min … max):    18.4 ms …  28.5 ms    161 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: kcas-this/_build/default/test/xt_parallel_cmp_bench.exe 100000
  Time (mean ± σ):      18.7 ms ±   1.6 ms    [User: 29.7 ms, System: 1.6 ms]
  Range (min … max):    17.9 ms …  28.2 ms    165 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  'kcas-this/_build/default/test/xt_parallel_cmp_bench.exe 100000' ran
    1.05 ± 0.12 times faster than 'kcas-main/_build/default/test/xt_parallel_cmp_bench.exe 100000'

Benchmark 1: kcas-main/_build/default/test/xt_parallel_cmp_bench.exe 200000
  Time (mean ± σ):      36.6 ms ±   2.5 ms    [User: 61.3 ms, System: 2.3 ms]
  Range (min … max):    34.6 ms …  41.1 ms    85 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: kcas-this/_build/default/test/xt_parallel_cmp_bench.exe 200000
  Time (mean ± σ):      35.1 ms ±   2.4 ms    [User: 58.1 ms, System: 2.3 ms]
  Range (min … max):    33.4 ms …  40.1 ms    88 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  'kcas-this/_build/default/test/xt_parallel_cmp_bench.exe 200000' ran
    1.04 ± 0.10 times faster than 'kcas-main/_build/default/test/xt_parallel_cmp_bench.exe 200000'

Benchmark 1: kcas-main/_build/default/test/xt_parallel_cmp_bench.exe 400000
  Time (mean ± σ):      72.1 ms ±   5.6 ms    [User: 123.8 ms, System: 3.4 ms]
  Range (min … max):    66.8 ms …  80.0 ms    44 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: kcas-this/_build/default/test/xt_parallel_cmp_bench.exe 400000
  Time (mean ± σ):      67.9 ms ±   5.2 ms    [User: 115.5 ms, System: 3.4 ms]
  Range (min … max):    64.7 ms …  78.1 ms    46 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  'kcas-this/_build/default/test/xt_parallel_cmp_bench.exe 400000' ran
    1.06 ± 0.12 times faster than 'kcas-main/_build/default/test/xt_parallel_cmp_bench.exe 400000'

Benchmark 1: kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 1 1_000_000 1000 90
  Time (mean ± σ):      42.6 ms ±   0.2 ms    [User: 41.4 ms, System: 0.9 ms]
  Range (min … max):    42.3 ms …  43.1 ms    69 runs

Benchmark 2: kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 1 1_000_000 1000 90
  Time (mean ± σ):      39.4 ms ±   0.1 ms    [User: 38.2 ms, System: 0.9 ms]
  Range (min … max):    39.0 ms …  39.8 ms    75 runs

Summary
  'kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 1 1_000_000 1000 90' ran
    1.08 ± 0.01 times faster than 'kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 1 1_000_000 1000 90'

Benchmark 1: kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 2 1_000_000 1000 90
  Time (mean ± σ):      26.4 ms ±   0.2 ms    [User: 48.3 ms, System: 1.2 ms]
  Range (min … max):    26.1 ms …  28.1 ms    111 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 2 1_000_000 1000 90
  Time (mean ± σ):      25.4 ms ±   0.1 ms    [User: 46.5 ms, System: 1.2 ms]
  Range (min … max):    25.2 ms …  25.8 ms    116 runs

Summary
  'kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 2 1_000_000 1000 90' ran
    1.04 ± 0.01 times faster than 'kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 2 1_000_000 1000 90'

Benchmark 1: kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 4 1_000_000 1000 90
  Time (mean ± σ):      16.4 ms ±   0.2 ms    [User: 53.2 ms, System: 2.1 ms]
  Range (min … max):    15.9 ms …  17.9 ms    167 runs

  Warning: The first benchmarking run for this command was significantly slower than the rest (17.9 ms). This could be caused by (filesystem) caches that were not filled until after the first run. You are already using the '--warmup' option which helps to fill these caches before the actual benchmark. You can either try to increase the warmup count further or re-run this benchmark on a quiet system in case it was a random outlier. Alternatively, consider using the '--prepare' option to clear the caches before each timing run.

Benchmark 2: kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 4 1_000_000 1000 90
  Time (mean ± σ):      15.8 ms ±   0.3 ms    [User: 51.1 ms, System: 1.9 ms]
  Range (min … max):    15.3 ms …  18.1 ms    190 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  'kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 4 1_000_000 1000 90' ran
    1.04 ± 0.02 times faster than 'kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 4 1_000_000 1000 90'

Benchmark 1: kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 1 1_000_000 1000 10
  Time (mean ± σ):     258.6 ms ±   0.3 ms    [User: 257.1 ms, System: 1.1 ms]
  Range (min … max):   258.2 ms … 259.2 ms    11 runs

Benchmark 2: kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 1 1_000_000 1000 10
  Time (mean ± σ):     228.0 ms ±   0.6 ms    [User: 226.5 ms, System: 1.1 ms]
  Range (min … max):   227.1 ms … 229.3 ms    13 runs

Summary
  'kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 1 1_000_000 1000 10' ran
    1.13 ± 0.00 times faster than 'kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 1 1_000_000 1000 10'

Benchmark 1: kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 2 1_000_000 1000 10
  Time (mean ± σ):     147.3 ms ±   0.5 ms    [User: 289.2 ms, System: 1.6 ms]
  Range (min … max):   147.0 ms … 149.4 ms    20 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 2 1_000_000 1000 10
  Time (mean ± σ):     142.0 ms ±   1.0 ms    [User: 278.7 ms, System: 1.6 ms]
  Range (min … max):   141.4 ms … 146.3 ms    21 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  'kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 2 1_000_000 1000 10' ran
    1.04 ± 0.01 times faster than 'kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 2 1_000_000 1000 10'

Benchmark 1: kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 4 1_000_000 1000 10
  Time (mean ± σ):      81.9 ms ±   0.3 ms    [User: 312.4 ms, System: 2.6 ms]
  Range (min … max):    81.5 ms …  83.3 ms    36 runs

Benchmark 2: kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 4 1_000_000 1000 10
  Time (mean ± σ):      76.8 ms ±   0.5 ms    [User: 292.8 ms, System: 2.5 ms]
  Range (min … max):    76.3 ms …  78.4 ms    39 runs

Summary
  'kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 4 1_000_000 1000 10' ran
    1.07 ± 0.01 times faster than 'kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 4 1_000_000 1000 10'

Benchmark 1: kcas-main/_build/default/test/benchmark.exe 1 10000
  Time (mean ± σ):       3.0 ms ±   0.0 ms    [User: 2.1 ms, System: 0.7 ms]
  Range (min … max):     3.0 ms …   3.8 ms    790 runs

  Warning: The first benchmarking run for this command was significantly slower than the rest (3.8 ms). This could be caused by (filesystem) caches that were not filled until after the first run. You are already using the '--warmup' option which helps to fill these caches before the actual benchmark. You can either try to increase the warmup count further or re-run this benchmark on a quiet system in case it was a random outlier. Alternatively, consider using the '--prepare' option to clear the caches before each timing run.

Benchmark 2: kcas-this/_build/default/test/benchmark.exe 1 10000
  Time (mean ± σ):       3.0 ms ±   0.0 ms    [User: 2.1 ms, System: 0.7 ms]
  Range (min … max):     3.0 ms …   3.4 ms    990 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  'kcas-this/_build/default/test/benchmark.exe 1 10000' ran
    1.00 ± 0.02 times faster than 'kcas-main/_build/default/test/benchmark.exe 1 10000'

Benchmark 1: kcas-main/_build/default/test/benchmark.exe 2 10000
  Time (mean ± σ):       8.4 ms ±   0.0 ms    [User: 7.4 ms, System: 0.7 ms]
  Range (min … max):     8.3 ms …   8.8 ms    355 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: kcas-this/_build/default/test/benchmark.exe 2 10000
  Time (mean ± σ):       8.5 ms ±   0.0 ms    [User: 7.6 ms, System: 0.7 ms]
  Range (min … max):     8.4 ms …   8.8 ms    351 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  'kcas-main/_build/default/test/benchmark.exe 2 10000' ran
    1.01 ± 0.01 times faster than 'kcas-this/_build/default/test/benchmark.exe 2 10000'

Benchmark 1: kcas-main/_build/default/test/benchmark.exe 4 10000
  Time (mean ± σ):      13.6 ms ±   0.0 ms    [User: 12.6 ms, System: 0.7 ms]
  Range (min … max):    13.5 ms …  13.8 ms    221 runs

Benchmark 2: kcas-this/_build/default/test/benchmark.exe 4 10000
  Time (mean ± σ):      13.8 ms ±   0.0 ms    [User: 12.8 ms, System: 0.7 ms]
  Range (min … max):    13.7 ms …  14.1 ms    217 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  'kcas-main/_build/default/test/benchmark.exe 4 10000' ran
    1.02 ± 0.00 times faster than 'kcas-this/_build/default/test/benchmark.exe 4 10000'

Benchmark 1: kcas-main/_build/default/test/benchmark.exe 1 200000
  Time (mean ± σ):      23.1 ms ±   0.1 ms    [User: 22.1 ms, System: 0.7 ms]
  Range (min … max):    23.0 ms …  23.5 ms    130 runs

Benchmark 2: kcas-this/_build/default/test/benchmark.exe 1 200000
  Time (mean ± σ):      23.1 ms ±   0.1 ms    [User: 22.1 ms, System: 0.7 ms]
  Range (min … max):    23.0 ms …  23.5 ms    129 runs

Summary
  'kcas-this/_build/default/test/benchmark.exe 1 200000' ran
    1.00 ± 0.01 times faster than 'kcas-main/_build/default/test/benchmark.exe 1 200000'

Benchmark 1: kcas-main/_build/default/test/benchmark.exe 2 200000
  Time (mean ± σ):     130.3 ms ±   0.3 ms    [User: 128.9 ms, System: 1.0 ms]
  Range (min … max):   129.9 ms … 130.8 ms    22 runs

Benchmark 2: kcas-this/_build/default/test/benchmark.exe 2 200000
  Time (mean ± σ):     133.0 ms ±   0.2 ms    [User: 131.6 ms, System: 1.0 ms]
  Range (min … max):   132.6 ms … 133.4 ms    22 runs

Summary
  'kcas-main/_build/default/test/benchmark.exe 2 200000' ran
    1.02 ± 0.00 times faster than 'kcas-this/_build/default/test/benchmark.exe 2 200000'

Benchmark 1: kcas-main/_build/default/test/benchmark.exe 4 200000
  Time (mean ± σ):     233.5 ms ±   0.3 ms    [User: 232.0 ms, System: 1.2 ms]
  Range (min … max):   233.0 ms … 233.9 ms    12 runs

Benchmark 2: kcas-this/_build/default/test/benchmark.exe 4 200000
  Time (mean ± σ):     238.6 ms ±   0.3 ms    [User: 237.1 ms, System: 1.1 ms]
  Range (min … max):   238.1 ms … 239.1 ms    12 runs

Summary
  'kcas-main/_build/default/test/benchmark.exe 4 200000' ran
    1.02 ± 0.00 times faster than 'kcas-this/_build/default/test/benchmark.exe 4 200000'


https://docs.microsoft.com/en-us/azure/aks/devops-pipeline?pivots=pipelines-yaml&tryIt=true&source=docs#code-try-1

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az acr create
Errors:
argument error: Connected registry name must use only lowercase.

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az acr create --resource-group {} --name {} --sku {}

Expected Behavior
Environment Summary
Linux-5.4.0-1083-azure-x86_64-with-glibc2.28 (Cloud Shell), Common Base Linux Delridge (quinault)
Python 3.10.4
Installer: DEB

azure-cli 2.37.0

Extensions:
containerapp 0.3.5
application-insights 0.1.15
aks-preview 0.5.51
azure-firewall 0.13.0
ai-examples 0.2.5
ssh 1.1.1

Dependencies:
msal 1.18.0b1
azure-mgmt-resource 21.1.0b1

Additional Context

route to CXP team

@rotorr Thanks for reaching out to us and sharing this feedback. Could you please use the lowercase for the ACR name and test again ? More Info here.

--name -n
The name of the container registry. It should be specified in lower case.

Awaiting your reply.

@rotorr I wanted to do quick follow-up to check if you had a chance to look at my above comment. Please let us know if you are still facing the same issue after using lowercase for ACR name. Awaiting your reply.

@rotorr The action plan is currently pending on you to test the above plan. We will now proceed with closure of this github issue. If you need any further assistance on this issue in future, please feel free to reopen this thread. We would be happy to help.


Update custom-roles-portal.md

The following is one of the questions asked in Azure Administrator Certification exam and hasn't been mentioned anywhere in the doc (AFAIK). Currently, one can find inconsistent information about it on 3rd party sources. So I've added following to best of my knowledge, but feel free to edit it.  Regardless, it should be clearly mentioned in the doc to prevent confusion.
"You can only clone Microsoft Entra ID built-in roles but you cant clone Microsoft Entra ID custom roles."

@rolyon
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Hi @azarboon
Thanks for your feedback. For Microsoft Entra roles, I think you can clone the baseline permissions from a custom role, but you can't clone a built-in role. We made an update to the following doc:
https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/custom-create#create-a-role-in-the-microsoft-entra-admin-center
Let us know if you have additional feedback.
thanks

#please-close

Rhanks. I would say that update should be mentioned in this page too because when I googled "clone role azure", I got this page.  The other page and its included update, requires pre-existing knowledge.
May I change this pr to reflect that update?


Use Xcode7 for Travis

This looks good :+1:

Use this patch :+1:
I'll close this PR because #4 is required to pass tests.


Add reference filter and deprecated filter param…

Add reference filter and deprecated filter param for /images/json – it was a little bit too confusing for me between filter and filters.
This deprecates the filter param for the /images/json endpoint and make a new filter called reference to replace it. It does change the CLI side (still possible to do docker images busybox:musl) but changes the cli code to use the filter instead (so that docker images --filter reference=busybox:musl and docker images busybox:musl act the same).
$ docker images busybox
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
busybox             uclibc              e02e811dd08f        3 weeks ago         1.093 MB
busybox             musl                733eb3059dce        3 weeks ago         1.213 MB
busybox             glibc               21c16b6787c6        3 weeks ago         4.187 MB
busybox             latest              2b8fd9751c4c        4 months ago        1.093 MB
$ docker images --filter reference=busybox
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
busybox             uclibc              e02e811dd08f        3 weeks ago         1.093 MB
busybox             musl                733eb3059dce        3 weeks ago         1.213 MB
busybox             glibc               21c16b6787c6        3 weeks ago         4.187 MB
busybox             latest              2b8fd9751c4c        4 months ago        1.093 MB
# […]
$ docker images busybox:uclibc
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
busybox             uclibc              e02e811dd08f        3 weeks ago         1.093 MB
$ docker images --filter reference=busybox:uclibc
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
busybox             uclibc              e02e811dd08f        3 weeks ago         1.093 MB
$ docker images busyb
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
$ docker images --filter reference=busyb
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE

[x] Validate the new filter (name, …) 👼
[ ] Add tests for the new filter
[ ] Add docs for the new filter

/cc @thaJeztah @cpuguy83 @tiborvass @stevvooe
🐸
Signed-off-by: Vincent Demeester<EMAIL_ADDRESS>

design LGTM

All right, so docker images … support a little bit of globbing…
λ docker images "centos/*a*"
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
centos/mariadb      latest              23d3ef33ce06        3 months ago        370.6 MB
centos/etherpad     latest              097d06617332        3 months ago        378.1 MB

I need to update the PR code to re-use path instead of the reference package :sweat:

@vdemeester Might be worthwhile to bolster the reference package with glob-based matching:
references.Match(ref, "foo/**/ba[rz]")

This has use in scope-matching and other applications.

Updated and depends on docker/distribution#2039 👼

I think this is blocked by https://github.com/docker/docker/issues/28235 for now 👼

@vdemeester Should be unblocked, now!

@stevvooe It is, PR rebased 👼

LGTM

ping @AkihiroSuda;
15:35:31 ----------------------------------------------------------------------
15:35:31 FAIL: docker_cli_prune_unix_test.go:26: DockerSwarmSuite.TestPruneNetwork
15:35:31
15:35:31 [dfc709b8ed9a0] waiting for daemon to start
15:35:31 [dfc709b8ed9a0] daemon started
15:35:31 docker_cli_prune_unix_test.go:31:
15:35:31     c.Assert(err, checker.IsNil)
15:35:31 ... value *exec.ExitError = &exec.ExitError{ProcessState:(*os.ProcessState)(0xc42310d720), Stderr:[]uint8(nil)} ("exit status 1")
15:35:31
15:35:31 [dfc709b8ed9a0] exiting daemon
15:35:34
15:35:34 ----------------------------------------------------------------------

@thaJeztah ah, it is discussed in https://github.com/docker/docker/pull/27938 I will try to find the solution ASAP..

@AkihiroSuda ah! yes, no problem, just wanted to let you know :smile:


Failing Broker Queries - Faulty Channel

Broker queries fail with Faulty Channel Exception
Description
This error occurs when the broker queries fail on MM due to improper shutdown of Peon Task. I have patched this locally by explicitly un-announcing the peon task before destroy is called
This change was applied here https://github.com/apache/incubator-druid/blob/master/indexing-service/src/main/java/org/apache/druid/indexing/overlord/ForkingTaskRunner.java#L605
      curatorDruidNodeAnnouncer.unannounce(new DiscoveryDruidNode(
          new DruidNode(
              node.getServiceName(),
              node.getHost(),
              taskInfo.processHolder.port,
              taskInfo.processHolder.port,
              taskInfo.processHolder.tlsPort,
              node.isEnablePlaintextPort(),
              node.isEnableTlsPort()
          ),
          DruidNodeDiscoveryProvider.NODE_TYPE_PEON,
          ImmutableMap.of()
      ));

      try {
        log.info("Destroying task: %s . Sleeping for 10000 millis", taskid);
        Thread.sleep(10000);
      } catch (InterruptedException e) {
        log.error("Sleep interuppedted for task: %s", taskid);
      }

      taskInfo.processHolder.process.destroy();

This is similar to https://github.com/apache/incubator-druid/issues/6043 but the exceptions reported there are slightly different.

This sounds like a bug which stalebot should have ignored, adjusting label.

Encounter the same issue. Is this fixed in recent releases?

Facing this same issue as well

we hit this issue too


CFApp controller should reuse servicebinding.io capabilities to project the VCAP_APPLICATION env var to the app workload

Background
According to the servicebinding.io spec it is possible to project secrets as env vars in the workload. We could leverage this capability and delete our own code that deals with env var injection in our app workload.

Projecting the VCAP_APPLICATION env var via servicebinding.io will introduce complexity (management of one more object) with quiestionable return of investment. Closing.


Gap between 'Add new technical profiles' and 'Add the technical profiles as orchestration steps'

Hello, it seems that there is a missing section in the tutorial. In Add the technical profiles as orchestration steps you talk about orchestration steps but you don't provide any previous description.
It would be worth to explain where in the xml document insert the orchestration steps, and why there are only 3 orchestration steps
in the tutorial with order 2, 8 and 10. It is a bit confusing.
I think it would be worth to explain the creation in more details or at least include the complete version of TrustFrameworkExtensions.xml document.
Thank you

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

ID: 05baed83-30af-90a6-32cd-a7ff654ba52b
Version Independent ID: 96710fcb-6c62-fba5-e93e-c7fe344088c1
Content: Track user behavior by using Application Insights - Azure AD B2C
Content Source: articles/active-directory-b2c/analytics-with-application-insights.md
Service: active-directory
Sub-service: b2c
GitHub Login: @kengaderdus
Microsoft Alias: kengaderdus

@KrzysztofNapierala
Thanks for your feedback and patience.
You need to satisfy the prerequisites before you proceed. The prerequisites show you how to access the premade custom policies.  premade custom policies have existing orchestration steps, so you're adding new orchestration steps to existing ones. Your first orchestration step can be added as the second one, and the second and third claims are added before and after the SendClaims orchestration steps respectively.
After you add the new orchestration steps, renumber the steps sequentially without skipping any integers from 1 to N.
We'll update this doc to improve clarity #please-close


Revolutionise the NFT ecosystem: introduce slavery

The maths checks out, so it is just. Code is law.
CC @maiste.


Add Cell Collective Boolean expressions format -> cnet format

Sorry sent this late.
I took a little time to rewrite part of it to make it compatible to python 2.5 2.6 2.7 3.5 3.6 (other version not tested). Now it is 100x faster than my older version and is free from many possible issues due to strange node names (such as node names containing "/" "" "-" "NOT" "(" ")").
I wondered why I wrote a Boolean interpreter at the beginning. Now I am using python eval() (Just like Thomas did, though he is dealing with a slightly different file format). It is not surprising that this is much faster.
Add some comments to help understand how those code work.
I saw Thomas's pull request. Maybe I should modify it a little to put it inside BN.from_string() too. However, like we talked before, some networks' LUT are too huge. Thus use from_string() -> to_cnet() to convert file format would consume too much memory.
Looking forward to hear your opinion

Besides, I am really confused that why my pull request would contain 4 "merging commits". I thought it should be fast forward merge and no merging commits should exist.
Never see this on my own git server.

Talking about unit test, I am a little unsure about how the test for file format conversion should work.
Assert that converted file content to be exactly same as expected? Or just test a few lines of the converted file?
Let me think more about it.
Ideally a unit test should cover all strange cases like strange node names.
Then BN should be able to read the converted file and do some computation. We can assert the bias, k_eff or other measurements to be within expectation? That should be a better way for the test. In that case, if BN was changed so that it can no longer read the converted files, we will know immediately.

@xuan-w, I have resolved the conflicts on this pull request. Please let me know if you want me to push it. Are you done with the test cases?

@xuan-w, I'm closing this PR since this now conflicts with v0.1. Let's make a new PR to include the CellCollective I/O methods as we discussed. Cheers bud!


Could not find 'dotnet' host for the 'X64' architecture (Running on Mac M1 ARM64)

Type: Bug
Issue Description
When I'm trying to run individual unit tests by clicking Run Test above the test, it fails saying Could not find 'dotnet' host for the 'X64' architecture.
Note, I tried to run in a separate project and it works properly. I also tried mulitiple versions of dotnet and it doesn't seem to matter which version I use
Full log outputs
Steps to Reproduce
Click Run Test in an MSTest Unit Test
Expected Behavior
Test should be discovered and execute (works from CLI)
Actual Behavior
Fails to find/run test, reporting:
Starting test discovery
Microsoft.VisualStudio.TestPlatform.ObjectModel.TestPlatformException: Could not find 'dotnet' host for the 'X64' architecture.

You can resolve the problem by installing the 'X64' .NET.

The specified framework can be found at:
  - https://aka.ms/dotnet-download

   at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Hosting.DotnetTestHostManager.GetTestHostProcessStartInfo(IEnumerable`1 sources, IDictionary`2 environmentVariables, TestRunnerConnectionInfo connectionInfo) in /_/src/Microsoft.TestPlatform.TestHostProvider/Hosting/DotnetTestHostManager.cs:line 447
   at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Client.ProxyOperationManager.SetupChannel(IEnumerable`1 sources, String runSettings) in /_/src/Microsoft.TestPlatform.CrossPlatEngine/Client/ProxyOperationManager.cs:line 226
   at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Client.ProxyDiscoveryManager.InitializeDiscovery(DiscoveryCriteria discoveryCriteria, ITestDiscoveryEventsHandler2 eventHandler, Boolean skipDefaultAdapters) in /_/src/Microsoft.TestPlatform.CrossPlatEngine/Client/ProxyDiscoveryManager.cs:line 145
Test discovery aborted

.NET Test Log Output

MSBuild version 17.9.4+90725d08d for .NET
  Determining projects to restore...
  All projects are up-to-date for restore.
  -- Configuring done (0.1s)
  -- Generating done (0.0s)
  -- Build files have been written to: /Users/josh/Code/Fluxus/rp/build
  [ 60%] Built target RPCore
  [100%] Built target RPExecutable
  -- Configuring done (0.0s)
  -- Generating done (0.0s)
  -- Build files have been written to: /Users/josh/Code/Fluxus/rp/build
  [ 60%] Built target RPCore
  [100%] Built target RPExecutable
/usr/local/share/dotnet/sdk/8.0.201/Microsoft.Common.CurrentVersion.targets(2389,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Invalid number of sections declared in PE header. Invalid number of sections declared in PE header. [/Users/josh/Code/Fluxus/rp/src/ResultsProcessor/ResultsProcessor.CoreAPI/CoreAPI.csproj]
  CoreAPI -> /Users/josh/Code/Fluxus/rp/src/ResultsProcessor/ResultsProcessor.CoreAPI/bin/Debug/netstandard2.0/CoreAPI.dll
/usr/local/share/dotnet/sdk/8.0.201/Microsoft.Common.CurrentVersion.targets(2389,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Invalid number of sections declared in PE header. Invalid number of sections declared in PE header. [/Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/ResultsProcessor.CoreAPI.Tests.csproj]
  ResultsProcessor.CoreAPI.Tests -> /Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/bin/Debug/net8.0/ResultsProcessor.CoreAPI.Tests.dll
Build succeeded.
/usr/local/share/dotnet/sdk/8.0.201/Microsoft.Common.CurrentVersion.targets(2389,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Invalid number of sections declared in PE header. Invalid number of sections declared in PE header. [/Users/josh/Code/Fluxus/rp/src/ResultsProcessor/ResultsProcessor.CoreAPI/CoreAPI.csproj]
/usr/local/share/dotnet/sdk/8.0.201/Microsoft.Common.CurrentVersion.targets(2389,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Invalid number of sections declared in PE header. Invalid number of sections declared in PE header. [/Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/ResultsProcessor.CoreAPI.Tests.csproj]
    2 Warning(s)
    0 Error(s)
Time Elapsed 00:00:02.89
Starting test discovery
Microsoft.VisualStudio.TestPlatform.ObjectModel.TestPlatformException: Could not find 'dotnet' host for the 'X64' architecture.
You can resolve the problem by installing the 'X64' .NET.
The specified framework can be found at:

https://aka.ms/dotnet-download

at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Hosting.DotnetTestHostManager.GetTestHostProcessStartInfo(IEnumerable1 sources, IDictionary2 environmentVariables, TestRunnerConnectionInfo connectionInfo) in //src/Microsoft.TestPlatform.TestHostProvider/Hosting/DotnetTestHostManager.cs:line 447
at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Client.ProxyOperationManager.SetupChannel(IEnumerable`1 sources, String runSettings) in //src/Microsoft.TestPlatform.CrossPlatEngine/Client/ProxyOperationManager.cs:line 226
at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Client.ProxyDiscoveryManager.InitializeDiscovery(DiscoveryCriteria discoveryCriteria, ITestDiscoveryEventsHandler2 eventHandler, Boolean skipDefaultAdapters) in /_/src/Microsoft.TestPlatform.CrossPlatEngine/Client/ProxyDiscoveryManager.cs:line 145
Test discovery aborted

Log files
Successful, separate project
vsTestLogs_success.txt.zip
Failed runs on problem project, using two different versions of dotnet
vsTestLogs_fail1.txt.zip
vsTestLogs_fail2.txt.zip
C# log

[LanguageServerHost] /Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs found in workspace Host
[LanguageServerHost] [12:48:03.623][Start]textDocument/runTests
[Info  - 4:48:03 PM] [Microsoft.CodeAnalysis.LanguageServer.DotnetCliHelper] Using dotnet executable configured on the PATH
[Microsoft.CodeAnalysis.LanguageServer.DotnetCliHelper] Running dotnet CLI command at /opt/homebrew/bin/dotnet in directory /Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests with arguments System.String[]
[LanguageServerHost] [12:48:03.657][Start]workspace/buildOnlyDiagnosticIds
[LanguageServerHost] [12:48:03.666][End]workspace/buildOnlyDiagnosticIds
[LanguageServerHost] /Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs found in workspace Host
[LanguageServerHost] [12:48:03.984][Start]textDocument/codeLens
[LanguageServerHost] [12:48:03.985][End]textDocument/codeLens
[LanguageServerHost] /Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs found in workspace Host
[LanguageServerHost] /Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs found in workspace Host
[LanguageServerHost] [12:48:04.363][Start]codeLens/resolve
[LanguageServerHost] [12:48:04.364][Start]codeLens/resolve
[LanguageServerHost] [12:48:04.366][End]codeLens/resolve
[LanguageServerHost] [12:48:04.366][End]codeLens/resolve
[Microsoft.CodeAnalysis.LanguageServer.DotnetCliHelper] Running dotnet CLI command at /opt/homebrew/bin/dotnet in directory /Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/bin/Debug/net8.0 with arguments System.String[]
[Microsoft.CodeAnalysis.LanguageServer.DotnetCliHelper] .NET SDK:
 Version:           8.0.201
 Commit:            4c2d78f037
 Workload version:  8.0.200-manifests.3097af8b
Runtime Environment:
OS Name:     Mac OS X
OS Version:  14.3
OS Platform: Darwin
RID:         osx-arm64
Base Path:   /usr/local/share/dotnet/sdk/8.0.201/
.NET workloads installed:
There are no installed workloads to display.
Host:
Version:      8.0.2
Architecture: arm64
Commit:       1381d5ebd2
.NET SDKs installed:
6.0.402 [/usr/local/share/dotnet/sdk]
7.0.203 [/usr/local/share/dotnet/sdk]
8.0.201 [/usr/local/share/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.10 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.5 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.10 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Other architectures found:
x64   [/usr/local/share/dotnet/x64]
registered at [/etc/dotnet/install_location_x64]
Environment variables:
Not set
global.json file:
/Users/josh/Code/Fluxus/rp/global.json
Learn more:
https://aka.ms/dotnet/info
Download .NET:
https://aka.ms/dotnet/download
[Microsoft.CodeAnalysis.LanguageServer.DotnetCliHelper] Using vstest console at /usr/local/share/dotnet/sdk/8.0.201/vstest.console.dll
[Microsoft.CodeAnalysis.LanguageServer.Testing.TestDiscoverer] Potential test methods in range: [TestMethod]
public void TestMethod()
{
string repoRoot = System.IO.Directory.GetCurrentDirectory();
// os independent path combine
string dataPath = System.IO.Path.Combine(repoRoot, "exampleData", "med.flr");
CoreAPI.AnalyzeFile(dataPath);
        // Assert something about the result
        // Assert.IsNotNull(result);
    }

[LanguageServerHost] [12:48:07.476][End]textDocument/runTests
[LanguageServerHost] [12:48:11.004][Start]workspace/buildOnlyDiagnosticIds
[LanguageServerHost] [12:48:11.005][End]workspace/buildOnlyDiagnosticIds
[LanguageServerHost] /Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs found in workspace Host
[LanguageServerHost] [12:48:32.791][Start]textDocument/diagnostic
[LanguageServerHost] PublicDocumentPullDiagnosticsHandler(category: , source: ) started getting diagnostics
[LanguageServerHost] previousResults.Length=1
[LanguageServerHost] Processing 1 documents
[LanguageServerHost] Diagnostics were unchanged for DocumentDiagnosticSource: /Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs in ResultsProcessor.CoreAPI.Tests (net8.0)
[LanguageServerHost] Microsoft.CodeAnalysis.LanguageServer.Handler.Diagnostics.Public.PublicDocumentPullDiagnosticsHandler finished getting diagnostics
[LanguageServerHost] [12:48:32.792][End]textDocument/diagnostic

C# LSP Trace Logs
[Trace - 4:57:03 PM] Sending request 'textDocument/runTests - (39)'.
Params: {
    "textDocument": {
        "uri": "file:///Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs"
    },
    "range": {
        "start": {
            "line": 9,
            "character": 20
        },
        "end": {
            "line": 9,
            "character": 30
        }
    },
    "attachDebugger": false,
    "partialResultToken": "35c7a8fa-dc44-4421-979e-a46acf806f4e"
}
[Trace - 4:57:03 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] /Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs found in workspace Host"
}
[Trace - 4:57:03 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] [12:57:03.016][Start]textDocument/runTests"
}
[Trace - 4:57:03 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[Microsoft.CodeAnalysis.LanguageServer.DotnetCliHelper] Running dotnet CLI command at /opt/homebrew/bin/dotnet in directory /Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests with arguments System.String[]"
}
[Trace - 4:57:03 PM] Sending request 'workspace/buildOnlyDiagnosticIds - (40)'.
[Trace - 4:57:03 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] [12:57:03.055][Start]workspace/buildOnlyDiagnosticIds"
}
[Trace - 4:57:03 PM] Received response 'workspace/buildOnlyDiagnosticIds - (40)' in 37ms.
Result: {
"ids": [
"CS1607",
"CS0169",
"CS0414",
"CS0067",
"CS0649",
"CS0656",
"CS0518",
"CS5001",
"CS0028",
"CS0017",
"CS7022",
"CS1556",
"CS0402",
"CS1558",
"CS1555",
"CS8892",
"CS0148",
"CS8078",
"CS7038",
"CS0204",
"CS0570",
"CS8004",
"CS8006",
"CS8005",
"CS8008",
"CS4007",
"CS8178",
"CS4013",
"CS1969",
"CS9026",
"CS9068",
"CS9144",
"CS9148",
"CS9149",
"CS9153",
"CS9154",
"CS9155",
"CS9156",
"CS9158",
"CS9159",
"CS9160",
"CS9163",
"CS9177",
"CS9178",
"CS9207",
"CS8419",
"CS8420",
"CA1812",
"CA1824",
"CA1016",
"CA1014",
"CA1017",
"CA1017",
"CA1724",
"CA1724",
"CA1501",
"CA1502",
"CA1505",
"CA1506",
"CA1509",
"CA1852",
"CA5360",
"CA5399",
"CA5400",
"CA5380",
"CA5381",
"CA5367",
"CA5401",
"CA5402",
"CA2301",
"CA2302",
"CA2321",
"CA2322",
"CA2329",
"CA2330",
"CA2311",
"CA2312",
"CA2327",
"CA2328",
"CA5387",
"CA5388",
"CA5362",
"CA5396",
"CA5391",
"CA5395",
"CA5382",
"CA5383"
]
}
[Trace - 4:57:03 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] [12:57:03.057][End]workspace/buildOnlyDiagnosticIds"
}
[Trace - 4:57:03 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "MSBuild version 17.9.4+90725d08d for .NET"
}
]
[Trace - 4:57:03 PM] Sending request 'textDocument/codeLens - (41)'.
Params: {
"textDocument": {
"uri": "file:///Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs"
}
}
[Trace - 4:57:03 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] /Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs found in workspace Host"
}
[Trace - 4:57:03 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] [12:57:03.385][Start]textDocument/codeLens"
}
[Trace - 4:57:03 PM] Received response 'textDocument/codeLens - (41)' in 2ms.
Result: [
{
"range": {
"start": {
"line": 6,
"character": 17
},
"end": {
"line": 6,
"character": 23
}
},
"data": {
"SyntaxVersion": "2024-03-07T00:47:49.9249460Z-10030-0",
"ListIndex": 0,
"TextDocument": {
"uri": "file:///Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs"
}
}
},
{
"range": {
"start": {
"line": 9,
"character": 20
},
"end": {
"line": 9,
"character": 30
}
},
"data": {
"SyntaxVersion": "2024-03-07T00:47:49.9249460Z-10030-0",
"ListIndex": 1,
"TextDocument": {
"uri": "file:///Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs"
}
}
},
{
"range": {
"start": {
"line": 9,
"character": 20
},
"end": {
"line": 9,
"character": 30
}
},
"command": {
"title": "Run Test",
"command": "dotnet.test.run",
"arguments": [
{
"textDocument": {
"uri": "file:///Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs"
},
"range": {
"start": {
"line": 9,
"character": 20
},
"end": {
"line": 9,
"character": 30
}
},
"attachDebugger": false
}
]
}
},
{
"range": {
"start": {
"line": 9,
"character": 20
},
"end": {
"line": 9,
"character": 30
}
},
"command": {
"title": "Debug Test",
"command": "dotnet.test.run",
"arguments": [
{
"textDocument": {
"uri": "file:///Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs"
},
"range": {
"start": {
"line": 9,
"character": 20
},
"end": {
"line": 9,
"character": 30
}
},
"attachDebugger": true
}
]
}
},
{
"range": {
"start": {
"line": 6,
"character": 17
},
"end": {
"line": 6,
"character": 23
}
},
"command": {
"title": "Run All Tests",
"command": "dotnet.test.run",
"arguments": [
{
"textDocument": {
"uri": "file:///Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs"
},
"range": {
"start": {
"line": 6,
"character": 17
},
"end": {
"line": 6,
"character": 23
}
},
"attachDebugger": false
}
]
}
},
{
"range": {
"start": {
"line": 6,
"character": 17
},
"end": {
"line": 6,
"character": 23
}
},
"command": {
"title": "Debug All Tests",
"command": "dotnet.test.run",
"arguments": [
{
"textDocument": {
"uri": "file:///Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs"
},
"range": {
"start": {
"line": 6,
"character": 17
},
"end": {
"line": 6,
"character": 23
}
},
"attachDebugger": true
}
]
}
}
]
[Trace - 4:57:03 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] [12:57:03.385][End]textDocument/codeLens"
}
[Trace - 4:57:03 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "  Determining projects to restore..."
}
]
[Trace - 4:57:03 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "  All projects are up-to-date for restore."
}
]
[Trace - 4:57:03 PM] Sending request 'codeLens/resolve - (42)'.
Params: {
"range": {
"start": {
"line": 6,
"character": 17
},
"end": {
"line": 6,
"character": 23
}
},
"data": {
"SyntaxVersion": "2024-03-07T00:47:49.9249460Z-10030-0",
"ListIndex": 0,
"TextDocument": {
"uri": "file:///Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs"
}
}
}
[Trace - 4:57:03 PM] Sending request 'codeLens/resolve - (43)'.
Params: {
"range": {
"start": {
"line": 9,
"character": 20
},
"end": {
"line": 9,
"character": 30
}
},
"data": {
"SyntaxVersion": "2024-03-07T00:47:49.9249460Z-10030-0",
"ListIndex": 1,
"TextDocument": {
"uri": "file:///Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs"
}
}
}
[Trace - 4:57:03 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] /Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs found in workspace Host"
}
[Trace - 4:57:03 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] /Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs found in workspace Host"
}
[Trace - 4:57:03 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] [12:57:03.764][Start]codeLens/resolve"
}
[Trace - 4:57:03 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] [12:57:03.764][Start]codeLens/resolve"
}
[Trace - 4:57:03 PM] Received response 'codeLens/resolve - (42)' in 4ms.
Result: {
"range": {
"start": {
"line": 6,
"character": 17
},
"end": {
"line": 6,
"character": 23
}
},
"command": {
"title": "0 references",
"command": "roslyn.client.peekReferences",
"arguments": [
"file:///Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs",
{
"line": 6,
"character": 17
}
]
},
"data": {
"SyntaxVersion": "2024-03-07T00:47:49.9249460Z-10030-0",
"ListIndex": 0,
"TextDocument": {
"uri": "file:///Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs"
}
}
}
[Trace - 4:57:03 PM] Received response 'codeLens/resolve - (43)' in 4ms.
Result: {
"range": {
"start": {
"line": 9,
"character": 20
},
"end": {
"line": 9,
"character": 30
}
},
"command": {
"title": "0 references",
"command": "roslyn.client.peekReferences",
"arguments": [
"file:///Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs",
{
"line": 9,
"character": 20
}
]
},
"data": {
"SyntaxVersion": "2024-03-07T00:47:49.9249460Z-10030-0",
"ListIndex": 1,
"TextDocument": {
"uri": "file:///Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs"
}
}
}
[Trace - 4:57:03 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] [12:57:03.766][End]codeLens/resolve"
}
[Trace - 4:57:03 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] [12:57:03.766][End]codeLens/resolve"
}
[Trace - 4:57:04 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "  -- Configuring done (0.0s)"
}
]
[Trace - 4:57:04 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "  -- Generating done (0.1s)"
}
]
[Trace - 4:57:04 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "  -- Build files have been written to: /Users/josh/Code/Fluxus/rp/build"
}
]
[Trace - 4:57:04 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "  [ 60%] Built target RPCore"
}
]
[Trace - 4:57:04 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "  [100%] Built target RPExecutable"
}
]
[Trace - 4:57:05 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "  -- Configuring done (0.0s)"
}
]
[Trace - 4:57:05 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "  -- Generating done (0.0s)"
}
]
[Trace - 4:57:05 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "  -- Build files have been written to: /Users/josh/Code/Fluxus/rp/build"
}
]
[Trace - 4:57:05 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "  [ 60%] Built target RPCore"
}
]
[Trace - 4:57:05 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "  [100%] Built target RPExecutable"
}
]
[Trace - 4:57:05 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "/usr/local/share/dotnet/sdk/8.0.201/Microsoft.Common.CurrentVersion.targets(2389,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Invalid number of sections declared in PE header. Invalid number of sections declared in PE header. [/Users/josh/Code/Fluxus/rp/src/ResultsProcessor/ResultsProcessor.CoreAPI/CoreAPI.csproj]"
}
]
[Trace - 4:57:05 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "  CoreAPI -> /Users/josh/Code/Fluxus/rp/src/ResultsProcessor/ResultsProcessor.CoreAPI/bin/Debug/netstandard2.0/CoreAPI.dll"
}
]
[Trace - 4:57:05 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "/usr/local/share/dotnet/sdk/8.0.201/Microsoft.Common.CurrentVersion.targets(2389,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Invalid number of sections declared in PE header. Invalid number of sections declared in PE header. [/Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/ResultsProcessor.CoreAPI.Tests.csproj]"
}
]
[Trace - 4:57:05 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "  ResultsProcessor.CoreAPI.Tests -> /Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/bin/Debug/net8.0/ResultsProcessor.CoreAPI.Tests.dll"
}
]
[Trace - 4:57:05 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": ""
}
]
[Trace - 4:57:05 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "Build succeeded."
}
]
[Trace - 4:57:05 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": ""
}
]
[Trace - 4:57:05 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "/usr/local/share/dotnet/sdk/8.0.201/Microsoft.Common.CurrentVersion.targets(2389,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Invalid number of sections declared in PE header. Invalid number of sections declared in PE header. [/Users/josh/Code/Fluxus/rp/src/ResultsProcessor/ResultsProcessor.CoreAPI/CoreAPI.csproj]"
}
]
[Trace - 4:57:05 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "/usr/local/share/dotnet/sdk/8.0.201/Microsoft.Common.CurrentVersion.targets(2389,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Invalid number of sections declared in PE header. Invalid number of sections declared in PE header. [/Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/ResultsProcessor.CoreAPI.Tests.csproj]"
}
]
[Trace - 4:57:05 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "    2 Warning(s)"
}
]
[Trace - 4:57:05 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "    0 Error(s)"
}
]
[Trace - 4:57:05 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": ""
}
]
[Trace - 4:57:05 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Building project...",
"message": "Time Elapsed 00:00:02.41"
}
]
[Trace - 4:57:05 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[Microsoft.CodeAnalysis.LanguageServer.DotnetCliHelper] Running dotnet CLI command at /opt/homebrew/bin/dotnet in directory /Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/bin/Debug/net8.0 with arguments System.String[]"
}
[Trace - 4:57:06 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[Microsoft.CodeAnalysis.LanguageServer.DotnetCliHelper] .NET SDK:\n Version:           8.0.201\n Commit:            4c2d78f037\n Workload version:  8.0.200-manifests.3097af8b\n\nRuntime Environment:\n OS Name:     Mac OS X\n OS Version:  14.3\n OS Platform: Darwin\n RID:         osx-arm64\n Base Path:   /usr/local/share/dotnet/sdk/8.0.201/\n\n.NET workloads installed:\nThere are no installed workloads to display.\n\nHost:\n  Version:      8.0.2\n  Architecture: arm64\n  Commit:       1381d5ebd2\n\n.NET SDKs installed:\n  6.0.402 [/usr/local/share/dotnet/sdk]\n  7.0.203 [/usr/local/share/dotnet/sdk]\n  8.0.201 [/usr/local/share/dotnet/sdk]\n\n.NET runtimes installed:\n  Microsoft.AspNetCore.App 6.0.10 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]\n  Microsoft.AspNetCore.App 7.0.5 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]\n  Microsoft.AspNetCore.App 8.0.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]\n  Microsoft.NETCore.App 6.0.10 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]\n  Microsoft.NETCore.App 7.0.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]\n  Microsoft.NETCore.App 8.0.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]\n\nOther architectures found:\n  x64   [/usr/local/share/dotnet/x64]\n    registered at [/etc/dotnet/install_location_x64]\n\nEnvironment variables:\n  Not set\n\nglobal.json file:\n  /Users/josh/Code/Fluxus/rp/global.json\n\nLearn more:\n  https://aka.ms/dotnet/info\n\nDownload .NET:\n  https://aka.ms/dotnet/download\n\n"
}
[Trace - 4:57:06 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[Microsoft.CodeAnalysis.LanguageServer.DotnetCliHelper] Using vstest console at /usr/local/share/dotnet/sdk/8.0.201/vstest.console.dll"
}
[Trace - 4:57:06 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Discovering tests...",
"message": "\nStarting test discovery"
}
]
[Trace - 4:57:06 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[Microsoft.CodeAnalysis.LanguageServer.Testing.TestDiscoverer] Potential test methods in range: [TestMethod]\n        public void TestMethod()\n        {\n            string repoRoot = System.IO.Directory.GetCurrentDirectory();\n            // os independent path combine\n            string dataPath = System.IO.Path.Combine(repoRoot, "exampleData", "med.flr");\n            CoreAPI.AnalyzeFile(dataPath);\n\n            // Assert something about the result\n            // Assert.IsNotNull(result);\n        }"
}
[Trace - 4:57:06 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Discovering tests...",
"message": "Microsoft.VisualStudio.TestPlatform.ObjectModel.TestPlatformException: Could not find 'dotnet' host for the 'X64' architecture.\r\n\r\nYou can resolve the problem by installing the 'X64' .NET.\r\n\r\nThe specified framework can be found at:\r\n  - https://aka.ms/dotnet-download\r\n\n   at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Hosting.DotnetTestHostManager.GetTestHostProcessStartInfo(IEnumerable`1 sources, IDictionary`2 environmentVariables, TestRunnerConnectionInfo connectionInfo) in //src/Microsoft.TestPlatform.TestHostProvider/Hosting/DotnetTestHostManager.cs:line 447\n   at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Client.ProxyOperationManager.SetupChannel(IEnumerable`1 sources, String runSettings) in //src/Microsoft.TestPlatform.CrossPlatEngine/Client/ProxyOperationManager.cs:line 226\n   at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Client.ProxyDiscoveryManager.InitializeDiscovery(DiscoveryCriteria discoveryCriteria, ITestDiscoveryEventsHandler2 eventHandler, Boolean skipDefaultAdapters) in /_/src/Microsoft.TestPlatform.CrossPlatEngine/Client/ProxyDiscoveryManager.cs:line 145"
}
]
[Trace - 4:57:06 PM] Received notification '$/progress'.
Params: [
"35c7a8fa-dc44-4421-979e-a46acf806f4e",
{
"stage": "Discovering tests...",
"message": "Test discovery aborted"
}
]
[Trace - 4:57:06 PM] Received response 'textDocument/runTests - (39)' in 3280ms.
Result: []
[Trace - 4:57:06 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] [12:57:06.295][End]textDocument/runTests"
}
[Trace - 4:57:06 PM] Sending request 'workspace/buildOnlyDiagnosticIds - (44)'.
[Trace - 4:57:06 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] [12:57:06.606][Start]workspace/buildOnlyDiagnosticIds"
}
[Trace - 4:57:06 PM] Received response 'workspace/buildOnlyDiagnosticIds - (44)' in 5ms.
Result: {
"ids": [
"CS1607",
"CS0169",
"CS0414",
"CS0067",
"CS0649",
"CS0656",
"CS0518",
"CS5001",
"CS0028",
"CS0017",
"CS7022",
"CS1556",
"CS0402",
"CS1558",
"CS1555",
"CS8892",
"CS0148",
"CS8078",
"CS7038",
"CS0204",
"CS0570",
"CS8004",
"CS8006",
"CS8005",
"CS8008",
"CS4007",
"CS8178",
"CS4013",
"CS1969",
"CS9026",
"CS9068",
"CS9144",
"CS9148",
"CS9149",
"CS9153",
"CS9154",
"CS9155",
"CS9156",
"CS9158",
"CS9159",
"CS9160",
"CS9163",
"CS9177",
"CS9178",
"CS9207",
"CS8419",
"CS8420",
"CA1812",
"CA1824",
"CA1016",
"CA1014",
"CA1017",
"CA1017",
"CA1724",
"CA1724",
"CA1501",
"CA1502",
"CA1505",
"CA1506",
"CA1509",
"CA1852",
"CA5360",
"CA5399",
"CA5400",
"CA5380",
"CA5381",
"CA5367",
"CA5401",
"CA5402",
"CA2301",
"CA2302",
"CA2321",
"CA2322",
"CA2329",
"CA2330",
"CA2311",
"CA2312",
"CA2327",
"CA2328",
"CA5387",
"CA5388",
"CA5362",
"CA5396",
"CA5391",
"CA5395",
"CA5382",
"CA5383"
]
}
[Trace - 4:57:06 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] [12:57:06.607][End]workspace/buildOnlyDiagnosticIds"
}
[Trace - 4:57:08 PM] Sending request 'textDocument/diagnostic - (45)'.
Params: {
"textDocument": {
"uri": "file:///Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs"
},
"previousResultId": "PublicDocumentPullDiagnosticsHandler(category: , source: ):1"
}
[Trace - 4:57:08 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] /Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs found in workspace Host"
}
[Trace - 4:57:08 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] [12:57:08.423][Start]textDocument/diagnostic"
}
[Trace - 4:57:08 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] PublicDocumentPullDiagnosticsHandler(category: , source: ) started getting diagnostics"
}
[Trace - 4:57:08 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] previousResults.Length=1"
}
[Trace - 4:57:08 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] Processing 1 documents"
}
[Trace - 4:57:08 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] Diagnostics were unchanged for DocumentDiagnosticSource: /Users/josh/Code/Fluxus/rp/tests/ResultsProcessor/ResultsProcessor.CoreAPI.Tests/RPCoreTests.cs in ResultsProcessor.CoreAPI.Tests (net8.0)"
}
[Trace - 4:57:08 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] Microsoft.CodeAnalysis.LanguageServer.Handler.Diagnostics.Public.PublicDocumentPullDiagnosticsHandler finished getting diagnostics"
}
[Trace - 4:57:08 PM] Received response 'textDocument/diagnostic - (45)' in 3ms.
Result: {
"kind": "unchanged",
"resultId": "PublicDocumentPullDiagnosticsHandler(category: , source: ):1"
}
[Trace - 4:57:08 PM] Received notification 'window/logMessage'.
Params: {
"type": 4,
"message": "[LanguageServerHost] [12:57:08.423][End]textDocument/diagnostic"
}

Environment information
VSCode version: 1.87.0
C# Extension: 2.15.30
Using OmniSharp: false
Dotnet Information
.NET SDK:
 Version:           8.0.100
 Commit:            57efcf1350
 Workload version:  8.0.100-manifests.6c33ef20
Runtime Environment:
OS Name:     Mac OS X
OS Version:  14.3
OS Platform: Darwin
RID:         osx-arm64
Base Path:   /usr/local/share/dotnet/sdk/8.0.100/
.NET workloads installed:
Workload version: 8.0.100-manifests.6c33ef20
There are no installed workloads to display.
 I had to remove
    <GenerateTargetFrameworkAttribute>false</GenerateTargetFrameworkAttribute>

from my csproj


IC-1505: Upload daily snapshots to Analytical Platform

What does this pull request do?
Periodically exports all tables to CSVs and then uploads those into a timestamped "folder" in an Analytical Platform S3 "landing" bucket for further analytical processing
It is scheduled for 1 am every day (UTC)
🙋 Uses the new data-engineering-data-extractor image: https://github.com/ministryofjustice/data-engineering-data-extractor/pull/4
🙋 The s3://hmpps-interventions-dev-landing bucket is provisioned by the Analytical Platform, but access to it is controlled via https://github.com/ministryofjustice/cloud-platform-environments/pull/4604
Depends on

[x] https://github.com/ministryofjustice/data-engineering-data-extractor/pull/4
[x] https://github.com/ministryofjustice/cloud-platform-environments/pull/4604
[x] https://github.com/ministryofjustice/cloud-platform-environments/pull/4607
[x] https://github.com/ministryofjustice/data-engineering-data-extractor/pull/6
there will be further PRs to add the policy/buckets to other environments

What is the intent behind these changes?
To enable the analysis and processing of interventions data.

looks good - do we need to extract all tables? what about the migration tables etc?

yeah, all tables are fine for analytical platform, even the internal ones

🙇♂ Thank you!


The article wrongly assumes that ALL customers have the aks-preview e…

…xtension already installed
Running "az extension update --name aks-preview" may result in "The extension aks-preview is not installed".  For those customers, "az extension add --name aks-preview" should be run beforehand.  Please consider updating the article.

@gamcmaho : Thanks for your contribution! The author(s) have been notified to review your proposed change. @saudas

Hi @sauryadas -  Could you review the proposed changes?
Also, to support automated author notification, would you update the article metadata to use your Microsoft-linked GitHub username for the author value? Thanks.

already updated .. please check latest live docs

thanks @sauryadas and @gamcmaho . can this PR be closed? if so, please type #please-close into a comment. thanks.

#please-close


aria_dataset_downloader fails to download a complete sets of data

Hi team,
Thanks for the great work.
When I use aria_dataset_downloader to download the DTC data (including DTC objects and DTC Aria videos), the downloading process runs fine, but after the download is complete, the concluding printing prompt says that:
"2303/2396 objects are downloaded" (some text like this)
I tried this a couple of times, and the successfully downloadable objects vary, e.g., the next time I try downloading, it gets 2234 objects out of 2396 objects.
This also happens when I download the DTC Aria videos.
This did not happen to DTC DSLR data (105/105 are successfully downloaded).
Below are the commands I used:
(for Aria videos)
aria_dataset_downloader -c $HOME/Downloads/DTC_download_urls.json
-o $HOME/Documents/projectaria_tools_dtc_aria/
-d 0 1 2 3 6
(for objects)
dtc_object_downloader  -c $HOME/Downloads/DTC_objects_download_urls.json -o $HOME/Documents/projectaria_tools_dtc_object
The json files are downloaded from the DTC website: https://www.projectaria.com/datasets/dtc/
Thank you!

Thanks @KovenYu ! Our team is looking into this issue.

When downloading the object, I encountered an error indicating that releases were missing, but the JSON file contains the releases. However, when downloading the other two files, no such issue occurred.


socket.socket undefined using TLS on Node 0.12.7

When trying to connect using ldapjs.createClient({url: 'ldaps://url.to.ldap.tld:636/'}), I'm getting this stack on Node 0.12.7:
TypeError: Cannot read property 'on' of undefined
    at setupSocket (c:\Users\E0234544\Projets\TM4ALL\node_modules\ldapjs\lib\client\client.js:111:14)
    at Client._connect (c:\Users\E0234544\Projets\TM4ALL\node_modules\ldapjs\lib\client\client.js:742:3)
    at new Client (c:\Users\E0234544\Projets\TM4ALL\node_modules\ldapjs\lib\client\client.js:247:22)
    at Object.createClient (c:\Users\E0234544\Projets\TM4ALL\node_modules\ldapjs\lib\client\index.js:60:12)

The code there is:
  // Since tls.socket doesn't emit 'close' events, we must register to receive
  // them on net.socket instead
  var closeSocket = (opts.secure ? socket.socket : socket);
  // On close we have to walk the outstanding messages and go invoke their
  // callback with an error.
  closeSocket.on('close', function onClose(had_err) {

opts.secure equals to true but socket.socket doesn't exist (is undefined).
Moreover, looking at the Nodejs tls.connect() API, I don't understand why a distinction is done between secured (using tls API, and calling socket.socket) and unsecured (using net API and calling directly socket) connections.
I'm using node-ldapjs v0.7.1.

Using latest dev version ("dependencies": {"ldapjs": "mcavage/node-ldapjs#acc1ca8f4314fd9d67561feabc8ce4c235076a5e"}) fixed this issue.

Yes, I have this issue with any of the node 0.12.x builds.  okay for 0.10.36

Hi @mcavage, have you got an ETA to cut new release out of master and push to npm? This issue blocking us a bit as we switched to 0.12.

0.8.0 is mostly ready, save for updated documentation.
I have not been able to find time to work on it recently.

How were you able to install this on node 0.12. As per Issue #281, didn't think this could be installed...?

I just put "ldapjs": "mcavage/node-ldapjs#acc1ca8f4314fd9d67561feabc8ce4c235076a5e" as an npm dependency for my project in my package.json.

Hi @pfmooney . Thanks for working on this project!
Do you have any estimate on when a new version will be released that includes this fix?

I'm working on finishing updates to the documentation.
When that is done, I'll cut the release.

1.0.0 has been released with updated dependencies

I get below error  Invalid data, chunk must be a string or buffer, not object
at Socket.write (net.js:696:11)

⚠ This issue has been locked due to age. If you have encountered a recent
problem that seems to be covered by this issue, please open a new issue.
Please include a minimal reproducible example
when opening a new issue.


Define contrainsts for ULEB128

Binutils [1] and a currently in-flight LLD patch [2] define ULEB128 such that a SUB_ULEB128 must be preceded by a matching SET_ULEB128. This means that if the first SET_ULEB128 that comes before a given SUB_ULEB128 does not have the same relocation address, the linkers will fail. A SET_ULEB128 also cannot appear alone.
Define this behavior in psABI such that libraries that read relocations are able to make this same assumption.
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elfnn-riscv.c;h=09aa7be225ef3cba23fefd2ee977b3556a51368c;hb=HEAD#l2506
[2] https://reviews.llvm.org/D142880

Just add few more linker expert to view, but will commit this Friday IF no further comments.

I don't think they have to be consecutive pair. We probably should say that two relocations that refer to the same location are processed in-order. That means if a SET_ULEB128 appears before a SUB_ULEB128 in the relocation table, we'll get the desired outcome.

For SUB_ULEB128, I think it is fine to say that it must be paired with a SET_ULEB128 immediately before.
For SET_ULEB128, technically we can allow flexibility: it is fine to say that it can be used independently or paired with a subsequent SUB_ULEB128. In reality, a lone SET_ULEB128 seems not useful and we probably don't want to recommend its use.

Can anybody shed light on why GNU ld and lld require them to appear as a pair? In mold, we don't have such restrictions, and it seems they are working just fine; SET_ULEB128 writes a value, and SUB_ULEB128 reads the value, subtracts another value from it and then writes back the result.

It looks like that's how lld handles SET6 and SUB6 relocations; lld only requires SET6 precedes SUB6 if they refer to the same location, and they don't have to be consecutive. I wonder why lld can't do the same for SET_ULEB128 and SUB_ULEB128.

Can anybody shed light on why GNU ld and lld require them to appear as a pair? In mold, we don't have such restrictions, and it seems they are working just fine; SET_ULEB128 writes a value, and SUB_ULEB128 reads the value, subtracts another value from it and then writes back the result.

There’s only enough space guaranteed for the final result, but the SET might need more bytes.

I don't think they have to be consecutive pair. - rui314

For SUB_ULEB128, I think it is fine to say that it must be paired with a SET_ULEB128 immediately before. - MaskRay

I don't believe the wording I have proposed specifies that the SET must come immediately before.

Must be paired with the first SET_ULEB128 that comes before this

This wording I used was meant to be interpreted to mean that the SET can come anywhere before the SUB in the list of produced relocations. Should the wording be updated to enforce that they must be consecutive?

There’s only enough space guaranteed for the final result, but the SET might need more bytes.

That's not limited to SET_ULEB128. We have {SET,SUB}_{6,8,16,32,64,ULEB128}. What's special about ULEB128?

I would say that's kind of implementation limitation, and this limitation is make implementation  easier, since we must handle two relocation together, we can write more complicated logic to handle that right but seems not gain to much rather than give it few more constraint.
But why no similar issue for {SET,SUB}_{6,8,16,32,64}? because they are fixed length, and based on the general exception of linker relaxation is the symbol difference can be only shorter, so NO overflow is expected, then that could be handle separately is fine.

Thank you @kito-cheng, so here is my understanding. Can you confirm if we're on the same page?

unlike other SET/SUB relocations, we can't determine the distance between two symbols for SET_ULEB128/SUB_ULEB128,
we want to report an error if the calculated value doesn't fit, and
mandating SET_ULEB128/SUB_ULEB128 to appear together as a pair makes the diagnostics easier.

If that's the case, I think mandating them to appear as a pair makes sense. (I wasn't against the idea; I was just trying to understand the rationale behind it.)

@rui314 I believe your understanding is correct

Thanks for the clarification! Then, perhaps we should specify that the two relocations must appear consecutively? By doing so, we can essentially treat the two relocations as one, which I think would greatly simplify the implementation.

That is fine with me, I can change the wording if other people are okay with that @kito-cheng

Sorry for the late reply, I was out of office after attending LLVM dev conf, and back now :)
I think it's OK to constrain that more stricter: 1) Current assembler implementations are satisfied that constraint, 2) Current and proposed linker implementations are work well with that, 3) easier handling.
@rui314 thanks for the suggestion!

LGTM

Related question: since this is unsigned LEB, the result of a SET minus a SUB should be positive, but how does the compiler guarantee it if it doesn't know the final layout? What exactly is the use case of this relocation?

DWARF call sites are encoded as an address or unsigned offset, typically ULEB128 (unless not present, in which case they're an absolute 0 address). Toolchains previously had to turn off using ULEB128 for RISC-V and use less efficient encodings instead, but this allows them to make RISC-V look more normal and use ULEB128 again.

If a pair of SET and SUB relocations are used to calculate an unsigned offset, wouldn't the compiler already know the maximum possible offset? I'm wondering if we can trigger a relocation overflow error for the pair without it being a compiler bug.

If a pair of SET and SUB relocations are used to calculate an unsigned offset, wouldn't the compiler already know the maximum possible offset?

Yes, hence how it's possible to know how much to pad the .uleb128 by to ensure there are enough bytes to avoid overflow. Otherwise it just wouldn't work.

Ah, if that's the case, we don't need to check for overflow in the linker for ULEB128 relocations, do we? While detecting a compiler bug early on is beneficial, the psABI spec shouldn't require the linker to do that. Instead, it should be an optional measure the linker can adopt for all SET/SUB relocation pairs, not just ULEB but other types as well, if they chose to verify the input rigorously. I believe we should revert this change.

The linker should report errors if the length of ULEB128 byte sequence is more extended than the current byte sequence.

s/should/can/?
This patch is correct and adds more constraints to producers: "Must be placed immediately before a SUB_ULEB128 with the same offset. Local label assignment <<uleb128-note,*note>>"
Relocation overflow checking is an optional feature that linker are not obliged to implement. Personally I recommend implementing it.

Then why stop here and impose this restriction only for ULEB? If it's recommended to find a compiler bug, it looks like it is hard to justify doing it only for ULEB and not for {SET,SUB}{8,16,32,64} relocations.

More context for the demand of ULEB128: dwarf5 has add few new records are only available with ULEB128 encoding, unlike other record can using alternative encoding.

The linker should report errors if the length of ULEB128 byte sequence is more extended than the current byte sequence.

Both LLD (proposed patch) and ld.bfd has implement the check, will report error and abort.

Then why stop here and impose this restriction only for ULEB? If it's recommended to find a compiler bug, it looks like it is hard to justify doing it only for ULEB and not for {SET,SUB}{8,16,32,64} relocations.

Yeah, we may also implement overflow check for {SET,SUB}{8,16,32,64} too, generally it means something wrong when overflow happened.

Yeah, checking for overflow in the linker if SET and SUB are consecutive in the relocation table is perhaps a good practice to detect compiler bugs. However, isn't it odd that the psABI mandates the linker to do it in this specific case? I believe the confusion arises from the misconception that only {SET, SUB}_ULEB128 can overflow in a valid use case. This isn't true unless the compiler is buggy.

The reason I was interested in this was that I noticed that LLVM and binutils both implemented this constrained version and I am writing a library that consumes relocations that would like to use the same assumption. The library is module loading in the Linux kernel<EMAIL_ADDRESS>It is preferable to have the same behavior of the module linker as a user would expect from using binutils or LLVM. However, without this psABI requirement, it would not be valid to implement this restriction and the behavior could be different.

@charlie-rivos It turned out that the relocation overflow should never occur because the compiler knows the maximum length of a ULEB value when they create object files. So the exact behavior would be the same if you handle {SET,SUB}ULEB128 in the same way as {SET,SUB}{8,16,32,64}. It seems to me that the original GNU ld code was written with a misconception that only the ULEB128 relocations could overflow, and the behavior was copied to lld without further investigation. I don't think you need to mimic that behavior; it looks like it'd just complicate your logic. I do see it as an opportunity to simplify your patch.
For the mold linker, I'll keep handling {SET,SUB}_ULEB128 in the same way as we do for the other {SET,SUB} relocations.
@MaskRay Maybe you want to simplify the logic for lld too? These relocations can be handled individually just like other SET/SUB relocations. You might want to keep the overflow check as an assertion that works only when SET and SUB happen to be consecutive, but if you do that, you probably should do for all SET/SUB relocation paris (or don't do it for all SET/SUB).

Yeah, checking for overflow in the linker if SET and SUB are consecutive in the relocation table is perhaps a good practice to detect compiler bugs.

Agree.

However, isn't it odd that the psABI mandates the linker to do it in this specific case? I believe the confusion arises from the misconception that only {SET, SUB}_ULEB128 can overflow in a valid use case. This isn't true unless the compiler is buggy.

Agree. My mindset is: unless the wording says that no-checking is performed (like AArch64 *_NC), I assume that the relocation type needs checking.
The text should probably state that when R_RISCV_SET16/R_RISCV_SUB16 is used as a composed sequence (i.e. multiple consecutive relocation records are applied to the same relocation location), the difference is checked to be within the range [0,65535], instead of requiring the two S+A values to be within the range.

@charlie-rivos It turned out that the relocation overflow should never occur because the compiler knows the maximum length of a ULEB value when they create object files. So the exact behavior would be the same if you handle {SET,SUB}ULEB128 in the same way as {SET,SUB}{8,16,32,64}. It seems to me that the original GNU ld code was written with a misconception that only the ULEB128 relocations could overflow, and the behavior was copied to lld without further investigation. I don't think you need to mimic that behavior; it looks like it'd just complicate your logic. I do see it as an opportunity to simplify your patch.

lld/ELF/Arch/RISCV.cpp just doesn't check overflows for R_RISCV_{ADD,SET,SUB}* :)
I think this is reasonable as the semantics are still unclear and the return on investment isn't significant enough.

@MaskRay Maybe you want to simplify the logic for lld too? These relocations can be handled individually just like other SET/SUB relocations. You might want to keep the overflow check as an assertion that works only when SET and SUB happen to be consecutive, but if you do that, you probably should do for all SET/SUB relocation paris (or don't do it at all for all SET/SUB).

lld hasn't implement R_RISCV_SET_ULEB128 yet.
I am still waiting on the reviews for the assembler patch https://reviews.llvm.org/D157657

lld/ELF/Arch/RISCV.cpp just doesn't check overflows for R_RISCV_{ADD,SET,SUB}* :)

LD also doesn't check overflows for ADD/SET/SUB.  Currently we write the value back to the data filed immediately when handing each ADD/SET/SUB.  I tried to add the overflow checks for each of them, but met troubles since gcc may generate s ADD32/SET32/SUB32 under medany, which means the symbols may be 64-bit and will break the overflow checking every time.  A solution is that we should have an internal structures, including linked list or hash tables, to record the changes of values for each data field, and then write back the final values and check overflows until reviewed every ADD/SET/SUB relocations.

However, isn't it odd that the psABI mandates the linker to do it in this specific case? I believe the confusion arises from the misconception that only {SET, SUB}_ULEB128 can overflow in a valid use case. This isn't true unless the compiler is buggy.

Agreed.  Since we haven't supported the overflow checks for ADD/SET/SUB, so the easier and fastest way is to add the limitations to make SET_ULEB128/SUB_ULEB128 relocations work.  It's fine to remove those limitations from gnu toolchain, and maybe it's time to also add the overflow checks for ADD/SET/SUB/ULEB128 since they are the same issue from the implementation aspect.


Add launch_service_c changes for pool test

I forgot to push some commits. Rejecting

Never mind I added the changes. Reopening.


UART Abstraction hangs in otPlatUartFlush

I have an nrf52840 dongle, flashed to ot-cli-ftd from head (5b0429ecf6cb4837080d8adb6aceb8c5eb2fc026).
Right after reset, if I execute router table eleven times, it hangs in otPlatUartFlush, with (sUsbState.mTransferInProgress && !sUsbState.mTransferDone) == true indefinitely.
When I connect to a network and print some tables it hangs a lot faster, so I guess it's in some way proportional to the amount of output?

@TPolzer , thanks for raising this issue. I was able to reproduce your issue using the latest main branch (856c280bed73ba8846ded933ab4cf758e9af2dae).
@MarekPorwisz , can you help take a look?

If I insert a call to nrf5UartProcess() inside the loop in otPlatUartFlush (it clearly needs to be there), it prints a spurious newline instead of getting stuck. No idea where that's coming from, maybe that's actually a bug in the cli example?

@LuDuda @MarekPorwisz , can someone help with this issue?

@TPolzer Looks like the events on usb bus aren't handled/triggered correctly when we are near to end of capacity of sTxBuffer seems that incorrect params are passed to TX function.
The reason that adding nrf5UartProcess helps is because that function calls app_usbd_event_queue_process which triggers usbd events resumes the transfer.
Never the less I'm trying to figure out what is happening.

Resolved by #255


Arma 3 app disappear

Can you add Arma 3 app again? Looks like you deleted it
See previous PR https://github.com/Awes0meHub/caprover-one-click-apps/pull/78
Thanks

Done!


benchmarks: add a script to do a very fast check of which benchmarks changed.

Runs ~ 1 min to compare two benchmark builds.
Based on @palimondo's proposal to reduce the iteration count and increase the sample count.

@swift-ci smoke test and merge

@swift-ci smoke test and merge

@swift-ci smoke test and merge


variable is null checked but property is accessed without any null check

Variable 'config' is null checked here, but its property is accessed without null check afterward at line 35.
source file location :

frontend/src/app/welcome-banner/welcome-banner.component.ts

Hi! I I suppose my "you should habe opened a PR" remark in #1606 wasn't that smart... Please consider the following: Your IDE obviously finds some presumed code smells and you want to help out fixing them. So far all good. Now you send a GH issue for one and two separate PRs for two others. Those 2 PRs both fail our own code linting, which tells me that you didn't bother running it locally before pushing the fix and opening the PR. Oh, and your #1608 included the changes from #1607 once again, making #1607 obsolete anyway. Last but not least you introduced a totally unnecessary variable emailConfig where the better code fix would have been to remove the ternary operator on https://github.com/bkimminich/juice-shop/blob/f7e89ba5da9e5ac57632421292b9c82ad346b8c4/data/datacreator.js#L629 and https://github.com/bkimminich/juice-shop/blob/f7e89ba5da9e5ac57632421292b9c82ad346b8c4/data/datacreator.js#L638 because - unless I'm overlooking something - isn't needed as email won't be undefined in any case - as you noticed.
Don't get me wrong, I appreciate contributions to improve code quality a lot, but please don't make me review oneliner PRs if you plan to do more than one fix anyway. Please add commits to a single PR for that purpose, make sure our linter doesn't break, please don't introduce stuff that is weirder than what we had before, just because some IDE or other tool might recommend it.


Compile error when cross-compiling to armv7-linux-androideabi.

error[E0308]: mismatched types
   --> D:\AppData\Languages\Cargo\registry\src\index.crates.io-6f17d22bba15001f\atomic-write-file-0.2.1\src\imp\unix\mod.rs:249:43
    |
249 |         let mode = Mode::from_bits_retain(stat.st_mode);
    |                    ---------------------- ^^^^^^^^^^^^ expected `u16`, found `u32`
    |                    |
    |                    arguments to this function are incorrect
    |
note: associated function defined here
   --> D:\AppData\Languages\Cargo\registry\src\index.crates.io-6f17d22bba15001f\nix-0.29.0\src\sys\stat.rs:29:1
    |
29  | / libc_bitflags! {
30  | |     /// "File mode / permissions" flags.
31  | |     pub struct Mode: mode_t {
32  | |         /// Read, write and execute for owner.
...   |
61  | |     }
62  | | }
    | |_^
    = note: this error originates in the macro `$crate::__impl_bitflags` which comes from the expansion of the macro `libc_bitflags` (in Nightly builds, run with -Z macro-backtrace for more info)
help: you can convert a `u32` to a `u16` and panic if the converted value doesn't fit
    |
249 |         let mode = Mode::from_bits_retain(stat.st_mode.try_into().unwrap());
    |                                                       ++++++++++++++++++++

For more information about this error, try `rustc --explain E0308`.
error: could not compile `atomic-write-file` (lib) due to 1 previous error

What target are you trying to build the library?
I think we can simply do a cast here as the platform should at least guarantee that these things will work even though inconsistencies exist. This cast is not necessary on all the platforms, so clippy::unnecessary_cast is probably needed to make clippy happy.

Thanks for reporting this issue & submitting a fix. The fix is now part of the latest release: https://crates.io/crates/atomic-write-file/0.2.2
To catch this and similar issues in the future, I extended the GitHub workflow to build and test the crate on a large variety of platform and ABIs using cross. You can see an example run here: https://github.com/andreacorbellini/rust-atomic-write-file/actions/runs/11654980927


Making footer adding the icons and imp information and links

feature
add GSOC EXT and hacktoberfest label to it

I’d like to request to be assigned this issue.

Hey Please assign this to me as I have a good experience in web development as I worked as an intern at Metacrafters.

i want to fix this issue  Please assign this to me.

/assign

I would like to work on this @arushi2610

I would like to work on this @arushi2610

yes

@arushi2610 hey kindly assign this issue to me i want to work on this

if this issue is open can i work on it


Support for DRF-3.0+

Thanks @erfaan! I have not really used DRF 3 yet, but I think your modification looks decent. I think we should probably keep to_native() in there as well though, in order to retain support for DRF < 3.0.
This repo is in a kind of (stalled) work in progress state on my part, but I've been thinking of cleaning things up and submitting it to PyPi as it's sparked some (in all fairness quite minor) interest on Github in the last few months. Perhaps there are a few other DRF+sorl related tricks that we could include in such a release as well?


Define reinterpret intrinsics between vector boolean types and LMUL=1 (m1) vector integer types

Resolves #156.
The LLVM implementation is
D149642 [RISCV] Support vreinterpret intrinsics between vector boolean type and m1 vector integer type

Merging this upon approval and given that LLVM has a patch ready (mentioned in the PR's description).

Thanks @eopXD . Just FYI, the GCC upstream has implemented this VREINTERPRET intrinsic already.