converting facemesh json and bin

Hi,
Thank you so much for this repository. I liked. I tried to run it with BodyPix and worked well, but when I use facemesh it generates the following problem:
    attrs = _find_if_has_key(node[attr_key], key=str_key, of_type=list) KeyError: 'attr'
I tried to follow the reason, and I found some nodes in facemesh that have not this attribute (in attr_key), but it has input and the other 2 attrs (as common). Could you kindly check  the reason why it is happening please? Follow the json.
https://storage.googleapis.com/tfhub-tfjs-modules/mediapipe/tfjs-model/facemesh/1/default/1/model.json
https://storage.googleapis.com/tfhub-tfjs-modules/mediapipe/tfjs-model/facemesh/1/default/1/group1-shard1of1.bin

Hi!
Thanks for providing the link to the model.
The model contains layers that are not supported out-of-the-box by TensorFlow.
Even fixing the problem with the node pre-processing won't help, as additional work needs to be done to support the custom layers.
I'm currently looking into this and trying to find whether I can find the package that provides the custom layer and load it if necessary.
This might take a bit,but I'll keep you posted.

@emedinac Small update: I've added a check for unsupported layer types, so the converter will now display a proper error message instead of a misleading stack trace.
Unfortunately there's no easy way to convert the model without rewriting the graph.
I will have a go at it again tonight and try to convert the Prelu-layers into standard TF-operations.

@emedinac at long last support for facemesh made it into the converter.
You can also install it directly using pip now: pip install tfjs-graph-converter should work now.

@samuraiexx Hi!
The issue is fixed in the 1.x releases. I highly recommend using the PyPi version (currently version 1.2) as it fixes some other bugs as well.


[Feature Request] Areas order, Floors support?, Add support for "unassigned to area" entities

Some nice to have features:

Be able to order areas in some way
Segmenting things by floors can be useful too
Support for "unassigned to area" entities
Exclude specific areas
Add custom section at top/bottom

What ways of ordering sections are you looking for? Right now it does alphabetically by default, what else would you like to see it do?
Would you expect the strategy to be able to create a section per floor? Depending on how entities are linked to floors, this may already be possible.
Fundamentally, this strategy already supports entities not tied to an area, just not when grouping by area, if that makes sense. Are you looking to have like a catch all group for all entities not tied to an area when grouping by area?
Excluding certain areas is a good idea, I'll add a filter for it
Adding sections at the top or bottom should be easy to implement, so I'll get on that soon-ish.

@maslyankov  I just pushed 0.6.0 which includes an area filter and the ability to add custom sections to the top or bottom of the generated list. It's also got a breaking change in that I removed some unused configuration items.

What ways of ordering sections are you looking for? Right now it does alphabetically by default, what else would you like to see it do?
Would you expect the strategy to be able to create a section per floor? Depending on how entities are linked to floors, this may already be possible.
Fundamentally, this strategy already supports entities not tied to an area, just not when grouping by area, if that makes sense. Are you looking to have like a catch all group for all entities not tied to an area when grouping by area?
Excluding certain areas is a good idea, I'll add a filter for it
Adding sections at the top or bottom should be easy to implement, so I'll get on that soon-ish.

Not sure how it would be best to configure that, but something like:

I managed to make use of the custom top sections like so:
layout: sections
views:
  - title: Main
    strategy:
      type: custom:auto-sections
      options:
        max_columns: 2
        group_by:
          - device.area_id
          - entity.area_id
        group_name: area.area_id|name
        filter:
          include:
            - hidden: false
        sections:
          top:
            - type: grid
              cards:
                - type: markdown
                  content: '# {{ state_attr("zone.home", ''friendly_name'') }}'
                - type: conditional
                  conditions:
                    - condition: state
                      entity: input_boolean.ui_home_show_weather
                      state: 'on'
                  card:
                    type: custom:auto-entities
                    card:
                      type: custom:layout-card
                      layout_type: masonry
                      layout:
                        margin: 0
                        card_margin: 0
                      cards: []
                      view_layout: {}
                    filter:
                      exclude: []
                      include:
                        - domain: weather
                          options:
                            type: custom:auto-entities
                            card:
                              type: custom:layout-card
                            filter:
                              template: |
                                {{ [
                                  {
                                    "type": "weather-forecast",
                                    "forecast_type": "daily",
                                    "entity": config.entity
                                  }
                                ] }}
                - type: conditional
                  conditions:
                    - condition: state
                      entity: input_boolean.ui_home_show_alarm_panels
                      state: 'on'
                  card:
                    type: custom:auto-entities
                    card:
                      type: custom:layout-card
                      layout_type: masonry
                      layout:
                        margin: 0
                        card_margin: 0
                      cards: []
                      view_layout: {}
                    filter:
                      exclude: []
                      include:
                        - domain: alarm_control_panel
                          options:
                            type: custom:auto-entities
                            card:
                              type: custom:layout-card
                            filter:
                              template: |
                                {{ [
                                  {
                                    "type": "tile",
                                    "entity": config.entity,
                                    "features": [
                                      {
                                        "type": "alarm-modes",
                                        "modes": ["armed_home", "armed_away", "armed_night", "armed_vacation", "armed_custom_bypass", "disarmed"]
                                      }
                                    ]
                                  }
                                ] }}
        card_options:
          _:
            type: tile
          alarm_control_panel:
            features:
              - type: alarm-modes
                modes:
                  - armed_home
                  - armed_away
                  - armed_night
                  - armed_vacation
                  - armed_custom_bypass
                  - disarmed
          climate:
            features:
              - type: target-temperature
              - type: climate-fan-modes
                style: icons
                fan_modes:
                  - 'off'
                  - low
                  - medium
                  - high
                  - on_low
                  - on_high
                  - auto_low
                  - auto_high
              - type: climate-hvac-modes
                hvac_modes:
                  - auto
                  - heat_cool
                  - heat
                  - cool
                  - dry
                  - fan_only
                  - 'off'
          cover:
            features:
              - type: cover-open-close
          lawn_mower:
            features:
              - type: lawn-mower-commands
                commands:
                  - start_pause
                  - dock
          light:
            features:
              - type: light-brightness
          lock:
            features:
              - type: lock-commands
          media_player:
            type: media-control
          camera:
            show_state: false
            show_name: false
            camera_view: live
            type: picture-entity

This allows me to show and hide info from the top using input_booleans and thus being easily configurable. The issue is that by using it this way these auto-entities cards render with delay after the whole view. Do you have an idea how we can fix this or integrate something like this in a better way? Thanks!

I don't think there's much to be done about that unfortunately. There isn't really a way to "prerender" some cards as far as I'm aware.
I've just pushed 0.7.0 that includes priority sorting by the way!

I don't think there's much to be done about that unfortunately. There isn't really a way to "prerender" some cards as far as I'm aware.
I've just pushed 0.7.0 that includes priority sorting by the way!

You are awesome! Thank you for the update, looks great! For the cards, I was thinking that maybe the top/bottom cards can be configured the same way the sections filters/options are configured with includes/excludes, etc. This would remove the need to have that inclusion of auto-entities as above with the same result (minus the additional load)

maybe the top/bottom cards can be configured the same way the sections filters/options are currently configured with includes/excludes, etc.

Yeah, that's about the only way that I would be able to possibly fix the delay, but I really don't want to re-implement the auto-entities card. It's already pretty damn good at what it does. I think this is where I'll draw the lines in terms of the scope for this project.
Seeing as all the other requested features have been implemented (I'll add the device class filter later, that's another easy one), I'll close this issue as completed. Feel free to open other issues for more feature requests!


copy grayed out

When using yabai, the copy option in the right-click menu is (~always?~ no, not always....this is going to complicate things I'm aware) grayed out:

Command+C still works however.
After stopping the service, the copy option is available:

My system is an M2 macbook pro.
I assume this is a permissions issue, so I'll mention another issue I've noticed: when yabai is active, neither touch-id nor passwords work for authentication, e.g. to adjust app permissions. I have to stop the service, make the change (and authenticate), and afterwards restart the service. This is not too much of a hassle; I just mention it in case it's related.

I have not seen any of these issues in the latest versions, so closing this.


Small suggested clarifications

The word "E-Trace", used on pages 9, 10 and 79, presumably stands for "Efficient Trace", but AFAIK is nowhere so defined.
Suggest adding an item in Section 1.1 Terminology for this.

‘ucause’ is mentioned in Section 3.2.3; Section 4.1 second bullet; table 4.
‘utval’ is mentioned in Section 4.1 second bullet; Table 4; Table 17; 7.3.2.
AFAIK these CSRs were removed from the Privileged ISA spec?

In Section 4.1, we have:
The following information is mandatory:
...
* The instruction_type of retired instructions for:
  * Jumps with a target that cannot be inferred from the source code;
...

and
The following information is optional:
...
* The instruction_type of instructions for:
  ...
  * Jumps with a target that cannot be inferred from the source code;

This seems contradictory (both mandatory and optional)?

Rishiyur,
That's a good observation, and does indeed appear contradictory.  It came about as a result of an earlier clarification attempt.  The list of optional types in section 4.1 corresponds to the more detailed classifications in section 4.11.  Originally, this was broken down into Calls, Tail-calls, Returns, Co-routine swap and Other.  However, there is no formal definition of tail-call in the RISC-V ISA, and so references to 'tail call' in both section 4.1.1 and 4.1 were replaced with 'jump'.  With hindsight, this is too general, and probably needs to be something like "jump with discarded link address" or "call with discarded link address"
Please open an issue against the spec (https://github.com/riscv-non-isa/riscv-trace-spec/issues) and I'll address this in the next update.
Iain
From: Rishiyur S. Nikhil @.>
Sent: 03 September 2024 18:32
To: riscv-non-isa/riscv-trace-spec @.>
Cc: Subscribed @.***>
Subject: Re: [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
In Section 4.1, we have:
The following information is mandatory:
...

The instruction_type of retired instructions for:

Jumps with a target that cannot be inferred from the source code;

...
and
The following information is optional:
...

The instruction_type of instructions for:
...

Jumps with a target that cannot be inferred from the source code;

This seems contradictory (both mandatory and optional)?

Reply to this email directly, view it on GitHubhttps://github.com/riscv-non-isa/riscv-trace-spec/issues/138#issuecomment-2327070149, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSV4KFRG7M7M4S5F2K3ZUXW7VAVCNFSM6AAAAABNQZL5VGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRXGA3TAMJUHE.
You are receiving this because you are subscribed to this thread.Message ID<EMAIL_ADDRESS>

FWIW, when CTR went through ARC review, ARC requested the following
definitions for the various control transfer types:
[image: image.png]
On Wed, Sep 4, 2024 at 1:29 AM Mr Iain Robertson via lists.riscv.org
@.***> wrote:

Rishiyur,
            That’s a good observation, and does indeed appear

contradictory.  It came about as a result of an earlier clarification
attempt.  The list of optional types in section 4.1 corresponds to the more
detailed classifications in section 4.11.  Originally, this was broken down
into Calls, Tail-calls, Returns, Co-routine swap and Other.  However, there
is no formal definition of tail-call in the RISC-V ISA, and so references
to ‘tail call’ in both section 4.1.1 and 4.1 were replaced with ‘jump’.
With hindsight, this is too general, and probably needs to be something
like “jump with discarded link address” or “call with discarded link
address”
Please open an issue against the spec (
https://github.com/riscv-non-isa/riscv-trace-spec/issues) and I’ll
address this in the next update.
Iain
From: Rishiyur S. Nikhil @.>
Sent: 03 September 2024 18:32
To: riscv-non-isa/riscv-trace-spec @.>
Cc: Subscribed @.***>
Subject: Re: [riscv-non-isa/riscv-trace-spec] Small suggested
clarifications (Issue #138)
In Section 4.1, we have:
The following information is mandatory:
...

The instruction_type of retired instructions for:

Jumps with a target that cannot be inferred from the source code;

...
and
The following information is optional:
...

The instruction_type of instructions for:
...

Jumps with a target that cannot be inferred from the source code;

This seems contradictory (both mandatory and optional)?
—
Reply to this email directly, view it on GitHub
https://github.com/riscv-non-isa/riscv-trace-spec/issues/138#issuecomment-2327070149,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALQOPSV4KFRG7M7M4S5F2K3ZUXW7VAVCNFSM6AAAAABNQZL5VGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRXGA3TAMJUHE
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>
.,.,_
Links:
You receive all messages sent to this group.
View/Reply Online (#598)
https://lists.riscv.org/g/sig-debug-trace-perf-mon/message/598 | Reply
To Group
@.?subject=Re:%20Re%3A%20%5BRISC-V%5D%20%5Bsig-debug-trace-perf-mon%5D%20%5Briscv-non-isa%2Friscv-trace-spec%5D%20Small%20suggested%20clarifications%20%28Issue%20%23138%29>
| Reply To Sender
@.?subject=Private:%20Re:%20Re%3A%20%5BRISC-V%5D%20%5Bsig-debug-trace-perf-mon%5D%20%5Briscv-non-isa%2Friscv-trace-spec%5D%20Small%20suggested%20clarifications%20%28Issue%20%23138%29>
| Mute This Topic https://lists.riscv.org/mt/108261477/6477655 | New
Topic https://lists.riscv.org/g/sig-debug-trace-perf-mon/post
Your Subscription
https://lists.riscv.org/g/sig-debug-trace-perf-mon/editsub/6477655 | Contact
Group Owner @.> | Unsubscribe
https://lists.riscv.org/g/sig-debug-trace-perf-mon/unsub [
@.
.,.,_

Beeman,
Thanks – that looks like the terminology we should adopt.  Unfortunately your screen-grab doesn’t show up in the GIT issue – can you paste plain text or include a reference that I can follow later please?
Iain
From: Beeman Strong @.>
Sent: 04 September 2024 15:45
To: @.; Robertson, Iain (DI SW ICS DDCP TST RD EAH) @.>
Cc: riscv-non-isa/riscv-trace-spec @.>; riscv-non-isa/riscv-trace-spec @.>; Subscribed @.>
Subject: Re: [RISC-V] [sig-debug-trace-perf-mon] [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
FWIW, when CTR went through ARC review, ARC requested the following definitions for the various control transfer types:
@.***
On Wed, Sep 4, 2024 at 1:29 AM Mr Iain Robertson via lists.riscv.orghttp://lists.riscv.org/<EMAIL_ADDRESS>wrote:
Rishiyur,
That’s a good observation, and does indeed appear contradictory.  It came about as a result of an earlier clarification attempt.  The list of optional types in section 4.1 corresponds to the more detailed classifications in section 4.11.  Originally, this was broken down into Calls, Tail-calls, Returns, Co-routine swap and Other.  However, there is no formal definition of tail-call in the RISC-V ISA, and so references to ‘tail call’ in both section 4.1.1 and 4.1 were replaced with ‘jump’.  With hindsight, this is too general, and probably needs to be something like “jump with discarded link address” or “call with discarded link address”
Please open an issue against the spec (https://github.com/riscv-non-isa/riscv-trace-spec/issues) and I’ll address this in the next update.
Iain
From: Rishiyur S. Nikhil<EMAIL_ADDRESS>Sent: 03 September 2024 18:32
To: riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Subject: Re: [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
In Section 4.1, we have:
The following information is mandatory:
...

The instruction_type of retired instructions for:

Jumps with a target that cannot be inferred from the source code;

...
and
The following information is optional:
...

The instruction_type of instructions for:
...

Jumps with a target that cannot be inferred from the source code;

This seems contradictory (both mandatory and optional)?
—
Reply to this email directly, view it on GitHubhttps://github.com/riscv-non-isa/riscv-trace-spec/issues/138#issuecomment-2327070149, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSV4KFRG7M7M4S5F2K3ZUXW7VAVCNFSM6AAAAABNQZL5VGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRXGA3TAMJUHE.
You are receiving this because you are subscribed to this thread.Message ID<EMAIL_ADDRESS>.,.,_

Links:
You receive all messages sent to this group.
View/Reply Online (#598)https://lists.riscv.org/g/sig-debug-trace-perf-mon/message/598 | Reply To @.?subject=Re:%20Re%3A%20%5BRISC-V%5D%20%5Bsig-debug-trace-perf-mon%5D%20%5Briscv-non-isa%2Friscv-trace-spec%5D%20Small%20suggested%20clarifications%20%28Issue%20%23138%29> | Reply To @.?subject=Private:%20Re:%20Re%3A%20%5BRISC-V%5D%20%5Bsig-debug-trace-perf-mon%5D%20%5Briscv-non-isa%2Friscv-trace-spec%5D%20Small%20suggested%20clarifications%20%28Issue%20%23138%29> | Mute This Topichttps://lists.riscv.org/mt/108261477/6477655 | New Topichttps://lists.riscv.org/g/sig-debug-trace-perf-mon/post
Your Subscriptionhttps://lists.riscv.org/g/sig-debug-trace-perf-mon/editsub/6477655 | Contact Group @.> | Unsubscribehttps://lists.riscv.org/g/sig-debug-trace-perf-mon/unsub<EMAIL_ADDRESS>.,.,_

Sure, I'll paste the adoc text.
On Wed, Sep 4, 2024 at 8:40 AM Robertson, Iain @.***>
wrote:

Beeman,
            Thanks – that looks like the terminology we should adopt.

Unfortunately your screen-grab doesn’t show up in the GIT issue – can you
paste plain text or include a reference that I can follow later please?
Iain
From: Beeman Strong @.>
Sent: 04 September 2024 15:45
To: @.; Robertson, Iain (DI SW
ICS DDCP TST RD EAH) @.>
Cc: riscv-non-isa/riscv-trace-spec <
@.>;
riscv-non-isa/riscv-trace-spec @.>;
Subscribed @.>
Subject: Re: [RISC-V] [sig-debug-trace-perf-mon]
[riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
FWIW, when CTR went through ARC review, ARC requested the following
definitions for the various control transfer types:
On Wed, Sep 4, 2024 at 1:29 AM Mr Iain Robertson via lists.riscv.org
@.***> wrote:
Rishiyur,
            That’s a good observation, and does indeed appear

contradictory.  It came about as a result of an earlier clarification
attempt.  The list of optional types in section 4.1 corresponds to the more
detailed classifications in section 4.11.  Originally, this was broken down
into Calls, Tail-calls, Returns, Co-routine swap and Other.  However, there
is no formal definition of tail-call in the RISC-V ISA, and so references
to ‘tail call’ in both section 4.1.1 and 4.1 were replaced with ‘jump’.
With hindsight, this is too general, and probably needs to be something
like “jump with discarded link address” or “call with discarded link
address”
Please open an issue against the spec (
https://github.com/riscv-non-isa/riscv-trace-spec/issues) and I’ll
address this in the next update.
Iain
From: Rishiyur S. Nikhil @.>
Sent: 03 September 2024 18:32
To: riscv-non-isa/riscv-trace-spec @.>
Cc: Subscribed @.***>
Subject: Re: [riscv-non-isa/riscv-trace-spec] Small suggested
clarifications (Issue #138)
In Section 4.1, we have:
The following information is mandatory:
...

The instruction_type of retired instructions for:

Jumps with a target that cannot be inferred from the source code;

...
and
The following information is optional:
...

The instruction_type of instructions for:
...

Jumps with a target that cannot be inferred from the source code;

This seems contradictory (both mandatory and optional)?
—
Reply to this email directly, view it on GitHub
https://github.com/riscv-non-isa/riscv-trace-spec/issues/138#issuecomment-2327070149,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALQOPSV4KFRG7M7M4S5F2K3ZUXW7VAVCNFSM6AAAAABNQZL5VGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRXGA3TAMJUHE
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>
.,.,_
Links:
You receive all messages sent to this group.
View/Reply Online (#598)
https://lists.riscv.org/g/sig-debug-trace-perf-mon/message/598 | Reply
To Group
@.?subject=Re:%20Re%3A%20%5BRISC-V%5D%20%5Bsig-debug-trace-perf-mon%5D%20%5Briscv-non-isa%2Friscv-trace-spec%5D%20Small%20suggested%20clarifications%20%28Issue%20%23138%29>
| Reply To Sender
@.?subject=Private:%20Re:%20Re%3A%20%5BRISC-V%5D%20%5Bsig-debug-trace-perf-mon%5D%20%5Briscv-non-isa%2Friscv-trace-spec%5D%20Small%20suggested%20clarifications%20%28Issue%20%23138%29>
| Mute This Topic https://lists.riscv.org/mt/108261477/6477655 | New
Topic https://lists.riscv.org/g/sig-debug-trace-perf-mon/post
Your Subscription
https://lists.riscv.org/g/sig-debug-trace-perf-mon/editsub/6477655 | Contact
Group Owner @.> | Unsubscribe
https://lists.riscv.org/g/sig-debug-trace-perf-mon/unsub [
@.
.,.,_

It was also improved in N-Trace.  See this:
https://github.com/riscv-non-isa/tg-nexus-trace/blob/main/docs/RISC-V-N-Trace.adoc#2-trace-ingress-port
IMPORTANT: I am against that PR mentioned below.
We agreed to EXTRACT this into SINGLE source (as fast-track).
Thanks,
Robert

From: @.*** @.> on behalf of Mr Iain Robertson via lists.riscv.org @.>
Sent: Wednesday, September 4, 2024 8:40 AM
To: Beeman Strong @.>; @. @.>
Cc: riscv-non-isa/riscv-trace-spec @.>; riscv-non-isa/riscv-trace-spec @.>; Subscribed @.>
Subject: [EXTERNAL]Re: [RISC-V] [sig-debug-trace-perf-mon] [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
Beeman,
            Thanks – that looks like the terminology we should adopt.  Unfortunately your screen-grab doesn’t show up in the GIT issue – can you paste plain text or include a reference that I can follow later please?

Iain
From: Beeman Strong @.>
Sent: 04 September 2024 15:45
To: @.; Robertson, Iain (DI SW ICS DDCP TST RD EAH) @.>
Cc: riscv-non-isa/riscv-trace-spec @.>; riscv-non-isa/riscv-trace-spec @.>; Subscribed @.>
Subject: Re: [RISC-V] [sig-debug-trace-perf-mon] [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
FWIW, when CTR went through ARC review, ARC requested the following definitions for the various control transfer types:
@.***
On Wed, Sep 4, 2024 at 1:29 AM Mr Iain Robertson via lists.riscv.orghttp://lists.riscv.org/<EMAIL_ADDRESS>wrote:
Rishiyur,
            That’s a good observation, and does indeed appear contradictory.  It came about as a result of an earlier clarification attempt.  The list of optional types in section 4.1 corresponds to the more detailed classifications in section 4.11.  Originally, this was broken down into Calls, Tail-calls, Returns, Co-routine swap and Other.  However, there is no formal definition of tail-call in the RISC-V ISA, and so references to ‘tail call’ in both section 4.1.1 and 4.1 were replaced with ‘jump’.  With hindsight, this is too general, and probably needs to be something like “jump with discarded link address” or “call with discarded link address”

Please open an issue against the spec (https://github.com/riscv-non-isa/riscv-trace-spec/issues) and I’ll address this in the next update.
Iain
From: Rishiyur S. Nikhil<EMAIL_ADDRESS>Sent: 03 September 2024 18:32
To: riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Subject: Re: [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
In Section 4.1, we have:
The following information is mandatory:
...

The instruction_type of retired instructions for:

Jumps with a target that cannot be inferred from the source code;

...
and
The following information is optional:
...

The instruction_type of instructions for:
...

Jumps with a target that cannot be inferred from the source code;

This seems contradictory (both mandatory and optional)?
—
Reply to this email directly, view it on GitHubhttps://github.com/riscv-non-isa/riscv-trace-spec/issues/138#issuecomment-2327070149, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSV4KFRG7M7M4S5F2K3ZUXW7VAVCNFSM6AAAAABNQZL5VGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRXGA3TAMJUHE.
You are receiving this because you are subscribed to this thread.Message ID<EMAIL_ADDRESS>.,.,_

Links:
You receive all messages sent to this group.
View/Reply Online (#610)https://lists.riscv.org/g/sig-debug-trace-perf-mon/message/610 | Reply To @.?subject=Re:%20Re%3A%20%5BRISC-V%5D%20%5Bsig-debug-trace-perf-mon%5D%20%5Briscv-non-isa%2Friscv-trace-spec%5D%20Small%20suggested%20clarifications%20%28Issue%20%23138%29> | Reply To @.?subject=Private:%20Re:%20Re%3A%20%5BRISC-V%5D%20%5Bsig-debug-trace-perf-mon%5D%20%5Briscv-non-isa%2Friscv-trace-spec%5D%20Small%20suggested%20clarifications%20%28Issue%20%23138%29> | Mute This Topichttps://lists.riscv.org/mt/108261477/1782486 | New Topichttps://lists.riscv.org/g/sig-debug-trace-perf-mon/post
Your Subscriptionhttps://lists.riscv.org/g/sig-debug-trace-perf-mon/editsub/1782486 | Contact Group @.> | Unsubscribehttps://lists.riscv.org/g/sig-debug-trace-perf-mon/unsub @.
.,.,_

I see the issue hasn't been filed yet, so pasting the text here:
|INDCALLINH |Inhibit recording of indirect calls.  See <>.
|DIRCALLINH |Inhibit recording of direct calls.  See <>.
|INDJMPINH |Inhibit recording of indirect jumps (without linkage).  See
<>.
|DIRJMPINH |Inhibit recording of direct jumps (without linkage).  See
<>.
|CORSWAPINH |Inhibit recording of co-routine swaps.  See <>.
|RETINH |Inhibit recording of function returns.  See <>.
|INDLJMPINH |Inhibit recording of other indirect jumps (with linkage).  See
<>.
|DIRLJMPINH |Inhibit recording of other direct jumps (with linkage).  See
<>.
On Wed, Sep 4, 2024 at 8:58 AM Beeman Strong @.***> wrote:

Sure, I'll paste the adoc text.
On Wed, Sep 4, 2024 at 8:40 AM Robertson, Iain @.***>
wrote:

Beeman,
            Thanks – that looks like the terminology we should

adopt.  Unfortunately your screen-grab doesn’t show up in the GIT issue –
can you paste plain text or include a reference that I can follow later
please?
Iain
From: Beeman Strong @.>
Sent: 04 September 2024 15:45
To: @.; Robertson, Iain (DI SW
ICS DDCP TST RD EAH) @.>
Cc: riscv-non-isa/riscv-trace-spec <
@.>;
riscv-non-isa/riscv-trace-spec @.>;
Subscribed @.>
Subject: Re: [RISC-V] [sig-debug-trace-perf-mon]
[riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
FWIW, when CTR went through ARC review, ARC requested the following
definitions for the various control transfer types:
On Wed, Sep 4, 2024 at 1:29 AM Mr Iain Robertson via lists.riscv.org
@.***> wrote:
Rishiyur,
            That’s a good observation, and does indeed appear

contradictory.  It came about as a result of an earlier clarification
attempt.  The list of optional types in section 4.1 corresponds to the more
detailed classifications in section 4.11.  Originally, this was broken down
into Calls, Tail-calls, Returns, Co-routine swap and Other.  However, there
is no formal definition of tail-call in the RISC-V ISA, and so references
to ‘tail call’ in both section 4.1.1 and 4.1 were replaced with ‘jump’.
With hindsight, this is too general, and probably needs to be something
like “jump with discarded link address” or “call with discarded link
address”
Please open an issue against the spec (
https://github.com/riscv-non-isa/riscv-trace-spec/issues) and I’ll
address this in the next update.
Iain
From: Rishiyur S. Nikhil @.>
Sent: 03 September 2024 18:32
To: riscv-non-isa/riscv-trace-spec @.

Cc: Subscribed @.***>
Subject: Re: [riscv-non-isa/riscv-trace-spec] Small suggested
clarifications (Issue #138)
In Section 4.1, we have:
The following information is mandatory:
...

The instruction_type of retired instructions for:

Jumps with a target that cannot be inferred from the source code;

...
and
The following information is optional:
...

The instruction_type of instructions for:
...

Jumps with a target that cannot be inferred from the source code;

This seems contradictory (both mandatory and optional)?
—
Reply to this email directly, view it on GitHub
https://github.com/riscv-non-isa/riscv-trace-spec/issues/138#issuecomment-2327070149,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALQOPSV4KFRG7M7M4S5F2K3ZUXW7VAVCNFSM6AAAAABNQZL5VGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRXGA3TAMJUHE
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>
.,.,_
Links:
You receive all messages sent to this group.
View/Reply Online (#598)
https://lists.riscv.org/g/sig-debug-trace-perf-mon/message/598 | Reply
To Group
@.?subject=Re:%20Re%3A%20%5BRISC-V%5D%20%5Bsig-debug-trace-perf-mon%5D%20%5Briscv-non-isa%2Friscv-trace-spec%5D%20Small%20suggested%20clarifications%20%28Issue%20%23138%29>
| Reply To Sender
@.?subject=Private:%20Re:%20Re%3A%20%5BRISC-V%5D%20%5Bsig-debug-trace-perf-mon%5D%20%5Briscv-non-isa%2Friscv-trace-spec%5D%20Small%20suggested%20clarifications%20%28Issue%20%23138%29>
| Mute This Topic https://lists.riscv.org/mt/108261477/6477655 | New
Topic https://lists.riscv.org/g/sig-debug-trace-perf-mon/post
Your Subscription
https://lists.riscv.org/g/sig-debug-trace-perf-mon/editsub/6477655 | Contact
Group Owner @.> |
Unsubscribe https://lists.riscv.org/g/sig-debug-trace-perf-mon/unsub [
@.
.,.,_

Robert,
The issue is for a request to clarify chapter 4.  Whether that is done as part of an incremental update to the E-Trace spec (along with some other clarifications and corrections) before we pull out chapter 4, or whether chapter 4 gets pulled out first and the clarifications are handled as part of that makes no difference – the important thing is that we have a record of the need for clarification.
Iain
From: Robert Chyla @.>
Sent: 04 September 2024 17:32
To: Beeman Strong @.>; @.; Robertson, Iain (DI SW ICS DDCP TST RD EAH) @.>
Cc: riscv-non-isa/riscv-trace-spec @.>; riscv-non-isa/riscv-trace-spec @.>; Subscribed @.***>
Subject: Re: [EXTERNAL]Re: [RISC-V] [sig-debug-trace-perf-mon] [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
It was also improved in N-Trace.  See this:
https://github.com/riscv-non-isa/tg-nexus-trace/blob/main/docs/RISC-V-N-Trace.adoc#2-trace-ingress-port
IMPORTANT: I am against that PR mentioned below.
We agreed to EXTRACT this into SINGLE source (as fast-track).
Thanks,
Robert

From<EMAIL_ADDRESS><EMAIL_ADDRESS>on behalf of Mr Iain Robertson via lists.riscv.org<EMAIL_ADDRESS>Sent: Wednesday, September 4, 2024 8:40 AM
To: Beeman Strong<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Cc: riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>Subscribed<EMAIL_ADDRESS>Subject: [EXTERNAL]Re: [RISC-V] [sig-debug-trace-perf-mon] [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
Beeman,
            Thanks – that looks like the terminology we should adopt.  Unfortunately your screen-grab doesn’t show up in the GIT issue – can you paste plain text or include a reference that I can follow later please?

Iain
From: Beeman Strong<EMAIL_ADDRESS>Sent: 04 September 2024 15:45
To<EMAIL_ADDRESS>Robertson, Iain (DI SW ICS DDCP TST RD EAH<EMAIL_ADDRESS>Cc: riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>Subscribed<EMAIL_ADDRESS>Subject: Re: [RISC-V] [sig-debug-trace-perf-mon] [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
FWIW, when CTR went through ARC review, ARC requested the following definitions for the various control transfer types:
@.***
On Wed, Sep 4, 2024 at 1:29 AM Mr Iain Robertson via lists.riscv.orghttp://lists.riscv.org/<EMAIL_ADDRESS>wrote:
Rishiyur,
            That’s a good observation, and does indeed appear contradictory.  It came about as a result of an earlier clarification attempt.  The list of optional types in section 4.1 corresponds to the more detailed classifications in section 4.11.  Originally, this was broken down into Calls, Tail-calls, Returns, Co-routine swap and Other.  However, there is no formal definition of tail-call in the RISC-V ISA, and so references to ‘tail call’ in both section 4.1.1 and 4.1 were replaced with ‘jump’.  With hindsight, this is too general, and probably needs to be something like “jump with discarded link address” or “call with discarded link address”

Please open an issue against the spec (https://github.com/riscv-non-isa/riscv-trace-spec/issues) and I’ll address this in the next update.
Iain
From: Rishiyur S. Nikhil<EMAIL_ADDRESS>Sent: 03 September 2024 18:32
To: riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Subject: Re: [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
In Section 4.1, we have:
The following information is mandatory:
...

The instruction_type of retired instructions for:

Jumps with a target that cannot be inferred from the source code;

...
and
The following information is optional:
...

The instruction_type of instructions for:
...

Jumps with a target that cannot be inferred from the source code;

This seems contradictory (both mandatory and optional)?
—
Reply to this email directly, view it on GitHubhttps://github.com/riscv-non-isa/riscv-trace-spec/issues/138#issuecomment-2327070149, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSV4KFRG7M7M4S5F2K3ZUXW7VAVCNFSM6AAAAABNQZL5VGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRXGA3TAMJUHE.
You are receiving this because you are subscribed to this thread.Message ID<EMAIL_ADDRESS>.,.,_

Links:
You receive all messages sent to this group.
View/Reply Online (#610)https://lists.riscv.org/g/sig-debug-trace-perf-mon/message/610 | Reply To @.?subject=Re:%20Re%3A%20%5BRISC-V%5D%20%5Bsig-debug-trace-perf-mon%5D%20%5Briscv-non-isa%2Friscv-trace-spec%5D%20Small%20suggested%20clarifications%20%28Issue%20%23138%29> | Reply To @.?subject=Private:%20Re:%20Re%3A%20%5BRISC-V%5D%20%5Bsig-debug-trace-perf-mon%5D%20%5Briscv-non-isa%2Friscv-trace-spec%5D%20Small%20suggested%20clarifications%20%28Issue%20%23138%29> | Mute This Topichttps://lists.riscv.org/mt/108261477/1782486 | New Topichttps://lists.riscv.org/g/sig-debug-trace-perf-mon/post
Your Subscriptionhttps://lists.riscv.org/g/sig-debug-trace-perf-mon/editsub/1782486 | Contact Group @.> | Unsubscribehttps://lists.riscv.org/g/sig-debug-trace-perf-mon/unsub @.
.,.,_

N-Trace has 'correct' (ARC-blessed ...) names.
We (me, Jay, Ved=ARC) spent a lot of time (several meetings with ARC) making 'itype' names correctly named and correctly explained.
I assume 'extracted spec' will inherit this.
Thanks,
Robert

From: Robertson, Iain @.>
Sent: Wednesday, September 4, 2024 9:50 AM
To: Robert Chyla @.>; Beeman Strong @.>; @. @.>
Cc: riscv-non-isa/riscv-trace-spec @.>; riscv-non-isa/riscv-trace-spec @.>; Subscribed @.>
Subject: RE: [EXTERNAL]Re: [RISC-V] [sig-debug-trace-perf-mon] [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
Robert,
         The issue is for a request to clarify chapter 4.  Whether that is done as part of an incremental update to the E-Trace spec (along with some other clarifications and corrections) before we pull out chapter 4, or whether chapter 4 gets pulled out first and the clarifications are handled as part of that makes no difference – the important thing is that we have a record of the need for clarification.

Iain
From: Robert Chyla @.>
Sent: 04 September 2024 17:32
To: Beeman Strong @.>; @.; Robertson, Iain (DI SW ICS DDCP TST RD EAH) @.>
Cc: riscv-non-isa/riscv-trace-spec @.>; riscv-non-isa/riscv-trace-spec @.>; Subscribed @.***>
Subject: Re: [EXTERNAL]Re: [RISC-V] [sig-debug-trace-perf-mon] [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
It was also improved in N-Trace.  See this:
https://github.com/riscv-non-isa/tg-nexus-trace/blob/main/docs/RISC-V-N-Trace.adoc#2-trace-ingress-port
IMPORTANT: I am against that PR mentioned below.
We agreed to EXTRACT this into SINGLE source (as fast-track).
Thanks,
Robert

From<EMAIL_ADDRESS><EMAIL_ADDRESS>on behalf of Mr Iain Robertson via lists.riscv.org<EMAIL_ADDRESS>Sent: Wednesday, September 4, 2024 8:40 AM
To: Beeman Strong<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Cc: riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>Subscribed<EMAIL_ADDRESS>Subject: [EXTERNAL]Re: [RISC-V] [sig-debug-trace-perf-mon] [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
Beeman,
            Thanks – that looks like the terminology we should adopt.  Unfortunately your screen-grab doesn’t show up in the GIT issue – can you paste plain text or include a reference that I can follow later please?

Iain
From: Beeman Strong<EMAIL_ADDRESS>Sent: 04 September 2024 15:45
To<EMAIL_ADDRESS>Robertson, Iain (DI SW ICS DDCP TST RD EAH<EMAIL_ADDRESS>Cc: riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>Subscribed<EMAIL_ADDRESS>Subject: Re: [RISC-V] [sig-debug-trace-perf-mon] [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
FWIW, when CTR went through ARC review, ARC requested the following definitions for the various control transfer types:
@.***
On Wed, Sep 4, 2024 at 1:29 AM Mr Iain Robertson via lists.riscv.orghttp://lists.riscv.org/<EMAIL_ADDRESS>wrote:
Rishiyur,
            That’s a good observation, and does indeed appear contradictory.  It came about as a result of an earlier clarification attempt.  The list of optional types in section 4.1 corresponds to the more detailed classifications in section 4.11.  Originally, this was broken down into Calls, Tail-calls, Returns, Co-routine swap and Other.  However, there is no formal definition of tail-call in the RISC-V ISA, and so references to ‘tail call’ in both section 4.1.1 and 4.1 were replaced with ‘jump’.  With hindsight, this is too general, and probably needs to be something like “jump with discarded link address” or “call with discarded link address”

Please open an issue against the spec (https://github.com/riscv-non-isa/riscv-trace-spec/issues) and I’ll address this in the next update.
Iain
From: Rishiyur S. Nikhil<EMAIL_ADDRESS>Sent: 03 September 2024 18:32
To: riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Subject: Re: [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
In Section 4.1, we have:
The following information is mandatory:
...

The instruction_type of retired instructions for:

Jumps with a target that cannot be inferred from the source code;

...
and
The following information is optional:
...

The instruction_type of instructions for:
...

Jumps with a target that cannot be inferred from the source code;

This seems contradictory (both mandatory and optional)?
—
Reply to this email directly, view it on GitHubhttps://github.com/riscv-non-isa/riscv-trace-spec/issues/138#issuecomment-2327070149, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSV4KFRG7M7M4S5F2K3ZUXW7VAVCNFSM6AAAAABNQZL5VGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRXGA3TAMJUHE.
You are receiving this because you are subscribed to this thread.Message ID<EMAIL_ADDRESS>.,.,_

Links:
You receive all messages sent to this group.
View/Reply Online (#610)https://lists.riscv.org/g/sig-debug-trace-perf-mon/message/610 | Reply To @.?subject=Re:%20Re%3A%20%5BRISC-V%5D%20%5Bsig-debug-trace-perf-mon%5D%20%5Briscv-non-isa%2Friscv-trace-spec%5D%20Small%20suggested%20clarifications%20%28Issue%20%23138%29> | Reply To @.?subject=Private:%20Re:%20Re%3A%20%5BRISC-V%5D%20%5Bsig-debug-trace-perf-mon%5D%20%5Briscv-non-isa%2Friscv-trace-spec%5D%20Small%20suggested%20clarifications%20%28Issue%20%23138%29> | Mute This Topichttps://lists.riscv.org/mt/108261477/1782486 | New Topichttps://lists.riscv.org/g/sig-debug-trace-perf-mon/post
Your Subscriptionhttps://lists.riscv.org/g/sig-debug-trace-perf-mon/editsub/1782486 | Contact Group @.> | Unsubscribehttps://lists.riscv.org/g/sig-debug-trace-perf-mon/unsub @.
.,.,_

Robert,
Yes, and those are the same names Beeman put forward.  Again, no reason not to update the E-Trace spec if it happens that an update is done before chapter 4 is pulled out.
Iain
From: Robert Chyla @.>
Sent: 04 September 2024 17:54
To: Robertson, Iain (DI SW ICS DDCP TST RD EAH) @.>; Beeman Strong @.>; @.
Cc: riscv-non-isa/riscv-trace-spec @.>; riscv-non-isa/riscv-trace-spec @.>; Subscribed @.***>
Subject: Re: [EXTERNAL]Re: [RISC-V] [sig-debug-trace-perf-mon] [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
N-Trace has 'correct' (ARC-blessed ...) names.
We (me, Jay, Ved=ARC) spent a lot of time (several meetings with ARC) making 'itype' names correctly named and correctly explained.
I assume 'extracted spec' will inherit this.
Thanks,
Robert

From: Robertson, Iain<EMAIL_ADDRESS>Sent: Wednesday, September 4, 2024 9:50 AM
To: Robert Chyla<EMAIL_ADDRESS>Beeman Strong<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Cc: riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>Subscribed<EMAIL_ADDRESS>Subject: RE: [EXTERNAL]Re: [RISC-V] [sig-debug-trace-perf-mon] [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
Robert,
         The issue is for a request to clarify chapter 4.  Whether that is done as part of an incremental update to the E-Trace spec (along with some other clarifications and corrections) before we pull out chapter 4, or whether chapter 4 gets pulled out first and the clarifications are handled as part of that makes no difference – the important thing is that we have a record of the need for clarification.

Iain
From: Robert Chyla<EMAIL_ADDRESS>Sent: 04 September 2024 17:32
To: Beeman Strong<EMAIL_ADDRESS><EMAIL_ADDRESS>Robertson, Iain (DI SW ICS DDCP TST RD EAH<EMAIL_ADDRESS>Cc: riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>Subscribed<EMAIL_ADDRESS>Subject: Re: [EXTERNAL]Re: [RISC-V] [sig-debug-trace-perf-mon] [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
It was also improved in N-Trace.  See this:
https://github.com/riscv-non-isa/tg-nexus-trace/blob/main/docs/RISC-V-N-Trace.adoc#2-trace-ingress-port
IMPORTANT: I am against that PR mentioned below.
We agreed to EXTRACT this into SINGLE source (as fast-track).
Thanks,
Robert

From<EMAIL_ADDRESS><EMAIL_ADDRESS>on behalf of Mr Iain Robertson via lists.riscv.org<EMAIL_ADDRESS>Sent: Wednesday, September 4, 2024 8:40 AM
To: Beeman Strong<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Cc: riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>Subscribed<EMAIL_ADDRESS>Subject: [EXTERNAL]Re: [RISC-V] [sig-debug-trace-perf-mon] [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
Beeman,
            Thanks – that looks like the terminology we should adopt.  Unfortunately your screen-grab doesn’t show up in the GIT issue – can you paste plain text or include a reference that I can follow later please?

Iain
From: Beeman Strong<EMAIL_ADDRESS>Sent: 04 September 2024 15:45
To<EMAIL_ADDRESS>Robertson, Iain (DI SW ICS DDCP TST RD EAH<EMAIL_ADDRESS>Cc: riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>Subscribed<EMAIL_ADDRESS>Subject: Re: [RISC-V] [sig-debug-trace-perf-mon] [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
FWIW, when CTR went through ARC review, ARC requested the following definitions for the various control transfer types:
@.***
On Wed, Sep 4, 2024 at 1:29 AM Mr Iain Robertson via lists.riscv.orghttp://lists.riscv.org/<EMAIL_ADDRESS>wrote:
Rishiyur,
            That’s a good observation, and does indeed appear contradictory.  It came about as a result of an earlier clarification attempt.  The list of optional types in section 4.1 corresponds to the more detailed classifications in section 4.11.  Originally, this was broken down into Calls, Tail-calls, Returns, Co-routine swap and Other.  However, there is no formal definition of tail-call in the RISC-V ISA, and so references to ‘tail call’ in both section 4.1.1 and 4.1 were replaced with ‘jump’.  With hindsight, this is too general, and probably needs to be something like “jump with discarded link address” or “call with discarded link address”

Please open an issue against the spec (https://github.com/riscv-non-isa/riscv-trace-spec/issues) and I’ll address this in the next update.
Iain
From: Rishiyur S. Nikhil<EMAIL_ADDRESS>Sent: 03 September 2024 18:32
To: riscv-non-isa/riscv-trace-spec<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Subject: Re: [riscv-non-isa/riscv-trace-spec] Small suggested clarifications (Issue #138)
In Section 4.1, we have:
The following information is mandatory:
...

The instruction_type of retired instructions for:

Jumps with a target that cannot be inferred from the source code;

...
and
The following information is optional:
...

The instruction_type of instructions for:
...

Jumps with a target that cannot be inferred from the source code;

This seems contradictory (both mandatory and optional)?
—
Reply to this email directly, view it on GitHubhttps://github.com/riscv-non-isa/riscv-trace-spec/issues/138#issuecomment-2327070149, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSV4KFRG7M7M4S5F2K3ZUXW7VAVCNFSM6AAAAABNQZL5VGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRXGA3TAMJUHE.
You are receiving this because you are subscribed to this thread.Message ID<EMAIL_ADDRESS>.,.,_

Links:
You receive all messages sent to this group.
View/Reply Online (#610)https://lists.riscv.org/g/sig-debug-trace-perf-mon/message/610 | Reply To @.?subject=Re:%20Re%3A%20%5BRISC-V%5D%20%5Bsig-debug-trace-perf-mon%5D%20%5Briscv-non-isa%2Friscv-trace-spec%5D%20Small%20suggested%20clarifications%20%28Issue%20%23138%29> | Reply To @.?subject=Private:%20Re:%20Re%3A%20%5BRISC-V%5D%20%5Bsig-debug-trace-perf-mon%5D%20%5Briscv-non-isa%2Friscv-trace-spec%5D%20Small%20suggested%20clarifications%20%28Issue%20%23138%29> | Mute This Topichttps://lists.riscv.org/mt/108261477/1782486 | New Topichttps://lists.riscv.org/g/sig-debug-trace-perf-mon/post
Your Subscriptionhttps://lists.riscv.org/g/sig-debug-trace-perf-mon/editsub/1782486 | Contact Group @.> | Unsubscribehttps://lists.riscv.org/g/sig-debug-trace-perf-mon/unsub @.
.,.,_

@rsnikhil please review https://github.com/riscv-non-isa/riscv-trace-spec/pull/161 - does this address all of your concerns?

Yes, all these changes look fine to me (my apologies for my delay in reviewing).


Kibana fix

https://github.com/jorge07/symfony-5-es-cqrs-boilerplate/issues/150

right, done.

Thanks!


How can I upgrade and keep my 0.2.7 install intact?

I want to upgrade and test out 0.3 but I still need to be able to run my 0.2.7 app. How can I have both socketstreams installed?

I am using Node 0.6+, also I do not need it to run inside a current socketstream project. Following the directions...
git clone https://github.com/socketstream/socketstream.git
cd socketstream
sudo npm link
To generate a new empty SocketStream project type:
socketstream new <name_of_your_project>
This creates a 0.2.7 socketstream project and the rest fo the directions don't work. What am I doing wrong?

Hi,
Apologies for late reply (housemate interviewing, feel like a cooking judge). You've followed the instructions correctly, so you're not at fault. I'll be on the irc chat room tomorrow from 11:30am GMT to help you out. In the meantime what is the output of the following commands on your machine:
which socketstream
socketstream v

and what is the output from the "sudo npm link" command inside the socketstream directory?

So I think what is happening is socket stream 0.3 is being installed in /usr/local/bin/socketstream  and 0.2.7 is in /usr/bin/socketstream I don't want to get rid of 0.2.7 yet though so I dont want to delete that pointer.

you could write an alias in your bash config/profile file:
alias ss3="/usr/local/bin/socketstream"

That way you keep socketstream and have ss3 for the creation of new projects.


Added docstring

Closes issue number #275
Added docstring to the class and each of its methods(except the private ones)

Please check this PR @nikhil25803


Towards A Progressive Web App For Owls

Features
While the handcoded HTML that took 15 minutes is funny it's not really where we're going with this project. Also the title of this issue may be misleading. We're not developing an app for owls.

To start us down the Right Path we'll need to make a few important changes. Likely this branch will see these features:

An application framework
Navigation frames
Material design
Content cards

Content
Abandon the placeholder content that's been created thus far for some better copy that reflects a better diversity of styles and use cases.
The initial use case should be an informational website. Tracing the lineage of most companies they tend to put up a Wix/Squarespace kind of "About Our Vision" site in the beginning. We'll ape that perspective, calling owlsovernight.com a startup with little capital but a strong dream: Bringing You Owls Overnight.

Select Framework
The first question should be: is a framework the right choice? I think so. Given my low experience I see the value in using the most opinionated package out there. Once I've gotten enough experience to argue with the presented opinions I might go after a new framework, or go without it entirely.
From Google: A good definition of a Progressive Web App.

Progressive - Work for every user, regardless of browser choice because they’re built with progressive enhancement as a core tenant.
Responsive - Fit any form factor, desktop, mobile, tablet, or whatever is next.
Connectivity independent - Enhanced with service workers to work offline or on low quality networks.
App-like - Use the app shell model to provide app-style navigations and interactions.
Fresh - Always up-to-date thanks to the service worker update process.
Safe - Served via TLS to prevent snooping and ensure content hasn’t been tampered with.
Discoverable - Are identifiable as “applications” thanks to W3C manifests and service worker registration scope allowing search engines to find them.
Re-engageable - Make re-engagement easy through features like push notifications.
Installable - Allow users to “keep” apps they find most useful on their home screen without the hassle of an app store.
Linkable - Easily share via URL and not require complex installation

There's quite a bit of variety in libraries out there that support this. Some require a deep commitment to a particular tool chain, while others are more lightweight and make less assumptions. My survey lands me with some (not exclusive) choices:

React
Ember
Ionic
Polymer

The Javascript ecosystem can be both daunting and a pleasure for its scope and variety. Thanks to Google (once more) there's a good starting point in the Web Starter Kit that gives plenty of room to make your own choices while providing a solid ground. Once decision in the bag.
Looking through the major highlights of the above referenced frameworks there's one thing that really stands out in Polymer:

Developer costs
Developer costs come in the form of complexity and lock-in.
Over time, the stacks we’ve built on top of the platform have pushed web development further and further from the simplicity of view-source and shift-refresh, to a place where every project begins with an overwhelming sea of choices.
And when we rely on libraries and frameworks for even our most basic needs, we end up writing code that depends on opinionated abstractions rather than universal platform primitives. Because it’s expensive to migrate from one abstraction to another, these dependencies limit our future choices and make our code costlier to maintain.

This precisely details the struggle I'm facing currently and doesn't prevent a later refactoring for one or many of the other frameworks. It seems like a good place to start and frankly that's the only real constraint I'm facing.

An important note on progressive enhancement design from Wikipedia
PE strategy consists of the following core principles:

Basic content should be accessible to all web browsers
Basic functionality should be accessible to all web browsers
Sparse, semantic markup contains all content
Enhanced layout is provided by externally linked CSS
Enhanced behavior is provided by unobtrusive, externally linked JavaScript
End-user web browser preferences are respected

Closing the milestone for framework selection.


Enable sourcemaps in dev for both postcss and sass

This enables sourcemaps for both postcss and sass in development (just like they are enabled for css in development mode).

A year of waiting time for simple PR..

I'm going to close this in favor of https://github.com/zeit/next.js/issues/8626
Thanks for your contribution 🙏


docs: Add documentation on errors

We should describe how error codes are generated as is described here https://www.notion.so/Debugging-Custom-Anchor-Errors-b8540dd418c44a4e939ab17c56a3fd3b.
Framework errors are in the range 0-300. "Userspace" errors start at an offset of 300. So a program's first custom error code is 300. Second is 301. Etc.

Hey, it would be pretty awesome if you will be able to do it. For newcomers to Solana, this would be extremely useful !.

Docs here https://docs.rs/anchor-lang/latest/anchor_lang/__private/enum.ErrorCode.html.
We should bring that type out of the __private module though.


Update items.c

APPEND_NUM_FMT_STAT is a macro that expands to multiple statements, so it must have braces when used in a conditional.

Thanks! I changed the commit message to be more descriptive. Pushed for the next release.


IpAddr and SocketAddr are in core, but serde implements only for std

Hello, recently IpAddr was moved to core, but serde still requires std feature

Would a PR fixing this be accepted, even though it would raise MSRV significantly?

This should just affect/duplicate a few imports behind cfgs, this seems fine to me.


error message "access denied" when trying to run HWiNFO64.exe

Brief description of your issue
error message "access denied" when trying to run HWiNFO64.exe.
But I was able to run it in the past and when I copy/paste it to windows run dialog I get the UAC prompt and the application runs fine.
Steps to reproduce (optional)

start Systeminformer as admin
try to run "C:\Program Files\HWiNFO64\HWiNFO64.EXE" from System->run

Expected behavior (optional)
I can start HWiNFO
Actual behavior (optional)
I get error message "access denied"

ProcMon show no access denied only this:

HWiNFO can be started fine from ProcExp
Environment (optional)
3.0.7574
Windows 10 19045.4291 or 17763.5696 (I run Win11 only in vmware so I can't test it)

The cause of this is the driver protecting system informer. The following svchost.exe process requires excessive permissions to the protected process in order to create the process.

If I specifically craft a driver to omit that process the problem goes away:

I did some digging into their application manifest and it turns out they have uiAccess="true".
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"
    xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
    <assemblyIdentity name="HWiNFO64" processorArchitecture="amd64" version="<IP_ADDRESS>" type="win32"></assemblyIdentity>
    <description>HWiNFO64</description>
    <dependency>
        <dependentAssembly>
            <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls"
                version="<IP_ADDRESS>" processorArchitecture="amd64" publicKeyToken="6595b64144ccf1df"
                language="*"></assemblyIdentity>
        </dependentAssembly>
    </dependency>
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
            <requestedPrivileges>
                <requestedExecutionLevel level="requireAdministrator" uiAccess="true"></requestedExecutionLevel>
            </requestedPrivileges>
        </security>
    </trustInfo>
    <asmv3:application xmlns="urn:schemas-microsoft-com:asm.v3">
        <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
            <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
        </asmv3:windowsSettings>
    </asmv3:application>
    <ms_compatibility:compatibility
        xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1"
        xmlns="urn:schemas-microsoft-com:compatibility.v1">
        <ms_compatibility:application
            xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1">
            <ms_compatibility:supportedOS
                xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1"
                Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"></ms_compatibility:supportedOS>
            <ms_compatibility:supportedOS
                xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1"
                Id="{1F676C76-80E1-4239-95BB-83D0F6D0DA78}"></ms_compatibility:supportedOS>
            <ms_compatibility:supportedOS
                xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1"
                Id="{4A2F28E3-53B9-4441-BA9C-D69D4A4A6E38}"></ms_compatibility:supportedOS>
            <ms_compatibility:supportedOS
                xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1"
                Id="{35138B9A-5D96-4FBD-8E2D-A2440225F93A}"></ms_compatibility:supportedOS>
            <ms_compatibility:supportedOS
                xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1"
                Id="{E2011457-1546-43C5-A5FE-008DEEE3D3F0}"></ms_compatibility:supportedOS>
        </ms_compatibility:application>
    </ms_compatibility:compatibility>
</assembly>

The same behavior happens with osk.exe:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- Copyright (c) Microsoft Corporation -->
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
<assemblyIdentity
	version="<IP_ADDRESS>"
	processorArchitecture="*"
	name="Microsoft.windows.osk"
	type="win32"
/>
<description>OSK</description>
<dependency>
   <dependentAssembly>
      <assemblyIdentity
           type="win32"
           name="Microsoft.Windows.Common-Controls"
           version="<IP_ADDRESS>"
           processorArchitecture="*"
           publicKeyToken="6595b64144ccf1df"
	         language="*"
      />
   </dependentAssembly>
</dependency>
<asmv3:application>
    <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
        <dpiAware>true</dpiAware>
    </asmv3:windowsSettings>
</asmv3:application>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
  <security>
    <requestedPrivileges>
      <requestedExecutionLevel level="asInvoker" uiAccess="true"/>
    </requestedPrivileges>
  </security>
</trustInfo>
</assembly>

I am not going to fix this in the driver. The protections are working as intended. Maybe we could come up with a way to invoke ShellExecuteEx from another System Informer process that isn't being actively protected.

ok, this also happens with Microsoft Windows Performance Recorder UI (WPRUI.exe), it also has uiAccess="true" set in the manifest.

@MagicAndre1981 - This issue started with HWiNFO v7.73-5370 which is mentioned here due to the new OSD feature: https://www.hwinfo.com/forum/threads/hwinfo-v7-73-5370-beta-released.9513/
and in the following thread:
https://www.hwinfo.com/forum/threads/hwinfo-v7-73-5380-beta-released.9537/
The OSD feature is mentioned here:
https://www.hwinfo.com/forum/threads/hwinfo-osd.9495/
What you need to do is per Microsoft as seen here and confirmed by HWiNFO's author:
https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations
This policy setting enforces the requirement that apps that request running with a UIAccess integrity level by marking UIAccess=true in their app manifest must reside in a secure location on the file system. Relatively secure locations are limited to the following directories:
C:\Program Files\ including subdirectories
C:\Windows\system32
C:\Program Files (x86)\ including subdirectories for 64-bit versions of Windows
Even the autostart feature did not work until the fix was when autostart is enabled, it would create a HWiNFO64Launcher.exe file which would open HWiNFO64.exe.  When autostart is disabled, it would delete HWiNFO64Launcher.exe.
I am currently running HWiNFO64.exe v8.01-5420 under systeminformer-3.0.7578-canary:

@jxy-s - When you said "The workaround for now, if you want to invoke a uiAccess="true" process via the Run dialog in System Informer - do it when the driver isn't active." - Do you mean using System -> Run as... and then checking the "Create UIAccess" box? Thanks!

Problem is that applications with uiAccess=true cannot be started via CreateProcess (or similar) but require ShellExecute. That's why HWiNFO64 is now using a HWiNFO64Launcher.exe to start from TaskScheduler.

The issue is launching the HWiINFO via the System Informer System > Run... (which uses ShellExecuteEx) with the driver enabled System > Options > Enable kernel-mode driver. The issue only presents itself when the driver is enabled since we strip handle permission from the appinfo.dll svchost.exe process. Without the driver enabled there is no issue.
The workaround then is to disable and unload the driver System > Options > Enable kernel-mode driver and stop the KSystemInformer service.

@jxy-s - I am on Windows 11 Beta Insiders and my System > Options > Enable kernel-mode driver has always been unchecked and I don't have the KSystemInformer service running but I still have the same problem as the OP.

Oh sorry, I missed this line:

I just tried restarting the HWiNFO64.exe process in SI and it seems like the process gets killed but does not start the process.

To confirm, you mean right clicking the HWiNFO64.EXE process and choosing "Restart"? Or do you mean starting a second instance of HWiNFO64.EXE?
Few observations on my end:

Choosing "Restart" for HWiNFO64.EXE works for me with or without the driver enabled. The process exists and the new process takes its place. Looks to succeed here and not take the ShellExecuteEx path:
https://github.com/winsiderss/systeminformer/blob/ff4fc005c3f7ecf8b7df5fcdc6e52db13ea1359c/SystemInformer/actions.c#L2426-L2437
Starting another instance of HWiNFO64.EXE. The program seems to detect that another instance is running and exits. Same behavior as if you were to start it any other way.

I meant right clicking the HWiNFO64.EXE process and choosing "Restart".
It seems to start correctly this time but didn't when I wrote my earlier reply here:
https://github.com/winsiderss/systeminformer/issues/2037#issuecomment-2073495523


📝 add progress documentation

can you fix the background of the progress bar ?

I tried but I can't seem to figure out why it's not changing in the "dynamic colors" example

You need to create another styled component styled.progress with a prop background to be effective


Addition of bebi.com and *.adnow.com

bebi.com and ads1.adnow.com, ads2.adnow.com and ads3.adnow.com seems to be clickbaity and are also blocked by Easylist.

Sorry I didn't see your suggestion earlier! I had not configured my GitHub notifications correctly.
Do you have a link to a website that uses bebi.com or adnow.com ads? I'd like to check out the ads and make sure I'm deleting the right servers.


KAFKA-14008: Add docs for Streams metrics introduced in KIP-846

Related JIRA ticket - https://issues.apache.org/jira/browse/KAFKA-14008
Related KIP - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=211886093

Thanks for the PR! Merged to trunk.

Also cherry-picked to 3.3 branch.


Token icons not exchangeable or by default taken from a website like bscscan, ethscan or similar

Description
The current coin/token icons are usually standardized and just a few projects have their logo visible in Metamask. In case a new project wants to add it´s own logo to the Metamask wallet, so all of it´s users can see it and make it more attractive to hold, what is necessary to do? There is a basic advise about how to add it on Ethereum but how would it work on Binances Smart Chain or any others? I´m talking especially about the wallet in it´s browser extention form and the process of changing it should be easy to do even for non-tech founders. e.g. BScscan has an online formular where you can send your info and they update it, but that´s a manual process, so an automated one would be fantastic. The tokens new logo must be visible for all users, not just as a local solution.
Technical Details
Add the possibility to change a projects logo for the tokens owner, maybe with an email authentification process that includes the projects webdomain and some details on their website, like a pixel that needs to be checked, like Facebook does, just for a different purpose. Also a check with the contract owners wallet address to make him the single person to change the logo might be a solution. Since this request is written by a non-dev please just consider all options that aren´t even mentioned here.
Acceptance Criteria
Actually no criteria beside the authenticity check mentioned above ,so not everybody can change an icon at will for all to see.
Scenario:
Given a new project launched it´s token and is now on the process of an airdriop or raising money via an IDO. The project wants to look as professional as possible, so website, team, whitepaper and so on all add up. As for their token, they want to add their icon to the Metamask extention so all possibly interested buyers can spot the token very easily and have a visual confirmation that they buy the right thing. That beside the contracts address certainly. So when a User wants to invest in the project he gets the contract address, e.g. goes to Pancakeswap, and gets a visual confirmation that he has the right token when the logo of said token pops up in his metamask wallet.
References
Bscscan - https://bscscan.com/token/0xa4a94dcf0dc96f7B51d5b099EfE10BDf150ffDBe
Logo shown beside the tokens name, but added manually via first me confirming ownership
An automated way would be better though

Transferred to our contract-metadata repo.  Please review https://github.com/MetaMask/contract-metadata#submission-process
@Cryopracticer


Added the multilanguage support#9

Fixed issue #9

Please try resolving the conflicts and update your PR.


Apache mod_aliased asset files are reporting not found

If I have my asset files outside of the site's webroot, reference via mod_alias, munee throws a NotFoundException as it can't find the file due to file_exists referencing the wrong webroot.
Is there an option to have munee load the files by using the existing rewrite rules, eg a curl loopback would return the file based on an alias (though there might be an infinite loop with munee...)

I'm in agreement with @rubenvincenten.  @xiphiaz please reopen if you are still having issues.


Attach failure

docker attach does not work as expected when used with boot2docker. See dotcloud/docker#3693.
However, it works fine with a 'regular' distro.

Current version (cli v1.4.1), with DOCKER_HOST="tcp://<IP_ADDRESS>:2376", still no response on docker attach. An earlier comment alludes that using IP export with 0.11.1 will work, but I still get the issue on 1.4.1.

In fact,
$ boot2docker ssh
docker@boot2docker:~$ docker attach insane_mccarthy
# no response

Is this expected/the same issue?

Just to chime in that docker exec -it my-container bash is what works for me. Thanks @joallard!


Enhancements to Logging, Help Messages, and PR Description Generation

Type
Enhancement

Description
This PR introduces several enhancements to the PR-Agent:

The logging level for several messages in git_provider.py has been changed from debug to info, making these messages more visible in the logs.
The help messages in help.py have been significantly expanded and restructured. They are now organized into a HelpMessage class with several static methods, each returning a different part of the help message.
The PRDescription and PRReviewer classes have been updated to include help text in the generated PR description and review, respectively, if the gfm_markdown feature is supported and the enable_help_text configuration option is set.
Several typos have been fixed in the documentation files DESCRIBE.md, IMPROVE.md, and REVIEW.md, and some sentences have been rephrased for clarity.
A new configuration option enable_help_text has been added to the pr_description section in configuration.toml. This option controls whether help text should be included in the generated PR description.

Changes walkthrough
Relevant files                                                                                Logging

git_provider.py

        pr_agent/git_providers/git_provider.py
The logging level for several messages has been changed from debug to info. This will make these messages more visible in the logs.

 +4/-4

Documentation

help.py

        pr_agent/servers/help.py
The help messages have been significantly expanded and restructured. They are now organized into a HelpMessage class with several static methods, each returning a different part of the help message. This includes general commands, usage guides for the review and describe commands, and more.

 +174/-8

DESCRIBE.md

        docs/DESCRIBE.md
A typo has been fixed and a newline has been added at the end of the file.

 +2/-2

IMPROVE.md

        docs/IMPROVE.md
A typo has been fixed in the example extra instructions.

 +1/-1

REVIEW.md

        docs/REVIEW.md
Several typos have been fixed and some sentences have been rephrased for clarity.

 +3/-3

Enhancement

pr_description.py

        pr_agent/tools/pr_description.py
The PRDescription class has been updated to include help text in the generated PR description, if the gfm_markdown feature is supported and the enable_help_text configuration option is set. The help text is retrieved from the HelpMessage class.

 +9/-0

pr_reviewer.py

        pr_agent/tools/pr_reviewer.py
The PRReviewer class has been updated to include help text in the generated PR review, if the gfm_markdown feature is supported and the enable_help_text configuration option is set. The help text is retrieved from the HelpMessage class.

 +3/-8

Configuration changes

configuration.toml

        pr_agent/settings/configuration.toml
A new configuration option enable_help_text has been added to the pr_description section. This option controls whether help text should be included in the generated PR description.

 +1/-0

 ✨ Usage guide:
Overview:
The describe tool scans the PR code changes, and generates a description for the PR - title, type, summary, walkthrough and labels. The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on a PR.
When commenting, to edit configurations related to the describe tool (pr_description section), use the following template:
/describe --pr_description.some_config1=... --pr_description.some_config2=...

With a configuration file, use the following template:
[pr_description]
some_config1=...
some_config2=...

  Enabling\disabling automation

When you first install the app, the default mode for the describe tool is:

pr_commands = ["/describe --pr_description.add_original_user_description=true"
                         "--pr_description.keep_original_user_title=true", ...]

meaning the describe tool will run automatically on every PR, will keep the original title, and will add the original user description above the generated description.

Markers are an alternative way to control the generated description, to give maximal control to the user. If you set:

pr_commands = ["/describe --pr_description.use_description_markers=true", ...]

the tool will replace every marker of the form pr_agent:marker_name in the PR description with the relevant content, where marker_name is one of the following:

type: the PR type.
summary: the PR summary.
walkthrough: the PR walkthrough.

Note that when markers are enabled, if the original PR description does not contain any markers, the tool will not alter the description at all.

  Custom labels
The default labels of the describe tool are quite generic: [Bug fix, Tests, Enhancement, Documentation, Other].
If you specify custom labels in the repo's labels page or via configuration file, you can get tailored labels for your use cases.
Examples for custom labels:

Main topic:performance - pr_agent:The main topic of this PR is performance
New endpoint - pr_agent:A new endpoint was added in this PR
SQL query - pr_agent:A new SQL query was added in this PR
Dockerfile changes - pr_agent:The PR contains changes in the Dockerfile
...

The list above is eclectic, and aims to give an idea of different possibilities. Define custom labels that are relevant for your repo and use cases.
Note that Labels are not mutually exclusive, so you can add multiple label categories.
Make sure to provide proper title, and a detailed and well-phrased description for each label, so the tool will know when to suggest it.

  More PR-Agent commands

To invoke the PR-Agent, add a comment using one of the following commands:

/review: Request a review of your Pull Request.
/describe: Update the PR title and description based on the contents of the PR.
/improve [--extended]: Suggest code improvements. Extended mode provides a higher quality feedback.
/ask <QUESTION>: Ask a question about the PR.
/update_changelog: Update the changelog based on the PR's contents.
/add_docs 💎: Generate docstring for new components introduced in the PR.
/generate_labels 💎: Generate labels for the PR based on the PR's contents.
/analyze 💎: Automatically analyzes the PR, and presents changes walkthrough for each component.

See the tools guide for more details.
To list the possible configuration parameters, add a /config comment.

See the describe usage page for a comprehensive guide on using this tool.

Preparing review...

Persistent review updated to latest commit https://github.com/Codium-ai/pr-agent/commit/9cfb8ce4758798a9405f72294b3ec923c137498a

Preparing PR description...

PR Description updated to latest commit (https://github.com/Codium-ai/pr-agent/commit/9cfb8ce4758798a9405f72294b3ec923c137498a)

Preparing PR description...

PR Description updated to latest commit (https://github.com/Codium-ai/pr-agent/commit/8bb2eb48af5408a3c942ddb16a6bd74a715afce6)

Preparing PR description...

PR Description updated to latest commit (https://github.com/Codium-ai/pr-agent/commit/8bb2eb48af5408a3c942ddb16a6bd74a715afce6)

Preparing PR description...

PR Description updated to latest commit (https://github.com/Codium-ai/pr-agent/commit/8bb2eb48af5408a3c942ddb16a6bd74a715afce6)

Preparing PR description...

Preparing PR description...

PR Description updated to latest commit (https://github.com/Codium-ai/pr-agent/commit/8bb2eb48af5408a3c942ddb16a6bd74a715afce6)

Preparing PR description...

PR Description updated to latest commit (https://github.com/Codium-ai/pr-agent/commit/8bb2eb48af5408a3c942ddb16a6bd74a715afce6)

Preparing PR description...

PR Description updated to latest commit (https://github.com/Codium-ai/pr-agent/commit/8bb2eb48af5408a3c942ddb16a6bd74a715afce6)

Preparing PR description...

PR Description updated to latest commit (https://github.com/Codium-ai/pr-agent/commit/8bb2eb48af5408a3c942ddb16a6bd74a715afce6)

Preparing PR description...

Preparing suggestions...

PR Code Suggestions
💡 [best practice]
Consider using a docstring for each method in the HelpMessage class to describe what each method does. This will improve the readability and maintainability of your code.
File: pr_agent/servers/help.py (1-7)
  Example code:

Existing code:
class HelpMessage:
    @staticmethod
    def get_general_commands_text():
        commands_text = "> - **/review**: Request a review of your Pull Request.   \n" \
                        "> - **/describe**: Update the PR title and description based on the contents of the PR.   \n" \
                        "> - **/improve [--extended]**: Suggest code improvements. Extended mode provides a higher quality feedback.   \n" \
                        "> - **/ask \\<QUESTION\\>**: Ask a question about the PR.   \n" \
        return commands_text

Improved code:
class HelpMessage:
    @staticmethod
    def get_general_commands_text():
        """
        Returns a string containing the general commands text.
        """
        commands_text = "> - **/review**: Request a review of your Pull Request.   \n" \
                        "> - **/describe**: Update the PR title and description based on the contents of the PR.   \n" \
                        "> - **/improve [--extended]**: Suggest code improvements. Extended mode provides a higher quality feedback.   \n" \
                        "> - **/ask \\<QUESTION\\>**: Ask a question about the PR.   \n" \
        return commands_text

💡 [enhancement]
Consider using a more descriptive logging message in the get_user_description method. This will make it easier to understand the context when reading the logs.
File: pr_agent/git_providers/git_provider.py (78-78)
  Example code:

Existing code:
get_logger().info(f"Existing description:\n{description_lowercase}")

Improved code:
get_logger().info(f"Existing PR description:\n{description_lowercase}")

💡 [best practice]
Consider removing the unused import from pr_agent.servers.help import HelpMessage. This will improve the readability and maintainability of your code.
File: pr_agent/tools/pr_reviewer.py (20-20)
  Example code:

Existing code:
from pr_agent.servers.help import HelpMessage

Improved code:
# Removed unused import

💡 [best practice]
Consider adding a space after the comma in the tuple assignment pr_title, pr_body,  = self._prepare_pr_answer(). This will improve the readability of your code.
File: pr_agent/tools/pr_description.py (101-101)
  Example code:

Existing code:
pr_title, pr_body,  = self._prepare_pr_answer()

Improved code:
pr_title, pr_body = self._prepare_pr_answer()

Preparing suggestions...

PR Code Suggestions
💡 [readability]
Consider using a multi-line string for the commands_text in the get_general_commands_text method to improve readability.
File: pr_agent/servers/help.py (4-7)
  Example code:

Existing code:
commands_text = "> - **/review**: Request a review of your Pull Request.   \n" \
                "> - **/describe**: Update the PR title and description based on the contents of the PR.   \n" \
                "> - **/improve [--extended]**: Suggest code improvements. Extended mode provides a higher quality feedback.   \n" \
                "> - **/ask \\<QUESTION\\>**: Ask a question about the PR.   \n"

Improved code:
commands_text = """
> - **/review**: Request a review of your Pull Request.
> - **/describe**: Update the PR title and description based on the contents of the PR.
> - **/improve [--extended]**: Suggest code improvements. Extended mode provides a higher quality feedback.
> - **/ask \\<QUESTION\\>**: Ask a question about the PR.
"""

💡 [best practice]
Consider changing the log level from info to debug in the get_user_description method. This information seems more relevant for debugging purposes rather than regular operation information.
File: pr_agent/git_providers/git_provider.py (78-112)
  Example code:

Existing code:
get_logger().info(f"Existing description:\n{description_lowercase}")
...
get_logger().info(f"Existing description was not generated by the pr-agent")
...
get_logger().info(f"Existing description was generated by the pr-agent, but it doesn't contain a user description")
...
get_logger().info(f"Extracted user description from existing description:\n{original_user_description}")

Improved code:
get_logger().debug(f"Existing description:\n{description_lowercase}")
...
get_logger().debug(f"Existing description was not generated by the pr-agent")
...
get_logger().debug(f"Existing description was generated by the pr-agent, but it doesn't contain a user description")
...
get_logger().debug(f"Extracted user description from existing description:\n{original_user_description}")

💡 [readability]
Consider using a multi-line string for the markdown_text in the _prepare_pr_review method to improve readability.
File: pr_agent/tools/pr_reviewer.py (255-257)
  Example code:

Existing code:
markdown_text += "
\n\n ✨ Usage guide:
 \n\n"
markdown_text += HelpMessage.get_review_usage_guide()
markdown_text += "\n\n"

Improved code:
markdown_text += """

  ✨ Usage guide:

  {HelpMessage.get_review_usage_guide()}

"""

💡 [readability]
Consider using a multi-line string for the pr_body in the run method to improve readability.
File: pr_agent/tools/pr_description.py (105-107)
  Example code:

Existing code:
pr_body += "
\n\n ✨ Usage guide:
 \n\n"
pr_body += HelpMessage.get_describe_usage_guide()
pr_body += "\n\n"

Improved code:
pr_body += """

  ✨ Usage guide:

  {HelpMessage.get_describe_usage_guide()}

"""


Newer SDK for Azure Search should be used in retry guidance

This page on retry guidance has a sections for Azure search where the latest SDK is not used.
The package Microsoft.Azure.Search is being used instead of the newer Azure.Search.Documents.
Either replace the current content with that for the newer packageor ensure both new and older packages are covered.
If we are covering both, then do emphasize that we recommend the use of the newer one

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

ID: 8194899c-dee2-70ac-422a-edc06e779f7c
Version Independent ID: cafc7418-404c-5908-3037-dba7f452087b
Content: Retry guidance for Azure services - Best practices for cloud applications
Content Source: docs/best-practices/retry-service-specific.md
Service: architecture-center
Sub-service: best-practice
GitHub Login: @dragon119
Microsoft Alias: pnp

Thanks for reporting - this issue is under review. This is a Microsoft Internal DevOps Bug ID # 488383

#please-close


update for #2857 workaround

update for #2857 workaround

Coverage remained the same at 59.279% when pulling 58d8a145c30e117218edef6363f1c48d84004dce on pmelse:pmelse-workaround-#2857 into a65c4c94a0d7cb921eb410b4771b5daf5605b50d on Netflix:master.


[ChannelTabs] Request: hotkey for New Tab

Is your feature request related to a problem? Please describe.
There are hotkeys for Close Tab, Next Tab and Previous Tab but not for New Tab. I love using hotkeys so I really miss one for New Tab.
Describe the solution you'd like
Ctrl+t is normally the hotkey for new tab, any other hotkey would also be fine. Configurable is obviously best but I can just customize it myself using AHK anyway so I don't really mind.
Describe alternatives you've considered
It can't be done atm.
Additional context
Hotkeys are amazing.

Any chance to get an update on this?


READ_WRITE_ROUTING_URL is missing description

READ_WRITE_ROUTING_URL is documented in syntax part, but it does not have discription nor link to following Docs.
Secondary to primary replica read/write connection redirection (Always On Availability Groups)
https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/secondary-replica-connection-redirection-always-on-availability-groups?view=sql-server-ver15

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

Reviewing.

@MikeRayMSFT Is the PR ready to merge? Thanks.

@MikeRayMSFT It looks like Kevin approved these changes. Can you take on last look at the content/formatting and then sign off? Thanks!

#sign-off


Update README PHP setup with Xdebug

I went through the steps of installing xdebug and vdebug to debug my php setup and I couldn't, for the life of me get a debugger session working. I was getting the same error log over and over again:
[60807] Log opened at 2022-10-20 12:14:47.026666
[60807] [Step Debug] DEBUG: Found 'XDEBUG_CONFIG' ENV variable
[60807] [Step Debug] INFO: Connecting to configured address/port: <IP_ADDRESS>:9000.
[60807] [Step Debug] INFO: Connected to debugging client: <IP_ADDRESS>:9000 (through xdebug.client_host/xdebug.client_port). :-)
[60807] [Step Debug] -> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="{some_file_path}" language="PHP" xdebug:language_version="8.1.10" protocol_version="1.0" appid="60807" idekey="xdebug"><engine version="3.1.5"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2022 by Derick Rethans]]></copyright></init>

[60807] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" status="stopping" reason="ok"></response>

[60807] [Step Debug] WARN: 2022-10-20 12:14:47.028073: There was a problem sending 179 bytes on socket 6: Broken pipe.
[60807] Log closed at 2022-10-20 12:14:47.028225

There were 2 reasons:

The VdebugSetupPHP section includes a helper script to start a debugging session:

#!/bin/bash
export XDEBUG_CONFIG="idekey=xdebug"
/usr/bin/php "$@"

howerver, the xdebug docs also state that XDEBUG_SESSION=1 should be set, otherwise the debug session doesn't seem to start. So the php-xdebug script should be:
#!/bin/bash
export XDEBUG_SESSION=1
export XDEBUG_CONFIG="idekey=xdebug" # found out that this is not really needed
/usr/bin/php "$@"

The VdebugSetupPHP section says that we should set our host_port to 9000, but as stated here  (I honestly don't understand the why, yet) that is wrong, and should be on a port different than 9000 (like 9003, the default xdebug port) and in the .vimrc we'd need to add the following lines:

let g:vdebug_options = {}
let g:vdebug_options["port"] = 9003 # same as port defined for xdebug

now, starting a debug session with php-xdebug works as expected :)

These are changes from xdebug 2 to 3, and the instructions haven't been updated yet.


[CARBONDATA-2127] Documentation for Hive Standard Partition

Documentation for Hive Standard Partition

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

LGTM


GPU accelerated viz library?

I would like to include a good GPU accelerated viz package in the environment. DataShader looks to be a good candidate as they will be supporting RAPIDS within the next year (or so).
I wonder if I should go ahead and add DataShader now?

NVIDIA GPU support is now in Datashader (version 0.9.0); see https://github.com/holoviz/datashader/pull/793 .


DBZ-257 Support for different logical decoding plugins

Superseded with https://github.com/debezium/debezium/pull/290


Export token precedence map. Fixes #11.

@corywalker PTAL, thanks.

@corywalker Thanks. Oops, I merged the branch by mistake instead of the PR. I hope the results are the same.


The DFP can not work with upstream pyocd

Install pyocd as pip install pyocd
build a demo project with gnu gcc toolchain
create a 'pyocd.yaml' as:

pack:
  - Synwit.SWM32_DFP.1.20.4.pack

run pyocd list --targets, it will find the swm series MCU:

  swm181xb                  Synwit                  SWM181xB                     SWM181 Series   pack
  swm181xc                  Synwit                  SWM181xC                     SWM181 Series   pack
  swm190xb                  Synwit                  SWM190xB                     SWM190 Series   pack
  swm201x6                  Synwit                  SWM201x6                     SWM201 Series   pack
  swm211x8                  Synwit                  SWM211x8                     SWM211 Series   pack
  swm220x6                  Synwit                  SWM220x6                     SWM220 Series   pack
  swm220x8                  Synwit                  SWM220x8                     SWM220 Series   pack
  swm260xb                  Synwit                  SWM260xB                     SWM260 Series   pack
  swm320xc                  Synwit                  SWM320xC                     SWM320 Series   pack
  swm320xe                  Synwit                  SWM320xE                     SWM320 Series   pack
  swm341xe                  Synwit                  SWM341xE                     SWM341 Series   pack

try to erase pyocd erase -c -t swm181xb --config pyocd.yaml, the error output:

pyocd erase -c -t swm181xb --config pyocd.yaml
0000566 I Erasing chip... [eraser]
0006284 C flash uninit timed out [__main__]
Traceback (most recent call last):
  File "/home/cjacker/.local/lib/python3.10/site-packages/pyocd/__main__.py", line 161, in run
    status = cmd.invoke()
  File "/home/cjacker/.local/lib/python3.10/site-packages/pyocd/subcommands/erase_cmd.py", line 97, in invoke
    eraser.erase(addresses)
  File "/home/cjacker/.local/lib/python3.10/site-packages/pyocd/flash/eraser.py", line 79, in erase
    self._chip_erase()
  File "/home/cjacker/.local/lib/python3.10/site-packages/pyocd/flash/eraser.py", line 101, in _chip_erase
    region.flash.cleanup()
  File "/home/cjacker/.local/lib/python3.10/site-packages/pyocd/flash/flash.py", line 272, in cleanup
    self.uninit()
  File "/home/cjacker/.local/lib/python3.10/site-packages/pyocd/flash/flash.py", line 298, in uninit
    raise FlashFailure('flash uninit timed out')
pyocd.core.exceptions.FlashFailure: flash uninit timed out
make: *** [Makefile:161：program] 错误 1

Without support for OpenOCD or pyOCD, debugging is impossible from linux command line.
Please consider to add SWM MCUs support to OpenOCD, or make DFP work with upstream pyOCD.

You can download with SWMProg, and then debug with pyOCD.


Add plugins option line to zshrc during installation

Vero will read from the line:
VERO_PLUGINS=()
This should be set up with defaults during installation

This is being abandoned in favor of a simpler theme


Update New-CsAutoAttendantCallHandlingAssociation.md

I have added all week days to the "Business Hours" examples (1 and 2).

Docs Build status updates of commit 4a104e6:
:clock10: Full build: the average full build time is 14 min(s) 16 sec(s), this is based on the last 279 build(s) for this repository.

https://github.com/MicrosoftDocs/office-docs-powershell/issues/3437

Docs Build status updates of commit 4a104e6:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

skype/skype-ps/skype/New-CsAutoAttendantCallHandlingAssociation.md
:white_check_mark:Succeeded
View (skype-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 498c5ac:
:clock10: Full build: the average full build time is 14 min(s) 16 sec(s), this is based on the last 280 build(s) for this repository.

Docs Build status updates of commit 498c5ac:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

skype/skype-ps/skype/New-CsAutoAttendantCallHandlingAssociation.md
:white_check_mark:Succeeded
View (skype-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 380263c:
:clock10: Full build: the average full build time is 14 min(s) 17 sec(s), this is based on the last 284 build(s) for this repository.

Docs Build status updates of commit 380263c:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

skype/skype-ps/skype/New-CsAutoAttendantCallHandlingAssociation.md
:white_check_mark:Succeeded
View (skype-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


\Ramsey\Uuid\Uuid::uuid4() does not return an instance implementing Ramsey\Uuid\Rfc4122\UuidInterface as per the docs

The getting started guide says the following:
When using Ramsey\Uuid\Uuid::uuid4() it:

will return an instance of Ramsey\Uuid\Rfc4122\UuidV4.

However it does not.
var_dump(\Ramsey\Uuid\Uuid::uuid4() instanceof \Ramsey\Uuid\Rfc4122\UuidV4); // false

This is on current latest: 4.1.1

Please see the discussion on #327. This is a known issue that might be considered a documentation error, rather than a bug in the code. I'm still trying to decide what to do here.


Add switch to disable unique_id

Problem
During tests in CI there is no way to create app without support for UniqueId . Such application is required to perform TC-MCORE-FS-1.3 test.
Changes
I've addes support for option data-model-no-unique-id during build of apps.
Testing

Build chip-tool and lightapp

./scripts/build/build_examples.py \
    --target linux-x64-light-data-model-no-unique-id-no-wifi \
    --target linux-x64-chip-tool \
    build

Start lightapp and chip-tool

./out/linux-x64-chip-tool/chip-tool interactive start
./out/linux-x64-light-no-unique-id-no-wifi/chip-lighting-app

Execute commands in chip-tool

pairing onnetwork 1 20202021
basicinformation read unique-id 1 0

Exptected output with UniqueId disabled:
[1724666684.106] [68952:68954] [TOO] Response Failure: IM Error 0x00000586: General error: 0x86 (UNSUPPORTED_ATTRIBUTE)
[1724666684.106] [68952:68954] [TOO] Run command failure: IM Error 0x00000586: General error: 0x86 (UNSUPPORTED_ATTRIBUTE)

@tehampson for my email filters to give me updates on this PR

Looks good, but we need to fix scripts/tools/zap/update_cluster_revisions.py to not update the ZAP file or this app, in a separate PR.

Tracking with: https://github.com/project-chip/connectedhomeip/issues/35334