share_plus: 1.2.0 shareFiles() via WeChat only send the image file, but not the text (/subject)

System info
Issue occurs on: only tested Android
Plugin name: share_plus
Plugin version: 1.2.0
Flutter doctor output:
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel unknown, 1.22.6, on Microsoft Windows [Version 10.0.21390.1], locale en-US)
[√] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
[√] Android Studio (version 3.5)
[√] Connected device (1 available)
• No issues found!

Steps to Reproduce
very basic example:
import 'package:share_plus/share_plus.dart';

...

Share.shareFiles(
                        [imagePath],
                        text: imgUrl,
                        subject: imgUrl
                      );

When share via WeChat, only the image is sent, but none of text / subject is sent.
In contrast, if share via Gmail, all the image, text & subject are sent.
Has anyone able to make it work on WeChat?

Also occurs on iOS. Wont share image to WhatsApp if there is text present. Same story with Facebook.

Current version of share_plus is 2.1.2.
Can you confirm you are using the latest version?

Can confirm am on 2.1.2

Going to mark this as duplicated to #261 and will add info there

I think we should open this again since #261 has been closed due to the author doesn't need to share text and images at the same time

I disagree, this is a limitation of sharing works on those apps, nothing to do with the plugin.


Fix fp8 things

Fixes a few things with the fp8 integration since the merger of msamp:

Couldn't just use the accelerate configuration and leave the defaults, as the mixed precision wasn't set yet for when we check to build a recipe handler default
explicitly makes the backend te as the default (hit the dataclass not liking this w/o it being passed in)
some fixes to allow users to pass in either backend="te" or backend="TE"

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.


DPL-524 Establish process maps for TOL/SciOps Sample ingestion

Description
Establish a shared understanding of the process of sample ingestion between TOL - SciOps - process maps agreed with ToL and SciOps by Oct.
Discoverable process which can be viewed by all stakeholders as an agreed standard of how to request work
Who the primary contacts are for this work
Eduardo
Steve
Knowledge or Stake holders
TOL, SciOps
Additional context or information
Enabling Platforms & Core labs (Progs: ToL), SciOps - Long read, Sample Management, SSRs

Diagrams at: https://lucid.app/lucidchart/33b22c5e-cd4a-4cd9-8c7c-2ae1f110b347/edit?invitationId=inv_daeccc47-5803-4309-bd63-1a9e8fc4bf6b&page=0_0#

Stories created for next iteration that will allow CREATE:

https://github.com/sanger/tol-lab-share/issues/15
https://github.com/sanger/tol-lab-share/issues/16

@emrojo DPL-540 is not on your diagram. I also thought there was another more detailied diagram which you showed me?
We also need to think about ingestion into Samples extraction.
A couple of other things to think about. We will need some kind of interaction with stakeholders e.g. working with ToL and SSRs to show this working so I think it needs an extra story at least maybe 2 to ensure that we cover everything.
Iy might be worth engaging with ToL sooner rather than later and seeing what they are planning to do.

Hi,
Stories at the moment is this group:
https://github.com/sanger/tol-lab-share/issues?q=is%3Aissue+is%3Aopen+label%3A"ToL+Sample+ingestion+(phase+2)"

Closed as done.


Ability to select PTZ preset without trigger

Hello, will your app allow me to simply select a PTZ preset. I don't need to trigger recording, etc I would just like to use ActionTiles in combination with WebCore and smartthings to move my camera to set positions.
Thanks

Yes, you could set it up and not set up triggers or anything else.  The
apps and device handlers allow each camera to be a device on smartthings
that you can treat like any other device.  So you could use WebCORE or
something to send PTZ positions to the camera directly based on whatever
you want.
On Sat, Mar 21, 2020 at 6:20 PM rjsears<EMAIL_ADDRESS>wrote:

Hello, will your app allow me to simply select a PTZ preset. I don't need
to trigger recording, etc I would just like to use ActionTiles in
combination with WebCore and smartthings to move my camera to set positions.
Thanks
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/flyjmz/jmzSmartThings/issues/7, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEXMGQVQ3R5KAOSACEV4M2LRIU4SDANCNFSM4LRCFU5A
.


Enable set of Rubocop cops

Context
Enables the following cops

Style/HashConversion cop
Style/QuoteSymbols cop
Style/IfWithBooleanLiteralBranches cop
Style/BlockDelimiters cop
Style/SingleArgumentDig cop
Style/HashLikeCase cop
Style/ClassEqualityComparison cop
Style/OptionalBooleanParameter cop

Link to Trello card
https://trello.com/c/I6JiD7cR/3856-rubocop-cleanup
Things to check

[x] This code does not rely on migrations in the same Pull Request
[x] If this code includes a migration adding or changing columns, it also backfills existing records for consistency
[x] API release notes have been updated if necessary
[x] Required environment variables have been updated added to the Azure KeyVault

@cwrw I think some don't need to be set, not specifically ones on this PR but also others that I have already enabled. I need to do an overall review but I'll have a look at these ones as well before I merge.


Deprecation warning

I found this deprecation warning after upgrading to python 3.6 (using django extensions 1.9.9)
/usr/local/lib/python3.6/site-packages/django_extensions/collision_resolvers.py:207: DeprecationWarning: inspect.getargspec() is deprecated, use inspect.signature() or inspect.getfullargspec()
assert len(inspect.getargspec(collision_resolver_class.resolve_collisions).args) == 2, \

PR: https://github.com/django-extensions/django-extensions/pull/1181

Thanks !


Move all timestep calculations to GPU

Passes All Tests

Switched the first time step calculation to be done on GPU rather
than CPU
Make the host and device dti_array's local to Calc_dt_GPU
Removed last reference to HYDRO_GPU flag in cooling make file
Added comments to main to clarify what Grid3D::set_dt does
Deleted CPU time step functions

calc_dti_cpu
calc_dti_cpu_1D
calc_dti_cpu_2D
calc_dti_cpu_3D
calc_dti_CPU_3D_function

I looked it over, and it's mostly fine. This line "if (block_tot > 1) CudaSafeCall( cudaFreeHost(buffer) );" should not be in VL_3D_cuda (or any of the other integrators) any more.

Fixed it, I probably just missed that line when rebasing


Fixes/updates to build on linux.

a) An update to build-infer.sh to avoid downloading/building 4.02.3
ocaml compiler when it is already present.
b) Add the ifdef to avoid this error on glibc systems:
clang -c -w libc_basic.c -o libc_basic.o
libc_basic.c:692:12: error: unknown type name '__WAIT_STATUS'
pid_t wait(__WAIT_STATUS stat_loc) {
        ^

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

Regarding a)
We create separate opam switch intentionally to not pollute default opam switch (in case someone uses it for other ocaml development). The downside I know about is that ocaml needs to be rebuilt (but only once).
We introduced that logic to build-infer recently and we may revisit it in the future.
Regarding b)
Interesting find. Does compilation fail for you without it? What system and which version of gcc are you using?

We create separate opam switch intentionally to not pollute default opam switch (in case someone uses it for other ocaml development). The downside I know about is that ocaml needs to be rebuilt (but only once).

Yes, even with this, it clones a separate compiler but it clones from existing one rather than downloading and building 4.02.3 compiler  again even if it is installed.
As you can see from https://gist.github.com/ronin13/5bd675296326c3bfdff9e2e3dfc26a88 it doesn't modify the opam switch.

Regarding b)
Interesting find. Does compilation fail for you without it? What system and which version of gcc are you using?

pacman -Q 'glibc' 'gcc-libs-multilib' 'gcc-multilib'
glibc 2.24-2
gcc-libs-multilib 6.1.1-5
gcc-multilib 6.1.1-5

lsb_release
LSB Version:    1.4

Distro is Arch Linux.

and, yes, compilation fails with:

clang -c -w libc_basic.c -o libc_basic.o
libc_basic.c:692:12: error: unknown type name '__WAIT_STATUS'
pid_t wait(__WAIT_STATUS stat_loc) {
           ^

Yes, even with this, it clones a separate compiler but it clones from existing one rather than downloading and building 4.02.3 compiler again even if it is installed.

I missed that part. Does it really work like this? I tried to reproduce what your pull request does on my mac and opam is still downloading and compiling ocaml with following script:
ALIAS_SWITCH=$(opam config var switch)

OPAMSWITCH="infer-4.02.3"
opam switch install -j 4 $OPAMSWITCH --alias-of $ALIAS_SWITCH || true

ALIAS_SWITCH=$(opam config var switch)
OPAMSWITCH="infer-4.02.3"
opam switch install -j 4 $OPAMSWITCH --alias-of $ALIAS_SWITCH || true

Regarding this, I believe (not an opam expert), it will download only if  opam config var switch returns a switch which doesn't map to 4.02.3 installed as the default.
So, for me, by default,

opam config var ocaml-version
4.02.3

opam config var switch
system

Full config: https://gist.github.com/ronin13/938747dbe8663f6dccf54f6c8e8096c6

Thanks @ronin13!  Could you split this into two separate pull requests since the two changes are not very closely related.  Also, could you change the comment in build-infer.sh to refer to $OCAML_VERSION instead of 4.02.3 so that it stays accurate as we upgrade.  And the comment would be better wrapped at 100 columns.

@jberdine
Yes, will do, will file a separate pull request for the ocaml one.

I have updated the pull request with only the build fixes. I will submit the build-infer.sh fix in a separate pull request as discussed earlier.

The PR seems to contain both changes still.

Sorry about that, fixed now.

@ronin13 thanks for the fix! If you can submit your other change as a new PR I'll be happy to merge it in as well.

@jvillard
Thanks, will submit the other pull request soon.

@jvillard @jberdine  Submitted the pull request for build-infer here https://github.com/facebook/infer/pull/451


Minor fix to git clone example in README file.

What it says on the tin, just some doc cleanup.

The readme is not wrong, Git repositories can b cloned over many protocols, it used ssh syntax which ur asking to change to http which is fair enough, just maybe change the title to something like 'using http over ssh in git clone example'


Enhancing Website Animation on GitHub Readme

The current GitHub Readme website lacks animation, resulting in a static and less engaging user experience. To improve the overall aesthetics and user interaction, I  propose to add animations throughout the website. This includes implementing smooth features such as slide-ins, component movements, and dynamic transitions when entering or navigating the page.
Proposed Solution:
The proposed solution is to incorporate animations that enhance the visual appeal and interactivity of the GitHub Readme website. This can be achieved by utilizing CSS animations, JavaScript libraries, or frameworks to create smooth transitions and captivating effects. The suggested animations include slide-in effects for sections or elements, subtle movements of components, and dynamic transitions triggered when the page is entered or certain interactions occur.
Benefits

Enhanced User Experience
Improved Aesthetics
Increased Engagement

One of the best ones, thanks @drakshi, it's yours! 💪🏻


Stark: Small refactor of StarkTranscript

Small refactor of StarkTranscript
Description
This PR does as small reorganization of the code of stark/src/transcript.rs adds sample_z_ood to the StarkTranscript trait. It also moves constants only used by StoneProverTranscript to its implementation. And replaces the hasher attribute by a state.

Codecov Report

Merging #574 (25b5917) into main (da688cd) will decrease coverage by 0.01%.
The diff coverage is 96.96%.

@@            Coverage Diff             @@
##             main     #574      +/-   ##
==========================================
- Coverage   95.50%   95.50%   -0.01%
==========================================
  Files         112      112
  Lines       19006    19003       -3
==========================================
- Hits        18152    18149       -3
  Misses        854      854

Files Changed
Coverage Δ

provers/stark/src/transcript.rs
99.73% <96.77%> (-0.01%)
:arrow_down:

provers/stark/src/prover.rs
99.86% <100.00%> (-0.01%)
:arrow_down:

provers/stark/src/verifier.rs
98.87% <100.00%> (-0.01%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Poisson regression is not a good model for filtering variants anymore

Genomic diversity has undergone bottlenecks, so much of the variation in divergence has been restarting from more recent common ancestors.

This isn't really an issue in the sense that current variation is much narrower than expected under the Poisson model

Also see #385


feat: Start publishing jars

We need to start publishing jars do DataHub can use them.

Before we start doing this, if we don't touch the code here are the jars we'll make today:

ebean-dao
elasticsearch-dao
li-utils
metadata-dao
metadata-restli-resource
metadata-test-models
metadata-test-utils
metadata-utils
metadata-validators
neo4j-dao

@mars-lan thoughts on this? I'd propose the following changes:

Drop the "metadata" prefix from packages.
Rename li-utils to urn
Delete metadata-test-utils entirely.
a. Neo4j and ES shouldn't be used in the same module to avoid the dependency. If we need these, they can move to their own modules.
b. TestUtils doesn't do much and can easily be embedded.
c. AuditStamps, while nice also isn't doing a ton. I don't think it justifies the existence of a "utils" module. We could move it to test-models. However, this file may be more widely used by DataHub and within LinkedIn. At the very least maybe we can just drop the "utils" from the module name; it it'd just be testing.
Move metadata-utils back into datahub. Code is used mostly by jobs and can move back when the "job libraries" move.

So after that we'd be left with:

ebean-dao
elasticsearch-dao
urn
dao
restli-resource
test-models
testing
validators
neo4j-dao

Could also rename metadata-dao to dao-api instead.

Do we really want to rename everything? That means a lot of changes internally as well.

We already need internal changes when we switch from internal to external jars.
We don't have to rename anything, this is just a good time to do it if we want to :)

Agree. Some of these can use a better name :)

Any specific ideas or do I have carte blanche here? I'd rather discuss what we want upfront than in a PR.

dao sounds a bit too generic and confusing. Maybe rename it to dao-api or something?
Maybe rename restli-resource to restli-resources so it's consistent with the others?
li-utils contains more than just URN, unless you plan to move non-URN code/models out of the module?
Agree that metadata-utils should be moved back to datahub and maybe split into factories and elasticsearch-support or something.

Ok, sounds good, except 3. Maybe base-models or something instead of urn?

base-models can be misleading. Naming is the hardest thing in CS :)

core-models?

core-models SGTM


Only suggest topics associated with at least one board report

Regardless of whether the query is the preferred or alternative term, we should only suggest topics if they're associated with board reports.

Update: I tried to accomplish this using the minDocs filter, which I took to be an indication of how many documents were tagged with a term in SmartLogic. Per Steve, that's not quite right:

Mindocs is a filter where we could indicate how many resources in a system like Legistar had that concept attached. This value had to be periodically calculated from the source system and set for each concept. For Metro they’re all zero so not helpful.

He suggested that we might perform and store this count on our end, but in my view, it makes a lot more sense for it to be performed at the SmartLogic level, since their system is already set up to ingest this data.
@shrayshray, Steve mentioned that he'd need to extend the SmartLogic-Legistar bridge for this count to be accurate, and that he'd talk to you all about it. Once it's in place, this will be a trivial change on our end, but until then, I'd unfortunately consider us blocked.

@hancush would it be possible to do something like query the Legistar API each night to get a list of all terms used in MatterIndexes (exclude duplicates) and use that list to check and exclude those which are not used?

@shrayshray It would be possible for us to do that, however if the SmartLogic-Legistar bridge is already set up to store that information and already does a nightly sync with Legistar, it would make more sense for that operation to happen at the SmartLogic level. Then, we could make a tiny change on our end to exclude unused indexes from suggestions.
With all that said, I think it would good idea to have a call with you and Steve to discuss options and figure out what makes most sense and will be most cost effective for you all.

Look into adding indication of how frequently a suggested term is used (or even ordering suggestions by frequency).
Goal: Minimize dead end suggestions, without preventing legitimate searching.

@shrayshray @camachoo I've staged this improvement. You can compare suggestions (from the search box) and related terms (on the search results page) between the staging site and the live site.
Here's an example using my go-to term, "red".
Original (live site):

Improved (staging):

What do you think? Does this represent an improvement?

@shrayshray Do you think you'll have time to review this before next week's meetings? If not, I'll go ahead and deploy the update to the meeting status logic so we can test out the revision to the concluded tag. (Can't have both at once.)

@hancush i need to take a closer look at this, so please deploy the update to the meeting status logic instead.

Will do, @shrayshray, thank you!

@hancush could you help me understand why limiting the suggestions in the search box to only terms tagged on at least one board report would impact what shows in the related terms section of the search results? I'm extra confused about why this limitation would lead to more related terms listed, rather than fewer.
@camachoo Do you think it would be better to include terms which aren't tagged on any reports in the search suggestions (E.g., all the stages of the Red Line, so people know other stages exists, even if they return zero results)? The example Hannah used in the screen shots has me second guessing myself.

@shrayshray Oh, I didn't realize you'd like related terms to stay the same!  That's not a problem – I can preserve the original behavior of related terms while restricting search suggestions to only terms related to at least one board report. How's that soung?

@hancush yes, let's stick with what we had before for the related terms section. @camachoo could you weigh in on my previous comment on the suggestions in the screenshot above?

@camachoo Do you think it would be better to include terms which aren't tagged on any reports in the search suggestions (E.g., all the stages of the Red Line, so people know other stages exists, even if they return zero results)? The example Hannah used in the screen shots has me second guessing myself.

Table for now. We'll see how federated search tech works via testing, then circle back.


Change default folder to wiki

⚠ this is a breaking change.... BUT i think that's ok since we are still at v0 with specific tags i.e. no risk of a v0.2 (which doesn't exist btw) suddenly breaking
this PR would... checkboxes track draft

[x] change readme option text to match
[x] change action.yml default value
[x] change action.yml text
[x] OPTIONAL: change example to be non-default? like "my-wiki" or something?
[x] move test folder from .github/wiki to wiki/

discussed in #33
biggest proponent:

a point in favor of wiki vs .github/wiki is its prevalence in existing repos and the convention of where wiki docs are put: 137,000 in /wiki/**.md vs 154 in /.github/wiki/**.md -- pretty stark difference 🤪

@spenserblack ready for review

I think perhaps we should see what other users do. Do they often override the default folder to be /wiki/? I have a weirdly strong opinion about .github/wiki, but I'll change my mind if I'm obviously outvoted :slightly_smiling_face:

I can tell this is going nowhere with #81 in progress 😅


Add diagnostics to components

We might need to use dask.distributed for this, see #395

The LocalCluster already provides an interactive dashboard, which is accessible when the pipeline is running on your local machine. However, accessing the dashboard becomes less straightforward when the pipeline is not deployed locally. In such cases, it necessitates port forwarding to the Kubernetes pod or the remote VM in order to access the dashboard.
Dask dashboard
Maybe we could leverage the data explorer to accessing the dashboard more easy.
We have the option to store dashboard exports as static html files in cloud buckets by following the
following the documentation:
from dask.distributed import performance_report

with performance_report(filename="dask-report.html"):
    ## some dask computation

Additionally we could enable the access to the exported html files through the data explorer. However, I am not sure if a streamlit application is still the best option for rendering complete static html files.
For accessing the dashboard of the current run, we should make an effort to document the process of port-forwarding. The implementation of a general solution may be challenging due to the substantial variability in execution environments, and it is probably not possible for every execution environment (e.g. Vertex).
Further diagnostics
The dask dashboard provides valuable insights into the execution of dask. However, it might be a bit overwhelming and unintuitive if you see it for the first time. The most important metrics are not clear on the first point of view, e.g.:

The number of partitions being processed.
The overall progress of the pipeline.
Memory profiling at the partition level, specifically, the RAM requirements for processing individual partitions.
...

We could add a diagnostics class with the capability to log various metrics. These metrics can also be exported to a cloud bucket. Furthermore, we could implement simple visualizations for these metrics inside the fondant explorer. For instance, a basic progress bar could be used to visually represent the progress of individual pipeline steps.

Thanks for the breakdown @mrchtr
I agree with your suggestions:

Let's export the dashboard. Since it's exported as html, it shouldn't be too hard to show it. As a first step we could even just log the (authenticated) url where it's saved which the user can then open in a browser directly.
Let's document how to access the dashboard. By documenting this it will become clear for us as well if there are steps we can automate.

FYI, it should be possible to expose the dashboard on Vertex as well (link.-,enableDashboardAccess,-boolean))

Let's focus on improving the logging of valuable metrics so they can at least be used for debugging.

I think these actions will already provide a lot of benefit, and after adding them, we'll have a better view on which further steps would be most useful.


Add configs management

Info

Config model, the corresponding serializer ConfigSerializer and ConfigViewSet have been created. This makes it possible to store configurations in the database, as well as manage them (CRUD).
The source of per_conf attributes and report configurations getting has been changed. Now this data is obtained from the corresponding database configuration objects.

Overview of changes
Models
Config model contains  configuration information.
Fields:

created (timestamp of the config creation);
type (configuration type. All available types are contained in the ConfigTypes class);
name (configuration name. The namespace for global configurations is limited. All available global configuration names are contained in the GlobalConfigNames class);
version (configuration version);
is_current (validity flag. For each type-name pair, only one configuration can have is_current=True);
description (configuration description. May be blank);
user (creator of the object);
content (configuration content in JSON format).

Methods:

get_latest_version() class method is used to get the latest version of the configuration with the passed type and name;
get_current_version() class method is used to get current version of the configuration with the passed type and name;
delete() method. Redefined so that if a current version is deleted, the latest version is marked as current.

Serializers
ConfigSerializer — Config model serializer.
Methods:

new_version() method is used to get the version value for a new object;
update_data() method is used to update initial data with created time, version and user ID;
get_data() method is used to get data from an object and/or data with which the serializer was initialized;
ensure_json() method is used to convert content to JSON;
get_json_schema() method is used to get a JSON schema corresponding to the type and name of the configuration that will be used for content validation;
validate_name() method used to validate the value passed as the name for the global configuration;
validate_content() method is used to validate content using the appropriate JSON schema;
get_or_create() method is used to get an object by content or create a new one;
create() method. Redefined so that the new object becomes the only one current for its type-name.

API. Configurations
ConfigViewSet have been created.
Here is a list of new endpoints and some description of how to work with them.

Note!
All methods require administrator permission. The access_token is retrieved from request cookies.

1. api/v2/config/
Allows you to get a list of current configurations.
Allowed methods: GET
Response data:
[
    {
        "id": 8,
        "type": "report",
        "name": "dpdk-ethdev-ts",
        "description": "Performance report config for dpdk-ethdev-ts",
        "created": "2024-08-13T14:29:30.598176Z"
    },
    {
        "id": 1,
        "type": "global",
        "name": "per_conf",
        "description": "The main project config",
        "created": "2024-08-12T15:35:08.555075Z"
    }
]

Response status code: 200
2. api/v2/config/<ID>
Allows you to CRUD configurations.
Allowed methods: GET, POST, PATCH, DELETE
GET
Allows you to get configuration data.
Response data:
{
    "created": "2024-08-13T14:29:30.598176Z",
    "type": "report",
    "name": "dpdk-ethdev-ts",
    "version": 0,
    "is_current": true,
    "description": "Performance report config for dpdk-ethdev-ts",
    "user": 1,
    "content": {
        "tests": {
            "testpmd_txonly": {
                "axis_x": "testpmd_command_txpkts",
                "axis_y": [
                    {
                        "keys": {
                            "Side": [
                                "Tx"
                            ]
                        },
                        "type": [
                            "throughput"
                        ]
                    },
                    {
                        "aggr": [
                            "mean"
                        ],
                        "keys": {
                            "Side": [
                                "Tx"
                            ]
                        },
                        "type": [
                            "pps"
                        ]
                    }
                ],
                "chart_view": true,
                "table_view": true,
                "not_show_args": {},
                "records_order": [],
                "sequence_group_arg": "testpmd_arg_txq",
                "percentage_base_value": 1,
                "sequence_name_conversion": {}
            }
        },
        "title_content": [
            "CAMPAIGN_DATE",
            "CFG"
        ],
        "test_names_order": [
            "testpmd_txonly"
        ]
    }
}

Response status code: 200
POST
Allows you to create configuration.
POST request data:
{
    "type": <configuration type>,
    "name": <configuration name>,
    "description": <configuration description>,
    "content":  <configuration content>
}

Validation info:

type: only global and report are available (now), required;
name: only per_conf is available for global (now), required;
description: may be blank;
content: must be in JSON format and conform to the corresponding JSON schema; required.

Possible cases and responses:

Provided invalid name for global
Response data:

{
    "type": "ValidationError",
    "message": {
        "name": [
            "Unsupported global config name. Possible are: ['per_conf']"
        ]
    }
}

Response status code: 400

Provided invalid content
Response data:

{
    "type": "ValidationError",
    "message": {
        "content": [
            "Invalid format: 'PROJECT' is a required property"
        ]
    }
}

Response status code: 400

All data provided is valid
Response data:

{
    "created": "2024-08-13T15:01:05.413804Z",
    "type": "report",
    "name": "dpdk-ethdev-ts",
    "version": 1,
    "is_current": true,
    "description": "Updated performance report config for dpdk-ethdev-ts",
    "user": 1,
    "content": {
        "title_content": [
            "CAMPAIGN_DATE",
            "CFG"
        ],
        "test_names_order": [
            "testpmd_rxonly"
        ],
        "tests": {
            "testpmd_rxonly": {
                "table_view": true,
                "chart_view": true,
                "axis_x": "packet_size",
                "axis_y": [
                    {
                        "type": [
                            "throughput"
                        ],
                        "keys": {
                            "Side": [
                                "Rx"
                            ]
                        }
                    },
                    {
                        "type": [
                            "pps"
                        ],
                        "keys": {
                            "Side": [
                                "Rx"
                            ]
                        },
                        "aggr": [
                            "mean"
                        ]
                    }
                ],
                "sequence_group_arg": "testpmd_arg_rxq",
                "percentage_base_value": 1,
                "sequence_name_conversion": {},
                "not_show_args": {},
                "records_order": []
            }
        }
    }
}

Response status code:

201 (if created)
302 (if configuration with the same content already exist)

PATCH
Allows you to update configuration.
PATCH request data:
{
    "description": <configuration description>,
    "content":  <configuration content>
}

Validation info:

description: may be blank;
content: must be in JSON format and conform to the corresponding JSON schema.

Possible cases and responses:

Invalid data was provided (see POST cases)
All data provided is valid
PATCH request data:

{
    "description": "Updated description for dpdk-ethdev-ts report config",
    "content": {
        "title_content": [
            "CAMPAIGN_DATE",
            "CFG"
        ],
        "test_names_order": [
            "testpmd_rxonly"
        ],
        "tests": {
            "testpmd_rxonly": {
                "table_view": false,
                "chart_view": true,
                "axis_x": "packet_size",
                "axis_y": [
                    {
                        "type": [
                            "throughput"
                        ],
                        "keys": {
                            "Side": [
                                "Rx"
                            ]
                        }
                    },
                    {
                        "type": [
                            "pps"
                        ],
                        "keys": {
                            "Side": [
                                "Rx"
                            ]
                        },
                        "aggr": [
                            "mean"
                        ]
                    }
                ],
                "sequence_group_arg": "testpmd_arg_rxq",
                "percentage_base_value": 1,
                "sequence_name_conversion": {},
                "not_show_args": {},
                "records_order": []
            }
        }
    }
}

Response data:
{
    "created": "2024-08-14T08:25:37.237821Z",
    "type": "report",
    "name": "dpdk-ethdev-ts-rxonly",
    "version": 0,
    "is_current": true,
    "description": "Updated description for dpdk-ethdev-ts report config",
    "user": 1,
    "content": {
        "title_content": [
            "CAMPAIGN_DATE",
            "CFG"
        ],
        "test_names_order": [
            "testpmd_rxonly"
        ],
        "tests": {
            "testpmd_rxonly": {
                "table_view": false,
                "chart_view": true,
                "axis_x": "packet_size",
                "axis_y": [
                    {
                        "type": [
                            "throughput"
                        ],
                        "keys": {
                            "Side": [
                                "Rx"
                            ]
                        }
                    },
                    {
                        "type": [
                            "pps"
                        ],
                        "keys": {
                            "Side": [
                                "Rx"
                            ]
                        },
                        "aggr": [
                            "mean"
                        ]
                    }
                ],
                "sequence_group_arg": "testpmd_arg_rxq",
                "percentage_base_value": 1,
                "sequence_name_conversion": {},
                "not_show_args": {},
                "records_order": []
            }
        }
    }
}

Response status code:

200 (if content was not provided)
201 (if new content was provided)
302 (if object with passed content already exist)

DELETE
Allows you to delete configuration.
Response status code: 204
3. api/v2/config/<ID>/mark_as_current
Allows you to mark the configuration version as current.
Allowed methods: PATCH
Response status code: 204
4. api/v2/config/<ID>/all_versions
Allows you to get all versions of the passed configuration.
Allowed methods: GET
Response data:
{
    "type": "report",
    "name": "dpdk-ethdev-ts",
    "all_config_versions": [
        {
            "id": 25,
            "is_current": false,
            "description": "Report config for dpdk-ethdev-ts",
            "created": "2024-08-14T13:34:15.862297Z"
        },
        {
            "id": 26,
            "is_current": true,
            "description": "Updated report config for dpdk-ethdev-ts",
            "created": "2024-08-14T13:34:38.636108Z"
        }
    ]
}

Response status code: 200
5. api/v2/config/create_by_per_conf
Allows you to automatically create a global configuration based on the existing per_conf.py.
Allowed methods: POST
Response data:
{
    "created": "2024-08-14T10:02:25.797643Z",
    "type": "global",
    "name": "per_conf",
    "version": 0,
    "is_current": true,
    "description": "The main project config",
    "user": 1,
    "content": {
        "CSRF_TRUSTED_ORIGINS": [
            "https://<host_name>/"
        ],
        "DASHBOARD_HEADER": {
            "ts_name": "Test Suite",
            "configuration": "Configuration",
            "status": "Status",
            "total": "Total",
            "unexpected": "NOK",
            "progress": "Executed",
            "notes": "Notes"
        },
        "DASHBOARD_PAYLOAD": {
            "configuration": "go_run",
            "total": "go_tree",
            "unexpected": "go_run_failed",
            "notes": "go_bug"
        },
        "DASHBOARD_RUNS_SORT": [
            "start"
        ],
        "EMAIL_PROJECT_WATCHERS": [],
        "FILES_TO_GENERATE_METADATA": [
            "metadata.txt"
        ],
        "PROJECT": "project-name",
        "RUN_COMPLETE_FILE": ".finished",
        "RUN_KEY_METAS": [
            "START_TIMESTAMP"
        ],
        "RUN_STATUS_BY_NOK_BORDERS": [
            20.0,
            80.0
        ],
        "RUN_STATUS_META": "run_status",
        "SPECIAL_CATEGORIES": [
            "Test Suite",
            "Configuration"
        ]
    }
}

Response status code:

201 (if created)
302 (if configuration with the same content already exist)

API. Reports
Now the source of configurations for reports is a database.
The format of the list of available configurations has been changed!
Example:
Request: GET /bublik/api/v2/report/<run ID>/configs/
Response data:
{
    "run_report_configs": [
        {
            "id": 26,
            "created": "2024-08-14T13:34:38.636108Z",
            "name": "dpdk-ethdev-ts",
            "version": 1,
            "description": "Updated report config for dpdk-ethdev-ts"
        },
        {
            "id": 27,
            "created": "2024-08-14T14:03:00.927002Z",
            "name": "dpdk-ethdev-ts-txonly",
            "version": 0,
            "description": "TXonly report config for dpdk-ethdev-ts"
        }
    ]
}

Response status code: 200

Note!
The key invalid_report_config_files is no longer supported.

Other
Now the source of per_conf attributes is the database. If the corresponding object is not in the database, an exception is raised:
Response data:
{
    "type": "ObjectDoesNotExist",
    "message": "You need to move the contents of per_conf.py to the DB by creating a global per_conf config object"
}

Response status code: 500

I think I should be able to get JSON schemas by type from an API in case we update them so I can fetch them dynamically for validation purposes
https://github.com/ol-nata/bublik/blob/develop/configs/bublik/data/schemas/per_conf.json

We should be able to on/off config version.
If no version active, whole config is inactive and option is not displayed at the report dropdown for example
If one version active whole config should be active and option should display at the report
We also should all configs on the sidebar so active and inactive configs should be returned by default for config list


Spelling error - iff

http://swiftdoc.org/v2.2/type/AnyBidirectionalCollection/#func-contains_
Returns true iff an element in self satisfies predicate.

Hi @proyb6! "iff" is short for "if and only if"—it's a tighter constraint on what comes after. FWIW, those comments come directly from the Swift standard library's generated header. There's no editing of those at all.


callbacks changed to be called on the main thread rather than background

Unless there is a good reason as to why callbacks are called on a background thread, they should be called on the main thread. It’s very likely that most users will be doing UI stuff in these callbacks.

Totally in agreement. I think this is a leftover from the cloudkit/healthkit stuff.

+1


Stuck in the starting of kong

Error: /usr/local/share/lua/5.1/kong/tools/utils.lua:708: error loading module 'kong.plugins.oidc.handler':
/usr/local/share/lua/5.1/kong/plugins/oidc/handler.lua:1: module 'kong.plugins.base_plugin' not found:No LuaRocks module found for kong.plugins.base_plugin

I installed the plugin via luarocks install oicd
also tried to follow this tutorial: https://dev.to/robincher/securing-your-site-via-oidc-powered-by-kong-and-keycloak-2ccc
in my kong.conf I am using plugins = bundled,oidc
How can I get this working? Is it a dependency issue?

I was able to resolve the problem, with the latest version - I needed to remove the plugin first, change the filename of the rockspec to fit the format and make the whole thing. now I am running the latest version.


Merge pull request for extending README.md

Added Information 4 installatio from AUR.
See also Issue conversations #39

@TheRojam I added link toy your package in README, thank you.


Multiple exclusion for RequestPath

Health request exclusion works fine, but when I call my api it loads redoc and other js or json files
This works fine
Filter.ByExcluding("RequestPath like '/health%'")
but following does not
Filter.ByExcluding("RequestPath like '/health%' or '/redoc%'")
following does not even compile
Filter.ByExcluding("RequestPath like '/health%' or like '/redoc%'")
Second or(i.e. redoc) is still logged. Anything I am doing wrong?

Hi! You'll need:
Filter.ByExcluding("RequestPath like '/health%' or RequestPath like '/redoc%'")

HTH!

Hi! You'll need:
Filter.ByExcluding("RequestPath like '/health%' or RequestPath like '/redoc%'")

HTH!

yes this worked thank you

Great, thanks for the follow-up 👍


az login issue callback fails with NoneType

Describe the bug
Command Name
az login
Errors:
:open_mouth:

'NoneType' object is not callableTraceback (most recent call last):
  File "/Users/jeroen/Library/Python/3.6/lib/python/site-packages/knack/cli.py", line 206, in invoke
    cmd_result = self.invocation.execute(args)
  File "/Users/jeroen/Library/Python/3.6/lib/python/site-packages/azure/cli/core/commands/__init__.py", line 326, in execute
    raise ex
  File "/Users/jeroen/Library/Python/3.6/lib/python/site-packages/azure/cli/core/commands/__init__.py", line 384, in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
  File "/Users/jeroen/Library/Python/3.6/lib/python/site-packages/azure/cli/core/commands/__init__.py", line 377, in _run_job
    six.reraise(*sys.exc_info())
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/six.py", line 693, in reraise
    raise value
  File "/Users/jeroen/Library/Python/3.6/lib/python/site-packages/azure/cli/core/commands/__init__.py", line 354, in _run_job
    result = cmd_copy(params)
  File "/Users/jeroen/Library/Python/3.6/lib/python/site-packages/azure/cli/core/commands/__init__.py", line 145, in __call__
    return self.handler(*args, **kwargs)
  File "/Users/jeroen/Library/Python/3.6/lib/python/site-packages/azure/cli/core/__init__.py", line 451, in default_command_handler
    return op(**command_args)
  File "/Users/jeroen/Library/Python/3.6/lib/python/site-packages/azure/cli/command_modules/profile/custom.py", line 133, in login
    use_cert_sn_issuer=use_cert_sn_issuer)
  File "/Users/jeroen/Library/Python/3.6/lib/python/site-packages/azure/cli/core/_profile.py", line 190, in find_subscriptions_on_login
    tenant, self._ad_resource_uri, authority_url)
  File "/Users/jeroen/Library/Python/3.6/lib/python/site-packages/azure/cli/core/_profile.py", line 787, in find_through_authorization_code_flow
    result = self._find_using_common_tenant(token_entry[_ACCESS_TOKEN], resource)
  File "/Users/jeroen/Library/Python/3.6/lib/python/site-packages/azure/cli/core/_profile.py", line 829, in _find_using_common_tenant
    client = self._arm_client_factory(token_credential)
  File "/Users/jeroen/Library/Python/3.6/lib/python/site-packages/azure/cli/core/_profile.py", line 751, in create_arm_client_factory
    base_url=self.cli_ctx.cloud.endpoints.resource_manager))
TypeError: 'NoneType' object is not callable

To Reproduce:
Steps to reproduce the behavior. Note: Command arguments have been redacted.

Fill in additional info here
Run: az login

Expected Behavior
A clear and concise description of what you expected to happen.
Environment Summary
Darwin-18.5.0-x86_64-i386-64bit
Python 3.6.4
Shell: bash

azure-cli                         2.0.62

Additional Context
Add any other context about the problem here.

@jeroendelooze, do you remember how did you install the Azure CLI? To me, it appears the azure-mgmt-resource library is missing or at least not installed correctly.
CC @marstr

Same issue, installed on Windows with pip install azure-cli in Anaconda. Seems azure-cli is broken, lots of errors like this now!

It seems azure-mgmt-resource is missing. Please check https://github.com/Azure/azure-cli/issues/11236#issuecomment-564244983. As this issue is regarding an old version of Azure CLI. If the error persists, please create a new issue. Thanks.


Decide how to document our component JavaScript API

What
On the Design System website, we have documentation for each component that tells users about the Nunjucks API (macro options). We should decide how we will document any public JavaScript methods that a user needs to know about, e.g: init methods and any public functions they may need to hook into or call for certain components (for example, character count).
It may make sense to pick this work up after we've completed https://github.com/alphagov/govuk-frontend/issues/1722
Why
So we have a plan for how to inform users about what JavaScript methods are available to them, when they might need to use them and why. We should make sure this information is easily discoverable rather than relying on users digging into our code on Github to find out more.
This work will become more important as we pick up more complex components, like modals, when it's likely users will need to interact with our JavaScript functions more.
Who needs to work on this
Developers; Tech Writer; potentially Design too
Who needs to review this
Developers; Tech Writer
Done when

[ ] We've identified the best place to put this documentation, e.g: on Github vs the design system website vs the frontend docs
[ ] We know how the documentation should look and be structured on the page
[ ] We've written up these decisions

Note: this card does not include actually writing and publishing the documentation. There is a separate card for drafting and publishing the documentation

Closing as we're now publishing our JavaScript API Reference as part of the frontend docs


We should actually try and decompress the requests if reading the body succeeds.

Fixes #459

@leth I can't merge anymore...


44

ℹ Repository information
The repository has:

[ ] At least three issues with the good first issue label.
[ ] At least 10 contributors.
[ ] Detailed setup instructions for the project.
[ ] CONTRIBUTING.md
[ ] Actively maintained.

I have updated this file


Any errors from postinstall script invoking db/admin.pl are not shown

If you run the postinstall script without first creating the traffic_ops database in postgres, the script will fail with the message (per #3251):
Wed Jan 23 13:19:43 2019: INFO Setting up the database data
Wed Jan 23 13:19:43 2019: ERROR Database load_schema failed

This is not informative to the user at all. When you run the load_schema command directly using db/admin --env=integration load_schema, the following error is shown:
Creating database tables.
psql: FATAL:  database "to_integration" does not exist
Can't create database tables

That error output should be displayed in the output of _postinstall so that the user knows that the database needs to be created first.
Also, the db/admin.pl script is now deprecated and should be replaced with the binary db/admin before the Perl script is removed in a future release.

I believe this was fixed when postinstall was rewritten to Python. It appears to at least log it at the debug level now.


Update drone to 0.8

Coverage decreased (-0.02%) to 59.856% when pulling eb6df0931aae75101e96f50571b54c5f42dd5bd7 on wy65701436:debut-new-drone into c67e6e27587fe861306e52dd41fd6507f2f255fc on vmware:master.


Improve binary size of generated code

Potential improvements:

Enable pragma Restrictions (No_Exceptions)
Enable pragma Restrictions (No_Secondary_Stack)

The code size will be calculated by the size of the .text section of the generated binary minus the size of the .text section of a reference binary that is built from an empty main procedure.

I have done some analysis. With the method of calculating the size from the .text sections we still get approx. 160-170 KB. I have looked up another approach and it's possible to get the symbol size with the following command (the binary must not be stripped for this to work):
arm-eabi-nm --print-size --size-sort --radix=d obj/main

Most of the symbols are quite small, with 4 exceptions (sizes are decimal):
134217748 00015984 t main__responder__tick.5515
134243992 00029452 T rflx__spdm__request__get_field_value
134330152 00040700 T rflx__spdm__response__set_field_value
134273444 00050848 T rflx__spdm__request__verify

All of them have in common that they contain huge case statements (multiple hundred cases). Set_Field_Value and Get_Field_Value also have 30 to 40 instances of RFLX_Types.Extract and RFLX_Types.Insert respectively.
Knowing that generics increase the code size, we have to find a better way to express the functionality, than with generics. Looking at the fact that not all of these subprograms have generics, but all of them contain huge case statements, we may have to find another solution for this.

I have also identified these large case statements as major sources of proof slowness. So refactoring that would be doubly beneficial.

All of them have in common that they contain huge case statements (multiple hundred cases). Set_Field_Value and Get_Field_Value also have 30 to 40 instances of RFLX_Types.Extract and RFLX_Types.Insert respectively.
Knowing that generics increase the code size, we have to find a better way to express the functionality, than with generics.

I wonder if the generic instances have actually a big impact on the code size. These generic functions just consist of one function call. So I would expect the impact to be rather small.

I have also identified these large case statements as major sources of proof slowness. So refactoring that would be doubly beneficial.

@kanigsson I think then it would make sense that you have a look at how the mentioned functions could be improved (also as part of #767).

@kanigsson I think then it would make sense that you have a look at how the mentioned functions could be improved (also as part of #767).

I agree.

No_Secondary_Stack will be handled in #911.

This is unexpected, especially given -Os. Can you try to disable inlining completely (either globally or by adding No_Inline in the code generator) and see where we end up?

So I just got the hint to use -fno-inline and trying that out it indeed reduces the size of the code from 170kb to 120kb.

I noticed another source of problems. E.g. in Verify there is a large case statement that looks as follows:
case Fld is
   when F_Major_Version .. F_Negotiate_Algorithms_Request_Req_Alg_Structs =>
      Ctx.Verified_Last := ((Field_Last (Ctx, Fld) + 7) / 8) * 8;
   when F_Get_Digests_Request_Param_1 =>
      Ctx.Verified_Last := ((Field_Last (Ctx, Fld) + 7) / 8) * 8;
   when F_Get_Measurements_Request_Reserved_1 =>
      Ctx.Verified_Last := ((Field_Last (Ctx, Fld) + 7) / 8) * 8;
   when F_Get_Version_Request_Param_1 =>
      Ctx.Verified_Last := ((Field_Last (Ctx, Fld) + 7) / 8) * 8;
   when F_Key_Exchange_Request_Measurement_Summary_Hash_Type =>
      Ctx.Verified_Last := ((Field_Last (Ctx, Fld) + 7) / 8) * 8;
   when F_Key_Update_Request_Key_Operation =>
      Ctx.Verified_Last := ((Field_Last (Ctx, Fld) + 7) / 8) * 8;
   when F_Negotiate_Algorithms_Request_Req_Alg_Struct_Count =>
      Ctx.Verified_Last := ((Field_Last (Ctx, Fld) + 7) / 8) * 8;

You get the idea. This statement can be reduced to:
case Fld is
   when F_Major_Version .. F_Negotiate_Algorithms_Request_Req_Alg_Structs =>
      Ctx.Verified_Last := ((Field_Last (Ctx, Fld) + 7) / 8) * 8;
end case;

This change for this single instance alone reduces the code size by 6kb.

Adding -gnatp suppresses all checks. This brings the binary size down to ~70kb.

I noticed another source of problems. E.g. in Verify there is a large case statement that looks as follows:

That is related to #644. This case statement was introduced to increase the provability of the context predicate.

That is related to #644. This case statement was introduced to increase the provability of the context predicate. All branches contain the exact same statement. There are more instances of this.

Do you mean #664?

Yes, you are right. That was a typo.

Is there a way to easily reverse this behaviour?

Removing these case statements in the code generator is quite simple. There are three instances in rflx/generator/parser.py (all marked with Componolit/RecordFlux#664).

The currently two largest functions are Get_Field_Value and Set_Field_Value. Their size can be reduced a bit by setting Always_Inline for Extract and Insert however that only contributes to a hew hundred byte of the whole binary. The main reason are probably the large case statements. However in this case I wasn't able to come up with a good solution without breaking the type safety.

One of them is Field_First containing a large case statement. As it is a expression function contains many equal cases I suppose that's to help the provers?
I've taken a look and I think the following should express the same thing without increasing the code size:

Field_First encodes all the First aspects of the model. Using a case statement was the most obvious solution to do that. Using a case statement, is apparently not the best solution, especially as the First aspect is rarely used. We should improve the code generation there. I think your proposed code would only work, if we would put the case statement (or something semantically equivalent) in the post condition. I guess there could be an even simpler solution, using if-expressions only for the cases where an First aspect was defined.
Could you please collect all your findings where the code generator needs to be modified in a task list? I think that would be helpful to keep track.

I think generally we should try to avoid these kind of case statements that include lots of exception raises. Each raise causes a jump to a local exception call. While this is already the most efficient way to call the exception at each case, it still makes up roughly half of the generated code in these functions.

I guess a function call with Pre => False would not be better? That is what we used before.

I guess a function call with Pre => False would not be better? That is what we used before.

That would get rid of the exception code, however it would not get rid of a jump/call in each branch of the case statement. And this is what currently increases the code size. The problem is that the compiler can't infer that these functions will never be called.

I think your proposed code would only work, if we would put the case statement (or something semantically equivalent) in the post condition.

Putting the case statement as is into a post condition shouldn't be a problem in terms of code size since the compiler doesn't compile that. We could also put it into a ghost function and use that.

After some discussions it seems that the aggressive inlining is caused by expression functions. Expression functions are always inlined (see V127-006). With GNAT 23.0w using -gnatd.8 yields slightly better results than using -fno-inline, presumably because functions where inlining is useful are inlined now while the overly aggressive inlining is no longer existing.

I evaluated the current changes. It seems splitting up the Get_* and Set_* functions in general increases the code size. For Get_Field_Value this is the case. However while usually all Get_Field_* functions are at least used once to verify messages, not all Set_Field_Value functions are used. The removal of unused functions has a larger benefit here.
Summarized: we should split up Set_Field_Value but not Get_Field_Value.
Splitting Verify also increases the code size, so we should not do this.
The simplification of Field_First yields a significant gain in code size.
With these changes the code size is slightly below 60kB for RiscV64.
Additionally I found the following potential improvements:
In Verify is a large if-else statement where each branch has the same operation. Given that the compiler was not able to optimize a large case statement with the same property I think we can gain an improvement here.
               if Fld = F_Major_Version then
                  Ctx.Cursors (Successor (Ctx, Fld)) := (State => S_Invalid, Predecessor => Fld);
               elsif Fld = F_Minor_Version then
                  Ctx.Cursors (Successor (Ctx, Fld)) := (State => S_Invalid, Predecessor => Fld);
               elsif Fld = F_Code then
                  Ctx.Cursors (Successor (Ctx, Fld)) := (State => S_Invalid, Predecessor => Fld);
               elsif Fld = F_Challenge_Request_Slot then
                  Ctx.Cursors (Successor (Ctx, Fld)) := (State => S_Invalid, Predecessor => Fld);
               elsif Fld = F_End_Session_Request_Reserved_1 then
                  Ctx.Cursors (Successor (Ctx, Fld)) := (State => S_Invalid, Predecessor => Fld);
               elsif Fld = F_Finish_Request_Reserved then
                  Ctx.Cursors (Successor (Ctx, Fld)) := (State => S_Invalid, Predecessor => Fld);
               elsif Fld = F_Get_Capabilities_Request_Param_1 then
                  Ctx.Cursors (Successor (Ctx, Fld)) := (State => S_Invalid, Predecessor => Fld);

The function Successor is an expression function that returns a specific enum value based on the evaluation of a case statement with nested if-else statements. The problem seems to be the generated code that creates jumps for each case value and then return branches for them:
rflx__spdm__request__successor():
    80004798:   35fd                    addiw   a1,a1,-1
    8000479a:   0ff5f593                zext.b  a1,a1
    8000479e:   05f00713                li      a4,95
    800047a2:   87aa                    mv      a5,a0
    800047a4:   32b76e63                bltu    a4,a1,80004ae0 <rflx__spdm__request__successor+0x348>
    800047a8:   0000b697                auipc   a3,0xb
    800047ac:   a9868693                addi    a3,a3,-1384 # 8000f240 <CSWTCH.337+0x9c0>
    800047b0:   058a                    slli    a1,a1,0x2
    800047b2:   95b6                    add     a1,a1,a3
    800047b4:   4198                    lw      a4,0(a1)
    800047b6:   9736                    add     a4,a4,a3
    800047b8:   8702                    jr      a4
    800047ba:   4545                    li      a0,17
    800047bc:   8082                    ret
    800047be:   08854703                lbu     a4,136(a0)
    800047c2:   4785                    li      a5,1
    800047c4:   4501                    li      a0,0
    800047c6:   38f71b63                bne     a4,a5,80004b5c <rflx__spdm__request__successor+0x3c4>
    800047ca:   4509                    li      a0,2
    800047cc:   8082                    ret
    800047ce:   0b054703                lbu     a4,176(a0)
    800047d2:   4785                    li      a5,1
    800047d4:   450d                    li      a0,3
    800047d6:   38e7f363                bgeu    a5,a4,80004b5c <rflx__spdm__request__successor+0x3c4>
    800047da:   4501                    li      a0,0
    800047dc:   8082                    ret
    800047de:   0d854683                lbu     a3,216(a0)
    800047e2:   08300713                li      a4,131
    800047e6:   4511                    li      a0,4
    800047e8:   36e68a63                beq     a3,a4,80004b5c <rflx__spdm__request__successor+0x3c4>
    800047ec:   0b07c603                lbu     a2,176(a5)
    800047f0:   f1468593                addi    a1,a3,-236
    800047f4:   0006871b                sext.w  a4,a3
    800047f8:   fff60793                addi    a5,a2,-1
    800047fc:   00f037b3                snez    a5,a5
    80004800:   e581                    bnez    a1,80004808 <rflx__spdm__request__successor+0x70>
    80004802:   4515                    li      a0,5
    80004804:   34078c63                beqz    a5,80004b5c <rflx__spdm__request__successor+0x3c4>
    80004808:   f1b70593                addi    a1,a4,-229
    8000480c:   e581                    bnez    a1,80004814 <rflx__spdm__request__successor+0x7c>
    8000480e:   4519                    li      a0,6
    80004810:   34078663                beqz    a5,80004b5c <rflx__spdm__request__successor+0x3c4>
    80004814:   f1f70593                addi    a1,a4,-225
    80004818:   e581                    bnez    a1,80004820 <rflx__spdm__request__successor+0x88>
    8000481a:   451d                    li      a0,7
    8000481c:   34078063                beqz    a5,80004b5c <rflx__spdm__request__successor+0x3c4>
...
    8000487a:   453d                    li      a0,15
    8000487c:   8082                    ret
    8000487e:   4549                    li      a0,18
    80004880:   8082                    ret
    80004882:   454d                    li      a0,19
    80004884:   8082                    ret
    80004886:   4551                    li      a0,20
    80004888:   8082                    ret
    8000488a:   4555                    li      a0,21
    8000488c:   8082                    ret
    8000488e:   4559                    li      a0,22
    80004890:   8082                    ret
    80004892:   455d                    li      a0,23
    80004894:   8082                    ret
    80004896:   4561                    li      a0,24
    80004898:   8082                    ret
    8000489a:   4565                    li      a0,25
    8000489c:   8082                    ret
    8000489e:   4569                    li      a0,26
    800048a0:   8082                    ret
    800048a2:   456d                    li      a0,27
    800048a4:   8082                    ret
    800048a6:   4571                    li      a0,28
    800048a8:   8082                    ret
    800048aa:   4575                    li      a0,29
    800048ac:   8082                    ret
    800048ae:   4579                    li      a0,30
    800048b0:   8082                    ret
    800048b2:   457d                    li      a0,31
    800048b4:   8082                    ret
    800048b6:   02000513                li      a0,32
    800048ba:   8082                    ret
    800048bc:   02100513                li      a0,33
    800048c0:   8082                    ret
    800048c2:   02200513                li      a0,34
    800048c6:   8082                    ret
    800048c8:   02300513                li      a0,35
    800048cc:   8082                    ret

This doesn't seem to be the most efficient code. I suggest assigning the result in a regular function with a case statement to a variable and then returning this variable. This won't remove the branches but it will remove the inefficient return statements. I will also see if this can be a compiler improvement. The generated ARM code doesn't seem to have this particular problem, however the code of this function isn't smaller on ARM. This is especially interesting since the overall ARM code is slight bit smaller.
The function Valid_Predecessor contains a large case statement that could be rewritten as a single boolean expression. I'm not completely sure about the possible improvement, but I would give it a try. Less branching may give the compiler more room for optimization.
I took a look at Structural_Valid_Message and Valid_Message. Without taking a too deep look at the code they seem to share quite a lot of similar functionality. Maybe one is a superset of the other? If so it would make sense to reuse the smaller function.

The simplification of Field_First yields a significant gain in code size.

Does "significant gain in code size" mean it gets bigger and we shouldn't simplify Field_First?

Does "significant gain in code size" mean it gets bigger and we shouldn't simplify Field_First?

I wrote that a bit ambiguous. Let's say a significant improvement. We should definitely keep that simplification.

In Verify is a large if-else statement where each branch has the same operation. Given that the compiler was not able to optimize a large case statement with the same property I think we can gain an improvement here.

That was added for improving provability, but probably it is not required anymore (cf. #920). I have removed that and all other intentional code duplication in Verify for now. This improved the binary size significantly.

The function Successor is an expression function that returns a specific enum value based on the evaluation of a case statement with nested if-else statements. The problem seems to be the generated code that creates jumps for each case value and then return branches for them:
[...]
This doesn't seem to be the most efficient code. I suggest assigning the result in a regular function with a case statement to a variable and then returning this variable. This won't remove the branches but it will remove the inefficient return statements.

Done. This reduced the binary size by 112 byte for DHCP (x86_64).

The function Valid_Predecessor contains a large case statement that could be rewritten as a single boolean expression. I'm not completely sure about the possible improvement, but I would give it a try. Less branching may give the compiler more room for optimization.

Done. This increased the binary size by 352 byte for DHCP (x86_64).

I took a look at Structural_Valid_Message and Valid_Message. Without taking a too deep look at the code they seem to share quite a lot of similar functionality. Maybe one is a superset of the other? If so it would make sense to reuse the smaller function.

Valid_Message is not used by any session code. So changing this function will have no impact on the binary size, as it will be optimized out. We could consider removing this function completely, as I don't see a use case for it in the near future. Valid_Message was just added for consistency. We also differentiate between Structural_Valid and Valid for single fields.
@jklmnn I have updated the issue_908 branch, so that you can analyze the impact of these changes on SPDM.

I was able to significantly simplify the Structural_Valid_Message function (I think it should be semantically equivalent, but that should be verified). This change reduced the binary size for DHCP (x86_64) by 3680 bytes. I'm curious to see how big the impact will be for SPDM.

As expexted, the removal of Valid_Message didn't change the code size at all. It's up to you if you want to keep this commit. The simplification of Structural_Valid_Message yielded a significant improvement in code size (multiple kB).
The refactoring of Successor slightly increases the code size on RiscV64. So far it seems that we already had the best solution. The difference to the generated ARM code are explained by instruction set features. Any other improvement here probably requires some work on the compiler so I'd keep the old version here.
The refactoring of Valid_Predecessor significantly increased the code size. So I think we should stay with the old version here.

On thing I noticed is the function Field_Size. While the Unreachable type removes the necessity for exceptions I think the small case statements could still be reduced.
   function Field_Size (Ctx : Context; Fld : Field) return RFLX_Types.Bit_Length is
     ((case Ctx.Cursors (Fld).Predecessor is
          when F_Initial =>
             (case Fld is
                 when F_Major_Version =>
                    RFLX.SPDM.Major_Version_Base'Size,
                 when others =>
                    RFLX_Types.Unreachable),
          when F_Major_Version =>
             (case Fld is
                 when F_Minor_Version =>
                    RFLX.SPDM.Minor_Version_Base'Size,
                 when others =>
                    RFLX_Types.Unreachable),
          when F_Minor_Version =>
             (case Fld is
                 when F_Code =>
                    RFLX.SPDM.Response_Code_Base'Size,
                 when others =>
                    RFLX_Types.Unreachable),

This could be used as a postcondition (or in a ghost function) while the regular body of Field_Size could be rewritten as:
function Field_Size (Ctx : Context; Fld : Field) return RFLX_Types.Bit_Length
is
begin
   case Ctx.Cursors (Fld).Predecessor is
      when F_Initial =>
         if Fld = F_Major_Version then
            return RFLX.SPDM.Major_Version_Base'Size;
         end if;
      when F_Major_Version =>
         if Fld = F_Minor_Version then
            return RFLX.SPDM.Minor_Version_Base'Size;
         end if;
      ...
   end case;
   return RFLX_Types.Unreachable.
end Field_SIze;

It's hard to say if that generates better code. It could be that the implicit else branches of the if statements create jumps to the return and that there is no gain.
Another thing I was thinking about. Maybe it's possible to add a shortcut for scalar fields that always have the same size? So that there are not two, but only one check for fields like F_Major_Version etc?

Since we're running out of obviously large functions to reduce, I looked at the smaller but much more numerous functions. E.g. there are many Set_* procedures that are around 330 bytes each. They all look as follows:
   procedure Set_Major_Version (Ctx : in out Context; Val : RFLX.SPDM.Major_Version) is
      Field_Value : constant Field_Dependent_Value := (F_Major_Version, To_Base (Val));
      First, Last : RFLX_Types.Bit_Index;
      function Buffer_First return RFLX_Types.Index is
        (RFLX_Types.To_Index (First));
      function Buffer_Last return RFLX_Types.Index is
        (RFLX_Types.To_Index (Last));
      function Offset return RFLX_Types.Offset is
        (RFLX_Types.Offset ((8 - Last mod 8) mod 8));
      procedure Insert is new RFLX_Types.Insert (RFLX.SPDM.Major_Version_Base);
   begin
      Reset_Dependent_Fields (Ctx, F_Major_Version);
      First := Field_First (Ctx, F_Major_Version);
      Last := Field_Last (Ctx, F_Major_Version);
      Insert (Field_Value.Major_Version_Value, Ctx.Buffer.all (Buffer_First .. Buffer_Last), Offset);
      pragma Warnings (Off, "attribute Update is an obsolescent feature");
      Ctx := Ctx'Update (Verified_Last => ((Last + 7) / 8) * 8, Written_Last => ((Last + 7) / 8) * 8);
      pragma Warnings (On, "attribute Update is an obsolescent feature");
      Ctx.Cursors (F_Major_Version) := (State => S_Valid, First => First, Last => Last, Value => Field_Value, Predecessor => Ctx.Cursors (F_Major_Version).Predecessor);
      Ctx.Cursors (Successor (Ctx, F_Major_Version)) := (State => S_Invalid, Predecessor => F_Major_Version);
   end Set_Major_Version;

While we can't index into variant records with non-static discriminants there are still a few operations that are similar for each call:
      Reset_Dependent_Fields (Ctx, F_Major_Version);
      First := Field_First (Ctx, F_Major_Version);
      Last := Field_Last (Ctx, F_Major_Version);

I factored these out as follows:
   procedure Reset_First_Last (Ctx : in out Context; Field : Virtual_Field; First : out RFLX_Types.Bit_Index; Last : out RFLX_Types.Bit_Index)
   is
   begin
      Reset_Dependent_Fields (Ctx, Field);
      First := Field_First (Ctx, Field);
      Last := Field_Last (Ctx, Field);
   end Reset_First_Last;

   procedure Set_Major_Version (Ctx : in out Context; Val : RFLX.SPDM.Major_Version) is
      Field_Value : constant Field_Dependent_Value := (F_Major_Version, To_Base (Val));
      First, Last : RFLX_Types.Bit_Index;
      function Buffer_First return RFLX_Types.Index is
        (RFLX_Types.To_Index (First));
      function Buffer_Last return RFLX_Types.Index is
        (RFLX_Types.To_Index (Last));
      function Offset return RFLX_Types.Offset is
        (RFLX_Types.Offset ((8 - Last mod 8) mod 8));
      procedure Insert is new RFLX_Types.Insert (RFLX.SPDM.Major_Version_Base);
   begin
      Reset_First_Last (Ctx, F_Major_Version, First, Last);
      Insert (Field_Value.Major_Version_Value, Ctx.Buffer.all (Buffer_First .. Buffer_Last), Offset);
      pragma Warnings (Off, "attribute Update is an obsolescent feature");
      Ctx := Ctx'Update (Verified_Last => ((Last + 7) / 8) * 8, Written_Last => ((Last + 7) / 8) * 8);
      pragma Warnings (On, "attribute Update is an obsolescent feature");
      Ctx.Cursors (F_Major_Version) := (State => S_Valid, First => First, Last => Last, Value => Field_Value, Predecessor => Ctx.Cursors (F_Major_Version).Predecessor);
      Ctx.Cursors (Successor (Ctx, F_Major_Version)) := (State => S_Invalid, Predecessor => F_Major_Version);
   end Set_Major_Version;

For up to 2 Set_* procedures this slightly increases the code size, but from the third procedure there is a reduce in size. Each symbol is slightly 10% smaller, the whole binary about 1.5kB.

I found a way to optimize Valid_Predecessor. In the expression function we calculate the predecessor in each case:
   function Valid_Predecessor (Ctx : Context; Fld : Virtual_Field) return Boolean is
     ((case Fld is
          when F_Initial =>
             True,
          when F_Major_Version =>
             Ctx.Cursors (Fld).Predecessor = F_Initial,
          when F_Minor_Version =>
             (Valid (Ctx.Cursors (F_Major_Version))
              and Ctx.Cursors (Fld).Predecessor = F_Major_Version),
          when F_Code =>
             (Valid (Ctx.Cursors (F_Minor_Version))
              and Ctx.Cursors (Fld).Predecessor = F_Minor_Version),

I rebuilt this function into a regular one with a body (which interestingly reduced it's size by 10 bytes) and then precalculated the predecessor:
   function Valid_Predecessor (Ctx : Context; Fld : Virtual_Field) return Boolean
   is
      Predecessor : constant Virtual_Field := Ctx.Cursors (Fld).Predecessor;
   begin
      case Fld is
         when F_Initial =>
            return True;
         when F_Major_Version =>
            return Predecessor = F_Initial;
         when F_Minor_Version =>
            return (Valid (Ctx.Cursors (F_Major_Version))
             and Predecessor = F_Major_Version);
         when F_Code =>
            return (Valid (Ctx.Cursors (F_Minor_Version))
             and Predecessor = F_Minor_Version);

This reduces the size of this function by ca. 400 bytes (ca. 30% of the function). Factoring out the Valid (Ctx.Cursors (F... did not yield any improvement, my guess is that it's already optimized well by the compiler due to inlining and a static discriminant for Ctx.Cursors.
Generally I think it's worth to take a look at other places (in particular large repetitive subprograms) and precalculate record accesses if possible. Each record/array access generates code if the compiler can't infer the target memory statically.

@jklmnn Note that you can use declare expressions (syntax is (declare ... begin ...) with no end) to avoid transforming the function into a regular function. Does the size reduction still apply in that case?

@jklmnn Note that you can use declare expressions (syntax is (declare ... begin ...) with no end) to avoid transforming the function into a regular function. Does the size reduction still apply in that case?

@kanigsson I thought about that, too. Isn't that an Ada 2022 feature? Not sure everybody wants / is able to use that...

Good point, it's indeed an Ada 2022 feature. The problem is that the function is used for proof, and turning it into a regular function will make the body invisible for proof.

Good point, it's indeed an Ada 2022 feature. The problem is that the function is used for proof, and turning it into a regular function will make the body invisible for proof.

That's a problem indeed. I guess we'd have to keep the expression function around as ghost function and then use it in the post condition of the new regular function which probably creates new challenges when proving that post condition for complex cases...

I took a look at the available compiler options. Unless I missed something, the options we currently use seem to be the best we can get. I was able to tune the optimizations done by -Os with:
--param max-grow-copy-bb-insns=1 --param max-crossjump-edges=256 --param max-hoist-depth=0

However this only reduces the code size by 52 bytes.

Let me know when you reach a version that you are happy with from a size point of view and I can try make them prove again.

I'm never happy from a size point of view ;) But for the time being I think you can take a look at the code I posted. I didn't find any further significant improvements.

I found a relatively simple optimization in Composite_Field. Currently it's implemented as a case statement:
(case Fld is
   when F_A | F_B | F_C ... => True,
   when F_X | F_Y | F_Z ... => False);

This can be rewritten as:
(Fld in F_A | F_B | F_C ...);

This yields a significant relative (40%) although small absolute (20 byte) size improvement. I'd still recommend this optimization here since I also think the latter version is better code.

This optimization doesn't seem to work for case statements with many cases. However the reason for this is that the compiler generates jump tables for larger case statements and these reside in .rodata instead of .text. So when they're replaced with something else the size of .text increases because it doesn't use a jump table anymore. I did a simple experiment by replacing a case statement with an if-elsif-else expression. While this increased the size of .text it reduced the size of .rodata by a larger amount.

 I looked at the Successor function which is basically a mapping between fields. It cannot be calculated statically for all fields, but for the large majority of them. So I tried to implement these using a constant array. This array contains all fields, and those without a statically known successor have F_Initial set:
   type Field_Array is array (Field'Range) of Virtual_Field;

   Field_Successor : constant Field_Array :=
      (F_Major_Version => F_Initial,
       F_Minor_Version => F_Initial,
       F_Code => F_Initial,
       F_Challenge_Request_Slot => F_Challenge_Request_Hash_Type,
       F_End_Session_Request_Reserved_1 => F_End_Session_Request_Clear_Negotiated_State,
       F_Finish_Request_Reserved => F_Finish_Request_Signature_Included,
       F_Get_Capabilities_Request_Param_1 => F_Get_Capabilities_Request_Param_2,
       F_Get_Certificate_Request_Slot => F_Get_Certificate_Request_Param_2,
...

I then grouped all statically known fields in Successor into a single case branch that returns Field_Successor (Fld) instead of multiple ones returning their specific successors each.
While this might look like just moving code into the static data, this solution actually reduces both .text and .rodata. The reason is that it reduces the size of the compiler generated jump table and that this array is smaller than the equivalent portion of the jump table.
This can be applied to Successor, possibly Field_Size.  Both functions but especially Successor belong to the larger functions so it makes sense to see if we can implement this optimization (and keep it provable). I tested this on Request.Successor which reduced it's size from 932 to 556 byte (+94 bytes in .rodata, yet the overall size of this section was reduced to 5280 bytes from 5544 bytes). Response.Successor is currently the fourth largest symbol in .text with nearly 1.5kB.

$ gnatprove -Ptest -Xtest=tlv --memcached-server=localhost:11211
Phase 1 of 2: generation of Global contracts ...
Phase 2 of 2: flow analysis and proof ...

rflx-tlv-message.adb:345:41: medium: predicate check might fail
  345 |      Insert (Field_Value.Tag_Value, Ctx.Buffer, Buffer_First, Buffer_Last, Offset, RFLX_Types.High_Order_First);
      |                                     ~~~^~~~~~~

rflx-tlv-message.adb:355:44: medium: predicate check might fail
  355 |      Insert (Field_Value.Length_Value, Ctx.Buffer, Buffer_First, Buffer_Last, Offset, RFLX_Types.High_Order_First);
      |                                        ~~~^~~~~~~

@kanigsson Could you please have a look at that? It is unclear to me what happens here. The only part related to Buffer in the predicate is (if Buffer /= null then Buffer'First = Buffer_First and Buffer'Last = Buffer_Last). Can this property be violated when Buffer is passed as an in parameter to Insert?

I don't think that Insert could actually change the bounds, but gnatprove doesn't currently know that. I am opening a SPARK ticket.

Thanks! I can confirm that adding such a postcondition solves the issue.

I took a look into how we can reduce code (and information) duplication. One thing @treiher and I noticed is that Field_Condition and Path_Condition seem to share the same information encoded differently:
          when F_Code =>
             (case Fld is
                 when F_Challenge_Request_Slot =>
                    RFLX_Types.U64 (Ctx.Cursors (F_Code).Value.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Challenge)),
                 when F_End_Session_Request_Reserved_1 =>
                    RFLX_Types.U64 (Ctx.Cursors (F_Code).Value.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.End_Session))
                    and Ctx.Cursors (F_Minor_Version).Value.Minor_Version_Value = 1,
                 when F_Finish_Request_Reserved =>
                    RFLX_Types.U64 (Ctx.Cursors (F_Code).Value.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Finish))
                    and Ctx.Cursors (F_Minor_Version).Value.Minor_Version_Value = 1,
                 when F_Get_Capabilities_Request_Param_1 =>
                    RFLX_Types.U64 (Ctx.Cursors (F_Code).Value.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Get_Capabilities))
                    and Ctx.Cursors (F_Minor_Version).Value.Minor_Version_Value = 1,
                 when F_Get_Certificate_Request_Slot =>
                    RFLX_Types.U64 (Ctx.Cursors (F_Code).Value.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Get_Certificate)),
                 when F_Get_Digests_Request_Param_1 =>
                    RFLX_Types.U64 (Ctx.Cursors (F_Code).Value.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Get_Digests)),
                 when F_Get_Measurements_Request_Reserved_1 =>
                    RFLX_Types.U64 (Ctx.Cursors (F_Code).Value.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Get_Measurements))
                    and Ctx.Cursors (F_Minor_Version).Value.Minor_Version_Value = 1,
                 when F_Get_Version_Request_Param_1 =>
                    RFLX_Types.U64 (Ctx.Cursors (F_Code).Value.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Get_Version))
                    and Ctx.Cursors (F_Minor_Version).Value.Minor_Version_Value = 0,
                 when F_Key_Exchange_Request_Measurement_Summary_Hash_Type =>
                    RFLX_Types.U64 (Ctx.Cursors (F_Code).Value.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Key_Exchange))
                    and Ctx.Cursors (F_Minor_Version).Value.Minor_Version_Value = 1,
                 when F_Key_Update_Request_Key_Operation =>
                    RFLX_Types.U64 (Ctx.Cursors (F_Code).Value.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Key_Update))
                    and Ctx.Cursors (F_Minor_Version).Value.Minor_Version_Value = 1,
                 when F_Negotiate_Algorithms_Request_Req_Alg_Struct_Count =>
                    RFLX_Types.U64 (Ctx.Cursors (F_Code).Value.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Negotiate_Algorithms))
                    and Ctx.Cursors (F_Minor_Version).Value.Minor_Version_Value = 1,
                 when F_Respond_If_Ready_Request_Original_Request_Code =>
                    RFLX_Types.U64 (Ctx.Cursors (F_Code).Value.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Respond_If_Ready)),
                 when others =>
                    False),

          when F_Code =>
             RFLX_Types.U64 (Val.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Challenge))
             or (RFLX_Types.U64 (Val.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.End_Session))
                 and Ctx.Cursors (F_Minor_Version).Value.Minor_Version_Value = 1)
             or (RFLX_Types.U64 (Val.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Finish))
                 and Ctx.Cursors (F_Minor_Version).Value.Minor_Version_Value = 1)
             or (RFLX_Types.U64 (Val.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Get_Capabilities))
                 and Ctx.Cursors (F_Minor_Version).Value.Minor_Version_Value = 1)
             or RFLX_Types.U64 (Val.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Get_Certificate))
             or RFLX_Types.U64 (Val.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Get_Digests))
             or (RFLX_Types.U64 (Val.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Get_Measurements))
                 and Ctx.Cursors (F_Minor_Version).Value.Minor_Version_Value = 1)
             or (RFLX_Types.U64 (Val.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Get_Version))
                 and Ctx.Cursors (F_Minor_Version).Value.Minor_Version_Value = 0)
             or (RFLX_Types.U64 (Val.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Key_Exchange))
                 and Ctx.Cursors (F_Minor_Version).Value.Minor_Version_Value = 1)
             or (RFLX_Types.U64 (Val.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Key_Update))
                 and Ctx.Cursors (F_Minor_Version).Value.Minor_Version_Value = 1)
             or (RFLX_Types.U64 (Val.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Negotiate_Algorithms))
                 and Ctx.Cursors (F_Minor_Version).Value.Minor_Version_Value = 1)
             or RFLX_Types.U64 (Val.Code_Value) = RFLX_Types.U64 (To_Base (RFLX.SPDM.Respond_If_Ready)),

Both examples encode the conditions of the outgoing links from F_Code, the first in a case statement and the second as a disjunction. The first function could be used to generate the disjunction on the fly without the need to encode the disjunction in code.
The general idea here is to only have a single large case statement (or any other form that works well) that encodes all link conditions and then have all other uses of these link conditions use only this single case statement. If that is an improvement or of the additional code needed to call the function containing the case statement is larger than the case statement itself needs to be verified experimentally.

I took a look at Prepare_Algorithms and one thing I noticed is that it's more efficient to remove the RFLX_Exception variable and directly assign and return from the occurrences that would set it to true. This might seem to be counter intuitive and but it seems that the compiler is capable of optimizing returns in the else branched of nested if statements pretty efficiently.

I took a look at Valid_Predecessor and Successor. In theory both should encode the same information. The reason for that is that we always only have one valid predecessor and one valid successor. It is always possible to get the set predecessor, so if a field is a valid successor of its predecessor its predecessor should also be valid.
I have replaced the implementation of Valid_Predecessor with the following:
   function Valid_Predecessor (Ctx : Context; Fld : Virtual_Field) return Boolean
   is
   begin
      if Fld = F_Initial then
         return True;
      end if;
      if Fld = F_Major_Version then
         return Predecessor (Ctx, Fld) = F_Initial;
      end if;
      return Successor (Ctx, Predecessor (Ctx, Fld)) = Fld;
   end Valid_Predecessor;

The special case for the first field after F_Initial could be removed if Successor had a separate case for F_Initial. This change alone reduces the size of the binary by 3kB.

Another thing that could significantly improve the code size is an improved handling of operations on objects in the spec. For example we have the Check_Algorithms_* states in SPDM that check if a sequence contains at least one element of a specific type. That should be a very simple operation yet it generates a procedure that is 500 bytes large and has 5 nested exception conditions.

The setters for scalar fields can be improved further. Currently they look as follows:
   procedure Set_Capabilities_Response_Reserved_4 (Ctx : in out Context; Val : RFLX.SPDM.Reserved_15) is
      Value : constant RFLX_Types.U64 := To_U64 (Val);
      Buffer_First, Buffer_Last : RFLX_Types.Index;
      Offset : RFLX_Types.Offset;
   begin
      Set (Ctx, F_Capabilities_Response_Reserved_4, Value, 15, True, Buffer_First, Buffer_Last, Offset);
      RFLX_Types.Insert (Value, Ctx.Buffer, Buffer_First, Buffer_Last, Offset, 15, RFLX_Types.High_Order_First);
   end Set_Capabilities_Response_Reserved_4;

They all share the calls to Set, Insert and the local variables. Their only differences are the field name and the type of the value that is later converted to U64. This can be factored out by adding a scalar specific set:
   procedure Set_Scalar (Ctx : in out Context;
                         Fld : Field;
                         Val : RFLX_Types.U64)
   is
      Buffer_First, Buffer_Last : RFLX_Types.Index;
      Offset : RFLX_Types.Offset;
   begin
      Set (Ctx, Fld, Val, 1, True, Buffer_First, Buffer_Last, Offset);
      RFLX_Types.Insert (Val, Ctx.Buffer, Buffer_First, Buffer_Last, Offset, 1, RFLX_Types.High_Order_First);
   end Set_Scalar;

The Set procedures for scalar fields can then be simplified to:
   procedure Set_Capabilities_Response_Reserved_4 (Ctx : in out Context; Val : RFLX.SPDM.Reserved_15) is
   begin
      Set (Ctx, F_Capabilities_Response_Reserved_4, To_U64 (Val));
   end Set_Capabilities_Response_Reserved_4;

This reduces the size of each scalar Set procedure from 74 to 20 bytes. This doesn't sound much, but we have over one hundred of them. A rough estimate would be an improvement around 5kB.

All realistic optimization have been done.


Unable to add additional tabs in code editor frame

Describe the bug
Opening a project with multiple files in StackBlitz should permit opening more than one of those files at a time in the code editor window. However, there is no right-click option to add a file as another tab in the editor ("open with" option exists in VS code context menu), I can't drag a file to the editor to open a new tab beside an existing tab, and there's no "+" button in the editor window to allow me to pick another file to open. In short, there's no obvious way to control tab count in the editor window. Split view isn't what I'm looking for--that works fine.
Instead, clicking on any file in the explorer window results in unpredictable behavior: replace the current open tab with that file or add an additional tab (sometimes but not always).
Link to the blitz that caused the error
Any project, but e.g., https://stackblitz.com/fork/nextjs
Steps to reproduce

Open new stackblitz project template of your choice in a chromium-based or firefox-based browser
Attempt to open two files at once in the same editor window by dragging a file to the tab editor or right-clicking a file or right clicking on the editor window
Le sad...

Expected behavior
Any one of these options would be fine, I wouldn't ask for or expect all of them. I do think it's reasonable to be able to control how many tabs I have open in the editor, at least to some extent.

Right-click on file in explorer window provides option to open a file in a new tab
dragging a file from the explorer window to the top bar of the code editor window allows drag&drop for new tab
right-click on code editor window allows option to add a new tab using a file in the project

Parity with Local

[X] I have run the project in my local machine and I could not reproduce the issue.

Screenshots
No response
Platform
Browser name  = Firefox
Full version  = 107.0
Major version = 107
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:107.0) Gecko/20100101 Firefox/107.0
performance.memory = undefined
Hash = 8cf5a3c77f45c942df800a39619ec49fff7e5814

Additional context
No response

Hey there 👋 Thanks for opening this issue. Our so called v1 editor is a little limited and doesn't implement the full scope of what VSC provides as functionality. However, if you use Codeflow IDE you get full VSC in your browser including dragging files to the side, selecting multiple files and opening them in the editor etc. For the v1 editor you can open a split editor and open files side by side.

@d3lm That's great to hear the CodeFlow version has the multi-tab support in the code editor window! I might have to join the beta and check it out.
Do you know if there are plans for a v2 editor for the non-CodeFlow version of StackBlitz, or is the plan to make the CodeFlow version essentially become the primary StackBlitz version once CodeFlow comes out of beta? I ask because it seems the v1 code editor window in StackBlitz is capable of showing more than one tab, it just doesn't seem possible yet to control when that happens. I have not been able to discern a pattern of behavior that results in a 2nd tab being opened, but it definitely does happen sometimes.
As an in-the-meantime feature, would it be possible to make a particular tab sticky or locked open once it is open? That way clicking on another file would open in a new tab, up to some pre-determined max # of tabs maybe? If all of that is set for a later edition, no worries. Totally understand, and feel free to close this "issue" (more of a feature request as it turns out).


Reenable revive golangci-lints

It looks like by default, golangci has some preset for revive. By disabling a single rule (increment-decrement), this somehow disables all revive rules.
We should re-enable revive, as it is the replacement for golint. This is not trival, as there are quite a few changes we need to make for it to be compliant with revive again.

fwiw I did realise and look into this a while ago, and found only https://github.com/google/osv-scanner/pull/997 to be worth enabling at the time.
While I didn't write up any detailed notes, I believe my overall findings were:

a lot of what's being linted is already been covered by other enabled lints (or in fact clash with them)
some would require breaking changes, and didn't seem like something we cared strongly about based on existing code (e.g. stuttering and unexported-return)
there didn't seem to be any complaints, common mistakes, dislikes, etc slipping through to make it worth chasing these

I'm not against working towards re-enabling revive, but I think it would be best to start by capturing a list or table of all the rules that should be (re)enabled so that we can easily work through them and also coordinate with the upcoming v2.
I also think ideally we should be trying to enable the rules we're addressing for as we go to ensure we don't regress - that could be done either by a file-by-file, package-by-package, or by enabling across the whole codebase and explicitly disabling the rule inline for existing violations (happy to do a PR or two to showcase what I mean if that's not clear).

some would require breaking changes, and didn't seem like something we cared strongly about based on existing code (e.g. stuttering and unexported-return)

fwiw, running revive with defaults, the only things I see that are not in internal  and would be breaking changes are:
pkg/config/config.go:18:6: exported: type name will be used as config.ConfigManager by other packages, and that stutters; consider calling this Manager (revive)
type ConfigManager struct {
     ^
pkg/osvscanner/osvscanner.go:67:5: error-naming: error var NoPackagesFoundErr should have name of the form ErrFoo (revive)
var NoPackagesFoundErr = errors.New("no packages found in scan")
    ^
pkg/osvscanner/osvscanner.go:73:5: error-naming: error var VulnerabilitiesFoundErr should have name of the form ErrFoo (revive)
var VulnerabilitiesFoundErr = errors.New("vulnerabilities found")
    ^
pkg/osvscanner/osvscanner.go:78:5: error-naming: error var OnlyUncalledVulnerabilitiesFoundErr should have name of the form ErrFoo (revive)
var OnlyUncalledVulnerabilitiesFoundErr = errors.New("only uncalled vulnerabilities found")
    ^

We already have //nolint:errname for the errors, so we can disable one of the rules. So that just leaves the config.ConfigManager stuttering, which we can ignore inline.
The majority of our failures seem to be unused-parameter, which should be a simple and unintrusive to change.