Cross Partition ORDER BY Queries consume large RUs

Describe the bug
Execute a query as:
using (var iter = c.GetItemQueryIterator<Record>("SELECT * FROM C ORDER BY C.SortValue", continuationToken, new QueryRequestOptions { MaxBufferedItemCount = 0, MaxItemCount = 25, MaxConcurrency = 1 }))

And don't reuse the FeedIterator across boundaries, but instead construct a new FeedIterator based on the continuation token from the previous result.
The RUs consumed are quite large as compared to the consumed RUs when the FeedIterator can be reused.
To Reproduce
Create a container provisioned for 50K RUs.
See this program:
using Microsoft.Azure.Cosmos;
using Microsoft.Azure.Cosmos.Fluent;
using Newtonsoft.Json;
using System;
using System.IO;
using System.Linq;
using System.Threading;
using System.Threading.Tasks;

namespace CosmosDBSort
{
    class Program
    {
        const string connectionString = "<connectionstring>";

        static async Task Main(string[] args)
        {
            CosmosClient cc = new CosmosClientBuilder(connectionString)
                .WithApplicationName("TestSorter")
                .WithConnectionModeDirect()
                .AddCustomHandlers(new Tracer())
                .WithBulkExecution(true)
                .Build();

            var c = cc.GetContainer("sorttest", "testcontainer");

            await CreateItemsAsync(c, 1000 * 1000);
            await QueryAsync(c);
        }

        private static async Task QueryAsync(Container c)
        {
            string continuationToken = null;
            double totalRu = 0;
            int resCount = 0;
            while (true)
            {
                using (var iter = c.GetItemQueryIterator<Record>("SELECT * FROM C ORDER BY C.SortValue", continuationToken, new QueryRequestOptions { MaxBufferedItemCount = 0, MaxItemCount = 25, MaxConcurrency = 1 }))
                {
                    var currentMax = int.MinValue;
                    while (iter.HasMoreResults)
                    {
                        var res = await iter.ReadNextAsync();
                        // Console.WriteLine(res.ContinuationToken);
                        totalRu += res.RequestCharge;
                        Console.WriteLine($"Running Request Charge: {totalRu} RUs.");
                        foreach (var r in res)
                        {
                            resCount++;
                            if (r.SortValue < currentMax)
                            {
                                // throw new Exception("Encountered ordering error.");
                            }
                            else
                            {
                                currentMax = r.SortValue;
                            }
                        }
                        Console.WriteLine($"Running Item Count: {resCount}.");
                        continuationToken = res.ContinuationToken;

                        // simulate round tripping continuation token to client by creating a new ItemQueryIterator<T>
                        break;
                    }

                    if (!iter.HasMoreResults)
                        break;
                }
            }
        }

        static async Task CreateItemsAsync(Container c, int itemCount, CancellationToken ct = default)
        {
            var random = new Random();
            var tasks = Enumerable.Range(0, itemCount).Select(i => new Record
            {
                Id = $"Record-{i}",
                Name = $"MyRecord-{i}",
                PartitionKey = $"PartitionKey-{i}",
                SortValue = random.Next(),
            }).Select(r => c.UpsertItemAsync(r, new PartitionKey(r.PartitionKey), new ItemRequestOptions { EnableContentResponseOnWrite = false }, ct));

            _ = await Task.WhenAll(tasks);
        }
    }

    class Record
    {
        [JsonProperty("id")]
        public string Id { get; set; }

        public string PartitionKey { get; set; }

        public string Name { get; set; }

        public int SortValue { get; set; }
    }

    class Tracer : RequestHandler
    {
        public override async Task<ResponseMessage> SendAsync(RequestMessage request, CancellationToken cancellationToken)
        {
            var content = new StreamReader(request.Content).ReadToEnd();

            Console.WriteLine($"{request.RequestUri} - {content}");
            PrintHeaders(request.Headers);
            var res = await InnerHandler.SendAsync(request, cancellationToken);
            Console.WriteLine($"Subquery had charge of {res.Headers.RequestCharge} RUs");
            Console.WriteLine(res.Diagnostics.ToString());
            PrintHeaders(res.Headers);
            return res;
        }

        private static void PrintHeaders(Headers headers)
        {
            var hs = headers.AllKeys().Select(k => $"\t\t{k} - {headers[k]}");
            foreach (var h in hs)
            {
                Console.WriteLine(h);
            }
        }
    }
}

Expected behavior
RUs should be equivalent (approximately) with the scenario where the FeedIterator can be reused. In our applications case, we round trip ContinuationTokens to the client, so we end up tearing down and rebuilding FeedIterators across REST API calls to our service.
Actual behavior
RUs are quite large. Digging into the response logs, it seems what happens is that some of the requests to the backend are made with no limit on the response size, the result is that we end up materializing 10K+ items from the backend. This behavior does not seem to repro when the same FeedIterator instance is used to materialize all of the results.
Environment summary
SDK Version: 3.21.0
OS Version (e.g. Windows, Linux, MacOSX)
Windows.
Additional context
Example PartitionRange response which had a large result and hence had increased RU usage:
dbs/sorttest/colls/testcontainer - {"query":"SELECT C._rid, [{\"item\": C.SortValue}] AS orderByItems, C AS payload\nFROM C\nWHERE (( C.SortValue > 61490 OR IS_STRING(C.SortValue) OR IS_ARRAY(C.SortValue) OR IS_OBJECT(C.SortValue) ))\nORDER BY C.SortValue"}
                x-ms-documentdb-query-iscontinuationexpected - False
                Content-Type - application/query+json
                x-ms-documentdb-isquery - True
                x-ms-documentdb-query-enablecrosspartition - True
                x-ms-max-item-count -<PHONE_NUMBER>
                x-ms-documentdb-query-parallelizecrosspartitionquery - True
                x-ms-documentdb-populatequerymetrics - True
Subquery had charge of 396.35 RUs
{"name":"Typed FeedIterator ReadNextAsync","id":"07c02326-deac-4127-8c35-369c97a5e71c","caller info":{"member":"OperationHelperWithRootTraceAsync","file":"ClientContextCore.cs","line":244},"start time":"09:18:46:611","duration in milliseconds":19720.8302,"data":{"Client Configuration":{"Client Created Time Utc":"2021-09-28T21:18:42.7046622Z","NumberOfClientsCreated":1,"User Agent":"cosmos-netstandard-sdk/3.21.0|3.21.1|1|X64|Microsoft Windows 10.0.22000|.NET Core 3.1.19|N|F 00000001|TestSorter","ConnectionConfig":{"gw":"(cps:50, urto:10, p:False, httpf: False)","rntbd":"(cto: 5, icto: -1, mrpc: 30, mcpe: 65535, erd: True, pr: ReuseUnicastPort)","other":"(ed:False, be:True)"},"ConsistencyConfig":"(consistency: NotSet, prgns:[])"}},"children":[{"name":"Create Query Pipeline","id":"4150d6a1-a65b-4b5d-8a10-4cd95c3aa4e0","caller info":{"member":"TryCreateCoreContextAsync","file":"CosmosQueryExecutionContextFactory.cs","line":85},"start time":"09:18:46:611","duration in milliseconds":71.88,"children":[{"name":"Get Container Properties","id":"5d5cf8df-a2b8-4d7c-8ee3-e08b5f246009","caller info":{"member":"GetCachedContainerPropertiesAsync","file":"ClientContextCore.cs","line":391},"start time":"09:18:46:613","duration in milliseconds":0.0969,"children":[{"name":"Get Collection Cache","id":"15d823f4-878a-490f-8354-45b734d75346","caller info":{"member":"GetCollectionCacheAsync","file":"DocumentClient.cs","line":546},"start time":"09:18:46:613","duration in milliseconds":0.0264}]},{"name":"Service Interop Query Plan","id":"c361a15e-1961-49db-aa81-485fc1b60b1b","caller info":{"member":"GetQueryPlanWithServiceInteropAsync","file":"QueryPlanRetriever.cs","line":59},"start time":"09:18:46:614","duration in milliseconds":1.606},{"name":"Get Partition Key Ranges","id":"13486c10-b949-454a-bf0d-8a0dc7d97d6d","caller info":{"member":"GetTargetPartitionKeyRangesAsync","file":"CosmosQueryClientCore.cs","line":242},"start time":"09:18:46:616","duration in milliseconds":0.4225,"children":[{"name":"Try Get Overlapping Ranges","id":"be06ac0a-0520-45bb-968f-de900d059f1b","caller info":{"member":"TryGetOverlappingRangesAsync","file":"PartitionKeyRangeCache.cs","line":53},"start time":"09:18:46:616","duration in milliseconds":0.1568}]}]},{"name":"Prefetching","id":"39b7a110-0bea-4aeb-805e-c2a1715336ef","caller info":{"member":"PrefetchInParallelAsync","file":"ParallelPrefetch.cs","line":31},"start time":"09:18:46:683","duration in milliseconds":16987.0383,"children":[{"name":"Prefetch","id":"bd9c0fa0-a51e-4d14-b94c-7d4bfc5bf2e8","caller info":{"member":"PrefetchAsync","file":"BufferedPartitionRangePageAsyncEnumerator.cs","line":50},"start time":"09:18:46:683","duration in milliseconds":3.0792,"children":[{"name":"[,05C1E399CD6732) move next","id":"a36a19d1-31fb-43c3-ae75-7dac6c8c41ba","caller info":{"member":"MoveNextAsync","file":"PartitionRangePageAsyncEnumerator.cs","line":49},"start time":"09:18:46:683","duration in milliseconds":3.0581,"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.RequestInvokerHandler","id":"194f2b32-3be6-4586-9557-65fbcaf50395","start time":"09:18:46:684","duration in milliseconds":0.8479,"children":[{"name":"Get Collection Cache","id":"4a91b75b-7422-4232-8048-6204414880ef","caller info":{"member":"GetCollectionCacheAsync","file":"DocumentClient.cs","line":546},"start time":"09:18:46:684","duration in milliseconds":0.0044},{"name":"Get Partition Key Range Cache","id":"9b92bfac-04f9-45de-8409-7d36f18767e7","caller info":{"member":"GetPartitionKeyRangeCacheAsync","file":"DocumentClient.cs","line":555},"start time":"09:18:46:684","duration in milliseconds":0.0017},{"name":"Try Get Overlapping Ranges","id":"79426df6-5fde-46b9-9fb9-0f269d9b3e13","caller info":{"member":"TryGetOverlappingRangesAsync","file":"PartitionKeyRangeCache.cs","line":53},"start time":"09:18:46:684","duration in milliseconds":0.0495}]},{"name":"Get Cosmos Element Response","id":"0c5afcb9-2f2c-4a9b-aff0-c7270f634ae4","caller info":{"member":"GetCosmosElementResponse","file":"CosmosQueryClientCore.cs","line":284},"start time":"09:18:46:684","duration in milliseconds":1.5982}]}]},{"name":"Prefetch","id":"0975b32d-256e-483c-a91d-100b4f978dae","caller info":{"member":"PrefetchAsync","file":"BufferedPartitionRangePageAsyncEnumerator.cs","line":50},"start time":"09:18:46:686","duration in milliseconds":799.8925,"children":[{"name":"[05C1E399CD6732,05C1E9CD673398) move next","id":"a8ce164a-9a3f-46ff-867e-739881c36f20","caller info":{"member":"MoveNextAsync","file":"PartitionRangePageAsyncEnumerator.cs","line":49},"start time":"09:18:46:686","duration in milliseconds":799.8524,"data":{"Query Metrics":"Retrieved Document Count                 :              25             \r\nRetrieved Document Size                  :           7,869 bytes       \r\nOutput Document Count                    :              25             \r\nOutput Document Size                     :           9,912 bytes       \r\nIndex Utilization                        :          100.00 %           \r\nTotal Query Execution Time               :            0.91 milliseconds\r\n  Query Preparation Time                 :            0.26 milliseconds\r\n  Index Lookup Time                      :            0.11 milliseconds\r\n  Document Load Time                     :            0.22 milliseconds\r\n  Runtime Execution Times                :            0.00 milliseconds\r\n  Document Write Time                    :            0.02 milliseconds\r\n\r\nIndex Utilization Information\r\n  Utilized Single Indexes\r\n  Potential Single Indexes\r\n  Utilized Composite Indexes\r\n  Potential Composite Indexes\r\n"},"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.RequestInvokerHandler","id":"51821caa-a25e-4406-a2fe-c985c1fa0355","start time":"09:18:46:686","duration in milliseconds":798.319,"children":[{"name":"Get Collection Cache","id":"6682ffaa-04e1-4704-87b1-d06616fe79ed","caller info":{"member":"GetCollectionCacheAsync","file":"DocumentClient.cs","line":546},"start time":"09:18:46:687","duration in milliseconds":0.0019},{"name":"Get Partition Key Range Cache","id":"3dd3ff6d-65b1-4d8b-a32f-8390e67cb28c","caller info":{"member":"GetPartitionKeyRangeCacheAsync","file":"DocumentClient.cs","line":555},"start time":"09:18:46:687","duration in milliseconds":0.0009},{"name":"Try Get Overlapping Ranges","id":"85a8032a-03de-4584-acb0-ed1c7ac8be0e","caller info":{"member":"TryGetOverlappingRangesAsync","file":"PartitionKeyRangeCache.cs","line":53},"start time":"09:18:46:687","duration in milliseconds":0.0212},{"name":"CosmosDBSort.Tracer","id":"31655c36-7e42-4667-9f8d-a03daca34e7e","start time":"09:18:46:687","duration in milliseconds":798.096,"data":{"System Info":{"systemHistory":[{"dateUtc":"2021-09-28T21:18:42.9923071Z","cpu":13.760,"memory":3182196.000,"threadInfo":{"isThreadStarving":"no info","availableThreads":32766,"minThreads":8,"maxThreads":32767}}]}},"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.RetryHandler","id":"9ad4d692-1300-421a-a156-620f93fa59f8","start time":"09:18:46:704","duration in milliseconds":139.0805,"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.RouterHandler","id":"1b240120-6d64-4f49-adcc-e18af22ef780","start time":"09:18:46:704","duration in milliseconds":138.9869,"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.TransportHandler","id":"c5a3a0c9-3f2d-45bb-af95-33fbfa21b480","start time":"09:18:46:704","duration in milliseconds":138.9689,"children":[{"name":"Microsoft.Azure.Documents.ServerStoreModel Transport Request","id":"df262514-3998-4eaf-8120-f0df628eff30","caller info":{"member":"ProcessMessageAsync","file":"TransportHandler.cs","line":109},"start time":"09:18:46:705","duration in milliseconds":138.5125,"data":{"Client Side Request Stats":{"Id":"AggregatedClientSideRequestStatistics","ContactedReplicas":[],"RegionsContacted":["https://jgallatest-westus.documents.azure.com/"],"FailedReplicas":[],"AddressResolutionStatistics":[],"StoreResponseStatistics":[{"ResponseTimeUTC":"2021-09-28T21:18:46.8373451Z","ResourceType":"Document","OperationType":"Query","LocationEndpoint":"https://jgallatest-westus.documents.azure.com/","StoreResult":{"ActivityId":"78613b0e-2927-4aa3-8636-04d751ec5245","StatusCode":"Ok","SubStatusCode":"Unknown","LSN":199440,"PartitionKeyRangeId":"3","GlobalCommittedLSN":199439,"ItemLSN":-1,"UsingLocalLSN":true,"QuorumAckedLSN":-1,"SessionToken":"-1#199440","CurrentWriteQuorum":-1,"CurrentReplicaSetSize":-1,"NumberOfReadRegions":0,"IsValid":true,"StorePhysicalAddress":"rntbd://cdb-ms-prod-westus1-fd68.documents.azure.com:14054/apps/55aff61a-7a47-46e9-bc6f-1ea0fc978f9b/services/1a35f239-cd25-4ee8-9d41-a9a744831036/partitions/85586bd2-73d4-4796-81c2-36e4fe079027/replicas/132772677064650747s/","RequestCharge":3.68,"BELatencyInMs":"1.327","transportRequestTimeline":{"requestTimeline":[{"event": "Created", "startTimeUtc": "2021-09-28T21:18:46.7060691Z", "durationInMs": 0.0988},{"event": "ChannelAcquisitionStarted", "startTimeUtc": "2021-09-28T21:18:46.7061679Z", "durationInMs": 106.8335},{"event": "Pipelined", "startTimeUtc": "2021-09-28T21:18:46.8130014Z", "durationInMs": 0.4279},{"event": "Transit Time", "startTimeUtc": "2021-09-28T21:18:46.8134293Z", "durationInMs": 23.5614},{"event": "Received", "startTimeUtc": "2021-09-28T21:18:46.8369907Z", "durationInMs": 0.3289},{"event": "Completed", "startTimeUtc": "2021-09-28T21:18:46.8373196Z", "durationInMs": 0}],"requestSizeInBytes":567,"requestBodySizeInBytes":130,"responseMetadataSizeInBytes":1001,"responseBodySizeInBytes":9912},"TransportException":null}}]}}}]}]}]}]}]},{"name":"Get Cosmos Element Response","id":"7296c703-9212-4922-bde4-5f0b7a6398a2","caller info":{"member":"GetCosmosElementResponse","file":"CosmosQueryClientCore.cs","line":284},"start time":"09:18:47:485","duration in milliseconds":1.2737}]}]},{"name":"Prefetch","id":"3bae905a-12fd-486e-8cd3-9282594c75cd","caller info":{"member":"PrefetchAsync","file":"BufferedPartitionRangePageAsyncEnumerator.cs","line":50},"start time":"09:18:47:487","duration in milliseconds":16182.7781,"children":[{"name":"[05C1E9CD673398,FF) move next","id":"09b18bc9-9d1b-43be-87f5-e53fd6563a4d","caller info":{"member":"MoveNextAsync","file":"PartitionRangePageAsyncEnumerator.cs","line":49},"start time":"09:18:47:487","duration in milliseconds":16182.6901,"data":{"Query Metrics":"Retrieved Document Count                 :              25             \r\nRetrieved Document Size                  :           7,866 bytes       \r\nOutput Document Count                    :              25             \r\nOutput Document Size                     :           9,909 bytes       \r\nIndex Utilization                        :          100.00 %           \r\nTotal Query Execution Time               :            1.23 milliseconds\r\n  Query Preparation Time                 :            0.43 milliseconds\r\n  Index Lookup Time                      :            0.25 milliseconds\r\n  Document Load Time                     :            0.18 milliseconds\r\n  Runtime Execution Times                :            0.00 milliseconds\r\n  Document Write Time                    :            0.02 milliseconds\r\n\r\nIndex Utilization Information\r\n  Utilized Single Indexes\r\n  Potential Single Indexes\r\n  Utilized Composite Indexes\r\n  Potential Composite Indexes\r\n"},"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.RequestInvokerHandler","id":"76c5cf76-eb28-410c-a0c6-ac02230f1077","start time":"09:18:47:488","duration in milliseconds":16181.0421,"children":[{"name":"Get Collection Cache","id":"58777eef-3cdd-4335-af9c-000855a7ee66","caller info":{"member":"GetCollectionCacheAsync","file":"DocumentClient.cs","line":546},"start time":"09:18:47:488","duration in milliseconds":0.0249},{"name":"Get Partition Key Range Cache","id":"0e384c53-d53f-4690-b429-f99851d67fc2","caller info":{"member":"GetPartitionKeyRangeCacheAsync","file":"DocumentClient.cs","line":555},"start time":"09:18:47:488","duration in milliseconds":0.0258},{"name":"Try Get Overlapping Ranges","id":"ef5324b1-f7d4-4423-9d30-db54f96e5e8e","caller info":{"member":"TryGetOverlappingRangesAsync","file":"PartitionKeyRangeCache.cs","line":53},"start time":"09:18:47:488","duration in milliseconds":0.5143},{"name":"CosmosDBSort.Tracer","id":"7a890c3b-bb4d-4f85-829c-075d6dddc9a5","start time":"09:18:47:489","duration in milliseconds":16179.5134,"data":{"System Info":{"systemHistory":[{"dateUtc":"2021-09-28T21:18:42.9923071Z","cpu":13.760,"memory":3182196.000,"threadInfo":{"isThreadStarving":"no info","availableThreads":32766,"minThreads":8,"maxThreads":32767}}]}},"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.RetryHandler","id":"450d2998-0788-41fe-8547-27b33fedf4ba","start time":"09:18:47:563","duration in milliseconds":144.6427,"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.RouterHandler","id":"04f93b7a-0cfc-42c0-b9d2-7fcfb9c36456","start time":"09:18:47:563","duration in milliseconds":144.5387,"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.TransportHandler","id":"f9144771-0dad-406a-9d91-a65e30778a1a","start time":"09:18:47:563","duration in milliseconds":144.5135,"children":[{"name":"Microsoft.Azure.Documents.ServerStoreModel Transport Request","id":"c285cda6-577c-4f08-8c3d-1b46e407b28f","caller info":{"member":"ProcessMessageAsync","file":"TransportHandler.cs","line":109},"start time":"09:18:47:576","duration in milliseconds":131.6042,"data":{"Client Side Request Stats":{"Id":"AggregatedClientSideRequestStatistics","ContactedReplicas":[],"RegionsContacted":["https://jgallatest-westus.documents.azure.com/"],"FailedReplicas":[],"AddressResolutionStatistics":[],"StoreResponseStatistics":[{"ResponseTimeUTC":"2021-09-28T21:18:47.7074563Z","ResourceType":"Document","OperationType":"Query","LocationEndpoint":"https://jgallatest-westus.documents.azure.com/","StoreResult":{"ActivityId":"78613b0e-2927-4aa3-8636-04d751ec5245","StatusCode":"Ok","SubStatusCode":"Unknown","LSN":199088,"PartitionKeyRangeId":"4","GlobalCommittedLSN":199087,"ItemLSN":-1,"UsingLocalLSN":true,"QuorumAckedLSN":-1,"SessionToken":"-1#199088","CurrentWriteQuorum":-1,"CurrentReplicaSetSize":-1,"NumberOfReadRegions":0,"IsValid":true,"StorePhysicalAddress":"rntbd://cdb-ms-prod-westus1-fd68.documents.azure.com:14426/apps/55aff61a-7a47-46e9-bc6f-1ea0fc978f9b/services/1daee770-f476-4c3f-8854-f141d82bc4b5/partitions/ae5922c5-6c8c-499d-9b63-774bc9c5f7b2/replicas/132772041616181005s/","RequestCharge":4.22,"BELatencyInMs":"1.628","transportRequestTimeline":{"requestTimeline":[{"event": "Created", "startTimeUtc": "2021-09-28T21:18:47.5769154Z", "durationInMs": 0.0772},{"event": "ChannelAcquisitionStarted", "startTimeUtc": "2021-09-28T21:18:47.5769926Z", "durationInMs": 105.0208},{"event": "Pipelined", "startTimeUtc": "2021-09-28T21:18:47.6820134Z", "durationInMs": 0.7518},{"event": "Transit Time", "startTimeUtc": "2021-09-28T21:18:47.6827652Z", "durationInMs": 24.2247},{"event": "Received", "startTimeUtc": "2021-09-28T21:18:47.7069899Z", "durationInMs": 0.4458},{"event": "Completed", "startTimeUtc": "2021-09-28T21:18:47.7074357Z", "durationInMs": 0}],"requestSizeInBytes":664,"requestBodySizeInBytes":227,"responseMetadataSizeInBytes":1270,"responseBodySizeInBytes":9909},"TransportException":null}}]}}}]}]}]}]}]},{"name":"Get Cosmos Element Response","id":"c728fd6d-668c-4962-85e7-e079e392c7e5","caller info":{"member":"GetCosmosElementResponse","file":"CosmosQueryClientCore.cs","line":284},"start time":"09:19:03:669","duration in milliseconds":0.9791}]}]}]},{"name":"[,05C1E399CD6732) move next","id":"b77666fd-c997-4174-8235-ba53b23c8bca","caller info":{"member":"MoveNextAsync","file":"PartitionRangePageAsyncEnumerator.cs","line":49},"start time":"09:19:03:670","duration in milliseconds":0.0946,"children":[{"name":"[,05C1E399CD6732) move next","id":"cdcbbd6b-7c00-40c4-bbcc-cf52b68cfd7e","caller info":{"member":"MoveNextAsync","file":"PartitionRangePageAsyncEnumerator.cs","line":49},"start time":"09:19:03:670","duration in milliseconds":0.0454,"children":[{"name":"Prefetch","id":"05fc89b0-33b4-444d-9e6d-cc2eea802d1f","caller info":{"member":"PrefetchAsync","file":"BufferedPartitionRangePageAsyncEnumerator.cs","line":50},"start time":"09:19:03:670","duration in milliseconds":0.0016}]}]},{"name":"Get Container Properties","id":"8a1c9ead-e111-49f6-bd4b-3dc0b3424f33","caller info":{"member":"GetCachedContainerPropertiesAsync","file":"ClientContextCore.cs","line":391},"start time":"09:19:03:681","duration in milliseconds":0.0922,"children":[{"name":"Get Collection Cache","id":"0281622d-3fbd-4b43-b867-418ed7b2068d","caller info":{"member":"GetCollectionCacheAsync","file":"DocumentClient.cs","line":546},"start time":"09:19:03:681","duration in milliseconds":0.0128}]},{"name":"Get RID","id":"da7980c1-c7de-4e9f-b4f3-f1cb1b38e4a7","caller info":{"member":"GetCachedRIDAsync","file":"ContainerCore.cs","line":437},"start time":"09:19:03:682","duration in milliseconds":0.0325},{"name":"Get Collection Cache","id":"97932ee8-0cec-459f-ace0-3fdfde907fc1","caller info":{"member":"GetCollectionCacheAsync","file":"DocumentClient.cs","line":546},"start time":"09:19:03:682","duration in milliseconds":0.0017},{"name":"Get Overlapping Feed Ranges","id":"f2d9f1d0-773c-4fe3-9bab-5a0e28a54f1b","caller info":{"member":"GetTargetPartitionKeyRangeByFeedRangeAsync","file":"CosmosQueryClientCore.cs","line":209},"start time":"09:19:03:683","duration in milliseconds":0.5271,"children":[{"name":"Get Partition Key Ranges","id":"fc6a9501-9da5-4471-acb7-d2bcd69a48c7","caller info":{"member":"GetTargetPartitionKeyRangesAsync","file":"CosmosQueryClientCore.cs","line":242},"start time":"09:19:03:683","duration in milliseconds":0.3129,"children":[{"name":"Try Get Overlapping Ranges","id":"e763bfcb-cab3-49f7-ba59-0a2e1f2281d9","caller info":{"member":"TryGetOverlappingRangesAsync","file":"PartitionKeyRangeCache.cs","line":53},"start time":"09:19:03:684","duration in milliseconds":0.1229}]}]},{"name":"Prefetching","id":"50e6950c-8abd-496d-bf5f-b5b7fea8f965","caller info":{"member":"PrefetchInParallelAsync","file":"ParallelPrefetch.cs","line":31},"start time":"09:19:03:688","duration in milliseconds":2645.2022,"children":[{"name":"Prefetch","id":"7221712d-149f-46b4-b2cc-1386599a968c","caller info":{"member":"PrefetchAsync","file":"BufferedPartitionRangePageAsyncEnumerator.cs","line":50},"start time":"09:19:03:688","duration in milliseconds":0.0036},{"name":"Prefetch","id":"dbaaa185-8602-449f-b9d8-62286ab8eabe","caller info":{"member":"PrefetchAsync","file":"BufferedPartitionRangePageAsyncEnumerator.cs","line":50},"start time":"09:19:03:688","duration in milliseconds":0.0022},{"name":"Prefetch","id":"2bac924d-2eac-44e3-9807-559490f47b0c","caller info":{"member":"PrefetchAsync","file":"BufferedPartitionRangePageAsyncEnumerator.cs","line":50},"start time":"09:19:03:688","duration in milliseconds":1623.8789,"children":[{"name":"[,05C1C9CD673398) move next","id":"9a34502e-52ab-4bfa-b349-bff02c0a265d","caller info":{"member":"MoveNextAsync","file":"PartitionRangePageAsyncEnumerator.cs","line":49},"start time":"09:19:03:688","duration in milliseconds":1623.8406,"data":{"Query Metrics":"Retrieved Document Count                 :          10,530             \r\nRetrieved Document Size                  :       3,334,846 bytes       \r\nOutput Document Count                    :          10,530             \r\nOutput Document Size                     :       4,198,644 bytes       \r\nIndex Utilization                        :          100.00 %           \r\nTotal Query Execution Time               :           85.81 milliseconds\r\n  Query Preparation Time                 :            0.32 milliseconds\r\n  Index Lookup Time                      :            1.86 milliseconds\r\n  Document Load Time                     :           48.78 milliseconds\r\n  Runtime Execution Times                :            0.00 milliseconds\r\n  Document Write Time                    :           12.32 milliseconds\r\n\r\nIndex Utilization Information\r\n  Utilized Single Indexes\r\n  Potential Single Indexes\r\n  Utilized Composite Indexes\r\n  Potential Composite Indexes\r\n"},"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.RequestInvokerHandler","id":"a4d0a9d3-8a1b-4771-8179-0fed47b6e2ce","start time":"09:19:03:688","duration in milliseconds":1460.6414,"children":[{"name":"Get Collection Cache","id":"d2e7408e-9654-41f6-bf1c-dd0f32062db0","caller info":{"member":"GetCollectionCacheAsync","file":"DocumentClient.cs","line":546},"start time":"09:19:03:688","duration in milliseconds":0.0016},{"name":"Get Partition Key Range Cache","id":"f986e7c4-164a-453f-a14e-aa5220bdcf16","caller info":{"member":"GetPartitionKeyRangeCacheAsync","file":"DocumentClient.cs","line":555},"start time":"09:19:03:688","duration in milliseconds":0.0006},{"name":"Try Get Overlapping Ranges","id":"018f22ff-207c-4398-bf12-bd5aef3f74d7","caller info":{"member":"TryGetOverlappingRangesAsync","file":"PartitionKeyRangeCache.cs","line":53},"start time":"09:19:03:688","duration in milliseconds":0.018},{"name":"CosmosDBSort.Tracer","id":"785c84b0-c613-4901-b2a8-f51c77952346","start time":"09:19:03:688","duration in milliseconds":1460.4431,"data":{"System Info":{"systemHistory":[{"dateUtc":"2021-09-28T21:18:42.9923071Z","cpu":13.760,"memory":3182196.000,"threadInfo":{"isThreadStarving":"no info","availableThreads":32766,"minThreads":8,"maxThreads":32767}},{"dateUtc":"2021-09-28T21:18:53.0319003Z","cpu":30.078,"memory":3311232.000,"threadInfo":{"isThreadStarving":"False","threadWaitIntervalInMs":0.1294,"availableThreads":32765,"minThreads":8,"maxThreads":32767}},{"dateUtc":"2021-09-28T21:19:03.0434032Z","cpu":21.523,"memory":3378460.000,"threadInfo":{"isThreadStarving":"False","threadWaitIntervalInMs":0.1395,"availableThreads":32764,"minThreads":8,"maxThreads":32767}}]}},"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.RetryHandler","id":"d5852c83-94e3-4d94-94d3-d7ec3a8c9dac","start time":"09:19:03:742","duration in milliseconds":1038.6025,"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.RouterHandler","id":"2635eb84-867a-47cc-89f8-aae706625e30","start time":"09:19:03:742","duration in milliseconds":1038.52,"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.TransportHandler","id":"71bfda75-711b-4316-a648-75c9c9dcc5c4","start time":"09:19:03:742","duration in milliseconds":1038.5039,"children":[{"name":"Microsoft.Azure.Documents.ServerStoreModel Transport Request","id":"ecccbe49-59e8-4d8e-a613-cceb329e19a5","caller info":{"member":"ProcessMessageAsync","file":"TransportHandler.cs","line":109},"start time":"09:19:03:743","duration in milliseconds":1038.1407,"data":{"Client Side Request Stats":{"Id":"AggregatedClientSideRequestStatistics","ContactedReplicas":[],"RegionsContacted":["https://jgallatest-westus.documents.azure.com/"],"FailedReplicas":[],"AddressResolutionStatistics":[],"StoreResponseStatistics":[{"ResponseTimeUTC":"2021-09-28T21:19:04.7807991Z","ResourceType":"Document","OperationType":"Query","LocationEndpoint":"https://jgallatest-westus.documents.azure.com/","StoreResult":{"ActivityId":"78613b0e-2927-4aa3-8636-04d751ec5245","StatusCode":"Ok","SubStatusCode":"Unknown","LSN":199442,"PartitionKeyRangeId":"0","GlobalCommittedLSN":199441,"ItemLSN":-1,"UsingLocalLSN":true,"QuorumAckedLSN":-1,"SessionToken":"-1#199442","CurrentWriteQuorum":-1,"CurrentReplicaSetSize":-1,"NumberOfReadRegions":0,"IsValid":true,"StorePhysicalAddress":"rntbd://cdb-ms-prod-westus1-fd68.documents.azure.com:14320/apps/7e8a7628-3024-417a-9c8d-499a423f39ec/services/388919cd-a792-4c51-871a-b9dc7cbcb55c/partitions/f6711166-e48b-4bb4-9c81-c643a750b37d/replicas/132769956037385524s/","RequestCharge":395.45,"BELatencyInMs":"86.194","transportRequestTimeline":{"requestTimeline":[{"event": "Created", "startTimeUtc": "2021-09-28T21:19:03.7435655Z", "durationInMs": 0.0808},{"event": "ChannelAcquisitionStarted", "startTimeUtc": "2021-09-28T21:19:03.7436463Z", "durationInMs": 140.5861},{"event": "Pipelined", "startTimeUtc": "2021-09-28T21:19:03.8842324Z", "durationInMs": 0.3812},{"event": "Transit Time", "startTimeUtc": "2021-09-28T21:19:03.8846136Z", "durationInMs": 895.7126},{"event": "Received", "startTimeUtc": "2021-09-28T21:19:04.7803262Z", "durationInMs": 0.4448},{"event": "Completed", "startTimeUtc": "2021-09-28T21:19:04.7807710Z", "durationInMs": 0}],"requestSizeInBytes":661,"requestBodySizeInBytes":226,"responseMetadataSizeInBytes":1165,"responseBodySizeInBytes":4198644},"TransportException":null}}]}}}]}]}]}]}]},{"name":"Get Cosmos Element Response","id":"25f49fdf-a9d7-4a7d-81cf-eb17171c577b","caller info":{"member":"GetCosmosElementResponse","file":"CosmosQueryClientCore.cs","line":284},"start time":"09:19:05:149","duration in milliseconds":158.9829}]}]},{"name":"Prefetch","id":"cff5ffe8-a17e-47d1-bfc8-5d6226481f9a","caller info":{"member":"PrefetchAsync","file":"BufferedPartitionRangePageAsyncEnumerator.cs","line":50},"start time":"09:19:05:312","duration in milliseconds":1021.0661,"children":[{"name":"[05C1C9CD673398,05C1D9CD673398) move next","id":"6f73e03c-f693-4998-9aa6-04023244cc7a","caller info":{"member":"MoveNextAsync","file":"PartitionRangePageAsyncEnumerator.cs","line":49},"start time":"09:19:05:312","duration in milliseconds":1021.0306,"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.RequestInvokerHandler","id":"2807ea68-5410-498d-9450-5dd526b92014","start time":"09:19:05:312","duration in milliseconds":1020.7271,"children":[{"name":"Get Collection Cache","id":"8e1202c4-fe46-4c82-a7f8-6c39501fce6b","caller info":{"member":"GetCollectionCacheAsync","file":"DocumentClient.cs","line":546},"start time":"09:19:05:312","duration in milliseconds":0.0065},{"name":"Get Partition Key Range Cache","id":"4f1f025b-cbb9-45d6-8df8-bbad1a0c0cc5","caller info":{"member":"GetPartitionKeyRangeCacheAsync","file":"DocumentClient.cs","line":555},"start time":"09:19:05:312","duration in milliseconds":0.0041},{"name":"Try Get Overlapping Ranges","id":"70a0d7e1-f196-41c9-88b2-7243176c75e9","caller info":{"member":"TryGetOverlappingRangesAsync","file":"PartitionKeyRangeCache.cs","line":53},"start time":"09:19:05:312","duration in milliseconds":0.0838},{"name":"CosmosDBSort.Tracer","id":"b1a74853-02e5-49e8-b497-53c5c1de4df3","start time":"09:19:05:313","duration in milliseconds":1020.4152,"data":{"System Info":{"systemHistory":[{"dateUtc":"2021-09-28T21:18:42.9923071Z","cpu":13.760,"memory":3182196.000,"threadInfo":{"isThreadStarving":"no info","availableThreads":32766,"minThreads":8,"maxThreads":32767}},{"dateUtc":"2021-09-28T21:18:53.0319003Z","cpu":30.078,"memory":3311232.000,"threadInfo":{"isThreadStarving":"False","threadWaitIntervalInMs":0.1294,"availableThreads":32765,"minThreads":8,"maxThreads":32767}},{"dateUtc":"2021-09-28T21:19:03.0434032Z","cpu":21.523,"memory":3378460.000,"threadInfo":{"isThreadStarving":"False","threadWaitIntervalInMs":0.1395,"availableThreads":32764,"minThreads":8,"maxThreads":32767}}]}},"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.RetryHandler","id":"e72ff88a-b577-4c6d-b7fa-0960ab6a39d7","start time":"09:19:05:364","duration in milliseconds":967.7303,"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.RouterHandler","id":"2d02ff8c-2522-433e-92d5-f8b8e228c223","start time":"09:19:05:364","duration in milliseconds":967.636,"children":[{"name":"Microsoft.Azure.Cosmos.Handlers.TransportHandler","id":"e6b0a9f4-0c8a-484c-ac56-4de5134ac8a8","start time":"09:19:05:364","duration in milliseconds":967.6193,"children":[{"name":"Microsoft.Azure.Documents.ServerStoreModel Transport Request","id":"7f8857f1-bd11-4fe5-847f-12608dfa9d1d","caller info":{"member":"ProcessMessageAsync","file":"TransportHandler.cs","line":109},"start time":"09:19:05:364","duration in milliseconds":967.1052,"data":{"Client Side Request Stats":{"Id":"AggregatedClientSideRequestStatistics","ContactedReplicas":[],"RegionsContacted":["https://jgallatest-westus.documents.azure.com/"],"FailedReplicas":[],"AddressResolutionStatistics":[],"StoreResponseStatistics":[{"ResponseTimeUTC":"2021-09-28T21:19:06.3316977Z","ResourceType":"Document","OperationType":"Query","LocationEndpoint":"https://jgallatest-westus.documents.azure.com/","StoreResult":{"ActivityId":"78613b0e-2927-4aa3-8636-04d751ec5245","StatusCode":"Ok","SubStatusCode":"Unknown","LSN":199213,"PartitionKeyRangeId":"1","GlobalCommittedLSN":199212,"ItemLSN":-1,"UsingLocalLSN":true,"QuorumAckedLSN":-1,"SessionToken":"-1#199213","CurrentWriteQuorum":-1,"CurrentReplicaSetSize":-1,"NumberOfReadRegions":0,"IsValid":true,"StorePhysicalAddress":"rntbd://cdb-ms-prod-westus1-fd68.documents.azure.com:14077/apps/55aff61a-7a47-46e9-bc6f-1ea0fc978f9b/services/dd4515ee-1d88-4be1-a78d-51c7b82520c6/partitions/0a2438e2-176e-4503-a9d4-df26ee3629ec/replicas/132766344699765295s/","RequestCharge":396.35,"BELatencyInMs":"86.615","transportRequestTimeline":{"requestTimeline":[{"event": "Created", "startTimeUtc": "2021-09-28T21:19:05.3655940Z", "durationInMs": 0.079},{"event": "ChannelAcquisitionStarted", "startTimeUtc": "2021-09-28T21:19:05.3656730Z", "durationInMs": 108.7322},{"event": "Pipelined", "startTimeUtc": "2021-09-28T21:19:05.4744052Z", "durationInMs": 0.5608},{"event": "Transit Time", "startTimeUtc": "2021-09-28T21:19:05.4749660Z", "durationInMs": 856.4247},{"event": "Received", "startTimeUtc": "2021-09-28T21:19:06.3313907Z", "durationInMs": 0.2878},{"event": "Completed", "startTimeUtc": "2021-09-28T21:19:06.3316785Z", "durationInMs": 0}],"requestSizeInBytes":657,"requestBodySizeInBytes":226,"responseMetadataSizeInBytes":1297,"responseBodySizeInBytes":4198776},"TransportException":null}}]}}}]}]}]}]}]}]}]}]}]}
                x-ms-activity-id - 78613b0e-2927-4aa3-8636-04d751ec5245
                x-ms-last-state-change-utc - Mon, 20 Sep 2021 18:01:18.169 GMT
                x-ms-continuation - +RID:~M+JmAMx1QYAzbwIAAAAACA==#RT:1#TRC:10531#RTD:6ZzvmckHCLGZ9CJxeQEUBMGbbSVa#ISV:2#IEO:65567#QCF:4#FPC:AggAAAAAACAAAAwAAAAAIAAAAAAAAAAgAAAGAAHA/v/wfwEAAAAAIAAABgCxZf/+QFoCAAAAACAAAAIAAEADAAAAACAAAAIAAEAEAAAAACAAAAIAAEAFAAAAACAAAAYAsUv/70B0BgAAAAAgAAACAABABwAAAAAgAAACAABACAAAAAAgAAAKAPFg/9/BRO//MFoJAAAAACAAAAIAAEAKAAAAACAAAAYAoVn/91BmCwAAAAAgAAAGAJFR3/9gbgwAAAAAIAAABAABTQEA
                x-ms-resource-quota - documentSize=51200;documentsSize=52428800;documentsCount=-1;collectionSize=52428800;
                x-ms-resource-usage - documentSize=170;documentsSize=122252;documentsCount=199936;collectionSize=174969;
                x-ms-schemaversion - 1.12
                lsn - 199213
                x-ms-item-count - 10531
                x-ms-request-charge - 396.35
                x-ms-alt-content-path - dbs/sorttest/colls/testcontainer
                x-ms-content-path - M+JmAMx1QYA=
                x-ms-documentdb-partitionkeyrangeid - 1
                x-ms-xp-role - 1
                x-ms-documentdb-query-metrics - totalExecutionTimeInMs=86.20;queryCompileTimeInMs=0.17;queryLogicalPlanBuildTimeInMs=0.07;queryPhysicalPlanBuildTimeInMs=0.12;queryOptimizationTimeInMs=0.02;VMExecutionTimeInMs=85.54;indexLookupTimeInMs=2.24;documentLoadTimeInMs=48.72;systemFunctionExecuteTimeInMs=0.00;userFunctionExecuteTimeInMs=0.00;retrievedDocumentCount=10531;retrievedDocumentSize=3334983;outputDocumentCount=10531;outputDocumentSize=4198776;writeOutputTimeInMs=12.34;indexUtilizationRatio=1.00
                x-ms-cosmos-query-execution-info - {"reverseRidEnabled":false,"reverseIndexScan":false}
                x-ms-global-Committed-lsn - 199212
                x-ms-number-of-read-regions - 0
                x-ms-transport-request-id - 1
                x-ms-cosmos-llsn - 199213
                x-ms-session-token - 1:-1#199213
                x-ms-request-duration-ms - 86.615
                x-ms-serviceversion -  version=<IP_ADDRESS>
                x-ms-cosmos-is-partition-key-delete-pending - false

@johngallardo can you try the 3.22.0-preview release which has the fix?

I tried 3.22.0-preview release, and there is some improvement. However, comparing iterating the FeedIterator in a loop vs. having to reconstruct a FeedIterator from continuation token still results in substantial increase in RU consumption (5x).

This is expected behavior since creating a new FeedIterator results in query having to recreate the heap for the k-way merge and we need to prefetch from all partitions.


need async API call review

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/then


I modified your code to train my crack data set and encountered some problems

My dataset n_channel = 2 (cracks or cracks), I like your code training cityscapes in the code, change the n_channels to 2, but the program is running to The Times wrong one_hot tensor input to the model (pictured), I find a solution, the Internet has a cudnn version of the problem, but I can run successful your source code, so I hope to get your help, thank you!

Hi @wanjianr I am not able to clearly get the problem you are facing, maybe you can elucidate a bit more. If it related to the wrong number of channels problem, you may once see the make_one_hot function in utils.py.

Closing it for now


CapsLock key support

Unable to find capslock key in the syntax details and documentation ?
Is it supported ?
if not then is there any plan to include that ?
Expected Behavior
Capslock key should work :
robot.keyTap('capslock');

Current Behavior
Capslock key not working

Steps to Reproduce (for bugs)
Try : robot.keyTap('capslock');

Context
I'm trying to render capslock key event from my electron app

Your Environment

RobotJS version: 0.4.7
Node.js version: 4.5.0
npm version: 2.15.9
electron version: 1.7.3
Operating System: Win 7

Is there any update on this ?

@octalmage  Is there any plan to support CapsLock key in future ?
I haven't received any comments on my issue above..

Hi poojas2288. How temporary solve problem, i just add { "capslock",       K_CAPSLOCK }, to KeyNames array in file node_modules/robotjs/src/robotjs.cc
After that, you can use capslock like other keyboard triggers: robotjs.keyTap('capslock');

This issue has been closed because it has been inactive for > 180 days.
You may reopen this issue if it has been closed in error.


chore: Bump Tauri to 1.4

Bump Tauri to newest stable release.

It clippy errors in a dependency even though I disabled dependency checking. Wtf?


RuntimeError: Trying to backward through the graph a second time with custom ttt_layer in self-attention

Hello,
I have replaced a model's self-attention with TTTLinear using the code provided. When performing loss.backward on the first batch, there are no issues. However, during loss.backward() on the second batch, I encounter the following error:
File "train_engine.py", line 43, in train_one_epoch
scaler.scale(losses["cost"]).backward()
File "train.py", line 194, in main
train_one_epoch(
File "train.py", line 255, in
main()
RuntimeError: Trying to backward through the graph a second time (or directly access saved tensors after they have already been freed). Saved intermediate values of the graph are freed when you call .backward() or autograd.grad(). Specify retain_graph=True if you need to backward through the graph a second time or if you need to access saved tensors after calling backward.

It seems to be related to the release of some intermediate values in the ttt_layer or related to gradient computation. Since I'm not very familiar with the internal gradient calculations of ttt_layer, I cannot pinpoint the faulty code.
Do you have any insights or suggestions on how to resolve this issue?
Thank you!

You can copy and paste this text into your GitHub issue.

Hi, did you remove the transformer's K,Q,V entirely, and replaced it with TTT-defined K,Q,V's?

Hi @maojiaqi111
Is it possible to provide some code to reproduce your error? Or did you try to directly train the provided TTT model instead of modifying self-attention?

Hi, @xvjiarui
Thanks for your question, +1
Also, I wonder whether it's ever feasible to load k, q, v from the pretrained transformer (standard transformer's self-attention, not the k,q,v in ttt.linear) directly/easily? Or does one have to map each key to ttt.linear manually? If the latter, then I guess the mapping would require very delicate efforts and susceptible to errors?
Thank you!

@LuoyaoChen Hi. The QKV in a transformer are analogous to those in TTT. You should be able to load them and they should correspond with the same shape. Page 7:


Inform user if not using latest version of application

Is your feature request related to a problem? Please describe.
I don't know when I am using the latest version of the application.
Describe the solution you'd like
Be aware when I am not running the latest version, so I can upgrade and read messages sent in newer versions
Describe alternatives you've considered
N/A
Additional context
Older versions are not guaranteed to read later version message formats

#254 would provide a more elegant way of informing users there is a newer version of the application available. Similar to the docker OSX client "Check for updates.." and periodic request to update to latest version. This is the approach we would like to take in the proposed client.


Problem when i listen to onBrush inside useEffect

@lpatiny @targos @stropitek
when i add a Brush inside [ ] in useEffect beside state the component rerender continually.
https://github.com/cheminfo/nmr-displayer/blob/dd5326c3d4dc6a122a98f30fd9b0244741171234/src/component/EventsTrackers/BrushTracker.js#L110-L114

You need to make sure your onBrush function is not recreated on every render here. You can call useCallback for that.

useCallback

You need to make sure your onBrush function is not recreated on every render here. You can call useCallback for that.

i try that option but you can't use useCallback inside useSize, so What to do?

Are you sure you need to create those callbacks inside of the useSize hook? it looks to me that you could instead do that just before useSize is called and you would be able to use useCallback here.

Are you sure you need to create those callbacks inside of the useSize hook? it looks to me that you could instead do that just before useSize is called and you would be able to use use callback here.

I used useCallback for onBrush event handler and I add it outside the useSize, but we have another problem if you use zoom brush first and used it to zoom to specific area and then select another tool " not matter if it's peak picking or integral tool "  it will Trigger the onBrush, can you check the code I push the last version of the code at GitHub

can you or Daniel  check the code for this problem?

@hamed-musallam
indeed that is a bug with the BrushTracker component. I'm looking into it

fixed in e12b176a2ec6bc02b7aac9e6f99e232c63793d0e


High memory usage

Hi,
I install Influxdb on ubuntu server with 4G of memory and use python's requests module to write 10M points into db.
The python script inserts 20k points per second into db successfully but ubuntu's memory goes high until Influxdb use 97% of Ram.
After that I can't query a simple request like "select * from srcipm limit 1".
Even after write process is finished, Influxdb doesn't release memory.
Details:

Server: 64bit Ubuntu Server 15.10, 1 Core CPU, 4G RAM
InfluxDB Version 0.9.6

Write query in python:
requests.post("http://<IP_ADDRESS>:8086/write?db=mydb", "srcipm,device_id=4,input_snmp=2,output_snmp=3,direction=1,ip=<IP_ADDRESS> bytes=25478")

Where is the problem? should I config something or my query is wrong?

@tahmasebi what do you mean by I can't query a simple request like "select * from srcipm limit 1".? Does the query not return?

@mjdesa, The query execution takes a lot of time, one time, it didn't return anything for 30 minutes, then i cancel the query by ctr+c. even after restarting Influxdb service manually (because of memory usage), the query returns result very slow and memory is full again.

How many cores does the machine have?

1 Core, for 2 or 3 seconds cpu usage goes 100% and then return to under 5% when i request a query. the problem I can see in htop is memory usage of influxdb by 97-8%.

how man unique series are you writing to the database?

How should I get number of series? I'm new in Influxdb.
I don't have access to machine now, I should check it tomorrow at company. I'm sorry.

No need to be sorry. :)
The query show series will give you all of the series the are stored in a database.

@mjdesa , I use show series to find number of series in my db but it displays a list of all series. so I used python to count number of series in my db like this:
SHOW SERIES FROM srcipm
len(result['results'][0]['series'][0]['values'])
and I get 153K of series. Is it too many series for 10M points?

@tahmasebi No, you should be well within your limits. We've had problems with 0.9.6 in the past consuming too much memory. Can you run the test against 0.10.0beta2 and see if Influx behave more stably
https://influxdb.s3.amazonaws.com/influxdb_0.10.0-0.beta2_amd64.deb
https://influxdb.s3.amazonaws.com/influxdb-0.10.0-0.beta2.x86_64.rpm

Sure, I'll test this version of Influxdb and I'll inform you tomorrow. (It's time difference :) )
Thank you.

Hi @mjdesa ,
I removed influxdb from ubuntu by apt-get remove influxdb and then install that package you gave me above.
Database from previous version exist yet, but when I execute a query on old db, it returns an error ERR: read message type: read tcp <IP_ADDRESS>:8088: i/o timeout.
So I create a new db and write 10M point to it. the write process became very slow than before (6k/s) and this time the memory goes up to 74%.
I take a screenshot of htop and iotop for more details.

Try reduce cache-snapshot-memory-size and cache-snapshot-write-cold-duration in the configuration.
I set mine cache-snapshot-memory-size = 2621440 and cache-snapshot-write-cold-duration = "1m" during massive writes.

I resolved ERR: read message type: read tcp <IP_ADDRESS>:8088: i/o timeout.  by increasing shard-mapper-timeout under [cluster] section, FYI

@tahmasebi Are you still experiencing this problem?

I am brand new to influxdb and ran into this problem.
I started by inserting 6928 price points for one stock. Ex of data points is such:
INSERT price,ric=VOD.L,open=12.3,close=12.3,volume=1200 dummy=1<PHONE_NUMBER>7
Then i did  a query like this :
SELECT ric, close, volume FROM price WHERE ric = 'VOD.L' LIMIT 1;
This killed my laptop by consuming all 16Gb of RAM.

I'm making a similar stock system like @adilbaig, and counting just the same problem with InfluxDB 0.13.0.
When I'm tried to insert about 4k trading points all at once using batch insert via http api, InfluxDB just took all of my 8G memory and all swap memory, which made the whole system  deadly slow.
Is there a way to limit the total memory usage?
My OS is Ubuntu 16.04 LTM

@adilbaig In the example point you listed
price,ric=VOD.L,open=12.3,close=12.3,volume=1200 dummy=1<PHONE_NUMBER>7

ric, open, close, and volume are all tags. Meaning that both key and value will be treated as strings. Additionally they will be index. And presumably will have an absurdly high cardinality. This is most likely why you're seeing so much memory used. Try changing open, close, and volume to be fields instead.

@dy1901 What does your schema look like?

@DavidSoong128 what specifically would you like to know?

@mjdesa  Thank you for your reply.
i install  influxdb V0.13.0  on linux  server with 16G of memory and use java's requests  to write some points into db.   but  memory is continuously reduced, even  consumed 11G，then , the only operation what i can do  is just  restart influxdb， i think it is the same problem @dy1901

@DavidSoong128
I have a few more questions:

Can you give some examples of the data that you're writing in line protocol?
About how long was InfluxDB running before you hit this problem?
Did you have any queries running when you hit this problem? If so, what were they?

Can you give some examples of the data that you're writing in line protocol?
  **point like this :  tps is the measurement, appName, serviceName are tags,  tpsAmount, currency are field,   example:  tps, order, addOrder   2000,<PHONE_NUMBER>284000 **

About how long was InfluxDB running before you hit this problem?

Did you have any queries running when you hit this problem? If so, what were they?

I'm having a similar problem with memory usage growing to consuming the entire machine and never really dropping back.  There are three main data streams of incoming data using the InfluxDB Go client to different databases:

50 points/sec in batches of 1000
Telegraf data at 10s intervals for system metrics of a few hosts
84 points/sec in batches of 10000

Occasionally, a Grafana client will pull 5-20 queries to draw charts but it isn't a constant request rate.  We're recently starting to consume considerable swap space.  The node has 128GB (usually between 80-98% of memory used) and has been up for 30d.

I'm having the exact issues as everyone here. During inserts my memory usage jumps over 8G  and then influx throws error about memory allocation failure (my VM is limited to ~8GB RAM). I've tried settings proposed by @lpc921 in his post here:
  cache-snapshot-memory-size = 262144
  cache-snapshot-write-cold-duration = "0h1m0s"
  compact-full-write-cold-duration = "0h1m0s"

It didn't change a thing.
Guys, seriously. This issue has been open for half a year. For me this is a critical issue which rules out usage of influx on a production environments.

@carbolymer It looks like you have sparse data (stock prices) which ends up creating hundreds of small shards.  In your docker sample, I'd recommend increasing the shard group duration on your default retention policy after creating the databases.
For example, running the following before writing data:
alter retention policy default on no_memory shard group duration 520w
will change the shard group duration to 10y which should reduce the number of shards from ~1500 to 4.
I would also suggest setting cache-snapshot-write-cold-duration = "10s".  You should not need to  change compact-full-write-cold-duration or cache-snapshot-memory-size from the default values though.

@carbolymer My server has 48 GB of RAM and 24 high-end CPUs, but it's still not enough for InfluxDB (having 30 GB RAM limit) with just several tens of thousands of daily series (several GB of data). Some queries end after a timeout, other end because Influx reaches the memory limit and crashes. I'm beginning to deeply regret that choice... I have no idea what to do now.

@adampl What kind of data are your writing and what is writing it?  I suspect you have an issue with your schema, but grabbing some profiles when memory is high would help to diagnose:
curl -o heap.txt "localhost:8086/debug/pprof/heap?debug=2"
curl -o goroutine.txt "localhost:8086/debug/pprof/goroutine?debug=2"
curl -o block.txt "localhost:8086/debug/pprof/block?debug=2"

Also, can you attach the output of the following:
influx -execute "show shards" > shards.txt
influx -execute "show stats" > stats.txt
influx -execute "show diagnostics" > diagnostics.txt

@jwilder In my case the data is very sparse - just one point a day in each series - so I've dropped the entire database in order to try that trick with shard duration, and now the data is being loaded again. If the timeouts and crashes don't disappear, I'll provide you with the diagnostics.

@jwilder Increasing shard duration indeed helped (set to 1000w) - now I don't get OOMs as it takes "only" 5 GB and doesn't go up.
Still, requests covering all of the measurement's data take long to complete (15 seconds) - much longer than simply reading all of the measurement's rows from text file, filtering them by tags and aggregating in Python on a single process (2 seconds).

@adampl What version are you running?

Version 0.13 on CentOS 7

@adampl I'd suggest upgrading to the 1.0beta3 release or latest nightly.  There are many query optimization since 0.13.

Ok, I'll give it a try. Meanwhile, please look into #6994 which is a very serious functional bug IMHO.

@jwilder Many thanks! It helped.

@carbolymer  Have you solved the problem？  please tell me some solutions, thank you

@DavidSoong128, yes. This worked for me: https://github.com/influxdata/influxdb/issues/5440#issuecomment-233230997
You can find working configuration in the latest commit on master on https://github.com/carbolymer/influxdb-large-memory-proof

@carbolymer  ok, thank you for your reply, i will do some tests。 If there is any question, ask again


Make the Neural Net ready to call UI functions

Need to make sure, we can return:

[ ] train score
[ ] test score
[ ] list of points
[ ] list of predictions

/assign

/area modelling

/priority high

Was fixed /close


WAS problem with UF background tasks like lucene indexes due to wrong

component being used - does not use EJB for async operations but simple
thread pool and thus has no access to CDI beans, fails with:
java.lang.ClassCastException:
com.ibm.ejs.container.deploy.java.util.concurrent.EJSLocal0SGSimpleAsyncExecutorService_ef40626b
incompatible with org.uberfire.commons.async.SimpleAsyncExecutorService
Revert "by implement an interface, it makes easy to mock"
This reverts commit bae32af57249f244937718b40fa67b58b039494f.

uberfire
(master) http://github.com/uberfire/uberfire/commit/9dc372239
(0.7.x) http://github.com/uberfire/uberfire/commit/b76731bc6

Thanks @porcelli !


Display Target Goal Amount

Feature Request
Firstly my apologies if I have done this wrong. I am new to contributing, but am keen to help.
This feature is for those who use the budget subcategory name to show the target goal amount for each category.
eg:

This is ok, however when you edit the goal amount, you then have to edit it again in the budget subcategory name.
If anybody is interested, I have created the feature and created a pull request.
I have also made it work with the existing Add Goals Indication feature.
eg:

Still to do:

Update goal value when edited.
Fix styles.
Find correct changedNodes event for Target Balance Date.
Insert two decimal places (.00) for items without cents.
Insert comma for thousands (1,000.00).

@danieldbird You should use ynab.YNABSharedLib.currencyFormatter.format(ynab.YNABSharedLib.currencyFormatter.convertToMilliDollars(value)) (where value is the variable to be formatted) to get the amount formatted. That handles all the different currencies that YNAB supports so you don't have to do it. That'll knock the last two items off your list.

Wow that's great thanks David. I appreciate your help. Updated.

Can I ask a few questions?

I am using a mac, and chrome. I find that I have to ./build twice in order for changes to take effect in the browser. Have you faced this before, is that normal, is it a caching thing?
Is it not good of me to be putting css inline in my javascript/jquery? Is there a better way?
The white gradient background here is the only thing left that bugs me, it looks pretty fugly.
 do you know of any trick to know if the row is checked/highlighted and if so, turn my gradient background colour to: #005a6e

@danieldbird

I also use a Mac/Chrome and have to run ./build twice to get the changes updated. Not sure why. I've tried running ./clean and then ./build without luck. Need ./build twice.

I wouldn't say that is an issue. In the old code files you could injectCss files, but I'm not sure if that is available in this new structure yet.

I added a PR #1 on your fork that adds some code to the observe which will update that background color. It also includes some reworking of the jQuery appends to avoid CSS (as was mentioned in my PR #745).

@alanhoskins Fantastic thanks! Yeah, the double ./build issue is strange.

@danieldbird  @alanhoskins  I'm on Windows and for code in the /sauce/ directory I do have to do 2 builds to pick up changes. I've not had the time to track down why it's necessary.
I was going to comment about the inline CSS but didn't because injecting CSS for a feature using the new sauce structure isn't supported yet. It will be in time but I suspect everyone is so busy right now they don't have time to determine the best approach. I know @blargity and @joshmadewell are aware of it. Once it's sorted, you will want to move the CSS to a separate file and just add classes to the appropriate elements.

Sorry, I accidentally removed the fork and orphaned this old pull request. I created a new one.

Cool, I'll go ahead and close it then, thanks!


[jax_dynamic_shapes] clean_up_dead_vars removes variable which may still be referenced when using jax_dynamic_shapes

Description
Hi,
we are using JAX to generate StableHLO and we are interested in abstracted_axes and ranked tensors with dynamic/unknown shapes. We have already contributed a couple of pull requests [0], [1]. We are interested in continuing contributing another pull request for the following issue:
When jax.jiting a function with jax.config.update("jax_dynamic_shapes", True)  this function will raise a KeyError in the following example.
import jax

jax.config.update("jax_enable_x64", True)
jax.config.update("jax_platform_name", "cpu")
jax.config.update("jax_dynamic_shapes", True)

@jax.jit
def f(s):
    a = jax.numpy.ones(s)
    b = jax.numpy.ones(s)
    return a + b

f((1,))

with the following stack trace:
--------------------

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/erick.ochoalopez/Code/cataliist/test.py", line 13, in <module>
    f((1,))
  File "/home/erick.ochoalopez/Code/env/lib/python3.10/site-packages/jax/_src/traceback_util.py", line 166, in reraise_with_filtered_traceback
    return fun(*args, **kwargs)
  File "/home/erick.ochoalopez/Code/env/lib/python3.10/site-packages/jax/_src/pjit.py", line 253, in cache_miss
    outs, out_flat, out_tree, args_flat, jaxpr = _python_pjit_helper(
  File "/home/erick.ochoalopez/Code/env/lib/python3.10/site-packages/jax/_src/pjit.py", line 166, in _python_pjit_helper
    out_flat = pjit_p.bind(*args_flat, **params)
  File "/home/erick.ochoalopez/Code/env/lib/python3.10/site-packages/jax/_src/core.py", line 2597, in bind
    return self.bind_with_trace(top_trace, args, params)
  File "/home/erick.ochoalopez/Code/env/lib/python3.10/site-packages/jax/_src/core.py", line 390, in bind_with_trace
    out = trace.process_primitive(self, x, params)
  File "/home/erick.ochoalopez/Code/env/lib/python3.10/site-packages/jax/_src/core.py", line 822, in process_primitive
    return primitive.impl(*tracers, **params)
  File "/home/erick.ochoalopez/Code/env/lib/python3.10/site-packages/jax/_src/pjit.py", line 1209, in _pjit_call_impl
    return xc._xla.pjit(name, f, call_impl_cache_miss, [], [], donated_argnums,
  File "/home/erick.ochoalopez/Code/env/lib/python3.10/site-packages/jax/_src/pjit.py", line 1192, in call_impl_cache_miss
    out_flat, compiled = _pjit_call_impl_python(
  File "/home/erick.ochoalopez/Code/env/lib/python3.10/site-packages/jax/_src/pjit.py", line 1125, in _pjit_call_impl_python
    compiled = _pjit_lower(
  File "/home/erick.ochoalopez/Code/env/lib/python3.10/site-packages/jax/_src/pjit.py", line 1259, in _pjit_lower
    return _pjit_lower_cached(jaxpr, in_shardings, out_shardings, *args, **kwargs)
  File "/home/erick.ochoalopez/Code/env/lib/python3.10/site-packages/jax/_src/pjit.py", line 1301, in _pjit_lower_cached
    return pxla.lower_sharding_computation(
  File "/home/erick.ochoalopez/Code/env/lib/python3.10/site-packages/jax/_src/profiler.py", line 314, in wrapper
    return func(*args, **kwargs)
  File "/home/erick.ochoalopez/Code/env/lib/python3.10/site-packages/jax/_src/interpreters/pxla.py", line 1968, in lower_sharding_computation
    nreps, tuple_args, shape_poly_state) = _cached_lowering_to_hlo(
  File "/home/erick.ochoalopez/Code/env/lib/python3.10/site-packages/jax/_src/interpreters/pxla.py", line 1808, in _cached_lowering_to_hlo
    lowering_result = mlir.lower_jaxpr_to_module(
  File "/home/erick.ochoalopez/Code/env/lib/python3.10/site-packages/jax/_src/interpreters/mlir.py", line 729, in lower_jaxpr_to_module
    lower_jaxpr_to_fun(
  File "/home/erick.ochoalopez/Code/env/lib/python3.10/site-packages/jax/_src/interpreters/mlir.py", line 1070, in lower_jaxpr_to_fun
    out_vals, tokens_out = jaxpr_subcomp(ctx.replace(name_stack=callee_name_stack),
  File "/home/erick.ochoalopez/Code/env/lib/python3.10/site-packages/jax/_src/interpreters/mlir.py", line 1223, in jaxpr_subcomp
    axis_size_env = {d: read(d)[0]
  File "/home/erick.ochoalopez/Code/env/lib/python3.10/site-packages/jax/_src/interpreters/mlir.py", line 1223, in <dictcomp>
    axis_size_env = {d: read(d)[0]
  File "/home/erick.ochoalopez/Code/env/lib/python3.10/site-packages/jax/_src/interpreters/mlir.py", line 1161, in read
    return env[v]
jax._src.traceback_util.UnfilteredStackTrace: KeyError: a

The stack trace below excludes JAX-internal frames.
The preceding is the original exception that occurred, unmodified.

(Please note that to run this example you'll likely need to [0] and [1])
I've narrowed it down to an error in last_used and clean_up_dead_vars inlined below
def last_used(jaxpr: Jaxpr) -> dict[Var, JaxprEqn | None]:
  """Returns a mapping from every var in jaxpr to what equation uses it last."""
  last_used: dict[Var, JaxprEqn | None] = {
      v: None for v in jaxpr.outvars if not isinstance(v, Literal)}
  for eqn in reversed(jaxpr.eqns):
    for v in eqn.invars:
      if not isinstance(v, Literal) and v not in last_used:
        last_used[v] = eqn
  return last_used

def clean_up_dead_vars(eqn: JaxprEqn, env: dict[Var, Any],
                       last_used: dict[Var, JaxprEqn | None]):
  """Remove all eqn.invars from env if eqn is the last time they were used."""
  for v in {v for v in eqn.invars if not isinstance(v, Literal)}:
    if last_used[v] is eqn:
      # Delete ref to variable when it is no longer needed by next equations.
      del env[v]

What happens is that last_used does not look for the variable v in eqn.outvars types. When using jax_dynamic_shapes, jaxpr variables may be part of types. Since last_used does not look at the type of the variables for potential last uses, it will eventually return an instruction which is before the actual last use of the variable. The variable will be deleted by clean_up_dead_vars and later on, will result in the error above being raised.
I am happy to discuss possible solutions to this and submit a PR sometime (perhaps next year?).
Thanks!
What jax/jaxlib version are you using?
0.4.21
Which accelerator(s) are you using?
CPU
Additional system info?
1.26.1 3.10.11 (main, May 13 2023, 12:07:51) [GCC 9.4.0] uname_result(system='Linux', node='DL7420-GS4N1J3', release='5.15.0-88-generic', version='#98~20.04.1-Ubuntu SMP Mon Oct 9 16:43:45 UTC 2023', machine='x86_64')
NVIDIA GPU info
No response

Just a small correction, the patches mentioned in the issue description (inlined below) are not needed to reproduced this error:

(Please note that to run this example you'll likely need to https://github.com/google/jax/pull/18579 and https://github.com/google/jax/pull/18505)

The description will be updated to remove the need of these patches to reproduce this error.


Add "form" attribute to buttons of type="submit"

🙋 Feature Request
It would be nice to have a "form" attribute for React Spectrum Buttons, when they are of type="submit".
🔦 Context
See the following example coming from the React Spectrum examples page:
<DialogTrigger>
  <ActionButton>Register</ActionButton>
  {(close) => (
    <Dialog>
      <Heading>
        <Flex alignItems="center" gap="size-100">
          <Book size="S" />
          <Text>Register for newsletter</Text>
        </Flex>
      </Heading>
      <Header>
        <Link>
          <a href="//example.com" target="_blank">
            What is this?
          </a>
        </Link>
      </Header>
      <Divider />
      <Content>
        <Form>
          <TextField label="First Name" placeholder="John" autoFocus />
          <TextField label="Last Name" placeholder="Smith" />
          <TextField label="Street Address" placeholder="123 Any Street" />
          <TextField label="City" placeholder="San Francisco" />
        </Form>
      </Content>
      <Footer>
        <Checkbox>
          I want to receive updates for exclusive offers in my area.
        </Checkbox>
      </Footer>
      <ButtonGroup>
        <Button variant="secondary" onPress={close}>
          Cancel
        </Button>
        <Button variant="cta" onPress={close}>
          Register
        </Button>
      </ButtonGroup>
    </Dialog>
  )}
</DialogTrigger>

The dialog is nicely designed, and the content is kept separate in the <Heading>, <Content>, and <Footer>.
Problem is that the ButtonGroup, which very likely contains a submit button in such Dialogs, belongs to the Footer, i.e. it's not contained within the <Form> component – hence it can't act as a Button of type="submit".
In HTML it's possible to add a form attribute to a submit Button, so that it can work regardless to its positioning. E.g.
<form id="aForm">
  <!-- stuff -->
</form>
<button type="submit" form="aForm">Submit</button>

A similar possibility for <Form> and React Buttons would be nice to have.
Thanks!

@undavide Allowing the form attribute on a button seems pretty reasonable, lemme double check with the team just in case.

@undavide Allowing the form attribute on a button seems pretty reasonable, lemme double check with the team just in case.

I'm guessing this is related to wanting the enter key to trigger the submit button's action? I'm having a hard time imagining wanting to submit a form via the browser which would trigger a full page reload.
If so, it seems related to #855

I'm guessing this is related to wanting the enter key to trigger the submit button's action? I'm having a hard time imagining wanting to submit a form via the browser which would trigger a full page reload.
If so, it seems related to #855

Uhm, actually no, my feat request was specifically only about being able to use a submit button when the button itself can't be inside the <form>

Uhm, actually no, my feat request was specifically only about being able to use a submit button when the button itself can't be inside the <form>

i think there are some other libraries out there regarding forms that usually really on a submit button being present in the form to handle submit

i think there are some other libraries out there regarding forms that usually really on a submit button being present in the form to handle submit

Since the <Button> component in Spectrum is an implementation of the native <button> element, shouldn't it support all the native attributes?
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#attr-form

I have a similar use case where I was trying to put a form inside the content area of a dialog, and then include a submit button in the footer of the dialog, because wrapping the input and submit buttons in the same <Form> component was breaking the dialog layout.

I think Button should also have name, formmethod and formaction attributes. They are all very useful when working with forms. And in frameworks like remix-run forms are used to trigger any actions (they do not trigger full reloads like it was mentioned earlier). In some cases this approach makes it simpler to implement a basic experience even if JavaScript fails for some reason.

I'm struggling with the same Issue. My very ugly workaround right now is to add
  useEffect(() => {
    ref.current?.UNSAFE_getDOMNode().setAttribute("form", "new-field-form");
  }, [ref]);

I've also run into this issue. I have a situation where I'm trying to deal with a nested form. The natural conclusion is instead to have self-closing forms with ids that the inputs then refer to. This doesn't seem possible to do with react-spectrum.

As outlined in https://github.com/adobe/react-spectrum/discussions/6481, I think this is a very important issue, as this would be universally applicable & areas of application are manifold. The Dialog modal component is perfect for submitting any kind of form data, and as @undavide pointed out, the great default design should not be compromised in order to achieve something like that - up to now, I put ButtonGroup inside Content and added the margin etc myself, having to integrate Footer manually, and well .. sigh


Implement "simple" strategy

I'm trying to automate the following manual strategy:

Set a buy order as -0.5% of the current price
Keep open order until bought
If buy order does not occur during 1 hour, reset the buy order to -0.5% of the current price
If buy order occurs, set a sell order as +1.0% of the bought price
Keep open order until sold
Repeat the cycle

This strategy works well in a growing market with moderate-high price volatility (like BTC/USD, ETH/USD, LTC/USD), and earns a higher return than buy-hold strategy. The problem I'm facing is the need to automate the process, in order to set the sell/buy orders right after the trade is complete to avoid missing on opportunities.
I haven't found this type of strategy in zenbot, and think it would be a great addition.
Thanks to everyone for a help to implement it!

This issue was moved to highvelocityspace/zenbot#45


树莓派安装后显示快捷键错误，点击没反应

return request('get', url, params=params, **kwargs)
File "/home_ _ z Z Z LD 128k 四季予你  -  程响  < 四季予你 >pi.py", line 61, in request
return session.request(method=method, url=url, **kwargs)
File "/home/pi/.local/lib/python3.7/site-packages/requests_cache/core.py", line 136, in request
**kwargs
File "/home/pi/.local/lib/python3.7/site-packages/requests/sessions.py", line 542, in request
resp = self.send(prep, **send_kwargs)
File "/home/pi/.local/lib/python3.7/site-packages/requests_cache/core.py", line 104, in send
response, timestamp = self.cache.get_response_and_time(cache_key)
File "/home/pi/.local/lib/python3.7/site-packages/requests_cache/backends/base.py", line 70, in get_response_and_time
if key not in self.responses:
File "/usr/lib/python3.7/_collections_abc.py", line 666, in contains
self[key]
File "/home/pi/.local/lib/python3.7/site-packages/requests_cache/backends/storage/dbdict.py", line 169, in getitem
return pickle.loads(bytes(super(DbPickleDict, self).getitem(key)))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 1: ordinal not in range(128)
能进去界面，但是快捷键没反应，确认键可以，也能正常播放

Try this:
pip3 install -U --user requests-cache

requests-cache 0.6.3 may fix this issue.

Try this:
pip3 install -U --user requests-cache

requests-cache 0.6.3 may fix this issue.

Try this:
pip3 install -U --user requests-cache

requests-cache 0.6.3 may fix this issue.
下载你的  pip3 install -U --user requests-cache  显示错误如下，还是不能用数字键

netease-musicbox 0.3.1 has requirement requests-cache<0.6.0,>=0.5.2, but you'll have requests-cache 0.6.3 which is incompatible.
Installing collected packages: requests-cache
Successfully installed requests-cache-0.6.3

The message "...requirement requests-cache<0.6.0,>=0.5.2..." is due to this line in pyproject.toml. I believe musicbox 0.3.1 and requests-cache 0.6.3 are compatible, though.
Do you still get the message "UnicodeDecodeError: 'ascii' codec can't decode byte..."? It is possible that there are old items in the cache created with python 2, and encoded with ascii instead of utf-8.
Try clearing the cache:
python -c "\
import NEMbox.api; \
import requests_cache; \
requests_cache.clear()"

Or a different way to do the same thing, by deleting the cache file directly:
cache_path=$(python -c "from NEMbox.api import Constant; print(Constant.cache_path)")
echo $cache_path
rm $cache_path

no  UnicodeDecodeError: 'ascii' codec can't decode byte...
还是不行，清除了缓存，我点数字后再点j或k会跳过点的数字，比如指标在0，点了数字5在点j，指标就会在5那里，像是加了个5一样。。。

Oh, that's strange! These might be 2 separate problems, then. I don't have any more ideas about the shortcut keys, sorry!


Added Django CORS Functionality and Limited Users Token Creation

What's this PR do?
By default servers send a NOT ALLOW CROSS ORIGIN REQUEST to the client so that no request to another server can be sent. The offline client works as a local server that will load a page and then post data to the server to authenticate. Therefore we need a CROS ORIGIN REQUEST HEADER. Right now I left the ALLOW_ALL_ORIGINS in setting and in production we can define which origins.
Also there was a discussion in an issue of limiting Tokens just for ADMINISTRACION and CAPTURISTA users.
Where should the reviewer start?
jp2_online/settings/base.py
jp2_online/settings/production.py
perfiles_usuario/models.py
requirements/base.txt
How should this be manually tested?
python manage.py test
flake8
Any background context you want to provide?
https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
This template was adapted ~stolen~ from Quickleft/Sprint.ly

Codecov Report

Merging #28 into develop will decrease coverage by -0.33%.
The diff coverage is 75%.

@@             Coverage Diff             @@
##           develop      #28      +/-   ##
===========================================
- Coverage     93.2%   92.88%   -0.33%
===========================================
  Files           54       54
  Lines          574      576       +2
===========================================
  Hits           535      535
- Misses          39       41       +2

Impacted Files
Coverage Δ

jp2_online/urls.py
100% <ø> (ø)
:white_check_mark:

jp2_online/settings/production.py
0% <ø> (ø)
:white_check_mark:

jp2_online/settings/base.py
95.65% <100%> (+0.19%)
:white_check_mark:

perfiles_usuario/models.py
94.44% <100%> (-5.56%)
:x:

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 bd75b87...41b0c7f. Read the comment docs.


Dear Mr Li Hongmin,

I am a data science student at the University of Paris, France. I made a scientific poster on this article,
and I would like to contribute with you to publish it,
because I like your work and I am interested in the research in machine learning,
I did not find your email so please contact me on<EMAIL_ADDRESS>Regards,

Hello ,
Thanks for your reply the poster is about ENSEMBE LEARNING FOR SPECTRAL CLUSTERING article , we did it as course project, and if it's okay i want to know if we can publish it ,
you can find the poster attached,
Regards,
https://drive.google.com/file/d/1w16im4tT-26ICundECcdlFcEEylXLqXZ/view?usp=sharing

Hello Abderraouf Zoghbi, Thank you for your comment. I am not sure which paper you refer to.  Regards, —————————————————— Hongmin Li Department of Computer Science University of Tsukuba Tsukuba, Japan @.***
…
On Feb 17, 2022, at 10:17, Raouf Zoghbi @.> wrote: I am a data science student at the University of Paris, I made a scientific poster on this article, and I would like to contribute with you to publish it, because I like your work and I am interested in the research in machine learning, I did not find your email so please contact me on: @. @.***>. Regards, — Reply to this email directly, view it on GitHub <#1>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMZLPZ5KMY75CUTEEUIHYDU3REEHANCNFSM5OTH5OIA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you are subscribed to this thread.

Hello,
Thanks for your reply the poster is for ENSEMBLE LEARNING FOR SPECTRAL CLUSTERING paper , it is a school project but i would like to know if we can publish this work with you and the other conterbutors ,
You can find the poster attached bellow,
Regards,
https://drive.google.com/file/d/1w16im4tT-26ICundECcdlFcEEylXLqXZ/view?usp=sharing

Hello Abderraouf Zoghbi,
Thank you to ask me this.
Please do not publish this poster.
Because it is literally copyright infringement.
Your post just introduces my work.
I am sorry that you may only show this in your school project.
Regards,
——————————————————
Hongmin Li
Department of Computer Science University of Tsukuba
Tsukuba, Japan
@.***

On Feb 17, 2022, at 20:27, Raouf Zoghbi @.***> wrote:
Hello,
Thanks for your reply the poster is for ENSEMBLE LEARNING FOR SPECTRAL CLUSTERING paper , it is a school project but i would like to know if we can publish this work with you and the other conterbutors ,
You can find the poster attached bellow,
Regards,
https://drive.google.com/file/d/1w16im4tT-26ICundECcdlFcEEylXLqXZ/view?usp=sharing https://drive.google.com/file/d/1w16im4tT-26ICundECcdlFcEEylXLqXZ/view?usp=sharing
—
Reply to this email directly, view it on GitHub https://github.com/Li-Hongmin/MyPaperWithCode/issues/1#issuecomment-1042851016, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMZLP5XJYZZKGHK2DFET5TU3TLSZANCNFSM5OTH5OIA.
Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.


Primer page content

The content of the "Primer" page is missing:
https://iot-campus-metaverse-hackathon.github.io/primer/

Done, the page is hidden for now.


V6 testdoc

There was some missing documentation on how to run some basic tests on v6.
The transactional (functional) tests have a new api. And Forge and Smoke Tests are the latest frameworks to this version. Those were undocumented.
We've also added and 0L specific smoke tests based on the added Forge/Smoketests architecture.

@corynthian this may be the missing piece to some of your issues.

LGTM


Add ordering feature

[ ] ordering in the backend
[ ] option to choose the order in front end : order, alphabetical, created date | asc,desc

ReorderBehaviour is already implemented by the Slide model, we just need to improve the back-end with such a feature :)


Update with Image frontend buttons

🔗 Issue
https://github.com/rubyforgood/pet-rescue/issues/592
✍ Description

Overview: Update the dashboard to allow staff to manage Page Text options, including updating Hero Text, About Us text, and corresponding images on the organization's root/home page.
Implementation:

Utilize PageText model with has_one_attached :hero_image and has_many_attached :about_us_images.
Add form inputs for attachments on the PageText form: one clearly labeled for Hero Image (single attachment) and one for About Us images (one or two attachments).
Implement model validations for image file type and size restrictions, referencing the Pets Controller for examples.
Update PageTextsController to handle image attachments and purging.
Ensure staff can upload and purge images.
Reuse partials for upload inputs and image display tables, similar to those used in Pet tabs.
On the org's root/home page, render the hero_image and one or both about_us_images as applicable, with a default image for the second if only one is uploaded.

Testing:

Modify tests to accommodate changes to the page_text model. Pay special attention to these modifications.

I do not like how the about us images upload but I could use a little feedback
📷 Screenshots/Demos

Hey @ErinClaudio the implementation looks good! Just a couple small details to tweak.
For tests, I think we can handle setting up the PageText differently - see my comment on that.
I also think we could add a controller test for uploading an image.
Also, when I run the tests locally, this test keeps failing for me (though in the pipeline it passes, so maybe there's something going on locally for me...does it pass for you locally?
Organizations::PageTextsControllerTest#test_: PATCH #update should update page text.  [test/controllers/organizations/page_texts_controller_test.rb:53]:
Expected: "canine caped crusader"
  Actual: "Eius id minus et."


Added reciprocal links for all components

Added links between all related components

@mlmsmith This PR is empty? I'll close for now but if you update the branch we can re-open

Sorry about that Josh, not sure what happened there. I've made a new PR with some actual changes in it


Update getting-started.md

@DEEPANSHU-KUSHWAHA - since there's just one 'next step' this should stay as is.
@msangapu-msft - if you disagree and would like to proceed, ping me and I'll reopen this PR. thanks!


Preview causing infinite reloading loop in Chrome and Firefox

Versions

package_name: v0.1.0
node: v16.13.1

Reproduction
Using preview in Chrome and Firefox causes infinite reloading loop. Works as expected in Safari.
Steps to reproduce
Create slicemachine Next.js project, and use this guide to set up Previews.
What is expected?
Preview to load once and not cause infinite reloading loop.
What is actually happening?
Preview is in infinite reloading loop.

Hey @draykefriesen is it possible at all that you can show me a repo where this issue is happening?

Same problem, I noticed if I comment the redirectToPreviewURL on pages/api/preview.js it stops reloading
import { createClient, linkResolver } from '../../utils/prismicHelpers'
import * as prismicNext from '@prismicio/next'

export default async (req, res) => {
  const client = createClient({ req })
  await prismicNext.setPreviewData({ req, res })
  // await prismicNext.redirectToPreviewURL({ req, res, client, linkResolver }) <- this line is causing an infinite reload
}

So it probably has to be something wrong with this function?
https://github.com/prismicio/prismic-next/blob/db8ca224edf10b4de8384782f4bab32df69ec47f/src/redirectToPreviewURL.ts#L75-L95

Hey, @dayhaysoos
Not sure if this is linked, but I had this issue of the preview in a reloading loop when I wrongly setup my preview in my prismic repository. In the domain name name I had put "http" instead of "https". When I added the "s" it fixed it.
maybe it can help to solve the issue?

Hey, @dayhaysoos Not sure if this is linked, but I had this issue of the preview in a reloading loop when I wrongly setup my preview in my prismic repository. In the domain name name I had put "http" instead of "https". When I added the "s" it fixed it. maybe it can help to solve the issue?

Maybe can be one problem that can cause this, but in my case Is still http because I'm using preview on localhost:3000 (as it's on the docs at this moment)

Similar issue here.
First preview is ok (toward a domain.localhost:3000, NextJS 12.1.4), I save and preview from prismic.io and can navigate to differents page without issue.
But if I modify the url address manually (just press enter), or if I do a change from prismic.io and save, it start an infinite reload loop.
Other issue, more nextJS side I think, is the fact that the preview feature seems not handling perfectly my _middleware that redirect / toward /dashboard if there is a JWT request.cookie.  And so the prismic preview get me to / at first and require me to navigate again to /, to get the right /dashboard rewrite (by the _middleware handling).

Hey everyone, thanks for the details. I will be looking into why this is happening and coming up with a solution.
Could everyone provide me details about their app?

Do you use basePath in your app? If not, do you have any other setup that changes your app's URLs (middleware, i18n, etc.)?
Are you using the recommended /api/preview and /api/exit-preview API endpoints? If not, what are they?

This will help me understand how <PrismicPreview> should support your setup, or identify extra config that is necessary for your app.
Thanks!

Some background info on why the infinite refresh happens: Prismic lets you share preview sessions with others by clicking the Get a sharable link button in the Prismic toolbar. This will only appear when you are in a preview session.
When a users visits the shared preview link, the following happens:

User visits the Prismic URL.
It sets a cookie that identifies the preview session.
User is redirected to your app's page where the shareable preview link was created.
Your app sees the Prismic cookie, but also sees that Next.js's Preview Mode is not active.
Your app fetches the Preview Mode endpoint (/api/preview by default) to set the Preview Mode cookie.
Your app refreshes the page, now with Preview Mode active.

If the Preview Mode cookie is not set in Step 5 for any reason, such as accessing the incorrect API endpoint, Steps 4-6 get stuck in an infinite loop.

@jeremytenjo @guilhermefront @chamois-d-or @webda2l
Could you try out a new alpha version, v0.2.0-alpha.0, and let me know if it fixes any of the infinite reloading issues?
npm install @prismicio/next@alpha

This version adds support for basePath if you app uses it. It also includes some extra protections against infinite loops when the preview hooks do not work as expected. In some cases, you may see a console error that provides more details.
Thanks!

Hey everyone, thanks for the details. I will be looking into why this is happening and coming up with a solution.
Could everyone provide me details about their app?
1. Do you use [`basePath`](https://nextjs.org/docs/api-reference/next.config.js/basepath) in your app? If not, do you have any other setup that changes your app's URLs (middleware, i18n, etc.)?

No basePath, only a middleware as explain earlier.
export const middleware = async (request: NextRequest) => {
  if (request.nextUrl.pathname === '/') {
    if (!request.cookies[COOKIE_JWT_HP]) {
      return
    }

    const url = request.nextUrl.clone()
    url.pathname = routes.dashboard
    return NextResponse.redirect(url)
  }
}

2. Are you using the recommended `/api/preview` and `/api/exit-preview` API endpoints? If not, what are they?

Yes

3. Are you using an Incognito or some kind of private window for previews?

No

This will help me understand how <PrismicPreview> should support your setup, or identify extra config that is necessary for your app.
Thanks!
Some background info on why the infinite refresh happens: Prismic lets you share preview sessions with others by clicking the Get a sharable link button in the Prismic toolbar. This will only appear when you are in a preview session.
When a users visits the shared preview link, the following happens:
1. User visits the Prismic URL.

2. It sets a cookie that identifies the preview session.

3. User is redirected to your app's page where the shareable preview link was created.

4. Your app sees the Prismic cookie, but also sees that Next.js's Preview Mode is not active.

5. Your app fetches the Preview Mode endpoint (`/api/preview` by default) to set the Preview Mode cookie.

6. Your app refreshes the page, now with Preview Mode active.

If the Preview Mode cookie is not set in Step 5 for any reason, such as accessing the incorrect API endpoint, Steps 4-6 get stuck in an infinite loop.

@jeremytenjo @guilhermefront @chamois-d-or @webda2l
Could you try out a new alpha version, v0.2.0-alpha.0, and let me know if it fixes any of the infinite reloading issues?
npm install @prismicio/next@alpha

This version adds support for basePath if your app uses it (see #20 for more details). It also includes some extra protections against infinite loops when the preview hooks do not work as expected. In some cases, you may see a console error that provides more details.
Thanks!

No improvement on my side with a custom type 'container' case.
const DashboardPage: INextPageWithLayout = () => {
  const { checkingAuth } = useAuthRequired()

  const [document, { state, error }] = usePrismicDocumentByUID(
    'container',
    'banner'
  )

  if (checkingAuth || state !== 'loaded') return <ContainerLoading />

  return (
    <Wrapper>
      ...

      <SliceZone
        slices={document.data.slices}
        components={components}
        context={{ misc: 'misc' }}
      />

      ...

I succeed to preview once the page, but if I do a change & save from prismic.io, or press enter in the url address bar, it start looping.
It's not an usual case as explain earlier, and I suspect an issue with Next & middleware https://github.com/prismicio/prismic-next/issues/13#issuecomment-1087491282. I'll see that with them later maybe, so if your alpha release fix the problem for others, feel free to close the issue.
Because, on another case, with a more classic use of Prismic in the way of yours example projects and documentation, the preview works well as expected. :)
const PrismicPage: INextPageWithLayout = ({ slices }) => (
  <>
    <SliceZone slices={slices} components={components} />
  </>
)
...

@jeremytenjo @guilhermefront @chamois-d-or @webda2l
Could you try out a new alpha version, v0.2.0-alpha.0, and let me know if it fixes any of the infinite reloading issues?
npm install @prismicio/next@alpha

This version adds support for basePath if your app uses it (see #20 for more details). It also includes some extra protections against infinite loops when the preview hooks do not work as expected. In some cases, you may see a console error that provides more details.
Thanks!

Still having the same problem.

Do you use basePath in your app? If not, do you have any other setup that changes your app's URLs (middleware, i18n, etc.)?

We don't use basePath, but we have trailingSlash set to true (changing it to false didn't solve here)

Are you using the recommended /api/preview and /api/exit-preview API endpoints? If not, what are they?

Yes

Are you using an Incognito or some kind of private window for previews?

No

Hey everyone, I still have not been able to track down or reproduce this issue. Could someone (@webda2l or @guilhermefront?) share a project that gets stuck in an infinite loop during a preview?
I'll need the following to test on my side:

The Next.js project. This could be your actual project or a minimal reproduction.
The name of the Prismic repository used in the Next.js project.
The name and type of the document that triggers the infinite refresh when previewing (if it only occurs for certain documents).

If you would like to send this privately, you can send me a direct message on the Prismic community forum with this link: https://community.prismic.io/new-message?username=angeloashmore&title=@prismicio/next - GitHub Issue 13
Thank you!

Same issue here, infinite reloading the website.

Hey everyone, after more investigations, it looks like the issue roots from the Prismic Toolbar, not necessarily @prismicio/next.
A PR fixing two bugs was opened here: https://github.com/prismicio/prismic-toolbar/pull/97
I am working toward getting the fix deployed. Once it is available, I'll post here again to ask everyone to test their previews again. Thank you for your patience! 🙏

Hey everyone, a quick update: The Prismic team is working on validating the toolbar PR link above before deploying publicly.
Once it is available to test, I'll post here again. Thank you!

Hey there, thank you all for your contribution and patience 🙏
The fixed toolbar was deployed at the beginning of July, you should no longer experience the above.
If you still do, feel free to reopen this issue or to open a new one :)


Feature add AsyncMoya

:sparkles:

Add Async way to make request with MoyaProvider
Add documentation

@BasThomas Hi ✋🏻, can you make review my PR?)

@ashfurrow hi) can you help me with review?)

@thejohnlima fix docs

@BasThomas Hi✋🏻, can you merge PR or rereview him?)

Hey, this is awesome @gre4ixin, thanks! Unfortunately, I don't currently have the bandwidth to review / merge this.

@BasThomas should I contact someone else or wait until the bandwidth is available?)

I'll ask some people 👍

I'll ask some people 👍

Thank you)

@BasThomas Hi) have you any updates?)

@BasThomas Hi) have you any updates?)

Unfortunately not. I'll see if I can set some time aside to review this! :)

Can we add some tests?

@BasThomas add tests)

Can we add some tests?

done ✅

After we've come up with a change of the name for Task, I want to do a pass at improving some of the documentation and then I think this is ready to be merged. Thanks again, @gre4ixin 🙏

@gre4ixin can you check the Xcode project? It seems like this has not been set up properly — I can only see the MoyaProvider+Async file.

@gre4ixin can you check the Xcode project? It seems like this has not been set up properly — I can only see the MoyaProvider+Async file.

Yes, I found a bug, I edited only through Package.swift

@gre4ixin can you check the Xcode project? It seems like this has not been set up properly — I can only see the MoyaProvider+Async file.

fixed

@BasThomas looks good 👍🏻
AsyncTask has been deleted?

Hm, I still see it here. I did rename the file from AliasTask to AsyncTask, though

@BasThomas I think, AsyncTask can be deleted, if you renamed Task to HttpTask)

I have indeed changed Task to HTTPTask, but it still has a typealias for compatibility reasons.
We can remove it and deprecate AsyncTask in a future release. :)

Hi, Has there been any progress on this PR? Task is now conflicting with Task in the standard library.

Is there any progress on this PR?

@gre4ixin Thanks for the PR, any progress on merging into master?


Temporary fix for release notes

Summary
Older release notes are not getting detected properly due to a probable reno bug. This fixes the issue temporarily.
Details and comments
Fixes #

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 69.137%

Totals

Change from base Build<PHONE_NUMBER>:
0.1%

Covered Lines:
2052

Relevant Lines:
2968

💛  - Coveralls


IN 865_867

Hi,
Can i get full information details regarding IN 865_867 frequency plan used in chripstack network server.toml file.

Please refer to the Regional Parameters Specification at https://lora-alliance.org/resource-hub.