[Snyk] Security upgrade urllib3 from 2.0.7 to 2.2.2

This PR was automatically created by Snyk using the credentials of a real user.![snyk-top-banner](https://github.com/andygongea/OWASP-Benchmark/assets/818805/c518c423-16fe-447e-b67f-ad5a49b5d123)
Snyk has created this PR to fix 1 vulnerabilities in the pip dependencies of this project.
Snyk changed the following file(s):

requirements.txt

⚠ Warning
```
mlflow 1.30.1 requires scipy, which is not installed.
kedro 0.18.14 has requirement importlib-metadata<5.0,>=3.6; python_version < "3.8", but you have importlib-metadata 5.2.0.
pytoolconfig 1.3.0 has requirement packaging>=22.0, but you have packaging 21.3.
</details>

---

> [!IMPORTANT]
>
> - Check the changes in this PR to ensure they won't cause issues with your project.
> - Max score is 1000. Note that the real score may have changed since the PR was raised.
> - This PR was automatically created by Snyk using the credentials of a real user.
> - Some vulnerabilities couldn't be fully fixed and so Snyk will still find them when the project is tested again. This may be because the vulnerability existed within more than one direct dependency, but not all of the affected dependencies could be upgraded.

---

**Note:** _You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs._

For more information: <img src="https://api.segment.io/v1/pixel/track?data=eyJ3cml0ZUtleSI6InJyWmxZcEdHY2RyTHZsb0lYd0dUcVg4WkFRTnNCOUEwIiwiYW5vbnltb3VzSWQiOiJiYjk2ZWRlZC04ZTg2LTQ0M2QtYjYwMi00OGU2YzQxNmNmMzMiLCJldmVudCI6IlBSIHZpZXdlZCIsInByb3BlcnRpZXMiOnsicHJJZCI6ImJiOTZlZGVkLThlODYtNDQzZC1iNjAyLTQ4ZTZjNDE2Y2YzMyJ9fQ==" width="0" height="0"/>
🧐 [View latest project report](https://app.snyk.io/org/galileo-galilei/project/1e817adc-a97c-4a91-b109-38de880a043d?utm_source=github&utm_medium=referral&page=fix-pr)
📜 [Customise PR templates](https://docs.snyk.io/scan-using-snyk/pull-requests/snyk-fix-pull-or-merge-requests/customize-pr-templates)
🛠 [Adjust project settings](https://app.snyk.io/org/galileo-galilei/project/1e817adc-a97c-4a91-b109-38de880a043d?utm_source=github&utm_medium=referral&page=fix-pr/settings)
📚 [Read about Snyk's upgrade logic](https://support.snyk.io/hc/en-us/articles/360003891078-Snyk-patches-to-fix-vulnerabilities)

---

**Learn how to fix vulnerabilities with free interactive lessons:**

🦉 [Learn about vulnerability in an interactive lesson of Snyk Learn.](https://learn.snyk.io/?loc=fix-pr)

[//]: # 'snyk:metadata:{"customTemplate":{"variablesUsed":[],"fieldsUsed":[]},"dependencies":[{"name":"urllib3","from":"2.0.7","to":"2.2.2"}],"env":"prod","issuesToFix":[{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-URLLIB3-7267250","priority_score":586,"priority_score_factors":[{"type":"freshness","label":true,"score":71},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"6","score":300},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Improper Removal of Sensitive Information Before Storage or Transfer"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-URLLIB3-7267250","priority_score":586,"priority_score_factors":[{"type":"freshness","label":true,"score":71},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"6","score":300},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Improper Removal of Sensitive Information Before Storage or Transfer"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-URLLIB3-7267250","priority_score":586,"priority_score_factors":[{"type":"freshness","label":true,"score":71},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"6","score":300},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Improper Removal of Sensitive Information Before Storage or Transfer"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-URLLIB3-7267250","priority_score":586,"priority_score_factors":[{"type":"freshness","label":true,"score":71},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"6","score":300},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Improper Removal of Sensitive Information Before Storage or Transfer"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-URLLIB3-7267250","priority_score":586,"priority_score_factors":[{"type":"freshness","label":true,"score":71},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"6","score":300},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Improper Removal of Sensitive Information Before Storage or Transfer"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-URLLIB3-7267250","priority_score":586,"priority_score_factors":[{"type":"freshness","label":true,"score":71},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"6","score":300},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Improper Removal of Sensitive Information Before Storage or Transfer"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-URLLIB3-7267250","priority_score":586,"priority_score_factors":[{"type":"freshness","label":true,"score":71},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"6","score":300},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Improper Removal of Sensitive Information Before Storage or Transfer"}],"prId":"bb96eded-8e86-443d-b602-48e6c416cf33","prPublicId":"bb96eded-8e86-443d-b602-48e6c416cf33","packageManager":"pip","priorityScoreList":[586],"projectPublicId":"1e817adc-a97c-4a91-b109-38de880a043d","projectUrl":"https://app.snyk.io/org/galileo-galilei/project/1e817adc-a97c-4a91-b109-38de880a043d?utm_source=github&utm_medium=referral&page=fix-pr","prType":"fix","templateFieldSources":{"branchName":"default","commitMessage":"default","description":"default","title":"default"},"templateVariants":["updated-fix-title","pr-warning-shown","priorityScore"],"type":"auto","upgrade":[],"vulns":["SNYK-PYTHON-URLLIB3-7267250"],"patch":[],"isBreakingChange":false,"remediationStrategy":"vuln"}'

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 99.90%. Comparing base (64b8e94) to head (33bb8f7).

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #560      +/-   ##
==========================================
- Coverage   99.90%   99.90%   -0.01%
==========================================
  Files          29       29
  Lines        1021     1020       -1
==========================================
- Hits         1020     1019       -1
  Misses          1        1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


baking picture

main requirement:

[x] relative to gmod.exe materials folder path
minor requirements:
[x] automatically resource.AddFile
[x] UL.View_Bake(string view)

[x] view->WriteToPNG()

[ ] switch b and r channels?

closed by https://github.com/SupinePandora43/gm_ultralight/commit/753ae9e9328a739378f57a9c86a2f89df4cfff7d


Refactor

Warning: These changes break API
Refactor
Summary of changes:

battery_system, motion_sink, ambient_sink and planner bundled into new rmf_task::agv::Parameters class
Updated signature for rmf_task::agv::TaskPlanner::Configuration.

Configuration(
      Parameters parameters,
      Constraints constraints,
      ConstCostCalculatorPtr cost_calculator,
      bool drain_battery);

TaskPlanner::greedy_plan() and TaskPlanner::optimal_plan() no longer need std::vector<Constraints> to be passed in. The TaskPlanner always assumed that the battery characteristics and nav graphs of the agents being planned for are same. In facts the Requests are generated with this assumption. But users were able to pass a Constraint for each State implying that agents may have unique characteristics. This was misleading. Now, by passing in a single Constraints into TaskPlanner::Configuration, it is clearer that these constraints apply to all agents.
A recharge_soc parameter is added to rmf_task::agv::Constraints to allow users to specify what battery level an agent should be recharged up to. Previously, this was always 1.0. Fix https://github.com/open-rmf/rmf_task/issues/11
Previously, a drain_battery boolean was passed into the factory for any Request. This tied up battery drain with the request itself. Thus in downstream fleet adapter packages, it was not possible to simply replan the assignments without factoring battery drain unless all the requests were regenerated. Now, the drain_battery parameter is specified in TaskPlanner::Configuration and the Request::Description::estimate_finish() function takes in a drain_battery boolean. Thus, the same set of requests can be planned for with/without battery drain by appropriately initializing the TaskPlanner. Note: A user will need to re-initialize the TaskPlanner when they switch drain_battery values as the internal cache will need to be reset. The API enforces this.

Thanks for the guidance @mxgrey. I've refactored as per your suggestion.

Thanks for the feedback @mxgrey. I hope I have addressed all your points.
One thing I would like to point out is that with the refactor, the average time taken to solve the scenarios in the unit test goes down by 15-30%. Here are the test printouts before and after. The worst scenario takes ~160ms which is still not too bad. I'm guessing the increased time is from the initialization of the Models during each run which was previously "cached" into the Requests themselves. But the improved flexibility with the new API certainly outweighs the increased computation time.

There isn't any reason we should have to accept a performance drop from the API changes. We probably just need one more implementation tweak.
Inside the planner code, define some struct like
struct RequestModel
{
  Request request;
  std::shared_ptr<Request::Model> model;
};

Initialize one of these at the start for each input request and then pass them around as a replacement for all the places that you used to pass a Request around.

Initialize one of these at the start for each input request and then pass them around as std::shared_ptr a replacement for all the places that you used to pass a std::shared_ptr around.

Sure, that would prevent Models from being initialized every time make_initial_node() is called but wouldn't the overall solve duration still be higher than earlier as we still need to initialize all the Models once? Of course if we measure performance by summing the durations to create the requests and then solve them, the performance will be the same with the change above. But in the fleet adapters for example where requests are generated once and are replanned every now and then, the time taken to produce a plan would be longer with the new API.
But yes, I shall implement the suggestion above.

I see, I'm surprised that the one-time calculation of the invariants would cost so much. I guess that's from computing the energy drain while driving?
After looking more closely at the code, I'm not sure my suggestion about bundling the model with the request will accomplish anything since it looks like a PendingTask instance is only created once for each request.
I think we could deal with the replanning performance drop by beefing up the TaskPlanner or TaskPlanner::Result class to maintain a cache of the Model for each request in between runs, and have an API for us to add/remove/enable/disable requests before each planning attempt. But that can be saved for a followup PR.

After looking more closely at the code, I'm not sure my suggestion about bundling the model with the request will accomplish anything since it looks like a PendingTask instance is only created once for each request.

Yeah I tried it out but there wasn't any significant improvement.

I think we could deal with the replanning performance drop by beefing up the TaskPlanner or TaskPlanner::Result class to maintain a cache of the Model for each request in between runs, and have an API for us to add/remove/enable/disable requests before each planning attempt. But that can be saved for a followup PR.

Sounds good. I'll open a ticket for that.

I just noticed, I think there was a misunderstanding. I was saying we can change this whole if-statement to
if (initial_state.battery_soc() >= recharge_soc - 1e-3
  && initial_state.waypoint() == initial_state.charging_waypoint())

The way it is right now, the first check in the or-statement is redundant with the second.

whoops gross oversight 🤦🏼♂


envoy/lds: use listenerBuilder type to build listener and filters

Description:
This change consolidates functions used to build the listener
component as method receivers for the listenerBuilder type.
This results in better organization of related code and avoids
passing MeshCataloger and Configurator objects repeatedly
between different functions.
This is in preparation for #2056 and #1521.
Signed-off-by: Shashank Ram<EMAIL_ADDRESS>
Affected area:

New Functionality      [ ]
Documentation          [ ]
Install                [ ]
Control Plane          [X]
CLI Tool               [ ]
Certificate Management [ ]
Networking             [ ]
Metrics                [ ]
SMI Policy             [ ]
Security               [ ]
Tests                  [ ]
CI System              [ ]
Performance            [ ]
Other                  [ ]

Please answer the following questions with yes/no.

Does this change contain code from or inspired by another project? If so, did you notify the maintainers and provide attribution?
No

Codecov Report

Merging #2105 (6648f40) into main (120b1cf) will increase coverage by 0.07%.
The diff coverage is 25.00%.

@@            Coverage Diff             @@
##             main    #2105      +/-   ##
==========================================
+ Coverage   58.38%   58.45%   +0.07%
==========================================
  Files         144      144
  Lines        5911     5912       +1
==========================================
+ Hits         3451     3456       +5
+ Misses       2457     2453       -4
  Partials        3        3

Impacted Files
Coverage Δ

pkg/envoy/lds/listener.go
26.53% <0.00%> (ø)

pkg/envoy/lds/response.go
6.34% <33.33%> (+6.34%)
:arrow_up:

pkg/envoy/lds/inmesh.go
85.18% <100.00%> (ø)

pkg/envoy/route/config.go
96.03% <0.00%> (+0.79%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 120b1cf...6648f40. Read the comment docs.


Corners are rounded when window is maximized

When I maximize the Source Git window, the corners of the window are rounded. When I reach the upper right corner to close the window, I move the mouse pointer very close to the actual screen corner, and the click does not hit the close button.
Other applications that use a custom title bar (Firefox, Electron) will display fine, with rounded corners when not maximized and square corners when maximized.
I'm using KDE6, and when I disable rounded corners in my theme settings, Source Git is still rounded.

(Maximized window)

Try commit c1c1e1f0c896b46f4112a5460b50a345ee903210

Try again?
f4f5ae7430 - ux: remove rounded corner when window is maximized using TemplateBinding (#378)

Now it displays correctly, but clicking still doesn't hit the button, even though the button behaves as if it was clicked
For some reason GitHub doesn't like the video so I archived it
output.zip

I can see nothing in your video 😅
https://github.com/user-attachments/assets/c915c552-48b0-4fab-8383-85cee3b70a29

That was awkward :grin: for some reason it plays just fine for me
Hope re-encoding will help:
https://github.com/user-attachments/assets/24f8050e-a611-4027-b926-3753eb07efcc

I reproduce this issue on Windows. It is very strange.

According to the event, it has been handled by Button

This issue seems not blongs to this software and it has little impact. I'm not going into it.


Streaming plugin not working in some cases

Might it be because more people are sent presences of than members? or the other way around?

Actually this might not be anythign and rather the discord client being out of sync

Gonna chalk this one up to just that, seems to be working fine.


Cloudflare Workers Vitest integration Broken by this package

The Cloudflare Workers recommended testing strategy, the Vitest Integration, is not compatible with this package. It's due to a dependency, @asteasolutions/zod-to-openapi. This package depends on v5 of  @asteasolutions/zod-to-openapi, which was not published in ESM format. Vitest only works with ESM code.
The dependency has already been fixed in v7. Can this package be updated to use the v7 of @asteasolutions/zod-to-openapi?
References

https://github.com/asteasolutions/zod-to-openapi/issues/219
https://github.com/asteasolutions/zod-to-openapi/releases/tag/v7.0.0

I've overriden @asteasolutions/zod-to-openapi in my app's package.json to use v7 with no ill effects so far.
In package.json:
{
  "dependencies": {
    "@cloudflare/itty-router-openapi": "^1.1.0",
    "zod": "^3.22.4"
  },
  "overrides": {
    "@cloudflare/itty-router-openapi": {
      "@asteasolutions/zod-to-openapi": "^7.0.0"
    }
  }
}

Duplicate of #144. Resolved in v1.1.1.


Update Hyperlink title i

https://developers.mattermost.com/integrate/customization/embedding/

Hello @varghesejose2020,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

@cwarnermm Could you please review this change?


#12151: Replace avg_pool2d with global_avg_pool2d

Ticket
#12151
Problem description
In ttnn currently there are global_avg_pool2d and avg_pool2d. Both of them do global average pooling (compute a single average of each channel). It seems that avg_pool2d is not a public API (couldn't be found on https://docs.tenstorrent.com/ttnn/latest/ttnn/ttnn) and most places in tt-metal use global_avg_pool2d
This change removes the avg_pool2d and replace all its remaining usages with global_avg_pool2d. This frees up the name ttnn.avg_pool2d for the implementation of the actual average pooling API with kernel size (#12151)
What's changed

Remove the export of ttnn.avg_pool2d (which is actually global average pool2d)
Replace the remaining usages of avg_pool2d in tt-metal with global_avg_pool2d

Checklist

[x] Post commit CI passes (https://github.com/tenstorrent/tt-metal/actions/runs/11546482848)
[ ] Blackhole Post commit (if applicable)
[ ] Model regression CI testing passes (if applicable)
[ ] Device performance regression CI testing passes (if applicable)
[x] New/Existing tests provide coverage for changes

Thanks for the review! Could someone help me merge the PR? It seems like I still have no permission to merge


Added middleware for subscribe API

Added middleware for /challenge/subscribe API. So that -

This can prevent security issues.
It avoids users to send any data to this endpoint.
This can prevent to potential vulnerabilities and exploits.

Nit:- can you please connect issue ticket in description


Turn on performance for when lid open

Change the lid state to performance when the lid opens again and it should be performance.

Fixed in #118


Phone calls and glitches on iphone6

I’m on the latest version of Unc0ver 2.3.1
While in a call I hear a incoming call. But it doesn’t show a name or banner.
On top of that while in FaceTime call my iPhone glitches and hearing weird noises.
I use this phone everyday and I have to call people to see if they called me. Like work or important meetings.

unc0ver 2.3.1.... are you from the future?

@chasewyrick uninstall opener


Review actors code and adapt to simpler design

The current implementation of IPC actors follow the legacy (and more complex) design of the protocol. We need to adapt the implementation to @guy-goren's simpler design. My proposal is to do a 3-days/1-week sprint were @cryptoAtwill can walk @guy-goren through the code and @guy-goren can share the changes required to adapt the actors to his simpler design. This way we would have a first version of the actors ready for deployment with the new spec.
The outcome of the sprint should be a set of issues or changes required for our actors to implement the simpler version of the protocol (cross-net actors). This exercise can also be useful as a first internal audit of the code.
List of changes required
After a first pass through the code and the simpler design, here are the list of things that we should change/improve.
Single-level cross-net messages allowed
In the simplified model, the IPC client is responsible for the propagation of arbitrary cross-net messages between subnets. Actors won't be the ones handling this operation, on-chain. Consequently, the SendCross method for the IPC gateway will be disabled, and only fund and release will be exposed through the IPC gatway to send cross-net message. The only low-level primitive exposed by the gateway is to send a cross-net message to the parent of a subnet or to an immediate child.
Triggered by externally owned addresses
With this, if a user wants to send a cross-net message from subnet A1 (where it holds some funds) to call an actor at address f01 in  subnetB1 through the following path: A1 -> /root -> B1, this won't be handled automatically anymore by sendCross of the IPC protocol but by the IPC client. The client will decompose in a set of message that funds an account for the user in B1 to perform the call. It will be decomposed into a release message from A1 to root a fund message from root to B1, and the actor call within B1. This is possible because the on-chain ID for f1EOA in every subnet can be known through the mapping between users key pairs and their account actor.
This approach removes the issue of providing feedback about the execution of a message by the actors, e.g. if the user doesn't provide enough funds to the message to be execute and runs out of gas half-way, the IPC client will notify that, and prompt the user to fund the address where the message failed to keep propagating the funds to the target subnet for the actor call.
To illustrate the example graphically, sendCross(from: A1:f1EOA, to: B1:f01, method: X, params: blob, amount: gas_provision) translates into:
1. release(from: A1:f1EOA, to: root:f1EOA, amount: gas_provision)
2. fund(from: root:f1EOA, to: B1:f1EOA,  amount: gas_provision -  release_fee)
3. send(from: B1:f1EOA, to: B1:f01, method: X, params: blob)

Thus, release and fund are exclusively used to move funds up and down the hierarchy. The EOA is the one responsible for paying for all the gas for the cross-net propagation and execution.
Triggered by actors.
Not only EOA can trigger cross-net messages, they may also be triggered as a side-effect of an actor execution in a subnet. For the propagation of these cross-net actors, we will include a new data structure in the IPC gateway state, postbox: THamt<Address, TCid<THamt<TCid<Msg>, Msg>> and two new method wrapped_cross_msg and propagate:

wrapped_cross_msg can be called by actor to send cross-net messages to some other actor in another subnet of the hierarchy.
postbox keeps track for an EOA of all the cross-net messages triggered by an actor that need to be propagated further through the hierarchy. As described above, messages can only be propagated one subnet at a time, either to the parent or to its immediate parent.
propagate needs to be called by the EOA that triggered the cross-net message from the original actor to move the cross-net from the postbox up or down.

Lets illustrate the set of low-level messages involved here with a sample message from A1:f1EOA to actor A1:f01 that triggers a call to wrapped_cross_message(owner: f1EOA, msg: msg(from: A1:f01, to: B1:f02, method: X, params: blob)) from f01 as a side-effect.
// initial message to actor that triggers side-effect.
1. msg(from: A1:f1EOA, to: A1f01, ...)
// message called by the actor to the ipc-gateway as a side-effect. The wrapped message
// is included in the postbox for further propagation with `f1EOA` as the owner.
   side-effect > wrapped_cross_message(owner: f1EOA, amound: provision_gas, msg: msg(from: A1:f01, to: B1:f02, amount: A, method: X, params: blob))
// f1EOA sends a message to `propagate` in IPC gateway of A1 to propagate the wrapped message
// to the root from the postbox.
2. propagate(amount: provision_gas: params: msg_cid)   // A1 subnet
// f1EOA sends a message to `propagate` in IPC gateway of root to propagate the wrapped message
// down to B1 from the postbox
3. propagate(amount: provision_gas: params: msg_cid)   // root
// f1EOA triggers the application of the cross-message
4. apply_msg(amount: provision_gas: params: msg_cid)  // B1
   // the application of the message triggers as a side-effect the call to the destination actor in the destination subnet.
   side-effect > send(msg(from: A1:f01, to: B1:f02, amount: A, method: X, params: blob)))

The EOA that triggers the initial side-effect in the originator actor is the one responsible for the propagation of the message to its destination, and for paying for the gas of routing the message. Actors can't sign messages by themselves, and the only way they have to trust that the message that triggered the forwarding of a cross-net message has been finalized in the source subnet, is if it is propagated though all of the consensus engines of the subnets to its path to the destination.
User-defined execution of cross-net messages.
In the MVP, the execution of cross-net messages was performed through an ApplyImplicitMessage from the system_actor. This was possible because the IPC gateway was a builtin actor that could get special treatment and all peers shipped with the necessary logic to handle these special messages (the same way that rewards and cron events are handled implicitly). With the IPC gateway as a user-defined actor this is no longer possible.
For the execution of cross-net messages in the IPC gateway as a user-defined actor we will rely on getting a quorum of validators to accept the execution of the messages. In this new version, apply_msg accepts as parameters a batch of messages to be applied. When validators see that there are unverified cross-net messages to be applied, they perform all the consensus checks to determine that is final in the source subnet, and vote for their application by sending a message to apply_msg (which can only be called by validators). The gateway waits for every message to be "voted for execution" (i.e. that is final and the consensus checks have been successful) by a majority of validators in the subnet. We can then introduce a reward that is distributed to validators from the tokens provisioned by the user to pay for propagation and execution fees.
Illustrating it step-by-step the execution of cross-net messages works as follows:
Before (IPC gateway as builtin-actor):
1. Cross-net message pool (unverified)
2. Cross-net messages are proposed in a block.
3. To accept messages as part of the block validators perform cross-net consensus checks.
4. Cross-net messages within a block are executed implicitly (the same way block reward messages and cron events are executed)

After (IPC gateway as user-defined actor):
1.Cross-net message pool (unverified)
5. Each validator perform cross-net consensus checks
6. Each validator calls apply_msg
7. When consensus reached the message is executed and rewards distributed.

Note to self: add a note on why we need this generalization to pass information (prevent pairwise bridges, a baseline mechanisms for passing information with the same trust assumptions provided by IPC).

Gas fees for cross-net primitives

WIP

Hi @adlrocha @guy-goren , just two quick questions to clarify on the terminologies.

By the term IPC client, I assume it's code other than gateway and subnet-actor? Also, who is maintaining the IPC client, how do we know IPC client will behave correctly?
What's EOA?

By the term IPC client, I assume it's code other than gateway and subnet-actor? Also, who is maintaining the IPC client, how do we know IPC client will behave correctly?

The IPC client is the peer implementation, the off-chain code that orchestrates all the interaction with the actors and other peers of the network (let me know if it still not clear). The architecture in this issue should make it a bit clearer.

What's EOA?

Externally Owned Address. I should have stated this explicitly, sorry.

Closed by #30


SOLR-15536: Rewrite /c//shards v2 APIs using annotations

Description
The community is in the process of migrating v2 API implementations over to an annotation-based framework that results in less duplication and easier to understand code.  But the /c//shards APIs still need to use this.
Solution
This PR reimplements the /c//shards APIs using the annotation framework.
Tests
See V2ShardsAPIMappingTest
Checklist
Please review the following and check all that apply:

[x] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
[x] I have created a Jira issue and added the issue ID to my pull request title.
[x] I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
[x] I have developed this patch against the main branch.
[ ] I have run ./gradlew check.
[x] I have added tests for my changes.

FYI @epugh since you've been kind enough to review similar patches in the past.

I think I am slightly confused, I was expecting these "apispec.json" files to go away, but they are over in solrj????
https://github.com/gerlowskija/solr/blob/SOLR_15536_shards_v2_apis_using_annotation_framework/solr/solrj/src/resources/apispec/collections.collection.shards.shard.Commands.json
Do we define the apis on both places?  Or am I jumping the gun and you just haven't gotton to deleting the related .json file?   Great to see progress...

I think I am slightly confused, I was expecting these "apispec.json" files to go away, but they are over in solrj????
https://github.com/gerlowskija/solr/blob/SOLR_15536_shards_v2_apis_using_annotation_framework/solr/solrj/src/resources/apispec/collections.collection.shards.shard.Commands.json
Do we define the apis on both places? Or am I jumping the gun and you just haven't gotton to deleting the related .json file? Great to see progress...

Never mind, I didn't scroll far enough down...?

Okay, one more morning thought....   Do we actually need the captureConvertedV1Params and the mapping between V1 and V2 tests?   Do we care that V2 is different then V1????    Especially now that it's "experimental" and we might make a LOT of changes...     DO we limit ourselves by having this mapping check?    I'm curious how having these tests (which also look complex and a LOT of work) help us build a better V2 API?
A part of me wants to pick a common use case for the API, and draw out the steps and the related API calls, and see where we are overly verbose or overly terse to inform our V2 structure ;-)

Do we actually need the captureConvertedV1Params and the mapping between V1 and V2 tests? Do we care that V2 is different then V1????

I think so, but maybe you can correct me.  Here's the case I'd make for them:
Right now our v2 APIs are mostly written as a thin interface that calls out to existing v1 functionality.  e.g. AddReplicaAPI doesn't really have replica-adding logic - it just shuffles some parameters around and calls the v1 logic that already exists in CollectionsHandler.handleRequestBody.
So to have confidence in our v2 API, we need to verify two things:

That CollectionsHandler.handleRequestBody works as expected.
That the "parameter shuffling" AddReplicaAPI does before calling handleRequestBody is correct.

The first is already verified by many tests throughout the codebase.  So that box is checked.  We should already have lots of confidence in /solr/admin/collections?action=ADDREPLICA.
That just leaves (2).
To trust AddReplicaAPIs replica-property support, we need to verify that AddReplicaAPI's JSON map of properties gets flattened and prefixed with property..  To trust AddReplicaAPI's handling of nodeset values we need to verify that they are converted from the nice JSON list that AddReplicaAPI offers to the comma-delimited string that v1 requires. And so on.
That's what the tests in this PR are doing.  They're not ensuring that v1 and v2 are the same - they don't have to be.  They're ensuring that when a v2 API makes use of v1 code, it's invoking that code correctly.


Provide custom focus implementation

feature request
It would be nice to specify focus implementation. For example to make smooth scroll to element + Npx above it before focusing:
import createDecorator from 'final-form-focus'

const onFocus = input => {
  const { top } = getOffset(input);
  const scrollTop = top - 50;

  window.scrollTo({
    top: scrollTop,
	behavior: 'smooth',
  });

  input.focus();
}

const focusOnErrors = createDecorator(null, null, onFocus)

@erikras Any plans to support custom focus implementations?

My team has rolled its own solution for this, which focuses on the input and smooth-scrolls to it using scrollIntoView. Therefore, we stopped using this library. Our solutions looks like this:
import React from 'react'
import { Form as FinalForm } from 'react-final-form'

const Form = props => (
  <FinalForm {...props}>
    {({
      form: finalFormApi,
      handleSubmit,
    }) => (
      <form
        finalFormApi={finalFormApi}
        {...props}
        onSubmit={event => {
          const invalidField = finalFormApi.getRegisteredFields().find(field => finalFormApi.getFieldState(field).invalid)

          if (invalidField) {
            const targetInput = document.querySelector(`[name="${invalidField}"]`)
            const targetLabel = document.querySelector(`label[for="${invalidField}"]`) || targetInput
            if (targetInput) {
              targetInput.focus({ preventScroll: true })
              targetLabel.scrollIntoView({
                behavior: 'smooth',
                block: 'center',
              })
            }
          }

          handleSubmit(event)
        }}
      >
        {props.children}
      </form>
    )}
  </FinalForm>
)

export default Form

FYI, here's a PR for this: https://github.com/final-form/final-form-focus/pull/25


0933 - Number of Recent Calls

Description of the Problem
You have a RecentCounter class which counts the number of recent requests within a certain time frame.
Implement the RecentCounter class:

RecentCounter() Initializes the counter with zero recent requests.
int ping(int t) Adds a new request at time t, where t represents some time in milliseconds, and returns the number of requests that has happened in the past 3000 milliseconds (including the new request). Specifically, return the number of requests that have happened in the inclusive range [t - 3000, t].

It is guaranteed that every call to ping uses a strictly larger value of t than the previous call.
Example 1:
Input
["RecentCounter", "ping", "ping", "ping", "ping"]
[[], [1], [100], [3001], [3002]]
Output
[null, 1, 2, 3, 3]

Explanation
RecentCounter recentCounter = new RecentCounter();
recentCounter.ping(1);     // requests = [1], range is [-2999,1], return 1
recentCounter.ping(100);   // requests = [1, 100], range is [-2900,100], return 2
recentCounter.ping(3001);  // requests = [1, 100, 3001], range is [1,3001], return 3
recentCounter.ping(3002);  // requests = [1, 100, 3001, 3002], range is [2,3002], return 3

Constraints:

1 <= t <= 109
Each test case will call ping with strictly increasing values of t.
At most 10^4 calls will be made to ping.

Code
class RecentCounter:
    def __init__(self):

    def ping(self, t: int) -> int:

# Your RecentCounter object will be instantiated and called as such:
# obj = RecentCounter()
# param_1 = obj.ping(t)

Link To The LeetCode Problem
LeetCode

Please assign this to me, I would love to solve the problem

Hey I was assigned the problem, please take a look at my solution

#154


[SPARK-30394]Skip DetermineTableStats rule when hive table can be converted to datasource table

What changes were proposed in this pull request?
Currently,  the sizeInBytes of HiveTableRelation will be defaultSizeInBytes(Long.MaxValue) if spark.sql.statistics.fallBackToHdfs not enabled, and there are risks that Long type overflows when we set spark.sql.sources.fileCompressionFactor to a value greater than 1.
https://github.com/apache/spark/blob/cb9fc4bb6ffe542e526a6006582606eb709fb311/sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/HadoopFsRelation.scala#L72
This PR will bring three major improvements:

Skip DetermineTableStats rule when hive table can be converted to datasource table, and compute the stats on demand in HadoopFsRelation. This size estimation can be more accurate for columnar-based files like parquet.
It solves the overflows issue.
It make the code path for sizeEstimation consistent. This will do the estimation on demand just like  what the PruneFileSourcePartitions may do.

Why are the changes needed?
This PR fix potential bugs and bring some other benefits.
Does this PR introduce any user-facing change?
No
How was this patch tested?
UT & test on real clusters

Can one of the admins verify this patch?

Can one of the admins verify this patch?

ok to test

Test build #117764 has started for PR 27055 at commit c5297d4.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/22527/
Test PASSed.

Test build #117764 has finished for PR 27055 at commit c5297d4.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/117764/
Test FAILed.

It solves the overflows issue.

I think the overflow issue is not limited to Hive case here. It sounds like a separate issue.

Yes，I thinks it's a common issue,  we can solve it in a separate PR. I will create another PR for this later


Authentication not working (on premises, multi-context)

Hi there, I'm excited to try out the app!
Unfortunately no authentication method is working for me. I've tried an API client, a local account with the correct permissions, and the admin account.
Useful context could be that I'm trying an on-prem instance which is multi-context, i.e. https://ourserver.com/mycontext. I mention this because sometimes Jamf trip over this type of URL. The instance is Jamf Pro 10.50.
Sure enough, if I use my sandbox cloud instance, the authorisation works.

Hi Graham,
Hold that thought, I can get one spun up. Let me test and get back to you.

Hi Graham
I have identified the problem.
Will test a fix shortly.

Awesome, thanks Richard!
Our instances are hidden inside our network, so I would not have been able to give you access. Thanks for finding another way!

Will close this issue as this has been resolved in 1.0.1


Add striped progressbar

Bootstrap themes have a striped progressbar option; this can be added fairly easily with an image layout.

The image above was created with this simple style prototype which could be added as a new style class called striped.Horizontal.TProgressbar
from PIL import ImageDraw, Image, ImageTk
from tkinter import ttk
from ttkbootstrap import Colors

style = ttk.Style()
style.theme_use('clam')

# light theme colors
colors = Colors(**{
    "primary": "#4582ec",
    "secondary": "#adb5bd",
    "success": "#02b875",
    "info": "#17a2b8",
    "warning": "#f0ad4e",
    "danger": "#d9534f",
    "bg": "#ffffff",
    "fg": "#343a40",
    "selectbg": "#adb5bd",
    "selectfg": "#ffffff",
    "border": "#e5e5e5",
    "inputfg": "#343a40",
    "inputbg": "#f8f9fa"})

# progress bar colors
bar_primary = colors.primary
bar_secondary = Colors.update_hsv(bar_primary, vd=-0.05)

# progressbar image (create large and then resize to create smoother edges)
im = Image.new('RGBA', (100, 100), bar_secondary)
draw = ImageDraw.Draw(im)

# stripe 1
draw.polygon([(0, 0), (48, 0), (100, 52), (100, 100), (100, 100)], fill=bar_primary)

# stripe 2
draw.polygon([(0, 52), (48, 100), (0, 100)], fill=bar_primary)

# resize image and create PhotoImage instance for tkinter
indicator_img = ImageTk.PhotoImage(im.resize((25, 25), Image.LANCZOS))

# setup new style
style.element_create('Horizontal.Progressbar.pbar', 'image', indicator_img, width=25, sticky='ew')

style.layout('Horizontal.TProgressbar', [
    ('Horizontal.Progressbar.trough', {'sticky': 'nswe', 'children': [
        ('Horizontal.Progressbar.pbar', {'side': 'left', 'sticky': 'ns'})]})])

style.configure('Horizontal.TProgressbar', troughcolor=colors.inputbg)

# create progressbar and run program
ttk.Progressbar(orient='horizontal', value=75).pack(fill='x', padx=10, pady=10)
style.master.mainloop()

I added a calculation for the light color on the progressbar stripe. However, I had to add some boundaries when the brightness was above 80% or below 40% as the contrast was either not enough or too much.
# calculate value of light color
brightness = colorsys.rgb_to_hsv(*Colors.hex_to_rgb(bar_primary))[2]
if brightness < 0.4:
    value_delta = 0.3
elif brightness > 0.8:
    value_delta = 0
else:
    value_delta = 0.1
bar_secondary = Colors.update_hsv(bar_primary, sd=-0.2, vd=value_delta)

an example with the yeti theme using progressbar with style='Striped.Horizontal.TProgressbar'

an example with the darkly theme using progressbar with style='Striped.Horizontal.TProgressbar'

demonstration of dark theme style options:

demonstration of light theme style options:


starting up with ndbench

hello
I have limited exposure in data store systems and cloud.
I am planning on evaluating ndbench for a particular usecase. i need help setting ndbench up and get going.
I have following questions to begin with
1. What is minimum count of serverboxes i need to start ? do you have minimum HW configuration requirements?
2. What SW/stack framework do i need to set up? i.e. specific hadoop or cassandra version or other framework?
3. how to install ndbench on my setup, integrate with framework (hadoop/cassandra/etc) and run the benchmark?
4. what kind if score or result ndbech generate and how to interpret it ?
thanks
Ankit

Hello @ankitpateledu

You can use a single server or as many servers as you like.
There are two plugins for Cassandra, one with Thrift (using Astyanax) and one with CQL.
You can do ./gradlew appRun to just run locally or you can deploy the .war in a Tomcat server
You can see the output in the UI.

Since the question seems to have been addressed and there is no further follow-up for some time now, I will close this issue. Please feel free to reopen this or another one if you need any further assistance.


Initial implementation of FungusScript Lua scripting

damn you're going huge with Fungus development!!
i'll try these new features very soon! :)

Cheers Stefano! The Lua integration still needs a bit of polishing up and documentation, but it's working pretty well now.


Do you plan to mention "contributors" in future releases?

I noticed that many of the new features in the latest release are kind of the same there I have made public a few weeks before.  Even though you may have a different, cleaner implementation, the concepts are pretty much the same.
Not  expecting to be paid or a parade :D, but a simple mention  will suffice, otherwise I don't feel to have any motivation to keep sharing the ideas there I'm working on
Off course I know you are working heavily on this framework and this kind of things may slip trough.

by the way, thanks a lot for the new GPU acceleration for desktop!!!

@lisbravo We have a contribution policy for the project. We welcome your contributions to our project based on the contribution policy as well as email feedback on the project. I don't recall getting an email from you to mgyong at google dot com based on our previous exchange on issue 119. A few other users have mentioned in the issue that it would be great to get your code example for showing desktop hand landmarks.  It would be great if you could clean up your code and maybe contribute that as an example to MediaPipe

So, I upload many desktop versions of previous mobile only examples to my fork, which I see you are following, and they coincidentally appear a few weeks latter into a release?
Its ok, I still think this is a good framework

@lisbravo In this case, it is purely coincidental and not related to your desktop versions. We have not actually seen your fork. Could you share you link to the fork? Our desktop examples were planned 2 months ago given that we had quite a few requests for desktop examples


Add a key binding to reset joint positions

This PR add a key binding that resets all joint positions to zero.
Currently "z" is the key to reset joints but I welcome any alternative key for that.

Thanks!


Update build

This PR does a few things:

Uses Golang Modules to install errcheck, protoc-gen-go, and protoc-gen-gofast. This is very simple as of Go 1.11 and allows pinning of versions.
Install protoc from GitHub Releases, instead of relying on a system-wide installation.
Install dep from GitHub Releases, instead of relying on a system-wide installation.
Upgrades golang/protobuf and gogo/protobuf to the latest 1.3.0 and 1.2.1 respectively.
Upgrades stretchr/testify to 1.3.0.
Add a new vendor_update target that calls dep ensure -update using the installed dep.
make vendor_update.
Remove _tools. I know retool is a Twitch project, and this might not feel great, but with Golang Modules (available for two Golang versions now, so this feels OK) it's not needed as much anymore, and this simplifies the build a lot. Note that Twirp itself remains compatible with previous Golang versions, this is just a build concern.
Remove the setup target as it is no longer needed.
make generate to pick up new golang/protobuf and gogo/protobuf changes.
Removes 1.9 and 1.10 from .travis.yml since they will not work with the build anymore.
Updates the documentation to say Go 1.11+.
Sets go_import_path in .travis.yml to make builds work with forks.
Have Travis call make so that CI matches development locally.

With these changes, the build is entirely self-contained now, with no need for system tools other than git, go, curl, make. You could go a step further and install Golang itself as part of the build on a specific version if you wanted to using the same technique in the Makefile as done below.
Note that in the Makefile, it is possible to call errcheck, protoc, etc because the PATH is set in the Makefile. Even if there is a system-wide installation, these take precedence, so the system-wide installation will not be called. This removes the need to do i.e. $(ERRCHECK) and you can instead call errcheck (or more to the point, protoc in your scripts) with no issue.
The .tmp directory is split up by OS/Arch to make this easy to use with Docker.
This is just a suggestion - feel free to reject this diff obviously. I would recommend checking it out and playing with it first if you want to consider merging it.
# not that you would need instructions but just for copy/paste purposes
cd $GOPATH/src/github.com/twitchtv
mv twirp twirp.bk
git clone https://github.com/peter-edge/twirp
cd twirp
git checkout update-build
make

I know the diff is huge due to updating vendor and deleting _tools, these are the two files you'll care most about:
https://github.com/peter-edge/twirp/blob/update-build/Makefile
https://github.com/peter-edge/twirp/blob/update-build/.travis.yml

I updated the build assets to go to .tmp as well - this makes it easy when operating in multiple environments, ie Mac and a Docker container. I addressed the comment as well.

I also removed the compat file targets - these are currently not specified in a way that would result in a rebuild if any of them changed. Since the rebuild of each is so quick, you might as well make it easy and just rebuild them before each test. You could have more complicated Makefile rules to make sure they only get rebuilt if source files change, but you get into complicated territory to save 1-2 seconds, and rebuilding is likely more reliable.

I'm closing this, but the ideas are still useful - thanks a lot, Peter.

Note this does use a local install of the WKT. They’re in a temp include
directory. If for some reason protoc is still going back to system-wide
install, then just include them.
All would be handled with prototool.
On Mon, Mar 11, 2019 at 9:41 AM Spencer Nelson<EMAIL_ADDRESS>wrote:

Closed #153 https://github.com/twitchtv/twirp/pull/153.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/twitchtv/twirp/pull/153#event-2194548314, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AECGvD8s6ysK9s2Zyq8iUW5B9wYlYx_eks5vVodGgaJpZM4bkB5f
.

You are right, of course. I misread the line @rm -rf $(TMP)/include/google/protobuf; it occurs before the archive is unzipped, not after.


Adding progress callback to provide feedback by writing dots . to the…

… command line (#145))

@palemieux I've updated to master and resolve conflicts. Please do a final pass for the review.


Invalid email addresses remain in the address bar

Version: <IP_ADDRESS>5
Repro:
Click create a new mail
Type "blah" into the To field, and press space. The text disappears.
Type a valid email address<EMAIL_ADDRESS>into the field, and complete your message, click on send.
Expected:
The email be sent to<EMAIL_ADDRESS>address only
Actual:
The email has "blah<EMAIL_ADDRESS>in the To field.
This causes a send error (on my mail config at least), and the email is NOT sent.
Oct  8 10:08:54 mail postfix/submission/smtpd[12725]: warning: Illegal address syntax from localhost[::1] in RCPT command<EMAIL_ADDRESS>

It works correctly for me in the latest version is <IP_ADDRESS>3.

I will give it a try when I have some time to do the upgrade.

Is the versioning semantic?

Is the versioning semantic?

I dunno.

Confirmed fixed.


Refactoring

What?
I created a calculator UI using react.
Why?
So I can use it to create a Single Page App.
How?

I installed create-react-app globally on my local machine
I navigated to the folder in which I wanted to create the app on my local machine and used create-react-app maths-magician command to create the folder locally.
I then installed linters.
I pushed my code to a "Maths-Magician"repo I initially created.
I created a components folder in the src folder.
I created a calculator.js file in the components folder.
I created the calculator UI using a function.
I created the UI with the mobile first approach.
I export the calculator from the Calculator.js and imported it into App.js
I created a logic directory inside the src directory
I created two files, calculate.js and operate.js inside the logic folder.
I copied and pasted their respective files from Microverse course requirement.
I installed Big
I imported calculate into the calculator.js
I declared properties inside the class
I wrote an onClick function to handle events.
I added the onClick to every button.
Refactored the calculator.js and App.js modules to functions
Change the value when 'AC' button is clicked from null to 0.

@mmsesay Thank you for reviewing my project.


A template for usage with the web component instead of icon font requires some changes

Hi Atisa,
First of all, thank you very much for your contribution of boxicons to the world !
It is very useful indeed.
Secondly, some minor changes are required in the boxicons.js file to make it work.
Please check the revised file here : https://raw.githubusercontent.com/linuxguist/boxicons/main/boxicons-iv.js
in this file, the variable n is substituted 3 times, with my repository's location ( i.e. linuxguist ) and your web component template works well now. As my repository is just meant for one time testing, please revise your .js file too, similarly, to point to unpkg.com
Also, revise the example template like below:
<!doctype html>

<meta charset='utf-8'>
<meta name='viewport' content='width=device-width, initial-scale=1, shrink-to-fit=no'>

<title>Hello, Boxicons!</title>

Hello, Boxicons!

<box-icon name='hot'></box-icon>
<box-icon type='solid' name='hot'></box-icon>
<box-icon type='logo' name='facebook-square'></box-icon>

Thanks and Best Regards,
Nathan S.R.

Thanks , i will check it out


Conflicting category slugs

When different authors create category with same name they conflict with each other. Make category slug unique by adding counter or use author/category combination.

or maybe we should share the category for all authors.
If someone creates a category we could show that for everyone. if they are writing on the same blog, so then it's not good to have multiple categories but the same category content. then visitors will be confused.

The categories completely reworked and now belong to authors rather than been shared. So whenever you click on category it brings you to author's page and category identified by both author and category slugs, so there should be no conflicts.


New Emulator not sending recipient info

Version 3.5.20 message structure:
from 'user':
{
  "type": "message",
  "text": "hi",
  "from": {
    "id": "default-user",
    "name": "User"
  },
  "timestamp": "2016-11-23T05:35:19.425Z",
  "channelData": {
    "clientActivityId": "1479879313312.7115656006164095.0"
  },
  "serviceUrl": "https://b7eb894d.ngrok.io",
  "id": "511ggghn8i2kann73",
  "channelId": "emulator",
  "recipient": {
    "id": "l3iemcdml1ghd784l"
  },
  "conversation": {
    "id": "b9c9mgcl0jacihcjgc"
  }
}

reply from 'bot':
{
  "type": "message",
  "timestamp": "2016-11-23T05:35:25.570Z",
  "serviceUrl": "https://b7eb894d.ngrok.io",
  "channelId": "emulator",
  "from": {
    "id": "l3iemcdml1ghd784l",
    "name": "Bot"
  },
  "conversation": {
    "id": "b9c9mgcl0jacihcjgc"
  },
  "recipient": {
    "id": ""
  },
  "text": "Please note that by using this chat bot you are agreeing to our terms and conditions. [Ts&Cs](https://nedgroupinvestments.co.za/terms-and-conditions)",
  "attachments": [],
  "entities": [],
  "replyToId": "511ggghn8i2kann73",
  "id": "1nljk346n041j88l4c"
}

compared with version <IP_ADDRESS>:
from 'user':
{
  "type": "message",
  "id": "29a999a3b2e84bb8b84193141f6e2923",
  "timestamp": "2016-11-23T05:37:42.9156081Z",
  "serviceUrl": "http://localhost:9000/",
  "channelId": "emulator",
  "from": {
    "id": "2c1c7fa3",
    "name": "User1"
  },
  "conversation": {
    "isGroup": false,
    "id": "8a684db8",
    "name": "Conv1"
  },
  "recipient": {
    "id": "56800324",
    "name": "Bot1"
  },
  "text": "heyy",
  "attachments": [],
  "entities": []
}

from 'bot':
{
  "type": "message",
  "timestamp": "2016-11-23T05:37:48.1789651Z",
  "serviceUrl": "http://localhost:9000/",
  "channelId": "emulator",
  "from": {
    "id": "56800324",
    "name": "Bot1"
  },
  "conversation": {
    "isGroup": false,
    "id": "8a684db8",
    "name": "Conv1"
  },
  "recipient": {
    "id": "2c1c7fa3",
    "name": "User1"
  },
  "text": "Please note that by using this chat bot you are agreeing to our terms and conditions. [Ts&Cs](https://nedgroupinvestments.co.za/terms-and-conditions)",
  "attachments": [],
  "entities": [],
  "replyToId": "29a999a3b2e84bb8b84193141f6e2923"
}

Spot the difference right? There's no recipient name anymore?

@JPThorne We've made an interim fix for this and now send the recipient's id. A more complete fix will be made soon, which will enable sending of name and id of recipients. A new emulator build should be going out later today.


synthesized comparable for enums

WIP: Implementation for Synthesized Comparable conformance for simple enum types.

@swift-ci please smoke test

note: i’ve fixed the merge conflicts to the point where it’s compiling again but it crashes at run time, so the update isn’t really ready yet

@DougGregor hi, i’ve pushed changes that fixed the crasher, added support for enums with associated values, and updated the tests

@swift-ci please smoke test

@swift-ci please test source compatibility

@kelvin13 looks like we changed something on master that broke this:
/Users/buildnode/jenkins/workspace/swift-PR-osx-smoke-test/branch-master/swift/lib/Sema/DerivedConformanceComparable.cpp:375:21: error: no member named 'setGenericEnvironment' in 'swift::FuncDecl'
15:28:09     comparableDecl->setGenericEnvironment(genericEnv);
15:28:09     ~~~~~~~~~~~~~~  ^
15:28:09 1 error generated.

can we try this again

@swift-ci please smoke test

@swift-ci please test source compatibility

@kelvin13 Can you fix the conflicts? I'll poke CI again.

Thanks, @kelvin13!
@swift-ci please smoke test

@swift-ci please test source compatibility

@swift-ci please smoke test Linux

@swift-ci please test source compatibility

Test failures were unrelated.

new version should be passing the test

@swift-ci please smoke test

@swift-ci please test source compatibility

@swift-ci please test source compatibility debug

this is all green on the checks, can we merge?

@douggregor good to merge?

@DougGregor ping

@DougGregor pong

Should enums such as Never and NoCases be supported?

@benrimmington Never already conforms to Comparable

@kelvin13 Please may it be tested in this pull request?

stdlib/public/core/Policy.swift
-extension Never: Comparable {
-  public static func < (lhs: Never, rhs: Never) -> Bool {
-  }
-}
+extension Never: Comparable {}

test/Sema/enum_conformance_synthesis.swift
 // An enum with no cases should also derive conformance.
-enum NoCases: Hashable {}
+enum NoCases: Hashable, Comparable {}

@swift-ci please test

@swift-ci please test source compatibility

Build failed
Swift Test Linux Platform
Git Sha - 37edea60bedda0559aa400003d6a745e3bddaba2

Build failed
Swift Test OS X Platform
Git Sha - 37edea60bedda0559aa400003d6a745e3bddaba2

20:03:54 + export head_ghprbActualCommit=ed2552a6946a27483f7a8fa3561a626991d63e05
20:03:54 + head_ghprbActualCommit=ed2552a6946a27483f7a8fa3561a626991d63e05
20:03:54 + '[' 37edea60bedda0559aa400003d6a745e3bddaba2 == ed2552a6946a27483f7a8fa3561a626991d63e05 ']'
20:03:54 + echo 'Wrong sha 37edea60bedda0559aa400003d6a745e3bddaba2'
20:03:54 Wrong sha 37edea60bedda0559aa400003d6a745e3bddaba2
20:03:54 + echo ghprbActualCommit=ed2552a6946a27483f7a8fa3561a626991d63e05
20:03:54 + echo '--- Automatically restarting the build, due to invalid sha ---'

?

@harlanhaskins this is passing on my machine, can we run this again?

@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - ed2552a6946a27483f7a8fa3561a626991d63e05

Build failed
Swift Test Linux Platform
Git Sha - ed2552a6946a27483f7a8fa3561a626991d63e05

is this a CI problem? it looks like the build is not even starting up properly

It does that occasionally. The next build will succeed.

Do you need to test source compatibility again?

everything’s green, @DougGregor can we merge? this pr is v prone to merge conflicts because it factors out a few common functions from DerivedConformanceEquatableHashable.cpp into a separate file

@benrimmington yes, i don’t have permissions for the CI though

@swift-ci please test source compatibility

ping

Alright, the AST synthesis looks fine for now.
Please also update Interpreter/synthesized_extension_conformances.swift and add a test to test/Sema/enum_conformance_synthesis.swift that involves an extension.

done

@swift-ci please test

@swift-ci please test source compatibility

Build failed
Swift Test Linux Platform
Git Sha - d71b3dfec887de32f41f931e5af7a96cde49364a

Build failed
Swift Test OS X Platform
Git Sha - d71b3dfec887de32f41f931e5af7a96cde49364a

the error seems real, but it’s not happening when I run the build on my machine? any idea what’s going on? this is the invocation i’m using:
swift/utils/build-script --release-debuginfo -t

the error seems real, but it’s not happening when I run the build on my machine?

Are you testing locally on Linux? It // REQUIRES: objc_interop for some reason.

@benrimmington yes

Try an release-asserts build.

It looks like the test failure on macOS can be fixed with:
-struct SInt: Codable, Equatable, Hashable {
+struct SInt: Codable, Equatable, Hashable, Comparable {

You could also try removing the // REQUIRES: objc_interop and see if the tests pass on Linux.

@benrimmington that doesn’t work, it fails to import Foundation
swift/test/Interpreter/synthesized_extension_conformances.swift:8:8: error: no such module 'Foundation'
import Foundation

adding --assert doesn’t seem to do anything different either

It looks like the test failure on macOS can be fixed with:
-struct SInt: Codable, Equatable, Hashable {
+struct SInt: Codable, Equatable, Hashable, Comparable {

You could also try removing the // REQUIRES: objc_interop and see if the tests pass on Linux.

Comparable can’t be synthesized on structs, only enums

Comparable can’t be synthesized on structs, only enums

That is true, but that's not what the error is about. The error is saying that SInt doesn't conform to Comparable. The extension you added to EGeneric requires its generic parameter to be Comparable:

extension EGeneric: Comparable where T: Comparable {}

In your test function, you're using EGeneric<SInt> but the compiler is unable to synthesise Comparable conformance for EGeneric because SInt doesn't conform to Comparable.

You should be able to test on Linux by changing:
-// REQUIRES: objc_interop
+// REQUIRES: foundation

For example, this is also used in:

test/Sanitizers/tsan-emptyarraystorage.swift
test/Runtime/lazy_witness_table_cycle.swift
test/stdlib/StdlibUnittestOverrelease.swift
test/stdlib/DispatchDate.swift

Then the test failure can be fixed by adding:
extension SInt: Comparable {
  static func < (_ lhs: Self, _ rhs: Self) -> Bool {
    return lhs.x < rhs.x
  }
}

This passed on macOS when I tried it.
To re-run a single test, you can use the following (with the build path adjusted for Linux):
llvm-project/llvm/utils/lit/lit.py --show-all build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/test-macosx-x86_64/Interpreter/synthesized_extension_conformances.swift

i couldn’t get Foundation to build (part of the compiler needs libssl1.0-dev and another part seems to need libcurl4-openssl-dev and they conflict with each other)
could someone trigger the ci?

@kelvin13 Can you go ahead and resolve these new conflicts? I'll kick CI after

@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - 178b0ff4d9cb12a3f85b6b2645189af670d49df9

Build failed
Swift Test Linux Platform
Git Sha - 178b0ff4d9cb12a3f85b6b2645189af670d49df9

@swift-ci please test source compatibility

@CodaFi ping

⛵

@kelvin13 do you mind adding this to the changelog?

@theblixguy #29782


Error Installing BoringSSL-GRPC

What version of gRPC and what language are you using?
Trying to install BoringSSL-GRPC (0.0.3) via terminal on Mac OS Catalina 10.15.2
What operating system (Linux, Windows,...) and version?
Mac OS Catalina 10.15.2
What runtime / compiler are you using (e.g. python version or version of gcc)
Xcode Environment
What did you do?
If possible, provide a recipe for reproducing the error. Try being specific and include code snippets if helpful.
Added pod 'Firebase/Firestore' to the PodFile and ran 'pod install'
What did you expect to see?
Pods installed successfully
What did you see instead?
Installing BoringSSL-GRPC (0.0.2)
[!] Error installing BoringSSL-GRPC
[!] /usr/bin/git clone https://github.com/google/boringssl.git /var/folders/k3/8phztphs11d0hbtshqcxx9hr0000gn/T/d20190226-73853-1azgtd4 --template=
Cloning into '/var/folders/k3/8phztphs11d0hbtshqcxx9hr0000gn/T/d20190226-73853-1azgtd4'...
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
This also takes forever to show this error more than an hour and a half
Make sure you include information that can help us debug (full error message, exception listing, stack trace, logs).
See TROUBLESHOOTING.md for how to diagnose problems better.
Anything else we should know about your project / environment?

@AbScott1985 did you managed to find a solution for it ?

Yes there was a block on my internet so I tried a vpn and it worked so went on the my network and took off the security on my network
Sent from my iPhone

On 20 Mar 2020, at 12:50, adarsh raj<EMAIL_ADDRESS>wrote:

@AbScott1985 did you managed to find a solution for it ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Thanks, @AbScott1985 I just figured it out by switching the network, not sure what was issue with network probably something to do with pandemic traffic.

I was so annoyed I had changed a lot of my settings and messed around with it so much for it to not be an issue with the app was so angry but at least it is sorted now and I will be checking that first from now on lol glad its sorted x

This fixed the problem for me
in the project directory using terminal
rm -rf Pods

rm Podfile.lock

pod install

Connecting to my VPN solved it, too. Weird.

same here, Any solutions?

Compiling with/without your VPN does not make sense for that solution. Most likely just Pods using cache previously installed with later versions. BoringSSL is a heavily used packaged throughout different packages.
Also, the comment about "Pandemic Traffic" is hilarious.. :P

@joshua-hester can you elaborate about that please?

Refer to: https://github.com/firebase/firebase-ios-sdk/issues/4994#issuecomment-592763815

Brand new laptop, fresh environment, still struggling with this problem.

Hi,
I managed to resolve this. You need to open the PodFile under your Xcode prroject and do the following...
Remove Firebase/Firestore pods from the PodFile and save the PodFile.
Make sure Xcode is closed.
Open Terminal and cd to your Xcode project directory.
Run 'pod install'
After that you add the fireStore then its worked for me
Add pod 'Firebase/Auth' and pod 'Firebase/Firestore' to your PodFile and save the PodFile.
Run 'pod install'

Although this was closed a while back, it seems that there is still an issue. Yulin, can you take a look at this?

Although this was closed a while back, it seems that there is still an issue. Yulin, can you take a look at this?

Sure, I'll take a look at it.

Brand new laptop, fresh environment, still struggling with this problem.

Have you fixed it? If not, have you tried the solution that bongzlive@ mentioned above?

Hi facing the same issue while adding 'pod 'Firebase/Firestore'.
Any working solution?
Thanks

Hi facing the same issue while adding 'pod 'Firebase/Firestore'.
Any working solution?
@yulin-liang , Have you got any workaround?
Thanks

Have you tried the solution bongzlive@ mentioned above?

Remove ALL Firebase pods from the PodFile and save the PodFile.
Make sure Xcode is closed.
Open Terminal and cd to your Xcode project directory.
Run 'pod install'
Add pod 'Firebase/Auth' and pod 'Firebase/Firestore' to your PodFile and save the PodFile.
Run 'pod install'.

So I have this issue...is there any resolution on the horizon?

To give some context to this...I am using a brand new MacBook on Catalina and I am using Xcode 12.0.1. I can build an iOS app with the basic flutter counter app and this displays in the iPhone simulator as expected.  However, I have another app that runs fine on Android on Windows but I can't get past this error on macOS.
This morning I went to the effort of removing anything Firebase related out of my pubspec and deleted pods with the commands suggested above. However, this produced the same error.

I have now isolated this issue in my case where I am using flutter. Removing the dependency cloud_firestore, allows me to successfully pod install. However, this dependency is required in my app and every time I add it back in - I get the above error.

To add even further context, it turns out the precise command that is failing is git clone https://github.com/CocoaPods/Specs.git, which is hanging up unexpectedly. See https://github.com/flutter/flutter/issues/30185 where they refer to this.
Only way I am going to resolve this is finding a way to pull from this repo without it hanging up. Thought I would post this update as it confirms issue is not with BoringSSL itself, but during pod install when the above repo is cloned.

-> Installing BoringSSL-GRPC (0.0.7)

Git download
Git download
$ /usr/bin/git clone https://github.com/google/boringssl.git /var/folders/5y/kz_7kysj73z8jtb1xzc0skmr0000gp/T/d20200928-1463-1g58de
--template=
Cloning into '/var/folders/5y/kz_7kysj73z8jtb1xzc0skmr0000gp/T/d20200928-1463-1g58de'...
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

[!] Error installing BoringSSL-GRPC
[!] /usr/bin/git clone https://github.com/google/boringssl.git /var/folders/5y/kz_7kysj73z8jtb1xzc0skmr0000gp/T/d20200928-1463-1g58de --template=
Cloning into '/var/folders/5y/kz_7kysj73z8jtb1xzc0skmr0000gp/T/d20200928-1463-1g58de'...
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

My current internet connection is 110 Mbps, so no issues there

@lemusthelroy Thanks for the information, can you try to remove ios/Flutter/Flutter.framework, ios/Pods, and Podfile.lock before running pod install?

Same error unfortunately 😭

@lemusthelroy Can you create a simple demo that I can reproduce the issue?

For me to get the issue all I have to do is the following:-

flutter create demoApp
Add cloud_firestore as a dependency in pubspec.yaml
flutter run

@lemusthelroy I tried to add cloud_firestore: ^0.12.9+5 in the pubspec.yaml and ran pod install in iOS/ directory, I can install it successfully. What's the version of your flutter? Can you also paste your dependencies?

Flutter 1.20.4 • channel stable • https://github.com/flutter/flutter.git
Framework • revision fba99f6cf9 (2 weeks ago) • 2020-09-14 15:32:52 -0700
Engine • revision d1bc06f032
Tools • Dart 2.9.2

name: boringSSLBug
description: A new Flutter project.
publish_to: 'none'
https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html
version: 1.0.0+1
environment:
sdk: ">=2.7.0 <3.0.0"
dependencies:
flutter:
sdk: flutter
cloud_firestore:
cupertino_icons: ^0.1.3
dev_dependencies:
flutter_test:
sdk: flutter
flutter:
uses-material-design: true

@lemusthelroy It looks like an git internet connection issue, you can take a look at this post, https://stackoverflow.com/questions/38618885/error-rpc-failed-curl-transfer-closed-with-outstanding-read-data-remaining.
I also found a similar issue in Cocoapods repo. Can you try to increase buffer size? Hope it can work.
git config --global http.postBuffer 524288000

Yeah I've seen that suggestion before. Tried it again and still the same issue 😢 I'm pretty new to developing on iOS but had enjoyed Flutter on Windows over the last year, just a shame I can't any of my apps on iOS atm.

So on a hunch, I ran 'flutter run' on a hotspot and it worked just fine. For all others that may hit the same issue, I am in the UK and using Virgin Media. I had to log into Virgin Media website, (not to the router), and disable Child Safe.

This seems like an internet connection issue and not much we can do. For those who may ran into the same issue, please try to do the following first:
Remove Firebase/Firestore pods from the PodFile and save the PodFile.
Make sure Xcode is closed.
Open Terminal and cd to your Xcode project directory.
Run 'pod install'
After that you add the fireStore then its worked for me
Add pod 'Firebase/Auth' and pod 'Firebase/Firestore' to your PodFile and save the PodFile.
Run 'pod install'

If it doesn't work for you, you may need to switch to another network or check your network configuration.

This is hard to believe. I root caused this issue to a wired ethernet adapter I was using. wifi and two other wired ethernet adapters worked.
Note that ethernet adapter seemed to work fine otherwise. The git clone worked fine from the command line, the issue only surfaced when ruby Process.spawn executed it!

This is hard to believe. I root caused this issue to a wired ethernet adapter I was using. wifi and two other wired ethernet adapters worked.
Note that ethernet adapter seemed to work fine otherwise. The git clone worked fine from the command line, the issue only surfaced when ruby Process.spawn executed it!

@vharron Unbelievable! I've read your post and I've tried to unplug my network adapter and update all the pods with wifi connection. It greatly works! It fixed my issue. You saved me. Thank you. My network adapter is: Atolla wired sub/ethernet apple adapter. I will buy an original adapter 👍

For Flutter developers:
change all firebase dependencies I use to this versions solve my problem
 firebase_messaging: ^10.0.2
 firebase_auth: ^1.4.1
 cloud_firestore: ^2.2.1
 firebase_storage: ^8.1.3
 firebase_core: ^1.3.0

I fix by add
pod 'FirebaseFirestore', :git => 'https://github.com/invertase/firestore-ios-sdk-frameworks.git', :tag => '8.8.0'
or
pod 'FirebaseFirestore', :git => 'https://github.com/invertase/firestore-ios-sdk-frameworks.git', :tag => '8.6.0'
in ios/Podfile
Example:
target 'Runner' do
  use_frameworks!
  use_modular_headers!

  pod 'FirebaseFirestore', :git => 'https://github.com/invertase/firestore-ios-sdk-frameworks.git', :tag => '8.8.0'
  pod 'Firebase/Core'

  flutter_install_all_ios_pods File.dirname(File.realpath(__FILE__))
end

to solve this delete podfile and podfile.lock then run (flutter pub get) then in terminal run  (cd ios)  then run (pod install).

This is hard to believe. I root caused this issue to a wired ethernet adapter I was using. wifi and two other wired ethernet adapters worked.
Note that ethernet adapter seemed to work fine otherwise. The git clone worked fine from the command line, the issue only surfaced when ruby Process.spawn executed it!

@vharron Unbelievable! I've read your post and I've tried to unplug my network adapter and update all the pods with wifi connection. It greatly works! It fixed my issue. You saved me. Thank you. My network adapter is: Atolla wired sub/ethernet apple adapter. I will buy an original adapter 👍

This actually resolved the issue for me

Using a VPN worked for me
stackoverflow

I have tried many different solution but this fixed my problem.
target 'Runner' do
  use_frameworks!
  use_modular_headers!
  pod 'FirebaseFirestore/WithLeveldb', :git => 'https://github.com/invertase/firestore-ios-sdk-frameworks.git', :tag => '10.9.0'
  flutter_install_all_ios_pods File.dirname(File.realpath(__FILE__))
end

For flutter, I fixed mine using git config --global http.postBuffer<PHONE_NUMBER> to  increase the postBuffer size in my git configuration. This helps with issues related to large files in the repository. Then cd ios && rm -rf Pods && rm Podfile.lock && gem install cocoapods && pod install

For flutter, I fixed mine using git config --global http.postBuffer<PHONE_NUMBER> to increase the postBuffer size in my git configuration. This helps with issues related to large files in the repository. Then cd ios && rm -rf Pods && rm Podfile.lock && gem install cocoapods && pod install

This did not fix the issue. I still get the error in react native version 0.73.0

git config --global http.postBuffer 524288000
for me its working by running this command, after running this command inside iOS folder of flutter project I run ### pod install command and all working fine

@lemusthelroy It looks like an git internet connection issue, you can take a look at this post, https://stackoverflow.com/questions/38618885/error-rpc-failed-curl-transfer-closed-with-outstanding-read-data-remaining. I also found a similar issue in Cocoapods repo. Can you try to increase buffer size? Hope it can work.
git config --global http.postBuffer 524288000

that's working for me, thanks

git config --global http.postBuffer 524288000
solved using this

changing the network worked for me

this is solution
pod update

just provide any progress bar or size of file, there is noting what the hell? Very disappointed. I have tried more than 50 times but not know what's size evey time got error after 200mb of internet used.
[!] Error installing BoringSSL-GRPC
[!] /usr/local/bin/git clone https://github.com/google/boringssl.git /var/folders/yw/bfsq8qr95qs8x5gws3_jt4vm0000gn/T/d20240710-3521-tmnryv --template=
Cloning into '/var/folders/yw/bfsq8qr95qs8x5gws3_jt4vm0000gn/T/d20240710-3521-tmnryv'...
error: RPC failed; curl 92 HTTP/2 stream 3 was not closed cleanly: CANCEL (err 8)
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Here's a revised version of your documentation that omits the specific real path of the project while still guiding users through the process:

Step 1: Clone BoringSSL Manually

Open Terminal.

Navigate to a directory where you want to clone BoringSSL (e.g., ~/Documents):
cd ~/Documents

Clone the repository:
git clone https://github.com/google/boringssl.git

Step 2: Specify the Local Path in Your Podfile

Open your Podfile in your Flutter project's ios directory. You can use a text editor like nano, vim, or any graphical text editor:
cd ios
nano Podfile

Locate the line for BoringSSL-GRPC and modify it to specify the local path. Replace the existing line with:
pod 'BoringSSL-GRPC', :path => '../Documents/boringssl'

Adjust the path based on where you cloned BoringSSL relative to your Podfile.

Step 3: Create the Podspec File
If you encounter an error indicating that CocoaPods couldn't find a .podspec file for BoringSSL-GRPC, follow these steps:

Navigate to the BoringSSL directory:
cd ../boringssl

Create a new file named BoringSSL-GRPC.podspec:
nano BoringSSL-GRPC.podspec

Copy and paste the following content into the BoringSSL-GRPC.podspec file:
Pod::Spec.new do |s|
  s.name         = 'BoringSSL-GRPC'
  s.version      = '0.0.32'  # Update this line if necessary
  s.summary      = 'BoringSSL forked from OpenSSL.'
  s.description  = <<-DESC
    BoringSSL is a fork of OpenSSL that is designed to meet the needs of Google and its users.
    It is a C library that provides cryptographic operations.
  DESC
  s.homepage     = 'https://boringssl.googlesource.com/boringssl'
  s.license      = { :file => 'LICENSE' }
  s.author       = { 'Google' => 'https://www.google.com/' }
  s.source       = { :git => 'https://boringssl.googlesource.com/boringssl.git', :tag => s.version.to_s }
  s.platform     = :ios, '9.0'
  s.source_files  = 'include/**', 'crypto/**', 'ssl/**'
end

Save and close the file.

Step 4: Clean and Re-Install Pods
To ensure everything is in sync, follow these steps:

Clean the Pod Cache:
pod cache clean --all

Delete the Pods folder and Podfile.lock:
rm -rf Pods Podfile.lock

Re-Install Pods:
pod install

Feel free to adjust any part of this documentation as needed!

`[!] Error installing BoringSSL-GRPC
[!] /opt/homebrew/bin/git clone https://github.com/google/boringssl.git /var/folders/6v/fc5vp06x6zx9h6ydjr9pgm7c0000gq/T/d20241008-28534-pcd4la --template=
Cloning into '/var/folders/6v/fc5vp06x6zx9h6ydjr9pgm7c0000gq/T/d20241008-28534-pcd4la'...
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
error: 5547 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output`
By this error up, I solved it as this:
git config --global http.lowSpeedTime 999999

git config --global http.postBuffer 524288000
for me its working by running this command, after running this command inside iOS folder of flutter project I run ### pod install command and all working fine

Worked for me thx


Add launch instructions to readme

Feedback from @yijiangh:

Give detailed launch instructions in your readme or tutorials instruction file.

Probably a lot of the info now in the readme should move to the tutorial page on the ROS wiki.


whole system freezes after running an infinite loop in Ruby on VS Code, using Ubuntu 18.04

After accidentally creating an endless loop in Ruby in VS Code(version 1.30.2) and running it, I have this issue where my whole Ubuntu system will freeze up, forcing me to restart computer.  After running the loop, I will kill the terminal, and a few seconds to a few minutes later, the system will very often hang up to the point of not being able to do anything, not even moving the cursor works.  This has happened to me at least a half a dozen times in the past couple weeks.

I believe this will get fixed when we pull in https://github.com/xtermjs/xterm.js/pull/1818

I made an infinite loop in Ruby:
while true
    puts("looping")
end

And ran it in the integrated terminal: ruby rubytest.rb
I haven't been able to reproduce the original issue in stable. Are there other verification steps?

@alexr00 the issue was a result of the time to pull in data from the pty and render a frame in the terminal taking too long for the renderer to keep up. It should be much more difficult to run into this problem now on slow hardware as data parsing time is capped at ~12ms where as before it was essentially unbounded. If that worked then I'd call this verified.


Update Part-0.md

Update path to ReactMount.js.
Remove line number (because code may changed and line number is no longer pointed to correct source code line number)

My fault. I have compared files with master branch.

@roya3000, no worries, thanks for trying to help. Yes, there is an exact version which was used, so, it will always match to it.


[WIP] now passing additionalTrustBundle to capx

Issue #, if available:
Description of changes:
ref:

https://github.com/nutanix-cloud-native/cluster-api-provider-nutanix/pull/171
https://github.com/nutanix-cloud-native/cluster-api-provider-nutanix/pull/180

Testing (if applicable):
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/hold

/ok-to-test

/unhold


Where is homekit code??

Hi all,
Have followed instructions and have api code etc, however am stuck on getting my homekit code - can't see it anywhere on the gardena hub or my smart watering system. Can't see it in the app either - anyone able to offer any pointers here??

Try the Gardena app under settings -> Homekit. The code should be there.

I run app version 3.1.093 and have another line between Alexa and IFTT.
Can you update your app? Are you on an outdated OS that prevent you from seeing newer app-releases perhaps?

Ah, your response twigged me - the app is OS dependent (was using latest Android on my Pixel and also tried through browser) - installed through iPhone and the homekit option appears!
Only thing now I get is an error saying: The device is already pairing with another controller
Tried restarting the Gardena hub, Home Assistant and also tried reinstalling the HACS component, but error still remains. Definitely was working previously as got homekit prompt - any clues as to how to resolve this error?

Ah, scratch that - apple obviously persist a session or something when using their app. Quitting app completely seemed to fix! All working now!

Great!
And no surprise really that HomeKit (Apple feature) isn’t available on an Android device ;)
I thought you were using an iPhone :)

I know... long day..... ;)


feat(Function): Fixed points of function f with f(x) >= x

We added some lemmas of fixed points of function f with f(x) >= x, where f : α → α is a function on a finite type α. This will be needed in proof of Bondy-Chvátal theorem.

See also branch meow-sister/BondyChvatal.

@b-mehta and I discussed this PR and we basically think the right setup is Scott continuity, rather than what you currently have.

This looks almost identical to the setup for normal ordinal functions! Specifically, any normal function satisfies x ≤ f x, and for any a, the supremum of f^[n] a is a fixed point of f. We have this as Ordinal.nfp.
I don't know anything about Scott continuity, but if there's anything that can be done to merge our results together, I'd be glad to learn.

I suggest you read Order.OmegaCompletePartialOrder. It's very instructive!


Fixes Inf.Duration = 0 returning error message.

Fixes bug where Inf.Duration and StarPoint.TimeOffset couldn't be set to 0.
According to HLS specs these values are allowed for both attributes and shouldn't return an error.

LGTM


Bug: Spoiler markdown rendering when hidden

Describe the bug
Using lists, either with hyphens or numbers, show through the spoiler-markdown window.
To Reproduce
Use this in a note as an example:
## Heading

**Xaelith’s Role**:
1. This is a number.
2. This is the second.

- This is a bullet
- This is another

Expected behavior
All (supported) markdown content should be hidden behind the spoiler window.
Screenshots

Additional context
I'm on the latest version of the plugin and of Obsidian on Windows 11.. This issue also occurs on my iPad with the same markdown.

Fixed in 1.0.4


Bedig solution

Comfort-1
Completeness-4
I am not comfortable with javascript in the slightest.  This took many hours of googling and asking for help.  I'm going to try and devote more time to javascript because I feel I am so weak.

Your code was actually very very close to working fine. You had a few bugs.
Take a look at my changes for:

var colorSelected in function colorChange()
var colorSelected in function onClick() (also I would rename this function to something more semantic like paintSquare())

Other than that everything else looks good. Keep up the good work. 👍

///creat the variable button, and name it, this is my target//
//commit 1&2//
var colorButton = $('button')

function colorChange(event){
  event.preventDefault();
  var colorSelected = $('#color-field').val();
  $('.brush').css('background',colorSelected)
}

colorButton.on('click',colorChange)
//commit 3//

function addDiv(){
  for (var i=0; i<8000; i++) {
    var div = document.createElement('div')
    div.className = 'square'
    $('body').append(div);
    //add function to click to change square.
    $('.square').on('mouseover',onClick)
  }
}
addDiv(8000);
//commit 4/5//
function onClick(){
  var colorSelected = $('.brush').css('background');
  $(this).css('background', colorSelected)
};


Support local vitualenv instalations

Instead of installing virtual envs to $VIRTUALFISH_HOME, allow them to be installed locally.
Something like node_modules directory, but for python stuff.
$ vf activate ./env    # Activates local "env" dir
$ vf activate some-env # Activates "some-env" installed at $VIRTUALFISH_HOME

Hi,
Thanks for your suggestion!
My inclination is to not implement this, since it's easy enough to do this without virtualfish at all:
$ virtualenv -ppython3.6 env
$ . env/bin/activate.fish
(env) $ which python
/Users/adam/temp/env/bin/python
(env) $ deactivate
$ which python
/usr/local/bin/python

Most virtualfish commands that operate on an active virtualenv (e.g. vf cdpackages) will work just fine while a virtualenv is activated in this way, since they look at the value of $VIRTUAL_ENV which activate.fish also sets. Ditto with your $PROMPT: just do set -g VIRTUAL_ENV_DISABLE_PROMPT 1 in your config.fish to disable activate.fish's fish_prompt mangling, and your prompt will work as you expect.

You're right, but there's one thing that is missing: virtualenv auto activation.
A simply loved this feature, and can't use it with local env installations.

The problem with that is, right now virtualfish makes the (reasonable) assumption that anything inside VIRTUALFISH_HOME is a virtualenv. If we were doing auto-activation on cwd-relative virtualenvs, we'd have to introduce a bunch of heuristics to check whether or not a env (or whatever) subdirectory of the cwd is actually a virtualenv, and not some other directory that just happens to be called that.
Also, then we'd be automatically executing files relative to your cwd, which has security implications for much the same reasons as adding . to your PATH is generally considered a bad idea.


Kia EV6: get VIN without OBD port

0x7c6 may be the cluster ECU, and knows the VIN. It's accessible on the EV6 HDA2 from the camera, but isn't on a GV80 (requires OBD port)
I wasn't able to find this, because query_fw_versions.py skips if any of the three queries it does time out, which this ECU does to the extended diagnostic query.
*** Results for address 0x7C6 ***

0xF100 IDENTIFICATION_OPTION_VEHICLE_MANUFACTURER_SPECIFIC_DATA_IDENTIFIER: b'133'
0xF18C ECU_SERIAL_NUMBER: b'REDACTED'
0xF190 VIN: b'KNDC44LA2XXXXXXXX'
0xF191 VEHICLE_MANUFACTURER_ECU_HARDWARE_NUMBER: b'0100'
0xF193 SYSTEM_SUPPLIER_ECU_HARDWARE_VERSION_NUMBER: b'0100'
0xF195 SYSTEM_SUPPLIER_ECU_SOFTWARE_VERSION_NUMBER: b'0408'
0xF1A1 IDENTIFICATION_OPTION_VEHICLE_MANUFACTURER_SPECIFIC: b'P068'
0xF1B0 IDENTIFICATION_OPTION_VEHICLE_MANUFACTURER_SPECIFIC: b'\x02'
0xF1B2 IDENTIFICATION_OPTION_VEHICLE_MANUFACTURER_SPECIFIC: b'0044'

[ ] Need to support multiplexing in get_vin.py, EV6's ECAN/main PT bus is bus 1, non-OBD multiplexed

I consider https://github.com/commaai/openpilot/pull/31348 enough to close this issue, just wanted to write some context.


New Version: Sigil-Ebook.PageEdit version 2.3.1

Checklist for Pull Requests

[x] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Manifests

[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.6 schema?

Note: <path> is the directory's name containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Automatic Validation ended with:

Executable C:\Users\validator\AppData\Local\Programs\PageEdit\PageEdit.exe returned exit code: -1073741515
Executable C:\Users\validator\AppData\Local\Programs\PageEdit\QtWebEngineProcess.exe returned exit code: -1073741515

Automated error analysis suggests -1073741515 may mean STATUS_DLL_NOT_FOUND - possibly due to a dependency on Microsoft.VCRedist.2015+.x64 (or .x86).
(Automated response - build 895.)

See the previous version's PR: #168593
There's a weird catch-22 where the local scope install can't find the Microsoft.VCRedist.2015+.x64 dependency, but there is no Microsoft.VCRedist.2015+.x64 package available for the local scope. This same scenario was approved last time. It tests fine locally since Microsoft.VCRedist.2015+.x64 is installed by default on the Minimum OS version this manifest supports. Thanks for your time and efforts!

We've been down this road again and again. Yes, both scopes need the dependency, but the validation process fails miserably if the dependency is specified for the user scope installation the manifest (because no user scope package exists for Microsoft.VCRedist.2015+.x64).
Hence the catch-22 I mentioned.

I will, however, try your suggested change.

Someone needs to explain how we're supposed properly manifest a user scope install that has a Microsoft.VCRedist.2015+.x64 dependency, because I'm tired of guessing.

Automatic Validation ended with:

Installation failed with exit code -1978334972
2024-09-10 06:39:54.191 [CLI ] No suitable installer found for manifest Microsoft.VCRedist.2015+.x64 with version 14.40.33810.0

Automated error analysis suggests -1978334972 may mean This package has a dependency missing from your system.
(Automated response - build 895.)

[Policy] Needs-Manual-Merge


Add option for bounding caches by byte-size

See example in the readme for usage.

CC @dpezely @jeffgrunewald: this is likely the last major update to this cache before we start using it instead of e2qc. General opinions in addition to PR-specific are very welcome.

It seems like a more consistent behavior would be to always cache a value when it's supplied and return the current/immediately previous value that was present for that key (or notfound if no value was previously cached).

@jeffgrunewald If you look closely at cache/3 you see that it takes a fun representing an expensive operation. That funtion is only called if the cache doesn't alreay have the value specifically to prevent calling it. You can achieve what you're talking about by calling insert instead. Whether or not this is a good API is still up for debate.

It seems like a more consistent behavior would be to always cache a value when it's supplied and return the current/immediately previous value that was present for that key (or notfound if no value was previously cached).

@jeffgrunewald If you look closely at cache/3 you see that it takes a fun representing an expensive operation. That funtion is only called if the cache doesn't alreay have the value specifically to prevent calling it. You can achieve what you're talking about by calling insert instead. Whether or not this is a good API is still up for debate.

I stand corrected; I wasn't really paying attention to the fact that the "value" was actually a function to produce a value, and I see in either case (previously cached or newly computed) you're returning the value anyway so I'll just see myself out

I'm always interested in gut reactions. They sometimes point out non-obvious problems with APIs.


Method redefinitions in test cases do not work

The following testcase fails, while it works properly using Test.@testset:
using XUnit

@testset "" begin
@testcase "" begin
    arr = zeros(Int)

    doit(arr) = arr[] = 1

    function kernel(arr)
        doit(arr)
        return
    end

    kernel(arr)
    @test arr[] == 1

    doit(ptr) = ptr[] = 2

    kernel(arr)
    @test arr[] == 2
end
end

In a similar vein, changing the doit method definitions to @eval doit(arr) = ... (which we require for CUDA.jl to avoid boxes), we get a world age error:
  Got exception outside of a @test
  MethodError: no method matching doit(::Array{Int64, 0})
  The applicable method may be too new: running in world age 29599, while current world is 29600.
  Closest candidates are:
    doit(::Any) at /tmp/wip.jl:7 (method too new to be called from this world context.)

Thinking about it some more: I guess it's hard to really match Test.@testset here, and with invokelatest it's possible to work around it.


chore: add transports example

This PR adds tests for the transports example

Rebased with master and fixed conflicts


Change prepublish script to prepare script

They do exactly the same thing, but prepublish is
deprecated because it has a confusing name.
Signed-off-by: Bob Wombat Hogg<EMAIL_ADDRESS>

Coverage remained the same at 95.787% when pulling 09eee1472ceb747e7992668a94bc1f0fa206cdaa on rhoggSugarcrm:prepublish-to-prepare into e3ac3b09fa2b9a2685ccbe563b0993347213e0de on sugarcrm:master.

Coverage remained the same at 95.787% when pulling e0bd50d0b7088719a4f14810a369d02e8605789b on rhoggSugarcrm:prepublish-to-prepare into fe63897f35f6423a2f3dd481c4919fbdf0325aa6 on sugarcrm:master.

Coverage remained the same at 95.787% when pulling 5dac9caf0298241311775ebf8f85cc2ceae8fa8c on rhoggSugarcrm:prepublish-to-prepare into c5740d8d6c7f132929a93024b8501501b2760816 on sugarcrm:master.

Coverage remained the same at 95.787% when pulling 7e0fe2fdcce36c05022f8f13ef9f8a1e409b6ab0 on rhoggSugarcrm:prepublish-to-prepare into 61d64230e9d5bf8a64a98a87a59ffaa46ca1d6fe on sugarcrm:master.

Coverage remained the same at 95.787% when pulling f1a5e6a5eada1813f8aff7b82b189703389f6493 on rhoggSugarcrm:prepublish-to-prepare into 8df3a924358885d7a2285f9ea06948172611cb5e on sugarcrm:master.

Coverage remained the same at 95.787% when pulling 0f355e1df2dfbf5894e81db4a79df700449d67fa on rhoggSugarcrm:prepublish-to-prepare into 2a66d5e605f2cca7c7c1cb03f51b20c01166053c on sugarcrm:master.

Coverage remained the same at 95.845% when pulling f384a56e6b4ea457ece65f69fd583e92e5ddca9a on rhoggSugarcrm:prepublish-to-prepare into 0a7363a5c701ddce3fc86333874de37e507270c6 on sugarcrm:master.

Coverage remained the same at 95.549% when pulling 744a7a2b5d8b6865f863d548bcd1d1055b05cb83 on rhoggSugarcrm:prepublish-to-prepare into ecbcd356ca5a28ba88c15a3aa2e4fcf2b6ec9c0e on sugarcrm:master.


Wrap messages (frames/predictions) in objects

We need to make sure that the data that we send to/receive from the redis server is wrapped in an object. The object would hold information such as a history of which components the message passed through, timestamps that indicate when it entered/left a component, a message id, the source stream address, and anything else that could prove useful later on when monitoring the messages.
Additionally, the message contains a payload, which holds the actual data (frame or prediction) as well as other relevant information specific to that data (for example, the dimensions of the frame).

Fixed in #16 .


Refactor uploader

Reduce allocations for index/tags parse
Switch from urlParse for tagsParse for extract tags (better perfomance)
Fix double write when daily index enabled (for index)
Extend statistic (use struct instead of number metrics may be add more complex metrics like cache hits/miss)

Have some problem - large delay of point insert


Create a pure v3 client

In order to properly test 1to1 it would be nice to be able to create a pure v3 client. This will be necessary once we support SCW as well.

All tests pass 🎉


Perform offline install from new install from ROCK iso

This works fantastically. CentOS is upset when it can't reach the yum mirrors on the Internet, so will likely create a wrapper script that sets the necessary values in the repo files and others, runs the deploy, then sets them back.

We set default install to offline in #75. This fixes this issue.