Docker Console and Debugger

Ticket

Resolves #14

Changes

Updated web_console config to allow most local IPs to access the console for local development with docker
Updated docs to give more specific instructions on how to access the debugger

Questions for reviewers

In the technical-foundation doc, it says to run the app with make rails-console though I think elsewhere it says to use make init-native/container and make start-native/container for local native and local docker development. Should we change it here to be consistent?
We're pulling the ruby:3.3.1-slim image from dockerhub which comes with the debug gem version 1.19.1. However, in our local gemfile.lock we have debug version 1.19.2 installed. Using debug in docker breaks when there is a version mismatch between the server and the client. This will be fixed whenever dockerhub updates their ruby:3.3.1-slim image, but I was only able to get it running locally by locking my debug version in the gemfile to 1.9.1. Is there a best practice to address this?
When setting the IP addresses for permissions, there are some programmatic ways of getting locaL IP addresses, but it seems like those require additional libraries (socket, ipaddr). Is that preferred to the current method or should we go even further by allowing <IP_ADDRESS>?

Testing

Add a console statement to a view in the application and confirm that the console shows up in your browser when hitting that page. Test in both native and container modes.
Add a debugger statement to a controller and follow the instructions in the technical-foundation.md doc to attach the debugger. Confirm in both native and container modes.

Questions for reviewers

In the technical-foundation doc, it says to run the app with make rails-console though I think elsewhere it says to use make init-native/container and make start-native/container for local native and local docker development. Should we change it here to be consistent?

I addressed this in my inline comments. make init-container and make start-container initialize and start the container. They do not create an interactive rails console. make rails-console does.

We're pulling the ruby:3.3.1-slim image from dockerhub which comes with the debug gem version 1.19.1. However, in our local gemfile.lock we have debug version 1.19.2 installed. Using debug in docker breaks when there is a version mismatch between the server and the client. This will be fixed whenever dockerhub updates their ruby:3.3.1-slim image, but I was only able to get it running locally by locking my debug version in the gemfile to 1.9.1. Is there a best practice to address this?

Can you link me to where the upstream ruby docker hub image includes the debug gem? I'm not seeing that. What were you trying to run that was failing with this?

When setting the IP addresses for permissions, there are some programmatic ways of getting locaL IP addresses, but it seems like those require additional libraries (socket, ipaddr). Is that preferred to the current method or should we go even further by allowing <IP_ADDRESS>?

What wasn't working before you added this?

In the technical-foundation doc, it says to run the app with make rails-console though I think elsewhere it says to use make init-native/container and make start-native/container for local native and local docker development. Should we change it here to be consistent?

I addressed this in my inline comments. make init-container and make start-container initialize and start the container. They do not create an interactive rails console. make rails-console does.

Sounds good. Thanks for clarifying.

We're pulling the ruby:3.3.1-slim image from dockerhub which comes with the debug gem version 1.19.1. However, in our local gemfile.lock we have debug version 1.19.2 installed. Using debug in docker breaks when there is a version mismatch between the server and the client. This will be fixed whenever dockerhub updates their ruby:3.3.1-slim image, but I was only able to get it running locally by locking my debug version in the gemfile to 1.9.1. Is there a best practice to address this?

Can you link me to where the upstream ruby docker hub image includes the debug gem? I'm not seeing that. You said "I was only able to get it running locally". What were you trying to run that was failing with this?
The debug gem in the docker ruby 3.3.1-slim image is listed as version 1.9.1, which I was able to confirm on the dockerhub website:

The debug version getting installed in our project is listed as 1.9.2 in our gemfile.lock.
When I try to attach a debugger to the docker container with docker exec -i <Container ID> rdbg -An I get the error in my terminal:

app-rails-1  | 14:42:38 web.1  | DEBUGGER: wait for debugger connection...
app-rails-1  | 14:43:25 web.1  | DEBUGGER: Connected.
app-rails-1  | 14:43:25 web.1  | DEBUGGER: GreetingError: out DEBUGGER: Incompatible version (server:1.9.2 and client:1.9.1)
app-rails-1  | 14:43:25 web.1  | DEBUGGER: Disconnected.

However, if I lock my debug gem to version 1.9.1, and re-bundle and create a new containerized app, it works as expected.
I described how I'm running my docker container in the inline comment here, are you doing it differently?

When setting the IP addresses for permissions, there are some programmatic ways of getting locaL IP addresses, but it seems like those require additional libraries (socket, ipaddr). Is that preferred to the current method or should we go even further by allowing <IP_ADDRESS>?

Can you explain what wasn't working before you added this? I'm not sure I'm following.
Responded to your inline comment.

However, if I lock my debug gem to version 1.9.1, and re-bundle and create a new containerized app, it works as expected.
I described how I'm running my docker container in the inline comment here, are you doing it differently?

Got it! Thanks. I think what we should do is explicitly install a global version of the debug gem inside the docker image that is used for development, by adding this to line 57 of the Dockerfile:
# Install system-wide gems for development
# This version must match Gemfile.lock. Otherwise, `rdbg` will fail.
RUN gem install debug -v 1.9.2

When setting the IP addresses for permissions, there are some programmatic ways of getting locaL IP addresses, but it seems like those require additional libraries (socket, ipaddr). Is that preferred to the current method or should we go even further by allowing <IP_ADDRESS>?

Can you explain what wasn't working before you added this? I'm not sure I'm following.

Responded to your inline comment.

I think your change is good and that we don't need to expand out to <IP_ADDRESS>.


channel batching doesn't work

until yesterday(i think, I have auto-update activated) entering a channel url(e.g. https://www.youtube.com/user/PewDiePie) would result in all uploads being listed. Now that doesn't work anymore.

Does it work on CI build?
https://github.com/Tyrrrz/YoutubeDownloader/actions/runs/315724845

I'm not able to replicate the issue. Everything is working as expected. Thanks for your attention and the whole project!


Add .editorconfig

The project has specific C# formatting choices like requiring this. for local property/member access. Having the preferred style specified in an .editorconfig can help VS and contributors do the right thing for the style you want.

Good idea. Which version of VS shipped .editorconfig support? And how do I generate one?

VS 2017 is the first one that ships with support. I believe most of the VS/.NET specific extensions are used/specified here: https://github.com/dotnet/roslyn/blob/master/.editorconfig
Mads also released a language service that has IntelliSense and highlighting for .editorconfig files: https://marketplace.visualstudio.com/items?itemName=MadsKristensen.EditorConfig


Adding new preview API for promotions

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Please ensure to add changelog with this PR by answering the following questions.

What's the purpose of the update?

[ ] new service onboarding
[X] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When you are targeting to deploy new service/feature to public regions? Please provide date, or month to public if date is not available yet.
When you expect to publish swagger? Please provide date, or month to public if date is not available yet.
If it's an update to existing version,  please select SDKs of specific language and CLIs that require refresh after swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[x] No, no need to refresh for updates in this PR

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of “no breaking changes
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[x] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
Adding a new service

[x] Please ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from API Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable version with Breaking Change Validation errors
[ ] Updating API(s) in preview over 1 year

To initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

You don't have permission to trigger SDK Automation.
Please add yourself to Azure group from opensource portal if you are MSFT employee,
or please ask reviewer to add comment *** /openapibot sdkautomation ***.
Please ask<EMAIL_ADDRESS>(or NullMDR in github) for additional help.

Please get an internal approval from ACE API reviewers before going ahead with ARM review.

Please get an internal approval from ACE API reviewers before going ahead with ARM review.

Will do, this was published to ACE internal review.

Signing off from ARM side

Approved

Please get an internal approval from ACE API reviewers before going ahead with ARM review.

done

@xccc-msft can you please merge this

Hi rkapso, I noticed below SDK breaking change looks caused by rename:   Can I know why has this rename for operation_id?
info	[Changelog]   - Removed operation InvoicesOperations.download_multiple_billing_subscription_invoice
info	[Changelog]   - Removed operation InvoicesOperations.download_multiple_modern_invoice

@rkapso kindly ping for my comment

Hi rkapso, I noticed below SDK breaking change looks caused by rename: Can I know why has this rename for operation_id?
info [Changelog] - Removed operation InvoicesOperations.download_multiple_billing_subscription_invoice
info [Changelog] - Removed operation InvoicesOperations.download_multiple_modern_invoice

The old operation was not used at has been removed

Hi rkapso, I noticed below SDK breaking change looks caused by rename: Can I know why has this rename for operation_id?
info [Changelog] - Removed operation InvoicesOperations.download_multiple_billing_subscription_invoice
info [Changelog] - Removed operation InvoicesOperations.download_multiple_modern_invoice

The old operation was not used at has been removed

Thanks @rkapso , my question is why rename it as it caused sdk breaking change which has impact to customer. @msyyc for comments the impact for customer

and Is this PR still in use. there is lots of validation failure https://github.com/Azure/azure-rest-api-specs/pull/11286
Seems it is adding api in billing.json for same feature. it is not consistent as this PR. @rkapso


Fixed the height of the boxes present on the homepage of the website

This pr fixed the height of the boxes on the homepage.
fixes #459

Summary by CodeRabbit
Style: Adjusted CSS styles for better mobile responsiveness

Reduced the min-height property of the .listContainer class from 17rem to 8.8rem to optimize space utilization on smaller screens.
Introduced a max-height property with a value of 295px to the .listContainer class, ensuring consistent display across various screen sizes.

please add hacktoberfest tag when merge this please


session should support (host, apiKey)

Currently, the NewSession method takes host, login and passwd as parameters.  Keeping passwd in clear text is against my company's policy.  I am wondering if we can have another way to create the session.  PANOS does support ApiKey as part of their standard interface.  And I can see that internal to go-panos, the ApiKey is also used.  Can we have a new session interface based on host and ApiKey?

Hi,
I will definitely work at getting this added. I'll work at it today and test it.

This is great!  Thank you.
Rex

On Aug 30, 2017, at 9:49 AM, Scott Ware<EMAIL_ADDRESS>wrote:
Hi,
I will definitely work at getting this added. I'll work at it today and test it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/scottdware/go-panos/issues/10#issuecomment-326051251, or mute the thread https://github.com/notifications/unsubscribe-auth/AMvdJrjWtLcEW6zixe4doEt9lxlehfDXks5sdZKVgaJpZM4PGe8e.

Rex,
I just committed a change which should take care of this. I also updated the README with examples of how to use it.

I just saw the code update.  Nice!
Rex

On Aug 30, 2017, at 10:27 AM, Scott Ware<EMAIL_ADDRESS>wrote:
Rex,
I just committed a change which should take care of this. I also updated the README with examples of how to use it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/scottdware/go-panos/issues/10#issuecomment-326062031, or mute the thread https://github.com/notifications/unsubscribe-auth/AMvdJjzaGAt7ptHelBviiSGJo8QHQQnUks5sdZuNgaJpZM4PGe8e.


Chi Square

Adds Chi Square function to Entropy as requested in #164. This is just the basic Chi Square function without the other functions included in "ent". There is a bit of a difference in output which I assume is due to JavaScript float point operations. I also noticed there is a bit of a difference between "ent" output depending on platform so this may not be a big deal.

Nice operation.
At some point, it might be a good idea to add some graphics to this in a similar manner to the Entropy operation, so as to illustrate what it's trying to tell you.


Demo seems to be broken

Hi,
The online demo seems to give the following error: Unable to fetch upstream endpoints from svc

sorry that it took so long. It's back up for now


Strikes "Smart" from "Smart" Widgets

Remove the not-in-URLs usages of "smart" referring to widgets.

:+1:

:+1:


Blog app: add authorization rules

Changes introduced. 😎

Limit access to web app resources based on authorization rules. ✔

Install CanCanCan  in my project. ✔
Add a role column to the users table.✔
Implement appropriate authorization rules. ✔

Note:

This project phase has a very basic styling. considering the time and requirements, we have left the styling as it is now.

Thank you @Lordkaito, Nice to have your approval.


Questions

Hi
I have two questions.

How can you add more PBIs, Bugs or tasks to an existing estimation session?
I am getting an error when estimating a task, it says

Which field is required on the task for it to work?

Thanks

@huwbristow Thanks for reaching out.

Unless you use a query-based session we currently have no way to change the items in the session. I'll add it to the backlog for condicideration.
For this you need to go to the settings and select the size field to use for the Task work item type (typically Original Estimate).


Chore: Add slack channel

We will add a slack channel for coordination especially wrt #429

@disordinary Made one, with a temporary invite link: https://mobiledoc-kit.slack.com/shared_invite/MTQwMTI1MTQ3NDEyLTE0ODY3NTY5OTYtMzdiMmU4MThiMA
We still need to set up a permanent slack-in URL, and then update the README

I created a slackin app and updated the readme.
For reference the slackin app is located here: https://mobiledoc-slack.herokuapp.com/
I'll close this issue. 😄


Cannot configure module "@adonisjs/attachment-lite"

I try to configure @adonisjs/attachment-lite after installed
i used adonis framework version 6 (latest version)
but i have an error. this is the picture

Hey @poedihippo! 👋🏻
The package @adonisjs/attachment-lite has not been released for AdonisJS 6 yet.

ohhh i see, thanks @RomainLanz


inference code

Hello
How are you?
Thanks for contributing to this project.
Could you add the inference codes of the finetuned checkpoints in your project?

Thank you for the comment, I will add a sample inference code too! (Although I have deleted the trained checkpoint, so will use a placeholder instead.)

Hi @PrakharSaxena24
When will you add the inference code?

Hey!
Apologies for the delay
Added a ipynb for a general template of inference, let mw know if there are any questions. (I cannot use the trained lora as I have deleted the old trained loras)

BTW, I would recommend to use vLLM or TGI,  for optimised inference.


Remove all delete calls in /test

This PR removes all the delete calls in our test directory by applying smart pointers.   This work started by simplifying the InsertPlan code to enhance parameterizaton later in this week, so it would be nice to merge it soon.
The code changes are straightforward, so someone could spend less than quarter an hour to review them.

@seojungmin I think you need to rebase first.

Coverage increased (+0.01%) to 75.023% when pulling 6996f5369065d052003a6ef4eb305583b26b4dab on seojungmin:refactor-insert into 3f499947c722f1f03f85c1d3953459032a58948e on cmu-db:master.

Coverage increased (+0.02%) to 75.031% when pulling e0bc24841d168c64324b360f390223ae5e3b383f on seojungmin:refactor-insert into 3f499947c722f1f03f85c1d3953459032a58948e on cmu-db:master.

@chenboy @luochenUmich Can you guys review this today? I think that we should get it in before tomorrow's hackathon. Thanks.

sure, I will review this today

Looks good to me. After the build passes, it should be good to go.

Coverage decreased (-0.02%) to 74.996% when pulling e0d76786c0df9d720ce2f149f497ad8122cbe441 on seojungmin:refactor-insert into 3f499947c722f1f03f85c1d3953459032a58948e on cmu-db:master.


Update SQLite bundled with Docker container

It's 3.26.0 at the moment:
https://github.com/simonw/datasette/blob/af9cd4ca64652fae262e6f7b5d201f6e0adc989b/Dockerfile#L9-L11
Most recent release is 3.31.1: https://www.sqlite.org/releaselog/3_31_1.html

From https://www.sqlite.org/download.html the download URL is https://www.sqlite.org/2020/sqlite-autoconf-3310100.tar.gz

On my laptop I can build and test like so:
cd datasette
docker build -t datasette-sqlite .
docker run -p 8001:8001 -v `pwd`:/mnt \
    datasette-sqlite \
    datasette -p 8001 -h <IP_ADDRESS> /mnt/fixtures.db

Need to test with SpatiaLite here too.
docker run -p 8001:8001 -v `pwd`:/mnt \
    datasette-sqlite \
    datasette -p 8001 -h <IP_ADDRESS> /mnt/spatial.db \
    --load-extension=/usr/local/lib/mod_spatialite.so

Here's how to run the unit test suite inside the freshly built Docker container (built with a new SQLite):
docker run -it -v `pwd`:/mnt datasette-sqlite /bin/bash
root@0e1928cfdf79:/# cd /mnt
root@0e1928cfdf79:/mnt# pip install -e .[test]
root@0e1928cfdf79:/mnt# pytest

I ran that against SQLite 3.31.1 and got one failure!
It was for test_searchable[/fixtures/searchable.json?_search=te*+AND+do*&_searchmode=raw-expected_rows3]
    def test_searchable(app_client, path, expected_rows):
        response = app_client.get(path)
>       assert expected_rows == response.json["rows"]
E       AssertionError: assert [[1, 'barry c...sel', 'puma']] == []
E         Left contains 2 more items, first extra item: [1, 'barry cat', 'terry dog', 'panther']
E         Full diff:
E         + []
E         - [[1, 'barry cat', 'terry dog', 'panther'],
E         -  [2, 'terry dog', 'sara weasel', 'puma']]

Well that's odd. If I run the tests against SQLite 3.26.0 inside the container I get the same failure there as well:
docker run -it -v `pwd`:/mnt datasetteproject/datasette:0.37.1 /bin/bash
root@710eed6278b2:/# cd /mnt
root@710eed6278b2:/mnt# pip install -e .[test] && pytest

SpatiaLite testing works fine. I'm going to ship this even though there's a single failing test, since that's not a regression from the previous Docker release. I'm going to file a separate issue about that.

Shipped in Datasette 0.38.


Display of queried result

Hi,
I am a newbie here trying out MongoDB for the first time. I just started using adminMongo. Great job you guys!
I had a very simple question. When we query a document, where should I expect to see the result? eg.
db.mycol.find({"likes":{$gt:1000}})

Thanks!

If you are using the "Query documents" button you should be able to enter your query in the modal like:
{"likes":{$gt:1000}}

Thanks for the reply @mrvautin. I have tried the above format as well. It displays all my documents. {"likes":1000} displays 1 document. Operations like gt,lt,ne doesn't seem to work

Ok. I'm not sure that has been tested thoroughly. Let me have a look into it.

It seems the mongodb-extended-json module is struggling with parsing the query.
Can you try like this (note the quotes around "$gt"):
{"likes":{"$gt":1000}}

Now it works. Thanks!

Great!


Write ADR for repository library design

I'm trying to provide the following in the coming days:

PR with Architectural Decision Record on repository library design based on Metadata API. I see three main options:

No repository library, rely on Metadata API to be easy enough for apps to solve the issues themselves
provide a repository_tool-like API
provide a minimal repository abstraction, show how to implement repositories with it

A design document for Minimal Repository Abstraction proposal to back that up

This is part of #1136. My current writing is in https://docs.google.com/document/d/1ZsXWMP_JgsI6RLhyiDn1Fr6rSCMFVoYSBwBakMzspjs but it's really not a proper design document yet

copy-pasting initial ADR writeup for reference

Repository library design
Context and Problem Statement
The Metadata API provides a modern Python API for accessing individual pieces of metadata. It does not provide any wider context help to someone looking to implement a TUF repository.
The legacy python-tuf implementation offers tools for this but suffers from some issues (as do many other implementations):

There is a very large amount of code to maintain: repo.py, repository_tool.py and repository_lib.py alone are almost 7000 lines of code.
The "library like" parts of the implementation do not form a good coherent API: methods routinely have a large number of arguments, code still depends on globals in a major way and application (repo.py) still implements a lot of "repository code" itself
The "library like" parts of the implementation make decisions that look like application decisions. As an example, repository_tool loads every metadata file in the repository: this is fine for CLI that operates on a small repository but is unlikely to be a good choice for PyPI.

Decision Drivers

There is a consensus on removing the legacy code from python-tuf because of maintainability issues
Metadata API makes modifying metadata far easier than legacy code base: this makes significantly different designs possible
Not providing a "repository library" (and leaving implementers on their own) may be a short term solution because of the previous point, but it does seem like the project would benefit from some shared repository code and shared repository design
Maintainability must be a top concern
Allowing a wide range of repository implementations (from CLI tools to minimal in-memory implementations to large scale applications like Warehouse) would be good: unfortunately these can have wildly differing requirements

Considered Options

No repository packages
repository_tool -like API
Minimal repository abstraction

Decision Outcome
Option 3: Minimal repository abstraction
While option 1 might be used temporarily, the goal should be to implement a minimal repository abstraction as soon as possible: this should give the project a path forward where the maintenance burden is reasonable and results should be usable very soon. The python-tuf repository functionality can be later extended as ideas are experimented with in upstream projects and in python-tuf example code.
The concept is still unproven but validating the design should be straight forward: decision could be re-evaluated in months if not in weeks.
Pros and Cons of the Options
No repository packages
Metadata API makes editing the repository content vastly simpler. There are already repository implementations built with it (RepositorySimulator in python-tuf tests is an in-memory implementation, while repository-editor-for-tuf is an external CLI tool) so clearly a repository library is not an absolute requirement.
Not providing repository packages in python-tuf does mean that external projects could experiment and create implementations without adding to the maintenance burden of python-tuf. This would be the easiest way to iterate many different designs and hopefully find good ones in the end.
That said, there are some tricky parts of repository maintenance (e.g. initialization, snapshot update, hashed bin management) that would benefit from having a canonical implementation. Likewise, a well designed library could make some repeated actions (e.g. version bumps, expiry updates, signing) much easier to manage.
repository_tool -like API
It won't be possible to support the repository_tool API as it is but a similar one would certainly be an option.
This would likely be the easiest upgrade path for any repository_tool users out there. The implementation would not be a huge amount of work as Metadata API makes many things easier.
However, repository_tool (and parts of repo.py) are not a great API. It is likely that a similar API suffers from some of the same issues: it might end up being a substantial amount of code that is only a good fit for one application.
Minimal repository abstraction
python-tuf could define a repository abstraction that

provides tricky some functionality (like core snapshot update) but
does not implement all repository actions itself
leaves application details to specific implementations (examples of decisions library should not always decide: "are targets stored with the repo?", "which versions of metadata are stored?", "when to load metadata?", "when to unload metadata?", "when to bump version?", "how to decide new expiry date?", "which versions should be part of new snapshot?")
python-tuf could also provide one or more implementations of this abstraction as examples -- this could include a repo.py- or repository_tool-like implementation.

This could be a compromise that allows:

low maintenance burden on python-tuf: initial library could be tiny
sharing the important, canonical parts of a TUF repository implementation
ergonomic repository modification, meaning most actions do not have to be in the core code
very different repository implementations using the same core code and the same abstract API

The approach does have some downsides:

it's definitely not a drop in replacement for repository_tool
A preliminary design has been implemented (in a repository-editor-for-tuf branch ) but the concept is still unproven

Links
TODO: Link to a design document
TODO :Link to mockup implementation

Great write-up, @jku! I'd love if we had a comprehensive list of both the specific functionality a minimal repository abstraction includes, and leaves to application  implementations respectively, and also why.
Maybe this is more relevant for the design document than for the ADR. What do you think?

Oh agreed, I think the ADR is pretty pointless without some kind of design document: this is why the content is just a comment for now...
The point about including reasoning for those decisions is good, I'll have to think where and how to do that


Is it still active?

The current version crashes on Big Sur for me

I'm also interested in knowing if this is still active.

It's not abandoned, but SwiftUI have so many issues on macOS that it's hard to justify working it. I might continue this year, but I guess I'll be much more motivated when a new version of macOS will be released with a better SwiftUI.

There was a release 8 days ago. So, it seems like there's work going on.

@Dimillian Is this still maintained ?
~7 months since the last push and the release...

Well I mean, it’s working :)

Well I mean, it’s working :)

However, It is buggy as hell :(
It crashes here and there, disabled sidebar items from the settings is ignored and shown everywhere, It can't load u/usernames.... etc

I remember the original developer mentioning that this was due to Swift 4. I have since assumed he gave up, and so i removed it and gave up waiting as well ;-)


Chart draws second time on render() if I change state of a component. Using ReactJS

Lightweight Charts Version: 3.1.5
import React from 'react'
import './Home.css'
import Graph from '../graph/Graph'
import MoreInfo from '../moreInfo/MoreInfo';

export default class Home extends React.Component {
    constructor(props) {
        super(props);
        this.state = {
            showMoreInfo: false
        };
    }

    changeState = () => {
        this.setState({
            showMoreInfo: !this.state.showMoreInfo
        });
    }

    render() {
        return (

                    {this.state.showMoreInfo && <MoreInfo />}

                    <Graph symbol='GOOGL' changeState={this.changeState} />

        )
    }
}

Actual behavior:
When i click on button to use method changeState, state changes, MoreInfo component shows, but chart is drawing again like this:

I've already checked even without MoreInfo component. If I just change state of parent Component, graph draws one more time. If I click again on button, it draws third time and so more. If I display a lot of charts, all of them draw one more time every button click.
Can you help me with it?
Thanks

Can you help me with it?

So, what's the problem?

That it draws again on every button click but shouldn't.

That it draws again on every button click but shouldn't.

What do you mean? The chart makes re-render or what? How it's related to the issue's title? Can you create reproduction for that?

If I didn't describe this problem well with project title, I'm sorry. Here's a video of the problem. Again, chart shouldn't draw second and third time, but it does after I change state of component

This issue isn't related to the lightweight-charts itself, it's related to react and how you wrap the library with react. I think that the issue is with import Graph from '../graph/Graph' component, which re-creates the widget every instead of using the previous one. But because it isn't related the library, please ask this question on stackoverflow https://stackoverflow.com/questions/tagged/lightweight-charts or in our discord chat https://discord.com/invite/E6UthXZ.

As you said, the problem was with the code. Every time I getting new data from api, I used method createChart() and it made new chart. I fixed it by just passing data to an existed chart.

How did u do that ? Please share  the code or explain


Yosegi-73 New classes added to Float and Double generic tests.

What is the necessity of this update? What is updated?
New encoding class added to Float and Double generic tests.
How did you do the test? (Not required for updating documents)

LGTM


App icon is missing after icon logic update

💻 Environment
Platform: macOS
🐞 Actual behavior
The app built by our buildbot is without Toggl logo. Default system icon is shown instead.
💯 Expected behavior
Buildbot builds with the correct icon
📦 Additional info
Might be caused by building with sdk 10.11 maybe it does not support the Icon Assets

After investigating, it revealed that we have to build Toggl by using

OS >= 10.12
Xcode >= 8.0

Because ImageAsset is officially supported

Maybe one of these solutions will help https://stackoverflow.com/questions/46109835/app-icons-not-included-in-build-from-xcode
Also it is strange that the icon is there in the build folder but when we unpack the app from dmg it's gone.

The issue might be caused by packing the app into dmg. The dmg image has a size limit and if the updated icons make the app bigger than the image it can be an issue. The other possible cause is that something is just not packed into the dmg properly.

Regarding this [StackOverflow's solution](url
https://stackoverflow.com/questions/46109835/app-icons-not-included-in-build-from-xcode), I don't think that it could solve our issue because it mentions about the missing icon in Xcode 9 by using wrong icon format.
It's totally different with our scenario, which is that the Xcode version (OS X 10.11) in buildbot didn't recognize Image Assets appropriately.
On the other hand, I tried to archive Toggl by Xcode 10.1, and it bundled the icon properly. So I suspect that our the version of Xcode in buildbot could be a problem.

Can you confirm what the current value of $(XCODELEGACYSDK) is in our buildbot 🤖 server?

I'm setting up to access directly to our buildbot 🤖, let see what the problem is 🏄♂

Brief result from last investigation on Mini Buildbot 🤖
Basically, I tried to archive successfully Toggl (has correct logo) with macOS 10.14, Xcode 9.0 and config -macos10.11 in my machine.
However, in Mini 🤖 , which is macOS 11.12, Xcode 9.0 and config -macos10.11, for some mysterious reasons, the icon asset wasn't bundled appropriately.
I'm intending to upgrade Mini to Xcode 9.1 or Xcode 9.4 to see whether the issue is gone or not.

After detail investigation, it turns out that I updated all Project Setting in Xcode 10.1 in #2689.
Consequently, this setting doesn't match well with Xcode 9.0, so there are certain project warnings ⚠ .
I will re-config this setting, then double check again 🤖

After many testing combinations in Xcode 9.0 (10.11 mini bot) and Xcode 9.0 (10.14 my workspace), I believe that there are mysterious reasons, which are related to OS rather than the version Xcode, which cause our Icon problem.
Steps to replicate

Download this IconTest (Github)
Make sure Minimum Deployment OS is 10.11
Product -> Archive
Export without signing
Open *.app and check the assets.car by AssetCatalogTinker
Check whether the icon is existing

OS Specific
We repeat Steps to Replicate twice in both following workspace.

Workspace
Xcode
OS

Mini bot
9.0
10.11

My workspace
9.0
10.14

Result

Workspace
Icon in assets.car

Mini bot
NO

My workspace
YES

How macOS get the icon of IconTest.app.
Regarding macOS < 10.13 (Mini buildbot 🤖 ), macOS acquire the icon from IconTest.app/Contents/Resources/AppIcon.icns
Whereas, macOS >= 10.13 (My workspace) prefers IconTest.app/Contents/Resources/Assets.car if Assets.car is existing or get the icon from AppIcon.cns (backward-compatible)
actool
After deep investigation, I realize that actool is responsible for bundling our icons to asset.car file.
According to Manpage's actool
--app-icon name
              Can  be  combined  with --compile to select an app icon. **The app
              icon will either be copied into the output  directory  specified
              by  --compile,  or into the generated CAR file, depending on the
              value of --minimum-deployment-target.** Deploying to  macOS  10.13
              or  iOS 11.0 and later will cause the app icon to be included in
              the generated CAR file. A partially defined image is still  gen-
              erated  into  the  output path, but this behavior may go away in
              the future. This flag also causes actool to declare the app icon
              in  the  patrial info plist component specified by --output-par-
              tial-info-plist.

It means that if we archive Toggl under macOS < 10.13, actool always prefers copying our icon into output directory rather than bundling inside the CAR file.
Consequently, the set of icon is missing in CAR file, and results in the missing icon in OS >= 10.13.
It's reasonable to explain why previous result has different results even the app configuration is same.
actool example
    /Applications/Xcode.app/Contents/Developer/usr/bin/actool
    --output-format human-readable-text
    --notices
    --warnings
    --export-dependency-info /Users/mini/Desktop/iconTest/build/IconTest.build/Release/IconTest.build/assetcatalog_dependencies
    --output-partial-info-plist /Users/mini/Desktop/iconTest/build/IconTest.build/Release/IconTest.build/assetcatalog_generated_info.plist
    --app-icon AppIcon --enable-on-demand-resources NO
    --sticker-pack-identifier-prefix com.mac.mini.IconTest.sticker-pack.
    --target-device mac --minimum-deployment-target 10.11
    --platform macosx --product-type com.apple.product-type.application
    --compile /Users/mini/Desktop/iconTest/build/Release/IconTest.app/Contents/Resources /Users/mini/Desktop/iconTest/IconTest/Assets.xcassets

Final result
There is no options / choices to force actool to bundle Toggl's icon to CAR file in order to work with latest macOS (>= 10.13).
My suggestion

Just keep the revert PR as it is.
Upgrade Mini boot to macOS 10.13.

I prefer the first options since it's effortless.

Let's go with the 1. suggestion and keep the old icon logic. If we get more reports about missing icons we will take another look at it.
At least we have a lot of info now about the logic the macOS has for bundling icon. Great documentation @NghiaTranUIT . Thank you for being so thorough.


Make #prop(into, default) a bit more ergonomic.

At the momement MaybeSignal and similar component properties can be constructed like this:
#prop(into, default = false.into()) disabled: MaybeSignal<bool>
#prop(into, default = "Some value".into()) disabled: MaybeSignal<String>

While this is working when components with many default props are created, the into() calls on the default creates a lot of noise, boilerplate. So I'd suggest to make the .into() call part of the proc-macro:
#prop(into, default = false) disabled: MaybeSignal<bool>
#prop(into, default = "Some value") disabled: MaybeSignal<String>

I think the extra into when it is not required would be compiled to a no-op.
Also this feature could be enabled only when both the input and default tags are present in the annotation.

Any interest in making a PR?


Translating Checking Unions with Index Signature.ts to pt-br

@khaosdoctor @alvarocamillont @danilofuchs @orta
Add pt-br translations to:

Checking Unions with Index Signatures.ts

LGTM


feat: use current asset for default trade pair

Description

I added some props to Trade, TradeCard and TradeRoutes in order to select the default asset to buy when you're on a specific asset page
It allows ERC20 assets
If you are on the ETH asset page, FOX is selected
If you are on another chain asset like BTC for example, ETH => FOX pair is selected

Notice
Before submitting a pull request, please make sure you have answered the following:

[x] Have you followed the guidelines in our Contributing guide?
[x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Pull Request Type

[ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[x] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)
closes #934
Risk
No that risky, mainly about default trade pair
Testing

Pull this branch
Go on BTC asset page, default pair should be ETH => FOX
Go on ETH asset page, default pair should be ETH => FOX
Go on another asset page, default pair should be ETH =>

Screenshots (if applicable)
https://user-images.githubusercontent.com/14963751/159129258-a487b546-3d1b-459a-9664-e0c091ee469d.mp4

@cjthompson for reference https://github.com/shapeshift/web/pull/1008#issuecomment-1057679103
I think he tried to use useAsset in order to avoid the props depth hell, I worked following your feedbacks but maybe using the selector would be cleaner, just tell me!

@NeOMakinG Can you mergefix this? 🙏🏽


Fix tilemap mode, in the tile draw window to move the mouse, window dithering

In tilemap mode, the tilemap toolbar is compressed together after narrowing the window. At this time, when the mouse is moved, the length of the brick coordinate information keeps changing, and the drawing window also changes.The method I took was to set the window information label to be at least 200 wide, and the number of characters larger than 12 characters with "..."Instead of the rest of the text
Bugsquad edit: Fixes #31836

Please squash commits together, see PR workflow.

There is still the issue in 3.2 alpha 3 ...

Please squash commits together.

Superseded by #33829, but thanks for the contribution nevertheless!


I can not play video with m3u8 format

Current behavior
When a streaming url is assigned to source, the video never plays.
Platform
Which player are you experiencing the problem on:

iOS
Android ExoPlayer

Sample
This is my configuration in the Video component:
Version: 4.3.1
 <Video       source={{uri: "https://s3.amazonaws.com/yojma/hls/movie/yvZmxnCwaHGSLUpKFzoTlYrOXRdWQgePIqihbfcs/main.m3u8", type:"m3u8"} }      navigator={ this.props.navigation }       />
And this in app/build.gradle:
dependencies {     compile project(':react-native-video-exoplayer')     implementation "com.facebook.react:react-native:+"  // From node_modules     implementation fileTree(dir: "libs", include: ["*.jar"])     implementation "com.android.support:appcompat-v7:${rootProject.ext.supportLibVersion}" }
And this settings.gradle:
rootProject.name = 'Yojma' include ':react-native-video-exoplayer' project(':react-native-video-exoplayer').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-video/android-exoplayer') include ':app'
This is what the m3u8 file looks like:
`#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=500000,NAME="Main",CODECS="avc1.66.30",RESOLUTION=426x240,AUDIO="aac",SUBTITLES="subs"
240p/file.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=800000,NAME="Main",CODECS="avc1.66.30",RESOLUTION=640x360,AUDIO="aac",SUBTITLES="subs"
360p/file.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1400000,NAME="Main",CODECS="avc1.66.30",RESOLUTION=854x480,AUDIO="aac",SUBTITLES="subs"
480p/file.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2800000,NAME="Main",CODECS="avc1.66.30",RESOLUTION=1280x720,AUDIO="aac",SUBTITLES="subs"
720p/file.m3u8
#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",NAME="InglÃ©s", DEFAULT=YES,AUTOSELECT=YES,LANGUAGE="en", URI="test/audio_english.m3u8"`

+1

Anyone?

I am getting this when requesting the stream:
<?xml version="1.0" encoding="UTF-8"?>
<Error>
    AllAccessDisabled
    <Message>All access to this object has been disabled</Message>
    <RequestId>02469639E7DD7EB0</RequestId>
    <HostId>4iaIa9tYD60Pal7z290fFnLz7stI9SVwfNxak7noyndG0xmAHThMQto5IuFckXRIFj1xDJ30JM8=</HostId>
</Error>

Please share updated streams you are using to diagnose.

it worked for me when I do this
      source={{
        uri,
        type: 'm3u8',
      }}


Consistent logging, with a proper logger module

Per chat with Joel:
Consistent logging, with a proper logger module (there are a few different logging techniques in UMD, including a home-grown logger that looks like it came from BBE).  Something that gives us timestamps, and source location (file.cpp:123) would be nice.  I've used spdlog (fmt-based) and glog (stream style syntax) in the past but I don't have strong opinions about the library.  Something that's thread safe and fast, can log to stderr or to a file.

Related to this, we should get rid of LOG1 LOG2 and similar stuff

I vote for spdlog

I vote for spdlog

Is this used by tt-metal as well? I'd like us to be consistent.


Create new TransactionSender Class

Fixes #67
Creating a new class for sending transaction that embed sendinf, wait confirmation and wait error.
This class is an observer thant provide multiple events.
All documentation is in the readme
Also fixes #75
Added a new function fromBigInt to convert Big int number into decimal number

I got this error in the console


Remove CAPI labels from the crds

Description of changes:
Remove CAPI labels from the tinkerbell CRDs to avoid removing them
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm

/approve


Added the discussed fix for the standard appender

This should fix #20
Please let me know if the coding "style" is not what you expected and I will update the fix.

Thank you for contributing a fix for this!
When you have a chance, would you mind adding unit tests for this? https://github.com/cerner/canadarm/blob/1.0.1/test/unit/appender/standard.js

Added unit test for the fix, Also fixed the missing space after if

:+1:

Would a simpler approach be to just detect the global variable identifying the current file in Node and if not present fallback onto looking up the script?

https://nodejs.org/api/globals.html#globals_filename
https://nodejs.org/api/globals.html#globals_dirname

Could you please update the changelog and and contributors files as the CONTRIBUTING.md file?

I would prefer these approaches mentioned by Mike.

@mhemesath I do not 100% follow what you mean:

Would a simpler approach be to just detect the global variable identifying the current file in Node and if not present fallback onto looking up the script?

The code exists to get the current file path. I'm simply suggesting that we check for the presence of the global variable that references the current file and path and use that. If those don't exist, then assume we are in a browser context and call getElementsByTagName

@mhemesath But usage of __filename in the standard-appender will always return the standard appender-filename, right? And anything else will alter the API of the logging, which I guess you don't want?

@JohnPhoto your right, duh :)
I was looking at the code though and it seems that node errors have a stack property. How is the code even getting into this execution block in nodejs?  Admittedly I haven't done node programming in a while so there might be something I'm missing.

I agree with your assumption regarding exception and stack. But I put
console.log(typeof exception, exception); at row 54 in the appender (directly after the first assignments in the appenderfunction. (row 413 in the build).
There I got a undefined, undefined printout with my setup.
My theory is that I'm doing a manual Canadarm.warn('Test') which maybe is not giving any exceptions, and therefore the code only crashes (prior to fix) with the manual logging and not when catching thrown errors.

My theory is that I'm doing a manual Canadarm.warn('Test') which maybe is not giving any exceptions, and therefore the code only crashes (prior to fix) with the manual logging and not when catching thrown errors.

You are correct @JohnPhoto. Looking at the code it actually has this comment:

// Or one of our custom loggers was called, e.g. Logger.debug('message').

There is no exception passed and that's on purpose because there is not an exception. At the time of creation I don't think I fully understood the implications on node having that browser bit.

I think this looks good. 👍  Thanks for the pull request.  I'll see if anyone has any objections and if not, I'll get this merged and published soon.


[Feature]: Support for temperature and humidity sensors

Domain
sensor
What is actually missing?
hi there , can you kindly add support for temp & humd sensor , many thanks in advance.

Could you please provide some more details about the attributes and states of your entities?
Please go to the "developer tools" in home assistant. Open the "states" tab and search for one humidity and one temperature sensor.
Past the entity_id, current state and attributes here.
E.g. like this:

Started to look into this.
@t0bst4r I have a lot of things working locally but I'm unable to find a solution for the Error: Only supported EndpointInterface implementation is Endpoint error.
How did you solve this? hope you're not publishing the package before testing 😅

@pvanbuijtene
we are speaking about local development, right?
The error message happens when matterbridge-home-assistant is using matterbridge from a different node_modules folder than the matterbridge package that is actually running.
For example this can happen when you have installed matterbridge globally, while adding the plugin from the local development environment to it.
How did you add the dev plugin and how did you start matterbridge? You could use npm run run:matterbridge at the root of the project. It will actually go into the nested package, build it, add it to matterbridge and run the locally installed matterbridge from the correct node_modules.
if that is not working let’s add another issue to solve problems with local development to not spam this issue here.

Local development indeed. Missed that part, got it working 👍

Thanks to @pvanbuijtene this was released with 2.6.0


module inputs: alb_arn_suffix and target_group_arn_suffix do not comport with resource outputs

currently at https://github.com/cloudposse/terraform-aws-alb-target-group-cloudwatch-sns-alarms/blob/master/alarms.tf#L10-L11
we have:
    "TargetGroup"  = "${join("/", list("targetgroup", var.target_group_name, var.target_group_arn_suffix))}"
    "LoadBalancer" = "${join("/", list("app", var.alb_name, var.alb_arn_suffix))}"

but both of those RHS values (var.target_group_arn_suffix, var.alb_arn_suffix) already include text that the join() statement always adds.
Walking up to this module, I expected to be able to take the resource outputs named arn_suffix from both the TG and ALB:

https://www.terraform.io/docs/providers/aws/r/lb_target_group.html#arn_suffix
https://www.terraform.io/docs/providers/aws/r/lb.html#arn_suffix

and pass them directly to this module, like this:
module "alb_alarms" {
    source                  = "git::https://github.com/cloudposse/terraform-aws-alb-target-group-cloudwatch-sns-alarms.git?ref=tags/0.2.0"
    alb_name          = "${aws_alb.foo.name}"
    alb_arn_suffix          = "${aws_alb.foo.arn_suffix}"
    target_group_name = "${aws_lb_target_group.foo.name}"
    target_group_arn_suffix = "${aws_lb_target_group.foo.arn_suffix}"
...
}

Instead, I need to perform the very regex interpolations that the arn_suffix resource outputs were specifically designed to eliminate:
module "alb_alarms" {
...
    alb_arn_suffix          = "${replace(aws_alb.foo.arn_suffix,"/app/[^/]+//","")}"
    target_group_arn_suffix = "${replace(aws_lb_target_group.foo.arn_suffix,"/targetgroup/[^/]+//","")}"
...
}

Is this intentional in this module or am I missing something?

For reference, suffix output examples are in the tests:

https://github.com/hashicorp/terraform/blob/04bda48c36388593fcb4f5cdb795c4330d9ecc6b/builtin/providers/aws/resource_aws_alb_target_group_test.go#L25
https://github.com/hashicorp/terraform/blob/04bda48c36388593fcb4f5cdb795c4330d9ecc6b/builtin/providers/aws/resource_aws_alb_test.go#L25-L26

Confirmed this, pushing out a PR shortly


Converted Seattle Lidar example to a project

Converts the Seattle Lidar example on EarthML to a project. Testing and running correctly locally. This project might be able to work on Travis as long as the intake download from S3 can happen fast enough. When the necessary data is in the cache, the notebook runs fairly quickly.

Tests are green and the comments addressed. I need this merged to master to continue with the website builds. I'm merging now but happy to open another PR if further tweaks are needed.


Switch to use Bazel Modules

Hi there,
thanks for your awesome work on hermitic gcc toolchains for bazel. Its a very helpful idea to get build processes more deterministic and reliable.
As Bazel will drop the support for the old WORKSPACE architecture (see bazel roadmap ) and switch to new module design and it would simplify especially these kind of projects, it would be very nice to switch to this system ( Bazel modules ) with your project, too.
best regards,
Daniel

Hi Daniel, thanks for posting here.
Would you be willing to contribute the bzlmod support? If not, I'll be able to get to it in the coming months.

Hi,
thanks for your response and your offer! Atm I think that I can not contribute faster then in a few months to it, as i need a deep dive into your code first, to understand what must be changed. So I thing I need getting a block of time free for it, this is not possible in the next weeks, sorry. If you find time to work on this, would be very great :-)
best regards,
Daniel


(APS-352) Remove accessibility benefits section

Context
JIRA
The accessibility benefits section does not map directly to any questions in the application
Changes in this PR

Remove accessibility benefits section from matching information screen in the Assess journey (/assessments/:assessment-id/tasks/matching-information/pages/matching-information)

Screenshots of UI changes
Before

After

Release checklist
As part of our continuous deployment strategy we must ensure that this work is
ready to be released at any point. Before merging to main we must first
confirm:
Pre merge checklist

[🤷🏻♀] Have all changes to any dependencies been deployed to both preprod and
production in a backwards compatible way? (This includes our API,
infrastructure, third-party integrations and any secrets or environment variables)
[ ] Has a required data migration been included in this change or been done in
advance?

Post merge checklist
Once we've merged we now need to release this through to production before
considering it done.
Find the build-and-deploy job in CircleCI
and work through the following steps:

[ ] Has the product manager asked to provide approval for this feature?

[ ] Has the product manager approved?

[ ] Manually approve release to preprod
[ ] Verify change released to preprod
[ ] Manually approve release to prod
[ ] Verify change released to production

Should a release fail at any step, you as the author should now lead the work to
fix it as soon as possible.

I think the link to Jira is incorrect!
Maybe using the ticket title plus the ticket number in the link would be more resilient? e.g.
APS-352: Remove accessibility benefits section from matching requirements screen

I think the link to Jira is incorrect!
Maybe using the ticket title plus the ticket number in the link would be more resilient? e.g.
APS-352: Remove accessibility benefits section from matching requirements screen

Also, a heads up that this change may require the E2Es to be updated

Also, a heads up that this change may require the E2Es to be updated

Looks like this set of checkboxes weren't covered by the E2E tests. The suite did fail here but passed for #1521 (merged later), so it looks like the failure was just flakiness (the error looked unrelated). Hopefully I can get access to dev soon to update E2E tests for the later changes!


Re-implement VisualScript using a 'block and wire' system

The system is very straightforward in concept:
Scratch-style puzzle-blocks with the flexibility of Blueprint-style node-wiring.
Visual scripting seems to be dominated by a node-wiring paradigm throughout the biggest game-engines, which is great for flexibility and seeing the flow of process logic, however it quickly becomes visually busy and unappealing to work with as scripts become larger and more complicated.
Partly, this complexity can be addressed with an abstraction feature which can encapsulate complicated logic into a simple new node, however, I feel an even more clean approach would be to embrace the verti-linear structure of code blocks as seen implemented with Scratch, and Googles 'Blockly' system. https://developers.google.com/blockly/
Essentially. Wiring would be limited to just the types of blocks necessary to implement the continuation of program flow. That is, most of the program would be written as vertical 'clusters' of code-blocks representing some portion of the necessary logic (ie. a step in whatever process is being achieved), and then wiring would connect that cluster to the next which represents the next step.
For example, when one finds the need to do some complicated process inside a loop or nested loop structure, but would otherwise complicate the present cluster, the wiring flow could break away to a cluster dedicated to the loop, and then come back from the loop to a new cluster which can be directly below the inital cluster before the break-away.
This allows for cleanly putting code aside, while also using the visual layout to describe continuity. It may even be preferable for the first and third cluster to reconnect in a distinct manner to explicitly describe the continuity.
EDIT:
This is a very rudimentary mockup that just shows how clusters of blocks can have verti-linear flow much like text-based scripting, but still benefit from wiring flow, allow for a more freeform organization of code.
note the verti-linear flow would also help visual scripters transition to text-based scripting

Coudl you maybe post a mockup of how this would look? I have a hard time imagining this.

Can you post a photo? I am not sure which of the three types of visual scripting it is.

flow based programming (blueprint, godot)
blockly
event sheets

My understanding is that all three of these are just different views on the same data.
It should be possible to equivalently structure code in any of those formats. If I understand, @qaptoR, you are proposing to allow users to use nestled blockly/scratch style blocks, and then take multiple of these code blocks and continue flows with wires?
Making functions to split up the code into smaller pieces is another way to do this, but wires could work too. I don't think the proposed paradigm will work if wires are nestled inside code flow.

For example, when one finds the need to do some complicated process inside a loop or nested loop structure, but would otherwise complicate the present cluster, the wiring flow could break away to a cluster dedicated to the loop, and then come back from the loop to a new cluster which can be directly below the inital cluster before the break-away.

I don't know mixing and matching in the way you suggest is possible. For example, imagine you had a loop inside an if statement:
[if enemy_nearby {
    [for i in range(particle_burst_count) {
       [print("Spawn bullet")]
                     ----> spawn bullet ----> ???
    }]
    # is this a separate block? is tick_particles moved below?
    [tick_particles()]
}]
# what about the case where I don't go in the if statement

I wonder if once a particular part of the code has been split up, all the parent blocks would have to be split up. But then what if there is an if statement surrounding the whole function?
Example modified from https://github.com/geekdojo-io/scratch-programming :

Here's some example I threw together with Visual Script adding 1 to transform.origin.y 4 times every frame:

prints:
[X: (1, 0, 0), Y: (0, 1, 0), Z: (0, 0, 1), O: (0, 389, 0)]
[X: (1, 0, 0), Y: (0, 1, 0), Z: (0, 0, 1), O: (0, 390, 0)]
[X: (1, 0, 0), Y: (0, 1, 0), Z: (0, 0, 1), O: (0, 391, 0)]
[X: (1, 0, 0), Y: (0, 1, 0), Z: (0, 0, 1), O: (0, 392, 0)]
Hello, World!

Here's an imagining of how scratch style blocks could be done:

How would this be done in this proposal?
I imagine that blocks can be pulled out and carry a connecting wire with them, kind of like:

I forgot to change the string being printed, but you can imagine this program would do the following:
Hello, World!
[X: (1, 0, 0), Y: (0, 1, 0), Z: (0, 0, 1), O: (0, 389, 0)]
Hello, World!
[X: (1, 0, 0), Y: (0, 1, 0), Z: (0, 0, 1), O: (0, 390, 0)]
Hello, World!
[X: (1, 0, 0), Y: (0, 1, 0), Z: (0, 0, 1), O: (0, 391, 0)]
Hello, World!
[X: (1, 0, 0), Y: (0, 1, 0), Z: (0, 0, 1), O: (0, 392, 0)]
Hello, World!

That is to say, it would first update the transform, then print Hello, World!, then print the transform. Finally, at the end of the loop, it prints Hello, World! again.
Obviously, the input and output ports in the mockup are in the wrong places, and you'd want arguments to be nestled appropriately, possibly even using shapes to denote <predicate>, (value) or other special types like what Scratch does.

@derkork @fire, there is now a mockup of what the flow could look like
@lyuma has brought up fantastic points.
To address them:

Wiring flow is different from abstracting logic into a function.

Functions specifically hide the logic, forcing the user to go and look for the definition if necessary

Wiring flow is like taking the text-based loop, and adding a second parallel column of text, by taking advantage of the visual space available

I do think that wiring flow should be available inside function abstractions
flow should only be possible from the end of a statement to another statement or logic/loop body where code can be nested, and it should be explicitly clear when going back to the flow outside of a body from only the end of a body

eg. statement A goes into a for loop B

inside B we go to statement Ba

Ba comes back to B when it ends

at the end of loop B we go on to statement C

@fire also brought up the idea of there being 'event sheets', which to me seems like a great idea to help organize code. That is to say I think a single VisualScript file should have the capability of having multiple grapheditor sheets.

First of all, I really like the current visual script, it was getting a 9.6-9.8 feature in Godot 4 . .
If you're gonna develop this, make it something else, please just maintain the current stuff, it's getting very good . . .

It's a full coding system, no dumbing down . .
It's getting, finally, really nice in Godot 4 . .
People that have liked it for years, won't like some new replacement
I think this is called 'scratch' coding, and it's not as elegant, or useful as the current stuff . .

So, I suggest if anything, make it a new feature, and, at least keep the current visual script system . . .

I would agree on @charlesmlamb's take here.
First order of business should be making the current system work as a GDExtension with Godot 4. I am currently on this but it is progressing a lot slower than I would like, mainly because the new GDExtension system is very new and needs a lot of tweaks here and there to support all the functionality and engine extension points that the visual scripting needs.
After this has been done,  a next step could be incorporating other kinds of visual scripting, e.g. some of the suggestions raised here and maybe also some stuff like state machines and behaviour trees which can tremendously help in rapid prototyping.
Another approach could be to make multiple extensions that use different approaches to visual scripting and then everyone can choose the approach that works best for them (or even combine them).

Working with other horizontal node based visual scripting languages [Bolt, Blueprints, Blender Nodes, Cinema Nodes, etc] I found myself trying to separate operations or data, from the flow that will execute the operations.
There are some node based systems with a vertical design, and I think the way they try to tidy the logic is very helpfull.

Unity's Visual Effect Graph<EMAIL_ADDRESS>

Bolt 2: https://ludiq.io/blog/bolt-2

So here is my aproach for a mock-up thincking in this concept.

I think simplification is welcome and i will push the concept of playing with boxes of data, and make it colorful and have icons in order to find quickly the node desired. Regarding this I don´t know how to feel regarding the naming on each variable type inside the nodes (bool, float, vec3, etc). Most other visual scripting language assume that if there is a color code for variable types, then the color means the type.

I think also that Godot has a minor readability problem regarding variables color code by type, cause float, int, strings and bools, are too close on it's color and it's not clear the difference between them only looking at it's color can cause confusion. Here is another mock-up trying to simplify components.

Groups should be something useful, but also "signal connectors" in witch you can create a connection but not show the line conection in order to not have multiple lines crossing your graph. Ej. using delta value from _process.
Line conexion

"Signal" conextion. [This can be also used storing variables and reusing that data, but in a fancier way.]

The proposal don´t cover the color usage or shape style so other designs are welcome.

Who is this VS language for,
is probably one of the first questions we would need to answer IMO
There are very different answers to problems depending on who it is aimed at.
Maybe we should also come up with requirements we want a new VS language to fulfill, basically like a wish list what an optimal solution would provide and then figure out how to get as close as possible to that wish list.

See also https://github.com/godotengine/godot-visual-script/issues/27

I think, these are good suggestions . . Perhaps starting a topic, about several visual script extensions now, since it's possible, and, then finding the best one's . .
However, I do think the current is best, in that it is useful to beginners, but, can also be used for pro work . . And, that what was in Godot 4 was perhaps the ' Godot ' visual script, and, also it fits gdscript, sort-of it's the same stuff . . That also makes it fast, easier to integrate, etc . .
However, I think working on perhaps several visual script languages now, is more possible . . There prob. just has to be different github, or, somehow topics for it . . Also, right now I think it's about making use of the years of work, already added to current system, and, that works as extension, of visual script in 3.5, where it is still being worked on, etc . .
Last, I think maybe the coders here have a super - challenges right now, to just get the system already there working, so we can have visual script back, in the fast way, ie. keeping the current system, for now . . . :-O

There are different approaches to non-textbasedcode. And people will feel more comfortable with different styles.
If vs goes to an extension, it's sure it will be multiple vs extensions with different arrangements.
This is issue is "Re-implement VisualScripting using 'block and wire'".
Imposing one vs arrangement over the others as the official, if now vs is going to an extension, sounds weird to me.
I will suggest not having "Godot's Visual Scripting" as a name, I think we can structure the project better, naming better the project, so that Godot's Visual Scripting not imply that other arrangemnts are not valid and not seen as "official visual scripting".
Creating a Godot's "Blocks and Wire Visual Scripting" , "Sheets Style Visual Scripting", "Scratch Visual Scripting", ... as different projects. Other issue could be making all these styles based on a common under base structure, to not duplicate work.
With this in mind I think the best approach is having an usable "Blocks and Wire Visual Scripting", that is the one that Godot was using.
Maybe in the future, another style is desired as the official one, so this will also cover the Blocks and Wire Visual Scripting style inside Godot.
Regarding Blocks and Wire Visual Scripting:
I would love customization similar as how much blender inferface is not that much hardcoded and there are multiple settings to change type colors, roundness of boxes, curving of lines, ...,  and if there is the ability to change flow from horizontal to vertical as an option, would be amazing to me, as @charlesmlamb described.
At the end this is a personal thought that is being shared in order to see how much people resonate with it.
Trying to be more practical some ideas I think are needed are:

[] Use scripts as nodes, allow vs script to output and input data, and that way reuse logic and create more individual blocking logic. Similar to groups but with reuse as focus.
[] Reroutes.

My thoughts exactly, I think even Juan said, he wanted to add 'scratch' some time ago, in some poll . . .
One advantages right now, since there isn't ' one ' visual script language, is one could start thinking about having several extensions, the big problem is someone has to code that stuff . . And, scattering effort over several languages, effectively means we get nothing, or, it'll take forever . . For now, I think it's better to just focus on the current one, not getting even scattered, however, I think having early debates, also thinking what could be done, getting advice from coders, then looking at what's possible, I hear good things about some of the other systems, however, I think for now, simply talking about it, and, not making any plans, is prob. a minimum . . Making these coding languages, I have an idea it might not be as easy, as at least asking for them . . . However, I think it's fun to debate, and, having several extensions, for even different coding systems, might be quite cool, a ton of people say this is quite good, esp. for beginners, I think it's called ' scratch ', not sure . . .

I think simply adding the years of work already done, as simply the best priority, doesn't make sense, people know the system, ton of people want it back, and, it's so good, it could be used by small teams, perhaps even (pro) studios . . Getting that back, or wasting time, not getting that back, also the coders that have made it, understand it, it makes sense to do that first . .
To not stress, over new systems, simply think about, have early ideas, pick a few one's, then keep them on list of, maybe, or, if there are enough volunteer coders, that then 100 % can code, design etc . .
I think we could make a list of potential, or one_day other coding systems, keeping it as early debate, and, keeping it fun, or early ideas, at best . .

These things are possible right now, in a sense, make some different extensions, however, I think the team that started this page prob. want to work on what was being finished, in Godot 4, a very pro, advanced visual script, and, having a more simple system, in Godot 3.4, and I think that's simply the best thing, that could happen . . . After that, or if other people want to develop a separate extension, that might make some sense . . .

I think everyone is talking about different things. We need to try to figure out what the future Visual Scripting system should look like, having a discussion about it (as we do right now). We need a good forum to do this, either GitHub discussions (git admin can enable this), Godot discussion forums (sadly not used much for such discussions), or something else. Right now I see four or five different issues just to discuss how Visual Scripting should carry on forward and sadly it tends to become messy pretty fast.
I found these discussions very interesting and would really like to collect them into one place so you can get a great overview over what alternatives there are.

Yes, I would also be interested in discussing a future VS system and I think it shouldn't just be a discussion about which of the existing systems we should pick, because we will never find a consensus about that since everyone simply prefers 1 system and will be dissatisfied with anything but that system. No, I think it should be a discussion about the advantages and disadvantages of these different systems in an effort to create a tailor made system that specifically fits Godot.
I could imagine that it would also be easier to find developers interested in working on a tailor made Godot VS language instead of copying an existing one.
These discussions should probably be disconnected from the efforts to maintain/extend/port the current system though, which I agree is a sensible thing to do since it already exists.

@fire if you have admin, would it be possible to enable Discussions for this GitHub repository?
https://github.com/godotengine/godot-visual-script/discussions gives 404

I think it'd be nice to think, or early brain-storm possible visual script systems, that we might one day want . . Also, for the coders to simply start thinking, a tiny bit, about one-day, maybe that'd be nice, beyond that, I think all focus should be on finishing the work, started in Godot 4, it only makes sense, it was getting to be an almost pro feature, and, trying to implement some new system will take much longer, it'll be both difficult, and, esp. blood-sweat, perhaps tears for the coders, it's semi - easy to ask for something, actually setting a few years aside, to make something, I think the coders should have almost final say, esp. if it's a difficult, or advanced system to implement, or code with flair . . In the end, should the coders walk away, or not want to work on something, it doesn't really matter, then we're never gonna get it . .
I wish this page had a reddit, where people could talk, etc, and if something was good enough, it could be posted here, perhaps a Facebook, I think this is better made to be work, or code only, have a very different place, to debate this stuff, and, a link in one of the topics here, reddit is super - good for that stuff, maybe there's a volunteer here, who could start the page, and, perhaps moderate it, leaving the coders time to work, on the basically point, of this code github, or so . . . .
We need to think about what works for the coders, if they leave, the entire purpose of this just doesn't work, etc, and, how to constructively, or sensibly ask for stuff, so it adds to the engine, but, also the work, that's either difficult, or challenging, for the actual coders, etc . . 👍

@akien-mga Can you help out, I can see discussions but they don't seem to be public.

Wow, thank you to everyone who has contributed to this discussion. After reading everyone's perspective here I concur with some essential things which have been proposed

Godot can have multiple visual languages now that they are moved to extension status

Godot should have multiple visual languages because they support more types of coders which is in the spirit of Godot

The VS languages should be developed foremost for Godot, and not to copy some other paradigm. Similarities and inspiration should be in service of what works for Godot.

The general community should work on porting the current system first, then branch out onto a few ideas which have established benefits for one interest group or another, eg. a language meant for kids 8-10 who are learning to code.

I seem to recall Juan mentioning in his post about the removal of VS that it was due to how few users find VS easier than GDscript. I concur with that sentiment. I personally have found little reason to use VS over GDs.
This proposal was meant to highlight what I felt were limitations to the present paradigm, and offer suggestions for how to make VS easier for younger coders as well with an emphasis on design that makes transitioning to regular scripting easier.
Now, after this lengthy discussion, I feel that Visual Scripting, above and beyond being useful for artists and non-coder types, should be focused on providing features that are easier to comprehend visually, rather than with code. Such as Color nodes, timing-graphs nodes, gradient nodes, or texture nodes etc.

I agree, however as someone who wants to make pro, or hard-core stuff, the current VS is, sort-of really good for pro work . . Making it more ' simple ', like Godot 3, I sort-of think Godot 4 has -the- best VS, I've prob. ever seen . . If one wanted a simpler VS, I'd just tell people to use Godot 3 . . Anyway, for me, wanting to do perhaps pro - work, the current full-coding language system, quite advanced, only makes it better . . . I think they should finish Godot 4, then perhaps find other ways, of coding, I hear a ton of people saying, the scratch stuff is very good, I have not tried, however everyone says it's good system . . .
Having VS in Godot 3 means, there's no hurry to make Godot 4 VS, as such . . One can make the same stuff in Godot 3, I'm waiting for the work finish here, to get started on VS spec. for Godot 4, my point is, finish the current system, it's quite advanced, makes it more fun to use, and, maybe there are other good systems, or so . . . :-))) <3

The biggest issue with event sheets that I see is that the flow becomes linear, from up to down similar to real code. Then of course Event Sheet is good if that kind of flow should be visualized since using nodes would make it more difficult to read. Also, it is how most things are coded, if an event occurs then do this and that in that order. However, an event sheet would miss out on the flowchart-style design that nodes might give. A flowchart design would make it possible for a higher level of abstraction and overview but then not so many implementation details can be put, else it will look messy quite fast.

I haven't used Godot before so I'm sorry if I don't understand something.
I wasn't really sure if I should create a new issue for this but I was reading through this thread and one use case for Visual Scripting that I haven't seen is to be used as a designer/editor tool. Programmers create larger building blocks for designers to connect together.
I'm the maintainer of a package on Unity (Currently in the process of forking): https://github.com/dannymate/NodeGraphProcessor
What I personally use the tool for is as an editor for a ScriptableObject. There's a button on the ScriptableObject that when pressed opens a graph. It creates a source node based on that ScriptableObject with generated ports. You can then plug nodes into those ports and when saved everything gets compiled into the ScriptableObject. In Godot's case a ScriptableObject would be a Resource.
I can go more in depth if this interests anybody but maybe this is a direction VisualScript could go or as something built on top of it to provide a use case. I could foresee maybe extending from GraphResource instead of resource and adding whatever an attribute is in GDScript for Inputs and Outputs on different variables.
Also if there's anything I can do to help with this as somebody who doesn't know C++ please let me know what I can do!

Hi guys, I´ve experience with a lot of VS tools like Cryengine Flowcharts, Unreal kismet and blueprints, most of unity ones and even some related to engineering and industrial automation.
The set of tools that mostly made sense, had performance and was well integrated by far from my point of view was Bolt 2, unfortunately acquired and discontinued by unity, they choose to stay with Bolt one because it was ready, but Bolt 1 tech was really old and lacking after all that time, now bolt1 is not receiving any more development and Unity is in a bad situation regarding VS. What's maybe fortunately for other engines.
Bolt 2 had an beautiful design and VERY easy to read because of the chosen colors and contrasts, code generation offered the best performance in comparison to reflection and for people that love visual scripting, it felt like a real and complete IDE.
Here we still have the design document:
https://www.notion.so/Bolt-2-6a85ef4102694be889fb8413ab83aaa7
And here PanthenEye make a useful full-of-gifs, defense of Bolt 2, against a mega corporation incapable of doing what one guy was doing alone.
https://forum.unity.com/threads/on-the-road-to-the-next-major-version-of-unity-visual-scripting-lessons-from-bolt-2.1285637/
Gif example "creating a sub group in seconds":

I believe its design deserve some review and consideration.

Plus it was an unity extension, making it easier to develop and maintain, it loaded a defined set of namespaces and types, but the user could manually add any other. And for last there was a set of high level nodes, but if you look at the documentation, "which covered only those manually developed high end nodes and general functionality" they were just a few. Not too much in terms of development

I will still say that the best one is my experience is the event sheets. If you look at the number of games shipped on steam using visual programming exclusively, it also wins over skratch and the spaghetti nodeness.
Construct2+3 and Clickteam fusion are quite impressively dominating

Verge3D uses Blockly and is quite compelling, but as a true non-programmer (never got beyond Basic, try as I may, and even simple GDScript makes my eyes glaze over) I was able to do quite a bit with Construct 3's event system with little trouble.

And here PanthenEye make a useful full-of-gifs, defense of Bolt 2, against a mega corporation incapable of doing what one guy was doing alone. https://forum.unity.com/threads/on-the-road-to-the-next-major-version-of-unity-visual-scripting-lessons-from-bolt-2.1285637/

I just want to note that every single improvement he demonstrates in Bolt 2 there already exists in Unreal Blueprints.
If Visual Script makes a comeback in Godot, I would hope the aim would be to surpass Blueprints.

Please consider an event sheet approach instead of this. Nodes already tried and failed :(

Appeared that someone already made another vs scripting plugin? https://github.com/Vahera/godot-orchestrator


Fix State

Using HomeAssistant 2023.4  - when running chrome dev-tools:
translationsl["component.person.state._.home"]
>undefined

but
translations["component.person.entity_component._.state.home"]
>'Home'

See this:
https://developers.home-assistant.io/blog/2023/03/27/entity_name_translations/
Should fix #35

@GuyKh is it possible to use your repo from HA?

Add to Hacs: https://github.com/GuyKh/person-entity-card (and please star the repo)

Thanks a lot! First ⭐ well deserved.


WIP Simplify custom binary serialization

This change is meant to allow users to

overloading void serialize_value(const T& value

instead of

specializing void set_patch_from_property(const P& property

for a specific property type.

OK, so basically I am facing this issue:


CIV-5327 Remove R2 screen

Before creating a pull request make sure that:

[x] commit messages are meaningful and follow good commit message guidelines
[x] README and other documentation has been updated / added (if needed)
[x] tests have been updated / new tests has been added (if needed)

Please remove this line and everything above and fill the following sections:
JIRA link (if applicable)
https://tools.hmcts.net/jira/browse/CIV-5327
Change description
Exclude R2 Enhancement Screen
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[ ] No

API

Smoke test

https://github.com/hmcts/civil-general-apps-ccd-definition/pull/380

Remove basic-access profile as it's been no longer exits


allow main source file to have not only .cc extension

fixes #980

Does this allow any file that has main before period? Perhaps, it better to allow a finite set of extensions?

Does this allow any file that has main before period? Perhaps, it better to allow a finite set of extensions?

listSourceFilePaths function already lists only source files with an extension in SOURCE_FILE_EXTS, so main source file must have one of those extensions.

Thank you for working on this!

Does this allow any file that has main before period? Perhaps, it better to allow a finite set of extensions?

listSourceFilePaths function already lists only source files with an extension in SOURCE_FILE_EXTS, so main source file must have one of those extensions.

listSourceFilePaths finds source files recursively, so src/foo/main.cpp could be used for example but this should be treated as a normal source file, although this is awkward (for better usability, we can consider emitting a warning as it's likely a human error). Also, if there are multiple main source files, which file will be chosen is ambiguous. So, I think the best rules will be:

There should be only one main source file., if not, emit an error (multiple main files).
The main file should be directly in the src directory, if not, emit an error (not found).

Eventually, we can also implement the src/bin binary target feature and those rules wouldn't interfere with this feature.
I would love to hear your thoughts!


Remove support for endOfNight_additionalSteps.sh

We told people in v2023.05.01 that support for endOfNight_additionalSteps.sh was going away in the next release.
Well, this is the next release.
Remove all references to that file EXCEPT in install.sh where we check for it an if found produce a message "this file is no longer supported".

Fixed in next release.


Update increase-the-recoverable-quota-for-mailboxes-on-hold.md

Updated the URL for the deleted item retention period.
Fixes#https://github.com/MicrosoftDocs/microsoft-365-docs/issues/10431

@JohanFreelancer9 Please copy review

Learn Build status updates of commit da6451f:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

microsoft-365/compliance/increase-the-recoverable-quota-for-mailboxes-on-hold.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

Learn Build status updates of commit 7d31170:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

microsoft-365/compliance/increase-the-recoverable-quota-for-mailboxes-on-hold.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

Learn Build status updates of commit a225bdb:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

microsoft-365/compliance/increase-the-recoverable-quota-for-mailboxes-on-hold.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

@msbemba - thanks, updated in separate PR.


fix(buttons): use theme toolbar colors for default iOS buttons

Pull request checklist
Please check if your PR fulfills the following requirements:

[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been reviewed and added / updated if needed (for bug fixes / features)
[x] Build (npm run build) was run locally and any changes were pushed
[x] Lint (npm run lint) has passed locally and any fixes were made for failures

Pull request type

Please check the type of change your PR introduces:

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Codepen reproducing the problem: https://codepen.io/brandyscarney/pen/VNoPNj?editors=0110
Issue Number: #18184 and #17840
What is the new behavior?

Updates the iOS buttons in a toolbar to use the proper global theming variables
Fixes the iOS segment to use the correct background variable when checked
Fixes the iOS back button to use the proper color in a toolbar

Does this introduce a breaking change?

[ ] Yes
[x] No

Other information
Fixes #18184, fixes #17840
The iOS buttons were not using the global theme variables that the material design buttons did use. So in the conference app, for example, if you applied the same global theme variables as md is using, it wouldn't work in iOS. Here's a before & after of this with the following custom variables:
:root {
  /* Custom Toolbar CSS (optional) */
  --ion-toolbar-background: #000;
  --ion-toolbar-border-color: #333;
  --ion-toolbar-color: limegreen;
  --ion-toolbar-color-activated: rgb(35, 156, 35);
}

/* Customize the Toolbar Segment by Mode */
.ios {
  --ion-toolbar-color-unchecked: limegreen;
  --ion-toolbar-color-checked: limegreen;
}

.md {
  --ion-toolbar-color-unchecked: rgba(255, 255, 255, .6);
  --ion-toolbar-color-checked: #fff;
}

Note that this also has a ton of other custom variables above it for the background/texts.
master:

branch:

I found some issues with the toolbar colors that exist on master that I am looking into.

This should be good to go now!