text:
how to debug main thread or node code?

how to debug main thread or node code?
i set
"start-hot": "cross-env HOT=1 NODE_ENV=development electron --debug-brk=5858  -r babel-register -r babel-polyfill ./main.development",

but it does`t work ?
how can i do?

Use the developer tools.

@amilajack  but the main.js file? how to debug?

At the moment I'm not sure how to do this. We should make this a high priority.

From what I've found, you need to setup an external debugger.

I can't figure this out either

Electron has a number of shortcomings when it comes to development experience. For me, two major issues are the developer tools not having fully-working integration (specifically the debugger) and the lack of tooling/discussion on debugging the main thread. But I think that eventually the community will provide idiomatic ways or built-in support for these issues. But at the moment, current solutions seem super tacky.

Setting up debugging for the main.js file is honestly more work than debugging blind. It's truly ridiculous. Wasted 6 hours and still couldn't get the debugging up. A solution would be great, but I'm sure it will not come easy.

Lets merge this into https://github.com/chentsulin/electron-react-boilerplate/issues/379

Yea i have spent numerous hours trying to get this to work too @Slapbox :/

@aj-ptw Your best bet it to just use console.log() statements as much as possible and refer to your terminal for the output.
Unless it's formally integrated into the boilerplate, I've just come to terms with the fact that I'm going to have to live without it.

Unless it's formally integrated into the boilerplate, I've just come to terms with the fact that I'm going to have to live without it.

A fix for this is being worked on at the moment.

@amilajack that will be awesome. I'm looking forward to it. Thanks as always for all your hard work.

@amilajack any update about this feature ?

so many console.log() hahah

@ritz078 sorry for the delay on this. I've been looking into this for a while because its something I'm really excited for. I'll look into this over winter break

@amilajack happy to look too, just have not been given much to work with but if you're able to get a PR with what your thinking I'm glad to jump in. I really really need this haha

Guys I think this and hot reloading main process are the biggest bottleneck for developing project in this boilerplate. It turns out to be very irritating while development 😭

@ritz078 would be great if you or anyone else could PR for this. At the moment, I dont have much time. But expect a PR for this from me during late december or early january if one hasnt been made already.

I got Webstorm's debugger working by removing webpack-specific features from the background process files and running main.dev.js directly with electron / node.
The features I lost:

ES6 module syntax, have to use require()
FlowType
async/await (should be here pretty soon though)

All other ES6/ES7 features I'd use babel for seem already covered by node, so the tradeoff was worth it for me. The best part is, I can still use babel to build the optimized production version.
This is the setup:

I start this configuration from Webstorm (with or without debugger), then run npm run hot-updates-server from a terminal. I can restart the main process freely as I make changes, or put it on nodemon, whatever.
IMO this is a good option for people who need to do a lot of development in the background process, or don't care about FlowType.

@panta82, very cool. Thanks for sharing

Thanks @panta82! I got debug running on PhpStorm (is Webstorm) via your method.
For others attempting the same, I have made a branch on a fork that shows what I changed (not a lot):  https://github.com/chentsulin/electron-react-boilerplate/compare/master...DaanBroekhof:debug-main-process
In the current master, starting the renderer process is now npm run start-renderer-dev instead of hot-updates-server.

I DONT CARE ABOUT FLOW TYPE AND DO A LOT OF DEVELOPMENT ON BACKGROUBD PROCESSES AND I USE WEBSTORM
Holllaaa thanks!!

I know this is a super old issue, but in case anyone stumbles here by way of Google: electron added main process debugging a while back. Practically, the way to debug the main process is to add --inspect=5858 to start-main-dev in package.json. Since this was solved upstream, this issue can probably be closed.

Thanks @panta82! I got debug running on PhpStorm (is Webstorm) via your method.
For others attempting the same, I have made a branch on a fork that shows what I changed (not a lot): master...DaanBroekhof:debug-main-process
In the current master, starting the renderer process is now npm run start-renderer-dev instead of hot-updates-server.

It's working by your method, do you know why need change the "import.. from..." to require() but original project don't need the change?

I really don't think this should be closed as all that is being debugged is the renderer process, as opposed to Main and Renderer.
This works to debug the main
"start-main-dev": "cross-env HOT=1 NODE_ENV=development electron $NODE_DEBUG_OPTION -r @babel/register ./app/main.dev.js",
The renderer process though is still not picking up on debugging even after
"start-renderer-dev": "cross-env NODE_ENV=development webpack-dev-server $NODE_DEBUG_OPTION --config configs/webpack.config.renderer.dev.babel.js",

I had to browse through several posts (not only #428 and #528) until it worked for me with the current version, so here is a setup which worked in VS Code, at least with the current master (63cebabb467400c910acf51fa7a0b9285b7bff22)
In package.json add extra script:
"start-main-debug": "yarn start-main-dev --inspect=5858 --remote-debugging-port=9223"
In launch.json:
{
  "version": "0.2.0",
  "configurations": [
      {
          "type": "node",
          "request": "launch",
          "name": "Electron: Main",
          "protocol": "inspector",
          "runtimeExecutable": "yarn",
          "runtimeArgs": [
              "start-main-debug"
          ],
          "preLaunchTask": "Start Webpack Dev"
      },
      {
        "name": "Electron: Renderer",
        "type": "chrome",
        "request": "attach",
        "port": 9223,
        "webRoot": "${workspaceFolder}",
        "timeout": 15000
      }
  ],
  "compounds": [
      {
          "name": "Electron: All",
          "configurations": [
              "Electron: Main",
              "Electron: Renderer"
          ]
      }
  ]
}

In targets.json:
{
  "version": "2.0.0",
  "tasks": [
    {
      "type": "npm",
      "label": "Start Webpack Dev",
      "script": "start-renderer-dev",
      "options": {
        "cwd": "${workspaceFolder}"
      },
      "isBackground": true,
      "problemMatcher": {
        "owner": "custom",
        "pattern": {
          "regexp": "____________"
        },
        "background": {
          "activeOnStart": true,
          "beginsPattern": "Compiling\\.\\.\\.$",
          "endsPattern": "(Compiled successfully|Failed to compile)\\.$"
        }
      }
    }
  ]
}

What @Do-do-new  said works for me, only if  I changed

targets.json

to

tasks.json

Awesome! Thank you!

Anybody have an idea on how to do this with Webstorm?

Webstorm hardly ever gets any love because it's paid.
I think it would be worth it at this point for JetBrains to slow vscode run settings be consumable by their IDE.

Anybody have an idea on how to do this with Webstorm?

Webstorm hardly ever gets any love because it's paid.
I think it would be worth it at this point for JetBrains to have vscode run settings be consumable by their IDE.

It's true. What a fantastic idea!

Has anybody figured out how to connect it to the renderer? I used @Do-do-new file configuration, but it only working for the main process and not the renderer.

Has anybody figured out how to connect it to the renderer? I used @Do-do-new file configuration, but it only working for the main process and not the renderer.

Are you using compound configuration (Electron: All) when starting? Okay, it is a stupid question, but anyway.
If yes, have you also tried debugging renderer-only?

Has anybody figured out how to connect it to the renderer? I used @Do-do-new file configuration, but it only working for the main process and not the renderer.

@ethanbonin
Are you using compound configuration (Electron: All) when starting? Okay, it is a stupid question, but anyway.
If yes, have you also tried debugging renderer-only?
P.S. I will check the possibility to do it with Webstorm, even though it is in general not free, but it offers better refactoring support (at least, in my experience) and there is also EAP (early access program)

@Do-do-new, yes. I have tried Electron-All. I actually have tried the single Electron-Renderer by itself. .
But just looking at the configuration. It’s just attaching itself to the chrome. So I don’t know how that would help without starting the electron app. 😳

@Do-do-new, yes. I have tried Electron-All. I actually have tried the single Electron-Renderer by itself. .
But just looking at the configuration. It’s just attaching itself to the chrome. So I don’t know how that would help without starting the electron app. 😳

@ethanbonin
Unravel launch.json, the first part, Electron: Main. It has runtime argument, start-main-debug.
Which in turn calls start-main-dev. Which in turn starts electron app.
(you can see that in package.json of the boilerplate).

@ethanbonin  @iyobo
As for the webstorm, also doable. The only problem is that I couldn't find a possibility to run "Before launch" task in backround, so you have to start renederer manually.
So.

run (and allow to keep running) yarn start-renderer-dev
Add two configurations, one npm, one Attach to Node.js/Chrome.
npm should run start-main-debug (I prefer yarn, but configuration is still called npm)
Attaching should connect to 9223.
Start both of them clicking on debug icon. (for the attaching you will be asked to choose page to debug)
OR use compound configuration which will start both
That's it.

Here are screenshots and correspondent run configs (they are normally in .run as separate files, but they won't work without referencing in .idea/workspace.xml. so I suggest following the screenshots).

<component name="ProjectRunConfigurationManager">
  <configuration default="false" name="Electron: Main" type="js.build_tools.npm">
    <package-json value="$PROJECT_DIR$/package.json" />
    <command value="run" />
    <scripts>
      <script value="start-main-debug" />
    </scripts>
    <node-interpreter value="project" />
    <envs />
    <method v="2" />
  </configuration>
</component>

<component name="ProjectRunConfigurationManager">
  <configuration default="false" name="Electron: Renderer" type="ChromiumRemoteDebugType" factoryName="Chromium Remote" port="9223" restartOnDisconnect="true">
    <method v="2" />
  </configuration>
</component>

<component name="ProjectRunConfigurationManager">
  <configuration default="false" name="Ectron: All" type="CompoundRunConfigurationType">
    <toRun name="Electron: Main" type="js.build_tools.npm" />
    <toRun name="Electron: Renderer" type="ChromiumRemoteDebugType" />
    <method v="2" />
  </configuration>
</component>

@Do-do-new, that is pretty slick. Here's what I got. What I did is created the Attach to Node.js/Chrome configuration. I then added in the Before Launch the NPM script to run start-main-debug

@ethanbonin
Is it working for you?
Because, first, I don't see where you run renderer, second, I don't see how webstorm could attach to main here, and we discuss debugging both in parallel...

@Do-do-new, You're totally right.

@Do-do-new, I was able to get your main debug process working. The breakpoints work on the Main, but I can't seem to get it to work on the renderer. Any ideas?

@ethanbonin
Is your electron app displayed correctly? I mean, is renderer process running okay?
I ensure by running it explicitly (in case of webstorm) and with task in case of VS Code.

If yes, then you need to attach to it properly. When running compound configuration, the renderer part will ask you to select to what you want to attach. Select you app. For me it looks something like this:

@Do-do-new, When I run yarn dev or yarn start-renderer-dev without the debugger, everything works great. The main and the renderer both work and display the app.
It gives me this weird bug when I try to run the Electron: All in debug and the renderer part never asks what to attach to.

Here are my run configuration files:
<!-- Electron Main-->
<component name="ProjectRunConfigurationManager">
  <configuration default="false" name="Electron: Main" type="js.build_tools.npm">
    <package-json value="$PROJECT_DIR$/package.json" />
    <command value="run" />
    <scripts>
      <script value="start-main-debug" />
    </scripts>
    <node-interpreter value="project" />
    <envs />
    <method v="2" />
  </configuration>
</component>

<!-- Electron Renderer-->
<component name="ProjectRunConfigurationManager">
  <configuration default="false" name="Electron: Renderer" type="ChromiumRemoteDebugType" factoryName="Chromium Remote" port="9223" restartOnDisconnect="true">
    <method v="2" />
  </configuration>
</component>

<!-- Electron All-->
<component name="ProjectRunConfigurationManager">
  <configuration default="false" name="Ectron: All" type="CompoundRunConfigurationType">
    <toRun name="Electron: Main" type="js.build_tools.npm" />
    <toRun name="Electron: Renderer" type="ChromiumRemoteDebugType" />
    <method v="2" />
  </configuration>
</component>

Just to ensure, here is my package.json scripts
{
   "start-main-debug": "yarn start-main-dev --inspect=5858 --inspect-brk=9223 --remote-debugging-port=9223",
    "start-main-dev": "cross-env START_HOT=1 NODE_ENV=development electron -r ./internals/scripts/BabelRegister ./app/main.dev.ts",
    "start-renderer-dev": "cross-env NODE_ENV=development webpack-dev-server --config configs/webpack.config.renderer.dev.babel.js",
}

and I set inside webpack.config.renderer.dev.babel.js devServer: {noInfo: false} to false. Do you see anything I'm missing?

@ethanbonin
The only difference I see is that you use --inspect-brk=9223 (don't know what it is though).
Funny, I now cloned currect version of the boilerplate and they update the setup with .vscode settings which are discussed here.
I will check if it works and create fork with webstorm settings.

@ethanbonin
Just re-cloned boilerplate.
Current version (2e85c08438ef209ff9dcb636056628abb9f7aa99) also works without any extra magic (just what I described for Webstorm VS code works right away).
The only thing is that after yarn install I had to restart the PC, attaching wasn't working for some reason until I did so.

Debug both main and renderer
I had to browse through several posts (not only #428 and #528) until it worked for me with the current version, so here is a setup which worked in VS Code, at least with the current master (63cebab)
In package.json add extra script: "start-main-debug": "yarn start-main-dev --inspect=5858 --remote-debugging-port=9223"
In webpack.config.renderer.dev.babel.js: Change noInfo in devServer from true to false
In launch.json:
{
  "version": "0.2.0",
  "configurations": [
      {
          "type": "node",
          "request": "launch",
          "name": "Electron: Main",
          "protocol": "inspector",
          "runtimeExecutable": "yarn",
          "runtimeArgs": [
              "start-main-debug"
          ],
          "preLaunchTask": "Start Webpack Dev"
      },
      {
        "name": "Electron: Renderer",
        "type": "chrome",
        "request": "attach",
        "port": 9223,
        "webRoot": "${workspaceFolder}",
        "timeout": 15000
      }
  ],
  "compounds": [
      {
          "name": "Electron: All",
          "configurations": [
              "Electron: Main",
              "Electron: Renderer"
          ]
      }
  ]
}

In targets.json:
{
  "version": "2.0.0",
  "tasks": [
    {
      "type": "npm",
      "label": "Start Webpack Dev",
      "script": "start-renderer-dev",
      "options": {
        "cwd": "${workspaceFolder}"
      },
      "isBackground": true,
      "problemMatcher": {
        "owner": "custom",
        "pattern": {
          "regexp": "____________"
        },
        "background": {
          "activeOnStart": true,
          "beginsPattern": "Compiling\\.\\.\\.$",
          "endsPattern": "(Compiled successfully|Failed to compile)\\.$"
        }
      }
    }
  ]
}

Cooooool!   This works.
But in v4.3.0 we need change some files to make it work with vscode.

First

in v4.3.0 .erb/configs/webpack.config.base.ts

  stats: "errors-only"  # this should change to { all: undefined }
# webpack errors-only will only output error msg, no output like "Compiled successfully" will cause task never finished and vscode debugger will stun by this.

Second
In targets/tasks.json file endsPattern may diff in diff webpack version.
If endsPattern is not match, Start Webpack Dev will always running.
I test in webpack 5.60.0，my output is like
webpack 5.60.0 compiled successfully in 3037 ms
So I change it to below:

        "background": {
          "endsPattern": "(compiled successfully|failed to compile)"
        }

Third

in v4.3.0 .vscode/launch.json Electron: Main should change like your version put electron node args in package.json

# in package.json
{
"start:main": "cross-env NODE_ENV=development electron --inspect=5858 --remote-debugging-port=9223 -r ts-node/register/transpile-only ./src/main/main.ts",
}
# in .vscode/launch.json
{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Electron: Main",
      "type": "node",
      "request": "launch",
      "protocol": "inspector",
      "runtimeExecutable": "npm",
      "runtimeArgs": ["start:main"],
      "preLaunchTask": "Start Webpack Dev"
    },
    {
      "name": "Electron: Renderer",
      "type": "chrome",
      "request": "attach",
      "port": 9223,
      "webRoot": "${workspaceFolder}",
      "timeout": 15000
    }
  ],
  "compounds": [
    {
      "name": "Electron: All",
      "configurations": ["Electron: Main", "Electron: Renderer"]
    }
  ]
}

Reopening since the existing debugging solution is broken

Any progress with debugging in webstorm?

Easy fix for you Webstorm people:
Node interpreter: The usual one, in node_modules/.bin/electron
Node Parameters: --require ts-node/register   .
Enviroment variables: TS_NODE_TRANSPILE_ONLY=true;NODE_ENV=development

Click the edit environment variables button for easy edit:

Now you'll be able to edit you main process easily.

authors: AndreyDodonov-EH DaanBroekhof Do-do-new Evilu PitterL Slapbox aj-ptw amilajack ethanbonin iyobo nessup panta82 pialin prophetw ritz078 wyjieying

repo: chentsulin/electron-react-boilerplate


text:
🛑 El abridor is down

In 5bfa247, El abridor (https://chequeado.com/elabridor/) was down:

HTTP code: 503
Response time: 15 ms

Resolved: El abridor is back up in 7c2fe57.

source: gharchive/issue

repo: chequeado/status

license: MIT

license_type: permissive

license_source: github-api


text:
Pattern starting with fixed content are ignored

Foo{X1} does not work. Foo is ignored.
{X1}-Foo-{X1} works.

Fixed, thanks =)

repo: cherry-wave/NMG

license: mit

license_source: bigquery


text:
outdated docker packages

Hi,
would it be possible to update the docker package at https://github.com/orgs/chevere/packages/container/package/xr ?

There's a new package, here: https://github.com/chevere/xr-server/pkgs/container/xr-server

Nice, thanks.

repo: chevere/xr


text:
poetry install does not install buzz

Using version 0.8.4, and on GNU/Linux running
$ pip install poetry
$ poetry install

there is no tool buzz installed in ~/.local/bin. Running poetry run python main.py works, but the CLI tool, mentioned in the documentation, is not installed.

See notes on running locally https://github.com/chidiwilliams/buzz/blob/main/CONTRIBUTING.md
Try running poetry build to build the *.whl and then install it from ./dist folder. Or just use snap https://snapcraft.io/buzz

authors: paulmenzel raivisdejus

repo: chidiwilliams/buzz


text:
[Visual Bug] Sprinting in a chair

It is weird that I can actually sprint while sitting on a chair. Even weirder is the fact that I see the running particles. Btw, is it intentional I have to click it with an empty hand to sit in it? Inconvenient. :3

I agree that it's kind of weird. However, in my testing, I found the same behavior exists in a minecart that isn't on any rails. It is completely stationary, but the visual effects still trigger.
As for the empty hand thing; that will be fixed in the version coming later this week. I already have it updated in the main branch, so when I get things ported to 1.18.1 and 1.17.1 and finish squashing what bugs I can, it'll be uploaded to CurseForge.

2.5.1 of the mod has been published to CurseForge for all three supported versions!

authors: HacoKavanah chimericdream

repo: chimericdream/minekea-fabric


text:
Using attributes on a transparent enum (specifically derive)

Hi, this might be something I missed when reading the book/tests/examples but I can't find a way to use the derive attribute on a transparent enum. Here's an example:
#[swift_bridge::bridge]
mod ffi {
    #[derive(Debug)] // fails to compile unless this is removed
    pub enum TestEnum {
        Variant1,
        Variant2,
    }
}

Am I missing something or is this not supported? Are there any workarounds besides manually implementing the traits? Thanks.

Do I have to manually implement the Debug part? Would I be able to easily use derive macros from other crates?

We can consider supporting popular stdlib derives on a case by case basis (for example, we may want to support serde's derives).
But I don't think that we want to support arbitrary derives, since a derive could emit code that breaks out codegen.
This comment in the cxx explains a code example, where a derive macro could emit type u32 = u8.
This would lead our codegen to emit code that it thinks is for a u32 when it's really for a u8, which could lead to undefined behavior if, for example, we have a struct MyStruct { field: u32 } which would be a u8 on the Rust side but a u32 on the Swift side.

I will work on implementing this. Thanks for the detailed implementation guide!

Awesome!! Feel free to ask lots of questions as you dive in. I'm here to help!

Also, if I'm correct, swift-bridge does not support copying docs from Rust to the generated Swift code. Is there an issue for this, and would I be able to help?

Yup, there is! It has an implementation guide that you could follow https://github.com/chinedufn/swift-bridge/issues/62

Actually, it might be possible to safely support arbitrary derives.
We'd need to think through all of the possible edge cases but in general I'm imagining something like:

Let's say we had this bridge module:
#[swift_bridge::bridge]
mod ffi {
    #[derive(SomeCustomDerive)]
    struct MyStruct {
        field: u32
    }
}

Which generated something like:
mod ffi {
    type u32 = ();

    struct MyStruct {
        field: u32
    }
}

We could make this a compile time error by emitting the following into every bridge module that used at least one deriving:
mod ffi {
    type u8 = swift_bridge::stdlib::u8;
    type i8 = swift_bridge::stdlib::i8;
    // ...
    type u32 = swift_bridge::stdlib::u32;
    // ...
}

In this way if the derive macro emitted type u32 = () there would be a compile time error since type u32 would be defined twice.
mod ffi {
    // ...
    type u32 = swift_bridge::stdlib::u32;
    // ...

    // This `type u32 = ()` was emitted by the custom derive.
    type u32 = ();

    struct MyStruct {
        field: u32
    }
}

This approach would guarantee that all of the types are what we think that they are.
This is a quick idea off the top of my head so I haven't thought through whether or not there are ways to get around this technique.. but if not then this would let us support arbitrary derives without the possibility of introducing undefined behavior.

For the purpose of this issue we can just focus on landing #[derive(Debug)]. I'm just sharing some ideas for the future.

Parsing the #[derive(Debug)] macro

I'm a bit lost here in terms of where I would need to add properties for the DeriveAttrs. I've added a property to the newly added SharedEnumAllAttributes and also SharedEnum and it's able to recognize derive attributes (no parsing of Debug yet though). I'm also not sure if I should rename any of the structs I moved to enum_attributes, and I don't know how to pass the ParseErrors to safely handle errors. Would you like me to push my WIP changes to a branch?

Here's how the opaque type's attributes get parsed https://github.com/chinedufn/swift-bridge/blob/3c0d00da33fdf19e201eb121c7e6e370897f8070/crates/swift-bridge-ir/src/parse/parse_extern_mod.rs#L88
We'd make a similar call to SharedEnumAllAttributes::from_attributes around here https://github.com/chinedufn/swift-bridge/blob/819e39160ec5b38dce2e60e2d39d078617ad158d/crates/swift-bridge-ir/src/parse/parse_enum.rs#L72-L92

I'm also not sure if I should rename any of the structs I moved to enum_attributes

Yeah you can rename them to be similar to the opaque type attributes.

I don't know how to pass the ParseErrors to safely handle errors.

If you want you can just early return with ? like we do for opaque type attributes https://github.com/chinedufn/swift-bridge/blob/3c0d00da33fdf19e201eb121c7e6e370897f8070/crates/swift-bridge-ir/src/parse/parse_extern_mod.rs#L88
Not as nice as pushing to parse errors, but it's fine for now since the OpaqueTypeAllAttributes::from_attributes flow
But, if you wanted to push parse errors you could just pass in self.errors into SharedEnumAllAttributes::from_attributes(&item_enum.attrs, self.errors) around here https://github.com/chinedufn/swift-bridge/blob/819e39160ec5b38dce2e60e2d39d078617ad158d/crates/swift-bridge-ir/src/parse/parse_enum.rs#L72-L92

Would you like me to push my WIP changes to a branch?

Absolutely!

authors: chinedufn naturecodevoid

repo: chinedufn/swift-bridge


text:
Node.js is not a programming language.

Node.js is not a programming language, it is a runtime.

awa

Node.js is not a programming language, it is a runtime.

I just say language, didn't say programming language

it is not a language too

it is a runtime

lao

nou

okay, I will edit it.
so i will close this issue


text:
The genscope is not parsed

It is similar to https://github.com/chipsalliance/Surelog/issues/2445, but it is 1 instance deeper. I don't know if the problem is the depth or the initialization of the top parameter that includes many package references.
Source:
package prim_pad_wrapper_pkg;
   typedef enum  logic [2:0] {
      A = 3'h0,
      B = 3'h1
   } pad_type_e;
endpackage : prim_pad_wrapper_pkg

package pinmux_pkg;
   import prim_pad_wrapper_pkg::*;

   parameter int NDioPads = 1;

   typedef struct packed {
      pad_type_e [NDioPads-1:0] dio_pad_type;
   } target_cfg_t;

   parameter target_cfg_t DefaultTargetCfg = '{
      dio_pad_type: {NDioPads{A}}
   };
endpackage : pinmux_pkg

module prim_generic_pad_attr(output int a);
   import prim_pad_wrapper_pkg::*;
   parameter pad_type_e PadType = A;
   if (PadType == B) begin : gen_assign
      assign a = 1;
   end
endmodule : prim_generic_pad_attr

module prim_pad_attr(output int b);
   import prim_pad_wrapper_pkg::*;
   parameter pad_type_e PadType = A;

   if (1) begin : gen_generic
      prim_generic_pad_attr #(
         .PadType(PadType)
      ) u_impl_generic(.a(b));
   end
endmodule

module sub_top(output int c);
   import pinmux_pkg::*;
   parameter target_cfg_t TargetCfg = DefaultTargetCfg;

  for (genvar k = 0; k < NDioPads; k++) begin : gen_dio_attr
     prim_pad_attr #(
        .PadType(TargetCfg.dio_pad_type[k])
     ) u_prim_pad_attr(.b(c));
  end
endmodule

module top(output int o);
   localparam pinmux_pkg::target_cfg_t PinmuxTargetCfg = '{
      dio_pad_type: {pinmux_pkg::NDioPads{prim_pad_wrapper_pkg::B}}
   };

   sub_top #(
      .TargetCfg(PinmuxTargetCfg)
   ) u_sub(.c(o));
endmodule

The problem is that there is no gen_assign scope in uhdm.
|uhdmtopModules:
\_module: work@top (work@top) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:52:1: , endln:60:10
  |vpiName:work@top
  |vpiVariables:
  \_int_var: (work@top.o), line:52:23, endln:52:24, parent:work@top
    |vpiName:o
    |vpiFullName:work@top.o
    |vpiAutomatic:1
    |vpiVisibility:1
  |vpiParameter:
  \_parameter: (work@top.PinmuxTargetCfg), line:53:40, endln:55:5, parent:work@top
    |vpiTypespec:
    \_struct_typespec: (pinmux_pkg::target_cfg_t), line:13:12, endln:13:18, parent:work@top.PinmuxTargetCfg
      |vpiName:pinmux_pkg::target_cfg_t
      |vpiInstance:
      \_package: pinmux_pkg (pinmux_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:8:1: , endln:20:24, parent:work@top
        |vpiName:pinmux_pkg
        |vpiFullName:pinmux_pkg::
        |vpiParameter:
        \_parameter: (pinmux_pkg::NDioPads), line:11:18, endln:11:30, parent:pinmux_pkg::
          |UINT:1
          |vpiTypespec:
          \_int_typespec: , line:11:14, endln:11:17, parent:pinmux_pkg::NDioPads
            |vpiInstance:
            \_package: pinmux_pkg (pinmux_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:8:1: , endln:20:24, parent:work@top
          |vpiName:NDioPads
          |vpiFullName:pinmux_pkg::NDioPads
        |vpiParameter:
        \_parameter: (pinmux_pkg::DefaultTargetCfg), line:17:27, endln:19:5, parent:pinmux_pkg::
          |vpiTypespec:
          \_struct_typespec: (pinmux_pkg::target_cfg_t), line:13:12, endln:13:18, parent:work@top.PinmuxTargetCfg
            |vpiName:pinmux_pkg::target_cfg_t
            |vpiInstance:
            \_package: pinmux_pkg (pinmux_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:8:1: , endln:20:24, parent:work@top
            |vpiPacked:1
            |vpiTypespecMember:
            \_typespec_member: (dio_pad_type), line:14:33, endln:14:45
              |vpiName:dio_pad_type
              |vpiTypespec:
              \_packed_array_typespec:
                |vpiInstance:
                \_package: pinmux_pkg (pinmux_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:8:1: , endln:20:24, parent:work@top
                |vpiRange:
                \_range: , line:14:19, endln:14:31, parent:pinmux_pkg::target_cfg_t
                  |vpiLeftRange:
                  \_constant: , line:14:19, endln:14:27
                    |vpiDecompile:0
                    |vpiSize:64
                    |INT:0
                    |vpiConstType:7
                  |vpiRightRange:
                  \_constant: , line:14:30, endln:14:31
                    |vpiDecompile:0
                    |vpiSize:64
                    |UINT:0
                    |vpiConstType:9
                |vpiElemTypespec:
                \_enum_typespec: (prim_pad_wrapper_pkg::pad_type_e), line:5:6, endln:5:16, parent:work@prim_pad_attr.PadType
                  |vpiName:prim_pad_wrapper_pkg::pad_type_e
                  |vpiInstance:
                  \_package: prim_pad_wrapper_pkg (prim_pad_wrapper_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:1:1: , endln:6:34, parent:work@top
                    |vpiName:prim_pad_wrapper_pkg
                    |vpiFullName:prim_pad_wrapper_pkg::
                    |vpiTypedef:
                    \_enum_typespec: (prim_pad_wrapper_pkg::pad_type_e), line:5:6, endln:5:16, parent:work@prim_pad_attr.PadType
                    |vpiDefName:prim_pad_wrapper_pkg
                  |vpiBaseTypespec:
                  \_logic_typespec: , line:2:18, endln:2:23
                    |vpiInstance:
                    \_package: prim_pad_wrapper_pkg (prim_pad_wrapper_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:1:1: , endln:6:34, parent:work@top
                    |vpiRange:
                    \_range: , line:2:25, endln:2:28
                      |vpiLeftRange:
                      \_constant: , line:2:25, endln:2:26
                        |vpiDecompile:2
                        |vpiSize:64
                        |UINT:2
                        |vpiConstType:9
                      |vpiRightRange:
                      \_constant: , line:2:27, endln:2:28
                        |vpiDecompile:0
                        |vpiSize:64
                        |UINT:0
                        |vpiConstType:9
                  |vpiEnumConst:
                  \_enum_const: (A), line:3:7, endln:3:8
                    |vpiName:A
                    |UINT:0
                    |vpiDecompile:3'h0
                    |vpiSize:3
                  |vpiEnumConst:
                  \_enum_const: (B), line:4:7, endln:4:8
                    |vpiName:B
                    |UINT:1
                    |vpiDecompile:3'h1
                    |vpiSize:3
          |vpiName:DefaultTargetCfg
          |vpiFullName:pinmux_pkg::DefaultTargetCfg
        |vpiParamAssign:
        \_param_assign: , line:11:18, endln:11:30, parent:pinmux_pkg::
          |vpiRhs:
          \_constant: , line:11:29, endln:11:30
            |vpiDecompile:1
            |vpiSize:32
            |UINT:1
            |vpiTypespec:
            \_int_typespec: , line:11:14, endln:11:17, parent:pinmux_pkg::NDioPads
            |vpiConstType:9
          |vpiLhs:
          \_parameter: (pinmux_pkg::NDioPads), line:11:18, endln:11:30, parent:pinmux_pkg::
        |vpiParamAssign:
        \_param_assign: , line:17:27, endln:19:5, parent:pinmux_pkg::
          |vpiRhs:
          \_operation: , line:17:46, endln:19:5
            |vpiOpType:75
            |vpiOperand:
            \_tagged_pattern:
              |vpiPattern:
              \_constant: , line:18:21, endln:18:34
                |vpiDecompile:000
                |vpiSize:3
                |BIN:000
                |vpiTypespec:
                \_int_typespec:
                  |UINT:3
                |vpiConstType:3
              |vpiTypespec:
              \_string_typespec: (dio_pad_type), line:18:7, endln:18:19
                |vpiName:dio_pad_type
          |vpiLhs:
          \_parameter: (pinmux_pkg::DefaultTargetCfg), line:17:27, endln:19:5, parent:pinmux_pkg::
        |vpiTypedef:
        \_enum_typespec: (prim_pad_wrapper_pkg::pad_type_e), line:5:6, endln:5:16, parent:work@prim_pad_attr.PadType
        |vpiTypedef:
        \_struct_typespec: (pinmux_pkg::target_cfg_t), line:13:12, endln:13:18, parent:work@top.PinmuxTargetCfg
        |vpiTypedef:
        \_import: (prim_pad_wrapper_pkg), line:9:11, endln:9:34
        |vpiDefName:pinmux_pkg
      |vpiPacked:1
      |vpiTypespecMember:
      \_typespec_member: (dio_pad_type), line:14:33, endln:14:45, parent:pinmux_pkg::target_cfg_t
        |vpiName:dio_pad_type
        |vpiTypespec:
        \_packed_array_typespec: , parent:dio_pad_type
          |vpiInstance:
          \_package: pinmux_pkg (pinmux_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:8:1: , endln:20:24, parent:work@top
          |vpiRange:
          \_range: , line:14:19, endln:14:31
            |vpiLeftRange:
            \_constant: , line:14:19, endln:14:27
              |vpiDecompile:0
              |vpiSize:64
              |INT:0
              |vpiConstType:7
            |vpiRightRange:
            \_constant: , line:14:30, endln:14:31
              |vpiDecompile:0
              |vpiSize:64
              |UINT:0
              |vpiConstType:9
          |vpiElemTypespec:
          \_enum_typespec: (prim_pad_wrapper_pkg::pad_type_e), line:5:6, endln:5:16
            |vpiName:prim_pad_wrapper_pkg::pad_type_e
            |vpiInstance:
            \_package: prim_pad_wrapper_pkg (prim_pad_wrapper_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:1:1: , endln:6:34, parent:work@top
            |vpiBaseTypespec:
            \_logic_typespec: , line:2:18, endln:2:23, parent:prim_pad_wrapper_pkg::pad_type_e
              |vpiInstance:
              \_package: prim_pad_wrapper_pkg (prim_pad_wrapper_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:1:1: , endln:6:34, parent:work@top
              |vpiRange:
              \_range: , line:2:25, endln:2:28
                |vpiLeftRange:
                \_constant: , line:2:25, endln:2:26
                  |vpiDecompile:2
                  |vpiSize:64
                  |UINT:2
                  |vpiConstType:9
                |vpiRightRange:
                \_constant: , line:2:27, endln:2:28
                  |vpiDecompile:0
                  |vpiSize:64
                  |UINT:0
                  |vpiConstType:9
            |vpiEnumConst:
            \_enum_const: (A), line:3:7, endln:3:8, parent:prim_pad_wrapper_pkg::pad_type_e
              |vpiName:A
              |UINT:0
              |vpiDecompile:3'h0
              |vpiSize:3
            |vpiEnumConst:
            \_enum_const: (B), line:4:7, endln:4:8, parent:prim_pad_wrapper_pkg::pad_type_e
              |vpiName:B
              |UINT:1
              |vpiDecompile:3'h1
              |vpiSize:3
    |vpiLocalParam:1
    |vpiName:PinmuxTargetCfg
    |vpiFullName:work@top.PinmuxTargetCfg
  |vpiParamAssign:
  \_param_assign: , line:53:40, endln:55:5, parent:work@top
    |vpiRhs:
    \_operation: , line:53:58, endln:55:5
      |vpiTypespec:
      \_struct_typespec: (pinmux_pkg::target_cfg_t), line:13:12, endln:13:18
        |vpiName:pinmux_pkg::target_cfg_t
        |vpiInstance:
        \_package: pinmux_pkg (pinmux_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:8:1: , endln:20:24, parent:work@top
        |vpiPacked:1
        |vpiTypespecMember:
        \_typespec_member: (dio_pad_type), line:14:33, endln:14:45, parent:pinmux_pkg::target_cfg_t
          |vpiName:dio_pad_type
          |vpiTypespec:
          \_packed_array_typespec: , parent:dio_pad_type
            |vpiInstance:
            \_package: pinmux_pkg (pinmux_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:8:1: , endln:20:24, parent:work@top
            |vpiRange:
            \_range: , line:14:19, endln:14:31
              |vpiLeftRange:
              \_constant: , line:14:19, endln:14:27
                |vpiDecompile:0
                |vpiSize:64
                |INT:0
                |vpiConstType:7
              |vpiRightRange:
              \_constant: , line:14:30, endln:14:31
                |vpiDecompile:0
                |vpiSize:64
                |UINT:0
                |vpiConstType:9
            |vpiElemTypespec:
            \_enum_typespec: (prim_pad_wrapper_pkg::pad_type_e), line:5:6, endln:5:16
              |vpiName:prim_pad_wrapper_pkg::pad_type_e
              |vpiInstance:
              \_package: prim_pad_wrapper_pkg (prim_pad_wrapper_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:1:1: , endln:6:34, parent:work@top
              |vpiBaseTypespec:
              \_logic_typespec: , line:2:18, endln:2:23, parent:prim_pad_wrapper_pkg::pad_type_e
                |vpiInstance:
                \_package: prim_pad_wrapper_pkg (prim_pad_wrapper_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:1:1: , endln:6:34, parent:work@top
                |vpiRange:
                \_range: , line:2:25, endln:2:28
                  |vpiLeftRange:
                  \_constant: , line:2:25, endln:2:26
                    |vpiDecompile:2
                    |vpiSize:64
                    |UINT:2
                    |vpiConstType:9
                  |vpiRightRange:
                  \_constant: , line:2:27, endln:2:28
                    |vpiDecompile:0
                    |vpiSize:64
                    |UINT:0
                    |vpiConstType:9
              |vpiEnumConst:
              \_enum_const: (A), line:3:7, endln:3:8, parent:prim_pad_wrapper_pkg::pad_type_e
                |vpiName:A
                |UINT:0
                |vpiDecompile:3'h0
                |vpiSize:3
              |vpiEnumConst:
              \_enum_const: (B), line:4:7, endln:4:8, parent:prim_pad_wrapper_pkg::pad_type_e
                |vpiName:B
                |UINT:1
                |vpiDecompile:3'h1
                |vpiSize:3
      |vpiOpType:75
      |vpiFlattened:1
      |vpiOperand:
      \_operation: , line:54:21, endln:54:68
        |vpiOpType:34
        |vpiOperand:
        \_constant: , line:54:22, endln:54:42
          |vpiDecompile:1
          |vpiSize:32
          |UINT:1
          |vpiConstType:9
        |vpiOperand:
        \_operation: , line:54:43, endln:54:66
          |vpiOpType:33
          |vpiOperand:
          \_constant: , line:54:43, endln:54:66
            |vpiDecompile:1
            |vpiSize:3
            |UINT:1
            |vpiConstType:9
    |vpiLhs:
    \_parameter: (work@top.PinmuxTargetCfg), line:53:40, endln:55:5, parent:work@top
  |vpiDefName:work@top
  |vpiPort:
  \_port: (o), line:52:23, endln:52:24, parent:work@top
    |vpiName:o
    |vpiDirection:2
    |vpiLowConn:
    \_ref_obj: (work@top.o)
      |vpiName:o
      |vpiFullName:work@top.o
      |vpiActual:
      \_int_var: (work@top.o), line:52:23, endln:52:24, parent:work@top
  |vpiModule:
  \_module: work@sub_top (work@top.u_sub) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:57:4: , endln:59:19, parent:work@top
    |vpiName:u_sub
    |vpiFullName:work@top.u_sub
    |vpiVariables:
    \_int_var: (work@top.u_sub.c), line:41:27, endln:41:28, parent:work@top.u_sub
      |vpiName:c
      |vpiFullName:work@top.u_sub.c
      |vpiAutomatic:1
      |vpiVisibility:1
    |vpiParameter:
    \_parameter: (work@top.u_sub.DefaultTargetCfg), line:17:27, endln:19:5, parent:work@top.u_sub
      |vpiTypespec:
      \_struct_typespec: (pinmux_pkg::target_cfg_t), line:13:12, endln:13:18, parent:work@top.u_sub.DefaultTargetCfg
        |vpiName:pinmux_pkg::target_cfg_t
        |vpiInstance:
        \_package: pinmux_pkg (pinmux_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:8:1: , endln:20:24, parent:work@top
        |vpiPacked:1
        |vpiTypespecMember:
        \_typespec_member: (dio_pad_type), line:14:33, endln:14:45, parent:pinmux_pkg::target_cfg_t
          |vpiName:dio_pad_type
          |vpiTypespec:
          \_packed_array_typespec: , parent:dio_pad_type
            |vpiInstance:
            \_package: pinmux_pkg (pinmux_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:8:1: , endln:20:24, parent:work@top
            |vpiRange:
            \_range: , line:14:19, endln:14:31
              |vpiLeftRange:
              \_constant: , line:14:19, endln:14:27
                |vpiDecompile:0
                |vpiSize:64
                |INT:0
                |vpiConstType:7
              |vpiRightRange:
              \_constant: , line:14:30, endln:14:31
                |vpiDecompile:0
                |vpiSize:64
                |UINT:0
                |vpiConstType:9
            |vpiElemTypespec:
            \_enum_typespec: (prim_pad_wrapper_pkg::pad_type_e), line:5:6, endln:5:16
              |vpiName:prim_pad_wrapper_pkg::pad_type_e
              |vpiInstance:
              \_package: prim_pad_wrapper_pkg (prim_pad_wrapper_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:1:1: , endln:6:34, parent:work@top
              |vpiBaseTypespec:
              \_logic_typespec: , line:2:18, endln:2:23, parent:prim_pad_wrapper_pkg::pad_type_e
                |vpiInstance:
                \_package: prim_pad_wrapper_pkg (prim_pad_wrapper_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:1:1: , endln:6:34, parent:work@top
                |vpiRange:
                \_range: , line:2:25, endln:2:28
                  |vpiLeftRange:
                  \_constant: , line:2:25, endln:2:26
                    |vpiDecompile:2
                    |vpiSize:64
                    |UINT:2
                    |vpiConstType:9
                  |vpiRightRange:
                  \_constant: , line:2:27, endln:2:28
                    |vpiDecompile:0
                    |vpiSize:64
                    |UINT:0
                    |vpiConstType:9
              |vpiEnumConst:
              \_enum_const: (A), line:3:7, endln:3:8, parent:prim_pad_wrapper_pkg::pad_type_e
                |vpiName:A
                |UINT:0
                |vpiDecompile:3'h0
                |vpiSize:3
              |vpiEnumConst:
              \_enum_const: (B), line:4:7, endln:4:8, parent:prim_pad_wrapper_pkg::pad_type_e
                |vpiName:B
                |UINT:1
                |vpiDecompile:3'h1
                |vpiSize:3
      |vpiName:DefaultTargetCfg
      |vpiFullName:work@top.u_sub.DefaultTargetCfg
      |vpiImported:pinmux_pkg
    |vpiParameter:
    \_parameter: (work@top.u_sub.NDioPads), line:11:18, endln:11:30, parent:work@top.u_sub
      |UINT:1
      |vpiTypespec:
      \_int_typespec: , line:11:14, endln:11:17, parent:work@top.u_sub.NDioPads
        |vpiInstance:
        \_package: pinmux_pkg (pinmux_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:8:1: , endln:20:24, parent:work@top
      |vpiName:NDioPads
      |vpiFullName:work@top.u_sub.NDioPads
      |vpiImported:pinmux_pkg
    |vpiParameter:
    \_parameter: (work@top.u_sub.TargetCfg), line:43:27, endln:43:55, parent:work@top.u_sub
      |vpiTypespec:
      \_struct_typespec: (pinmux_pkg::target_cfg_t), line:13:12, endln:13:18, parent:work@top.u_sub.TargetCfg
        |vpiName:pinmux_pkg::target_cfg_t
        |vpiInstance:
        \_package: pinmux_pkg (pinmux_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:8:1: , endln:20:24, parent:work@top
        |vpiPacked:1
        |vpiTypespecMember:
        \_typespec_member: (dio_pad_type), line:14:33, endln:14:45, parent:pinmux_pkg::target_cfg_t
          |vpiName:dio_pad_type
          |vpiTypespec:
          \_packed_array_typespec: , parent:dio_pad_type
            |vpiInstance:
            \_package: pinmux_pkg (pinmux_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:8:1: , endln:20:24, parent:work@top
            |vpiRange:
            \_range: , line:14:19, endln:14:31
              |vpiLeftRange:
              \_constant: , line:14:19, endln:14:27
                |vpiDecompile:0
                |vpiSize:64
                |INT:0
                |vpiConstType:7
              |vpiRightRange:
              \_constant: , line:14:30, endln:14:31
                |vpiDecompile:0
                |vpiSize:64
                |UINT:0
                |vpiConstType:9
            |vpiElemTypespec:
            \_enum_typespec: (prim_pad_wrapper_pkg::pad_type_e), line:5:6, endln:5:16
              |vpiName:prim_pad_wrapper_pkg::pad_type_e
              |vpiInstance:
              \_package: prim_pad_wrapper_pkg (prim_pad_wrapper_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:1:1: , endln:6:34, parent:work@top
              |vpiBaseTypespec:
              \_logic_typespec: , line:2:18, endln:2:23, parent:prim_pad_wrapper_pkg::pad_type_e
                |vpiInstance:
                \_package: prim_pad_wrapper_pkg (prim_pad_wrapper_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:1:1: , endln:6:34, parent:work@top
                |vpiRange:
                \_range: , line:2:25, endln:2:28
                  |vpiLeftRange:
                  \_constant: , line:2:25, endln:2:26
                    |vpiDecompile:2
                    |vpiSize:64
                    |UINT:2
                    |vpiConstType:9
                  |vpiRightRange:
                  \_constant: , line:2:27, endln:2:28
                    |vpiDecompile:0
                    |vpiSize:64
                    |UINT:0
                    |vpiConstType:9
              |vpiEnumConst:
              \_enum_const: (A), line:3:7, endln:3:8, parent:prim_pad_wrapper_pkg::pad_type_e
                |vpiName:A
                |UINT:0
                |vpiDecompile:3'h0
                |vpiSize:3
              |vpiEnumConst:
              \_enum_const: (B), line:4:7, endln:4:8, parent:prim_pad_wrapper_pkg::pad_type_e
                |vpiName:B
                |UINT:1
                |vpiDecompile:3'h1
                |vpiSize:3
      |vpiName:TargetCfg
      |vpiFullName:work@top.u_sub.TargetCfg
    |vpiParamAssign:
    \_param_assign: , line:11:18, endln:11:30, parent:work@top.u_sub
      |vpiRhs:
      \_constant: , line:11:29, endln:11:30
        |vpiDecompile:1
        |vpiSize:32
        |UINT:1
        |vpiTypespec:
        \_int_typespec: , line:11:14, endln:11:17, parent:work@sub_top.NDioPads
          |vpiInstance:
          \_package: pinmux_pkg (pinmux_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:8:1: , endln:20:24, parent:work@top
        |vpiConstType:9
      |vpiLhs:
      \_parameter: (work@top.u_sub.NDioPads), line:11:18, endln:11:30, parent:work@top.u_sub
    |vpiParamAssign:
    \_param_assign: , line:17:27, endln:19:5, parent:work@top.u_sub
      |vpiRhs:
      \_operation: , line:17:46, endln:19:5
        |vpiTypespec:
        \_struct_typespec: (pinmux_pkg::target_cfg_t), line:13:12, endln:13:18
          |vpiName:pinmux_pkg::target_cfg_t
          |vpiInstance:
          \_package: pinmux_pkg (pinmux_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:8:1: , endln:20:24, parent:work@top
          |vpiPacked:1
          |vpiTypespecMember:
          \_typespec_member: (dio_pad_type), line:14:33, endln:14:45, parent:pinmux_pkg::target_cfg_t
            |vpiName:dio_pad_type
            |vpiTypespec:
            \_packed_array_typespec: , parent:dio_pad_type
              |vpiInstance:
              \_package: pinmux_pkg (pinmux_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:8:1: , endln:20:24, parent:work@top
              |vpiRange:
              \_range: , line:14:19, endln:14:31
                |vpiLeftRange:
                \_constant: , line:14:19, endln:14:27
                  |vpiDecompile:0
                  |vpiSize:64
                  |INT:0
                  |vpiConstType:7
                |vpiRightRange:
                \_constant: , line:14:30, endln:14:31
                  |vpiDecompile:0
                  |vpiSize:64
                  |UINT:0
                  |vpiConstType:9
              |vpiElemTypespec:
              \_enum_typespec: (prim_pad_wrapper_pkg::pad_type_e), line:5:6, endln:5:16
                |vpiName:prim_pad_wrapper_pkg::pad_type_e
                |vpiInstance:
                \_package: prim_pad_wrapper_pkg (prim_pad_wrapper_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:1:1: , endln:6:34, parent:work@top
                |vpiBaseTypespec:
                \_logic_typespec: , line:2:18, endln:2:23, parent:prim_pad_wrapper_pkg::pad_type_e
                  |vpiInstance:
                  \_package: prim_pad_wrapper_pkg (prim_pad_wrapper_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:1:1: , endln:6:34, parent:work@top
                  |vpiRange:
                  \_range: , line:2:25, endln:2:28
                    |vpiLeftRange:
                    \_constant: , line:2:25, endln:2:26
                      |vpiDecompile:2
                      |vpiSize:64
                      |UINT:2
                      |vpiConstType:9
                    |vpiRightRange:
                    \_constant: , line:2:27, endln:2:28
                      |vpiDecompile:0
                      |vpiSize:64
                      |UINT:0
                      |vpiConstType:9
                |vpiEnumConst:
                \_enum_const: (A), line:3:7, endln:3:8, parent:prim_pad_wrapper_pkg::pad_type_e
                  |vpiName:A
                  |UINT:0
                  |vpiDecompile:3'h0
                  |vpiSize:3
                |vpiEnumConst:
                \_enum_const: (B), line:4:7, endln:4:8, parent:prim_pad_wrapper_pkg::pad_type_e
                  |vpiName:B
                  |UINT:1
                  |vpiDecompile:3'h1
                  |vpiSize:3
        |vpiOpType:75
        |vpiFlattened:1
        |vpiOperand:
        \_constant: , line:18:21, endln:18:34
          |vpiDecompile:000
          |vpiSize:3
          |BIN:000
          |vpiTypespec:
          \_int_typespec:
            |UINT:3
          |vpiConstType:3
      |vpiLhs:
      \_parameter: (work@top.u_sub.DefaultTargetCfg), line:17:27, endln:19:5, parent:work@top.u_sub
    |vpiParamAssign:
    \_param_assign: , line:43:27, endln:43:55, parent:work@top.u_sub
      |vpiOverriden:1
      |vpiRhs:
      \_operation: , line:58:18, endln:58:33
        |vpiTypespec:
        \_struct_typespec: (pinmux_pkg::target_cfg_t), line:13:12, endln:13:18
          |vpiName:pinmux_pkg::target_cfg_t
          |vpiInstance:
          \_package: pinmux_pkg (pinmux_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:8:1: , endln:20:24, parent:work@top
          |vpiPacked:1
          |vpiTypespecMember:
          \_typespec_member: (dio_pad_type), line:14:33, endln:14:45, parent:pinmux_pkg::target_cfg_t
            |vpiName:dio_pad_type
            |vpiTypespec:
            \_packed_array_typespec: , parent:dio_pad_type
              |vpiInstance:
              \_package: pinmux_pkg (pinmux_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:8:1: , endln:20:24, parent:work@top
              |vpiRange:
              \_range: , line:14:19, endln:14:31
                |vpiLeftRange:
                \_constant: , line:14:19, endln:14:27
                  |vpiDecompile:0
                  |vpiSize:64
                  |INT:0
                  |vpiConstType:7
                |vpiRightRange:
                \_constant: , line:14:30, endln:14:31
                  |vpiDecompile:0
                  |vpiSize:64
                  |UINT:0
                  |vpiConstType:9
              |vpiElemTypespec:
              \_enum_typespec: (prim_pad_wrapper_pkg::pad_type_e), line:5:6, endln:5:16
                |vpiName:prim_pad_wrapper_pkg::pad_type_e
                |vpiInstance:
                \_package: prim_pad_wrapper_pkg (prim_pad_wrapper_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:1:1: , endln:6:34, parent:work@top
                |vpiBaseTypespec:
                \_logic_typespec: , line:2:18, endln:2:23, parent:prim_pad_wrapper_pkg::pad_type_e
                  |vpiInstance:
                  \_package: prim_pad_wrapper_pkg (prim_pad_wrapper_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:1:1: , endln:6:34, parent:work@top
                  |vpiRange:
                  \_range: , line:2:25, endln:2:28
                    |vpiLeftRange:
                    \_constant: , line:2:25, endln:2:26
                      |vpiDecompile:2
                      |vpiSize:64
                      |UINT:2
                      |vpiConstType:9
                    |vpiRightRange:
                    \_constant: , line:2:27, endln:2:28
                      |vpiDecompile:0
                      |vpiSize:64
                      |UINT:0
                      |vpiConstType:9
                |vpiEnumConst:
                \_enum_const: (A), line:3:7, endln:3:8, parent:prim_pad_wrapper_pkg::pad_type_e
                  |vpiName:A
                  |UINT:0
                  |vpiDecompile:3'h0
                  |vpiSize:3
                |vpiEnumConst:
                \_enum_const: (B), line:4:7, endln:4:8, parent:prim_pad_wrapper_pkg::pad_type_e
                  |vpiName:B
                  |UINT:1
                  |vpiDecompile:3'h1
                  |vpiSize:3
        |vpiOpType:75
        |vpiFlattened:1
        |vpiOperand:
        \_operation: , line:54:21, endln:54:68
          |vpiOpType:34
          |vpiOperand:
          \_constant: , line:54:22, endln:54:42
            |vpiDecompile:1
            |vpiSize:32
            |UINT:1
            |vpiConstType:9
          |vpiOperand:
          \_operation: , line:54:43, endln:54:66
            |vpiOpType:33
            |vpiOperand:
            \_constant: , line:54:43, endln:54:66
              |vpiDecompile:1
              |vpiSize:3
              |UINT:1
              |vpiConstType:9
      |vpiLhs:
      \_parameter: (work@top.u_sub.TargetCfg), line:43:27, endln:43:55, parent:work@top.u_sub
    |vpiTypedef:
    \_enum_typespec: (prim_pad_wrapper_pkg::pad_type_e), line:5:6, endln:5:16, parent:work@prim_pad_attr.PadType
    |vpiTypedef:
    \_struct_typespec: (pinmux_pkg::target_cfg_t), line:13:12, endln:13:18, parent:work@top.PinmuxTargetCfg
    |vpiTypedef:
    \_import: (pinmux_pkg), line:42:11, endln:42:24
    |vpiDefName:work@sub_top
    |vpiDefFile:tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv
    |vpiDefLineNo:41
    |vpiInstance:
    \_module: work@top (work@top) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:52:1: , endln:60:10
    |vpiPort:
    \_port: (c), line:41:27, endln:41:28, parent:work@top.u_sub
      |vpiName:c
      |vpiDirection:2
      |vpiHighConn:
      \_ref_obj: (work@top.o), line:59:15, endln:59:16
        |vpiName:o
        |vpiFullName:work@top.o
        |vpiActual:
        \_int_var: (work@top.o), line:52:23, endln:52:24, parent:work@top
      |vpiLowConn:
      \_ref_obj: (work@top.u_sub.c)
        |vpiName:c
        |vpiFullName:work@top.u_sub.c
        |vpiActual:
        \_int_var: (work@top.u_sub.c), line:41:27, endln:41:28, parent:work@top.u_sub
    |vpiGenScopeArray:
    \_gen_scope_array: (work@top.u_sub.gen_dio_attr[0]), line:45:41, endln:49:6, parent:work@top.u_sub
      |vpiName:gen_dio_attr[0]
      |vpiFullName:work@top.u_sub.gen_dio_attr[0]
      |vpiGenScope:
      \_gen_scope: (work@top.u_sub.gen_dio_attr[0]), parent:work@top.u_sub.gen_dio_attr[0]
        |vpiFullName:work@top.u_sub.gen_dio_attr[0]
        |vpiParameter:
        \_parameter: (work@top.u_sub.gen_dio_attr[0].k), line:45, parent:work@top.u_sub.gen_dio_attr[0]
          |UINT:0
          |vpiTypespec:
          \_int_typespec:
          |vpiLocalParam:1
          |vpiName:k
          |vpiFullName:work@top.u_sub.gen_dio_attr[0].k
        |vpiModule:
        \_module: work@prim_pad_attr (work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:46:6: , endln:48:31, parent:work@top.u_sub.gen_dio_attr[0]
          |vpiName:u_prim_pad_attr
          |vpiFullName:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr
          |vpiVariables:
          \_int_var: (work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.b), line:30:33, endln:30:34, parent:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr
            |vpiName:b
            |vpiFullName:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.b
            |vpiAutomatic:1
            |vpiVisibility:1
          |vpiParameter:
          \_parameter: (work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.PadType), line:32:25, endln:32:36, parent:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr
            |vpiTypespec:
            \_enum_typespec: (prim_pad_wrapper_pkg::pad_type_e), line:5:6, endln:5:16, parent:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.PadType
              |vpiName:prim_pad_wrapper_pkg::pad_type_e
              |vpiInstance:
              \_package: prim_pad_wrapper_pkg (prim_pad_wrapper_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:1:1: , endln:6:34, parent:work@top
              |vpiBaseTypespec:
              \_logic_typespec: , line:2:18, endln:2:23, parent:prim_pad_wrapper_pkg::pad_type_e
                |vpiInstance:
                \_package: prim_pad_wrapper_pkg (prim_pad_wrapper_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:1:1: , endln:6:34, parent:work@top
                |vpiRange:
                \_range: , line:2:25, endln:2:28
                  |vpiLeftRange:
                  \_constant: , line:2:25, endln:2:26
                    |vpiDecompile:2
                    |vpiSize:64
                    |UINT:2
                    |vpiConstType:9
                  |vpiRightRange:
                  \_constant: , line:2:27, endln:2:28
                    |vpiDecompile:0
                    |vpiSize:64
                    |UINT:0
                    |vpiConstType:9
              |vpiEnumConst:
              \_enum_const: (A), line:3:7, endln:3:8, parent:prim_pad_wrapper_pkg::pad_type_e
                |vpiName:A
                |UINT:0
                |vpiDecompile:3'h0
                |vpiSize:3
              |vpiEnumConst:
              \_enum_const: (B), line:4:7, endln:4:8, parent:prim_pad_wrapper_pkg::pad_type_e
                |vpiName:B
                |UINT:1
                |vpiDecompile:3'h1
                |vpiSize:3
            |vpiName:PadType
            |vpiFullName:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.PadType
          |vpiParamAssign:
          \_param_assign: , line:32:25, endln:32:36, parent:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr
            |vpiOverriden:1
            |vpiRhs:
            \_hier_path: (TargetCfg.dio_pad_type[0]), line:36:19, endln:36:26
              |vpiTypespec:
              \_struct_typespec: (pinmux_pkg::target_cfg_t), line:13:12, endln:13:18
              |vpiName:TargetCfg.dio_pad_type[0]
              |vpiActual:
              \_ref_obj: (TargetCfg), parent:TargetCfg.dio_pad_type[0]
                |vpiName:TargetCfg
              |vpiActual:
              \_bit_select: (dio_pad_type), parent:TargetCfg.dio_pad_type[0]
                |vpiName:dio_pad_type
                |vpiIndex:
                \_constant: , line:47:41, endln:47:42
                  |vpiDecompile:0
                  |vpiSize:64
                  |UINT:0
                  |vpiConstType:9
              |vpiExpr:
              \_operation: , line:58:18, endln:58:33
            |vpiLhs:
            \_parameter: (work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.PadType), line:32:25, endln:32:36, parent:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr
          |vpiTypedef:
          \_enum_typespec: (prim_pad_wrapper_pkg::pad_type_e), line:5:6, endln:5:16, parent:work@prim_pad_attr.PadType
          |vpiTypedef:
          \_import: (prim_pad_wrapper_pkg), line:31:11, endln:31:34
          |vpiDefName:work@prim_pad_attr
          |vpiDefFile:tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv
          |vpiDefLineNo:30
          |vpiPort:
          \_port: (b), line:30:33, endln:30:34, parent:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr
            |vpiName:b
            |vpiDirection:2
            |vpiHighConn:
            \_ref_obj: (work@top.u_sub.gen_dio_attr[0].c), line:48:27, endln:48:28
              |vpiName:c
              |vpiFullName:work@top.u_sub.gen_dio_attr[0].c
              |vpiActual:
              \_int_var: (work@top.u_sub.c), line:41:27, endln:41:28, parent:work@top.u_sub
            |vpiLowConn:
            \_ref_obj: (work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.b)
              |vpiName:b
              |vpiFullName:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.b
              |vpiActual:
              \_int_var: (work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.b), line:30:33, endln:30:34, parent:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr
          |vpiGenScopeArray:
          \_gen_scope_array: (work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic), line:34:4, endln:38:7, parent:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr
            |vpiName:gen_generic
            |vpiFullName:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic
            |vpiGenScope:
            \_gen_scope: (work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic), parent:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic
              |vpiFullName:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic
              |vpiModule:
              \_module: work@prim_generic_pad_attr (work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic.u_impl_generic) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:35:7: , endln:37:31, parent:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic
                |vpiName:u_impl_generic
                |vpiFullName:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic.u_impl_generic
                |vpiVariables:
                \_int_var: (work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic.u_impl_generic.a), line:22:41, endln:22:42, parent:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic.u_impl_generic
                  |vpiName:a
                  |vpiFullName:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic.u_impl_generic.a
                  |vpiAutomatic:1
                  |vpiVisibility:1
                |vpiParameter:
                \_parameter: (work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic.u_impl_generic.PadType), line:24:25, endln:24:36, parent:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic.u_impl_generic
                  |vpiTypespec:
                  \_enum_typespec: (prim_pad_wrapper_pkg::pad_type_e), line:5:6, endln:5:16, parent:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic.u_impl_generic.PadType
                    |vpiName:prim_pad_wrapper_pkg::pad_type_e
                    |vpiInstance:
                    \_package: prim_pad_wrapper_pkg (prim_pad_wrapper_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:1:1: , endln:6:34, parent:work@top
                    |vpiBaseTypespec:
                    \_logic_typespec: , line:2:18, endln:2:23, parent:prim_pad_wrapper_pkg::pad_type_e
                      |vpiInstance:
                      \_package: prim_pad_wrapper_pkg (prim_pad_wrapper_pkg::) tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv:1:1: , endln:6:34, parent:work@top
                      |vpiRange:
                      \_range: , line:2:25, endln:2:28
                        |vpiLeftRange:
                        \_constant: , line:2:25, endln:2:26
                          |vpiDecompile:2
                          |vpiSize:64
                          |UINT:2
                          |vpiConstType:9
                        |vpiRightRange:
                        \_constant: , line:2:27, endln:2:28
                          |vpiDecompile:0
                          |vpiSize:64
                          |UINT:0
                          |vpiConstType:9
                    |vpiEnumConst:
                    \_enum_const: (A), line:3:7, endln:3:8, parent:prim_pad_wrapper_pkg::pad_type_e
                      |vpiName:A
                      |UINT:0
                      |vpiDecompile:3'h0
                      |vpiSize:3
                    |vpiEnumConst:
                    \_enum_const: (B), line:4:7, endln:4:8, parent:prim_pad_wrapper_pkg::pad_type_e
                      |vpiName:B
                      |UINT:1
                      |vpiDecompile:3'h1
                      |vpiSize:3
                  |vpiName:PadType
                  |vpiFullName:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic.u_impl_generic.PadType
                |vpiParamAssign:
                \_param_assign: , line:24:25, endln:24:36, parent:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic.u_impl_generic
                  |vpiOverriden:1
                  |vpiRhs:
                  \_hier_path: (TargetCfg.dio_pad_type[0]), line:36:19, endln:36:26
                  |vpiLhs:
                  \_parameter: (work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic.u_impl_generic.PadType), line:24:25, endln:24:36, parent:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic.u_impl_generic
                |vpiTypedef:
                \_enum_typespec: (prim_pad_wrapper_pkg::pad_type_e), line:5:6, endln:5:16, parent:work@prim_pad_attr.PadType
                |vpiTypedef:
                \_import: (prim_pad_wrapper_pkg), line:23:11, endln:23:34
                |vpiDefName:work@prim_generic_pad_attr
                |vpiDefFile:tests/BitSelectOfParameterPassedToSubmoduleInGenForOfSubmodule/top.sv
                |vpiDefLineNo:22
                |vpiPort:
                \_port: (a), line:22:41, endln:22:42, parent:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic.u_impl_generic
                  |vpiName:a
                  |vpiDirection:2
                  |vpiHighConn:
                  \_ref_obj: (work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic.b), line:37:27, endln:37:28
                    |vpiName:b
                    |vpiFullName:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic.b
                    |vpiActual:
                    \_int_var: (work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.b), line:30:33, endln:30:34, parent:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr
                  |vpiLowConn:
                  \_ref_obj: (work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic.u_impl_generic.a)
                    |vpiName:a
                    |vpiFullName:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic.u_impl_generic.a
                    |vpiActual:
                    \_int_var: (work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic.u_impl_generic.a), line:22:41, endln:22:42, parent:work@top.u_sub.gen_dio_attr[0].u_prim_pad_attr.gen_generic.u_impl_generic

Fixed by #2483

authors: RRozak alaindargelas

repo: chipsalliance/Surelog


text:
registers/systemrdl: add I3C registers and RDL

And update parser and generator to support the more advanced formats.

Superseded by https://github.com/chipsalliance/caliptra-sw/pull/1697

source: gharchive/pull-request

repo: chipsalliance/caliptra-sw


text:
Update experimental-features.md

Fix copy-paste error.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@sequencer don't forget that 3.5.x is the published branch so we need to backport to have this show up

@Mergifyio backport 3.5.x

authors: CLAassistant gonsolo jackkoenig


text:
[build system] allow using pre-built emulator to run tests

This PR achieve these goals:

Add a nix derivation for verilator emulator, which can be cached by nix store and be reused across multiple runners.
Bump mill to 0.11.5 so that we can pre-fetch dependencies before build, and now all the sandbox option can be drop.
Update CI logic to generate wave file after test fail, so that our RTL dev can download and debug those failing tests.

This PR is now ready to be merged.


text:
Feature Request: Path/Header Variable Support in HTTP Integration

Hi!
I’d like to kindly suggest adding support for path variables in ChirpStack's HTTP integration, similar to how it's implemented in The Things Stack (docs).
For example, configuring the URL as:
https://example.com/webhook/{application_id}/{device_id}
should resolve dynamically based on metadata, e.g.,
https://example.com/webhook/app123/device456
This feature would:

Simplify integrations with systems requiring dynamic URLs.
Eliminate the need for middleware to route requests.
Ensure feature parity with other LoRaWAN platforms.

Thank you for considering this enhancement!

Simplify integrations with systems requiring dynamic URLs.

Could you provide a few examples?

Eliminate the need for middleware to route requests.

But in any case, you need a ChirpStack specific handler, as the payload is specified by ChirpStack. Thus the receiver must have a handler that understands this payload at the first place.

Thank you for your responses! Let me clarify some use cases:
Long-term storage of uplinks:
For our setup, we store uplinks in a bucket where each device (identified by its DevEUI) has its own folder. To achieve this, we currently need to parse every incoming uplink to extract the DevEUI and write the data to the appropriate device folder. With path variables (e.g., {dev_eui}), this logic could be entirely avoided, as the DevEUI could directly be part of the URL.
Different processing for applications:
Uplinks from different applications might require specific processing logic. For example, Application A's data could be transformed before storage, while Application B's data might trigger external workflows. Without a dynamic URL containing the Application ID (e.g., {application_id}), we are forced to parse and inspect each message manually to determine how it should be processed. Dynamic URL paths or even variable headers would eliminate this overhead by enabling direct routing.
Essentially, these features would simplify integrations by offloading routing and processing logic to the URL structure, allowing us to focus on handling the actual data rather than parsing and redirecting it.

repo: chirpstack/chirpstack


text:
ManagedClient ：Disconnect when message is received

When I use ManagedClient, I encounter a problem. When I receive a JSON message, ManagedClient disconnects. Is the message too long?
playload:
{
"StateList": [
{
"Type": "0",
"ID": "1093",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "1094",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "1095",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "1096",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "1097",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "1098",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "1099",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "1100",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "1101",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "1102",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "1103",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "1104",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "1105",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "1106",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "66",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "67",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "69",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "70",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "71",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "72",
"IsOnine": "true",
"Msg": ""
},
{
"Type": "0",
"ID": "73",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "74",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "75",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "76",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "77",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "78",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "79",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "80",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "81",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "82",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "83",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "84",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "85",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "86",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "87",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "88",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "89",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "90",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "91",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "92",
"IsOnine": "false",
"Msg": ""
},
{
"Type": "0",
"ID": "93",
"IsOnine": "true",
"Msg": ""
}
]
}

MqttClient: await TryProcessReceivedPacketAsync(packet, cancellationToken).ConfigureAwait(false);
throw "System.Threading.Tasks.TaskCanceledException"
MqttTcpChannel :await _stream.ReadAsync(buffer, offset, count, cancellationToken).ConfigureAwait(false); retrun 0

Hi, do you maybe send a new message via PublishAsync in the message handler? The message size is fine. It can also be much bigger.

@fengbozs Can you provide some example code, please?

I'm closing this due to inactivity. Feel free to re-open this if needed.

authors: SeppPenner chkr1011 fengbozs


text:
cannot connect to AWS IoT with certificate

When connecting to AWS Iot Core, the selected pfx certificate seems to not be used in the TLS options. When I made the following changes to set the cert and applicationProtocols, it started working:
MqttClientService.cs:
        clientOptionsBuilder.WithTls(o =>
        {
            o.SslProtocol = item.ServerOptions.SelectedTlsVersion.Value;
            o.IgnoreCertificateChainErrors = item.ServerOptions.IgnoreCertificateErrors;
            o.IgnoreCertificateRevocationErrors = item.ServerOptions.IgnoreCertificateErrors;
            o.CertificateValidationHandler = item.ServerOptions.IgnoreCertificateErrors ? _ => true : null;

            **if (!string.IsNullOrEmpty(item.SessionOptions.CertificatePath))
            {
                X509Certificate2Collection certificates = new()
                {
                    new X509Certificate2(item.SessionOptions.CertificatePath)
                };

                o.Certificates = certificates;
                o.ApplicationProtocols = new List<SslApplicationProtocol>() { new("mqtt") };
            }**
        });

Thanks for reporting the issue, I will integrate the fix and release a new version soon.


text:
Check static linking on Mac and Linux

Static linking of Clang and LLVM libraries is not easy, unfortunately. Clang uses zlib, ffi and other libraries. MacOSX SDK during compilation with these static libraries produces weird errors like redefinition of isnan, isinf or undefined type nullptr_t. Perhaps libclang-static-build has answers and a solution.

It's possible by using llvm as a submodule, implemented in separate branch.

It's possible by using llvm as a submodule, implemented in separate branch.


text:
RFP - JModelica

Checklist

[x] The package I am requesting does not already exist on https://chocolatey.org/packages;
[x] There is no open issue for this package;
[x] The issue title starts 'RFP - ';
[x] The download URL is public and not locked behind a paywall / login;

Package Details
Software project URL : https://jmodelica.org/
Direct download URL for the software / installer : https://jmodelica.org/downloads/JModelica.org-2.4.exe
Software summary / short description:  from their website:

JModelica.org is an extensible Modelica-based open source platform for optimization, simulation and analysis of complex dynamic systems.

Status: Review
https://chocolatey.org/packages/jmodelica

Status: Published
https://chocolatey.org/packages/jmodelica
Can be closed.

authors: Foadsf chtof


text:
(apache-httpd) htdocs folder is removed on uninstall

When Apache-httpd is uninstalled the htdocs folder is removed in the uninstall.
As a default, if there is content in the htdocs folder; the folder should not be removed during the uninstall process.
Expected
The htdocs folder should not have been removed on uninstall as there was content in the folder beyond the default index.html file and the apache icon file.
Actual
The htdocs folder was completely removed on uninstall

Please reopen, this is an important issue. The htdocs folder should not be removed.

The issues hanged 6 mo and it reached the end of life.  We can't have issues pilling up here without any activity on them.
Anybody can provide PR any time.

See 3.3 about issue expiration.

Does anyone ever really work on an issue that is an "enhancement" or "up for grabs" and has been closed?
Should we just pollute the issues by posting a new issue for this to ensure it's open and has a chance someone might work on it. That does not make a lot of sense to me.
I understand the policy, but the application of it clearly leaves a lot of things just hanging out in the wind to wither away.
I don't have the PowerShell knowledge or skills to deal with this issue, but it is a necessary one to be dealt with.

authors: majkinetor photodude

repo: chocolatey/chocolatey-coreteampackages


text:
Add protein prep test scripts and update various protein prep and docking functions

Description
There are some lingering issues with prepared models and some kinks to work out with some of the saving / loading, and I thought while I'm at it I could make some pared down testing scripts.
EDIT 2023.01.20
Unfortunately this has become my default working branch, making it full of many things.
Now it also hosts the scripts to re-run the SARS retrospective work.
Merge Problems
I somewhat stupidly merged the #94 and #99 branches into this PR, making it much longer and much more complicated than it needed to be.
Additionally, Ben added some nice seqres handling scripts here #116 which I would like to include in this branch.
So before this gets merged, probably these branches should be merged into main

[x] #94
[x] #99
[x] #116

Related issues

[x] #29
[x] #47
[x] #75
[x] #72

Todos
Notable points that this PR has either accomplished or will accomplish.

[x] test if save_openeye_pdb keeps the SEQRES record - it does!
[x] oechem.OEPlaceHydrogens in the modeling.mutate_residues function doesn't renumber the hydrogen atoms it adds, so if you stop after this step you will get wacky connect records (see below). I think this should be fixed somehow

this was previously seen in #66
[x] I think the to-do item here is to add a little function that takes care of this and include this function in all the pdb
[x] done here: https://github.com/choderalab/covid-moonshot-ml/pull/104/commits/36dba1390d3e5c74dfebd96a18283bca97374954
saving scripts:

 # Clean up PDB info after adding missing atoms
oechem.OEPerceiveResidues(mol, oechem.OEPreserveResInfo_ChainID | oechem.OEPreserveResInfo_ResidueNumber | oechem.OEPreserveResInfo_ResidueName)

[x] determine when / where the SEQRES record is getting lost
[x] recover the SEQRES record
[x] fix merge conflicts between #116 and this branch

done in: 1f5b568

[x] change output .pdb and .oedu files to have the full complex_id as the name of the file

done in: fa33816

[x] finish converting protein prep print statements to logger
[x] #119
[x] change parse_xtal to enable preparation of all fragalysis structures

Re-run SARS-CoV-2 Retrospective To-Dos

[x] re-dock 220 fragalysis P-structures against all others (40,000 complexes)

happening here: asap-datasets/retro_docking/sars_fragalysis_retrospective/20221202

[x] add multi-sdf openeye saving function
[x] add script to make sdf file with correct bond orders (using the SMILES) from the fragalysis data
[x] add ability in the run_docking_oe.py script to get compound id from the multi-ligand sdf file to circumvent needing the mcss pkl
[x] re-run protein prep functions on fragalysis p structures
[x] #111

Status

[x] Ready to go

mutated_test.pdb:
HETATM 5390  O   HOH W 576     -21.855  16.656 -18.645  1.00 53.40           O
HETATM    0  H1  HOH W 576     -22.385  17.451 -18.587  1.00 20.00           H
HETATM    0  H2  HOH W 576     -22.385  16.051 -19.164  1.00 20.00           H

CONECT 5390    0    0
CONECT    0 5390
CONECT    0 5390

Codecov Report

Merging #104 (a6e36ca) into main (da836ee) will decrease coverage by 0.00%.
The diff coverage is 0.00%.

:exclamation: Current head a6e36ca differs from pull request most recent head e2f32ac. Consider uploading reports for the commit e2f32ac to get more accurate results

@apayne97 Is this branch expected to be merged into main at some point?

Yes that is the goal!

I would like to get this merged finally so that I can do a better job of having a simple PR that just changes a few files for future tasks.

In the future we definitely want to avoid having such huge PRs, even though I understand sometimes this is not possible. But I think it will make things easier in the long term if we try to stick to more atomic/small changes for each PR.
@apayne97  It also seems that the title/description of this PR is no longer suited for it, can you please review it? Thanks!

@ijpulidos I'm currently skipping unit tests that we don't have support for using pytest.skip, however it seems like I need to add it at the beginning of the file (i.e. before module import) in order to avoid the failed openeye import. this makes flake unhappy because it means that some of the module imports are not at the top of the file. Please fix this however you see fit - I would like to keep the tests in for now and skip them until we can enable using openeye / input files as per #182

@JenkeScheen

there's been some jumping between naming, e.g. prepped_receptor_0.oedu and prepped_receptor.oedu. As I'm pulling from current whenever a dir symlink is updated with changed naming all my code breaks down (very fixable on-the-fly though), so we need to be careful to not jump around too much.

I've been trying to be careful about letting you know about naming changes (this one included)!

I see some RMSD benchmarking of pose predictions, do you have results of this anywhere worked out? happy to sync up on this as we need something like this for ASAP.
Not quite yet. We can sync sometime this week!

@ijpulidos I'm currently skipping unit tests that we don't have support for using pytest.skip, however it seems like I need to add it at the beginning of the file (i.e. before module import) in order to avoid the failed openeye import.

I think the best approach here is to write these tests with a better structure, not just being scripts but actual classes/functions/methods. That way we can skip the individual tests as needed without having to skip them at the module level.
@apayne97  I'll be doing the refactor for that to happen.

@JenkeScheen This looks good enough for me, your suggested changes should've been addressed already. Can you give this another quick look and approve if you think it is ok? Thanks!

authors: apayne97 codecov-commenter ijpulidos

repo: choderalab/asapdiscovery


text:
(#146) - Support for building el9 packages

(#146) added support for el9 packages to be built using a template of el8. Also added support for building el9 packages to the nightly build in the github workflow

I will do a follow up to update dependencies and move to go 1.21 which will be the minimum @gerrity95

Nightly build runs, we'll see how it goes tomorrow once its been all the way through and into the repos

repo: choria-io/stream-replicator


text:
Fixed Pen.Width handling for WP Plattforms

I have noticed that on Windows Phone, the pen width is handled in such a way that the complete ellipse fits into the specified Rect. This is different from the plattforms in NGraphics (I tested Android and iOS), in that the drawn ellipse on these plattforms will be larger than the Rect.
Although I like the way it is handled on WP better (because I can always be sure that my ellipse fits into my Rect), I think it should be changed to behave like the other plattforms for the sake of simplicity.
Feel free to use this PR for discussion on this topic - maybe it should instead be reported as an issue to NGraphics (i.e. treat the implementation in NControl as the correct one and it should be fixed for Android and iOS)?

Done.

authors: Henkoglobin chrfalch

repo: chrfalch/NControl


text:
Electrum 4.0.0a0, LN and EPS

Posting this here, had an issue with an electrum LN testing wallet, while using EPS. Was told I can't use LN with EPS.
https://github.com/spesmilo/electrum/issues/5786

Related: https://github.com/chris-belcher/electrum-personal-server/issues/174
Currently EPS does not support LN.

authors: Coinomatron NullSense

repo: chris-belcher/electrum-personal-server


text:
Problem with pinch zoom

Problem when I try to pinch image in ViewPager.

Is it possible to use Photoview in a single activity without Viewpager ,  I am getting array index out of bound exception while zooming for the same

          java.lang.ArrayIndexOutOfBoundsException: length=1; index=1
                                                 at android.support.v4.widget.ViewDragHelper.saveLastMotion(ViewDragHelper.java:849)
                                                 at android.support.v4.widget.ViewDragHelper.shouldInterceptTouchEvent(ViewDragHelper.java:1057)
                                                 at android.support.v4.widget.DrawerLayout.onInterceptTouchEvent(DrawerLayout.java:1434)
                                                 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2108)
                                                 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2555)
                                                 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2254)
                                                 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2555)
                                                 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2254)
                                                 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2555)
                                                 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2254)
                                                 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2555)
                                                 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2254)
                                                 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2555)
                                                 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2254)
                                                 at com.android.internal.policy.PhoneWindow$DecorView.superDispatchTouchEvent(PhoneWindow.java:2403)
                                                 at com.android.internal.policy.PhoneWindow.superDispatchTouchEvent(PhoneWindow.java:1737)
                                                 at android.app.Activity.dispatchTouchEvent(Activity.java:2775)

Take a look at the Readme or the sample

authors: Jawnnypoo SrishtiRoy kirich1409

repo: chrisbanes/PhotoView


text:
LazyList doesn't show the item defined by initialFirstVisibleItemIndex in LazyListState

Describe the bug
LazyList with snapper doesn't scroll to the item defined by initialFirstVisibleItemIndex.
To Reproduce
Steps to reproduce the behavior:
val lazyListState = rememberLazyListState(initialFirstVisibleItemIndex = 3)

val flingBehavior = rememberSnapperFlingBehavior(
    lazyListState = lazyListState,
    endContentPadding = contentPadding.calculateEndPadding(LayoutDirection.Ltr),
)

LazyRow(
    state = lazyListState,
    flingBehavior = flingBehavior
) {
    items(5) {
        // show item here
    }
}

Expected behavior
On the initial display (or first launch), the lazylist should auto-scroll to 3rd item. The lazylist shouldn't scroll after display but rather scroll to the correct initial item index before displaying.
Actual behavior
On initial display, the lazylist shows 1st item as the 1st visible item.
To work this issue around, I am using a side affect to scroll to the initial page when the screen is shown
val lazyListState = rememberLazyListState(initialFirstVisibleItemIndex = 3)

// workaround
LaunchedEffect(Unit) {
    lazyListState.animateScrollToItem(initialPage)
}

val flingBehavior = rememberSnapperFlingBehavior(
    lazyListState = lazyListState,
    endContentPadding = contentPadding.calculateEndPadding(LayoutDirection.Ltr),
)

LazyRow(
    state = lazyListState,
    flingBehavior = flingBehavior
) {
    items(5) {
        // show item here
    }
}

Screenshots?
If applicable, add screenshots to help explain your problem.
Environment:

Android OS version: 13
Device:  Google Pixel 4a
Library version: 0.2.2

Additional context
Add any other context about the problem here.

Not a lot we can do about this unfortunately. FlingBehaviors aren't notified about the initial scroll value, only deltas.
FYI @andkulikov

Hm, not sure I understood what exactly doesn't work for you.
So you set initialFirstVisibleItemIndex to 3, but in fact it displays item 0? It is not even related to flingBehavior, it should not ignore the initial index you provided. And are you sure that if you not set flingBehavior on such list it makes any difference?
Would be great if you can provide some screenshots. Thanks

I just tried and with initialFirstVisibleItemIndex = 3 and it does display item index 3, but not snapped.

Yes, that is expected. The same is true when you try to programmatically scroll via scrollTo/animateScrollTo. FlingBehavior is only run when the user is performing gestures via touch.
@iamutkarshtiwari is it what you meant?

I just tried and with initialFirstVisibleItemIndex = 3 and it does display item index 3

Interesting. In my case, it doesn't.
@chrisbanes did you do exactly as I did? I mean did you just initialize the lazyliststate as
val lazyListState = rememberLazyListState(initialFirstVisibleItemIndex = 3)

and you carousel was showing the 3 item on initial display?

authors: andkulikov chrisbanes iamutkarshtiwari

repo: chrisbanes/snapper


text:
Generate static calendar files

As @Jbithell commented in #3 it is better to create static files and publish those.
Closes #3

Looks really good! <3

authors: Jbithell chriscn

repo: chriscn/uoy-week-calendar


text:
ERROR: InexactError: trunc(Int64, Inf)

Here is a MWE:
function calc!(x)
    delta_fp = 2
    phase_fp = Int32(0)
    @avx for i = 1:length(x)
        phase_fp = phase_fp + delta_fp
        phase_int = phase_fp >> 17
        x[i] = phase_int
    end
end
x = Vector{Int32}(undef, 100)
calc!(x)

ERROR: InexactError: trunc(Int64, Inf)
Stacktrace:
 [1] trunc at ./float.jl:702 [inlined]
 [2] round at ./float.jl:367 [inlined]
 [3] unroll_no_reductions(::LoopVectorization.LoopSet, ::Array{Symbol,1}, ::Symbol, ::Int64, ::Int64) at /home/zorn/.julia/packages/LoopVectorization/9Qgzg/src/determinestrategy.jl:151
 [4] determine_unroll_factor(::LoopVectorization.LoopSet, ::Array{Symbol,1}, ::Symbol, ::Symbol) at /home/zorn/.julia/packages/LoopVectorization/9Qgzg/src/determinestrategy.jl:170
 [5] choose_order(::LoopVectorization.LoopSet) at /home/zorn/.julia/packages/LoopVectorization/9Qgzg/src/determinestrategy.jl:550
 [6] lower(::LoopVectorization.LoopSet, ::Int8) at /home/zorn/.julia/packages/LoopVectorization/9Qgzg/src/lowering.jl:497
 [7] avx_body(::Tuple{Int8,Int8,Int8}, ::Array{LoopVectorization.Instruction,1}, ::Array{LoopVectorization.OperationStruct,1}, ::Array{LoopVectorization.ArrayRefStruct,1}, ::Core.SimpleVector, ::Core.SimpleVector, ::NTuple{4,DataType}) at /home/zorn/.julia/packages/LoopVectorization/9Qgzg/src/reconstruct_loopset.jl:225

I'm closing this issue because:
julia> using LoopVectorization

julia> function calc!(x)
           delta_fp = 2
           phase_fp = Int32(0)
           @avx for i = 1:length(x)
               phase_fp = phase_fp + delta_fp
               phase_int = phase_fp >> 17
               x[i] = phase_int
           end
       end
calc! (generic function with 1 method)

julia> calc!(x)
200

julia> function calc2!(x)
           delta_fp = 2
           phase_fp = Int32(0)
           @avx for i = 1:length(x)
               phase_fp = phase_fp + delta_fp
               phase_int = phase_fp >> 17
               x[i] = phase_int
           end
       end
calc2! (generic function with 1 method)

julia> x2 = Vector{Int32}(undef, 100);

julia> calc2!(x2)
200

julia> x == x2
true

It still needs better support for mixing types.
Feel free to create an issue for that, if (e.g.) you want to try and convert between fixed and floating point.

authors: chriselrod zsoerenm


text:
New version

Could you release to latest changes as a new version on npm please? Just trying to get rid of deprecations.

+1

you mean this? I hadn't looked at the newest version but if it handles this I'm a +1 :-)
DEPRECATION: The initialize method for Application initializer 'ember-breadcrumbs' should take only one argument

any news?

+1
It seems like the changes are in, just need a new version rolled out.

Sorry for the huge delay – 0.1.8 is out.

Thanks!

:+1:

authors: carlbennettnz chrisfarber denchen haldiggs marceloandrader meliborn smvv

repo: chrisfarber/ember-breadcrumbs