[Feature] [E2E-INFRA] Request to make kind file configuration expandable with system environment

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Description
Request to make kind file configuration expandable with system environment.
Use case
E2E configuration sample:
setup:
  env: kind
  file: common/kind-$K8S_VERSION.yaml

And there are several kind configurations in common folder:
common
├── kind-1.19.yaml
├── kind-1.20.yaml
├── kind-1.21.yaml
└── kind-1.22.yaml

Then, we could create a matrix E2E testing in GitHub Action, such as:
jobs:
  Install:
    name: XYZ
    runs-on: ubuntu-latest
    timeout-minutes: 60
    strategy:
      matrix:
        k8sVersion: ["1.19", "1.20", "1.21", "1.22"]
    steps:
      - uses: actions/checkout@v2
      -
      - name: Run E2E Test
        uses: apache/skywalking-infra-e2e@feat/expand-env-for-kind-config-path
        env:
          K8S_VERSION: ${{ matrix.k8sVersion }}
        with:
          e2e-file: $GITHUB_WORKSPACE/test/e2e/cases/xyz/e2e.yaml

Related issues
No response
Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Assigned to you already. This seems reasonable when face multiple versions of k8s testings, like in KubeSphere cases.


Access Violation in EnumRows

Hello, anyone knows how to fix? It happens when I'm loading a certain GDB folder.
Hello, I'm encountering an access violation when calling EnumRows.Next. It happens when I'm loading the attachedn GDB folder. Any ideas?
Exception thrown at 0x00007FFE19D3BC60 (FileGDBAPID.dll) in Samples.exe: 0xC0000005: Access violation reading location 0x000001C48DFF1000.

Same here, unless I do not retrieve the shape, then there is no issue.
Getting the shape contents gives the error, pretty randomly, sometimes after 162 rows, sometimes after 512 rows.
I also tested your FileGDB in QGIS and it shows strange artifacts.

Hi @Pat28 , just solved my issue. Our GDB exporter caused the crash on import due to empty ShapeBuffer set in Row.SetGeometry.

Ah, that explains why rendering in QGIS and other applications did work, probably because the empty entry was not part of the spatial index and hence, ignored.

I think EnumRows.Next should throw an exemption when the geometry is empty so that we can catch it.


Full(er) JSON Schema support for tool calling

Currently parameters in tool definition is a very limited subset of a JSON Schema. This makes it non-compatible with OpenAI (https://github.com/ollama/ollama/issues/6155) and it general it makes it really hard to use it because you cannot pass JSON Schema as parameters but have to manually map to the API structure tool definition expects. Good enough if you are manually making a tool definition, but hard if you have automatic process to generate JSON Schema (for example, I use https://github.com/invopop/jsonschema Go package to generate JSON Schema from Go struct automatically, which works great with other API providers like OpenAI).
So I would suggest that API is relaxed to get embedded JSON Schema and not just fixed structure it currently allows.

Also the Parameters struct from ToolFunction should be an exported symbol in Go API so that it is possible to unmarshal JSON directly into that struct.

I would also like to bring attention to this addition. It seems like tool calling jsons only go two levels deep at the point that the prompt is generated. Any extra nested properties or keys beyond are truncated. This limits ability for complex tooll calls.


How can i launch aerender and pass script to it?

Describe your question, attach logs, images or anything that might help to better understand it.
Question is not a bit related to nexrender...
How can i pass script (jsx) to aerender so it will run script and render video?

It is not possible to do in the default aerender.


Node 12+ required to run the extension locally

Hello there,
just noticed that a recent change from https://github.com/sindresorhus/refined-github/pull/3171 is making the extension runable only on Node 12+.
I reckon this is coming from the use of Object.fromEntries in webpack.config.ts (i.e. https://github.com/sindresorhus/refined-github/blame/fe806803b0a6cc6e473e5e10d00a00fb5571a178/webpack.config.ts#L51 or https://github.com/sindresorhus/refined-github/blame/fe806803b0a6cc6e473e5e10d00a00fb5571a178/webpack.config.ts#L98).
I couldn't see any mention of that requirement anywhere, so I wondered if it had been done on purpose? If it wasn't, maybe it's worth a note somewhere (or we could add an engines property in the package.json for example)?

engine is only read from dependencies, it doesn't affect the local package/app.
For the record, this is the full error. It appears regardless of the engine and honestly I don't think there's a way to suggest a node version other than just writing it on contributing.md
❯ npm run build

> @ build .
> run-p build:* --continue-on-error

> @ build:typescript .
> tsc --noEmit

> @ build:webpack .
> webpack --mode=production

./webpack.config.ts:51
        entry: Object.fromEntries([
               ^
TypeError: Object.fromEntries is not a function
    at Object.<anonymous> (./webpack.config.ts:51:16)
    at Module._compile (./node_modules/webpack-cli/node_modules/v8-compile-cache/v8-compile-cache.js:192:30)
    at Module.m._compile (./node_modules/ts-node/src/index.ts:858:23)
    at Module._extensions..js (internal/modules/cjs/loader.js:827:10)
    at Object.require.extensions.(anonymous function) [as .ts] (./node_modules/ts-node/src/index.ts:861:12)
    at Module.load (internal/modules/cjs/loader.js:685:32)
    at Function.Module._load (internal/modules/cjs/loader.js:620:12)
    at Module.require (internal/modules/cjs/loader.js:723:19)
    at require (./node_modules/webpack-cli/node_modules/v8-compile-cache/v8-compile-cache.js:161:20)
    at WEBPACK_OPTIONS (./node_modules/webpack-cli/bin/utils/convert-argv.js:114:13)
    at requireConfig (./node_modules/webpack-cli/bin/utils/convert-argv.js:116:6)
    at ./node_modules/webpack-cli/bin/utils/convert-argv.js:123:17
    at Array.forEach (<anonymous>)
    at module.exports (./node_modules/webpack-cli/bin/utils/convert-argv.js:121:15)
    at yargs.parse (./node_modules/webpack-cli/bin/cli.js:71:45)
    at Object.parse (./node_modules/webpack-cli/node_modules/yargs/yargs.js:567:18)
    at ./node_modules/webpack-cli/bin/cli.js:49:8
    at Object.<anonymous> (./node_modules/webpack-cli/bin/cli.js:366:3)
    at Module._compile (internal/modules/cjs/loader.js:816:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:827:10)
    at Module.load (internal/modules/cjs/loader.js:685:32)
    at Function.Module._load (internal/modules/cjs/loader.js:620:12)
    at Module.require (internal/modules/cjs/loader.js:723:19)
    at require (internal/modules/cjs/helpers.js:14:16)
    at Object.<anonymous> (./node_modules/webpack/bin/webpack.js:156:2)
    at Module._compile (internal/modules/cjs/loader.js:816:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:827:10)
    at Module.load (internal/modules/cjs/loader.js:685:32)
    at Function.Module._load (internal/modules/cjs/loader.js:620:12)
    at Function.Module.runMain (internal/modules/cjs/loader.js:877:12)
    at internal/main/run_main_module.js:21:11

We define the version we test against in CI, we could link to that in
contributing.
On Mon, Jun 8, 2020, 11:35 AM Fregante<EMAIL_ADDRESS>wrote:

engine is only read from dependencies, it doesn't affect the local
package/app.
For the record, this is the full error. It appears regardless of the
engine and honestly I don't think there's a way to suggest a node version
other than just writing it on contributing.md
❯ npm run build

@ build .

run-p build:* --continue-on-error

@ build:typescript .

tsc --noEmit

@ build:webpack .

webpack --mode=production

./webpack.config.ts:51
    entry: Object.fromEntries([

           ^

TypeError: Object.fromEntries is not a function
at Object.<anonymous> (./webpack.config.ts:51:16)

at Module._compile (./node_modules/webpack-cli/node_modules/v8-compile-cache/v8-compile-cache.js:192:30)

at Module.m._compile (./node_modules/ts-node/src/index.ts:858:23)

at Module._extensions..js (internal/modules/cjs/loader.js:827:10)

at Object.require.extensions.(anonymous function) [as .ts] (./node_modules/ts-node/src/index.ts:861:12)

at Module.load (internal/modules/cjs/loader.js:685:32)

at Function.Module._load (internal/modules/cjs/loader.js:620:12)

at Module.require (internal/modules/cjs/loader.js:723:19)

at require (./node_modules/webpack-cli/node_modules/v8-compile-cache/v8-compile-cache.js:161:20)

at WEBPACK_OPTIONS (./node_modules/webpack-cli/bin/utils/convert-argv.js:114:13)

at requireConfig (./node_modules/webpack-cli/bin/utils/convert-argv.js:116:6)

at ./node_modules/webpack-cli/bin/utils/convert-argv.js:123:17

at Array.forEach (<anonymous>)

at module.exports (./node_modules/webpack-cli/bin/utils/convert-argv.js:121:15)

at yargs.parse (./node_modules/webpack-cli/bin/cli.js:71:45)

at Object.parse (./node_modules/webpack-cli/node_modules/yargs/yargs.js:567:18)

at ./node_modules/webpack-cli/bin/cli.js:49:8

at Object.<anonymous> (./node_modules/webpack-cli/bin/cli.js:366:3)

at Module._compile (internal/modules/cjs/loader.js:816:30)

at Object.Module._extensions..js (internal/modules/cjs/loader.js:827:10)

at Module.load (internal/modules/cjs/loader.js:685:32)

at Function.Module._load (internal/modules/cjs/loader.js:620:12)

at Module.require (internal/modules/cjs/loader.js:723:19)

at require (internal/modules/cjs/helpers.js:14:16)

at Object.<anonymous> (./node_modules/webpack/bin/webpack.js:156:2)

at Module._compile (internal/modules/cjs/loader.js:816:30)

at Object.Module._extensions..js (internal/modules/cjs/loader.js:827:10)

at Module.load (internal/modules/cjs/loader.js:685:32)

at Function.Module._load (internal/modules/cjs/loader.js:620:12)

at Function.Module.runMain (internal/modules/cjs/loader.js:877:12)

at internal/main/run_main_module.js:21:11

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/sindresorhus/refined-github/issues/3202#issuecomment-640739228,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGRMZCQMSRN7BQTXP4IEHDRVUHORANCNFSM4NYRFP6Q
.

We define the version we test against in CI

Actually we don't, we just use the default of ubuntu-latest, currently 12.16

We define the version we test against in CI

Actually we don't, we just use the default of ubuntu-latest, currently 12.16

https://github.com/sindresorhus/refined-github/blob/master/.github/workflows/test.yml#L25

Heh, indeed, but as the comment suggests, it's only there because our tests don't run on newer Node versions, not because they don't run on older. i.e. once https://github.com/sindresorhus/refined-github/issues/2900 is fixed, that line can be removed.

@arnaudvalle https://github.com/sindresorhus/refined-github/issues/2900 requires Node 13 (with warnings) or Node 14 (flawless).
What can we do to close this issue?

What can we do to close this issue?

To me, a simple Requirements section or notice somewhere on the contributing.md file would be enough.  Maybe just before Notions?
I'm happy to open up a PR if you're ok with that.


makealive doesn't understand apps properly, and also goes inside .gitignore files

rewrote the code and fixed the logic for how an app is detected. it's working now


Refactor browser tests to utilize the Page Object Pattern

See these Fluentlenium docs.
Off the top of my head, the following pages that already exist could likely benefit from having a Page Object:
In the admin view:

programs list
program edit
program block edit ("manage questions")
questions list
question edit

In the applicant view:

programs list
program block edit

This is obsolete now that we are no longer using Fluentlenium.


Implement the check function to dry up the codebase

Hello,
I have implemented the _check() function to dry up the code in the src/calculator.js file.
This is how the file looked like before

Here is how the file looked like after

Thank you so much @dantharejabot ! This is incredibly helpful and encouraging.


fix(core): fixed proto pollution

FIX this vulnerability for Swiper V5:

https://www.npmjs.com/advisories/1694
https://snyk.io/vuln/SNYK-JAVA-ORGWEBJARS-1244698

refs:

https://github.com/nolimits4web/swiper/commit/9dad2739b7474f383474773d5ab898a0c29ac178

Does this also need to check for constructor and prototype like this?
https://github.com/ionic-team/ionic-framework/pull/23344/files

I am afraid that will required a more work and not extend 'proto', 'constructor', 'prototype' props. Plus it needs correctly reference other Swiper instances (required for Thumbs and Controller to work correctly). To be honest last Swiper v5 was released almost a year ago, and I didn't plan new v5 releases for sure. Why just not copy v5 package locally and do the local changes instead?

@nolimits4web @hydRAnger I thought the one-line code was the fix in version 6 and it seems it would work for v5. Is it possible to deploy a new v5 with this change?

@nolimits4web @hydRAnger I thought the one-line code was the fix in version 6 and it seems it would work for v5. Is it possible to deploy a new v5 with this change?

according to your suggestion, what should I do for now?


kibana-upload-objects doesn't work in platform environments

Kibana deprecated managing the .kibana index manually, and logsearch-for-cloudfoundry (correctly) responded by updating kibana objects using the kibana API. In platform environments, since we're not using UAA, these scripts don't work for us, and can't be easily modified to do so.

This will become urgent eventually but is currently stable.


Fix for Canvas.rows() output being 1 row/col too large when Canvas::new() is passed particular values

I had made a Pull Request on /ftxqxd/drawille-rs, but noticed this fork and the issue where you were given ownership, so I thought I'd bring the Pull Request here as well.
This change could potentially be partially breaking (may alter output slightly) if a user relied on the potential empty margin that could appear on the bottom and right of the Canvas.

What is it?
Fixes ftxqxd/drawille-rs#14, where output string can be 1 row and/or col too large resulting in additional white space when given width is divisible by 2 and/or height is divisible by 4.
The only time this issue occurs is when Canvas::new() is called and the given width/height are divisible by the 'braille-pixel' ratio, where width is divisible by 2 and height by 4. For example if a width of 12 is given, the Canvas struct's width would be 6 and when rows() is called, the maxrow variable would be off by one and cause an additional empty column to appear in the output string. Another example, if a height of 4 is given, the Canvas' height would be 1 and when rows() is called, the maxcol variable would be set to 1, allowing the loop to run an additional iteration and inserting an empty row in the output string.
Prior to this fix, the following code:
let mut canvas = Canvas::new(2, 4);
for y in 0..4 {
    for x in 0..2 {
        canvas.set(x, y);
    }
}
dbg!(canvas.frame());

Would output the following:
[examples\test_canvas_properties.rs:14] canvas.frame() = "⣿ \n  "

And with the fix the output is instead:
[examples\test_canvas_properties.rs:14] canvas.frame() = "⣿"

What's the fix?
A fix for this issue would be to instead dynamically update the width and height member fields of Canvas whenever it is modified, with for example a check_bounds(u16,u16):
fn check_bounds(&mut self, row: u16, col: u16) {
   if self.width < row + 1 {
      self.width = row + 1;
   }
   if self.height < col + 1 {
      self.height = col + 1;
   }
}

And to also properly calculate the Canvas width and height in the constructor:
pub fn new(width: u32, height: u32) -> Canvas {
   let width_adjustment: u16 = if width != 0 && width % 2 == 0 { 0 } else { 1 };
   let height_adjustment: u16 = if height != 0 && height % 4 == 0 { 0 } else { 1 };
   Canvas {
      chars: FnvHashMap::default(),
      width: (width / 2) as u16 + width_adjustment,
      height: (height / 4) as u16 + height_adjustment,
   }
}

With these changes, the bounds checking for loop in Canvas.rows() can be removed and the loop ranges become exclusive rather than inclusive:
pub fn rows(&self) -> Vec<String> {
   let maxrow = self.width;
   let maxcol = self.height;

   let mut result = Vec::with_capacity(maxcol as usize + 1);
   for y in 0..maxcol {
      let mut row = String::with_capacity(maxrow as usize + 1);
      for x in 0..maxrow {
   // -- snip --
}

I could also include Canvas.get_width() and Canvas.get_height() additions if you wish, however you do have another Pull Request which has Canvas.width() and Canvas.height(), so that's up to you.
Let me know if I could do anything or if there's an issue with this Pull Request. Thanks!

Hello ! Sorry for the late response, I haven't got any notification from your PR. (Should be fixed now though)
I am not sure about dynamically increasing width and height whenever we try to draw outside of the boundaries. I'm afraid this behavior will mostly be seen as undesirable, for example if we accidentally set a pixel at pos 65535 the canvas will suddenly increase out of control.
I'd rather just ignore those out-of-bounds draws when they happen (so maybe make check_bounds return a true when the col and row are in bounds, and use that in a conditional statement for setting pixels and so on).
What are your thoughts about this ? It's not a closed discussion so feel free to either argument on your fix or propose anything else. 😄


"Invalid refinement level" on R5 weapons

Current Behavior
Scanner doesn't properly recognise the R5 weapon refinement and doesn't include them, because it thinks that refinement level is at -1. Scanner continues to run and outputs all weapons, except those with invalid refinement level into the JSON file.
I have this happening to all R5 weapons in my inventory when using the scanner. Weapons with other refinement levels don't have this issue. Delay for scanning is set to "Slow"
Expected Behavior
The scanner to correctly exports the data
Reproducing a Behavior

Select "Weapons" mode
Run the scanner till the end
Get output of the "Error Log" and cross-check it with the inventory

Device OS
Windows 10
Genshin Impact Version
4.1
Inventory Kamera Version
1.3.11
Screen resolution, screen mode, and UI scale
3840x2160 screen with 175% scaling. game in 3200x1800 windowed borderless (-screen-fullscreen 0 -popupwindow)
Additional notes and remarks
My theory is that different color of the box with number in it causes OCR to give up. My suggestion would be to read the text right to it, as it doesn't change the color and has the same information
Evidence

Unable to validate information for weapon ID#14
Invalid refinement level
Weapon ID: 14
Name: TheViridescentHunt
Rarity: 4
Level 90
Refinement: -1
Locked: False
Equipped character: Diona
Unable to validate information for weapon ID#15
Invalid refinement level
Weapon ID: 15
Name: Rust
Rarity: 4
Level 90
Refinement: -1
Locked: False
Unable to validate information for weapon ID#16
Invalid refinement level
Weapon ID: 16
Name: SacrificialBow
Rarity: 4
Level 90
Refinement: -1
Locked: False
Equipped character: Fischl
Unable to validate information for weapon ID#17
Invalid refinement level
Weapon ID: 17
Name: TheStringless
Rarity: 4
Level 90
Refinement: -1
Locked: False
Equipped character: Venti
Unable to validate information for weapon ID#18
Invalid refinement level
Weapon ID: 18
Name: FavoniusWarbow
Rarity: 4
Level 90
Refinement: -1
Locked: False
Equipped character: Gorou
Unable to validate information for weapon ID#20
Invalid refinement level
Weapon ID: 20
Name: SolarPearl
Rarity: 4
Level 90
Refinement: -1
Locked: False
Equipped character: ShikanoinHeizou
Unable to validate information for weapon ID#21
Invalid refinement level
Weapon ID: 21
Name: TheWidsith
Rarity: 4
Level 90
Refinement: -1
Locked: False
Equipped character: Lisa
Unable to validate information for weapon ID#22
Invalid refinement level
Weapon ID: 22
Name: TheCatch
Rarity: 4
Level 90
Refinement: -1
Locked: False
Equipped character: RaidenShogun
Unable to validate information for weapon ID#23
Invalid refinement level
Weapon ID: 23
Name: FavoniusLance
Rarity: 4
Level 90
Refinement: -1
Locked: False
Equipped character: Zhongli
Unable to validate information for weapon ID#26
Invalid refinement level
Weapon ID: 26
Name: SerpentSpine
Rarity: 4
Level 90
Refinement: -1
Locked: False
Equipped character: AratakiItto
Unable to validate information for weapon ID#27
Invalid refinement level
Weapon ID: 27
Name: PrototypeArchaic
Rarity: 4
Level 90
Refinement: -1
Locked: False
Equipped character: Noelle
Unable to validate information for weapon ID#28
Invalid refinement level
Weapon ID: 28
Name: CinnabarSpindle
Rarity: 4
Level 90
Refinement: -1
Locked: False
Equipped character: Albedo
Unable to validate information for weapon ID#31
Invalid refinement level
Weapon ID: 31
Name: IronSting
Rarity: 4
Level 90
Refinement: -1
Locked: False
Equipped character: KukiShinobu
Unable to validate information for weapon ID#33
Invalid refinement level
Weapon ID: 33
Name: SacrificialSword
Rarity: 4
Level 90
Refinement: -1
Locked: False
Equipped character: Xingqiu
Unable to validate information for weapon ID#34
Invalid refinement level
Weapon ID: 34
Name: FavoniusSword
Rarity: 4
Level 90
Refinement: -1
Locked: False
Equipped character: Kaeya
Unable to validate information for weapon ID#35
Invalid refinement level
Weapon ID: 35
Name: FadingTwilight
Rarity: 4
Level 80
Refinement: -1
Locked: False
Unable to validate information for weapon ID#36
Invalid refinement level
Weapon ID: 36
Name: OathswornEye
Rarity: 4
Level 80
Refinement: -1
Locked: False
Unable to validate information for weapon ID#38
Invalid refinement level
Weapon ID: 38
Name: SacrificialGreatsword
Rarity: 4
Level 70
Refinement: -1
Locked: False
Equipped character: Chongyun
Unable to validate information for weapon ID#39
Invalid refinement level
Weapon ID: 39
Name: LionsRoar
Rarity: 4
Level 70
Refinement: -1
Locked: False
Equipped character: Keqing
Unable to validate information for weapon ID#40
Invalid refinement level
Weapon ID: 40
Name: DodocoTales
Rarity: 4
Level 60
Refinement: -1
Locked: False
Equipped character: Klee
Unable to validate information for weapon ID#41
Invalid refinement level
Weapon ID: 41
Name: EyeOfPerception
Rarity: 4
Level 60
Refinement: -1
Locked: False
Unable to validate information for weapon ID#42
Invalid refinement level
Weapon ID: 42
Name: MissiveWindspear
Rarity: 4
Level 60
Refinement: -1
Locked: False
Unable to validate information for weapon ID#43
Invalid refinement level
Weapon ID: 43
Name: PrototypeStarglitter
Rarity: 4
Level 60
Refinement: -1
Locked: False
Unable to validate information for weapon ID#44
Invalid refinement level
Weapon ID: 44
Name: LuxuriousSeaLord
Rarity: 4
Level 50
Refinement: -1
Locked: False
Equipped character: Diluc
Unable to validate information for weapon ID#45
Invalid refinement level
Weapon ID: 45
Name: FavoniusCodex
Rarity: 4
Level 40
Refinement: -1
Locked: False
Unable to validate information for weapon ID#46
Invalid refinement level
Weapon ID: 46
Name: MailedFlower
Rarity: 4
Level 40
Refinement: -1
Locked: False
Unable to validate information for weapon ID#49
Invalid refinement level
Weapon ID: 49
Name: IbisPiercer
Rarity: 4
Level 20
Refinement: -1
Locked: False
Unable to validate information for weapon ID#52
Invalid refinement level
Weapon ID: 52
Name: PrototypeAmber
Rarity: 4
Level 20
Refinement: -1
Locked: False
Unable to validate information for weapon ID#53
Invalid refinement level
Weapon ID: 53
Name: SacrificialFragments
Rarity: 4
Level 20
Refinement: -1
Locked: False
Unable to validate information for weapon ID#56
Invalid refinement level
Weapon ID: 56
Name: DragonsBane
Rarity: 4
Level 20
Refinement: -1
Locked: False
Unable to validate information for weapon ID#58
Invalid refinement level
Weapon ID: 58
Name: Rainslasher
Rarity: 4
Level 20
Refinement: -1
Locked: False
Unable to validate information for weapon ID#59
Invalid refinement level
Weapon ID: 59
Name: ToukabouShigure
Rarity: 4
Level 20
Refinement: -1
Locked: False
Unable to validate information for weapon ID#62
Invalid refinement level
Weapon ID: 62
Name: Rust
Rarity: 4
Level 1
Refinement: -1
Locked: False
Unable to validate information for weapon ID#63
Invalid refinement level
Weapon ID: 63
Name: Rust
Rarity: 4
Level 1
Refinement: -1
Locked: False
Unable to validate information for weapon ID#64
Invalid refinement level
Weapon ID: 64
Name: SacrificialBow
Rarity: 4
Level 1
Refinement: -1
Locked: False
Unable to validate information for weapon ID#74
Invalid refinement level
Weapon ID: 74
Name: TheWidsith
Rarity: 4
Level 1
Refinement: -1
Locked: False
Unable to validate information for weapon ID#76
Invalid refinement level
Weapon ID: 76
Name: FavoniusCodex
Rarity: 4
Level 1
Refinement: -1
Locked: False
Unable to validate information for weapon ID#77
Invalid refinement level
Weapon ID: 77
Name: FavoniusCodex
Rarity: 4
Level 1
Refinement: -1
Locked: False
Unable to validate information for weapon ID#82
Invalid refinement level
Weapon ID: 82
Name: DragonsBane
Rarity: 4
Level 1
Refinement: -1
Locked: False
Unable to validate information for weapon ID#88
Invalid refinement level
Weapon ID: 88
Name: FavoniusGreatsword
Rarity: 4
Level 1
Refinement: -1
Locked: False
Unable to validate information for weapon ID#89
Invalid refinement level
Weapon ID: 89
Name: FavoniusGreatsword
Rarity: 4
Level 1
Refinement: -1
Locked: False
Unable to validate information for weapon ID#94
Invalid refinement level
Weapon ID: 94
Name: LionsRoar
Rarity: 4
Level 1
Refinement: -1
Locked: False
Unable to validate information for weapon ID#99
Invalid refinement level
Weapon ID: 99
Name: TheFlute
Rarity: 4
Level 1
Refinement: -1
Locked: False
Unable to validate information for weapon ID#101
Invalid refinement level
Weapon ID: 101
Name: ThrillingTalesOfDragonSlayers
Rarity: 3
Level 90
Refinement: -1
Locked: False
Equipped character: Sucrose
Unable to validate information for weapon ID#102
Invalid refinement level
Weapon ID: 102
Name: BlackTassel
Rarity: 3
Level 90
Refinement: -1
Locked: False
Equipped character: YunJin
Level 1
Refinement: -1
Locked: False
Preflight Checklist

[X] I have checked for similar issues in the issue page, and I have not found any similar to mine.
[X] I am using the latest version of the scanner.
[X] I tried setting the scanning delay to maximum, and it still doesn't work.
[ ] I have attached the video recording to the bug report.
[X] I have attached the error log to the bug report.
[X] I am available to later explains the issue.
[X] I have disabled all screen filtering software or plugins (i.e. HDR, Image Sharpening) while scanning.
[X] I use default in-game keybindings or have configured keybindings for the scanner.

This issue is a bit old. Can you please let me know if this still occurs in the latest version?

Hi, wasn't looking into this issue thread after few month and only now noticed.
I still have this exact issue on my system with latest version of the game, graphics drivers and tool in question.
No modifications to the game or system are made that would affect output image.

@Cupcak3 Finally had time to look into this issue as it was still bothering me. It was still happening to me
Issue was occuring on line 338 of WeaponScrapper as GenshinProcesor.AnalyzeText was returning empty string when was given refinement level 5.
My first guess was to set argument of numbersOnly to true, but it would only lead the code being stuck in a loop and not allowing anything to be scanned at all past first few weapons. I can't find any other code that uses this argument and should probably be just removed entirely.
Then I was trying different pageMode values and SingleChar fixed an issue and all weapons are now parsing properly.
If you can push this fix it would be amazing and finally resolve my long running issue with refinement level 5 scans. Thanks


get-progression turns 2-digits session labels to 3 digits

labels.tsv.zip
merged.tsv.zip
When I run
clinicadl tsvtools get-progression labels.tsv --time_horizon 36
and then
clinicadl tsvtools analysis merged.tsv labels.tsv analysis.tsv
I get the following error:
KeyError: ('sub-ADNI002S0685', 'ses-M048')
It comes from the fact that get-progression converts 2-digits session labels to 3-digits labels (e.g. ses-M48 to ses-M048) in labels.tsv, whereas they stay 2-digits labels in merged.tsv. To be more precise it is done by the function merged_tsv_reader called at the begining of get_progression.
https://github.com/aramis-lab/clinicadl/blob/ff2f892927a8304b171012486936ae38f3d9688c/clinicadl/utils/tsvtools_utils.py#L15-L25
So my question is: what is the purpose of converting 2-digits to 3-digits labels?
And a more general remark: shouldn't we switch the whole ClinicaDL to 3-digits labels to be consistent with Clinica? (see aramis-lab/clinicadl_handbook#23)

There is no problem if the labels.tsv and merged.tsv files already contain 3-digits labels, as they are outputted now by Clinica.


update images for git upstream

The images did not match the text and the text needed some improvement.
Signed-off-by: jetzlstorfer<EMAIL_ADDRESS>

Preview: https://deploy-preview-900--keptn.netlify.app/docs/0.8.x/manage/git_upstream/


tags specified with --select-tag are not added

when running a deck sync the tags used to select the entities from the Kong datastore, should also be added to the entities being added to Kong, but this doesn't happen.
So after a first sync;
deck sync --select-tag=tieske -s xxx.yaml

returns this summary (on a blank datastore):
Summary:
  Created: 44
  Updated: 0
  Deleted: 0

everything is added, but without a tag tieske.
The following command;
deck diff --select-tag=tieske -s xxx.yaml

should return a summary of doing nothing, but it actually returns;
Summary:
  Created: 44
  Updated: 0
  Deleted: 0

The cause being that the tag was not added, hence the 2nd command selects nothing and adds everything again.

Can confirm your deck version and share the file in question? It looks like this should be specific to the resource type. Selected tag info is added to the state builder, and afterward merged into the entity tag lists per entity, e.g. for consumers. That suggests there's probably some entity type that we missed that for.

$ deck version
decK v1.6.0 (c8f40a9)

file: https://gist.github.com/Tieske/4ecb2fd7089aa09563477064128c8ee3 (slightly different because of continued testing, but exhibits the behaviour described)

The file contains; service, upstream, routes, and plugins

while I was bugging @mflendrich for an eta on this, the thought crossed my mind that fixing this bug might maybe break existing users' workflows?
So maybe instead of fixing it we should embrace it and add an additional flag(s):

--add-tag that will add the listed tags to all entities in the state-file (overcoming this bug)
--replace-tag that will replace all existing tags on the entities in the state-file with this new set of tags (this would prevent teams from accidentally using eachothers tags and start syncing with other teams config)

Much-belated post-KIC 2.0 deck cleanup: https://github.com/Kong/deck/pull/517 resolves this in the simplest way possible, by just using --select-tag throughout.
@Tieske what were the workflows you thought of? Running through possibilities myself I can't think of any that make sense, since everything breaks once you try to sync again. The closest I can think of are users that did have select tag metadata in their state file and didn't notice the flag not actually doing anything to the target config, hence the PR's failure on mismatches.

Thx @rainest (was ooo for a while, so sorry for not responding earlier)


Consider updating speech api docker base image to newer version of Debian

Now Buster is out:
https://www.debian.org/releases/buster/

fixed by #64


cannot describe a typical XML-based REST API in OpenAPI/Swagger

I cannot describe a XML request/response that has different elements typed by the same complex type. That should be possible, as it is common practice in XML modeling (typically using XSD schemas).
Simple example: a customer has a billing address (element name: billing-address) and a residential address (residential-address).
Reasons:

in order to reuse a complex type, in OpenAPI I must create a definition object, and refer to this definition in the $ref field in the body of request/response
in order to declare the name, namespace, prefix and other XML-specific metadata in OpenAPI, I must declare a XMLobject (via a "xml" field)
however, as per the spec, whenever you use $ref, other values are ignored, IOW, I cannot define the name/namespace/prefix of the XML element

See swagger-api/swagger-ui#3469 and #556.

I'm not sure this limitation is specific to XML based payloads.  Whenever you reference a "reusable" resource you cannot modify or add to that reusable component.  That is a limitation of the $ref construct that we borrowed from JSON Schema.  The JSON Schema folks are working on alternative mechanisms but currently there is no ability to do this.
You are limited to defining the xml field in the reused definition.  Is there a reason this does not work for you?

@darrelmiller This is the key requirement: "different elements typed by the same complex type" - they would all be deemed to have the same element name. The linked swagger-ui issue includes an example.

@abstratt Ah, I understand.  Yes that is a limitation, however  I would argue that doing that in XML isn't a particularly wise thing. Elements usually have a different structure. If you just want a descriptive difference between elements then create a name attribute on the element.  I realize that is probably not possible to change the XML in your case.
From a longer term perspective, I would like to see the addition of XSD support to OpenAPI rather than trying to fix the Xml annotations.

Thanks for the idea @darrelmiller, but I hope we agree that is a workaround, and with some serious limitations. A customer may have two addresses (not three or more), a residential one, and a billing one. The latter is optional. That is trivial to model with XSD. It should be possible to model with Swagger as well.  But it is not, actually not even if you  use JSON (because you cannot reuse complex types, but only entire property definitions, including things like descriptions, 'requiredness', etc - please correct me if that statement is incorrect, as I see it as the root cause for the present issue, and a major design issue with OpenAPI/Swagger).

@abstratt JSON Schema doesn't make a distinction between complex types and schemas.  Unfortunately you are trying to do something that JSON Schema was designed to do.  Currently OpenAPI is somewhat constrained by the limitations of JSON Schema when it comes to description of payloads.  Hopefully that won't always be the case.

@darrelmiller Thanks. Here's hoping that changes soon. That is a serious drawback in JSON Schema, one which Swagger/OpenAPI should not be inheriting, as it limits the description of JSON-based APIs, and prevents description of many XML-based APIs.

I think that draft-07 (which should be published by November 20th) and draft-08 will help with this sort of thing.  And the relevant ideas in draft-07 don't technically require an implementation change.
draft-07 classifies keywords as data model, assertions, or annotations, and is more formal about how annotations are applied to instance data.  xml is an annotation keyword: it adds information to the instance that is used by other tools.  Note that this is not a change from draft-05, it's just giving names to things that were not called out clearly before.
Based on how we define annotations and the concept of applicability in draft-07, I would expect this to work:
propA:
  allOf:
    - $ref: '#/definitions/MyType2'
    - xml:
        name: prop-a

I assume that it does not in current OpenAPI implementations?
As for draft-08, it will focus on re-usability, including several issues around how things with allOf and/or $ref function.  There is a draft-08 milestone if you want to keep an eye on that.

This may seem off the wall, but JSON schema definition seems to be in the same state that XML was about a millenia ago at version 0.5 or some such.  My 2 cents worth is that OpenApi should not tie itself to an emergent standard that could well take many years to become operable.  By comparison, XML, XSLT, XSD family of technologies could well have resolved most of the issues being found with OpenAPI 3 et al had they been adopted as the underlaying schema definition.  Not suggesting it changes, just saying it's all been done before.

Wow, a good old XML vs JSON discussion. Just wanted to bring back https://blog.jclark.com/2010/11/xml-vs-web_24.html in the discussion. Coming from XML (maybe even from SGML) this post has changed my relationship with JSON almost 9 years ago. BTW, James is back after (also) almost 9 years of Blog silence to talk about Ballerina ;-)
Disclaimer: I still enjoy writing parsers for X12 and EDIFACT ;-)

@chippyash The alternate schema work that is ongoing will ensure that no-one is tied to any particular schema language.  Despite it's "draft" status, JSON Schema is far from emergent.  I would argue it has more real world traction than XML Schema ever did.
XML Schema has a fundamentally different world view than JSON Schema.  The XML Schema "closed world" principle does not fit nearly as well with the loosely coupled web.
I am and always will be a fan of XML and XSLT.  Less so of XML Schema, but XML tech just isn't the best tool for the job when describing payloads for HTTP APIs.

This issue is not really a contest between JSON or XML, but about a relevant gap in OpenAPI spec in which it does not allow a fairly common modeling pattern (multiple child objects of the same base type with different roles/under different names) for XML-based APIs, ironically due to a limitation in JSON Schema.
Hopefully OpenAPI can loosen this restriction soon, as many well designed XML based APIs out there cannot be modeled with OpenAPI, as it stands now.

@chippyash @patricekrakow @abstratt @darrelmiller Please note that we finally, after over a year of work, released the 2019-09 draft of JSON Schema yesterday.
In IETF terms, this consists of several draft-handrews-*-02 documents (there is a giant table of all of the versions and identifiers on json-schema.org now, explaining IETF vs meta-schema and why we're using dates now).
Of particular interest may be the hypothetical code generation example in Appendix E of the Core spec.  This is intended to illustrate some techniques related to how JSON Schema 2019-09 could be extended for code generation.
@darrelmiller and the rest of the OpenAPI TSC have been working with @philsturgeon and myself on the JSON Schema side to ensure that JSON Schema is a better platform for the needs of OAS.  Between proposals for improving compatibility of the Schema Object in OAS 3.1, and the alternate-schema work that @darrelmiller mentioned, I am optimistic about future functionality and alignment.

Oops. @patricekrakow I have to grin. I read James' blog about Ballerina too.  Kinda how I ended up here. Was very interested in it's OpenApi (although limited) capability, started to play, delved deeper into the standard and started to find some fundamental issues particularly in the nesting and multiple child arenas that @abstratt refers to.  I'm going to use OpenApi, but instruct my devs to use copious examples to get around the limitation in the definition itself. Just means we'll have to hand code those bits in our implementations. Anyone remember the processors you could inject in an XSLT definition to get round local difficulties?  ;-) Still going to use XML for my DI container definitions though! And @handrews, thanks for all the good work you and your colleagues are doing to even try and establish a standard for API definitions.

@chippyash 🙏
For XML definitely the alternate-schema work will be more helpful for you!  While the flexibility we've put into JSON Schema 2019-09 should eventually make it more possible to describe other things, having the ability to use XML Schema for XML payloads is something that I very much support.

@handrews I wasn't really saying I want to have the ability to specify XML schema, although having to support clients that use XML and JSON (and a few other strange things that I can't remember the names of) would most certainly be useful. It was more about applying the pain that was gone through in XMLs birth to the construction of a JSON schema definition. I've shied away from using JSON as a reliable data transport mechanism simply because I couldn't validate it reliably and have built whole libraries around doing just that. I welcome a standardised mechanism to do that validation whole heartedly. Sure XSDs can be a PITA to design and implement, but at least there is only one way to do it, (barring a few processor 'flavours'!).  I guess my observation was kind of asking does the JSON schema group have old buggers with that pain involved in bringing a new standard into the world? I don't know but I guess I kinda hope so.

I think it sounds like you have feedback on how JSON Schema works, or used to work, or need support on a certain use case, or something. This doesn't seem like a "XML in OpenAPI" conversation anymore though, so lets close this one down?
If JSON Schema cannot do what you want, and the XML Object is not good enough, then XML Schema in Alternative Schema is going to solve your problems when it gets done. So its a solved problem however you spin it.

Can we please have a link to the document describing how to model XML APIs in OpenAPI using the a "Alternative Schema" approach (which I confess I know nothing about) which avoids the limitation reported here?
If that is doable with a new approach (and the new approach is already available even if in beta form etc), yup, closing this issue makes sense.

Alternative Schema is a draft feature still being worked on, but it will allow XSD as @chippyash is requesting. People who want alternative Schema can join in various conversations about alternative Schema. #1993
The main “doing this in JSON Schema + xml keyword” issue is solved by OpenAPI raising support for JSON Schema Draft 2019-09 in #1977
So anyone interested in those two topics can track progress there. This issue is now superfluous, confusingly named, and sinking in slightly in accurate person opinions about JSON and JSON Schema in general, which will probably not lead anywhere constructive.

@philsturgeon i didn't start this thread. Far be it from me to close it down. It does however leave some unanswered questions, however uncomfortable they are. By all means close it down, but how about raising issue tickets to resolve the the open questions (many here in this thread alone) that have been identified.  This is OpenAPI. The JSON schema issue aside, OpenAPI is not dealing with some of the real world use cases identified in this thread alone.

The TSC have done work to bring the Alternative Schema proposal to the community as a draft feature.  This will allow XML based APIs to be described accurately.  The next step in the draft feature process is for people building tools to implement the draft feature and provide feedback on its feasibility.  If we get multiple implementations then we will incorporate the feature into the specification.
The OpenAPI TSC has done what it can at this point to support this feature.  If you need proper support for XML, then please encourage the people building the tools you use to implement the alternative schema draft feature and provide us with real world implementation experience.
There doesn't need to be any further discussion on this thread.


Implementation Bug Fixes; Migrating to MySQL Server and Using Dapper; Schema Revision

Lessons Learned

Always be vigilant for naming errors in the code.

Problems Encountered

Problem: Implementing Microsoft SQL Server was complex and problematic.

Solution: I have opted to migrate to MySQL Server, as it is more beginner-friendly and easier to implement.

Problem: Initially, I attempted to use Microsoft Entity Framework, but it proved to be complex, and there was a lack of available resources.

Solution: I have switched to using Dapper, which simplifies the setup process and offers more developer-friendly features.

Comparison: Dapper vs. Entity Framework

Aspect
Dapper
Entity Framework

Learning Curve
Easier for developers familiar with SQL
Steeper learning curve, especially for beginners

Configuration
Minimal configuration needed
Requires more configuration and setup

Performance
Generally faster due to lightweight nature
Slightly slower due to abstraction layers

Control
Offers more control over SQL queries and database operations
Provides higher-level abstractions for database operations

SQL Queries
Developers write raw SQL queries
Allows using LINQ to write queries

Mapping
Manual object mapping required
Automatic object-relational mapping (ORM)

Maintenance
Less automated, more manual coding required
Provides more automation and code generation

Popularity
Popular in microservices and performance-critical applications
Widely used in enterprise and complex applications

Use Cases
Suitable for simple to moderately complex applications
Suitable for complex and enterprise-level applications

Ecosystem
Smaller ecosystem, fewer third-party libraries
Larger ecosystem with more extensions and libraries

Flexibility
Offers flexibility but requires more developer effort
Provides more convenience and built-in features

Integration
Easily integrates with existing databases and stored procedures
May require more work for certain integrations

Additional Changes

Schema fixes have been made to ensure data consistency and integrity.

Schema Revision
Original Schema:
CREATE TABLE Transactions (
    transaction_id INT,
    municipality_name VARCHAR(255),
    barangay_name VARCHAR(255),
    price DECIMAL(18, 2),
    quantity INT,
);

CREATE TABLE TransactionDocuments (
    document_id INT,
    municipality_name VARCHAR(255),
    barangay_name VARCHAR(255),
    punong_barangay_name VARCHAR(255),
    barangay_treasurer_name VARCHAR(255),
    unit_name VARCHAR(255),
    particulars VARCHAR(255),
    quantity INT,
    cost DECIMAL(18, 2),
    amount DECIMAL(18, 2)
);

CREATE TABLE PurchaseOrder (
    document_id INT,
    order_id INT AUTO_INCREMENT PRIMARY KEY,
    FOREIGN KEY (document_id) REFERENCES TransactionDocuments (document_id),
    mode_of_procurement VARCHAR(255)
);

CREATE TABLE AbstractQuotation (
    document_id INT,
    open_date DATE,
    office_location VARCHAR(255),
    office_of_the VARCHAR(255),
    awarded_to_the VARCHAR(255),
    office_of VARCHAR(255),
    opening_quotations_office VARCHAR(255),
    chairman_name VARCHAR(255),
    member1_name VARCHAR(255),
    member2_name VARCHAR(255),
    member3_name VARCHAR(255),
    member4_name VARCHAR(255),
    member5_name VARCHAR(255),
    member6_name VARCHAR(255)
);

CREATE TABLE PurchaseRequest (
    document_id INT,
    request_number VARCHAR(255),
    request_date DATE,
    requisition VARCHAR(255),
    delivery_location VARCHAR(255),
    delivery_terms VARCHAR(255),
    delivery_date DATE,
    purpose VARCHAR(255),
    requested_by_name VARCHAR(255),
    approved_for_issuance_name VARCHAR(255),
    requestor_name VARCHAR(255)
);

Revised Schema:
CREATE TABLE Transactions (
    transaction_id INT AUTO_INCREMENT PRIMARY KEY,
    municipality_name VARCHAR(255),
    barangay_name VARCHAR(255)
);

CREATE TABLE TransactionDocuments (
    document_id INT AUTO_INCREMENT PRIMARY KEY,
    transaction_id INT,
    punong_barangay_name VARCHAR(255),
    barangay_treasurer_name VARCHAR(255),
    FOREIGN KEY (transaction_id) REFERENCES Transactions (transaction_id)
);

CREATE TABLE TransactionItems (
    item_id INT AUTO_INCREMENT PRIMARY KEY,
    document_id INT,
    unit_name VARCHAR(255),
    particulars VARCHAR(255),
    quantity INT,
    cost DECIMAL(18, 2),
    amount DECIMAL(18, 2),
    price DECIMAL(18, 2),
    FOREIGN KEY (document_id) REFERENCES TransactionDocuments (document_id)
);

CREATE TABLE PurchaseOrder (
    order_id INT AUTO_INCREMENT PRIMARY KEY,
    document_id INT,
    mode_of_procurement VARCHAR(255),
    FOREIGN KEY (document_id) REFERENCES TransactionDocuments (document_id)
);

CREATE TABLE AbstractQuotation (
    abstract_id INT AUTO_INCREMENT PRIMARY KEY,
    document_id INT,
    open_date DATE,
    office_location VARCHAR(255),
    office_of_the VARCHAR(255),
    awarded_to_the VARCHAR(255),
    opening_quotations_office VARCHAR(255),
    FOREIGN KEY (document_id) REFERENCES TransactionDocuments (document_id)
);

CREATE TABLE PurchaseRequest (
    request_id INT AUTO_INCREMENT PRIMARY KEY,
    document_id INT,
    request_number VARCHAR(255),
    request_date DATE,
    requisition VARCHAR(255),
    delivery_location VARCHAR(255),
    delivery_terms VARCHAR(255),
    delivery_date DATE,
    purpose VARCHAR(255),
    requested_by_name VARCHAR(255),
    approved_for_issuance_name VARCHAR(255),
    requestor_name VARCHAR(255),
    FOREIGN KEY (document_id) REFERENCES TransactionDocuments (document_id)
);

Revised SQL View:
CREATE VIEW TransactionView AS
SELECT
    T.transaction_id,
    T.municipality_name,
    T.barangay_name,
    TD.punong_barangay_name,
    TD.barangay_treasurer_name,
    TI.unit_name,
    TI.particulars,
    TI.quantity,
    TI.cost,
    TI.amount,
    TI.price,
    PO.mode_of_procurement,
    AQ.open_date,
    AQ.office_location,
    AQ.office_of_the,
    AQ.awarded_to_the,
    AQ.opening_quotations_office,
    PR.request_number,
    PR.request_date,
    PR.requisition,
    PR.delivery_location,
    PR.delivery_terms,
    PR.delivery_date,
    PR.purpose,
    PR.requested_by_name,
    PR.approved_for_issuance_name,
    PR.requestor_name
FROM Transactions T
JOIN TransactionDocuments TD ON T.transaction_id = TD.transaction_id
JOIN TransactionItems TI ON TD.document_id = TI.document_id
LEFT JOIN PurchaseOrder PO ON TD.document_id = PO.document_id
LEFT JOIN AbstractQuotation AQ ON TD.document_id = AQ.document_id
LEFT JOIN PurchaseRequest PR ON TD.document_id = PR.document_id;

The schema has been revised to better represent the relationships between the tables and improve data consistency and integrity. Please review this pull request and provide your feedback. These changes aim to simplify the development process, improve performance, and enhance maintainability. Thank you for your attention to this matter.

 I am the only one who is working on this project, why am I trying to act like there's many devs working on this. HAHAHAHA


Add Metal support for the Ogre2 Render Engine

🎉 New feature
Summary
This PR adds Metal Render System support to the ogre2 render engine.
Relates to: https://github.com/ignitionrobotics/ign-rendering/issues/461 and discussions in https://github.com/ignitionrobotics/ign-rendering/issues/422.
Marked as draft as not all shaders have been ported to Metal and some examples are not working correctly.
Test it
A number of the examples have been modified to allow the Metal to be used with the ogre2 render engine instead of GL3+. For example to use Metal with the simple_demo example run:
./simple_demo ogre2 metal

For a list of tasks and the status of the examples see the accompanying feature request:  https://github.com/ignitionrobotics/ign-rendering/issues/461
Checklist

[x] Signed all commits for DCO
[ ] Added tests
[x] Added example and/or tutorial
[ ] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[ ] codecheck passed (See contributing)
[ ] All tests passed (See test coverage)
[ ] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge
🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸

I'm wondering whether to push it to this PR or to a create new one and then cherry pick it in later, as there is quite a lot here already?

+1 on creating a new PR for this. Makes it easier to review. Thanks!

Hi @ahcorde - thanks for reviewing.
I'm wondering if the issue you are seeing is related to https://github.com/ignitionrobotics/ign-rendering/pull/456? The selection buffer material (and a few others) reference other shader aliases. The error message is a bit cryptic but it looks like it may not be finding DepthCameraVS which is define as a unified shader in depth_camera.material
https://github.com/srmainwaring/ign-rendering/blob/f504e4fb8140a7ce9ba72e7def978578f11b3c74/ogre2/src/media/materials/scripts/selection_buffer.material#L29-L54

macOS Big Sur 11.6 and XCODE Version 12.5.1 (I think I can update to version 13.0.0)

I tried this other PR https://github.com/ignitionrobotics/ign-rendering/pull/467 and I'm able to visualize the depth camera.
I have never run the code with xcode, let me try it

I've rolled back Ogre2.2 to match the osrf/simulation brew version and cannot replicate the issue you're seeing. Could you  export the gpu trace and make it available on a shared drive (dropbox or equivalent).
To export: highlight the project in the left-hand pane, then from the menu: File > Export and you should get a simple_demo.gputrace file about 2.8 MB in size. Xcode can replay this, so I can run a side by side comparison to see what is going one.
Are you able to get any of the other examples working using ogre2 metal on the command line? All the ones listed as complete in https://github.com/ignitionrobotics/ign-rendering/issues/461#issuecomment-939524048 should now work.
In the meanwhile I will try to get this project set up on another machine - a MacBook this time to see if there's a hardware issue, and I'll also look into moving to Big Sur 11.6 and Xcode 12.5.1 on that machine so see if there is anything in that.

OK I can see two things can happen:

"Bad mac" is rendering to MSAA but not resolving. Because 4xFP32_ps expects a non-MSAA texture, it fails
"Bad mac" is rendering to MSAA but not resolving. The 4xFP32_ps receives is where the resolved output was supposed to be, but nothing was resolved into that so it's black.
"Bad mac" is rendering to non-msaa texture. The texture sent to 4xFP32_ps has nothing to do with that one (compare the pointer addresses)

All 3 cases sounds like ignition thinks it's using MSAA, but it's not; hence the compositors it prepared have extra steps to deal with MSAA and everything falls apart.

Bingo:

Edit 2: I'd try to force disable MSAA. Just leave this->dataPtr->fsaaLevels with "1" in OgreRenderEngine::CreateRenderSystem and make sure OgreRenderEngine::CreateRenderWindow doesn't contain _antiAliasing > 1

Force fsaa = 1 in Ogre2RenderTarget::BuildCompositor and it works.

@ahcorde here's the short version of what to do to get the tests working on your MacBook Pro:
In Main.cc set the camera anti-aliasing to 1.
  // create camera
  CameraPtr camera = _scene->CreateCamera("camera");
  ...
  camera->SetAntiAliasing(1);
 ...

The longer reason is that it is possible to set the anti-aliasing to a value not supported by the render system / hardware. For the MacBook Pro valid values are [1, 4, 8] so setting the value to 2 will fail, and for some reason this is not being caught in the function Ogre2RenderTarget::TargetFSAA. The other levels Anti-Aliasing=4 and Anti-Aliasing=8 also work.

+1 It's working!

just catching up on the thread. Great to hear it's working! :tada: :tada: :tada:

awesome! :tada:
We ran into the gamma issue before and added a Qt GammaAdjust effect in the GUI to bring it closer to the camera output: https://github.com/srmainwaring/ign-gui/blob/feature/ign-gui7-metal/src/plugins/scene3d/Scene3D.qml#L53-L62. Maybe that's not not working for Metal.

Would you like me to rebase this PR and update the corresponding Metal versions?

ah yes please, thanks!

or (and probably better) would be to implement a version GammaAdjust for Metal that can be used instead of the one in QtGraphicalEffects.

yeah but we only want it to be applied to the GUI camera and not the camera sensor images. Image looks fine when the data is copied from GPU to CPU. I think it's incorrect when Qt creates the texture from the texture id we pass it. So we probably just need a way for the camera created in ign-gui/gazebo to indicate that it needs gamma adjust effect applied.

@ahcorde and @iche033 I excluded the example simple_demo_qml from this PR because it's more complicated to provide Metal support in QML than for the GLUT examples as the main window render texture is shared with the application.
I've put together a version that can target either OpenGL or Metal in this branch: https://github.com/srmainwaring/ign-rendering/tree/feature/metal-simple_demo_qml which is based on main rather than ign-rendering6 because it requires the native Metal textures from the render system. By default the example will use OpenGL. To run with Metal use:
$ simple_demo_qml metal

I would like to use a similar approach to provide OpenGL / Metal support for MinimalScene in ignition-gui, at which point the bulk of the work to support ignition gazebo on macOS using Metal will be in place (there are a few other areas that need attention but this is the major gap outstanding).
I'd appreciate your thoughts on the approach. I have not submitted a PR because simple_demo_qml depends on the changes to the render system code from this PR (there is a separate copy in the metal-simple_demo_qml branch so it can run standalone).
If there is anything I can do to help this PR along, such as split it up into smaller chunks, please let me know.

Does Qt use native Metal or GL?
IIRC Apple has an OpenGL extension for wrapping a Metal texture into an OpenGL texture (i.e. MTLTexture goes in, GLuint handle comes out) to enable interop of new code into old code

Ok cool!

as the main window render texture is shared with the application.

What does that mean? Could you elaborate please?

Not very precise on my part - the texture for the MinimalScene is wrapped in Qt using  QQuickWindow::createTextureFromNativeObject which is then passed to the scene graph via a Texture Node (at least it is on macOS where brew provides a version of Qt that supports this function - on Ubuntu 20.04 the deprecated function createTextureFromId is used).
AFAICT this requires the QSGRendererInterface type to match the Ogre render system being used. In the case of Metal it's  QSGRendererInterface::MetalRhi

@srmainwaring I'll review this PR this week.

because it requires the native Metal textures from the render system

just to confirm, in order to get the simple_demo_qml working on Metal in ign-rendering6 (and ign-gazebo6), we would need a way to backport the RenderTextureMetalId and MetalId functions added in #478 right?

just to confirm, in order to get the simple_demo_qml working on Metal in ign-rendering6 (and ign-gazebo6), we would need a way to backport the RenderTextureMetalId and MetalId functions added in #478 right?

That's right. I was thinking that since some of the changes to the ign-gui plugins may also break API/ABI to get Metal in, it might be better to target Ignition Garden for full macOS / Metal support rather than try and back port the changes to Fortress. Of course it would be great to have macOS support in Fortress, but I can live with my custom solution until the next major release and have it done properly there rather than divert your teams resource to finding back port work-arounds (unless there is a larger community demand for macOS support - but I suspect not).

ok sounds good. Let's get this in Garden first. We can then evaluate the effort required to backport and get things working on Fortress, thanks.

Hi @srmainwaring,
I'm trying to compile your changes but I'm not able.

ign-rendering: feature/ign-rendering6-metal-macos
ign-gui: feature/ign-gui7-metal
ign-gazebo: feature/ign-gazebo7-metal

But I'm getting this error:
minimal_scene/MinimalSceneRhiMetal.mm:86:12: error: no member named 'RenderTextureMetalId' in 'ignition::rendering::Camera'
  _camera->RenderTextureMetalId(&texturePtr);
  ~~~~~~~~~^

Are these the right branches ?

@ahcorde you need to use main for ign-rendering as the changes to expose the Metal texture were ABI breaking.

@ahcorde do you want give this another test on your mac machine? As of now, you'll need to test this branch by itself. The other PRs for full ign-gazebo + Metal integration will likely target Garden and not Fortress.

yes @iche033,  I will test it today

I was able to compile it but I'm getting this trace when I try to run it:

ign gazebo -v 4 -g
```bash
ign gazebo -v 4 -g
[Msg] Ignition Gazebo GUI    v7.0.0~pre1
[Dbg] [Application.cc:87] Initializing application.
[Dbg] [Application.cc:105] Qt using Metal rendering interface
[GUI] [Dbg] [Application.cc:456] Create main window
[GUI] [Wrn] [Application.cc:698] [QT] Populating font family aliases took 639 ms. Replace uses of missing font family "Roboto" with one that exists to avoid this cost.
[GUI] [Wrn] [Application.cc:698] [QT] qrc:/qml/StyleDialog.qml:112:3: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
[GUI] [Wrn] [Application.cc:698] [QT] qrc:/qml/StyleDialog.qml:105:3: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
[GUI] [Wrn] [Application.cc:698] [QT] qrc:/qml/StyleDialog.qml:98:3: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
[GUI] [Wrn] [Application.cc:698] [QT] qrc:qml/Main.qml:83:3: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
[GUI] [Wrn] [Application.cc:698] [QT] qrc:/qml/PluginMenu.qml:27:3: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
[GUI] [Dbg] [PathManager.cc:66] Requesting resource paths through [/gazebo/resource_paths/get]
[GUI] [Wrn] [Application.cc:698] [QT] file::/Gazebo/GazeboDrawer.qml:241:3: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
[GUI] [Wrn] [Application.cc:698] [QT] file::/Gazebo/GazeboDrawer.qml:147:3: QML Dialog: Binding loop detected for property "implicitHeight"
[GUI] [Wrn] [Application.cc:698] [QT] file::/Gazebo/GazeboDrawer.qml:147:3: QML Dialog: Binding loop detected for property "implicitHeight"
[GUI] [Dbg] [Gui.cc:149] GUI requesting list of world names. The server may be busy downloading resources. Please be patient.
[GUI] [Dbg] [PathManager.cc:55] Received resource paths.
[GUI] [Dbg] [Gui.cc:208] Requesting GUI from [/world/default/gui/info]...
[GUI] [Dbg] [GuiRunner.cc:110] Requesting initial state from [/world/default/state]...
[GUI] [Msg] Loading config [/Users/ahcorde/.ignition/gazebo/7/gui.config]
[GUI] [Dbg] [Application.cc:336] Loading plugin [MinimalScene]
[GUI] [Dbg] [Application.cc:692] [QT] Creating ign-renderering interface for OpenGL
[GUI] [Dbg] [Application.cc:692] [QT] Creating ign-renderering interface for OpenGL
[GUI] [Dbg] [Application.cc:692] [QT] Creating render thread interface for OpenGL
[GUI] [Msg] Added plugin [3D View] to main window
[GUI] [Msg] Loaded plugin [MinimalScene] from path [/Users/ahcorde/ignition_fortress/install/lib/ign-gui-7/plugins/libMinimalScene.dylib]
[GUI] [Dbg] [Application.cc:336] Loading plugin [EntityContextMenuPlugin]
[GUI] [Wrn] [Application.cc:698] [QT] file::/EntityContextMenuPlugin/EntityContextMenuPlugin.qml:33:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
[GUI] [Msg] Added plugin [EntityContextMenu] to main window
[GUI] [Msg] Loaded plugin [EntityContextMenuPlugin] from path [/Users/ahcorde/ignition_fortress/install/lib/ign-gazebo-7/plugins/gui/libEntityContextMenuPlugin.dylib]
[GUI] [Dbg] [Application.cc:336] Loading plugin [GzSceneManager]
[GUI] [Msg] Added plugin [Scene Manager] to main window
[GUI] [Msg] Loaded plugin [GzSceneManager] from path [/Users/ahcorde/ignition_fortress/install/lib/ign-gazebo-7/plugins/gui/libGzSceneManager.dylib]
[GUI] [Dbg] [Application.cc:336] Loading plugin [InteractiveViewControl]
[GUI] [Msg] Camera view controller topic advertised on [/gui/camera/view_control]
[GUI] [Msg] Added plugin [] to main window
[GUI] [Msg] Loaded plugin [InteractiveViewControl] from path [/Users/ahcorde/ignition_fortress/install/lib/ign-gui-7/plugins/libInteractiveViewControl.dylib]
[GUI] [Dbg] [Application.cc:336] Loading plugin [CameraTracking]
[GUI] [Msg] Added plugin [Camera tracking] to main window
[GUI] [Msg] Loaded plugin [CameraTracking] from path [/Users/ahcorde/ignition_fortress/install/lib/ign-gui-7/plugins/libCameraTracking.dylib]
[GUI] [Dbg] [Application.cc:336] Loading plugin [MarkerManager]
[GUI] [Msg] Listening to stats on [/world/default/stats]
[GUI] [Msg] Added plugin [Marker Manager] to main window
[GUI] [Msg] Loaded plugin [MarkerManager] from path [/Users/ahcorde/ignition_fortress/install/lib/ign-gui-7/plugins/libMarkerManager.dylib]
[GUI] [Dbg] [Application.cc:336] Loading plugin [SelectEntities]
[GUI] [Msg] Added plugin [Select entities] to main window
[GUI] [Msg] Loaded plugin [SelectEntities] from path [/Users/ahcorde/ignition_fortress/install/lib/ign-gazebo-7/plugins/gui/libSelectEntities.dylib]
[GUI] [Dbg] [Application.cc:336] Loading plugin [Spawn]
[GUI] [Wrn] [Application.cc:698] [QT] file::/Spawn/Spawn.qml:28:3: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
[GUI] [Msg] Added plugin [Spawn] to main window
[GUI] [Msg] Loaded plugin [Spawn] from path [/Users/ahcorde/ignition_fortress/install/lib/ign-gazebo-7/plugins/gui/libSpawn.dylib]
[GUI] [Dbg] [Application.cc:336] Loading plugin [VisualizationCapabilities]
[GUI] [Msg] View as transparent service on [/gui/view/transparent]
[GUI] [Msg] View as wireframes service on [/gui/view/wireframes]
[GUI] [Msg] View center of mass service on [/gui/view/com]
[GUI] [Msg] View inertia service on [/gui/view/inertia]
[GUI] [Msg] View collisions service on [/gui/view/collisions]
[GUI] [Msg] View joints service on [/gui/view/joints]
[GUI] [Msg] Added plugin [VisualizationCapabilities] to main window
[GUI] [Msg] Loaded plugin [VisualizationCapabilities] from path [/Users/ahcorde/ignition_fortress/install/lib/ign-gazebo-7/plugins/gui/libVisualizationCapabilities.dylib]
[GUI] [Dbg] [Application.cc:336] Loading plugin [WorldControl]
[GUI] [Wrn] [Application.cc:698] [QT] file::/WorldControl/WorldControl.qml:30:3: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
[GUI] [Msg] Using world control service [/world/default/control]
[GUI] [Msg] Listening to stats on [/world/default/stats]
[GUI] [Msg] Added plugin [World control] to main window
[GUI] [Msg] Loaded plugin [WorldControl] from path [/Users/ahcorde/ignition_fortress/install/lib/ign-gui-7/plugins/libWorldControl.dylib]
[GUI] [Dbg] [Application.cc:336] Loading plugin [WorldStats]
[GUI] [Msg] Listening to stats on [/world/default/stats]
[GUI] [Msg] Added plugin [World stats] to main window
[GUI] [Msg] Loaded plugin [WorldStats] from path [/Users/ahcorde/ignition_fortress/install/lib/ign-gui-7/plugins/libWorldStats.dylib]
[GUI] [Dbg] [Application.cc:336] Loading plugin [Shapes]
[GUI] [Msg] Added plugin [Shapes] to main window
[GUI] [Msg] Loaded plugin [Shapes] from path [/Users/ahcorde/ignition_fortress/install/lib/ign-gazebo-7/plugins/gui/libShapes.dylib]
[GUI] [Dbg] [Application.cc:336] Loading plugin [Lights]
[GUI] [Msg] Added plugin [Lights] to main window
[GUI] [Msg] Loaded plugin [Lights] from path [/Users/ahcorde/ignition_fortress/install/lib/ign-gazebo-7/plugins/gui/libLights.dylib]
[GUI] [Dbg] [Application.cc:336] Loading plugin [TransformControl]
[GUI] [Wrn] [Application.cc:698] [QT] file::/TransformControl/TransformControl.qml:104:3: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
[GUI] [Wrn] [Application.cc:698] [QT] file::/TransformControl/TransformControl.qml:99:3: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
[GUI] [Wrn] [Application.cc:698] [QT] file::/TransformControl/TransformControl.qml:94:3: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
[GUI] [Wrn] [Application.cc:698] [QT] file::/TransformControl/TransformControl.qml:89:3: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
[GUI] [Dbg] [TransformControl.cc:219] Legacy mode is disabled; this plugin must be used with MinimalScene.
[GUI] [Msg] Added plugin [Transform control] to main window
[GUI] [Msg] Loaded plugin [TransformControl] from path [/Users/ahcorde/ignition_fortress/install/lib/ign-gazebo-7/plugins/gui/libTransformControl.dylib]
[GUI] [Dbg] [Application.cc:336] Loading plugin [Screenshot]
[GUI] [Wrn] [Application.cc:698] [QT] file::/Screenshot/Screenshot.qml:33:3: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
[GUI] [Msg] Screenshot service on [/gui/screenshot]
[GUI] [Msg] Added plugin [Screenshot] to main window
[GUI] [Msg] Loaded plugin [Screenshot] from path [/Users/ahcorde/ignition_fortress/install/lib/ign-gui-7/plugins/libScreenshot.dylib]
[GUI] [Dbg] [Application.cc:336] Loading plugin [ComponentInspector]
[GUI] [Msg] Added plugin [Component inspector] to main window
[GUI] [Msg] Loaded plugin [ComponentInspector] from path [/Users/ahcorde/ignition_fortress/install/lib/ign-gazebo-7/plugins/gui/libComponentInspector.dylib]
[GUI] [Dbg] [Application.cc:336] Loading plugin [EntityTree]
[GUI] [Msg] Added plugin [Entity tree] to main window
[GUI] [Msg] Loaded plugin [EntityTree] from path [/Users/ahcorde/ignition_fortress/install/lib/ign-gazebo-7/plugins/gui/libEntityTree.dylib]
[GUI] [Dbg] [Application.cc:289] Loading window config
[GUI] [Dbg] [Application.cc:470] Applying config
[GUI] [Wrn] [Application.cc:698] [QT] file::/Gazebo/GazeboDrawer.qml:147:3: QML Dialog: Binding loop detected for property "implicitHeight"
[GUI] [Dbg] [Application.cc:692] [QT] Creating ign-renderering interface for OpenGL
[GUI] [Dbg] [Application.cc:692] [QT] Creating render thread interface for OpenGL
Stack trace (most recent call last):
#31   Object "CoreFoundation", at 0x7fff20555f8c, in CFRunLoopRunSpecific + 563
#30   Object "CoreFoundation", at 0x7fff20556998, in __CFRunLoopRun + 841
#29   Object "CoreFoundation", at 0x7fff20557505, in __CFRunLoopDoObservers + 543
#28   Object "CoreFoundation", at 0x7fff20557671, in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
#27   Object "AppKit", at 0x7fff23639332, in ___NSRunLoopObserverCreateWithHandler_block_invoke + 41
#26   Object "AppKit                              0x00007fff22ee386c", at 0x7fff22ee386c, in NS_setFlushesWithDisplayLink]_block_invoke + 285
#25   Object "QuartzCore", at 0x7fff26cc8b6f, in CA::Transaction::commit() + 713
#24   Object "QuartzCore", at 0x7fff26e32bee, in CA::Context::commit_transaction(CA::Transaction*, double, double*) + 666
#23   Object "QuartzCore", at 0x7fff26ce76f3, in CA::Layer::display_if_needed(CA::Transaction*) + 863
#22   Object "QuartzCore                          0x00007fff26ce7ead", at 0x7fff26ce7ead, in display] + 183
#21   Object "libqcocoa.dylib", at 0x10cd32ff5, in qt_plugin_instance + 132629
#20   Object "libqcocoa.dylib", at 0x10cd2a8c6, in qt_plugin_instance + 98022
#19   Object "QtGui", at 0x1055de9d1, in void QWindowSystemInterface::handleExposeEvent(QWindow*, QRegion const&) + 273
#18   Object "QtGui", at 0x1055fa3b2, in QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*) + 306
#17   Object "QtCore", at 0x105d9ad66, in QCoreApplication::notifyInternal2(QObject*, QEvent*) + 166
#16   Object "QtWidgets", at 0x1050256ad, in QApplication::notify(QObject*, QEvent*) + 477
#15   Object "QtWidgets", at 0x1050242f6, in QApplicationPrivate::notify_helper(QObject*, QEvent*) + 262
#14   Object "QtQuick", at 0x103f66a31, in QQuickWindow::event(QEvent*) + 241
#13   Object "QtGui", at 0x105606024, in QWindow::event(QEvent*) + 692
#12   Object "QtQuick", at 0x103ee8755, in QSGRenderLoop::handleContextCreationFailure(QQuickWindow*) + 8645
#11   Object "QtQuick", at 0x103ee7e94, in QSGRenderLoop::handleContextCreationFailure(QQuickWindow*) + 6404
#10   Object "QtQuick", at 0x103f5e9d9, in QQuickWindowPrivate::syncSceneGraph() + 361
#9    Object "QtQuick", at 0x103f5ed64, in QQuickWindowPrivate::updateDirtyNodes() + 356
#8    Object "QtQuick", at 0x103f70fc5, in QQuickWindowPrivate::updateDirtyNode(QQuickItem*) + 2901
#7    Object "libMinimalScene.dylib", at 0x1437b0704, in ignition::gui::plugins::RenderWindowItem::updatePaintNode(QSGNode*, QQuickItem::UpdatePaintNodeData*) + 1124
#6    Object "QtGui", at 0x10563d9de, in QOpenGLContext::doneCurrent() + 14
#5    Object "libsystem_platform.dylib", at 0x7fff204a5d7c, in _sigtramp + 28
#4    Object "libignition-tools-backward.dylib", at 0x1014f5242, in backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 34
#3    Object "libignition-tools-backward.dylib", at 0x1014f548a, in backward::SignalHandling::handleSignal(int, __siginfo*, void*) + 106
#2    Object "libignition-tools-backward.dylib", at 0x1014f55a8, in backward::StackTraceImpl::load_from(void*, unsigned long, void*, void*) + 56
#1    Object "libignition-tools-backward.dylib", at 0x1014f5701, in backward::StackTraceImpl::load_here(unsigned long, void*, void*) + 129
#0    Object "libignition-tools-backward.dylib", at 0x1014f6f60, in unsigned long backward::details::unwind::callback>(backward::StackTraceImpl::callback, unsigned long) + 32
```

This are my collection of ignition libraries

Collection of Ignition Libraries
./ign-utils
* ign-utils1

./ign-gazebo
  ahcorde/improve/install_instructions
  ahcorde/pybind11
* feature/ign-gazebo7-metal
  ign-gazebo6
  main
 M CMakeLists.txt
 M src/systems/CMakeLists.txt

./ign-plugin
* ign-plugin1

./ign-rendering
  ahcorde/install/macos
  feature/ign-rendering6-metal-macos
  ign-rendering6
* main

./ign-math
  ahcorde/macos/install
  ahcorde/python/triangle
  ahcorde/python_all
* ign-math6

./ign-sensors
  ahcorde/macos/install
  ign-sensors6
* main

./ign-launch
  ahcorde/fix/install_instructions
* ign-launch5
  main

./pybind11
* master

./ign-cmake
* ign-cmake2

./ign-tools
* ign-tools1

./ign-msgs
* main

./ign-transport
  ahcorde/docs/tweaks
* ign-transport11
  main
 M example/CMakeLists.txt

./ign-gui
  ahcorde/macos/install
* feature/ign-gui7-metal
  ign-gui6
  main
 M CMakeLists.txt

./ign-fuel-tools
* main

./ign-common
  ahcorde/macos/install
* ign-common4

./ign-physics
  ahcorde/improve/readme.md
* ign-physics5
  main

./sdformat
  main
* sdf12

I was able to compile it but I'm getting this trace when I try to run it:

Hi @ahcorde it looks like you may be missing the <render_system>metal</render_system> element from the XML for the MinimalScene plugin (the branches with Metal support currently hardcode the Metal QML backend but dynamically determine which render system to load for the MinimalScene plugin - that you're seeing a reference to an OpenGL context in the trace means the plugin is not loading the Metal version).
How about we move the discussion of the ign-gui and ign-gazebo support to https://github.com/ignitionrobotics/ign-gui/issues/314 as they build upon this PR but don't affect it directly (I've probably confused issues by referencing the gui / gazebo work in this thread).

I think you should target main

I don't see any API/ABI changes in public headers, so we're good on that front. Does it break behavior or affect users negatively any other way?
Maybe we should revert https://github.com/ignitionrobotics/ign-rendering/pull/407 and see if the Ogre 2 tests pass on macOS CI with this PR?

Maybe we should revert #407 and see if the Ogre 2 tests pass on macOS CI with this PR?

The PR was set up to not change the default behaviour for macOS, so it will not alter the current CI tests for macOS (which will still use the OpenGL graphics API with Ogre2). I do have a local branch with a set of proposed changes to the tests which allow an additional graphics API parameter to be passed to the gtest runners, but thought it better to leave that for a separate PR as it has a wider impact and there is already a lot in this one.

LGTM! but I think you should target main, right @iche033

Thanks for the review @ahcorde. I think it's ok to stay in ign-rendering6. Any other changes required?

@srmainwaring awesome contribution! Thank you!

@iche033 and @ahcorde thanks for the review and feedback and for getting this merged.
One request please: could the ign-rendering6 branch with these changes be merged into main? I need the Metal ABI breaking change from main and this PR to prepare the Metal support PRs for ign-gui and ign-gazebo.

@srmainwaring  https://github.com/ignitionrobotics/ign-rendering/pull/496


Support StartAfter(List values)

Seems not support startAfter(List values).
int d1 = 1;
int d2 = 2;
int d3 = 3;

var collectionRef =
    Firestore.instance.collection("users/");

await collectionRef.add({'created': d1});
await collectionRef.add({'created': d2});
await collectionRef.add({'created': d3});

var results =
    await collectionRef.orderBy('created', descending: true).startAfter([d2]).getDocuments();

results.documents.forEach((d) => print(d.data['created']));

Thanks for writing a unit test!
You're right, this feature is not supported so far. I might get to it in the future. If you're feeling adventurous, feel free to contribute a PR!

@Hadii1 graciously implemented this feature at #70.


fix claimed cluster can not delete from clusterset

https://github.com/open-cluster-management/backlog/issues/13011

/retest

/retest

/retest

/lgtm


Additional trailing spaces in code block - https://raw.githubusercontent.com/MicrosoftLearning/mslearn-fabric/main/Instructions/Labs/06d-secure-data-warehouse.md

Module: 'Secure a Microsoft Fabric data warehouse'
Lab/Demo: 06d
Task: 'Implement Column-Level Security'
Step: 05
Description of issue
There are 3 additional trailing spaces after the opening tsql code block, and depending on ALH/parser used for markdown rendering this can lead to display issues.  Can these 3 spaces be deleted?

Yes they can be deleted.  Thanks!


System.ArgumentException

Every time crawlers raise a HEAD request to the root:
HEAD /
An exception is raised:
An item with the same key has already been added.
Problem Id | System.ArgumentException at RobotsTxt.RobotsTxtMiddleware+d__4.MoveNext |
-- | -- | --
Assembly | RobotsTxtCore, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null

Thanks @karl-sjogren for the reply.
Indeed when I removed the robots.txt middleware, and tested it, the exception was still occurring.
In my case it was a HTTP 405 that was raising the exception, because HEAD was not allowed by the API.

Thats great to hear! I'll go ahead and close this issue then.


possible name collision?

Hi, thanks for sharing this crate!
on Windows using egui 0.26.0, i get this.

https://i.imgur.com/Nbln3pK.gifv
it could be name collision?, seen in the egui documentation at

sorry for the bad translation, I do not speak English and I am using google translate.

Hi, thanks for the issue!
Interesting, I haven't had that problem yet and haven't seen it before. Especially since the error only occurs while scrolling.
Do you have a repository somewhere where I can reproduce the error?

of course!, thank you very much for the quick response and sorry for the delay.
the project aims to open and process a json file, and display the content, I will upload the repo in these days, while I organize the mess a little 😄
[dependencies]
egui = "0.26.0"
eframe = "0.26.0"
egui_extras = { version = "0.26.0"}
serde = { version = "~1.0", features = ["derive"] }
serde_json = { version = "~1.0" }
jsonschema = { version = "~0.17", features = ["draft202012"] }
# jsonpath_lib = "0.3.0"
jmespath = "0.3.0"
egui-file-dialog = "0.2.0"

what may be different is the use of additional options for eframe and derive.
use std::path::PathBuf;

use eframe::egui;
use egui_file_dialog::FileDialog;

#[derive(Default)]
struct MyApp {
    file_dialog: FileDialog,
    selected_file: Option<PathBuf>,
}

let options = eframe::NativeOptions {
    centered: true,
    viewport: egui::ViewportBuilder::default()
        .with_inner_size([900.0, 800.0]) // ancho - alto
        .with_min_inner_size([800.0, 600.0])
        .with_max_inner_size([1000.0, 900.0])
        .with_maximize_button(false),
    ..Default::default()
};
eframe::run_native("Roaspy", options,  Box::new(|_cc| Box::<MyApp>::default()))

and the part where the file is read...
egui::CentralPanel::default().show(ctx, |ui| {
    if let Some(path) = self.file_dialog.update(ctx).selected() {
        self.selected_file = Some(path.to_path_buf());
        let result = validate_file(path);

        match result {
            Ok(data) => {
                println!("leyendo el archivo: listo!");
                println!("la data: {:?}", data);
                self.data_to_draw = Some(data);
            }
            Err(err) => {
                self.data_to_draw = None;
                self.show_dialog_info = true;
                println!("ocurrio un error al leer el archivo: {}", err);
            }
        } // match
    }
 }); //CentralPanel

environment:

Rust 1.76.0
toolchin: stable-x86_64-pc-windows-msvc (default)
visual studio build tools 2022 (v.17.9.2)
Windows 10 (22H2)

I still can't reproduce the error with the same environment and options🤔
Let me know when your project is publicly available in a repo. Then I'll see if I can reproduce it with the same project :)
You can also try updating egui and eframe to version 0.26.2. egui-file-dialog now also has version 0.4.0 :)

I have upgraded to egui-file-dialog to 0.4.0 and egui to version 0.26.2 and the problem does not appear, in fact I can no longer replicate the error. :smile:

By the way, the implementation of
self.file_dialog.update(ctx);
if let Some(path) = self.file_dialog.take_selected(){
 ...
}

has been a great help, thank you very much!
I think we can close this issue...


Check Tool Dependencies from Arcade

In general, dotnet tool dependencies can be tracked by converting them into <PackageReference> and using dotnet list package --outdated etc.
However, if the tool source is a repo like dotnet/arcade which generates CI packages multiple times a day, that info isn't helpful - the tools will always be outdated.
In such a case, we should check the commit history of the relevant subdirectories for changes.

Example:
git clone https://github.com/dotnet/arcade --no-checkout
cd arcade
git rev-list HEAD -n 1 -- src/Microsoft.DotNet.AsmDiff src/Microsoft.DotNet.ApiCompat src/Microsoft.Cci.Extensions

Closed with 30dbb9c76d93acb9cb023191bc6202d9a72ff778.


HDL documentation (teroshdl-documenter?)

Currently, there is no explicit documentation of the (V)HDL source files beyond a lot of in-code comments. I have tried using DOXYGEN also for the HDL files - but that is not really pretty: the actual source files would be stuffed with DOXYGEN macros and the resulting documentation is somehow special... Since DOXYGEN is targeting software, this is ok.
Recently, I stumbled across this: https://github.com/TerosTechnology/teroshdl-documenter-demo
They even used this project as an example: https://terostechnology.github.io/teroshdl-documenter-demo/NEORV32_doc/index.html :heart: And I really have to say: this looks very good! Finally a nice (and pretty!) way of documenting HDL sources :+1:
Does anyone already have some experience with @TerosTechnology and especially with their documenter? Is there any option (yet) to include that into a Github workflow? 🤔

The main limitation for any documentation generator such as Teros' is parsing VHDL. There are very few usable VHDL parsers, and almost none of them has complete support for VHDL 2008. I believe that teros has an internal JS parser based on regular expressions, and it also uses VUnit for extracting the dependencies. VUnit's parser is also based on regular expressions. It is quite complete and it works reasonably well, but it has some limitations. In fact, replacing the parser in VUnit with rust_hdl or pyVHDLParser has been discussed before. Let me know if you want me to find some references to discussions about open source VHDL parsers.
The summary is that we have a new tool in the party: pyVHDLModel and pyGHDL.dom. pyVHDLModel was split from pyVHDLParser in Dec 2020. Integration into pyGHDL started in Jan 2021 and it is almost complete. @Paebbels has been working so hard on that during the last weeks. As explained in VHDL/pyVHDLModel, some of the use cases that pyGHDL.dom is expected to cover are precisely replacing the dependency analyser in VUnit, the symbol data extraction in Symbolator and providing a VHDL domain for Sphinx. VHDL/sphinx-vhdl is a placeholder for that.
Currently, NEORV32 is being used as one of the projects for testing pyGHDL.dom (see results of the master branch in https://ghdl.github.io/extended-tests/ and the development branch in https://paebbels.github.io/extended-tests/). Moreover, I do have a branch in my fork of this repo. See https://github.com/umarcor/neorv32/commits/pyVHDLModel and https://github.com/umarcor/neorv32/runs/2953525135?check_suite_focus=true#step:5:460. I didn't create an issue for this topic yet, because I'm waiting for the latest enhancements to pyGHDL.dom :wink:.
I believe that the most sensible way forward is for TerosHDL and VUnit to use pyGHDL.dom. However, I know there are users of VUnit who don't use GHDL. By the same token, I think that TerosHDL developers were trying to provide a JS only solution, which does not rely on Python or compiled dependencies. Therefore, the usage of pyGHDL.dom might need to be opt-in in both cases, and it might not be a priority for the maintainers.
Anyway, I think I can enhance TerosTechnology/teroshdl-documenter-demo for providing it as a GitHub Action (similarly to VUnit/vunit_action). Then, we can add it as an step in https://github.com/stnolting/neorv32/blob/master/.github/workflows/Documentation.yml and have the result pushed to GitHub Pages along with the other pieces. Alternatively, we could just copy their workflow, but I think it'd be better for the community to provide it as a "clean" step. What do you think?
/cc @qarlosalberto @smgl9 @LarsAsplund

@umarcor thanks for the mention :)
Currently in TerosHDL we use 2 parsers: tree-sitter-verilog (https://github.com/tree-sitter/tree-sitter-verilog) and tree-sitter-vhdl (https://github.com/alemuller/tree-sitter-vhdl). They don't use regex, they use tree-sitter (https://tree-sitter.github.io/tree-sitter/). Besides we have embedded them in our project with web-tree-sitter (https://www.npmjs.com/package/web-tree-sitter). So the only dependency is nodejs.
I think that tree-sitter-vhdl is a complete parser, but I'm not a VHDL language expert. I don't usually use VHDL 2008. With web-tree-sitter there is a problem, it's very very slow because it based in wasm.
We use VUnit for the dependency graph (https://terostechnology.github.io/teroshdl-documenter-demo/NEORV32_doc/index.html). But it's optional.
From my point of view the main feature in TerosHDL Documenter is the ability to parse the comments:

It's possible to use pyGHDL.dom as TerosHDL parser backend. We have a defined json format between parser and documenter: https://github.com/TerosTechnology/colibri/blob/master/test/examples/vhdl/example_1.json If pyGHDL.dom can provide this format it's easy to integrate it. Maybe the only problem is to parse the comments (https://terostechnology.github.io/terosHDLdoc/features/documenter.html)
I think that the best would be to provide it as a GitHub Action. Could you do it? I have no experience in that :/

Only one clarification, the command line documenter (https://github.com/TerosTechnology/colibri) is still beta. We could first to release a version and later to integrate it in Github Actions. What do you think?

I totally subscribe to @qarlosalberto.
@umarcor The only reasons not having a GitHub Action are the lack of experience and free time.
I have created this repo for Github Actions: https://github.com/TerosTechnology/teroshdl-documenter-action
There is also a docker with TerosHDL backend: docker pull terostech/colibri
But is probably outdated because the documenter CLI is changing a lot in the last days and is not still stable.  Hopefully in the next weeks there will be a well documented release :)

@smgl9 @qarlosalberto take it easy mates! 😃 I was not criticising the lack of Action, but willing to explain Stephan why we might want to wait some days/weeks before adding the feature to this repo.
In fact, as you already know, that's the area I feel comfortable with, so I created some PRs to get the CI in TerosTechnology in shape:

TerosTechnology/teroshdl-documenter-demo#1
TerosTechnology/teroshdl-documenter-demo#2
TerosTechnology/teroshdl-documenter-demo#3
TerosTechnology/colibri#225
See also https://github.com/umarcor/teroshdl-documenter-demo/commits/ci-action

However, I was thinking about it and I feel that the action belongs in TerosTechnology/colibri, rather than teroshdl-documenter-demo or a separated repo. That's why I did not open that PR yet. Let's deal with those 4 PRs first and we will then discuss the details of the Action.

They don't use regex, they use tree-sitter

@qarlosalberto I'm really sorry, I keep forgetting about tree-sitter again and again....

From my point of view the main feature in TerosHDL Documenter is the ability to parse the comments:

I agree, but I think that's an orthogonal feature. The purpose of pyVHDLModel is understanding the language, not custom comment metadata. Conversely, the focus of TerosHDL is interpreting multiple custom comments, while the language support is secondary. That's why it'd be interesting to combine them together. pyVHDLModel can ignore the comments and TerosHDL can process the comments only.

We have a defined json format between parser and documenter: https://github.com/TerosTechnology/colibri/blob/master/test/examples/vhdl/example_1.json If pyGHDL.dom can provide this format it's easy to integrate it.

Absolutely. Currently, the pretty printer in pyGHDL.dom produces the following output: https://github.com/umarcor/neorv32/runs/2953525135?check_suite_focus=true#step:5:460. So, the info is there already. We just need to adapt the output for generating a JSON instead of using YAML syntax. See a very minimal example about how to list the entities, generics and ports: https://github.com/vhdl/pyVHDLModel#list-all-entities-with-generics-and-ports. The complete pretty print is https://github.com/ghdl/ghdl/blob/master/pyGHDL/dom/formatting/prettyprint.py.

Maybe the only problem is to parse the comments (https://terostechnology.github.io/terosHDLdoc/features/documenter.html)

That might be tricky in the first iteration. GHDL and libghdl do ignore the comments by default. Therefore, although pyVHDLModel might handle them, currently the only implementation is pyGHDL.dom. Hence, I think it will be necessary to start with combining both pyGHDL.dom and TerosHDL's own solution.

We could first to release a version and later to integrate it in Github Actions. What do you think?

I heard @mithro say: release fast and improve iteratively; release before you think you are ready for it.
The last release of TerosHDL was in November 2020, but you've been doing much work these last months. Hence, I believe you could tag pre-releases maybe once a month, or more frequently. Tagging frequently allows users to pin known versions while not being left behind.
As commented in gitter.im/hdl/community I would like to see an Sphinx demo combining:

pyGHDL.dom for the structure, dependency diagrams and cross-references as in https://vhdl.github.io/pyVHDLModel/LanguageModel/index.html.
colibri for the registers/bitfields and the waveforms

sphinx-wavedrom

sphinxcontrib-hdl-diagrams for the RTL diagrams of the synthesisable components.

Then, we might wrap it in a single directive which provides all the features in a bundle.

Thanks @umarcor ! :D
So is it not possible to extract the comments with pyGHDL.dom? That could be a problem, since we would need a double parser (for comments and for HDL "tags").  How you can see in the terosHDL parser output (https://github.com/TerosTechnology/colibri/blob/master/test/examples/vhdl/example_1.json#L18) it provide the description (comments).
Later the documenter interprets the comments (description field) and it generates the wavedrom image... or a plan text description.
Is there a way to associate comments to ports, signals, generics... after to execute pyVHDLModel?

@qarlosalberto currently libghdl does not preserve comments. So the limitation is not pyVHDLModel or pyGHDL.dom based. The idea of pyVHDLParser is to preserved exactly this and to serve as a second input source for pyVHDLModel.

So is it not possible to extract the comments with pyGHDL.dom?

For now... rust_hdl and pyVHDLParser do preserve comments. Hence, when/if those "backends" are used for pyVHDLModel, the model itself can contain the comments.
On the other hand, GHDL removed the comments because those are not relevant for simulation or synthesis. However, since it is now being used for other use cases, it might be changed so that comments are preserved. I don't know if @Paebbels discussed this with Tristan already.
Currently, pyGHDL.dom can provide "name", "type", "direction", "default_value" and "line". The "type" and "default_value" are not just plain strings, but you can optionally get the range/limits, etc. Alternatively, you can get an string representation if you don't want to handle those details. So, TerosHDL would need to parse the comments only, for providing the "description" field to be added by name matching.

What could be the best option to parse the comments and associate them to a VHDL tag? regex + pyVHDLModel line field?

To start with something easy, I'd do it "a lo burro":

colibri > out.colibri.json
ghdl-dom --colibri > out.dom.json (naturally, ghdl-dom --colibri does not exist yet; that variation of the prettyprinter needs to be implemented)
Overwrite each field in out.colibri.json with the content of out.dom.json.

This Python snippet will do step 3:
data = {}

colibri_file = Path(__file__).resolve().parent / 'out.colibri.json'
if not colibri_file.is_file():
    print('Ups...')
    exit(1)
data = loads(colibri_file.open('r').read())

dom_file = Path(__file__).resolve().parent / 'out.dom.json'
if dom_file.is_file():
    print('Ups...')
    exit(1)
data.update(loads(dom_file.open('r').read()))

That will allow to check the compabilitity of the fields/data generated by ghdl-dom --colibri and the built-in parser. Then, it'd be a matter of removing fields from the colibri output (maybe support colibri --comments-only).

Then you want to combine the colibri descriptions with ghdl-dom, right?

Ok, I see a problem. Then we are running 2 parsers: tree-sitter-vhdl + ghdl-dom. tree-sitter-vhdl is very very slow and we will and the latency of ghdl-dom. I think that we are deleting the advantage to use ghdl-dom.
The main problem is that in colibri we need to parse the complete document to extract the comments. we can't separate it.
In my opinion the best way would be to use ghdl-dom + a simple regex parser for only the comments and too associate the comments to the VHDL tags (we could use the line??)

@qarlosalberto, agree. I'm not suggesting it as a definitive solution, but just so we can start with something usable. Rather than implementing a regex parser for the comments, I think we can all beg Tristan to pleeeeeeeeeeease let us get the comments through libghdl. I don't mind if we need to wait some weeks/months for that. I've been waiting YEARS for something such as pyVHDLModel to exist on top of GHDL 😄.
The proposal of using 2 parsers is because it allows us not to add a lot of new code now, but to use most of what is written already, and combine it as is. We can do that in a feature branch, not in main/master. Once the prototype works, we have further issues to discuss. Precisely, while I see the value in generating markdown, I don't think it's worth the effort of generating raw HTML. Instead, the HTML output should be meant to be combined with Sphinx, asciidoctor, or other static site generator engines. That allows significantly reducing the burden, since you don't need to care about styling, cross-referencing, etc. Moreover, we get PDF output "for free". Even if you don't use static site generators, the usage of templates (say jinja2, go templates, or whatever equivalent in JS) can help reuse and customisation.

okok, it's easy to do it. A command line interface with the colibri parser.

This is not urgent at all. I was just amazed by the documenter's features. :heart:
So I agree with @umarcor:

I was not criticising the lack of Action, but willing to explain Stephan why we might want to wait some days/weeks before adding the feature to this repo.

Sorry if I sound bad. Don't get me wrong.
I love this project and also @umarcor knows that I love the way he keep us all updated :)
I know we are colaborating and learning, continuously. And I Iove that :D


Expand parameter validation to type File

It's unclear how to require an uploaded multipart file parameter. We could also expand this to file formats.

@dblock I think this one is covered. Isn't it?

Yup. Also if you're sure just close it @dnesteryuk, what do I know? :)


ignore option?

I want to use it with pascalcase optioin, but I have to ignore some files, e.g. .eslintrc.js or rollup.config.js etc...
How about ignoring option?

If you want to skip linting those files entirely you can add them to .eslintignore. If you want to just disable this rule only, you can do it the usual way by adding /* eslint-disable filename-rules/match */ at the top of the file. Let me know if that solves your problem.

I want to keep other linting rules for these files.

/* eslint-disable filename-rules/match */ at the top of the file.

wow, thanks. It solves the problem.

I wanted to ignore all index.js files (maybe there's an option that supports it?) after matching all to PascalCase.
In this case, I added an override rule:
'overrides': [
    {
      'files': ['**/index.vue'],
      'rules': {
        'filename-rules/match': [0]
      }
    }
]