Additional processing support for MiniMagick and RMagick
This gem will helps you identify lines and characters of the text which are invalid for particular encoding
Simple rails plugin to make text more readable by applying some typographic rules to string.
Ruby library for consuming Google, Yahoo!, Flickr and Windows Live contact APIs
EventMachine based WebSocket server
Calendar-generating plugin for Ruby
Use FSEvent (Mac OS X 10.5 or higher) instead of filesystem polling.
One-dimensional bin packing algorithm, solved with hill climbing, tabu search and GA.
bootstrap-sass is bootstrap for Rails, ready to roll
Ckeditor integration gem for rails
Is there any way forward here? I get similar "permission denied" errors and it's not clear whether it can be fixed in current setup at all.
I am using lima with docker and regardless on whether I use rootless docker or rootful docker + sudo - I still get permission denied errors. Is it an sshfs limitation? or can we expect it to work in the future (ignoring 9p work).
comment created time in 13 hours
created branch time in 3 months
commit sha 240249736317ad9060dcfd7e9ae99d3ad8d850f6
Add 3 separate sotw.Server#process implementations to allow for clients to chose whether they need ordered on unordered ADS servers Signed-off-by: Pavel Forkert <email@example.com>
push time in 3 months
pull request commentenvoyproxy/go-control-plane
@snowp @alecholmez @kyessenov @jessicayuen
comment created time in 3 months
PR opened envoyproxy/go-control-plane
This is basically a continuation of https://github.com/envoyproxy/go-control-plane/pull/357, which instead of replacing current
sotw.Server#process implementation - adds 3 more implementations and ability to switch between them.
After https://github.com/envoyproxy/go-control-plane/pull/443 is merged - go-control-plane can support my original goals of being able not to have traffic drops when you have multiple resource types changed in a single "step", ie: if you change both CDS and EDS resource at the same time the only correct way to send these resources down the line is to send CDS first and EDS second (https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol#eventual-consistency-considerations).
Currently the user of this library cannot do this at all, cause if they pushe both CDS and EDS responses into their channels on the cache side in order - the select loop here (https://github.com/envoyproxy/go-control-plane/blob/main/pkg/server/sotw/v3/server.go#L195) does not guarantee that CDS will be selected first and EDS next.
Now, to actual implementations:
server_default.go- it is a copy of original
sotw.Server#processimplementation, to be able to "fall back to good state"
server_xds.go- works in the same way as the default one (responses channel is recreated on every valid incoming request), but only supports single resource type, which covers non-ADS protocol part. it is simpler than default one and (probably) a bit faster, given the fact that it just removes a bunch of stuff that non-ADS requests do not need.
server_ordered_ads.go- completely different implementation for ADS, that instead of creating a separate channel for each incoming request and abandoning the old one - uses (and reuses) single channel for all request types. the main benefit is that you no longer have a select that breaks ordering, so that if cache pushes CDS first and EDS second - this implementation guarantees that server will actually send updates to the wire in this order. Downside (as was discussed in previous PRs) - you no longer have backpressure per resource. ie: in default implementation if cache decides to send 2 CDS updates - the second one will be blocked, cause the channel has buffer of size 1 and second push to the channel will be blocked, but pushes to channels of other type urls can succeed as long as corresponding channels are empty. This implementation due to channel reuse and the fact that the channel is shared between type urls - if your cache implementation sends many EDS updates, for example - it might be blocked on channel push when there is a CDS update.
server_unordered_ads.go- reimplementation of the default behaviour, but based on reflect.Select, which eliminates duplication in original implementation and allows having any number of type urls supported without the need to fall back to either shared channel for non-LDS/RDS/CDS/EDS and does not require any additional goroutines if there is a need for same "backpressure semantics" for these non-main type urls.
pr created time in 3 months