auro-header: independent top/bottom margins

Is your feature request related to a problem? Please describe.
Consumers of the auro-header are limited to adjust either the top or bottom margin, but not both.
Describe the solution you'd like
As a developer for AScom, I would like to see the auro-header have the ability to specify both the top and bottom margin adjustments.  (Having full independent control of both top and bottom would be a nice-to-have, but the below alternative should be fine).
Describe alternatives you've considered
A simpler solution would be to have the option to set top/bottom margin to be both be the same 'size' value.
Additional context
Currently these are the two attributes which allow the consumer of this component to adjust the top or bottom:

Help to better understand the use case. Is the option that the top/bottom adjustments would be identical or independent. E.g. Top xs, Bottom lg, or Top/Bottom lg.

I think that we would like to have the prior example (top - xs, bottom - lg)


[Bug] Sending transactions isn't working properly

Short video showing the problem:
https://streamable.com/s9stn
When I try to send a transaction, the wallet shows a loading animation, but it doesn't send the transaction.

Two questions:

Does it work in the Devnet?
Can you send without scanning the QR Code? (I.e. pasting in the address)

Hehe, yeah I get the same bug when using the Devnet, also it doesn't matter if I scan a QR code or type the address myself, it still does the same loading animation and then nothing happens.

Hmm this works on my Android (at least with the current master,). Wonder if it's an iPhone related problem. If so someone else needs to verify & fix this.

here on my android, this too worked normally.

I pulled the latest master and the issue is gone somehow 😛 I did stumble on another issue though: https://github.com/ArkEcosystem/ark-mobile/issues/71


chore: bdd-nh-1584420149 to 0.0.1

chore: Promote bdd-nh-1584420149 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Adding an example of binary image classification using transfer learning

Hi, thank you so much for your contribution. We recently updated our APIs for better usability, which instructions can be found at https://colossalai.org. So we would really appreciate it if you could update your codes with our new APIs.

Hi @ShanMait  , thanks for your contribution. We are shifting the examples to an independent repo ColossalAI-Examples. Welcome to put up your PR there. We have also updated the tutorials and documentations. I will close this PR for now.


[AVM Module Issue]:  ip_restriction blocks can't be added

Check for previous/existing GitHub issues

[X] I have checked for previous/existing GitHub issues

Issue Type?
Bug
(Optional) Module Version
No response
(Optional) Correlation Id
No response
Description
This is not a very good bug report and I am sorry for that, hopefully soon I have a main.tf file to recreate it.
But the behavior is that setting the block for ip_restriction fails with a lot of other things need to be set, even then the headers block is required, I don't use headers so if I set every header to empty is still fails.
it somehow triggers the scm values as well, even if I choose use main for scm.

@thenewnano - will take a look into this shortly. Let me know if you are able to submit a code sample for recreation.

@thenewnano - I will add an example on how to use ip_restrinction block with the next release, but please let me know if it still gives you issues.

Example added in v0.7.1 release

Maybe we reopen this, I found that a few of the other issues were due to provider versions mismatch, but this ip_restriction issue is till messing.
I don't want to apply any ip restrictions as I don't have public access enabled.
I assume then sending no ip_restriction or sending null should be just fine but it is not, and I can't explain it .
│ .terraform/modules/azure_secure_ai_application_infra.azure_functions/variables.tf:1073,1-23: │ attribute "ip_restriction": incorrect map element type: attribute │ "headers": element "x_azure_fdid": object required. ╵ ╷ │ Error: Invalid value for input variable │  │   on ../../azure_secure_ai_application_infra/main.azure_functions.tf line 94, in module "azure_webapps": │   94:   site_config  = each.value.site_config │  │ The given value is not suitable for │ module.azure_secure_ai_application_infra.module.azure_webapps["rag-adminwebapp"].var.site_config │ declared at │ .terraform/modules/azure_secure_ai_application_infra.azure_webapps/variables.tf:1073,1-23: │ attribute "ip_restriction": incorrect map element type: attribute │ "headers": element "x_azure_fdid": object required. ╵ ╷ │ Error: Invalid value for input variable │  │   on ../../azure_secure_ai_application_infra/main.azure_functions.tf line 94, in module "azure_webapps": │   94:   site_config  = each.value.site_config │  │ The given value is not suitable for │ module.azure_secure_ai_application_infra.module.azure_webapps["rag-webapp"].var.site_config │ declared at │ .terraform/modules/azure_secure_ai_application_infra.azure_webapps/variables.tf:1073,1-23: │ attribute "ip_restriction": incorrect map element type: attribute │ "headers": element "x_fd_health_probe": object required. ╵
each.value.site_config is an object according to its definition see :
`site_config = {
always_on = true
application_insights_key                = module.this.application_insights.instrumentation_key
container_registry_use_managed_identity = true
auto_heal_enabled = null
minimum_tls_version      = "1.2"
remote_debugging_enabled = false
remote_debugging_version = "VS2022"
scm_minimum_tls_version  = "1.2"
vnet_route_all_enabled = true
websockets_enabled     = true
app_service_logs = {
default = {
disk_quota_mb         = 35
retention_period_days = 15
}
}
application_stack = {
primary_stack = {
docker = [
{
image_name   = "backend"
image_tag    = "latest"
registry_url = module.this.container_registry.login_server
}
]
}
}
ip_restriction = null
  }`

@donovm4 can we reopen this and take a look, it's getting tiresome as the code looks correct to me...

@thenewnano Is this configuration block a part of a variable you are using to set site_config? Or are you setting the site_config explicitly in the module call?

@thenewnano: Also, which version of the module are you currently using?


Release v0.2.1

New release v0.2.1 including a new kuadrant operator image v0.2.1 replacing v0.2.1. The dependencies versions remain the same.
kuadrant operator image v0.2.1 adds the following PRs:

#123
#136

Compare with v0.2.0
diff -r bundle/manifests/kuadrant-operator.clusterserviceversion.yaml ../kuadrant-operator/bundle/manifests/kuadrant-operator.clusterserviceversion.yaml
124c124
<     containerImage: quay.io/kuadrant/kuadrant-operator:v0.2.0
---
>     containerImage: quay.io/kuadrant/kuadrant-operator:v0.2.1
129c129
<   name: kuadrant-operator.v0.2.0
---
>   name: kuadrant-operator.v0.2.1
506c506
<                 image: quay.io/kuadrant/kuadrant-operator:v0.2.0
---
>                 image: quay.io/kuadrant/kuadrant-operator:v0.2.1
618c618,619
<   version: 0.2.0
---
>   replaces: kuadrant-operator.v0.2.0
>   version: 0.2.1

The error building the catalog is expected:
2023/01/17 16:40:54 render reference "quay.io/kuadrant/kuadrant-operator-bundle:v0.2.1": error resolving name : quay.io/kuadrant/kuadrant-operator-bundle:v0.2.1: not found

The bundle v0.2.1 will be created after this PR is merged and it is being tagged with v0.2.1


Add context from query string functionality to http module

It would be super cool if the http module in woodchipper could parse query strings. AFAICT nothing forces the query string to follow a particular spec, only convention. I found the TBL spec from 94 where he explains the query string:

The query string represents some operation applied to the object,
but this specification gives no common syntax or semantics for it.
In practice the syntax and sematics may depend on the scheme and
may even on the base URI.

Okay, cool, but convention around keys and values is pretty settled and we have urllib.parse which will even return a dict of the entries back for us.
For extensibility we could allow the user to provide a parser to woodchipper upon initialization, so that we can inject concerns like what delimiter character to use. Probably unecessary on a first pass though.

PR for this here: https://github.com/tackle-io/woodchipper/pull/37

Added with the merge in of #37 . Query are available in the logging context under http.query_param.<qparam_key_name>. Not released yet but that functionality lives in 203baba (#37).


KOGITO-1808: Editor's Backend Support

Proposal for the backend support infrastructure
This PR includes the following new packages:

backend and its sub-modules:

api: Core API for supporting generic backend services. This module must not depend on any other package.
channel-api: Backend services API for channels. This module should include all API definitions that channels can support.
http-bridge: Bridge implementations between channels and http services. Required for channels supporting such a communication.
node: Common implementations related to backend services that target node.

backend-quarkus-runner-unpacked: Retrieve the quarkus runner jar from maven (similar to what's done on kie-bc-editors-unpacked).
vscode-extension-backend: The VS Code extension that should be installed along the editor extensions to support backend services.

Most changes are additions, i.e., the current code won't have any initial impact.
All related PRs:

kogito-tooling: https://github.com/kiegroup/kogito-tooling/pull/256
appformer: https://github.com/kiegroup/appformer/pull/1028
kogito-tooling-java: https://github.com/kiegroup/kogito-tooling-java/pull/1

A complete documentation on the usage of the backend services infrastructure will be provided afterwards.
I've removed the sample code on the following commits, which can give an idea on how this works:

kogito-tooling: https://github.com/kiegroup/kogito-tooling/commit/038601ca32c4803673114038307007f6fc2b3db8
appformer: https://github.com/kiegroup/appformer/commit/e53551b0035f0ba1dea46bc982092c5507c45b6f
kogito-tooling-java: https://github.com/kiegroup/kogito-tooling-java/commit/f337a0b34b3eb9b13f48c14eca25244b97a7f17c

Additional notes:

The backend extension should be included into our bundle. This will be done once we have our first real backend service.

Hi @caponetto great work, went through the code, looks good to me.
I would like to give it a try >  You can give it a try - the vscode-extension-backend artifact is available in the CI workflow.
Could you please share more details on how to do a this? Is that possible with this PR, I understand it is just infra and there shouldn't be any visible changes but I would like you to confirm before I approve. Thanks.
Food for thought - what do you think about using graphql to  communicate across the extension? Channels could define a schema and orchestrate the communication between editors and backend or similar. Could that be considered? While I was reviewing it seemed it could work, and it that could prove beneficial in a longer run (flexibility). Wanted to hear your opinion. :)

Hi @domhanak, thanks for the review!
You can try it out with our development extension by doing the following:
Go to the last build associated with this PR (this one atm).
You will find two vsix artifacts: vscode-extension and vscode-extension-backend.
With these artifacts, here are some things you can do:
(1) Only vscode-extension installed.

Popup is shown when a diagram is opened.
Open a bpmn or dmn file. You should see a popup informing the user to install the backend extension.
Note: The "Install" button does not do anything because the backend extension hasn't been published yet.
Note: This popup should be shown only once per session. It should not be shown anymore if the user chooses "Don't Show Again".

Popup is shown when a backend service is called when the backend extension is not installed.
Open a scesim file. You should see a "Run" button on top right.
If you click on it, a popup will be shown because the backend extension is not installed.
Note: This popup should be shown every time you click on the button.

(2) Both vscode-extension and vscode-extension-backend installed. Make sure to reopen VS Code after installation.

Verify our Quarkus app.
Open a bpmn or dmn. Access http://localhost:8082/. This is our Quarkus app that will contain java services.
Note: The extension tries to find the first available port starting from 8082.
Note: Since we don't have any java service yet, there is no endpoint registered to be accessed.
Note: Our Quarkus app will be started up only if you have Java 11+.
Note: http://localhost:8082/ should only be killed when the VS Code is closed.

Test runner service sample.
Open dmn-quarkus-example on VS Code and then TrafficViolationTest.scesim. Click on the "Run" button and wait for the test runner to complete.
Note: It works only if you have Java 11+ and Maven 3.6.2+.
Note: It should take a while on the first run because Maven needs to download everything.

Notice that you won't see anything above on our next release extension.
Please let me know if you have any questions. :)

I must say that I haven't thought about graphql at all but that's a very good point.
Since we don't have any java service yet, we assumed having a basic rest API for now.
I see this infrastructure evolving while we accommodate future services and I personally think graphql can be considered in the next steps. Thanks for bringing this up. :)

@tiagobento Thanks again for the review. You will see on https://github.com/kiegroup/kogito-tooling/pull/256/commits/a9ba46950624bd7d48949d8a2025853e1ed73bb4:

All testRunner references have been renamed to testScenarioRunner.
Some minor improvements for the test scenario runner service.
The backend package has its own i18n.
Created the workspace package with api and vscode submodules.
Created the vscode submodule for the backend package.
The test runner command is now registered on vscode-extension-pack-kogito-kie-editors.
The responsibility to create the BackendProxy and stop the services were moved to vscode-extension-pack-kogito-kie-editors - now our vscode-extension/index is almost untouched.

Hi @caponetto I was able to successfully perform the scenarios from your comment
There is only one issue, or maybe not, might be that I misunderstood the sentence:

Note: This popup should be shown only once per session. It should not be shown anymore if the user chooses "Don't Show Again".
Clicking "Don't Show Again" works as expected, but when I didn't click "Don't Show Again" but I clicked the X and next time I opened a file, the popup didn't show up. Very minor issue, so I am approving anyway.

Hi @domhanak, thanks again for the review!
That's the expected behavior. I didn't want to annoy the user with the popup every time they open a diagram.
Instead, it is shown only the first time they use our extension as a reminder.
So the popup will be shown again only if VS Code is reopen.


Proxy-pallet: Add flow to add / register an user with a given role

It's necessary to assign a specific role when a user is registered without assigning them to a scope (project).

@DaniPoot done, test it please.


add route without keyword "return" .

I am try to add a feature that allow developer can add a route without keyword "return" .
https://github.com/perwendel/spark/compare/master...qwIvan:feature_router_without_return
example code:
get("/simple",(request, response) -> {
    response.body("Simple");
});

but these are some problem in lambda block that only contain code with throw exception, like:
get("/simple",(request, response) -> {
    throw new RuntimeException();
});

I was get a warning message from Intellij IDEA:

Ambiguaus method call. Both
my solution is add a condition before throw:

get("/simple",(request, response) -> {
    if (true)
        throw new RuntimeException();
});

but it is not elegant at all.

Why? Your example:
get("/simple", (request, response) -> {
    response.body("Simple");
});

Is a lot simpler with return:
get("/simple",(request, response) -> return "Simple");

Think of it as get(input, output)


episodic_return metric is biased

https://github.com/entity-neural-network/incubator/pull/93 fixed a bias in the episodeic_return metric that overweighted environments with a lower index in the VecEnv, but in the process introduced a different bias that overweights environments that finish their episode on a global step at which fewer other environments finish their global step.

On a related note. I think the most correct implementation given non-iid environments is to record the episodic return for each env like charts/episodic_return/env[i]


feat: tracing without performance for dio

:scroll: Description

Tracing without performance was implemented for HttpClient in https://github.com/getsentry/sentry-dart/pull/1621 but it was never implemented for sentry_dio package.
:bulb: Motivation and Context

On my project, we updated sentry to the latest version in order to get tracing without performance, but it wasn't working. Turned out this is because we are using Dio with sentry_dio. This PR resolves that issue.
:green_heart: How did you test it?
Unit tests
:pencil: Checklist

[x] I reviewed submitted code
[x] I added tests to verify changes
[x] No new PII added or SDK only sends newly added PII if sendDefaultPii is enabled
[x] I updated the docs if needed
[x] All tests passing
[x] No breaking changes

:crystal_ball: Next steps

Sure.
Verified by launching the example app from dio directory with the following scenarios:

Run app as is - sentry-trace and baggage available in the request headers
Run app with commented out transaction and 0 sample rate - sentry-trace is available in the request headers.

this is now released in 7.16.0


Level inverted exclamation and inverted question marks.

The Spanish (Castilian, Asturian, etc.) language requires exclamatory sentences
and questions not only to be followed by exclamation marks and question marks,
respectively but also to be preceeded by inverted (or "upside-down") versions of
these punctuation characters.
The typographic rule for these two inverted marks suggests to typeset them
with their tops aligned to the top of lowercase characters (or something along
that line...)
For all-uppercase or all-smallcaps phrases, e. g. in headlines these marks
hagning below the baseline disturb the tight block structure and
it may be preferable to have inverted marks whose bottoms align with the baseline.
We introduce two macros
\capitalinvertedexclamationmark[number]
\capitalinvertedquestionmark[number]

to typeset vertically-adjusted inverted marks, where number
selectes one of three possible glyphs and corrective values.
The new package option raiseinvertedmarks configures the
lengths to raise the respective glyphs, where an exact value
of 0pt triggers auto-leveling, i.e., a correction by exactly the
depth of the hbox.

@cspiel: Well, there are some issues with capital letters J and Q:

but good typographers know which one to use. Even in names with initial capital letters (the exceptions are J and Q), those marks looks very well. I see you later, @cspiel ;-)


report, aggregate

using report, log or aggregate, Watson provides me no way to use the command line again except by exiting. I'm runnning MX Linux 21 (with systemd if it helps).

Watson uses a pager by default. Press key q to quit or h for help. To disable it, run command report, log or aggregate with option -G, or edit your configuration file with watson config --edit or  watson config options.pager false.


Bump Node.js to v16

@rogerluan Thanks for this tool. My team uses it in a bunch of repos. Recently we started getting this warning from GitHub Actions about this particular action: Node.js 12 actions are deprecated. Please update the following actions to use Node.js 16.... I have this small change to bump the version of Node.js from 12 to 16.
Would you please take a look at these changes and merge/release if things look ok?

Thanks for this!! Were you able to test your changes @jgellin-sf ? 😃

Yes. I tested in a private repo with the following workflow:
name: gha test

on:
  pull_request:
    types: [closed]

jobs:
  test_action:
    runs-on: ubuntu-latest
    steps:
      - uses: rogerluan/label-remover@c5c162b06c5b71205c73e5c311c9bc6be5094d6f
        with:
          github_token: ${{ secrets.github_token }}

Thanks once again for this, @jgellin-sf! 🚀 Merging and releasing this!

Released in https://github.com/rogerluan/label-remover/releases/tag/v1.1.0