LogicalVolumes "leak" and slow down provisioning

Describe the bug
LogicalVolume objects tied to deleted nodes are not cleaned up and cannot be cleaned up, because the finalizer field is cleared by the topolvm-node on the node itself (which is no longer running).
Over time this results in the number of LV objects building up in Kubernetes.  The controller is constantly trying to process these and that leads to a general slowdown in that and thus in the provisioning of new volumes (as it's spending a lot of time/threads trying to delete LVs which can't be deleted)
According to the docs:

LogicalVolume is created with a finalizer.
When a LogicalVolume is being deleted, topolvm-node on the target node deletes
the corresponding LVM logical volume and clears the finalizer.

I've seen this happening on two of my own clusters today: one had 400+ stale LVs and another 1200+, built up over a year or so (through multiple topolvm upgrades but there were stale LVs created today - I upgraded to 0.18.1 weeks ago). On the larger cluster it was taking many hours to do a full rolling redeploy of 170 pods over 22 deployments
Note that LVs actually seem to get into two states:

They are marked for deletion (have a deletionTimestamp), but the finalizer blocks it
They belong to an invalid node (.spec.nodeName is no longer a valid node) but are not marked for deletion (and still have the finalizer, so once they're deleted 1 will become an issue)

Environments

Version: 0.18.1
OS: EKS v0.23

To Reproduce
Steps to reproduce the behavior:
I haven't figured out a surefire way to reproduce this - I can delete a node and the topolvm-node process usually seems to pick that up. I suspect that given certain conditions that process is either slow or the pod isn't running or gets terminated too quickly, and it doesn't get to removing the finalizer
Expected behavior
If the node that a LogicalVolume belongs to no longer exists, the controller should remove the finalizer itself before asking for its deletion
Additional context
These two scripts tidy up the LVs for me, in the short term I'll keep running them on an ad-hoc basis:

Delete LVs tied to non-existant nodes:

kubectl get logicalvolumes -ojson | jq -c .items[] | grep -vf <(kubectl get no -ojson | jq .items[].metadata.name -r) | jq -r .metadata.name | xargs kubectl delete logicalvolume

Remove finalizer on deleted LVs to allow deletion to complete:

kubectl get LogicalVolume -ojson | jq .items[] -c | grep deletionTimestamp | jq -r .metadata.name | xargs -I{} kubectl patch LogicalVolume {} -p '{"metadata":{"finalizers":null}}' --type merge

Hi @spmason
Are you using the --skip-node-finalize flag? In that case, the node finalizer is skipped and the LogicalVolumes should be deleted manually.
https://github.com/topolvm/topolvm/blob/6ed49a173e07fdfe48fc98af3ea02a1e2ea2903c/docs/topolvm-controller.md#node-finalizer
If that is not the case, could you provide me with the topolvm-controller's log at the time of node deletion and the problem occurred?
In the normal case, when the node is deleted, the topolvm-controller deletes LogicalVolumes related to the node. And then the finalizer on the node is deleted by the topolvm-controller. Because you are saying that some LogicalVolumes remains not marked as deleted despite the relevant node being deleted, the topolvm-controller might not be working correctly.

Do you mean the topolvm-node? That's what the docs say, and my logs from the time of the delete imply that too

Sorry for my confusing explanation. First of all, there are two kind of finalizers involved in the node deletion process: node finalizer and LogicalVolume finalizer.
The ordinary procedure of node deletion is as follows (complicated...) .

When the node is marked as deleted (= deletion timestamp is set), topolvm-controller realizes the event via the finalizer on the node.
topolvm-controller tries to delete all the related PVCs.
PVC deletion triggers the gRPC call to delete the volume for topolvm-controller.
topolvm-controller tries to delete LogicalVolume resources.
topolvm-node realizes the deletion of LogicalVolume, and ask for lvmd to delete the underlying LVs of LVM.

In my understanding, the node won't be deleted completely until all the related LogicalVolumes are deleted. I'm not sure why the node was deleted without cleaning up the LogicalVolumes. That's why I wanted to see the topolvm-controller's log.
Are there any event in the topolvm-controller's log around the time when you marked the node as deleted, and the time when the node was actually deleted?

The topolvm-node logs are more interesting:

The log says that topolvm-node asked for lvmd to delete the LV but it failed.

It retries this until the node is taken out (leaving the LV stranded I assume)

Let me clarify this point. The node has finally been deleted, but some LogicalVolume resources were left undeleted, right?

The logs for topolvm-lvmd are also relevant as tha seems to be what's returning exit status 5:

As you said, lvremove should succeed once the related pod is deleted.
By the way, could you tell me how you deleted the node? Did you drain the node before deleting the node resource?

Thanks for the explaination. At what point during that process does the controller remove the finalizer on the node? At that point the node can be removed, so I'm wondering if that happens before the LV has been properly deleted.

Are there any event in the topolvm-controller's log around the time when you marked the node as deleted, and the time when the node was actually deleted?

No other errors or warnings

The node has finally been deleted, but some LogicalVolume resources were left undeleted, right?

Yes, well they were marked as deleted (have a deletionTimestamp), but that was "hung" waiting on the finalizer to be removed on the LogicalVolume

could you tell me how you deleted the node? Did you drain the node before deleting the node resource?

We're using karpenter to manage our nodes, it will be what shuts them down (it handles it in the usual manner - cordon the node, drain the pods then delete the node at the end)

lvremove should succeed once the related pod is deleted.

So our pods take a while to shut down - could topolvm-node be backing off on the deletion attempts, to the point where it's taking so long between retries that the next attempt never happens because the node has been shut down?

At what point during that process does the controller remove the finalizer on the node? At that point the node can be removed, so I'm wondering if that happens before the LV has been properly deleted.

The finalizer on the node is deleted after deleting all the related PVCs. In v0.18.1 (which you are using, right?), it is done in the following lines of code.
https://github.com/topolvm/topolvm/blob/v0.18.1/controllers/node_controller.go#L68-L86
In r.doFinalize, PVCs are deleted.
I will further investigate the behavior around these functions. (It may take several working days.)

We're using karpenter to manage our nodes, it will be what shuts them down (it handles it in the usual manner - cordon the node, drain the pods then delete the node at the end)

The node is deleted after draining the pods, so I'm wondering why the filesystem is still in use at the time of node deletion. At this poind, all the pods must be removed. Do you have any ideas?

could topolvm-node be backing off on the deletion attempts, to the point where it's taking so long between retries that the next attempt never happens because the node has been shut down?

Though I'm not very familiar with the topolvm-node's back off interval, I guess the exponential back off is adopted. Even if that is true, it is strange that the node is finally deleted.

In r.doFinalize, PVCs are deleted.

Right, I see. And the LVs are deleted too. It also seems to be removing the finalizer on the LV itself? Got to admit that my Go knowledge isn't particularly strong but I think that's what cleanupLogicalVolumes is trying to do here?
https://github.com/topolvm/topolvm/blob/v0.18.1/controllers/node_controller.go#L167-L182
So even if topolvm-node isn't running then this code should be removing the finalizer on the LV and allowing the deletion - maybe something is wrong there?
Looking at the node_controller logs from around the time of a delete that orphaned an LV, the only log line I see is deleted LogicalVolume.  The LV didn't get deleted but it looks like it at least tried  - but the finalizer was left on it, which implies there's something wrong with the remove-finalizer code in cleanupLogicalVolumes? Or maybe it was recreated by something?
One last thing I noticed - it looks like that controller should also log when it deletes the PVC, and it didn't, so maybe that was cleaned up elsewhere? I don't know if that's a problem at all
I've added some more logging to that method anyway and deployed to my test cluster, hopefully that will give us some clues

I forgot to address this:

The node is deleted after draining the pods, so I'm wondering why the filesystem is still in use at the time of node deletion. At this poind, all the pods must be removed. Do you have any ideas?

My guess would be the backoff in topolvm-node means it doesn't remove the LV finalizer in time before the node gets torn down. However the node finalizer code should also remove the LV finalizer before allowing the node deletion, so I'm not sure what's going on here.
I thought it might be a karpenter bug, but I just tested by adding my own finalizer to a node and it's blocking deletion as expected

I have noticed this in the topolvm-node logs on the node I'm deleting:
{"level":"error","ts":1688722585.7012916,"msg":"failed to add finalizer","controller":"logicalvolume","controllerGroup":"topolvm.cybozu.com","controllerKind":"LogicalVolume","LogicalVolume":{"name":"pvc-42f87fd2-7ef0-481d-a773-92ad2a996246"},"namespace":"","name":"pvc-42f87fd2-7ef0-481d-a773-92ad2a996246","reconcileID":"18323ef2-74c2-4136-b61a-8c0cad8439ab","name":"pvc-42f87fd2-7ef0-481d-a773-92ad2a996246","error":"logicalvolumes.topolvm.cybozu.com \"pvc-42f87fd2-7ef0-481d-a773-92ad2a996246\" not found","stacktrace":"github.com/topolvm/topolvm/controllers.(*LogicalVolumeReconciler).Reconcile\n\t/workdir/controllers/logicalvolume_controller.go:68\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.13.1/pkg/internal/controller/controller.go:121\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.13.1/pkg/internal/controller/controller.go:320\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.13.1/pkg/internal/controller/controller.go:273\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.13.1/pkg/internal/controller/controller.go:234"}
/

So it's trying to add the finalizer to the LV? I guess if this were to succeed then that could cause this problem I'm seeing where the finalizer isn't cleaned up? The sequence of events being:

Node is deleted
Node controller runs, removes LV finalizer
LV controller runs & re-adds finalizer
Node controller deletes the LV
Node controller removes node finalizer deletes the node

The fix then might be to delete the LV before removing the finalizer in the controller? The LV controller guards around DeletionTimestamp being nil, so that should work?
Or am I completely misunderstanding what's happening here?

So even if topolvm-node isn't running then this code should be removing the finalizer on the LV and allowing the deletion - maybe something is wrong there?

That seems to be correct. I'm sorry that I misunderstood the spec of node finalizer deletion.
I found the following PR. In this PR, those LogicalVolume deletion codes have been added probably to delete stale LogicalVolumes.
https://github.com/topolvm/topolvm/pull/230

Looking at the node_controller logs from around the time of a delete that orphaned an LV, the only log line I see is deleted LogicalVolume. The LV didn't get deleted but it looks like it at least tried - but the finalizer was left on it, which implies there's something wrong with the remove-finalizer code in cleanupLogicalVolumes? Or maybe it was recreated by something?

Due to cleanupLogicalVolumes, LogicalVolumes cannot be left after the node is deleted...
As for the recreation of the LogicalVolumes, I think it does not occur because the LogicalVolume is created when the PVC is created.
(There might be some bugs...)

One last thing I noticed - it looks like that controller should also log when it deletes the PVC, and it didn't, so maybe that was cleaned up elsewhere? I don't know if that's a problem at all

If you did not delete PVCs that are provisioned by TopoLVM on the deleted node manually, that sounds strange...
Are there any stale PVCs still remaining?
I'm afraind it is time to finish my work today. I'll see your newest comment next Monday morning.
https://github.com/topolvm/topolvm/issues/715#issuecomment-1625156200
Thank you for all of your effort!

Are there any stale PVCs still remaining?

Nope, they're all cleaned up
I feel like I've hit upon the cause in my latest comment but you'll know more than me. If the LV controller is re-adding the finalizer after deletion due to a race-condition then that would explain things I think
Anyway, thanks for your help. Have a good weekend!

I investigated the code and did some experiments.
As a result, I succeeded in reproducing the "failed to add finalizer."
Now I think what you said in https://github.com/topolvm/topolvm/issues/715#issuecomment-1625156200 is correct.
I will discuss with other maintainers how to fix this issue.
IMO, your idea seems to be good.

The fix then might be to delete the LV before removing the finalizer in the controller? The LV controller guards around DeletionTimestamp being nil, so that should work?

I discussed this with other maintainers, and it turned out that there are several options about how to fix this issue.
(Adding finalizer to LogicalVolume when it is created instead of adding it in topolvm-node's LogicalVolumeReconciler, or letting topolvm-controller remove stale LogicalVolume periodically etc.)
Though I will continue to consider it, I may de-prioritize it because this is not a critical bug like data corruption.

Thanks for the update
While I agree this isn't as critical as a data-corruption bug, I would argue that it should still be fairly high-priority.
As these orphaned volumes get more numerous (which can happen over a period of months or even years) the topolvm-controller spends more and more time trying to delete them, which means it can spend less time provisioning new volumes.
Thus this eventually turns into a denial-of-service bug, where provisioning new volumes can take many hours to complete - if at all - and so the workloads that depend on them can't start running.  This situation can kill an entire cluster if a number of nodes get recycled in quick succession (eg rolling restart, or simple spot terminations).
Regarding the fix, I'd imagine this needs two approaches:

A way to stop this happening going forward (fix the race - by moving where the finalizer is added, or changing the order of the deletion)
A way to clean up these volumes from existing clusters upon upgrade of topolvm (periodic cleanup of stale LVs)

If an approach can be agreed for these then I'd be happy to try to put a PR together with a fix

While I agree this isn't as critical as a data-corruption bug, I would argue that it should still be fairly high-priority.

O.K.

If an approach can be agreed for these then I'd be happy to try to put a PR together with a fix

Thanks. It will help us a lot if you could create a PR.
Now I'm discussing this with other maintainers again, so please wait for a while.
(We are talking about another approach to prevent the race condition.)

Now I'm discussing this with other maintainers again, so please wait for a while.
(We are talking about another approach to prevent the race condition.)

As a result, now we think the following spec is good.

topolvm-controller spec

When the node is deleted and topolvm-controller tries to delete the finalizer on LogicalVolumes, topolvm-controller simultaneously adds an annotation to the LogicalVolume which indicates that the node related to the LogicalVolume is being deleted.
cf. https://github.com/topolvm/topolvm/blob/main/controllers/node_controller.go#L146-L152

topolvm-node spec

If the LogicalVolume has the annotation, do nothing. Just leave it to topolvm-controller.
cf. https://github.com/topolvm/topolvm/blob/main/controllers/logicalvolume_controller.go#L47

Could you create a PR with this spec?

A way to clean up these volumes from existing clusters upon upgrade of topolvm (periodic cleanup of stale LVs)

Though I understand this is reasonable for some scenarios, this cleanup procedure is not used unless some bugs exist. To keep the code base simple, I would not like to implement it at least for now.

Thanks @peng225 . I've opened https://github.com/topolvm/topolvm/pull/723 which I believe implements your spec


Setting cardEnabled to false breaks the dropin ui.

Setting cardEnabled to false causes the both the credit card AND the selected payment method to be hidden. Leaving only the text "Select Payment Method" in the bottom sheet.
Example:

                            final request = BraintreeDropInRequest(
                              cardEnabled: false,
                              clientToken:
                                  paymentMethodState.braintreeToken,
                              paypalRequest: BraintreePayPalRequest(
                                amount: '0.01',
                                currencyCode: 'USD',
                                payPalPaymentUserAction:
                                    PayPalPaymentUserAction.commit,
                              ),
                            );
                            final result =
                                await BraintreeDropIn.start(request);

hey did you find the solution to this? I also need to hide the cardEnable option hide


Uninstall instructions are available

This will link to the doc created in https://github.com/getappmap/applandinc.github.io/issues/1075

@brikelly getting rid of appmap completely is a nightmare, extention uninstall from vscode won't cut it at all... the link above is not there anymore. I have looked in all the extension files I could find, but my projects are still complaining about it.
Please give some pointers where to look for appmap extension references..

@cyberjunky uninstall docs are available here: https://appmap.io/docs/reference/uninstalling-appmap.html
Tagging @dustinbyrne @apotterri @kgilpin for visibility.

That document doesn't explain, how to properly undo all other modifications to the user account. Such as $HOME/.appmap directory. Such as some process that recreates appmap.log even after the extension was uninstalled.

@azazar Thanks for the report.  We'll work on updating the documents to include this newer folder that AppMap uses for storing things like downloaded CLI binaries, jar files, and local Navie chat history.

We've shipped the uninstall documentation here: https://appmap.io/docs/reference/uninstalling-appmap.html


Revert "chore(deps): update dependency io_bazel_stardoc to v0.5.6"

Reverts aspect-build/bazel-lib#441

We can let renovate try again :)


Add Sign-In/Sign-Up Functionality with Menu and Database Integration

Title: Add Sign-In/Sign-Up Functionality with Menu and Database Integration
Issue No. : #859
Code Stack : JavaScript, HTML, CSS, Firebase
Close #859
Checklist:

[X] I have mentioned the issue number in my Pull Request.
[X] I have commented my code, particularly in hard-to-understand areas.
[X] I have created a helpful and easy to understand README.md.
[X] I have gone through the contributing.md file before contributing.

Additional context (Mandatory )
This pull request introduces comprehensive authentication functionality including sign-in, sign-up, and menu updates based on user authentication state. It also integrates user data storage and retrieval with Firebase Firestore.
Are you contributing under any Open-source programme?

[ ] I'm a GSSOC'24 contributor
[X] I'm a SSOC'24 contributor

Changes Made:

Sign-Up Functionality:

Added signup.js to handle user registration.
Created a form for user registration with email, password, and Google sign-up options.
Stored additional user information (name, username) in Firestore.

Sign-In Functionality:

Added signin.js for user login with email/password and Google sign-in options.
Implemented session persistence for user authentication.

Menu Updates:

Updated index.html to show/hide menu items based on user authentication state.
Added a dropdown menu for the profile with options to edit profile and sign out.
Implemented main.js to handle dynamic display of menu items based on authentication.

Database Integration:

Utilized Firebase Firestore to store and retrieve user data.
Ensured user data is correctly fetched and displayed in the profile dropdown.

CSS Styling:

Styled the dropdown menu for the profile.
Ensured consistent styling across sign-in/sign-up forms and the dropdown menu.

Summary of Changes:

Added signup.js and signin.js for handling user registration and login.
Integrated Firebase Authentication and Firestore for user management.
Updated index.html to dynamically display menu options based on authentication state.
Styled the profile dropdown menu.
Implemented session persistence for user authentication.

Testing:

Tested sign-up and sign-in functionalities with both email/password and Google sign-in.
Verified session persistence and user state across different pages.
Ensured the profile dropdown menu is displayed correctly for authenticated users.

Notes:

Make sure to configure your Firebase project and update firebaseConfig.js with your project details.
Additional CSS adjustments may be needed to match your overall site design.

Hi @apu52 the changes I have made are currently on my forked repository. If you approve the pull request, they can be merged into the main repository and subsequently deployed.

Here is the video of sign up/sign in function:
https://github.com/apu52/METAVERSE/assets/64575332/c2a818a8-75e4-4977-ac8b-18935800ff3e

Hi @apu52 the changes I have made are currently on my forked repository. If you approve the pull request, they can be merged into the main repository and subsequently deployed.

Ok Let me Clear . I can see what are your changes through the Deployed link available in the PR (https://deploy-preview-869--cute-quokka-b093d8.netlify.app/) . Here u can see in the book review page it's showing the link is broken . So I am requesting u to look into this matter. Otherwise although I will merge your PR , no changes will be shown in the main website
Otherwise the changes u have made are really great . Just look into this matter

@apu52 I have made the changes. Now the page can be seen in the preview. Just a note that I am not uploading my firebase config secrets that is why this will not perform the same as in video. Please let me know if you can provide these or the PR can be merged without my configs.

@apu52 I have made the changes. Now the page can be seen in the preview. Just a note that I am not uploading my firebase config secrets that is why this will not perform the same as in video. Please let me know if you can provide these or the PR can be merged without my configs.

@gayatri-p786 yes.I understand . there is no need to share your config . Later on I will work on it. For now I am merging your PR under SSOC


New Feature

I thought of a new feature this Remodal plugin should have. It should have the option to close the modal after a certain time of X seconds (of course, it probably will be measured in milliseconds).

Hm. Why not? I've labeled it.

Why not?
1./ bigger codebase
2./ bad ux practice: let the user control the experience. Do you really want to let people create modals that cannot be closed for X seconds?  Let's not make it worse.
3./ It's easy enough to do when you really need it.
If argument 2 does not convince you, please consider argument 1 and 3.


docs(README): clarify examples/ rely on 0.12

A warning in the README—at least until 0.12 is released—might alleviate some confusion (e.g., #1522).

Thanks for the PR! I wonder, does the added text clarify much? It might be that I'm biased, but I'm used to example code at a certain commit in a repo to always work with that version of the code, not necessarily what is published.
Maybe there is some value in reminding people of that... What do you think of that message being in examples/README.md directly?

Thanks for the PR! I wonder, does the added text clarify much? It might be that I'm biased, but I'm used to example code at a certain commit in a repo to always work with that version of the code, not necessarily what is published.

That's a fair point.

Maybe there is some value in reminding people of that... What do you think of that message being in examples/README.md directly?

Could be! But if Hyper 0.12 will be released soon—the milestone for 0.12 suggests that the case—then maybe adding the README to examples might be unnecessary. Either way, I'll update the PR (or open a new one...) to add the README to the examples directory.

Ah, didn't see https://github.com/hyperium/hyper/commit/2415ce96e198bafc107c38e53a7bbacc2d361dbf. Closing this PR as it's handled.


(maint) Fix integration test

Previously the test helper was appending to the cmd_options object, which ended
up with double the parameters if it was called twice.  This commit creates a
copy of the array first, before modifying it.

Self merging.


Fixing main branch build: Update README.md

Can we have a release?

There will be a new major release once #157 is merged


It's too durty

Too many **

Hi Isamu,
Before I merge these pull requests, please sign the Mendix Contributors Agreement here:
https://www.clahub.com/agreements/mendix/docs
Thanks!
-Adam


Fix setting particle size

Summary
Setting the size of the particles after the particle emitter is created had no effect. The solution is to destroy and recreate the particle system with the new size.
I also updated the code so that the ParticleEmitter class does not create all different types of particle emitters (e.g. point, box, ellipsoid, etc) when it's initialized. When the user changes the emitter type, we'll destroy the existing emitter and create a new one with the specified type.
Note: my original intention was to have a flag to mark the emitter as dirty when the above params changed and let PreRender() handle the recreation of the emitter. However it was found that overriding PreRender() broke ABI so I worked around it with a manual PreRenderImpl call
Checklist

[x] Signed all commits for DCO
[ ] Added tests
[ ] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[ ] codecheck passed (See
contributing)
[ ] All tests passed (See
test coverage)
[ ] While waiting for a review on your PR, please help review
another open pull request
to support the maintainers

Note to maintainers: Remember to use Squash-Merge

I went ahead and addressed some of my feedback in https://github.com/ignitionrobotics/ign-rendering/pull/241/commits/a19125e60dafbc01f48f882465cda6b3b5615919.
I wanted to follow up about my previous comment regarding tests. So, it looks like the particle emitter unit test tests the data members that belong to the BaseParticleEmitter class, but what we should really do here is add a test to ensure that the Ogre::ParticleEmitter object in the Ogre2ParticleEmitter class is being updated correctly whenever an emitter is re-created due to a type or particle size change. Is it possible to test the validity of this data member somehow, or is it impossible since this data member belongs to Ogre2ParticleEmitterPrivate?

Is it possible to test the validity of this data member somehow, or is it impossible since this data member belongs to Ogre2ParticleEmitterPrivate?

I'm trying to keep the tests generic so we can run them for different rendering engines. The other option is an integration test to test before and after changing type or particles, e.g. if you have a point particle emitter with a duration or 1 sec and then you change it to a box emitter, you should see the particles more spread out while only being enabled for 1 sec as well.

I'm trying to keep the tests generic so we can run them for different rendering engines.

Good point, I didn't think about that :+1:

The other option is an integration test to test before and after changing type or particles, e.g. if you have a point particle emitter with a duration or 1 sec and then you change it to a box emitter, you should see the particles more spread out while only being enabled for 1 sec as well.

That's not a bad idea. The only thing to consider with an integration test like this is that we should try to test all of the emitter properties, not just duration (particle size, velocity, scale rate, etc.), which I think would be very difficult to test. So, we can either write an integration test that checks for some of these things, or just leave everything as-is (i.e., just keep the unit test). I'm not sure what would be better.

I'm leaning towards keeping the test as is given the amount of effort needed and time to get other particle effects changes in. Let's revisit this in the future. I've ticked an issue: https://github.com/ignitionrobotics/ign-rendering/issues/249

Most of this looks good to me, but before merging, @iche033 can you take a look at my feedback/review comments above and changes I made in https://github.com/ignitionrobotics/ign-rendering/pull/241/commits/a19125e60dafbc01f48f882465cda6b3b5615919? In particular, I'd like to get your confirmation about this change. If all the changes look good to you, then I am okay with approving and merging this.

If all the changes look good to you, then I am okay with approving and merging this.

the changes look good, thanks!


fix istioctl authz check for ingressgateway

#23526
The command can just check all the filter chains instead of restricting to the "virtualInbound" which doesn't exist for ingress gateway.
Please provide a description for what this PR is for.
And to help us figure out who should review this PR, please
put an X in all the areas that this PR affects.
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[x] Security
[ ] Test and Release
[x] User Experience
[ ] Developer Infrastructure
Pull Request Attributes
Please check any characteristics that apply to this pull request.
[x] Does not have any changes that may affect Istio users.

@yangminzhu: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
466386f09db39ced25ebbd4f9c8fae0fac44cda4
link
/test release-notes_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@yangminzhu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
466386f09db39ced25ebbd4f9c8fae0fac44cda4
link
/test release-notes_istio

gencheck_istio
466386f09db39ced25ebbd4f9c8fae0fac44cda4
link
/test gencheck_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@yangminzhu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
466386f09db39ced25ebbd4f9c8fae0fac44cda4
link
/test release-notes_istio

gencheck_istio
466386f09db39ced25ebbd4f9c8fae0fac44cda4
link
/test gencheck_istio

lint_istio
466386f09db39ced25ebbd4f9c8fae0fac44cda4
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@yangminzhu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

gencheck_istio
466386f09db39ced25ebbd4f9c8fae0fac44cda4
link
/test gencheck_istio

lint_istio
466386f09db39ced25ebbd4f9c8fae0fac44cda4
link
/test lint_istio

release-notes_istio
6f6d4c162f9ba5d1143021b07a6e8feca77333ae
link
/test release-notes_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@yangminzhu: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
96a7f4151fb4364077174ef69a58a2ab590136ad
link
/test release-notes_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@yangminzhu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
96a7f4151fb4364077174ef69a58a2ab590136ad
link
/test release-notes_istio

gencheck_istio
96a7f4151fb4364077174ef69a58a2ab590136ad
link
/test gencheck_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@yangminzhu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
96a7f4151fb4364077174ef69a58a2ab590136ad
link
/test release-notes_istio

gencheck_istio
96a7f4151fb4364077174ef69a58a2ab590136ad
link
/test gencheck_istio

integ-pilot-k8s-tests_istio
96a7f4151fb4364077174ef69a58a2ab590136ad
link
/test integ-pilot-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@yangminzhu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

gencheck_istio
96a7f4151fb4364077174ef69a58a2ab590136ad
link
/test gencheck_istio

integ-pilot-k8s-tests_istio
96a7f4151fb4364077174ef69a58a2ab590136ad
link
/test integ-pilot-k8s-tests_istio

release-notes_istio
b05060050edbc0f3846abe2d1c0a3bb50ef76be8
link
/test release-notes_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

This looks good to me.
Can you add a comment showing what the output looks like now, and how it looks different with this PR?

the output is not changed at all, it's the exact same as before. This PR just make it also work on gateways.

@istio/wg-networking-maintainers @istio/wg-test-and-release-maintainers ping


Post Tags

Create a index page that shows posts related to tags.

Not adding another generator, this will become as problematic as categories as the pagination functions the same way.  I'd rather not employ manual creation on tags so i'm just not going to add them. except as notations on posts and not links.


docs(oidctrusteddomains): Add note about configuring wildcards for trusteddomains

Add note about configuring wildcards for oidctrusteddomains.js and caution against using them.

minor linting to the readme.

Should resolve #865

Thank you again  @jafin .
It can also be a real warning in logs. if only "*" pattern is set.

Good point, I missed that entirely and assumed regex was only way to do this, should of read the code.. Will put up another PR.


CAP THINGS MY DUDE

Home Page
CAP - about.
CAP - minecraft stuff.
CAP - other stuff.
CAP - discord.
About Page
CAP - about
CAP - hey! CAP - i’m CAP - beatso. CAP - i make CAP - minecraft resource packs, amongst other stuff. CAP - i also do a bit of code.
CAP - i like CAP - minecraft. CAP - i do a bunch of things to do with (you could add within here, to stop continuous use of "do") the game.
CAP - i’ve made a custom resource pack picker for CAP - minecraft, which i coded from scratch. CAP - i also made textures for it, along with CAP - daggsy and CAP - kemiu.
CAP - i am part of the CAP - fingermaps map making team, and the website team at CAP - vanilla CAP - extract. CAP - check out all the CAP - minecraft stuff CAP - i do.
CAP - i am also a keen programmer. CAP - i made a few useless websites, some discord bots and other bits and pieces. CAP - check it out.
CAP - i have my own discord server, a community with over 100 members. CAP - come join and hang out :) (you could replace with an emoji or something, the prentices don't align with the Colon)
Minecraft stuff Page
CAP - minecraft stuff
CAP - a collection of minecraft things i made. CAP - other stuff
CAP - little improvements: custom
CAP - little improvements: custom is an open-source resource pack picker that i coded from scratch. CAP - there is a team of three texture artists (CAP - kemiu, CAP - daggsy and myself) who make textures and resource packs for lic. CAP - website
CAP - resource packs
CAP - i make a bunch of tweaks resource packs, that aim to improve the vanilla game in small ways. CAP - these include:
CAP - little improvements: variated, which adds alternate textures to many blocks; adding variety to the game, and avoiding grid patterns.
CAP - little improvements: redstone which is a utility pack that adds small quality of life additions to redstone components.
CAP - connected smooth stone, which, uhh, makes smooth stone connected.
CAP - all my resource packs can be found on my CAP - planet CAP - minecraft profile.
CAP - resource pack info
CAP - resource pack info is a small wiki for bits of info that can be useful when creating a minecraft resource pack. CAP - it’s mostly stuff that i didn’t find was immediately obvious when searching the web. CAP - website
CAP - simple auto clicker
CAP - simple auto clicker is a small program CAP - i made that has options to left clikc (YOU SPELLED CLICK WRONG) at different speeds for mob grinders, written in ahk. pmc
CAP - fingermaps
CAP - i am the website and bot developer for the CAP - fingermaps team, a map making team that currently has two maps published. CAP - we aim to create unique and interesting maps using custom data packs, mechanics, resource packs and other stuff. CAP - website
CAP - vanilla CAP - extract
CAP - i’m also part of the team at CAP - vanilla CAP - extract, which is another CAP - minecraft resource pack picker. CAP - i made the discord bot, CAP - i (you might wanna remove this "I") help out with the website, and CAP - i (same here) am part of the rp support team. CAP - website
Other stuff Page
CAP - other stuff
CAP - i make pretty useless stuff. CAP - don’t take them too seriously. CAP - minecraft stuff
CAP - trumptimer
CAP - a simple timer to count down until president trump leaves office. CAP - website
CAP - redditspyglass
CAP - a small website to see how many points a reddit post has, even if it’s hidden. CAP - website
CAP - translate nonsense
CAP - a python program to translate text through many languages so it becomes nonsense. CAP - github
CAP - pinn
CAP - a discord bot so anyone can pin messages, even if they don’t have the manage messages permission. top.gg
CAP - custom discord bots
CAP - i make a bunch of discord bots in discord.js. CAP - they’re all on my github profile.
Bottom Header
CAP - home · CAP - about · CAP - minecraft stuff · CAP - other stuff · CAP - discord
CAP - beatso

I don't care if it doesn't fit with ur theme I will keep commenting on this until you do it!

Also it'd be a lot cooler to have the links go onto another tab

So people can go back at any time to admire your grammar skills

Good.


UI Performance July

Objective
Improve UI performance of editing a property in the property pane.

Codemirror binding based property updates

Success Metrics

Goal
Goal Metric
Current Metric

Minimise UI thread blockage when changing a property of a widget
300-500ms delay between two character changes
1500 ms delay between two character changes

Requirements

Requirement
User Story
Importance
Notes

Smooth typing experience for property update
User should be able to edit any property on a property pane without noticeable UI freeze. The UI should not jitter while typing code inside the property pane
High
Slowdown 4x CPU for testing

Benchmark system specs

Browser: Chrome
Browser Settings: Regular, without throttle.

Demo of how the typing experience will be like: https://satishgandham.com/input-delay-glitch/

@SatishGandham can you close this, We something here belongs to the aug plan then lets take it out of here


Client-side component events break input focus

Discussed in https://github.com/reactive-python/reactpy/discussions/1187

Originally posted by williamneto January 13, 2024
So, while developing reactpy-material i faced a problem that might be related to the reactpy architecture for custom components.
To showcase the problem i created this small component, just a normal textfield. The problem is when attaching a on_change event to this custom component, the event on the page doesn't behavior as expected. Each time you type in the field (and trigger the onChange event) the page focus is moved out of the input element.
So, a simple custom TextField like that
import React from "react";
import ReactDOM from "react-dom";
import htm from "htm";

const html = htm.bind(React.createElement);

export function bind(node, config) {
  return {
    create: (type, props, children) => React.createElement(type, props, ...children),
    render: (element) => ReactDOM.render(element, node),
    unmount: () => ReactDOM.unmountComponentAtNode(node),
  }
}

export function TextField(attrs) {
  return html`
    <div>
      <input type="text" ...${attrs}>
    </div>`;
}

from pathlib import Path
from typing import Any
from reactpy.web.module import export, module_from_file
from reactpy import component

_js_module = module_from_file(
    "reactpy-events-problem",
    file=Path(__file__).parents[0] / "bundle.js"
)

new_text_field = export(_js_module, "TextField")

@component
def text_field(attrs: Any ={}):
    return new_text_field(attrs)

And when you try to use it like that
from reactpy import component, run, html, use_state
from reactpy_events_problem import text_field

@component
def app():
    text, set_text = use_state("Text")

    return html.div(
        html.h1(text),
        text_field(
            attrs={
                "value": text,
                "onChange": lambda e: set_text(e["target"]["value"])
            }
        )
    )

run(app)

You end up with this weird behavior at the page focus, making type in this field very unpratical

Relevant code is here. What's probably happening is that the element is getting recreated.
With that said, despite the fact that render() on the custom component is always called, subsequent calls to ReactDOM.render on the same element should trigger an update rather than a render from scratch.
One possible cause is that the element React is mounting to is changing for some reason.

On a separate note, we might want to add a method to custom components (perhaps mount()) that's called exactly once when the custom component is first rendered to a given DOM element. This would match up with the new createRoot(...).render() workflow in ReactJS 18.

@rmorshea this might actually be related to something else I've noticed recently. I think the last set of changes we did to layout.py is causing every component to be recreated every time.

I have confirmed this same exact behavior using a custom FormControl component from react-boostrap. I have also noticed what is likely the same root issue in a less annoying case using a custom Map component from pigeon-maps. In this latter case, the map flickers every time a change is triggered as if the image tiles are being re-rendered every time. This issue is a big deal based on what I hope to accomplish with reactpy and reactpy-django. So much so that I'd love to be part of the solution. I'm going to take a stab at detangling this, but this still all feels very black-boxy to me. Let me know if anyone else has made progress here before I waste too much time. Thanks!

I don't believe anyone has had time to untangle this issue yet, so feel free to take a stab at it!

FYI @williamneto
This issue has been resolved, which should fix the controlled inputs problems you've seen with reactpy-material.


Why Image compression increases size of image?

I am trying to compress the PNG image using imagemin and  imagemin-pngquant, after applying the transformation with different quality level, getting different sizes of image
See for quality between 0, 1 => 1848433. and for quality between  0, 0.8 => 2051244. for lower quality image size is greater than the higher quality.
e.g
input size 1677003 bytes
quality: [0, 0.1] => 1227453
quality: [0, 0.5] => 1662248
quality: [0, 0.7] => 1886730
quality: [0, 0.8] => 2051244
quality: [0, 0.9] => 2018915
quality: [0, 0.95] => 1995294
quality: [0, 1] => 1848433
Sample code:
let res = await imagemin.buffer(buffer, {                     plugins: [                         imageminPngquant({                             quality: [0, 1],                         }),                     ],                 });
Sample image:

got the same problem. cannot understand the 'quality' variable.


Add lilith to container registery

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is.
would like to have this added to a container registry for easy docker deployment
Describe the solution you'd like A clear and concise description of what you want to happen.
added to github container registry or docker hub.

Hey! Sure, we could do that, i might start working on that later today, will close this issue once it's done.

Waiting for review #24


Add automatic database configuration and Docker Desktop compatibility

Adding automatic database configuration for dev installation and make Alpha, Beta, RC and dev available for WSC_VERSION.

Thank you!


fix: styled should work properly for regular components again

Fixes https://github.com/uber-web/baseui/issues/184

released as https://github.com/uber-web/baseui/releases/tag/v1.3.1


Complete Testsuite

unit test core and utility modules
rather complex pytest runs and combinations of models
comparison tests to sklearn wherever possible

Tests are passing 💯
406651e9acc4b899ebe76e5c50319151efe9b25c


Set simulation configuration

It would be useful to have a way to get and set the simulation configuration using the aerie-cli. An example use case would be set up the config and then run a simulation, then set a new config and run a simulation, in order to do automated testing of difference scenarios.

Looks like this already exists in aerie-cli plans create-config


Shielding can get stuck; SendTToZ / SendZToT is waiting...

Sometimes (mostly with hush coin) shielding coins gets stuck and shows SendTToZ / SendZToT is waiting... messages when there actually is no pending z_sendmany operations. This can lead to pending blocks never paying and confirmations just keep counting up...
It requires restarting z-nomp to clear the internal opidCount variable to resume normal pool operations.

It was discovered this problem can occur when paymentInterval is set too low in your pool_config.
Short paymentInterval can result in overloading the RPC work queue leading to paymentProcessor problems. It is recommended to have a paymentInterval no less than 3 minutes.

utACK

PaymentInterval is bases on secs right? so it needs more than 180 right?

PaymentInterval is in seconds, walletInterval is in minutes

if you're pushing tons of blocks every few minutes, it's best to delay payments to once every 30 minutes or so. Maybe even twice a day

In my config payment interval set to 180, the problem with zen presist


Data collection time

Hi HuYong,
This is a GREAT dataset and thank you all for the working!
I am wondering when did the team collect the entire dataset, as we have concerns on the censorship may affect the validity of the data.
Thanks,

非常感谢提供内容丰富、数据翔实的微博数据库！我在导入sql-2014（express版本） 提示找不到行分隔符，而且中文字符为乱码？尝试用access也遇到同样的错误提示？请问如何解决，谢谢！

@wyiq More detail you can refer our paper, https://arxiv.org/abs/2005.09174

@knightc2020  中文字符的编码为utf-8编码，请确定是数据库的编码也是正确的

@nghuyong Thank you Hu Yong. But my question is quite different. Did the team collect the data in between December 1, 2019 and April 30, 2020 or at once after April 30, 2020? This question is critical as if the data is collected after April 30 -- some tweets posted on i.e. Feb. 13 might be censored in March. Whereas if the data collection process is enforced synchronically -- we may see those tweets in your dataset.  The paper did not articulate this question clearly.
Thank,

@wyiq
the filed crawl_time in each data, is the timestamp when we collect that data.

@wyiq
We collect data between 1, Dec,2019 and 20,April,2020 at 25,April,2020 to 28,April,2020
and data between 21,April,2020 and 30,April,2020 at 1,May,2020 to 4,May,2020

非常感谢对数据的分享！想请问一下就是数据集里面所爬取的“微博ID”为什么不是用户的微博名称呢？

@duoremi7 对，微博id是推文的唯一标示，不涉及用户的id，所以数据集不包含任何用户信息，脱敏使用


Create a company blooper 1

As a signed in user
When I navigate to the company tab
And I enter information into the fields and save
And I upload a company image
Then press save
I get a 'forbidden' error then
When I navigate back
I loose all the app information except the header and footer.

And when I sign out then in I can see my company

Then when I click on the company I see

Closing this issue as it is probably obsolete now.


websocket async write will cause data to be written incorrectly

here is the code , i use a queue to buffer write operation , and write it to websocket sequential, but this impl will cause payload changed on transmitting ,  and i found the changed part is exactly 8-bytes

#include <boost/asio/connect.hpp>
#include <boost/asio/ip/tcp.hpp>
#include <boost/beast/core.hpp>
#include <boost/beast/websocket.hpp>
#include <cstdlib>
#include <fstream>
#include <iostream>
#include <memory>
#include <mutex>
#include <queue>
#include <string>
#include <unordered_map>

namespace beast = boost::beast;
namespace http = beast::http;
namespace websocket = beast::websocket;
namespace net = boost::asio;
using tcp = boost::asio::ip::tcp;

std::unordered_map<uint64_t, std::shared_ptr<tcp::socket>> sessionIdToSocketMap;

class Session : public std::enable_shared_from_this<Session> {
   private:
    websocket::stream<tcp::socket> ws_;
    net::io_context& ioc_;
    std::queue<beast::flat_buffer> ws_write_buffer_;
    std::queue<std::pair<uint64_t, std::shared_ptr<beast::flat_buffer>>>
        tcp_write_buffer_;

   private:
    bool writing_to_ws_ = false;

    void create_conn(uint64_t session_id) {
        auto socket = std::make_shared<tcp::socket>(ioc_);
        socket->connect(
            tcp::endpoint(net::ip::make_address("<IP_ADDRESS>"), 8000));
        sessionIdToSocketMap[session_id] = socket;

        net::post(this->ioc_,
                  [self = shared_from_this(), session_id, socket]() {
                      self->do_tcp_read(session_id, socket);
                  });
    }

    void do_ws_write() {
        if (writing_to_ws_ || ws_write_buffer_.empty()) {
            return;
        }
        writing_to_ws_ = true;
        beast::flat_buffer buffer = ws_write_buffer_.front();
        ws_.binary(true);
        ws_.async_write(
            buffer.data(), [this, buffer](boost::system::error_code ec,
                                          std::size_t size_written) {
                if (!ec) {
                    ws_write_buffer_.pop();
                    std::printf("%ld size written\n", size_written);
                    writing_to_ws_ = false;
                    if (!ws_write_buffer_.empty()) {
                        net::post(this->ioc_, [this]() { do_ws_write(); });
                    }
                } else {
                    std::cout << "❌ write websocket failed:" << ec.message()
                              << std::endl;
                }
            });
    }

    void do_tcp_read(uint64_t sessionId, std::shared_ptr<tcp::socket> socket) {
        auto buffer = std::make_shared<beast::flat_buffer>();
        socket->async_read_some(
            buffer->prepare(8192),
            [self = shared_from_this(), sessionId, buffer, socket](
                boost::system::error_code ec, std::size_t bytes_read) {
                if (!ec) {
                    buffer->commit(bytes_read);
                    std::printf("session id %llu , %lu bytes read\n", sessionId,
                                bytes_read);
                    uint64_t big_endian_session_id = htonll(sessionId);
                    beast::flat_buffer flat_buffer;
                    flat_buffer.reserve(8 + bytes_read);
                    flat_buffer.commit(net::buffer_copy(
                        flat_buffer.prepare(8),
                        net::buffer(&big_endian_session_id, sizeof(uint64_t))));
                    flat_buffer.commit(
                        net::buffer_copy(flat_buffer.prepare(bytes_read),
                                         buffer->data(), bytes_read));

                    self->ws_write_buffer_.push(std::move(flat_buffer));
                    self->do_ws_write();

                    // ❗ turn off the comments to enable sync write (this version is no problem)
                   // self->ws_.binary(true);
                   // self->ws_.write(flat_buffer.data());

                    net::post(self->ioc_, [self, sessionId, socket]() {
                        self->do_tcp_read(sessionId, socket);
                    });
                } else {
                    sessionIdToSocketMap.erase(sessionId);
                    socket->close();
                    std::cout << "❌ read tcp failed:" << ec.message()
                              << std::endl;
                }
            });
    }

    void do_tcp_write() {
        if (tcp_write_buffer_.empty())
            return;

        auto [session_id, buffer] = tcp_write_buffer_.front();
        auto socket = sessionIdToSocketMap[session_id];

        net::async_write(
            *socket, buffer->data(),
            [self = shared_from_this()](boost::system::error_code write_ec,
                                        std::size_t bytes_written) {
                if (write_ec) {
                    std::cerr << "❌ Async write error to TCP socket: "
                              << write_ec.message() << "\n";
                    return;
                }

                self->tcp_write_buffer_.pop();
                if (!self->tcp_write_buffer_.empty()) {
                    net::post(self->ioc_, [self]() { self->do_tcp_write(); });
                }
            });
    }

    void do_ws_read() {
        auto buffer = std::make_shared<beast::flat_buffer>();
        ws_.got_binary();
        ws_.async_read(
            *buffer, [self = shared_from_this(), buffer](
                         beast::error_code ec, std::size_t bytes_transferred) {
                if (ec) {
                    std::cerr << "❌ Read error: " << ec.message() << "\n";
                    return;
                }

                const char* buf_ptr =
                    boost::asio::buffer_cast<const char*>(buffer->data());

                uint64_t session_id = 0;
                std::memcpy(&session_id, buf_ptr, 8);

                session_id = ntohll(session_id);
                buffer->consume(8);

                if (sessionIdToSocketMap.find(session_id) ==
                    sessionIdToSocketMap.end()) {
                    self->create_conn(session_id);
                }

                auto socket = sessionIdToSocketMap[session_id];
                self->tcp_write_buffer_.emplace(session_id, buffer);
                if (self->tcp_write_buffer_.size() == 1) {
                    self->do_tcp_write();
                }
                net::post(self->ioc_, [self]() { self->do_ws_read(); });
            });
    }

   public:
    explicit Session(net::io_context& ioc) : ws_(ioc), ioc_(ioc) {}

    void start(const std::string& host, const std::string& port) {
        tcp::resolver resolver{ws_.get_executor()};
        auto const results = resolver.resolve(host, port);
        auto ep = net::connect(ws_.next_layer(), results);
        auto target = host + ':' + std::to_string(ep.port());

        ws_.set_option(
            websocket::stream_base::decorator([](websocket::request_type& req) {
                req.set(http::field::user_agent,
                        std::string(BOOST_BEAST_VERSION_STRING) +
                            " websocket-client-coro");
            }));

        ws_.async_handshake(
            target, "/wait-mux-attach",
            [self = shared_from_this()](beast::error_code ec) {
                if (ec) {
                    std::cerr << "❌ Handshake error: " << ec.message() << "\n";
                    return;
                } else {
                    std::cout << "✅ Handshake success\n";
                }
                self->do_ws_read();
            });
    }
};

int main() {
    try {
        std::string host = "localhost";
        auto const port = "1997";

        net::io_context ioc;

        auto session = std::make_shared<Session>(ioc);
        session->start(host, port);

        ioc.run();
    } catch (const std::exception& e) {
        std::cerr << "Exception: " << e.what() << "\n";
    }
}

I believe the problem is that you are making a copy of the buffer on the stack and then trying to initiate the async operation with it. Instead, try using a reference to that element:
beast::flat_buffer& buffer = ws_write_buffer_.front();
ws_.binary(true);
ws_.async_write(....

Side note:
You've used resolve and connect in your code, which are not asynchronous. To make your code fully asynchronous, you might want to use the asynchronous versions of these functions.

I believe the problem is that you are making a copy of the buffer on the stack and then trying to initiate the async operation with it. Instead, try using a reference to that element:
beast::flat_buffer& buffer = ws_write_buffer_.front();
ws_.binary(true);
ws_.async_write(....

Side note: You've used resolve and connect in your code, which are not asynchronous. To make your code fully asynchronous, you might want to use the asynchronous versions of these functions.

thanks!

I believe the problem is that you are making a copy of the buffer on the stack and then trying to initiate the async operation with it. Instead, try using a reference to that element:
beast::flat_buffer& buffer = ws_write_buffer_.front();
ws_.binary(true);
ws_.async_write(....

Side note: You've used resolve and connect in your code, which are not asynchronous. To make your code fully asynchronous, you might want to use the asynchronous versions of these functions.

I found that this function also has data errors. I looked for it according to your idea, but I didn't find the problem. Can you help me take a look? Thanks for your hard work.
    void do_ws_read() {
        auto buffer = std::make_shared<beast::flat_buffer>();

        ws_.async_read(
            *buffer, [self = shared_from_this(), buffer](
                         beast::error_code ec, std::size_t bytes_transferred) {
                if (ec) {
                    std::cerr << "❌ Read error: " << ec.message() << "\n";
                    return;
                }

                const char* buf_ptr =
                    boost::asio::buffer_cast<const char*>(buffer->data());

                uint64_t session_id = 0;
                std::memcpy(&session_id, buf_ptr, 8);

                session_id = ntohll(session_id);
                buffer->consume(8);

                if (sessionIdToSocketMap.find(session_id) ==
                    sessionIdToSocketMap.end()) {
                    self->create_conn(session_id);
                }

                self->tcp_write_buffer_.emplace(session_id, buffer);
                std::printf("buffer content\n%s\n", buffer->data());
                if (!self->writing_tcp_[session_id]) {
                    self->do_tcp_write();
                }
                net::post(self->ioc_, [self]() { self->do_ws_read(); });
            });
    }

Are those HTTP headers part of the message?
Could you check with Wireshark what is the actual message received in your side?

Are those HTTP headers part of the message?
Could you check with Wireshark what is the actual message received in your side?

i already check it in server side, the header is the actually message but the random string not

If the headers are always intact, there is a good possibility that the rest of the message is fine as well. This might be an encrypted message or possibly a Unicode issue. It would be helpful if you verify it by Wireshark.

If the headers are always intact, there is a good possibility that the rest of the message is fine as well. This might be an encrypted message or possibly a Unicode issue. It would be helpful if you verify it by Wireshark.

i already verify it by Wireshark , and payload do not have random string , but the local buffer have

i already verify it by Wireshark , and payload do not have random string , but the local buffer have

Is this what you see in the console? It doesn't look like a random string. By the way, you might want to try using the synchronous versions of the read and write functions if you want to debug more quickly and reduce the potential for bugs.

i already verify it by Wireshark , and payload do not have random string , but the local buffer have

Is this what you see in the console? It doesn't look like a random string. By the way, you might want to try using the synchronous versions of the read and write functions if you want to debug more quickly and reduce the potential for bugs.

sometimes looks like random string ,but this time seems last response content .

@ashtum thanks ashtum, finally,  i find all bugs (some is in the server side)


Just a request :)

Hi! I was wondering if it was possible to have an inverted  faa-falling animation? Going up?
Thanks for your good work in any case!

Done in 0.3.0.

Thanks!


Add link to the CoRL talk

The talk gives a good overview over Carla. Therefore I propose to somewhere link to that talk.

This change is

Thanks for the link! we didn't know it was available :)


Integrated PowerShell Console behaves differently to pwsh with Write-Error

I have created a simple PowerShell script (with .ps1 extension, which GitHub did not like, hence it is .txt) as attached:
OutputDemo.txt
I am running PowerShell Core 6.1.2 on my Mac. If I type pwsh in the Terminal I can then type ./OutputDemo.ps1 and I see the following:
Hello World - Part 1
/Users/xxxxxxxxxx/IdeaProjects/PowerShell/OutputDemo.ps1 : Oh no!
At line:1 char:1
+ ./OutputDemo.ps1
+ ~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,OutputDemo.ps1

Finished

If I open the file with IntelliJ IDEA 2018.3.3 and the "PowerShell v2.0.1" plugin and run the script from there, I see the following:
Hello World - Part 1
Finished
/Users/xxxxxxxxxx/IdeaProjects/PowerShell/OutputDemo.ps1 : Oh no!
+ CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,OutputDemo.ps1

My key issue is that the error output is not being displayed in the same way as the interactive PowerShell console, the lines are all out of order and it is very confusing. Interestingly the error output is also different as the line, char information is not displayed.

The difference appears because we run the script via powershell -File <script file name>, while you likely run your script as a PowerShell command (i.e. just ./file.ps1).
I'll reclassify this as a feature request: let's add a way to run a command instead of a script in a run configuration. This way, it'll be possible to run a script as powershell -c ./myscript.ps1 instead of powershell -file ./myscript.ps1, and you'll get all the ordinary features of the script execution engine.


TestCafe server throws an exception if inIFrame target is not found

By some reason when client raises emptyIFrameArgument error it doesn't set relatedSourceCode property. Server throws an exception in function getStepCode, and hangs until browser is disconnected by heartbeat timeout.

@AndreyBelym is working on this

Thanks!


Drag-and-drop playlists, artists and albums

Extend dragging from tracks to all music-oriented assets. Likely to require a rebuild of the current drag functionality.

Done! Release 2.6.0


Add optional support for HTTP tasks

Description
If the HTTP task has the optional parameter set to true and the task fails, the status will be set to COMPLETED_WITH_ERRORS instead of FAILED allowing the workflow to continue.
See also issue #178
Example use :
  "http_request": {
    "uri": "http://host/path",
    "method": "POST",
    "optional": true,
    "body": {
      "var1": true
    }
  }

@picaron This may not be required.  Have you tried configuring the workflow with workflow task marked as optional?  We have this feature in a pre-release version 1.7.2+.

@v1r3n yes I tried using the latest master but for HTTP task this doesn't work because it does not extend WorkflowTask

Wouldn't it be better to make HTTP task extend the WorflowTask instead?

All the system tasks like HTTP extend from WorkflowSystemTask, which is what HTTP task extends too.
To use the optional flag, you want to set workflow task as option in the workflow definition.  That should do.

Well in my case the HTTP tasks are forked using a FORK_JOIN_DYNAMIC task and putting optional on it didn't work. I also tried putting on the JOIN and still I wasn't getting the desired behavior.
I had to do the changes in this PR to be able to get the desired behavior (see issue #178)

@picaron seems you deleted the branch before the merges are done.  Although setting optional should work, I think this is still a good feature to have.

@v1r3n actually I deleted the branch after you merge a recent PR because my changes were no longer compatible with the latest master, main reason being that the COMPLETED_WITH_ERRORS status was removed.
I would be happy to create a new PR.
Since this status COMPLETED_WITH_ERRORS no longer exists, how do to suggest to implement this?
Should I simply set the HTTP task to COMPLETED or is there another better approach?

@picaron we recently starting implementing a feature where the tasks can be marked as optional.  There are some pending items there (like dynamic fork to support that), but once implemented, it should allow HTTP tasks to ignore failures.  ETA is sometime this week.

ok that's perfect then, I can wait for that, thanks @v1r3n 👍

@v1r3n any updates on supporting optional HTTP tasks?


fix(radarr): SQP-1 (2160p) several updates (v2)

Pull Request
Purpose

Fix: #1614
Fix: #1626
Fix: #1627

#1614
#1626
#1627

Approach

[x] increase bluray-2160p quality size to compensate for uhd tiers.
[x] change maximum quality size for WEB-2160p
[x] remove boost from bcore streaming services and lowered it for SQP-1 to -10000

Open Questions and Pre-Merge TODOs

Requirements

[x] These changes meet the standards for contributing.
[x] I have read the code of conduct.

V2 of #1628 - a prior merge changed every CF json so recreation was easier than reconciling differences.


ABI checker: require explicit @available attributes for new APIs

Before this change, the ABI checker didn't complain about missing @available
attributes on new APIs if the enclosing scopes of new APIs have
availablity information. Instead, we should require explicit @available attributes
for new APIs to prevent them inheriting wrong availability information from a
preexisting scope.
rdar://81719628

@swift-ci please smoke test

@swift-ci please smoke test


Null Object Reference when trying to get back to freeplay after loading song

Describe your bug here.
So, I'm working on a V3 build for Vs. Tailsonic, and I'm trying to transfer all of the tracks and file stuff into the newer (0.6.3) Psych Engine. I eventually came across this error after exiting a track, or finishing it. The track loads properly, but after it exits, the error appears. Here it is:
flixel/system/FlxSound.hx (line 589)
flixel/system/FlxSound.hx (line 727)
flixel/system/FlxSoundGroup.hx (line 52)
flixel/system/frontEnds/SoundFrontEnd.hx (line 327)
flixel/system/frontEnds/SoundFrontEnd.hx (line 319)
flixel/FlxGame.hx (line 618)
flixel/FlxGame.hx (line 729)
flixel/FlxGame.hx (line 682)
flixel/FlxGame.hx (line 556)
openfl/events/EventDispatcher.hx (line 402)
openfl/display/DisplayObject.hx (line 1399)
Uncaught Error: Null Object Reference
Please report this error to the GitHub page: https://github.com/ShadowMario/FNF-PsychEngine

Crash Handler written by: sqirra-rng

Any help would be very much appreciated.
Command Prompt/Terminal logs (if existing)
No response
Are you modding a build from source or with Lua?
Source
What is your build target?
Windows
Did you edit anything in this build? If so, mention or summarize your changes.
Yes, I edited multiple source files.

Here's the link to the V2 build (you must download the new o.secrettailsonicweek file as well, as there will be an invalid chart error): https://gamebanana.com/mods/434218

Fixed it! Apparently the character.json files were missing from the /mods folder.


Migrate travis-ci .org -> .com

It looks like we're using travis-ci.org, and this is becoming legacy as they are moving all repositories to travis-ci.com. Migration is only in beta for public repositories within organisations, but currently, it is not working. Once it's back up and running again it is probably worth migrating to the new one.

Now this has been fixed I have attempted to migrate to travis-ci.com. Going to leave this issue open until confirmed working as intended.

It seems to be! I've just updated the badge URI.


Add a mention that there is a ServiceTag for AzureLoadBalancer

@TimLovellSmith : Thanks for your contribution! The author, @yegu-ms, has been notified to review your proposed change.

@TimLovellSmith Thanks, Tim!
#sign-off


any way to change height and width?

In some cases, default drawing is too big.

I have the same issue !!

me too

same to me. lol

Anyone found any solution to this? Seems like fitted box doesn't suit the purpose very well.

Anyone found any solution to this? Seems like fitted box doesn't suit the purpose very well.


WFCORE-6473 Remove references to obsolete remoting resource.

https://issues.redhat.com/browse/WFCORE-6473
See https://github.com/wildfly/wildfly-core/pull/5643 for context.

Closing for now


Broken Link of Quantum Fourier Transform Chapter on Shors Algorithm Page

Did you find a doc bug or broken link that needs to be fixed?
Yes

What is the file name(s) where you found the bug?
https://qiskit.org/textbook/ch-algorithms/shor.html#3.-Qiskit-Implementation

What is the current text that needs to be fixed or removed?
quantum Fourier transform chapter

Does existing documentation need to be updated with new content?
Yes

New Link to be updated-
https://qiskit.org/textbook/ch-algorithms/quantum-fourier-transform.html or https://qiskit.org/textbook/content/ch-algorithms/quantum-fourier-transform.ipynb

Raised the issue in qiskit-textbook repo
Ref- https://github.com/qiskit-community/qiskit-textbook/issues/548


The functionality to add multiple columns is now there. Feedback wanted

Okay so this could be the final version of the import function but it would be great if you guys could try it out.
The way I understood Emelie during the latest meeting was that even if entries does not have a reference, they should still be put in the queue so that they can be edited from there. I made it so they will have the placeholder value "unspecified". This makes it so they in this state can be submitted (the database will allow it). Maybe the intention was that they should instead get the empty value "" so that the database will give an error message (in this case they would have to be edited before submitting) but to me that does not seem like the best solution. If any entries was accidentally submitted they can be edited after they have been submitted.  It could work if a proper message was given instead of alerting an exception.
If this is the case (meaning that entries can be put in the queue without reference) then some parts of the code can be removed. I wanted to wait with doing this until it has been discussed/tested.
A couple of things to note:

The checkboxes could be replaced with "+" and "-" instead of the standard checkbox layout to make it more clear that the columns are going to be added. There is currently a picture in the "img" folder for the "-" but not for the "+".
It is still required to press the "Reference" button even if it is not mapped to anything. This requirement could be removed.

So please tell me what you think and I'll also talk to Emelie about it. The easiest way is probably to checkout the branch and see how it looks. I have attached the file Emelie gave me for testing. Apparently csv files cannot be attached here so you will have to download this xlsx file and then save it as a csv.
exempel.xlsx
Closes #86

Swweet! Some thoughts on your notes:

If you want some more flair to your checkboxes that's probably fine (and a good idea), but don't use the images: they scale very poorly and browsers render them in varying quality (from ok to bad). Instead, either try something like FontAwesome or find a good SVG icon. (SVG is preferable because it's more idiomatic but they are basically the same solution)
I agree with you on the reference button; it should probably be removed.  I only encountered a line break type problem:

I think there is some overflow-x: hidden or similar styling on the container that causes this, but I'm not 100% sure. It is probably worth looking into a solution that supports multiple line-breaks.

Yeah this looks good to me! :D Nice job man! 💯

One minor suggestion would be that it might be a good idea to have the file name in the modal so the user is confident they selected the right file.

Also it might be a good idea to have a generic error message at the end of the modal beside the upload and cancel buttons. For example if the user has left the 'collection name' or 'description' empty there is error messages beside these but these will be out of view so it will be difficult for the user to realise they have made errors and they might assume the import functionality is not working correctly.

Okay so thank you for the feedback! :)
Basically all the things that you commented on has been implemented. So for this commit the following has been added:

The file name will show at the top of the modal.
There will be an error message next to the upload button at the bottom of the page if anything is not correct.
The adding of more headers now works correctly. If they fill up horizontally, they will will continue filling up vertically.
There are now "+" and "-" icons instead of regular checkboxes when more headers are added (I added them as unicode characters).
Fixes from @smeetz comments on the code.
Other refactorizations that I did.

More comments are welcome if you have any.

Small update: Emelie has tried it out and approved it.


genestack issue #340 trailing newline characters for base64 secret

This commit fixes genestack issue https://github.com/rackerlabs/genestack/issues/340 to remove trailing newline (\n) from the base64 secrets
I have tested the modifications in my lab and the resulting secret.yaml file could be applied and secrets were created without any issue

instead of doing base64 | tr -d '\n', can we just use base64 -w0?

Thanks for the feedback. I have modified the file


Prune error: number of used blobs is larger than number of available blobs!

Output of restic version
restic 0.7.3 (v0.7.3-154-g9ce2a73f)
compiled with go1.9.1 on linux/amd64
How did you run restic exactly?
restic -r sftp://{{ my_backup_server }}//home/backups prune
enter password for repository:
password is correct
counting files in repo
building new index for repo
[0:12] 100.00%  24987 / 24987 packs
repository contains 24987 packs (3691414 blobs) with 111.785 GiB
processed 3691414 blobs: 0 duplicate blobs, 0B duplicate
load all snapshots
find data that is still in use for 41 snapshots
[4:22] 100.00%  41 / 41 snapshots
number of used blobs is larger than number of available blobs!
Please report this error (along with the output of the 'prune' run) at
https://github.com/restic/restic/issues/new
What backend/server/service did you use?
sftp
Expected behavior
prune completes without errors
Actual behavior
prune quit at 100% with the following message:
[4:22] 100.00%  41 / 41 snapshots
number of used blobs is larger than number of available blobs!
Please report this error (along with the output of the 'prune' run) at
https://github.com/restic/restic/issues/new
Steps to reproduce the behavior
re-running prune against my repo
Do you have any idea what may have caused this?
Do you have an idea how to solve the issue?

Thanks for the report! Can you please run restic check --read-data on that repo and report back?

enter password for repository:
password is correct
Create exclusive lock for repository
Load indexes
Check all packs
Check snapshots, trees and blobs
Read all data
[59:19] 100.00%  24987 / 24987 items
duration: 59:19
No errors were found

Hm, that's very odd, we need to debug this together.

We've identified the issue: The repository contained several tree blobs that were also used as contents of files. This isn't detected by the checker, but prune fails for that.

I'm going to close this issue for now, the repo was in an unusual state.
Please leave a commit if you experience this issue so we can reopen it!


JoErNanO: Watch bonazza

JoErNanO requests the watch of the watch_keyword bonazza. See the Metasmoke search here

The metasmoke search has no hits. Can you explain why this should be watched? We have lots of random things on the watchlist but it would still be helpful for future troubleshooting to see a rationale when it's not immediately obvious.

Clarification in chat:
https://chat.stackexchange.com/transcript/message/39865599#39865599

!!/approve


runtime: buildmode=c-archive support on darwin/386

Necessary (and possibly sufficient) condition for complete iOS simulator support. First part: https://go-review.googlesource.com/#/c/12412/

CL 12412 happened. Anything else?


Point to latest version.

@rnburn I've created branch hunter-1.3.0 from the latest v1.3.0 tag:

https://github.com/hunter-packages/opentracing-cpp/tree/hunter-1.3.0

Please send there the patches that we need from branch hunter:

https://github.com/hunter-packages/opentracing-cpp/tree/hunter

Actually do we need anything? I think the 1.3.0 release of this package can be used as is in Hunter, there is no need to maintain fork.


portico: fix broken electron check condition

fixes #11802

@vsvipul thanks for debugging this!  I see that the issue is /apps isn't a page where we run our standard auth decorators, and thus request.client is never set.  I have a better fix in mind, will do that and merge.

sure.. happy to help.. when u merge please point it to the issue so that i can see the fix.

Yep, was just finishing testing it.  Merged as e859ab75453fc7be658fa991982c903f8c8fa0cc, thanks @vsvipul!


wg-runtime Status Update 2020-01-06

Our first status update of the year!
What was accomplished
Lessons learned
What's next

What was accomplished

(internal): finished a new csi dashboards
performed measurements for evaluating a potential approach to protocol adapters.
Renamed strip-prefix to xssi-prefix (pr). Also added support to amp-form and amp-consent (1, 2)
Myriad small fixes:

amp-list race condition: https://github.com/ampproject/amphtml/pull/25964
docs height for amp-list: https://github.com/ampproject/amp.dev/pull/3280
gcc warning: https://github.com/ampproject/amphtml/pull/26086

Took time off and caught up on TV/movies

[x] The Mandalorian: 4/10 first 5 episodes, 9/10 the last three.
[x] Two popes: 6/10
[x] Knives out: 8/10

Lessons learned
What's next

Inlining worker-dom into the amp-script bundle (https://github.com/ampproject/amphtml/pull/26190). Potentially doing this to ww.js as well.
Initializing amp-list from amp-state and protocol adapters.

What was accomplished

Removed element size constraint for mutations in amp-script (#26047)
Started prototyping IntersectionObserver to replace part of resources-impl.js
Remove "canary" perf experiment (#26065)

What's next

Merge initial prototype for IntersectionObserver under runtime experiment

What was accomplished

Much video games
PR for Initial PreactBaseElement: https://github.com/ampproject/amphtml/pull/25969

Lessons learned

Getting closure compiler to include module variants of node_modules is very difficult.

What's next

Finish PreactBaseElement PR


Could not install packages due to an EnvironmentError:  Could not find a suitable TLS CA certificate bundle,

Could not find a suitable TLS CA certificate bundle, invalid path: .heroku/python/lib/python3.7/ensurepip/_bundled/pip-10.0.1-py2.py3-none-any.whl/pip/_vendor/certifi/cacert.pem

@metinjakupi Please could you post the full build log? The error would suggest the build was using a very old (and unsupported) Python 3.7 version, however, such old versions are not available on supported Heroku stacks, so something strange must be going on (is this being run outside of Heroku?).

@edmorley, I've been deploying applications on DigitalOcean's App Platform for the past couple of weeks without any issues. However, starting this week, I've been encountering challenges and can't successfully deploy anymore.
Here is my build log:

Could you assist me in resolving this? Thank you.


Discussion on naming convention of prototype utilities

Poke =>  @tdhartwick, @lgcallahan , @canterberrie , @rafibomb, @kball
My first reactions!
Margin - m-a-0, m-x-0, m-y-0, m-l-0, m-r-o.. etc
Padding - p-a-0, p-x-0, p-y-0, p-l-0, p-r-o... etc
Width - w-25, w-50... and mx-w
Height - h-25, h-50... and mx-h

Awesome!
I think that the a is implied similar to how it's written in CSS, so i'd drop that:
//affects all
margin: 1px;

//affects right
margin-right:1px;

I think that the a is implied similar to how it's written in CSS, so i'd drop that:
Agreed! Let drop it!
Other class to look at which should be modified is this
Separator separator-left =>  sep-left ...
Other classes good for me as classes like display-none, position-static, overflow-scroll follow the foundation convention and i dont think there is any need to change!

https://github.com/zurb/foundation-sites/pull/10017#issuecomment-305882408

@IamManchanda Glad those prototyping classes are finally here! Been wanting official padding & margin classes for a while

Thank you @canterberrie but there are many more. Infact which really excites me actually are not classes but mixins like Relational Mixins

🤔 hmmm that's an interesting one. I think the format that I think of for the classes are abbreviated css rule | modifier (like x,y) | value
Butttt for the .separator-left that's an interesting on since it's not an actual css rule so abbreviations would probably be less understood immediately. I'm thinking if it's not a css rule it should be spelled out?

Referring to @corysimmons https://github.com/zurb/foundation-sites/pull/10017#issuecomment-305896731
I think these helper classes are meant to only work in prototyping. I'm wondering if we'd want to include a linter or alert when watching that would warn people they're using prototyping classes.
Also on npm run build we could convey a more firm message if there are still prototyped classes?

Sure @tdhartwick .... same thoughts ... 100% sir ....
@kball can you help us here in these build messages ??

But these messages should be only for classes.
For mixins, it shouldnt be there!

Agreed!

@tdhartwick so what's the final verdit on separator ... ??
Reason i put it like this is because i have seen sep in some themes for the same or around similar purpose!

I would vote for keeping separator. sep isn't easily guessable even though it's easier to type.

Match syntax to Emmet?
But also, how will .m-7 work? Shouldn't it be something like .m-sm?

m-7 ... sorry but very careful here to not add many classes ... m-0 to m-3 only by default! (but can be customized)

Shouldn't it be something like .m-sm?
I like your idea but
No because we use sm (small) for responsive breakpoints!

Added a PR  #10122

So... I may be an outlier here, as I'm not really the target audience for prototyping classes, but I find these super terse classnames pretty aversive and hard to read.
Can we clarify a little who our target audience is for these?  Are we expecting these to only be used by power users like @tdhartwick? Or is this intended for beginners?

Yes i understand this .... Yup a tough line to walk ... i have added a PR ... happy to get that PR rejected too!

Are we expecting these to only be used by power users like @tdhartwick? Or is this intended for beginners?

Its for both ... power users and beginners!

Hmm... would like some more opinions on this... @lgcallahan, @LaurelBCodin as some of our newer coders at ZURB what do you think?
Also lets tag in folks involved in the original prototype PR and issue... @IllusionPerdu @natewiebe13 @brettsmason @DaSchTour

If people want aliases or even namespacing, they're simple enough to create with preprocessors:

I am liking the sound of this the most.

Hey i am Newbie,
margin-horizontal-0 ... so cool lets use it !
Hey i am Harry/@tdhartwick /@rafibomb  ,
margin-horizontal-0 ... oh its so bad ... so long to type!
Lets correct this up
.m-x-0 {
  @include margin(null, $spacer, null, $spacer);
}

The situation I use these is early in a client project to convey nicer scaffolds quicker. Instead of having to do the correct steps of thinking about naming conventions, creating partials, and loading into _app.scss it's more effective to get stakeholder buy-in early on visually (at least in our workflow at ZURB).
Also maybe I didn't understand the helper classes as far as the values, how does 1-3 work. Like where do those map?
Also, it jogged my memory that we've landed on an interesting approach for managing the grays for projects. We treat them like font weight values, and it's been suuuuper nice.
Something like this:
$gray-100: $off-white;
$gray-200: $lightest-gray;
$gray-300: $light-gray;
$gray-400: $gray;
$gray-500: $dark-gray;
$gray-600: $darkest-gray;

It's fantastic for prototyping. Interested  in hearing your thoughts on this too!

@tdhartwick A lot has been discussed here on this ( #9671 )
Right way is the color pallete instead => #9683

$gray-100: $off-white;
$gray-200: $lightest-gray;
$gray-300: $light-gray;
$gray-400: $gray;
$gray-500: $dark-gray;
$gray-600: $darkest-gray;

See http://sass-lang.com/documentation/Sass/Script/Functions.html#scale_color-instance_method

Also maybe I didn't understand the helper classes as far as the values, how does 1-3 work. Like where do those map?

$prototype-spacers-count: 3 !default;

https://github.com/zurb/foundation-sites/issues/10119#issuecomment-305917859 seems like it would be a nice accessory library (for power users).
<link href="foundation.css">
<link href="foundation-utils.css">

<p class="m-x-lg">

tbh, I'd just avoid this. Let Tachyons serve that crowd and Foundation serve everyone else.

@corysimmons
On http://foundation.zurb.com/sites/6.4.0-rc/docs/prototyping-utilities.html
I have my 3 cents

I might be wrong but i am getting a little feeling (with your Tachyons example you gave) that you might not concur with the development which has happended regarding prototypes.
I want to clear that first, I fully understand very well that these helper classes are a bad css practices and is really just one step away of inline css. But, i will be practical here... as a designer, we would know that while prototyping, we don't sell the code but instead sell the concept, the design, the interactivity. Infact in most situations, you need to show multiple designs to get one approved.
For that scenario, i think they are not bad because they are disabled by default and biggest part of the current development is that they can be easily swapped by the Sass Mixins which for me is huge.
Infact to make it more better, I totally agree with @tdhartwick that we should look to include a linter or alert when watching that would warn people when they're using prototyping classes. I also agree on npm run build to convey a more firm message if there are still using prototyped classes. Infact would urge @kball or @paxperscientiam to make that happen!

My another vision to this is with the dist build aka normal css projects (non modern web) where developers only code the design and they dont know CSS well
Well personally, As I live in India aka developing country, i can tell you the situation pretty well on this. In developing countries, 95% of the web if not more dont use Sass or even a good css methodology and moreover mostly developers(Php, Java Background) are the one who design the web and they just dont know css well. They want to just read the docs, get classes... add in code... repeat!
For them i think this is a huge development, I have just compared the css and this is what i get
a. foundation.min.css - 101kb
b. foundation-prototype.min.css - 109kb
I strongly believe that I have taken care of the code pretty well and have made the css as minimal as possible and I have no doubt in my mind that 8kb of extra code is not bad for such a cool and optional feature like Prototyping classes. Believe me or not, I personally think of this as a big reason why frameworks like bootstrap are so popular.

I now will come to the current discussion about renaming of sizing and spacing classes on whether its worth it or not!
I do think that It can be on first look... pretty difficult to understand the suggested naming but then I also have no doubt in mind that if we are showing these classes proper usage within the docs like below example :arrow_double_down:  then it wont be that difficult for a newbie to get into there minds pretty quickly!

Man, I appreciate the effortpost, but this is so much to read and I keep catching myself doing free consulting. Can someone please ban me from this repo/org so I can focus on getting a job?

No issue, I understand... Thanks for all you have done with helping out get us ideas with new grid.

Hey @tdhartwick @kball ... do we have a consensus on it ??

I'm all for margin & padding helpers, but personally I've never felt the need for height & width classes. Doesn't the grid already do this? 🤔

I've only used the margin-bottom classes before for prototyping.
Example:
.mb0 {
  margin-bottom: $global-margin;
}

.mb1 {
  margin-bottom: $global-margin;
}

.mb2 {
  margin-bottom: $global-margin * 2;
}

Don't think I'd use any others.

The way it's coded you are allowed to choose  which helper classes you want and which you don't want

It's already mentioned in the docs on how to choose specific utilities

But yes sizing classes are debatable!

https://github.com/zurb/foundation-sites/pull/10122#issuecomment-310976107


Major rewrite of TCPShield

TCPShield rewrite
This PR includes drastic changes to the TCPShield plugin. In order to understand the changes, I am going through most of them, and explain the works and motives behind them.
Gradle
This rewrite includes a move from Maven to Gradle.

automatic versioning (see later)
less boilerplate code
faster compile times

Versioning
Through the usage of GSON and SnakeYAML during build time, the plugin "manifest" files plugin.yml, bungee.yml and velocity-plugin.json are always up-to-date.
This reduces risks of wrong version numbers and time needed to update the version itself.
The version is updated by changing the variable version in build.gradle to the new version.
For example: version = '1.8' -> version = '2.0'.
Abstraction
Abstraction is the logical way to implement support for more than one platform. In order to reduce duplicate code, the main business logic is contained in classes shared by all platforms.
Abstraction also allows easy creation of tests.
The "heart" of the logic lies in net.tcpshield.tcpshield.HandshakePacketHandler.
There are three interfaces / abstract classes which handle platform specific tasks like e.g. modifying the original packet, setting their ip, configuration, etc.
In order to implement a new platform, one needs to implement IPlayer, IPacket and TCPShieldConfig. An example of an implementation of those classes can be seen under net.tcpshield.tcpshield.bungee.impl.
The second step is going through the usual steps in developing a plugin native for the platform: e.g. create a main class, create the plugin "manifest" (don't forget to add auto-versioning for that file in build.gradle!)
The final step is to implement packet interception and forwarding it to HandshakePacketHandler. An example of that can be seen in net.tcpshield.tcpshield.bungee.BungeeHandshakePacketHandler.
I encourage you to put platform-specific code in a package specific to that platform in order to retain a neat & tidy structure.
Exceptions
In order to improve code quality, there are custom exceptions specific for TCPShield. The exception handling is done in net.tcpshield.tcpshield.HandshakePacketHandler. Most exceptions don't get printed to the console unless debug is enabled in the config.
Testing
This rewrite includes JUnit 5 Tests in order to catch bugs early in the process. All tests are executed on build time.
Testing is yet limited to platform-independent code. Further tests for platform-specific code should be added in the future.
Platform support
Native Paper support
Because Paper provides the PlayerHandshakeEvent, we are able to easily implement native support. With only around 130 lines of code, some code-sharing with the ProtocolLib implementation and no use of Reflection (except maybe the check if the server is Paper), maintaining native Paper support is easy and straightforward.
Velocity support
Originally implemented as a demonstration of the benefits of abstraction, including Velocity support increases the target group able to enjoy TCPShield.
New Timestamp Validation
Time Validation was oddly enough originally only implemented in the Bungee version of TCPShield. In order to guarantee integrity of the received data, timestamp validation is crucial.
The downside of timestamp validation is that many admins don't have access to the host machine. Server times off by ~3 seconds render TCPShield with timestamp validation unusable.
The rewrite includes three configurable modes regarding timestamp validation:

HTPDate (default): syncs server time with a HTTP request to google.com (HTTP responses include the server time)
System Time: uses the system time
Disabled: disables timestamp validation (really really not recommended to use)

@Fuzzlemann Absolutely fantastic work here!
This will take me sometime to review, I may have a few comments before we merge into master. I was only able to glance today.
I will do a full review sometime over the next 48 hours.
Thanks so much for your contribution. This will do much for the MC community.

Nice work, but maybe it fails about keeping things simple. 😄💭

Personally don't see another way it could be done easier and with the same amount of encapsulation / abstraction providing the same amount of flexibility and ease of porting.