Send PRs to partner project packages to enable API analyzer

We added a feature to the WebSDK to enable OpenAPI analyzers when a flag is present IncludeOpenAPIAnalyzers. We should send PRs to partner teams (e.g. NSwag) to enable this when their packages are referenced.

cc @glennc

@mkArtakMSFT adding this to the preview4 milestone as discussed in your sync up.

This can happen after Preview7 code complete date, before we actually ship.

The flag is now included in this PR: https://github.com/RicoSuter/NSwag/pull/2226


Moved the building AAD-secured API tutorial to a separate article

Category

[x] Content fix
[ ] New article
Related issues: n/a

What's in this Pull Request?
Moved the building AAD-secured API tutorial to a separate article

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/spfx/build-azure-ad-secured-api.md
:white_check_mark:Succeeded
View

docs/spfx/web-parts/guidance/connect-to-api-secured-with-aad.md
:white_check_mark:Succeeded
View

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

Need help  think my gf is using this to spy on me

Shall we close this PR as it's likely out of date?

Closing as outdated and conflicting change.


Provide automation of CSV <-> YAML conversion and validation

validation can be part of the conversion, so may not need to be executed separately

find . -name "*.yaml" | sort

./config.yaml
./data_validation/results/yaml/Component-001.yaml
./data_validation/results/yaml/Component-002.yaml
./data_validation/results/yaml/Component-003.yaml
./data_validation/results/yaml/Food-001.yaml
./data_validation/results/yaml/Food-002.yaml
./data_validation/results/yaml/Provenance-001.yaml
./examples/output/Container-Component-001.yaml
./examples/output/Container-Component-002.yaml
./examples/output/Container-Component-003.yaml
./examples/output/Container-Food-001.yaml
./examples/output/Container-Food-002.yaml
./examples/output/Container-Provenance-001.yaml
./.github/workflows/deploy-docs.yaml
./.github/workflows/main.yaml
./.github/workflows/pypi-publish.yaml
./project/prefixmap/mifc.yaml
./src/data/examples/invalid/Container-Food-001-illegal-primary-preservation.yaml
./src/data/examples/invalid/Container-Food-001-missing-component_id.yaml
./src/data/examples/valid/Container-Component-001.yaml
./src/data/examples/valid/Container-Component-002.yaml
./src/data/examples/valid/Container-Component-003.yaml
./src/data/examples/valid/Container-Food-001.yaml
./src/data/examples/valid/Container-Food-002.yaml
./src/data/examples/valid/Container-Provenance-001.yaml
./src/mifc/schema/mifc.yaml
./tmp/prefixmap/mifc.yaml

I don't see an CSVs

But I do see TSV s

I will take data_validation/test_data/*.tsv as inputs
I suspect that I will be deleting ./data_validation/*.sh and replacing the functionality with targets in project.Makefile

see also

https://github.com/orgs/linkml/discussions/1996


Support use with implementations and proxies from OpenZeppelin Contracts 4.x

Users may want to migrate from Hardhat to Foundry, and they may have contracts and/or proxies already deployed with OpenZeppelin Contracts 4.x.
This would include:

[x] Add support for 4.x UUPS implementations
[x] Add support for upgrading existing 4.x proxies

Note that we will probably not support deploying new 4.x proxies, but this feature will cover support for upgrading existing ones.
Originally requested in https://forum.openzeppelin.com/t/first-look-at-the-upcoming-openzeppelin-foundry-upgrades-library/38347/2

What is different from doing this ?
        vm.startBroadcast(deployPrivateKey);
        address implementation = address(new MyContract());
        console2.log(implementation);
        address proxy = address(new ERC1967Proxy(implementation, ""));
        MyContract myContract = MyContract(proxy);
        vm.stopBroadcast();

I believe both are using ERC1967Proxy contract from OZ, but the call from Upgrades.sol contract is more safe?
Also, here we are initializing a new proxy I believe ? How to use existing proxy with having to call prepareUpgrade which have as input a proxy address ?

prepareUpgrade is similar to address(new MyContractV2()); but it also validates the new implementation for upgrade safety as a prerequisite before deploying it.  In order for this to work, in MyContractV2, you should add an annotation to specify the previous version that it upgrades from.  See https://docs.openzeppelin.com/upgrades-plugins/1.x/api-core#define-reference-contracts
Here is an example of how you would then use prepareUpgrade and then upgradeTo on an existing proxy:
        Options memory opts;
        address newImpl = Upgrades.prepareUpgrade("MyContractV2.sol", opts);

        MyContract myContract = MyContract(myProxyAddress);
        myContract.upgradeTo(newImpl);

Can  OpenZeppelin/openzeppelin-foundry-upgrades  be installed with a specific version ?
My contracts are using<EMAIL_ADDRESS>which is incoherent with Upgrades.sol imports using ERC1976Utils, that are not in the Proxy package of<EMAIL_ADDRESS>

Right, this issue will need to be fixed in order for 4.x to be used with Upgrades.sol.
To upgrade without openzeppelin-foundry-upgrades, it would be like:
        address newImpl = address(new MyContract());
        MyContract myContract = MyContract(myProxyAddress);
        myContract.upgradeTo(newImpl);

We still recommend validating storage layout compatibility before upgrading.  You can do that using the validate command from the Upgrades CLI.

Note that we will probably not support deploying new 4.x proxies, but this feature will cover support for upgrading existing ones.

Hi there I wonder what is the rationale for this, I'm trying to deploy a new proxy with legacy upgrades and would like to add integration tests for that deployment. Is there a workaround for doing this with the current library?


Could some ops(assert,switch...) be removed in inference model ?

I want to convert faster-rcnn model to tensorRT, but these ops can't be converted,because invalid dtype or non data value, so I want to know how to solve the question.

This question is better asked on  StackOverflow since it is not a  bug or feature request. There is also a larger community that reads questions there. Thanks!


feat(modeler): c7 append element template

Issue

#138

Description
The append-anything plugin for element templates does not work for C7. The problem is the missing createElement() method. With this PR we add this method to the elementTemplate module and override the existing one with it.
Checklist

Code is easy to understand
No obvious errors or bugs
CI/CD Pipelines did run successfully
Tests were implemented
Documentation was created

Codecov Report
Patch and project coverage have no change.

Comparison is base (54eb69f) 63.27% compared to head (87fddbe) 63.27%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #322   +/-   ##
=======================================
  Coverage   63.27%   63.27%
=======================================
  Files          14       14
  Lines         305      305
  Branches       40       40
=======================================
  Hits          193      193
  Misses         72       72
  Partials       40       40

Flag
Coverage Δ

unittests
63.27% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

In the Web Modeler though, all possible element-templates aka connectors are shown right away even, when the activity is not specified yet. In the Miranum IDE and Desktop Modeler you first of all need to specify the activity as service task before applying an element template.

❓Isn't this behavior dependent on the element template?
To achieve this I could just add "bpmn:Task" under appliesTo in my element template like below.
{
  ...
  "appliesTo": [
      "bpmn:Task"
  ],
  ...
}

In the Web Modeler though, all possible element-templates aka connectors are shown right away even, when the activity is not specified yet. In the Miranum IDE and Desktop Modeler you first of all need to specify the activity as service task before applying an element template.

Isn't this behavior dependent on the element template ❓ To achieve this I could just add "bpmn:Task" under appliesTo in my element template like below.
{
  ...
  "appliesTo": [
      "bpmn:Task"
  ],
  ...
}

Ah yes, you are absolutely right! 👍
Let's merge it then 🚀


, I'm using azure's openai api, how do I call gpt4o using azure's api from you?

Hi, your tutorials are really well done, I've been using Caption Helper recently, the interface is very intuitive, but I'm having trouble, I'm using azure's openai api, how do I call gpt4o using azure's api from you?

you can change gpt-interrogate then let the azure api to interrogate


dijkstra's Program in java

This Pull Request resolves Issue #700 and #702

Are there any updates or should we close the PR?

PR closed due to inactivity


How to change number of anchors? Is that possible?

Hello everyone, I want to change the number of anchors for model, eg. 10 anchor boxes for tiny-yolo and 15 anchor boxes for yolo. Is that possible and how can I do it? I've tried to modify some lines of the codes, but I always got shape error.

Not possible as the number of anchor boxes is designed as per the architecture ot the CNN, 9 for yolo3.
In yolo v3 detection happens at 3 stages of increasing scale / size and at each scale 3 boxes are predicted, hence 3x3= 9 boxes. That's why when you change the number of anchors tou get a size mismatch error.
Just curious, why do you want to change the number of anchor boxes?

Not possible as the number of anchor boxes is designed as per the architecture ot the CNN, 9 for yolo3.
In yolo v3 detection happens at 3 stages of increasing scale / size and at each scale 3 boxes are predicted, hence 3x3= 9 boxes. That's why when you change the number of anchors tou get a size mismatch error.
Just curious, why do you want to change the number of anchor boxes?

What if I want to design nn for multiple(>3) resolution? As far as I consider, there should be 3 scales in yolov3, can we use more scales?

Hi @abhay8051 , thanks for your reply. I know that yolov3 has 3 stages, but cannot we redesign it as 5 boxes for each stages (5x3) instead of (3x3)?
For your question: I'm trying to use tiny-yolo for sake of its speed and it has 6 anchor boxes, unlike yolov3. It looked not enough to generalize all the scales of objects in the dataset. So, I wanted to add some more anchor boxes.

Hi @abhay8051 , thanks for your reply. I know that yolov3 has 3 stages, but cannot we redesign it as 5 boxes for each stages (5x3) instead of (3x3)?
For your question: I'm trying to use tiny-yolo for sake of its speed and it has 6 anchor boxes, unlike yolov3. It looked not enough to generalize all the scales of objects in the dataset. So, I wanted to add some more anchor boxes.

This is possible. For scale, you need to propose resolutions in the yolo_body and merge them. In yolo_body we have 3 output, add more output for more possible scale.
For anchors, increase the number of anchors accordingly.However, you may need to start to change everything( at least code from kmean.py for number of clusters. Read yolo 2 for this part).

@lcltopismine  and @abhay8051 thank you both for your detailed explanations. those improved my insight for yolo architecture

Btw, I have just noticed a code line of yolo_loss function in model.py:
anchor_mask = [[6,7,8], [3,4,5], [0,1,2]] if num_layers==3 else [[3,4,5], [1,2,3]]
Is the final [1,2,3] correct, or should it be [0,1,2] ?

Btw, I have just noticed a code line of yolo_loss function in model.py:
anchor_mask = [[6,7,8], [3,4,5], [0,1,2]] if num_layers==3 else [[3,4,5], [1,2,3]]
Is the final [1,2,3] correct, or should it be [0,1,2] ?

I agree with you, I prefer to [0,1,2]


Multiple Metadata (Contract Modality)

Provide contract compatibility for multiple, simultaneous consumers - via a modality for multiple metadata schemas at once (for the same contract).
i.e. extension of nftmetadatakind to support multiple schemas.
TBD:
Configuration settings around Required, Optional, Default.

@RBYGLLS @deuszex Error excepted this has already been treated ?
https://github.com/casper-ecosystem/cep-78-enhanced-nft/pull/78

Correct @gRoussac this should be one of the issues that we discussed on multiple meetings that it is done. But be sure to wait on management to declare it so.

Closing this EPIC as the work has been deemed completed in the following ticket:
https://app.zenhub.com/workspaces/cep78-62f310b4981d7b002374a745/issues/gh/casper-ecosystem/cep-78-enhanced-nft/123


body class hold transition

First of all thank you for making this nice project. I have an issue on changing the body class..
in the head.php <body class="<?php echo $body_class; ?>"> i cant find where do i change it.. i want something like <body class="hold-transition skin-blue sidebar-mini">

You can either:

update $this->mBodyClass variable from controller (referenced from /application/core/MY_Controller)
update /application/views/_base/head.php and change the body class directly; but remember all pages will be affected by this method

thank you for the reply..


Scope educator permissions to homerooms

Educators should be able to see:

Their own homeroom
Other homerooms at the same grade level at their school
All homerooms, if they are a principal or district leader

@alexsoble: Another use case is for the ELL, special education, and resource teachers we met who said they support students across grade levels.
For now, maybe we can group these teachers similarly to the principal / admin level? Other ideas?
@jsgeiser: what do you think?

@marimuraki — I agree that we should group ELL, SPED, and resource teachers under the principal / admin level for right now. Let's build up the complexity of roles & permissions gradually rather than all at once.

That kind of grouping sounds good. Each special education/resource room teacher actually services only two grade levels (1-2, 3-4, 5-6, 7-8). The ESL teachers have a wider span of grade levels. Also, some students see both special ed and ESL teachers (called "dually-identified students"). If they can pull students that they see as a whole group and by homeroom, that would be helpful I think.

Done for teachers, but we need a grade-level view for them to replace the dropdown. #123
Done for admins.
More work needs to be done to scope the roles Jill mentions like ESL teachers, interventionists, SPED teachers and other educators who are not assigned to one homeroom/grade level. #179


Fix typo in gretil seed script

Fixes #223
Corrected the following typos:

From amaruzakatam to amaruzatakam
From bodhicAryAvatAraH to bodhicaryAvatAraH

Thank you!!


add "preview mode" for interactive rendering

would be useful to have on low-end devices and/or challenging scenes - reduce sample counts etc, ideally w/ max time-per-frame budget

In interactive mode, a preview is already shown in a window as the image progressively renders. This can be used in combination with the optix denoiser for extra noisy scenes to “get a sense” of what the final render will look like.
The max time-per-frame idea is a bit tricky, since per-frame render time is not known until after the image is rendered. (even one ray per pixel might take longer than the specified maximum amount of time)
I also don’t currently support rendering less than/more than one sample per pixel (that might need to happen first). I’ve been avoiding rendering less than/more than one sample per pixel, since that complicates segmentation exports, and if not done carefully, can also close the door for temporal-spatial denoising down the road.
So in short, I’ve thought about it, but the additional complexity vs potential benefits doesn’t seem worth the effort imo, at least not in the immediate future.


YOLOv8 pose

hey! i am working with yolov8pose-onnx-rknn. i don't have any experience before. Can you give me some sample as your YOLOv8--Segmentation when you have time to do.Thanks a lot!!!

I haven't looked into yolov8-pose yet. Maybe you can google other sources.


Scolling does not work on a MS precision touchpad.

Background
Starting with win8 Microsoft has started supported something it calls precision touchpads.  From what I understand this generates different events from the normal mouse scroll wheel.
Environment
I'm running windows 10 (on a surface book with precision touchpad) with atom 1.3.2.
Issue
Scrolling using the two finger gesture on the precision touchpad doesn't work.

I just got a new Dell Inspiron running Windows 10 with a precision touchpad. The two finger gesture does work for scrolling but it is a very slow in Atom editor windows (v 1.4.1). Much slower than Chrome, Android Studio, or native Windows apps. However the scroll speed is good in non-editor windows treeview, settings, etc.

Seems to be working now along with other similar issues i've had with some websites and the precision touchpad.  Not sure if it's a chrome(ium) fix, or a MS fix, or individual fixes to atom and chrome and individual websites.  In any case it's fixed.


Fixing redirect link to contributors chat room

Describe your problem and how to reproduce it:
The problem is when click on this link in /docs/how-to-setup-freecodecamp-locally.md directory to open
contributor's chat room link is not valid and go to 404 page.
Add a Link to the page with the problem:
Problem link here
Recommended fix, suggestions (how would you update it?):
I recommend to replace that link by this because the basic going to contributors channel.
If possible, add a screenshot here (you can drag and drop, png, jpg, gif, etc. in this box):
Image-1

Image-2

Thanks

Should be resolved in #40806

So should i close my pr ?


current_database should return live info rather than input parameter

Since a connection can be created with the user's default database, or from a session_id, the self.db_name is not always accurate. Can we change the current_database function to get the database from the session_info as below?
return self.con._client.get_session_info(self.con._session).database

https://github.com/omnisci/ibis-omniscidb/blob/d38992d9268a7eaffe2ba6163b48e1043d34a8c2/ibis_omniscidb/client.py#L1215

resolved by #32


Confused with Common Settings for Event Hub

In the step 6 of Instructions, a link should be add to deploy a new event hub if the user does not have one.
The step

List of event hubs - event hub ENTITIES find Event Hubs list the event hubs from which you'd pull events e.g. "insights-logs-networksecuritygroupevent,insights-logs-networksecuritygrouprulecounter".

confused me that I thought insights-logs-networksecuritygroupevent,insights-logs-networksecuritygrouprulecounter is a single event hub, not two separate event hubs insights-logs-networksecuritygroupevent and insights-logs-networksecuritygrouprulecounter.

#28


Overflowed columns should be summarized

Get the column width. If there are too many column then summarize them below the data.

closed with #27


Use specific PyRef where possible - code object/type_new_class

Following on from my previous PRs, this removes unnecessary uses of PyObjectRef in type_new_class function and in the areas around the code/frame object.

Codecov Report

Merging #740 into master will decrease coverage by 0.24%.
The diff coverage is 52.71%.

@@            Coverage Diff             @@
##           master     #740      +/-   ##
==========================================
- Coverage   44.69%   44.44%   -0.25%
==========================================
  Files          81       81
  Lines       16390    16459      +69
  Branches     4089     4108      +19
==========================================
- Hits         7326     7316      -10
- Misses       7275     7377     +102
+ Partials     1789     1766      -23

Impacted Files
Coverage Δ

vm/src/stdlib/types.rs
0% <0%> (ø)
:arrow_up:

vm/src/pyobject.rs
56.1% <0%> (-0.74%)
:arrow_down:

vm/src/stdlib/json.rs
57.6% <100%> (ø)
:arrow_up:

vm/src/obj/objtype.rs
47.53% <25%> (+1.53%)
:arrow_up:

vm/src/frame.rs
46.31% <40%> (-0.37%)
:arrow_down:

vm/src/sysmodule.rs
35.29% <40%> (-26.38%)
:arrow_down:

vm/src/obj/objfunction.rs
47.69% <50%> (+4.14%)
:arrow_up:

vm/src/vm.rs
50% <60%> (-2.29%)
:arrow_down:

vm/src/stdlib/dis.rs
46.15% <60%> (-12.18%)
:arrow_down:

vm/src/obj/objcode.rs
38.88% <60.86%> (-1.33%)
:arrow_down:

... and 12 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a156010...6eb93a7. Read the comment docs.


Generation Time

How long does it cost to generate a 3d model?

It takes about ~30min for DreamFusion/Magic3D and ~15min for Latent-NeRF, SJC and Fantasia3D (geometry). All measured on a single RTX3090 with batch size 1 for 10000 iterations.

which one produces the best result btw?

I would say dreamfusion-if and magic3d-if. The two perform differently, you could try both.

thx a lot!

I hope it supports output as 3d model(fbx or obj etc) files. Is that available?

On it 👨🏻💻 This is a high-priority feature!

Can we train it off of other 3D models/pictures?

Do you mean if we can input a 3D model and get refined appearances/geometry on top of it?

@sekkit
Hi! We now support exporting meshes! See here for more details.

Wow!!!!!!!!!!!!!!!!!! thx.


feat: persisted operations

Resolves #35
This adds a way to adopting persisted-operations within fuse, this leverages an exchange to take the pre-computed documentId from the document and sends it for mutations/queries. When we see queries the exchange will cast this to a GET operations to improve browser cache-ability of operations.
This is focussed currently on the Next.js way where we have our datalayer co-located with our front-end. This does not facilitate mobile/... clients yet, to do so we might need to expand the options of our route-handler to fetch persisted hashes from a Key-value store. We could facilitate pushing to i.e. Redis/... in a CLI and then configure our GraphQL endpoint to pull from there when a hash comes in.
Something that I would still like to improve here is the fact that you need to manually pass in the .json file. I was thinking that this could maybe be a fairly automatic adoption journey where you are opted into this automatically and need to opt-out explicitly.
Would be eager to hear peoples thoughts here
Personally I gravitate towards supporting a K/V store like Redis, ... or the JSON file for the simple case where we only have i.e. a co-located Next.JS application 😅 added an example how it could look like with vercel/kv

One downside here is that our codegen relies on the server running which could be a cascading effect when you import the persisted operations json but it doesn't exist yet 😅

Closing this for the time being


*certauth module on v1.8.2 with LibreSSL 3.2.2: GetKey() returned status 20 with key 3207a6f22e0fde7c0781b8d0b78dfa15126595b7

Hello, it seems that on znc v1.8 certauth module is broken. It cant get certificate sent by clients.
This GetKey() function returns status 20.
Also, I’m using LibreSSL 3.2.2.
Built ZNC with it and generated certificate with it too.
I’m running on Gentoo for you to get the build environment.
I looked a little on sources and it comes from https://github.com/znc/znc/blob/6cd80535c064e91155468e79f50fc1c3f3c0f3e5/modules/certauth.cpp#L221
Some debug logs:
[2020-11-07 01:17:52.632195] _LISTENER == ConnectionFrom(2a00:5881:4008:4210:7c38:4a33:c6a4:22b9, 45668) [Allowed]
[2020-11-07 01:17:52.632487] There are [0] clients from [2a00:5881:4008:4210:7c38:4a33:c6a4:22b9]
[2020-11-07 01:17:52.767556] (2a00:5881:4008:4210:7c38:4a33:c6a4:22b9) CLI -> ZNC [PASS password]
[2020-11-07 01:17:52.767725] (2a00:5881:4008:4210:7c38:4a33:c6a4:22b9) CLI -> ZNC [CAP LS 302]
[2020-11-07 01:17:52.767812] (2a00:5881:4008:4210:7c38:4a33:c6a4:22b9) ZNC -> CLI [:irc.znc.in CAP unknown-nick LS :batc
h cap-notify echo-message multi-prefix server-time userhost-in-names znc.in/batch znc.in/self-message znc.in/server-time
-iso]
[2020-11-07 01:17:52.768057] (2a00:5881:4008:4210:7c38:4a33:c6a4:22b9) CLI -> ZNC [NICK quentin]
[2020-11-07 01:17:52.768198] (2a00:5881:4008:4210:7c38:4a33:c6a4:22b9) CLI -> ZNC [USER caseof/geeknode 0 * :caseof/geek
node]
[2020-11-07 01:17:52.768780] (2a00:5881:4008:4210:7c38:4a33:c6a4:22b9) CLI -> ZNC [CAP REQ :cap-notify multi-prefix serv
er-time znc.in/server-time-iso znc.in/self-message]
[2020-11-07 01:17:52.768876] (2a00:5881:4008:4210:7c38:4a33:c6a4:22b9) ZNC -> CLI [@time=2020-11-07T00:17:52.768Z :irc.z
nc.in CAP quentin ACK :cap-notify multi-prefix server-time znc.in/server-time-iso znc.in/self-message]
[2020-11-07 01:17:52.769220] (2a00:5881:4008:4210:7c38:4a33:c6a4:22b9) CLI -> ZNC [CAP END]
[2020-11-07 01:17:52.769282] GetKey() returned status 20 with key 3207a6f22e0fde7c0781b8d0b78dfa15126595b7
[2020-11-07 01:17:52.769312] User: caseof Key:
[2020-11-07 01:17:52.769340] Peer got no public key, ignoring

GetKey() returned status 20 with key 3207a6f22e0fde7c0781b8d0b78dfa15126595b7

The above comes from here:
https://github.com/znc/znc/blob/0af3c4b234b7839bb1162e74b01b66e1a05e6fa1/modules/certauth.cpp#L221-L237
where GetKey is here:
https://github.com/jimloco/Csocket/blob/e8d9e0bb248c521c2c7fa01e1c6a116d929c41b4/Csocket.cc#L2875-L2905
Okay, so SSL_get_verify_result returned 20. According to https://www.openssl.org/docs/man1.0.2/man1/verify.html, that's:

20 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY: unable to get local issuer certificate
the issuer certificate could not be found: this occurs if the issuer certificate of an untrusted certificate cannot be found.

That error is not one of those that is ignored by certauth in the code I linked above.
@CaseOf Could you print the subject and issuer of your certificate? I would guess that your certificate is not properly self-signed, because I would expect the error X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT. So, somehow your certificate does not count as self-signed...?

Hi, here is the certificate I used (dont worry, it’s removed from my *certauth list now).
It’s in PEM format.
-----BEGIN CERTIFICATE-----
MIIEoDCCAogCCQC1yqd69UFylDANBgkqhkiG9w0BAQsFADASMRAwDgYDVQQDDAdD
YXNlX09mMB4XDTIwMDYyMTAwNDMwMloXDTMwMDYxOTAwNDMwMlowEjEQMA4GA1UE
AwwHQ2FzZV9PZjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBALBKmo/M
tndPSW6Ys30ewOP1zZFGvacUlMzcDXBNxsORf28lK/x8OSOzo5hL7iVWXRNraqgK
0P2QvUYXGygiPHTdlFinjQS7uHiLhoC+Eh3BoS6vF4bAzd8MKgBxNu2Qy7o7bH0B
ESOtbVTjNfOBlyhlCsYKUOBkzUt0IGNz6AqW+PuAJPWfPz0uRiBg74Fan5tDvDy1
RCClv6Pc4X3zAApWJxL3r05fG8J55aaR/56IujVxOZyHfMxyUdFVdKxxNdMKf+66
dB3BoqTzq7u/yZ+nlEwHUsbJVsghqy8Xo1cC7rdeorIBtwipRJTD2hQ+Ivpt5DY1
u6jxFDkto7veVEH+V0VY4nk3TfeRSz14u+tjgNFBf5SFRdVKgPQuTGVnSvFTNiiY
aQmym332oS6gCHjSARcZn+XSDF4FIMIkzjpXLoF8Sk57qN0lIk3mmFlxw82/QT4g
FSlcSvMqTbrvsmjXUAMnqdIuJ2BaXOWEUKHyqXMcfBn05yIwa1K41SP85aN+KJMF
aBSheBAKdGyCD8UqgiHo44n+DqQzmAWVCiMWBbZg011ODWq27vrrq0j6n57lKsd+
i2t8BRBd5A4qKbfIRtuktWmEihyYlncoFxsNDjermM866KGEO9hQAqoVnN7Z98gq
Mwy3dM3oTcA2jRl7lFC/jtXWyHd1EP7HrCRfAgMBAAEwDQYJKoZIhvcNAQELBQAD
ggIBAC1y+Fs6SepQ5SbFt52B9DhuCLE7jat6ZFaJIgGy6n8uQKkkC1DKMopApuas
TOpJs/yfnjcMCi9ZYfoOmBZ/HRxddtAHikLLdI8RLQAZm3o/HWkF9HflS1OBaFuw
bUv7YGqUt8jCk9Nt2Z7YwgbEeDAv0y3RtDqz8Qkz2yMaPL6I+5rj06Do7fZ9Z7Ul
6nBP76/hAG/YrSdTW/r9E7Gv/uaZaeFQqFQLVgjKKeKEp027hvDu2eB08vrgtpPG
zXAv2g6fTUacFnHyxNWaZYzavCAm8m107JmVa4ThptACFXNgsHKbKqoqy7J5ONrt
B+RKK9KgtyCSfXqlva1rbxtiZwb1+SbPdgUcnEJBGhrwf7T8CPjmOwdYHJimf2So
8KgjtzZroqQOhx+MX1+Jq/Ubwrf5b/04Q3IEQB5EFFzzGGH9x/h3QIELQUvov7DZ
hmRA5PNeMx8uCLrNijzRgqnZhq4M28j6v0+89SMzvI2nmvsWhlXw2siE2CtbHHj6
bsAjED+M3/uiKKb6zqKxfs5DGk1YKokxR4FPfcCqPbTNRInmTiXNgceYteGEtOVu
WamYcMEHL/CqxuWn//x+QKDn7jlIlh7Fzox4tnynb+UXwiZlZA0cuBYIT+7qxy6C
Qdn5Lc1xu6xheqsQdNpuhpUax8yEq4YlpDPg3iI3UBsuE5TX
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
MIIJQQIBADANBgkqhkiG9w0BAQEFAASCCSswggknAgEAAoICAQCwSpqPzLZ3T0lu
mLN9HsDj9c2RRr2nFJTM3A1wTcbDkX9vJSv8fDkjs6OYS+4lVl0Ta2qoCtD9kL1G
FxsoIjx03ZRYp40Eu7h4i4aAvhIdwaEurxeGwM3fDCoAcTbtkMu6O2x9AREjrW1U
4zXzgZcoZQrGClDgZM1LdCBjc+gKlvj7gCT1nz89LkYgYO+BWp+bQ7w8tUQgpb+j
3OF98wAKVicS969OXxvCeeWmkf+eiLo1cTmch3zMclHRVXSscTXTCn/uunQdwaKk
86u7v8mfp5RMB1LGyVbIIasvF6NXAu63XqKyAbcIqUSUw9oUPiL6beQ2Nbuo8RQ5
LaO73lRB/ldFWOJ5N033kUs9eLvrY4DRQX+UhUXVSoD0LkxlZ0rxUzYomGkJspt9
9qEuoAh40gEXGZ/l0gxeBSDCJM46Vy6BfEpOe6jdJSJN5phZccPNv0E+IBUpXErz
Kk2677Jo11ADJ6nSLidgWlzlhFCh8qlzHHwZ9OciMGtSuNUj/OWjfiiTBWgUoXgQ
CnRsgg/FKoIh6OOJ/g6kM5gFlQojFgW2YNNdTg1qtu7666tI+p+e5SrHfotrfAUQ
XeQOKim3yEbbpLVphIocmJZ3KBcbDQ43q5jPOuihhDvYUAKqFZze2ffIKjMMt3TN
6E3ANo0Ze5RQv47V1sh3dRD+x6wkXwIDAQABAoICAE95go57YnMNGnSygJBSkfDy
+jaZJpyxKZflSGWtmoLGECYiIt9TfUr8DC93Y6gPdCxyC4YwQiFd5AY6GnMQZCLn
VZ5WArv0iOhHNl7J0U764Ngz9S45s1XvnOvQHkwhL8cITRNZrMlhwN05BTR+4o9C
ZgX71pQivW5brtJHCX/kqeBv17mnjhHdz51/Ndoh6bxMYAsaSNlS/782r61hJE6E
ol7prG1vcQtOetqKDSwCRbgcEDXh2sAsdXgix1OKQhKfNCeChSB5EAK/G1er0ZCZ
MsDHuGiHkgjtLMgxJuDuIIIoNr57CXHtJU7PsHvZu1kcu3o45R33eP+B9MOYKnFK
UZbPNj98VgtCGEHqOkjsi1lGKChyODqUvYqGjL00unP5azRjyLulCpb6Tlx9D8A9
wqjsWpWkOsPRuicp0MVRsY67UPHQ+Dahq6HbvGSEvzu8YokPdco2oDhEjhRQpEng
MfFZ4G224nSfzf3nfd6L7THL0GhkIdTOSM3PugJSZI+bm9eciwZsXjY7kkWvU+xV
RnFg1XDQcYRNH1bJQuG9m7sb1ZDQGqmDIqQgwtLn4+Z5NTaz9jPKTgIelKj0FIlF
WzyIWXORSoueshhj/EjThZuxWqU/LW9PMArx6Ygeg/JaYDJ8Q1mQtYol/IAKko4b
P1grO4zd2ILJvWxu3MWRAoIBAQDXQf43UO8Gp6vKksX2uF02Ii9yCdJRP9VJlZMm
GWGWOMse5fK5Q9zr5ZOyXGug30wqSuFfrlmZlqMEwmJHwcvIWtcZcO37PDb5IG3N
7kqFD5hjAw4jXG74toS/gLvyOfUzUIrUgNFMusXx4FmRgknqhUasqsJzJpCffWZS
NdJmGnB98UGfQkKvlZlP20/PJAP3cSr8clCuhuSoCyzq5pvNnASZtcQ8ZBrAa8eD
vb/m2e2CQ7tJITqtjOIaurXCZye7IyexnCV/JOa0l9IDPdrI23kNUg7FE5RkYKKg
Ae9cGwrFRdZ3Ta6tjljl3VkpHM5t8pWTCXq0ewqbwJpYjTo3AoIBAQDRqI0tvfMC
19g0YsW6oKwFJUF0OaDx09vc+h2PEFUAVw3L/zJal0BTalmDqC7Mw7vNDsQu8HKF
w2Rm1F0BHtfh8K4c8dqN1lG1fRVhoMJB+dNUpna+WqG5usqEShlMeHBGRd3KZc65
7cgPehRqABIOm4HEZICMDXxy+o5J1u/zf7h4nhaxJyeeVWe2+wNMHfhHkapBaQ5a
EoihjZehZiAtQOLMTMoJTe/u670cgGxUf+UsstWuC9ekUTP3of9RDds4DTOX9oeJ
/bPC5diIq1sB6vSOgOv1d3wvDRvd8HB8EtEbJUO06Fl4ym++1vnBNa3OnihcsNFI
d6bUygkEu7MZAoIBAGHgIN44D6cgAC3o1Nic9c0SeC5LJvVIqAuAVlsheUzb4AfZ
mKcCo2Yjiie0fD+2qKQmThm6ZgU/CDq2xAdKqAUewOVRgvQUag6W3zaengWolKqY
jgooElFGdE+7EjpOfh5qBeYf+IsB9dVIJJHUAxX+qacDMc04ANR0KV1CGbvRU8sA
Ms1eTIIX7JDx8HUINEGDlH8a33Kr5TY/dpoMZ1VzFmhpzKOFBODvYNWXJrWp66Oq
dnMHB+43u+tZcCHH07n0fyz0CdypA7mjups8uclQeddDs3GKuJN3mRpWJubjaN9Q
JPc0PDOwIN3L6qmV7orxnW8xBTkhJS6ywbt347sCggEAfRJH5lnCdpe86sNhoYvo
Esm+2k7mrFzudEzhBU+A5csI+AEtUM2aGij/bYMPKCg8CIAemMHoD9QYOR/Gu7xi
nO6vb6T39FU+OT59WthECoe2gnErtTLr95hu56wsm2nd0I4tWWiSgmhPSKxTMUkJ
fJ1YNIigBuykqRK/f10xl9lBevMUJmptQA9C5+2mceoPCuLi5lJ9tU4JJBcLtcTu
vRBQPAAzJonP8H/BOReDiIUjeh7VShbWdbfbgIargPb7J9z4QldXVAJ9Em97VUyj
5ej8K2bNXIoDEy6GyUd+UwYGqGL6mRljBqP9NaOZKqGTJgdDnMf+kXSPmbFM3/35
QQKCAQB6pgLoAcgwSI4VV+cF4NvRvNrcIpSUWaEvHrUSuoLUUGO7aguvjtOQvq88
NxH1vySI7C3uLDk0O5Q+CwKYjcansi2rVac1gUjHDa3OlVAUdcRHXTZDvxphn0qC
UyNd0sNXe3UE/xSEcgxwUjuyWBXzXctB8Q01gks/n67nyy0pB9KHADVg4xHiBDRe
Knw06rUUQ9tUW0A85CK3e3UdHRmo0AO7l2d7o4G0saf+WnRJgHhegx+2QafYipDJ
Go0I4U0472oI23g9VDI1h4d46KJ9jCPce2m3M3x3Ao0P8MgRDy6ilVh2adgD41Hf
tllVSnX9etPIftqlIx4WNGPQ/PWF
-----END PRIVATE KEY-----

Else, from openssl command:
$ openssl x509 -text -noout -in znc.pem
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number:
            b5:ca:a7:7a:f5:41:72:94
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Case_Of
        Validity
            Not Before: Jun 21 00:43:02 2020 GMT
            Not After : Jun 19 00:43:02 2030 GMT
        Subject: CN=Case_Of
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    00:b0:4a:9a:8f:cc:b6:77:4f:49:6e:98:b3:7d:1e:
                    c0:e3:f5:cd:91:46:bd:a7:14:94:cc:dc:0d:70:4d:
                    c6:c3:91:7f:6f:25:2b:fc:7c:39:23:b3:a3:98:4b:
                    ee:25:56:5d:13:6b:6a:a8:0a:d0:fd:90:bd:46:17:
                    1b:28:22:3c:74:dd:94:58:a7:8d:04:bb:b8:78:8b:
                    86:80:be:12:1d:c1:a1:2e:af:17:86:c0:cd:df:0c:
                    2a:00:71:36:ed:90:cb:ba:3b:6c:7d:01:11:23:ad:
                    6d:54:e3:35:f3:81:97:28:65:0a:c6:0a:50:e0:64:
                    cd:4b:74:20:63:73:e8:0a:96:f8:fb:80:24:f5:9f:
                    3f:3d:2e:46:20:60:ef:81:5a:9f:9b:43:bc:3c:b5:
                    44:20:a5:bf:a3:dc:e1:7d:f3:00:0a:56:27:12:f7:
                    af:4e:5f:1b:c2:79:e5:a6:91:ff:9e:88:ba:35:71:
                    39:9c:87:7c:cc:72:51:d1:55:74:ac:71:35:d3:0a:
                    7f:ee:ba:74:1d:c1:a2:a4:f3:ab:bb:bf:c9:9f:a7:
                    94:4c:07:52:c6:c9:56:c8:21:ab:2f:17:a3:57:02:
                    ee:b7:5e:a2:b2:01:b7:08:a9:44:94:c3:da:14:3e:
                    22:fa:6d:e4:36:35:bb:a8:f1:14:39:2d:a3:bb:de:
                    54:41:fe:57:45:58:e2:79:37:4d:f7:91:4b:3d:78:
                    bb:eb:63:80:d1:41:7f:94:85:45:d5:4a:80:f4:2e:
                    4c:65:67:4a:f1:53:36:28:98:69:09:b2:9b:7d:f6:
                    a1:2e:a0:08:78:d2:01:17:19:9f:e5:d2:0c:5e:05:
                    20:c2:24:ce:3a:57:2e:81:7c:4a:4e:7b:a8:dd:25:
                    22:4d:e6:98:59:71:c3:cd:bf:41:3e:20:15:29:5c:
                    4a:f3:2a:4d:ba:ef:b2:68:d7:50:03:27:a9:d2:2e:
                    27:60:5a:5c:e5:84:50:a1:f2:a9:73:1c:7c:19:f4:
                    e7:22:30:6b:52:b8:d5:23:fc:e5:a3:7e:28:93:05:
                    68:14:a1:78:10:0a:74:6c:82:0f:c5:2a:82:21:e8:
                    e3:89:fe:0e:a4:33:98:05:95:0a:23:16:05:b6:60:
                    d3:5d:4e:0d:6a:b6:ee:fa:eb:ab:48:fa:9f:9e:e5:
                    2a:c7:7e:8b:6b:7c:05:10:5d:e4:0e:2a:29:b7:c8:
                    46:db:a4:b5:69:84:8a:1c:98:96:77:28:17:1b:0d:
                    0e:37:ab:98:cf:3a:e8:a1:84:3b:d8:50:02:aa:15:
                    9c:de:d9:f7:c8:2a:33:0c:b7:74:cd:e8:4d:c0:36:
                    8d:19:7b:94:50:bf:8e:d5:d6:c8:77:75:10:fe:c7:
                    ac:24:5f
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha256WithRSAEncryption
         2d:72:f8:5b:3a:49:ea:50:e5:26:c5:b7:9d:81:f4:38:6e:08:
         b1:3b:8d:ab:7a:64:56:89:22:01:b2:ea:7f:2e:40:a9:24:0b:
         50:ca:32:8a:40:a6:e6:ac:4c:ea:49:b3:fc:9f:9e:37:0c:0a:
         2f:59:61:fa:0e:98:16:7f:1d:1c:5d:76:d0:07:8a:42:cb:74:
         8f:11:2d:00:19:9b:7a:3f:1d:69:05:f4:77:e5:4b:53:81:68:
         5b:b0:6d:4b:fb:60:6a:94:b7:c8:c2:93:d3:6d:d9:9e:d8:c2:
         06:c4:78:30:2f:d3:2d:d1:b4:3a:b3:f1:09:33:db:23:1a:3c:
         be:88:fb:9a:e3:d3:a0:e8:ed:f6:7d:67:b5:25:ea:70:4f:ef:
         af:e1:00:6f:d8:ad:27:53:5b:fa:fd:13:b1:af:fe:e6:99:69:
         e1:50:a8:54:0b:56:08:ca:29:e2:84:a7:4d:bb:86:f0:ee:d9:
         e0:74:f2:fa:e0:b6:93:c6:cd:70:2f:da:0e:9f:4d:46:9c:16:
         71:f2:c4:d5:9a:65:8c:da:bc:20:26:f2:6d:74:ec:99:95:6b:
         84:e1:a6:d0:02:15:73:60:b0:72:9b:2a:aa:2a:cb:b2:79:38:
         da:ed:07:e4:4a:2b:d2:a0:b7:20:92:7d:7a:a5:bd:ad:6b:6f:
         1b:62:67:06:f5:f9:26:cf:76:05:1c:9c:42:41:1a:1a:f0:7f:
         b4:fc:08:f8:e6:3b:07:58:1c:98:a6:7f:64:a8:f0:a8:23:b7:
         36:6b:a2:a4:0e:87:1f:8c:5f:5f:89:ab:f5:1b:c2:b7:f9:6f:
         fd:38:43:72:04:40:1e:44:14:5c:f3:18:61:fd:c7:f8:77:40:
         81:0b:41:4b:e8:bf:b0:d9:86:64:40:e4:f3:5e:33:1f:2e:08:
         ba:cd:8a:3c:d1:82:a9:d9:86:ae:0c:db:c8:fa:bf:4f:bc:f5:
         23:33:bc:8d:a7:9a:fb:16:86:55:f0:da:c8:84:d8:2b:5b:1c:
         78:fa:6e:c0:23:10:3f:8c:df:fb:a2:28:a6:fa:ce:a2:b1:7e:
         ce:43:1a:4d:58:2a:89:31:47:81:4f:7d:c0:aa:3d:b4:cd:44:
         89:e6:4e:25:cd:81:c7:98:b5:e1:84:b4:e5:6e:59:a9:98:70:
         c1:07:2f:f0:aa:c6:e5:a7:ff:fc:7e:40:a0:e7:ee:39:48:96:
         1e:c5:ce:8c:78:b6:7c:a7:6f:e5:17:c2:26:65:64:0d:1c:b8:
         16:08:4f:ee:ea:c7:2e:82:41:d9:f9:2d:cd:71:bb:ac:61:7a:
         ab:10:74:da:6e:86:95:1a:c7:cc:84:ab:86:25:a4:33:e0:de:
         22:37:50:1b:2e:13:94:d7

        Issuer: CN=Case_Of
        Subject: CN=Case_Of

Okay, I have no clue where that X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY comes from. This looks "obviously self-signed". However, I wouldn't claim that I fully understand this stuff, so perhaps someone else has an idea...
(Did I perhaps look up the error incorrectly?)

Your certificate is a self-signed certificate.  if the certificate is self-signed you will always get "Unable to get issuer cert locally" or similar invalids - this is the case with any Self Signed certificate.
There are cases this can be adjusted - internal Certificate Authority systems for instance will have the CA cert added to the system store and then added to the cert chain.  However, your system will error hard on that if it's self-signed.  Likely, LibreSSL is expecting a 'valid identity certificate'.  (Also, your key/cert lines are inverted - you need to have key and then cert I believe for the PEM to work anyways)

if the certificate is self-signed you will always get "Unable to get issuer cert locally" or similar invalids

@teward In that case: How does certauth work for anyone? That module explicitly ignores the "usual" errors, so something must be different with this cert. If verification would fail with X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN or X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT or X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE, everything would be fine.

Unless the error codes aren't properly handled.  However I think your key and cert are inverted in your PEM (most secret item comes first!) so I think you need to switch the order in your PEM file.  Because I think it's seeing it just as a bare cert not a private identity cert.
This said, I'm OpenSSL fluent in this, not LibreSSL fluent - so my statements are just statements

Hm. I tried to reproduce this using openssl s_client -cert /tmp/foo.pem -key /tmp/foo.pem -connect localhost:1234 and this works with the files that were provided above (current debian testing; only OpenSSL involved). (Yes, I had to type IRC commands to load certauth and have it add the certificate. I do not want to do this again. I miss backspace.)
(I just updated my system (there was an openssl update) and this still works.)

Hm. I tried to reproduce this using openssl s_client ...

Yes, I tested as well.  The problem I see here is that unlike Debian/Ubuntu and most systems which are OpenSSL driven, this bug specifically says LibreSSL is involved - which means that it is likely LibreSSL failing to process the certificate properly and returning the error; it's also possible this is Not A ZNC Problem technically if LibreSSL fails hard.

LibreSSL 3.2.2 has a new/replacement X.509 verifier that addresses a bunch of problems with the original OpenSSL based X.509 verifier. Unfortunately, there are loads of corner cases and particular API behaviour  (much of it undocumented) that various pieces of software depend on. We'll take a look at this - I suspect we're returning X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY where the previous verifier was failing in a different way. Thanks for providing the relevant details/code snippets from the znc side.

Yeah, sorry folks, the legacy validation API is pretty squirrelly, and some of the legacy errors actually don't make any sense when you actually chase down all possible chains.   Nevertheless I have a candidate fix and we should be able to have this thing feeding you back the legacy "self signed" errors in the relevant special cases very soon. Thanks for the report.

Of note -> "fail hard" is still fail. We still fail validation in this case, it's simply how you choose to interpret the error code (and yes I understand the awful legacy here that forces you to do that ;)


No fine-grained authz for role global_cert_issuer

Similar to the change https://github.com/Netflix/lemur/pull/4034, allow users with global_cert_issuer to skip fine grained domain authorization and issue certificate for any domain. This allows to have a subset of users who'll have admin equivalent of permissions only when it comes to issuing certificates.
One still needs to have CA level access, which is current lemur behavior.

Coverage: 62.346% (-0.03%) from 62.375% when pulling cde5d0c6857b01426e8c29bb3dd22ff04cca4747 on charhate:admin-issuer into fc8b844d1fa091206a95c53a488966d27ffc0516 on Netflix:master.


Upgrade packages and move to eslint

Remove old deprecated TSLint and move to ESLint.
As a newcomer to TypeScript, I'm not familiar with the tools. Trying to run the code from this repository led to package dependency problems, probably caused by newer version of TypeScript conflicting the maximum supported versions of TypeScript compatible with the TSLint system. With this PR I tried to move to ESLint instead with the same, mostly default configuration, update some other packages, and solve some minor linting issues at once.

By merging something in the main branch of the fork, changes also got introduces in the PR when they shouldn't. I'll try creating an new PR with the correct set of changes.


Fix overriding a rule with a disable one

If we want to disable a rule from an inherited set of rules through overriding it in the child ruleset (*) the disabled rule is not created but the rule from the parent is left on the set of active rules.
Example:
require: default
rules:
    - name: openapi-tags-alphabetical
      disabled: true

(openapi-tags-alphabetical is defined in default)
This fix this situation by deleting the rule (if exists) from the set of active rules if the most specific rule is declared as disabled.
I took the liberty to add a deprecation message with an estimated version in which the enabled property would be removed. I can revert it if you think that it is not necessary.
The lines range 16-22 should be removed when enabled is deleted.
(*): Another option would be using skip but I think this option more like a temporal option used under some situation while you develop. Having it disabled in the ruleset is more organized (and, for example, you can leave a comment why you are disabling it).

@djtarazona Could you have a look at this PR and merge it if it's ok?
Additionally, I have 2 other open PR (#278 and #269) that would be great if you could have a look at them.
Thanks in advance!

@mdaloia Feel free to resolve the conflicts and I'll take another look at merging this in. Thanks!

@djtarazona Done! Fixed and rebased with master. Thanks


EnsembleGPUKernel + Texture Memory Support

@ChrisRackauckas @utkarsh530
Per our conversation here is an example demonstrating how texture memory interpolation could be use.
I would like to be able to leverage CUDA.jl's texture memory support for interpolation of data in the EOM and/or in a callback. A use case could be dropping a ball in a wind field with ground impact termination for a non-flat terrain. Here, one would want to interpolate the wind field as a function of state in the eom as a forcing term and an elevation map as a function of altitude.
Below is an initial prototype. This includes a CPU implementation that leverages DataInterpolations.jl to demonstrate the functionality desired using this data forecast.txt I also included an initial non-working prototype using texture memory.
No interpolation
Working model for CPU and GPU w/o interpolation
using CUDA, DiffEqGPU, OrdinaryDiffEq, Plots, Serialization, StaticArrays, Distributions, LinearAlgebra
import DataInterpolations
const DI = DataInterpolations

# Ballistic model
function ballistic(u, p, t, weather)
    CdS, mass, g = p
    vel = @view u[4:6]

    wind, ρ = get_weather(weather, u[3])

    airvelocity = vel - wind
    airspeed = norm(airvelocity)
    accel = -(ρ * CdS * airspeed) / (2 * mass) * airvelocity - mass*SVector{3}(0f0, 0f0, g)

    return SVector{6}(vel..., accel...)
end

# constant wind and airdensity.
function get_weather(weather, z)
    wind = SVector{3}(1f0, 0f0, 0f0)
    ρ = 1.27f0
    wind, ρ
end

trajectories = 100
u0 = @SVector [0.0f0, 0.0f0, 10000.0f0, 0f0, 0f0, 0f0]
tspan = (0.0f0, 50.0f0)
saveat = LinRange(tspan..., 100)
p = @SVector [25f0, 225f0, 9.807f0]
CdS_dist = Normal(0f0, 1f0)

eom_nowind = (u, p, t) -> ballistic(u,p,t,nothing)
prob = ODEProblem{false}(eom_nowind, u0, tspan, p)
sol = solve(prob, Tsit5())

prob_func = (prob, i, repeat) -> remake(prob, p = p + SVector{3}(rand(CdS_dist), 0f0, 0f0))
eprob = EnsembleProblem(prob, prob_func = prob_func, safetycopy = false)

esol = solve(eprob, Tsit5(); trajectories, saveat)
esol_gpu = solve(eprob, GPUTsit5(), EnsembleGPUKernel(); trajectories, saveat)

DataInterpolations.jl CPU Example
This demonstrates the basic capability I would like to replicate in w/ EnsembleGPUKernel using CUDA.CuTexture
# Ballistic w/ Interpolated winds via DataInterpolations.jl
data = deserialize("forecast.txt")
N = length(data.altitude)

weather_sa = map(data.altitude, data.windx, data.windy, data.density) do alt, wx, wy, ρ
    SVector{4}(alt, wx, wy, ρ)
end

interp = DI.LinearInterpolation(weather_sa,data.altitude)

function get_weather(itp::DI.LinearInterpolation, z)
    weather = itp(u[3])
    wind = SVector{3}(weather[2], weather[3], 0f0)
    ρ = weather[4]
    wind, ρ
end

eom_di = (u,p,t) -> ballistic(u,p,t,interp)
prob = ODEProblem{false}(eom_di, u0, tspan, p)
sol = solve(prob, Tsit5())

prob_func = (prob, i, repeat) -> remake(prob, p = p + SVector{3}(rand(dist), 0f0, 0f0))
eprob = EnsembleProblem(prob, prob_func = prob_func, safetycopy = false)
esol = solve(eprob, Tsit5(); trajectories, saveat)

GPU Texture Interpolation Validation
Demonstrate usage of CuTexture for interpolation. Note, here I index into the texture memory by broadcasting over a  CuArray{Float32} of indices via dst_gpu .= getindex.(Ref(texture), idx_tlu)
weather = map(weather_sa) do w
    (w...,)
end

weather_TA = CuTextureArray(weather)
texture = CuTexture(weather_TA; address_mode = CUDA.ADDRESS_MODE_CLAMP, normalized_coordinates = true, interpolation = CUDA.LinearInterpolation())

## Test Texture interpolation
idx = LinRange(0f0, 1f0, 4000)
idx_gpu = CuArray(idx)
idx_tlu = (1f0-1f0/N)*idx_gpu .+ 0.5f0/N  # normalized table lookup form https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#table-lookup
dst_gpu = CuArray{NTuple{4, Float32}}(undef, size(idx))
dst_gpu .= getindex.(Ref(texture), idx_tlu)  # interpolation ℝ->ℝ⁴

begin
    p1 = scatter(data.altitude, data.altitude, ylabel = "Altitude", label = "Raw", ms = 2, marker = :x)
    plot!(idx*data.altitude[end], getindex.(dst_cpu, 1), label = "Texture",lw = 2)

    p2 = scatter(data.altitude, data.windx, ylabel = "Wind X", label = "Raw", ms = 2, marker = :x, leg = false)
    plot!(idx*data.altitude[end], getindex.(dst_cpu, 2), label = "Texture",lw = 2)

    p3 = scatter(data.altitude, data.windy, ylabel = "Wind Y", label = "Raw", ms = 2, marker = :x, leg = false)
    plot!(idx*data.altitude[end], getindex.(dst_cpu, 3), label = "Texture",lw = 2)

    p4 = scatter(data.altitude, data.density, ylabel = "Density", label = "Raw", ms = 2, marker = :x, leg = false)
    plot!(idx*data.altitude[end], getindex.(dst_cpu, 4), label = "Texture",lw = 2)

    plot(p1, p2, p3, p4, link=:x, xlabel = "Altitude")
end

EnsembleGPUKernel + CuTexture prototype
Non-working prototype. Note here the get_weather function is indexing the texture at a single index for a single trajectory which isn't supported by CUDA.jl. Although this is scalar indexing it should actually be occurring for each trajectory in the ensemble.
function get_weather(tex::CuTexture, z, zmax = data.altitude[end], N = length(data.altitude))
    idx = (1f0-1f0/N)*z/zmax + 0.5f0/N # normalized input for table lookup based on https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#table-lookup
    tex[idx]
end

eom_tex = (u,p,t) -> ballistic(u,p,t,texture)
prob = ODEProblem{false}(eom_tex, u0, tspan, p)
prob_func = (prob, i, repeat) -> remake(prob, p = p + SVector{3}(rand(dist), 0f0, 0f0))
eprob = EnsembleProblem(prob, prob_func = prob_func, safetycopy = false)
esol_gpu = solve(eprob, GPUTsit5(), EnsembleGPUKernel(); trajectories, saveat) #InvalidIR

ContinousCallback Prototype
The above example only does interpolation in the eom. However, interpolation could also occur in evaluating a callback. e.g. something like this
terrain_texture = CuTexture(...)  # ℝ² -> ℝ, map xy position to ground elevation

condition(u,t,integrator) = u[3] - terrain_texture[@view u[1:2]]. # check height above elevation
cb = ContinuousCallback(condition, terminate!)

This looks great!

The texture interpolation results should like this

EnsembleGPUKernel + DataInterpolations.jl
As a first attempt to try out interpolation within GPU ODE solves, I got the MWE working with EnsembleGPUKernel + DataInterpolations.jl.

using CUDA, DiffEqGPU, OrdinaryDiffEq, Plots, Serialization, StaticArrays, Distributions, LinearAlgebra
import DataInterpolations
const DI = DataInterpolations

## CPU Working Example

# Ballistic model

function ballistic(u, p, t, weather)
    CdS, mass, g = p
    vel = @view u[4:6]

    wind, ρ = get_weather(weather, u[3])

    airvelocity = vel - wind
    airspeed = norm(airvelocity)
    accel = -(ρ * CdS * airspeed) / (2 * mass) * airvelocity - mass*SVector{3}(0f0, 0f0, g)

    return SVector{6}(vel..., accel...)
end

trajectories = 100
u0 = @SVector [0.0f0, 0.0f0, 10000.0f0, 0f0, 0f0, 0f0]
tspan = (0.0f0, 50.0f0)
saveat = LinRange(tspan..., 100)
p = @SVector [25f0, 225f0, 9.807f0]
CdS_dist = Normal(0f0, 1f0)

# Ballistic w/ Interpolated winds via DataInterpolations.jl

data = deserialize("forecast.txt")
N = length(data.altitude)

weather_sa = map(data.altitude, data.windx, data.windy, data.density) do alt, wx, wy, ρ
    SVector{4}(alt, wx, wy, ρ)
end

weather_sa = SVector{length(weather_sa)}(weather_sa)

interp = DI.LinearInterpolation{true}(hcat(weather_sa...),data.altitude)

function get_weather(itp::DI.LinearInterpolation, z)
    weather = itp(z)
    wind = SVector{3}(weather[2], weather[3], 0f0)
    ρ = weather[4]
    wind, ρ
end

eom_di = (u,p,t) -> ballistic(u,p,t,interp)
prob = ODEProblem{false}(eom_di, u0, tspan, p)
sol = solve(prob, Tsit5())

prob_func = (prob, i, repeat) -> remake(prob, p = p + SVector{3}(rand(CdS_dist), 0f0, 0f0))
eprob = EnsembleProblem(prob, prob_func = prob_func, safetycopy = false)
esol = solve(eprob, Tsit5(); trajectories, saveat)

### solving the ODE on GPU + Interpolation using DataInterpolations

function ballistic_gpu(u, p, t)
    CdS, mass, g = p[1]
    interp = p[2]
    vel = @view u[4:6]

    # tt = interp(0.1f0)[1]

    # @cushow tt

    # wind, ρ = get_weather(interp, u[3], zmax, N)
    wind, ρ = get_weather(interp, u[3])

    airvelocity = vel - wind
    airspeed = norm(airvelocity)
    accel = -(ρ * CdS * airspeed) / (2 * mass) * airvelocity - mass*SVector{3}(0f0, 0f0, g)

    return SVector{6}(vel..., accel...)
end

prob = ODEProblem(ballistic_gpu, u0, tspan, (p, interp))

prob_func = (prob, i, repeat) -> remake(prob, p = (p + SVector{3}(rand(CdS_dist), 0f0, 0f0), interp))
eprob = EnsembleProblem(prob, prob_func = prob_func, safetycopy = false)
esol_gpu = solve(eprob, GPUTsit5(), EnsembleGPUKernel(); trajectories, saveat)

Workaround: Using default LinearInterpolation object caused some dynamic function invocation. Hence, I changed the interp.u to be a matrix instead of a vector of SVector. Also, I clubbed the interp buffer with parameters as using the lambda function caused some dynamic function invocation.
Attempt to use Texture Memory
I tried to modify the problem definition and investigated where dynamic invocation was happening. I had to change the building of the problem as mentioned above. I tried to isolate some pieces here:
using CUDA, DiffEqGPU, OrdinaryDiffEq, Plots, Serialization, StaticArrays, Distributions, LinearAlgebra
import DataInterpolations
const DI = DataInterpolations

trajectories = 100
u0 = @SVector [0.0f0, 0.0f0, 10000.0f0, 0f0, 0f0, 0f0]
tspan = (0.0f0, 50.0f0)
saveat = LinRange(tspan..., 100)
p = @SVector [25f0, 225f0, 9.807f0]
CdS_dist = Normal(0f0, 1f0)

###

data = deserialize("forecast.txt")
N = length(data.altitude)

weather_sa = map(data.altitude, data.windx, data.windy, data.density) do alt, wx, wy, ρ
    SVector{4}(alt, wx, wy, ρ)
end

weather = map(weather_sa) do w
    (w...,)
end

weather_TA = CuTextureArray(weather)
texture = CuTexture(weather_TA; address_mode = CUDA.ADDRESS_MODE_CLAMP, normalized_coordinates = true, interpolation = CUDA.LinearInterpolation())

## Test Texture interpolation
idx = LinRange(0f0, 1f0, 4000)
idx_gpu = CuArray(idx)
idx_tlu = (1f0-1f0/N)*idx_gpu .+ 0.5f0/N  # normalized table lookup form https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#table-lookup
dst_gpu = CuArray{NTuple{4, Float32}}(undef, size(idx))
dst_gpu .= getindex.(Ref(texture), idx_tlu)  # interpolation ℝ->ℝ⁴

def_zmax = data.altitude[end]
N = length(data.altitude)
@inline function get_weather(tex, z, zmax, N)
    idx = (1f0-1f0/N)*z/zmax + 0.5f0/N # normalized input for table lookup based on https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#table-lookup
    weather = tex[idx]
    wind = SVector{3}(weather[2], weather[3], 0f0)
    ρ = weather[4]
    wind, ρ
end

### Experimentation

function kernel(texture, idx)
    tid = threadIdx().x + (blockIdx().x - 1) * blockDim().x
    @cushow texture[idx[tid]][1]
    return
end

@cuda kernel(texture, idx_tlu)

function ballistic_t(u, p, t)
    CdS, mass, g = p[1]
    interp = p[2]
    zmax = p[3]
    N = p[4]
    vel = @view u[4:6]

    tt = interp[zmax][1]

    @cushow tt

    wind, ρ = get_weather(interp, u[3], zmax, N)

    airvelocity = vel - wind
    airspeed = norm(airvelocity)
    accel = -(ρ * CdS * airspeed) / (2 * mass) * airvelocity - mass*SVector{3}(0f0, 0f0, g)

    return SVector{6}(vel..., accel...)
end

prob = ODEProblem(ballistic_t, u0, tspan, (p, texture, def_zmax, N))

function kernel_prob(prob)
    tt = prob.f(prob.u0, prob.p, 1.f0)
    return
end

@cuda kernel_prob(prob) # Works

eprob = EnsembleProblem(prob, safetycopy = false)
esol_gpu = solve(eprob, GPUTsit5(), EnsembleGPUKernel(0.0); trajectories, adptive = false, dt = 0.001f0) #InvalidIR

After performing the solve, I get this error:
Reason: unsupported dynamic function invocation (call to (f::ODEFunction)(args...) in SciMLBase at /home/gridsan/utkarsh/.julia/packages/SciMLBase/QqtZA/src/scimlfunctions.jl:2096)
Stacktrace:
 [1] step!
   @ ~/.julia/dev/DiffEqGPU/src/perform_step/gpu_tsit5_perform_step.jl:148
 [2] atsit5_kernel
   @ ~/.julia/dev/DiffEqGPU/src/perform_step/gpu_tsit5_perform_step.jl:271

Which seems a bit a strange to me, a simple kernel having prob as a parameter just worked. So Im not sure what's breaking here. The dispatch to solve essentially is cu(probs) which roughly mentioned here: https://docs.sciml.ai/DiffEqGPU/stable/tutorials/lower_level_api/. I can to isolate more pieces here but I'll need different set of eyes to have a look at it.
Maybe @maleadt can you have look at this, and help figuring out how to use Texture Memory with EnsembleGPUKernel?

Inspecting this kernel with Cthulhu (using Cthulthu, @device_code_warntype main(), press h to hide non-problematic code and navigate to the problematic code) reveals that the dynamic IR comes from the following call:
 • %419 = invoke ODEFunction(::SVector{6, Float32},::Tuple{SVector{3, Float32}, CuTexture{NTuple{4, Float32}, 1, CuTextureArray{NTuple{4, Float32}, 1}}, Float32, Int64},::Float32)::Union{}

That immediately shows the problem: your kernels still contain CPU datastructures (CuTexture, CuTextureArray) which first need to be converted to their GPU counterparts (CuDeviceTextire). Normally this conversion happens automatically when passing such objects to a kernel. In the case of structs containing GPU objects you need to define Adapt rules. It seems that ODEProblem already does so, because the kernel_prob invocation does already convert ODEProblem-contained GPU objects:
#kernel_prob#23(ODEProblem{SVector{6, Float32}, Tuple{Float32, Float32}, false, Tuple{SVector{3, Float32}, CuDeviceTexture{NTuple{4, Float32}, 1, CUDA.ArrayMemory, true, CUDA.LinearInterpolation}, Float32, Int64}, ODEFunction{false, true, ODEFunction{false, SciMLBase.AutoSpecialize, typeof(ballistic_t), UniformScaling{Bool}, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, typeof(SciMLBase.DEFAULT_OBSERVED), Nothing, Nothing}, UniformScaling{Bool}, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, typeof(SciMLBase.DEFAULT_OBSERVED), Nothing, Nothing}, Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}}, SciMLBase.StandardODEProblem})

However, the problematic atsit5 invocation below passes a GPU vector of problems, and the CPU-to-GPU object conversion does not happen automatically for array elements (because it would otherwise require a download from GPU->CPU, perform the conversion there, allocate a new array, upload again; making GPU kernel launches unacceptably expensive):
#atsit5_kernel(CuDeviceVector{ODEProblem{SVector{6, Float32}, Tuple{Float32, Float32}, false, Tuple{SVector{3, Float32}, CuTexture{NTuple{4, Float32}, 1, CuTextureArray{NTuple{4, Float32}, 1}}, Float32, Int64}, ODEFunction{false, SciMLBase.AutoSpecialize, typeof(ballistic_t), UniformScaling{Bool}, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, typeof(SciMLBase.DEFAULT_OBSERVED), Nothing, Nothing}, Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}}, SciMLBase.StandardODEProblem}, 1}, CuDeviceMatrix{SVector{6, Float32}, 1}, CuDeviceMatrix{Float32, 1}, Float32, CallbackSet{Tuple{}, Tuple{}}, Nothing, Float32, Float32, Nothing, Val{false})

The simplest solution here would be to pass a tuple of ODEProblems, because for tuples we can do the conversion efficiently. I'm not sure where that change would be needed, but @utkarsh530 or @ChrisRackauckas probably know where this comes from.

Hmm, passing these ODE problems as a tuple isn't going to work because of their size:
using Adapt

# HACK: force a GPU array of ODE problems to be passed as a tuple
Adapt.adapt_structure(to::CUDA.Adaptor, x::CuArray{<:ODEProblem}) =
    tuple(adapt.(Ref(to), Array(x))...)

... yields uses too much parameter space (0x22c4 bytes, 0x1100 max). So we can keep the array, but as I mentioned that conversion is expensive:
function Adapt.adapt_structure(to::CUDA.Adaptor, x::CuArray{<:ODEProblem})
    # first convert the contained ODE problems
    y = CuArray(adapt.(Ref(to), Array(x)))
    # continue doing what the default method does
    Base.unsafe_convert(CuDeviceArray{eltype(y),ndims(y),CUDA.AS.Global}, y)
end

And with that, the kernel launches and runs 🙂

The array of problems are built here: https://github.com/SciML/DiffEqGPU.jl/blob/70b0820e84c94e94fd9dcdf5c9b81c72be1e62ea/src/DiffEqGPU.jl#L598-L606, and the cu(probs) dispatch is here: https://github.com/SciML/DiffEqGPU.jl/blob/70b0820e84c94e94fd9dcdf5c9b81c72be1e62ea/src/DiffEqGPU.jl#L690-L696
But yes, I understood your point as to why that wasn't working. We can definitely try to figure out how "expensive" it is, but it works fine currently

Here's the comparison with interp as DataInterpolations.jl vs CUDA texture memory:

Script
using CUDA, DiffEqGPU, OrdinaryDiffEq, Plots, Serialization, StaticArrays, Distributions, LinearAlgebra
import DataInterpolations
const DI = DataInterpolations

## CPU Working Example

# Ballistic model

function ballistic(u, p, t, weather)
    CdS, mass, g = p
    vel = @view u[4:6]

    wind, ρ = get_weather(weather, u[3])

    airvelocity = vel - wind
    airspeed = norm(airvelocity)
    accel = -(ρ * CdS * airspeed) / (2 * mass) * airvelocity - mass*SVector{3}(0f0, 0f0, g)

    return SVector{6}(vel..., accel...)
end

trajectories = 100
u0 = @SVector [0.0f0, 0.0f0, 10000.0f0, 0f0, 0f0, 0f0]
tspan = (0.0f0, 50.0f0)
saveat = LinRange(tspan..., 100)
p = @SVector [25f0, 225f0, 9.807f0]
CdS_dist = Normal(0f0, 1f0)

# Ballistic w/ Interpolated winds via DataInterpolations.jl

data = deserialize("forecast.txt")
N = length(data.altitude)

weather_sa = map(data.altitude, data.windx, data.windy, data.density) do alt, wx, wy, ρ
    SVector{4}(alt, wx, wy, ρ)
end

weather_sa = SVector{length(weather_sa)}(weather_sa)

interp = DI.LinearInterpolation{true}(hcat(weather_sa...),data.altitude)

function get_weather(itp::DI.LinearInterpolation, z)
    weather = itp(z)
    wind = SVector{3}(weather[2], weather[3], 0f0)
    ρ = weather[4]
    wind, ρ
end

eom_di = (u,p,t) -> ballistic(u,p,t,interp)
prob = ODEProblem{false}(eom_di, u0, tspan, p)
sol = solve(prob, Tsit5())

prob_func = (prob, i, repeat) -> remake(prob, p = p + SVector{3}(rand(CdS_dist), 0f0, 0f0))
eprob = EnsembleProblem(prob, prob_func = prob_func, safetycopy = false)
esol = solve(eprob, Tsit5(); trajectories, saveat)

### solving the ODE on GPU + Interpolation using DataInterpolations

function ballistic_gpu(u, p, t)
    CdS, mass, g = p[1]
    interp = p[2]
    vel = @view u[4:6]

    # tt = interp(0.1f0)[1]

    # @cushow tt

    # wind, ρ = get_weather(interp, u[3], zmax, N)
    wind, ρ = get_weather(interp, u[3])

    airvelocity = vel - wind
    airspeed = norm(airvelocity)
    accel = -(ρ * CdS * airspeed) / (2 * mass) * airvelocity - mass*SVector{3}(0f0, 0f0, g)

    return SVector{6}(vel..., accel...)
end

prob = ODEProblem(ballistic_gpu, u0, tspan, (p, interp))

prob_func = (prob, i, repeat) -> remake(prob, p = (p + SVector{3}(rand(CdS_dist), 0f0, 0f0), interp))
eprob = EnsembleProblem(prob, prob_func = prob_func, safetycopy = false)
esol_gpu = solve(eprob, GPUTsit5(), EnsembleGPUKernel(); trajectories, saveat)

Benchmarking:
julia> @benchmark @CUDA.sync esol_gpu = solve(eprob_texture, GPUTsit5(), EnsembleGPUKernel(0.0); trajectories, saveat)
BenchmarkTools.Trial: 705 samples with 1 evaluation.
 Range (min … max):  5.657 ms … 34.047 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     6.443 ms              ┊ GC (median):    0.00%
 Time  (mean ± σ):   7.090 ms ±  3.021 ms  ┊ GC (mean ± σ):  0.81% ± 3.84%

  ▃▇█▇▄▁
  ███████▆▆▅▆▇▅▅▄▄▄▁▁▁▁▁▁▄▁▁▁▄▁▁▄▁▁▄▁▄▁▁▁▁▁▄▁▄▁▄▄▆▁▁▁▁▁▄▁▁▅▅ ▇
  5.66 ms      Histogram: log(frequency) by time     23.9 ms <

 Memory estimate: 850.06 KiB, allocs estimate: 12149.

julia> @benchmark @CUDA.sync esol_gpu = solve(eprob_interp, GPUTsit5(), EnsembleGPUKernel(0.0); trajectories, saveat)
BenchmarkTools.Trial: 393 samples with 1 evaluation.
 Range (min … max):   9.966 ms … 48.706 ms  ┊ GC (min … max): 0.00% … 48.42%
 Time  (median):     11.320 ms              ┊ GC (median):    0.00%
 Time  (mean ± σ):   12.722 ms ±  5.161 ms  ┊ GC (mean ± σ):  3.32% ±  8.46%

  ▅▇▇█▆
  █████▅▇▅▇▆▄▄▁▁▅▅▄▁▁▄▆▄▅▁▁▁▄▁▄▁▁▄▁▁▁▄▄▄▄▄▁▄▄▄▄▆▄▄▁▁▁▄▄▁▁▁▁▄▅ ▆
  9.97 ms      Histogram: log(frequency) by time      35.7 ms <

 Memory estimate: 4.84 MiB, allocs estimate: 39854.

@utkarsh530 is that the right script? There is no eprob_texture in the script you included.

Sorry, I just updated it.

 Range (min … max):  5.573 ms … 33.261 ms  ┊ GC (min … max): 0.00% … 69.47%
 Time  (median):     5.712 ms              ┊ GC (median):    0.00%
 Time  (mean ± σ):   5.887 ms ±  1.619 ms  ┊ GC (mean ± σ):  1.40% ±  4.25%

    ▃█▇▅▁          ▁▁▁
  ▃▆█████▆▃▃▄▃▅▅▅▇▇███▆▄▃▄▃▃▃▂▂▁▁▁▁▂▁▁▁▁▁▁▁▂▁▂▃▂▂▃▂▃▂▂▂▃▂▂▁▂ ▃
  5.57 ms        Histogram: frequency by time        6.53 ms <

 Memory estimate: 848.19 KiB, allocs estimate: 12097.

julia> @benchmark @CUDA.sync esol_gpu = solve(eprob_interp, GPUTsit5(), EnsembleGPUKernel(0.0); trajectories, saveat)
BenchmarkTools.Trial: 379 samples with 1 evaluation.
 Range (min … max):  11.605 ms … 47.908 ms  ┊ GC (min … max): 0.00% … 70.28%
 Time  (median):     12.987 ms              ┊ GC (median):    0.00%
 Time  (mean ± σ):   13.203 ms ±  4.656 ms  ┊ GC (mean ± σ):  4.67% ±  9.64%

  ▇ █
  █▇█▄▄▁▁▄▁▄▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▄▁▁▁▁▅ ▆
  11.6 ms      Histogram: log(frequency) by time      47.1 ms <

 Memory estimate: 4.84 MiB, allocs estimate: 39802.

Generally, that's the case with the EnsembleGPUKernel that competes to solve on GPU is faster than converting back to CPU arrays + SciMLSolution.  Can you try to use https://docs.sciml.ai/DiffEqGPU/dev/tutorials/lower_level_api/ ? It does not perform any expensive operations required on the CPU.

script
using Pkg; cd(@__DIR__); Pkg.activate(".")

using CUDA, DiffEqGPU, OrdinaryDiffEq, Plots, Serialization, StaticArrays, Distributions, LinearAlgebra, Adapt
import DataInterpolations
const DI = DataInterpolations

function ballistic(u, p, t)
    CdS, mass, g = p[1]
    interp = p[2]
    zmax = p[3]
    N = p[4]
    vel = @view u[4:6]

    wind, ρ = get_weather(interp, u[3], zmax, N)

    airvelocity = vel - wind
    airspeed = norm(airvelocity)
    accel = -(ρ * CdS * airspeed) / (2 * mass) * airvelocity - mass*SVector{3}(0f0, 0f0, g)

    return SVector{6}(vel..., accel...)
end

@inline function get_weather(tex, z, zmax, N)
    idx = (1f0-1f0/N)*z/zmax + 0.5f0/N # normalized input for table lookup based on https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#table-lookup
    weather = tex[idx]
    wind = SVector{3}(weather[2], weather[3], 0f0)
    ρ = weather[4]
    wind, ρ
end

@inline function get_weather(itp::DI.LinearInterpolation, z, zmax, N)
    weather = itp(z)
    wind = SVector{3}(weather[2], weather[3], 0f0)
    ρ = weather[4]
    wind, ρ
end

function Adapt.adapt_structure(to::CUDA.Adaptor, x::CuArray{<:ODEProblem})
    # first convert the contained ODE problems
    y = CuArray(adapt.(Ref(to), Array(x)))
    # continue doing what the default method does
    Base.unsafe_convert(CuDeviceArray{eltype(y),ndims(y),CUDA.AS.Global}, y)
end

# build interpolants
data = deserialize(joinpath(@__DIR__,"data","forecast.txt"))
N = length(data.altitude)
def_zmax = data.altitude[end]

weather_sa = map(data.altitude, data.windx, data.windy, data.density) do alt, wx, wy, ρ
    SVector{4}(alt, wx, wy, ρ)
end

weather_sa = SVector{length(weather_sa)}(weather_sa)
interp = DI.LinearInterpolation{true}(hcat(weather_sa...),data.altitude)

weather = map(weather_sa) do w
    (w...,)
end

weather_TA = CuTextureArray(weather)
texture = CuTexture(weather_TA; address_mode = CUDA.ADDRESS_MODE_CLAMP, normalized_coordinates = true, interpolation = CUDA.LinearInterpolation())

### Simulation parameters
trajectories = 10_000
u0 = @SVector [0.0f0, 0.0f0, 10000.0f0, 0f0, 0f0, 0f0]
tspan = (0.0f0, 40.0f0)
saveat = LinRange(tspan..., 100)
p = @SVector [25f0, 225f0, 9.807f0]
p_tx = (p, texture, def_zmax, N)
p_di = (p, interp, def_zmax, N)
CdS_dist = Normal(0f0, 1f0)
prob_func = (prob, i, repeat) -> remake(prob, p = (p + SVector{3}(rand(CdS_dist), 0f0, 0f0), prob.p[2:end]...))
### Texture Solve Test
# High Level

prob_tx = ODEProblem(ballistic, u0, tspan, p_tx)
eprob_tx = EnsembleProblem(prob_tx; prob_func, safetycopy = false)
@time esol_gpu = solve(eprob_tx, GPUTsit5(), EnsembleGPUKernel(0.0); trajectories, saveat)

# Low Level
@time begin
    probs_tex = map(1:trajectories) do i
        prob_func(prob_tx, i, false)
    end |> cu

    ts,us = DiffEqGPU.vectorized_asolve(probs_tex, prob_tx, GPUTsit5(); saveat)
end

### DI Solve Test
# High Level

prob_di = ODEProblem(ballistic, u0, tspan, p_di)
eprob_di = EnsembleProblem(prob_di; prob_func, safetycopy = false)
@time esol_di = solve(eprob_di, GPUTsit5(), EnsembleGPUKernel(0.0); trajectories, saveat)

# Low Level
@time begin
    probs_di = map(1:trajectories) do i
        prob_func(prob_di, i, false)
    end |> cu

    ts,us = DiffEqGPU.vectorized_asolve(probs_di, prob_di, GPUTsit5(); saveat)
end

# trajs = 8*4 .^(0:9)
using BenchmarkTools
BenchmarkTools.DEFAULT_PARAMETERS.samples = 3
trajs = 8*4 .^(0:8)
times = map(trajs[end]) do traj

    @show traj
    tx_lo = @benchmark @CUDA.sync begin
        probs_tex = map(1:$traj) do i
            prob_func(prob_tx, i, false)
        end |> cu

        ts,us = DiffEqGPU.vectorized_asolve(probs_tex, prob_tx, GPUTsit5(); $saveat)
    end
    display(tx_lo)

    di_lo = @benchmark @CUDA.sync  begin
        probs_di = map(1:$traj) do i
            prob_func(prob_di, i, false)
        end |> cu

        ts,us = DiffEqGPU.vectorized_asolve(probs_di, prob_di, GPUTsit5(); $saveat)
    end
    display(di_lo)

    tx = @benchmark @CUDA.sync esol_gpu = solve(eprob_tx, GPUTsit5(), EnsembleGPUKernel(0.0); trajectories = $traj, saveat = $saveat)
    display(tx)
    di = @benchmark @CUDA.sync esol_gpu = solve(eprob_di , GPUTsit5(), EnsembleGPUKernel(0.0); trajectories = $traj, saveat = $saveat)
    display(di)
    dicpu = @benchmark esol_cpu = solve(eprob_di , Tsit5(), EnsembleThreads(); trajectories = $traj, saveat = $saveat)
    display(dicpu)
    (tx    = minimum(tx.times) / 1e6,
     di    = minimum(di.times) / 1e6,
     dicpu = minimum(dicpu.times) / 1e6,
     tx_lo = minimum(tx_lo.times) / 1e6,
     di_lo = minimum(di_lo.times) / 1e6)
end

using Plots
begin
    plt = plot(trajs, getindex.(times, :tx), label = "Texture", marker = :utriangle, legend = :topleft, yaxis = :log, xaxis=:log)
    plot!(trajs, getindex.(times, :di), label = "Software", marker = :ltriangle)
    plot!(trajs, getindex.(times, :dicpu), label = "CPU", marker = :square)
    plot!(trajs, getindex.(times, :tx_lo), label = "Texture Low-Level", marker = :dtriangle, legend = :topleft)
    plot!(trajs, getindex.(times, :di_lo), label = "Software Low-Level", marker = :rtriangle)
    xlabel!("Trajectories")
    ylabel!("(ms)")
    plt
end

The low-level times includes the time to create and copy the probs. CPU times is using EnsembleThreads() on a 12 core machine
For say 524288 trajectories, if I time just the solve with the low level interface, I get
@time ts,us = DiffEqGPU.vectorized_asolve(probs_tex, prob_tx, GPUTsit5(); saveat);
 14.335337 seconds (51.38 M allocations: 1.992 GiB)

During this low-level solve I get 100% CPU usage on a single core and 0% usage on the GPU until right before the solve completes where it blips to ~30%.

However, the problematic atsit5 invocation below passes a GPU vector of problems, and the CPU-to-GPU object conversion does not happen automatically for array elements (because it would otherwise require a download from GPU->CPU, perform the conversion there, allocate a new array, upload again; making GPU kernel launches unacceptably expensive):

I am not sure, but the 100% CPU usage could be due to expensive GPU kernel launches requiring multiple uploads to GPU and CPU due to the reason Tim pointed out earlier. Even the scaling of the plot with trajectories seems a bit off, compared to plain ODE solves benchmarks. IMHO, we should only compare the time spent on solving the ODE rather than setup (which is generating GPU arrays of ODEProblem being parallelized before the solve, similar to just generating an array of parameters before and uploading them on GPU. (A common setup in other programs)).

I think @maleadt might be able to comment better here.

So, I've been experimenting with different options for passing the CuTexture w/o incurring the huge conversion overhead and I am at a bit of a loss for what I am observing. Because the texture is constant for all problems in the ensemble, I would think that I should be able to just write an ode in the form eom(u, p, t, texture) and do a closure over the texture. However, I still get a dynamic invocation with CuTexture instead of CuDeviceTexture.
NOTE: I am trying to avoid using the Adapt rule above due to the huge conversion overhead.
Here is a MWE demonstrating the issue
First, create a texture that just 0 everywhere and verify that it can be used in a closure w/ proper conversions. This works as expected.
using CUDA, DiffEqGPU, OrdinaryDiffEq, StaticArrays, Adapt

data = map(1:5000) do w
    (zeros(Float32, 4)...,)
end

texture = CuTexture( CuTextureArray(data); address_mode = CUDA.ADDRESS_MODE_CLAMP,
                        normalized_coordinates = true, interpolation = CUDA.LinearInterpolation())

idx_gpu = CuArray(LinRange(0f0, 1f0, 4000))
dst_gpu = CuArray{NTuple{4, Float32}}(undef, size(idx_gpu))

function interp!(dst, idx, tex)
    dst .= getindex.(Ref(tex), idx)
end

cl_let = let tex = texture
    (d,i) -> interp!(d, i, tex)
end
cl_let(dst_gpu, idx_gpu);

Next, lets define a simple ODE that accepts a texture as an argument but does nothing with it and solve over a closure of tex
function eom(u, p, t, tex)
    return @SVector zeros(Float32, 4)
end

Why? It seems like the proper conversion occurred in the other examples using a closure over the texture.

That's because in those cases you were invoking a closure directly, and Adapt.jl has rules  (Adapt.adapt_structure methods) to recursively convert the captures of a closure. Those rules are then used by CUDA.jl to convert the function (closure) you're invoking, as well as any of its arguments, to a GPU-compatible representation (CuTexture->CuDeviceTexture, etc).
Here, however, a kernel is invoked with an EnsembleProblem argument, which contains an ODEProblem, which contains an ODEFunction, which contains a closure that captures a CuTexture and a CuTextureArray. Although CUDA will use Adapt to try and convert such an argument to a device-compatible representation, there are no Adapt rules defined for these types of objects, so the conversion is a no-op.
So basically, there would need to be Adapt rules for each of these types so that kernel conversion recurses into the objects when the EnsembleProblem is passed to a kernel. Alternatively, the code constructing an EnsembleProblem could manually call cudaconvert on the fields that need to be converted, but depending on how that is done it would still need rules for all but the outermost object type (and also breaks platform portability).
One simple way to add Adapt rules is to use @adapt_structure, but that relies on default constructors being present, and that's not the case for ODEFunction:
julia> Adapt.@adapt_structure EnsembleProblem

julia> Adapt.@adapt_structure ODEProblem

julia> Adapt.@adapt_structure ODEFunction

julia> cudaconvert(eprob_tex)
ERROR: MethodError: no method matching ODEFunction(::var"#14#15"{CuDeviceTexture{NTuple{4, Float32}, 1, CUDA.ArrayMemory, true, CUDA.LinearInterpolation}}, ::LinearAlgebra.UniformScaling{Bool}, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::Nothing, ::typeof(SciMLBase.DEFAULT_OBSERVED), ::Nothing, ::Nothing)


[Bug]swarm start failed with a CLI client

🐛 Bug

To reproduce
Code snippet to reproduce
cargo run -p libra-swarm -- -s

Stack trace/error message
   Compiling libra-swarm v0.1.0 (/libra/libra-swarm)
    Finished dev [unoptimized + debuginfo] target(s) in 25.69s
     Running `target/debug/libra-swarm -s`
To run the Libra CLI client in a separate process and connect to the validator nodes you just spawned, use this command:
	cargo run --bin client -- -a localhost -p 56961 -s "/var/folders/50/gltb5mz92nn2pc_96t68fsth0000gp/T/468e8ba8af052999aa6cb8ec64f4874a/0/consensus_peers.config.toml" -m "/var/folders/50/gltb5mz92nn2pc_96t68fsth0000gp/T/468e8ba8af052999aa6cb8ec64f4874a/mint.key"
To run transaction generator run:
	cargo run --bin cluster-test -- --mint-file "/var/folders/50/gltb5mz92nn2pc_96t68fsth0000gp/T/468e8ba8af052999aa6cb8ec64f4874a/mint.key" --swarm --peers "localhost:56961"  --emit-tx
Loading client...
error: Found argument '-s' which wasn't expected, or isn't valid in this context

USAGE:
    client --faucet-key-file-path <faucet-account-file> --host <host> --mnemonic-file <mnemonic-file> --port <port>

For more information try --help
Exit client.
Exit libra-swarm.

Expected Behavior

No error msg.
System information
Please complete the following information:

 master branch

MacOS

Additional context
This pr #2002 remove -s  / validator_set_file  arg for client.

Yeah I noticed it yesterday. https://github.com/libra/libra/pull/2114 should fix it.


Add accessible autocomplete to incoming/outgoing trust pages

Context
To improve the usability of the prototype, we want to include autocomplete on the pages for searching for an incoming/outgoing trust
Changes

Adds the accessible autocomplete into the trust-name page and the incoming page
Updates the back links to support correct back navigation in the case of choosing the autocomplete result

Yes, that looks spot on!! Merge away.


Enable CONFIG_COMPAT kernel configs

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[x] The toolchain has been rebuilt successfully (or no changes were made to it)
[x] The toolchain/worker package manifests are up-to-date
[x] Any updated packages successfully build (or no packages were changed)
[x] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[x] All package sources are available
[x] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/tools/cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
[x] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[x] All source files have up-to-date hashes in the *.signatures.json files
[x] sudo make go-tidy-all and sudo make go-test-coverage pass
[x] Documentation has been updated to match any changes to the build system
[x] Ready to merge

Summary
Enable CONFIG_COMPAT kernel configs for Mariner X64 kernel.
CONFIG_COMPAT kernel configs are already enabled for Mariner aarch64 kernel.
These kernel configs are required to build myd_vsc/drv_vsc and drv_ion/myd_ion drivers from OpenVino toolkit.
Change Log

Change
Enable CONFIG_COMPAT kernel configs

Does this affect the toolchain?

YES/NO
Associated issues

#xxxx

Links to CVEs

https://nvd.nist.gov/vuln/detail/CVE-YYYY-XXXX

Test Methodology

Local build

Closing this PR which is sent to 1.0 instead of 1.0-dev.
Below is the new PR which is targeted to merge into 1.0-dev branch.
https://github.com/microsoft/CBL-Mariner/pull/1693


Defect dojo : HCL appscanner unable to parse the sample.xml

I've encountered a problem with the HCL AppScanner integration in DefectDojo. Despite defining the logic to parse the example.xml file correctly, the output for several fields (name, description, and others) is incorrect when processed by the HCL AppScanner in DefectDojo.
Here's a detailed description of the issue:
Parsing Logic: I've written logic to parse the example.xml file and extract the following fields:
Name
Description
Remediation
Advisory
Severity
CWE
Impact
Steps to Reproduce
Severity Justification
References
Host
Port
Domain
Entity
Cause ID
URL Name
Path
Local Testing: When I run the parsing logic on my local machine using simple Python code, it correctly extracts and processes all the specified fields from the example.xml file, providing the desired output.
Issue in DefectDojo: However, when I implement the same logic within DefectDojo using HCL AppScanner, the application fails to provide the correct output. Specifically, it returns incorrect values for the name, description, and other fields.
Steps to Reproduce
Define the parsing logic for example.xml file to extract the specified fields.
Test the logic locally using a simple Python script to ensure it works correctly.
Implement the parsing logic in DefectDojo using HCL AppScanner.
Upload the same example.xml file in DefectDojo and observe the output provided by HCL AppScanner.
Expected Behavior
The HCL AppScanner should correctly parse the example.xml file and extract the specified fields with the correct values, consistent with the local Python script output.
Actual Behavior
The HCL AppScanner in DefectDojo returns incorrect values for the name, description, and other fields specified in the example.xml file.
Request for Assistance
Any insights or assistance in resolving this issue would be greatly appreciated. Please let me know if additional information or clarification is needed.
Thank you!

@ashu-tosh99 It's possible that the output of HCL appscanner has changed - would it be possible for you to provide a sanitized example or a scan of a known vulnerable app?
If you need targets to scan, OWASP has this project that lists many options - https://owasp.org/www-project-vulnerable-web-applications-directory/


cargo test fails on freshly pulled repo

I start from scratch. I create a new fork of rustfmt. Then I run git clone [URL to my forked repo in github]. Then I enter the project and run cargo test, and it fails. Both with stable and nightly versions of Rust compiler.

Here's the output:
$ cargo test
   Compiling proc-macro2 v1.0.37
   Compiling unicode-xid v0.2.2
   Compiling syn v1.0.91
   Compiling libc v0.2.122
   Compiling memchr v2.4.1
   Compiling serde_derive v1.0.136
   Compiling serde v1.0.136
   Compiling quote v1.0.17
   Compiling version_check v0.9.4
   Compiling cfg-if v1.0.0
   Compiling log v0.4.16
   Compiling aho-corasick v0.7.18
   Compiling proc-macro-error-attr v1.0.4
   Compiling proc-macro-error v1.0.4
   Compiling autocfg v1.1.0
   Compiling regex-syntax v0.6.25
   Compiling indexmap v1.8.1
   Compiling crossbeam-utils v0.8.8
   Compiling lazy_static v1.4.0
   Compiling semver v1.0.7
   Compiling camino v1.0.7
   Compiling regex v1.5.5
   Compiling serde_json v1.0.79
   Compiling dirs-sys-next v0.1.2
   Compiling atty v0.2.14
   Compiling bstr v0.2.17
   Compiling hashbrown v0.11.2
   Compiling unicode-width v0.1.9
   Compiling fnv v1.0.7
   Compiling ryu v1.0.9
   Compiling anyhow v1.0.56
   Compiling same-file v1.0.6
   Compiling once_cell v1.10.0
   Compiling heck v0.4.0
   Compiling termcolor v1.1.3
   Compiling itoa v1.0.1
   Compiling thread_local v1.1.4
   Compiling walkdir v2.3.2
   Compiling globset v0.4.8
   Compiling dirs-next v2.0.0
   Compiling dirs-sys v0.3.7
   Compiling clap_derive v3.1.7
   Compiling thiserror-impl v1.0.30
   Compiling os_str_bytes v6.0.0
   Compiling yansi-term v0.1.2
   Compiling rustfmt-nightly v1.5.1 (/home/amab/src/rustfmt)
   Compiling either v1.6.1
   Compiling textwrap v0.15.0
   Compiling humantime v2.1.0
   Compiling strsim v0.10.0
   Compiling bitflags v1.3.2
   Compiling env_logger v0.9.0
   Compiling thiserror v1.0.30
   Compiling itertools v0.10.3
   Compiling clap v3.1.8
   Compiling annotate-snippets v0.9.1
   Compiling ignore v0.4.18
   Compiling rustfmt-config_proc_macro v0.3.0 (/home/amab/src/rustfmt/config_proc_macro)
   Compiling derive-new v0.5.9
   Compiling dirs v4.0.0
   Compiling term v0.7.0
   Compiling getopts v0.2.21
   Compiling unicode_categories v0.1.1
   Compiling unicode-segmentation v1.9.0
   Compiling diff v0.1.12
   Compiling bytecount v0.6.2
   Compiling rustc-workspace-hack v1.0.0
   Compiling cargo-platform v0.1.2
   Compiling toml v0.5.8
   Compiling cargo_metadata v0.14.2
error[E0463]: can't find crate for `rustc_ast`
  --> src/lib.rs:16:1
   |
16 | extern crate rustc_ast;
   | ^^^^^^^^^^^^^^^^^^^^^^^ can't find crate
   |
   = help: maybe you need to install the missing components with: `rustup component add rust-src rustc-dev llvm-tools-preview`

error[E0463]: can't find crate for `rustc_ast_pretty`
  --> src/lib.rs:17:1
   |
17 | extern crate rustc_ast_pretty;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate
   |
   = help: maybe you need to install the missing components with: `rustup component add rust-src rustc-dev llvm-tools-preview`

error[E0463]: can't find crate for `rustc_builtin_macros`
  --> src/lib.rs:18:1
   |
18 | extern crate rustc_builtin_macros;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate
   |
   = help: maybe you need to install the missing components with: `rustup component add rust-src rustc-dev llvm-tools-preview`

error[E0463]: can't find crate for `rustc_data_structures`
  --> src/lib.rs:19:1
   |
19 | extern crate rustc_data_structures;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate
   |
   = help: maybe you need to install the missing components with: `rustup component add rust-src rustc-dev llvm-tools-preview`

error[E0463]: can't find crate for `rustc_errors`
  --> src/lib.rs:20:1
   |
20 | extern crate rustc_errors;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate
   |
   = help: maybe you need to install the missing components with: `rustup component add rust-src rustc-dev llvm-tools-preview`

error[E0463]: can't find crate for `rustc_expand`
  --> src/lib.rs:21:1
   |
21 | extern crate rustc_expand;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate
   |
   = help: maybe you need to install the missing components with: `rustup component add rust-src rustc-dev llvm-tools-preview`

error[E0463]: can't find crate for `rustc_parse`
  --> src/lib.rs:22:1
   |
22 | extern crate rustc_parse;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate
   |
   = help: maybe you need to install the missing components with: `rustup component add rust-src rustc-dev llvm-tools-preview`

error[E0463]: can't find crate for `rustc_session`
  --> src/lib.rs:23:1
   |
23 | extern crate rustc_session;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate
   |
   = help: maybe you need to install the missing components with: `rustup component add rust-src rustc-dev llvm-tools-preview`

error[E0463]: can't find crate for `rustc_span`
  --> src/lib.rs:24:1
   |
24 | extern crate rustc_span;
   | ^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate
   |
   = help: maybe you need to install the missing components with: `rustup component add rust-src rustc-dev llvm-tools-preview`

error[E0432]: unresolved imports `crate::ast::AssocItemKind::*`, `ast::AssocConstraintKind::Bound`, `ast::AssocConstraintKind::Equality`
   --> src/items.rs:591:17
    |
591 |             use crate::ast::AssocItemKind::*;
    |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
   ::: src/types.rs:181:40
    |
181 |         use ast::AssocConstraintKind::{Bound, Equality};
    |                                        ^^^^^  ^^^^^^^^

error[E0531]: cannot find tuple struct or tuple variant `TyAlias` in this scope
   --> src/items.rs:597:18
    |
597 |                 (TyAlias(lty), TyAlias(rty))
    |                  ^^^^^^^ not found in this scope

error[E0531]: cannot find tuple struct or tuple variant `TyAlias` in this scope
   --> src/items.rs:597:32
    |
597 |                 (TyAlias(lty), TyAlias(rty))
    |                                ^^^^^^^ not found in this scope

error[E0531]: cannot find tuple struct or tuple variant `Const` in this scope
   --> src/items.rs:602:18
    |
602 |                 (Const(..), Const(..)) => false,
    |                  ^^^^^ not found in this scope
    |
help: consider importing this tuple variant
    |
3   | use crate::types::SegmentParam::Const;
    |

error[E0531]: cannot find tuple struct or tuple variant `Const` in this scope
   --> src/items.rs:602:29
    |
602 |                 (Const(..), Const(..)) => false,
    |                             ^^^^^ not found in this scope
    |
help: consider importing this tuple variant
    |
3   | use crate::types::SegmentParam::Const;
    |

error[E0531]: cannot find tuple struct or tuple variant `TyAlias` in this scope
   --> src/items.rs:615:18
    |
615 |                 (TyAlias(lty), TyAlias(rty))
    |                  ^^^^^^^ not found in this scope

error[E0531]: cannot find tuple struct or tuple variant `TyAlias` in this scope
   --> src/items.rs:615:32
    |
615 |                 (TyAlias(lty), TyAlias(rty))
    |                                ^^^^^^^ not found in this scope

error[E0531]: cannot find tuple struct or tuple variant `Const` in this scope
   --> src/items.rs:620:18
    |
620 |                 (Const(..), Const(..)) | (MacCall(..), MacCall(..)) => {
    |                  ^^^^^ not found in this scope
    |
help: consider importing this tuple variant
    |
3   | use crate::types::SegmentParam::Const;
    |

error[E0531]: cannot find tuple struct or tuple variant `Const` in this scope
   --> src/items.rs:620:29
    |
620 |                 (Const(..), Const(..)) | (MacCall(..), MacCall(..)) => {
    |                             ^^^^^ not found in this scope
    |
help: consider importing this tuple variant
    |
3   | use crate::types::SegmentParam::Const;
    |

error[E0531]: cannot find tuple struct or tuple variant `MacCall` in this scope
   --> src/items.rs:620:43
    |
620 |                 (Const(..), Const(..)) | (MacCall(..), MacCall(..)) => {
    |                                           ^^^^^^^ not found in this scope

error[E0531]: cannot find tuple struct or tuple variant `MacCall` in this scope
   --> src/items.rs:620:56
    |
620 |                 (Const(..), Const(..)) | (MacCall(..), MacCall(..)) => {
    |                                                        ^^^^^^^ not found in this scope

error[E0532]: expected tuple struct or tuple variant, found trait `Fn`
   --> src/items.rs:623:18
    |
623 |                 (Fn(..), Fn(..)) => a.span.lo().cmp(&b.span.lo()),
    |                  ^^ not a tuple struct or tuple variant

error[E0532]: expected tuple struct or tuple variant, found trait `Fn`
   --> src/items.rs:623:26
    |
623 |                 (Fn(..), Fn(..)) => a.span.lo().cmp(&b.span.lo()),
    |                          ^^ not a tuple struct or tuple variant

error[E0531]: cannot find tuple struct or tuple variant `TyAlias` in this scope
   --> src/items.rs:624:18
    |
624 |                 (TyAlias(ty), _) if is_type(&ty.ty) => Ordering::Less,
    |                  ^^^^^^^ not found in this scope

error[E0531]: cannot find tuple struct or tuple variant `TyAlias` in this scope
   --> src/items.rs:625:21
    |
625 |                 (_, TyAlias(ty)) if is_type(&ty.ty) => Ordering::Greater,
    |                     ^^^^^^^ not found in this scope

error[E0531]: cannot find tuple struct or tuple variant `TyAlias` in this scope
   --> src/items.rs:626:18
    |
626 |                 (TyAlias(..), _) => Ordering::Less,
    |                  ^^^^^^^ not found in this scope

error[E0531]: cannot find tuple struct or tuple variant `TyAlias` in this scope
   --> src/items.rs:627:21
    |
627 |                 (_, TyAlias(..)) => Ordering::Greater,
    |                     ^^^^^^^ not found in this scope

error[E0531]: cannot find tuple struct or tuple variant `Const` in this scope
   --> src/items.rs:628:18
    |
628 |                 (Const(..), _) => Ordering::Less,
    |                  ^^^^^ not found in this scope
    |
help: consider importing this tuple variant
    |
3   | use crate::types::SegmentParam::Const;
    |

error[E0531]: cannot find tuple struct or tuple variant `Const` in this scope
   --> src/items.rs:629:21
    |
629 |                 (_, Const(..)) => Ordering::Greater,
    |                     ^^^^^ not found in this scope
    |
help: consider importing this tuple variant
    |
3   | use crate::types::SegmentParam::Const;
    |

error[E0531]: cannot find tuple struct or tuple variant `MacCall` in this scope
   --> src/items.rs:630:18
    |
630 |                 (MacCall(..), _) => Ordering::Less,
    |                  ^^^^^^^ not found in this scope

error[E0531]: cannot find tuple struct or tuple variant `MacCall` in this scope
   --> src/items.rs:631:21
    |
631 |                 (_, MacCall(..)) => Ordering::Greater,
    |                     ^^^^^^^ not found in this scope

warning: unused import: `NodeIdExt`
  --> src/closures.rs:15:68
   |
15 | use crate::utils::{last_line_width, left_most_sub_expr, stmt_expr, NodeIdExt};
   |                                                                    ^^^^^^^^^
   |
   = note: `#[warn(unused_imports)]` on by default

warning: unused import: `NodeIdExt`
  --> src/macros.rs:39:77
   |
39 |     remove_trailing_white_spaces, rewrite_ident, trim_left_preserve_layout, NodeIdExt,
   |                                                                             ^^^^^^^^^

Some errors have detailed explanations: E0432, E0463, E0531, E0532.
For more information about an error, try `rustc --explain E0432`.
warning: `rustfmt-nightly` (lib) generated 2 warnings
error: could not compile `rustfmt-nightly` due to 30 previous errors; 2 warnings emitted
warning: build failed, waiting for other jobs to finish...
warning: `rustfmt-nightly` (lib test) generated 2 warnings (2 duplicates)
error: could not compile `rustfmt-nightly` due to 30 previous errors; 2 warnings emitted

Please follow the advice in the error message and try again:
error[E0463]: can't find crate for `rustc_ast`
  --> src/lib.rs:16:1
   |
16 | extern crate rustc_ast;
   | ^^^^^^^^^^^^^^^^^^^^^^^ can't find crate
   |
   = help: maybe you need to install the missing components with: `rustup component add rust-src rustc-dev llvm-tools-preview`

Because rustfmt relies on the compiler there are some additional rustup components that need to be installed.

it doesn't help. Pretty much same output from cargo test, even after running rustup component add rust-src rustc-dev llvm-tools-preview

What version of the compiler are you using? You should be able to run rustup show active-toolchain to find. out. You need a nightly compiler in order to build rustfmt. I'm wondering if that's the issue that you're running into.
@calebcartwright Do you have any thoughts on what might be going on?

What version of the compiler are you using? You should be able to run rustup show active-toolchain to find. out. You need a nightly compiler in order to build rustfmt. I'm wondering if that's the issue that you're running into.
@calebcartwright Do you have any thoughts on what might be going on?

$ rustup show active-toolchain
nightly-x86_64-unknown-linux-gnu (directory override for '[...]/src/rustfmt')

With the tools like rustfmt that consume the compiler internals via the sysroot, it's insufficient to just use a nightly; you need to use a nightly toolchain that's compatible with the version of the tool source. In this case you've almost certainly got a newer nightly than the current rustfmt codebase supports. The best way to go about this (for rustfmt and other such official tools) is to ensure you're using the exact toolchain specified in the toolchain file:
https://github.com/rust-lang/rustfmt/blob/ee2bed96d60fd7e46b1fb868f6a8f27e3a8058d0/rust-toolchain#L2
Download the nightly-2022-08-06 toolchain, install the rustc-dev component for that toolchain, and then ensure that toolchain is the one actually being used/not being overridden and you should be sorted

With the tools like rustfmt that consume the compiler internals via the sysroot, it's insufficient to just use a nightly; you need to use a nightly toolchain that's compatible with the version of the tool source. In this case you've almost certainly got a newer nightly than the current rustfmt codebase is compatible with due to those sysroot deps. The best way to go about this (for rustfmt and other such official tools) is to ensure you're using the exact toolchain specified in the toolchain file:
https://github.com/rust-lang/rustfmt/blob/ee2bed96d60fd7e46b1fb868f6a8f27e3a8058d0/rust-toolchain#L2
Download the nightly-2022-08-06 toolchain, install the rustc-dev component for that toolchain, and then ensure that toolchain is the one actually being used/not being overridden and you should be sorted

thanks, it works now :)


Soft-body with plane when the camera start bellow the plane even when the soft body passes in front of the camera

Godot version
v4.0.dev.custom_build [88b347dc2]
System information
Ubuntu 21.04. RTX 2060
Issue description
This issue is very strange but like the title says. If the softbody plane mesh start above the camera, it is complete invisible even if the soft body is in direction with the camera view.
Steps to reproduce
Use the InvisibleCloth.tscn scene from the Minimal reproduction project
Minimal reproduction project
Godot 4.0 SoftBody.zip

This happens because the visibility AABB isn't automatically adjust to account for the displayed vertices. I'm not sure if it's possible to do this in a cheap way.
In the meantime, increase Extra Cull Margin on the mesh.

Good to know that. Since this is not related to soft bodies then the issue can be closed or rename to explain the cause

This happens because the visibility AABB isn't automatically adjust to account for the displayed vertices. I'm not sure if it's possible to do this in a cheap way.

Soft bodies are supposed to update their AABB after calculating the new vertex positions, but there's probably a bug either in godot physics or in the vulkan renderer.
https://github.com/godotengine/godot/blob/30cf49e8d0325759b36af698f0c08d95629d1e09/scene/3d/soft_dynamic_body_3d.cpp#L90
@jcostello Do you know if it happens also in 3.x or just in 4.0?

@pouleyKetchoupp 4.0

Can confirm using the originally linked project in Godot 4.0 alpha 1.

Still occurs in Godot 4.0 alpha 4 with the originally linked project.
Workaround: Move the SoftBody so that it is in view of the Camera or increase Extra Cull Margin.


ast tree in detail

If we use that code, then we will see mush more detail of AST tree.

merged. thank you for your contribution!


Package Management tools

Package Management Tools

Issue template
CI/CD configuration
PR template
Pre-commit hook

@deshraj I am closing this issue.


Add the Portuguese version of documentation page 'Developer-Tips.md'

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/8910/
Test PASSed.

LGTM, thanks for the translation!


Support for partial data usage for LibriSpeech

There should be a functionality where instead of having to download entire dataset and train on it, we could download just partial data and use only that for training. And if not, then the documentation should clearly mention how the dataset directory structure should look like so that it's easier for us to use our own partial dataset. I'm currently trying to train a RNN-T model and I keep facing issues with directory structure.
Command that I'm using
python ./openspeech_cli/hydra_train.py dataset=librispeech dataset.dataset_download=False dataset.dataset_path=/home/guest/flsp/SpeechToText/RNN-T/openspeech/LIBRISPEECH_AUTO_DOWNLOAD/LibriSpeech dataset.manifest_file_path=/home/guest/flsp/SpeechToText/RNN-T/openspeech/LIBRISPEECH_AUTO_MANIFEST tokenizer=libri_subword model=rnn_transducer audio=melspectrogram lr_scheduler=warmup_reduce_lr_on_plateau trainer=gpu

There were many questions about the directory structure, so I thought I should document it.
Please wait for a moment.

What is the status of this?


Clear identifier for each rule

It would be nice, if each rule would have a clear identifier, e.g. a number so that it easer so search or grab for them.

Thank you for reporting this issue and appreciate your patience. We've  notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.


tiltfile2: k8s yaml accepts string

I'm confused...the PR description is "k8s yaml accepts string", but the PR is "k8s yaml does not accept string"?

Whoops, sorry @nicks that was an old title. Re-titling.


Updated config fields from rackspace

The Openstack driver has been updated to change config fields
from Rackspace to Openstack.  The change will be important
moving forward but didn't impact the existing driver.

Hi @clintonskitson,
I merged the PR. In the future, if you could please remember to add the label, milestone, etc., I'd appreciate it :)