Performance problems intermittently when using Direct + TCP connection mode

Describe the bug
Performance problems intermittently when using Direct + TCP connection mode
To Reproduce
Create documents at a slow rate, say 1 every 30 seconds
 _cosmosClient = new CosmosClient(
        connectionString,
        new CosmosClientOptions
        {
            SerializerOptions = new CosmosSerializationOptions
            {
                Indented = true,
                IgnoreNullValues = false,
                PropertyNamingPolicy = CosmosPropertyNamingPolicy.CamelCase
            },
        }
    );

Expected behavior
Once the initial warmup is complete most create requests should occur with 1 second.
Actual behavior
Intermittent performance tanks when a new connection needs to be established up to 3 seconds
Environment summary
SDK Version: 3.20.1
OS Version (e.g. Windows, Linux, MacOSX): Linux & MacOS
Additional context
During initial warmup, a connection is being established
DocDBTrace Information: 0 : Opened 1 channels to server rntbd://bluprdapp02-docdb-1.documents.azure.com:14078/
DocDBTrace Information: 0 : Awaiting RNTBD channel initialization. Request URI:
    rntbd://bluprdapp02-docdb-1.documents.azure.com:14078/apps/b3102e89-1a41-41aa-b073-4499e437059e/services/ce2b2f6a-f698-449b-8885-400b488915ac/partitions/d95a78a2-6efc-4818-bbc2-f6f8a9993cbb/replicas/132640708438632430s/
DocDBTrace Information: 0 : RNTBD: ConnectUnicastPortAsync connecting to rntbd://bluprdapp02-docdb-1.documents.azure.com:14078/ (address <IP_ADDRESS>)
DocDBTrace Information: 0 : RNTBD connection established <IP_ADDRESS>:49861 -> <IP_ADDRESS>:14078
DocDBTrace Information: 0 : RNTBD SSL handshake complete <IP_ADDRESS>:49861 -> <IP_ADDRESS>:14078

During a subsequent interaction (within 60 seconds), the transaction is interrupted by establishing a connection to a new replica (adding 500+ms overhead)
DocDBTrace Information: 0 : Opened 1 channels to server rntbd://bluprdapp02-docdb-1.documents.azure.com:14000/
DocDBTrace Information: 0 : Awaiting RNTBD channel initialization. Request URI:
    rntbd://bluprdapp02-docdb-1.documents.azure.com:14000/apps/b3102e89-1a41-41aa-b073-4499e437059e/services/ce2b2f6a-f698-449b-8885-400b488915ac/partitions/d95a78a2-6efc-4818-bbc2-f6f8a9993cbb/replicas/132666907683438758s/
DocDBTrace Information: 0 : RNTBD: ConnectUnicastPortAsync connecting to rntbd://bluprdapp02-docdb-1.documents.azure.com:14000/ (address <IP_ADDRESS>)
DocDBTrace Information: 0 : RNTBD connection established <IP_ADDRESS>:49910 -> <IP_ADDRESS>:14000
DocDBTrace Information: 0 : RNTBD SSL handshake complete <IP_ADDRESS>:49910 -> <IP_ADDRESS>:14000

How do you decide when initial warm up is complete? If connections to replicas are still being created it seems like it is still being warmed up.

By executing the same transaction repeatedly insert x into container y repeated about every 30 seconds.
Presumably, the first request or two will be slower but should stabilize.

What is the P99 during 1 Hr? Initial requests are expected to be slower

Looking at dependency logs in appinsights 99% is varies from 500ms to 1300ms

App insights tracks TCP requests? I thought it only tracked HTTP requests, if so, then it is tracking metadata requests, not the actual operations.
Are you following the https://docs.microsoft.com/en-us/azure/cosmos-db/performance-tips-dotnet-sdk-v3-sql#sdk-usage and using a singleton client for the lifetime of the application and executing on Direct mode and on the same region as the Cosmos DB account? Can you share Diagnostics of requests that are slow?

Yes to performance tips, client is a singleton, i also added a custom telemetry handler to capture the tcp requests via the CustomHandlers functionality.

Can you share Diagnostics for the operations where you see high latency? 500ms is rather high for TCP requests if it's within the same Azure region as the Cosmos DB endpoint.

{
  "name": "Typed FeedIterator ReadNextAsync",
  "id": "fd2f7bed-6aa7-44fb-9243-26d24fd557da",
  "caller info": {
    "member": "OperationHelperWithRootTraceAsync",
    "file": "ClientContextCore.cs",
    "line": 219
  },
  "start time": "05:37:09:198",
  "duration in milliseconds": 3629.9801,
  "data": {
    "Client Configuration": {
      "Client Created Time Utc": "2021-07-16T13:34:48.1308952Z",
      "NumberOfClientsCreated": 2,
      "User Agent": "cosmos-netstandard-sdk/3.20.1|3.19.3|1|X64|Linux 5.4.0-1031-azure 32 18.|.NET 5.0.8|S|",
      "ConnectionConfig": {
        "gw": "(cps:50, urto:10, p:False, httpf: False)",
        "rntbd": "(cto: 5, icto: -1, mrpc: 30, mcpe: 65535, erd: False, pr: ReuseUnicastPort)",
        "other": "(ed:False, be:False)"
      },
      "ConsistencyConfig": "(consistency: NotSet, prgns:[])"
    }
  },
  "children": [
    {
      "name": "Create Query Pipeline",
      "id": "6a3a1b07-b48e-4d45-a3de-ea455866eb4d",
      "caller info": {
        "member": "TryCreateCoreContextAsync",
        "file": "CosmosQueryExecutionContextFactory.cs",
        "line": 85
      },
      "start time": "05:37:09:198",
      "duration in milliseconds": 3629.9842,
      "children": [
        {
          "name": "Get Container Properties",
          "id": "b45e6abc-b27d-4b2c-bce9-76fc4cca69e9",
          "caller info": {
            "member": "GetCachedContainerPropertiesAsync",
            "file": "ClientContextCore.cs",
            "line": 366
          },
          "start time": "05:37:09:198",
          "duration in milliseconds": 0.0128,
          "children": [
            {
              "name": "Get Collection Cache",
              "id": "774a9421-83e7-4aac-9e50-7ba59a190343",
              "caller info": {
                "member": "GetCollectionCacheAsync",
                "file": "DocumentClient.cs",
                "line": 546
              },
              "start time": "05:37:09:198",
              "duration in milliseconds": 0.0016
            }
          ]
        },
        {
          "name": "Gateway QueryPlan",
          "id": "82489187-e45d-48d9-833f-b55812371a10",
          "caller info": {
            "member": "GetQueryPlanThroughGatewayAsync",
            "file": "QueryPlanRetriever.cs",
            "line": 112
          },
          "start time": "05:37:09:198",
          "duration in milliseconds": 0.3808
        },
        {
          "name": "Microsoft.Azure.Cosmos.Handlers.RequestInvokerHandler",
          "id": "c16d983e-4b52-447a-9d98-e9a7602ebc1f",
          "start time": "05:37:09:198",
          "duration in milliseconds": 3629.9478,
          "children": [
            {
              "name": "Redacted.Handlers.CosmosTelemetryHandler",
              "id": "c3b32862-b9bf-431d-8544-9ecace5fa610",
              "start time": "05:37:09:198",
              "duration in milliseconds": 3629.9367,
              "children": [
                {
                  "name": "Microsoft.Azure.Cosmos.Handlers.DiagnosticsHandler",
                  "id": "c33e687c-94f6-493e-8bec-53f23ca35207",
                  "start time": "05:37:09:198",
                  "duration in milliseconds": 3629.8174,
                  "data": {
                    "CPU Load History": {
                      "CPU History": "(2021-07-16T17:36:18.4625852Z 0.000), (2021-07-16T17:36:28.4586757Z 0.000), (2021-07-16T17:36:38.4581050Z 0.000), (2021-07-16T17:36:48.4631065Z 25.000), (2021-07-16T17:36:58.4580107Z 0.000), (2021-07-16T17:37:08.4561119Z 0.000)"
                    }
                  },
                  "children": [
                    {
                      "name": "Microsoft.Azure.Cosmos.Handlers.RetryHandler",
                      "id": "b061ff1c-5e18-4293-816f-e2c9eafaf01f",
                      "start time": "05:37:09:198",
                      "duration in milliseconds": 3629.813,
                      "children": [
                        {
                          "name": "Microsoft.Azure.Cosmos.Handlers.RouterHandler",
                          "id": "17f77cc2-95d0-4d73-9a5f-94954afa426e",
                          "start time": "05:37:09:198",
                          "duration in milliseconds": 3629.8027,
                          "children": [
                            {
                              "name": "Microsoft.Azure.Cosmos.Handlers.TransportHandler",
                              "id": "41339d3c-fa07-445d-9aea-ea0c123de025",
                              "start time": "05:37:09:198",
                              "duration in milliseconds": 3629.7987,
                              "children": [
                                {
                                  "name": "Microsoft.Azure.Cosmos.GatewayStoreModel Transport Request",
                                  "id": "6d75e693-8d28-4a3d-bae5-0ed06f9cde35",
                                  "caller info": {
                                    "member": "ProcessMessageAsync",
                                    "file": "TransportHandler.cs",
                                    "line": 109
                                  },
                                  "start time": "05:37:09:198",
                                  "duration in milliseconds": 3629.7482,
                                  "data": {
                                    "Client Side Request Stats": {
                                      "Id": "AggregatedClientSideRequestStatistics",
                                      "ContactedReplicas": [],
                                      "RegionsContacted": [],
                                      "FailedReplicas": [],
                                      "AddressResolutionStatistics": [],
                                      "StoreResponseStatistics": [],
                                      "HttpResponseStats": [
                                        {
                                          "StartTimeUTC": "2021-07-16T17:37:09.8278543Z",
                                          "DurationInMs": 0.0008,
                                          "RequestUri": "https://redacted.documents.azure.com/dbs/VehicleConditions/colls/ConditionSet/docs",
                                          "ResourceType": "Document",
                                          "HttpMethod": "POST",
                                          "ActivityId": "c9b0e602-4fc6-4c82-9dd3-56253e88ea1c",
                                          "ExceptionType": "System.Threading.Tasks.TaskCanceledException",
                                          "ExceptionMessage": "The operation was canceled."
                                        },
                                        {
                                          "StartTimeUTC": "2021-07-16T17:37:12.8284202Z",
                                          "DurationInMs": 0.0006,
                                          "RequestUri": "https://redacted.documents.azure.com/dbs/VehicleConditions/colls/ConditionSet/docs",
                                          "ResourceType": "Document",
                                          "HttpMethod": "POST",
                                          "ActivityId": "c9b0e602-4fc6-4c82-9dd3-56253e88ea1c",
                                          "StatusCode": "OK"
                                        }
                                      ]
                                    },
                                    "PointOperationStatisticsTraceDatum": {
                                      "Id": "PointOperationStatistics",
                                      "ActivityId": null,
                                      "ResponseTimeUtc": "2021-07-16T17:37:12.8284674Z",
                                      "StatusCode": 200,
                                      "SubStatusCode": 0,
                                      "RequestCharge": 0,
                                      "RequestUri": "dbs/VehicleConditions/colls/ConditionSet",
                                      "ErrorMessage": null,
                                      "RequestSessionToken": null,
                                      "ResponseSessionToken": null,
                                      "BELatencyInMs": null
                                    }
                                  }
                                }
                              ]
                            }
                          ]
                        }
                      ]
                    }
                  ]
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}

Bump

What is the max CPU on the machine? It's the only thing I can think of that might be an issue. If the max is low then I would recommend creating a support ticket so the Cosmos DB service team can investigate.

P1V2 App Service Plan

CPU is playing poker

Is that the max or the average CPU? Most of the time it defaults to the average which can hide spikes that max out the CPU.

Good call this is the max graph

Performance problems were caused by thread starvation (event at low CPU %), ensure cancelation tokens are passed and avoid using small sync queries like these
var item = _db.GetItemLinqQueryable<Entities.EntityName>(true)
    .Where(a => a.Id == id.ToLower())
    .AsEnumerable()
    .FirstOrDefault();


unable to build and run in yarn workspaces pnp monorepo

What version of Remix are you using?
1.7.0
Steps to Reproduce

create a basic yarn monorepo with pnp enabled
create the remix starter app in a workspace using yarn dlx create-remix@latest with the default options for everything
run yarn build in the workspace
additionally try to run yarn start in the workspace

Expected Behavior
it should build and run as normal, like how it is for a non-monorepo setup
Actual Behavior
yarn build will output the following warnings:
The path "@remix-run/react" is imported in app/root.tsx but "@remix-run/react" was not found in your node_modules. Did you forget to install it?
The path "react/jsx-runtime" is imported in app/routes/index.tsx but "react/jsx-runtime" was not found in your node_modules. Did you forget to install it?
The path "@remix-run/node" is imported in app/entry.server.tsx but "@remix-run/node" was not found in your node_modules. Did you forget to install it?
The path "react-dom/server" is imported in app/entry.server.tsx but "react-dom/server" was not found in your node_modules. Did you forget to install it?

doing some quick digging, the real errors are being suppressed here. adding a console.log to see the real errors, we can observe the following output:
Error: @remix-run/dev tried to access react, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.

Required package: react (via "react/jsx-runtime")
Required by: @remix-run/dev@virtual:e293270790bda2411a3626e57e15862403457209cbe755a222c752c37c8f53870ac5708914fca9c46ad11f81505a4af613c8b5e4bba765909191bb5f14d3b656#patch:@remix-run/dev@npm%3A1.7.0#./.yarn/patches/@remix-run-dev-npm-1.7.0-fe40e11b54.patch::version=1.7.0&hash=2d868d&locator=remix-yarn-pnp-monorepo-broken-repro%40workspace%3A. (via /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/@remix-run-dev-patch-f7da19538b-3b067b8179.zip/node_modules/@remix-run/dev/dist/compiler/plugins/)

Require stack:
- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>    at Function.require$$0.Module._resolveFilename (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.pnp.cjs:20639:13)
    at Function.resolve (node:internal/modules/cjs/helpers:108:19)
    at /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/@remix-run-dev-patch-f7da19538b-3b067b8179.zip/node_modules/@remix-run/dev/dist/compiler/plugins/serverBareModulesPlugin.js:82:21
    at callback (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/unplugged/esbuild-npm-0.14.51-a22b50b89c/node_modules/esbuild/lib/main.js:930:34)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async handleRequest (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/unplugged/esbuild-npm-0.14.51-a22b50b89c/node_modules/esbuild/lib/main.js:710:30)
The path "react/jsx-runtime" is imported in app/routes/index.tsx but "react/jsx-runtime" was not found in your node_modules. Did you forget to install it?
Error: @remix-run/dev tried to access @remix-run/react, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.

Required package: @remix-run/react
Required by: @remix-run/dev@virtual:e293270790bda2411a3626e57e15862403457209cbe755a222c752c37c8f53870ac5708914fca9c46ad11f81505a4af613c8b5e4bba765909191bb5f14d3b656#patch:@remix-run/dev@npm%3A1.7.0#./.yarn/patches/@remix-run-dev-npm-1.7.0-fe40e11b54.patch::version=1.7.0&hash=2d868d&locator=remix-yarn-pnp-monorepo-broken-repro%40workspace%3A. (via /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/@remix-run-dev-patch-f7da19538b-3b067b8179.zip/node_modules/@remix-run/dev/dist/compiler/plugins/)

Require stack:
- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>    at Function.require$$0.Module._resolveFilename (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.pnp.cjs:20639:13)
    at Function.resolve (node:internal/modules/cjs/helpers:108:19)
    at /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/@remix-run-dev-patch-f7da19538b-3b067b8179.zip/node_modules/@remix-run/dev/dist/compiler/plugins/serverBareModulesPlugin.js:82:21
    at callback (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/unplugged/esbuild-npm-0.14.51-a22b50b89c/node_modules/esbuild/lib/main.js:930:34)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async handleRequest (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/unplugged/esbuild-npm-0.14.51-a22b50b89c/node_modules/esbuild/lib/main.js:710:30)
The path "@remix-run/react" is imported in app/root.tsx but "@remix-run/react" was not found in your node_modules. Did you forget to install it?
Error: @remix-run/dev tried to access react, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.

Required package: react (via "react/jsx-runtime")
Required by: @remix-run/dev@virtual:e293270790bda2411a3626e57e15862403457209cbe755a222c752c37c8f53870ac5708914fca9c46ad11f81505a4af613c8b5e4bba765909191bb5f14d3b656#patch:@remix-run/dev@npm%3A1.7.0#./.yarn/patches/@remix-run-dev-npm-1.7.0-fe40e11b54.patch::version=1.7.0&hash=2d868d&locator=remix-yarn-pnp-monorepo-broken-repro%40workspace%3A. (via /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/@remix-run-dev-patch-f7da19538b-3b067b8179.zip/node_modules/@remix-run/dev/dist/compiler/plugins/)

Require stack:
- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>    at Function.require$$0.Module._resolveFilename (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.pnp.cjs:20639:13)
    at Function.resolve (node:internal/modules/cjs/helpers:108:19)
    at /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/@remix-run-dev-patch-f7da19538b-3b067b8179.zip/node_modules/@remix-run/dev/dist/compiler/plugins/serverBareModulesPlugin.js:82:21
    at callback (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/unplugged/esbuild-npm-0.14.51-a22b50b89c/node_modules/esbuild/lib/main.js:930:34)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async handleRequest (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/unplugged/esbuild-npm-0.14.51-a22b50b89c/node_modules/esbuild/lib/main.js:710:30)
Error: @remix-run/dev tried to access @remix-run/node, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.

Required package: @remix-run/node
Required by: @remix-run/dev@virtual:e293270790bda2411a3626e57e15862403457209cbe755a222c752c37c8f53870ac5708914fca9c46ad11f81505a4af613c8b5e4bba765909191bb5f14d3b656#patch:@remix-run/dev@npm%3A1.7.0#./.yarn/patches/@remix-run-dev-npm-1.7.0-fe40e11b54.patch::version=1.7.0&hash=2d868d&locator=remix-yarn-pnp-monorepo-broken-repro%40workspace%3A. (via /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/@remix-run-dev-patch-f7da19538b-3b067b8179.zip/node_modules/@remix-run/dev/dist/compiler/plugins/)

Require stack:
- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>    at Function.require$$0.Module._resolveFilename (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.pnp.cjs:20639:13)
    at Function.resolve (node:internal/modules/cjs/helpers:108:19)
    at /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/@remix-run-dev-patch-f7da19538b-3b067b8179.zip/node_modules/@remix-run/dev/dist/compiler/plugins/serverBareModulesPlugin.js:82:21
    at callback (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/unplugged/esbuild-npm-0.14.51-a22b50b89c/node_modules/esbuild/lib/main.js:930:34)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async handleRequest (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/unplugged/esbuild-npm-0.14.51-a22b50b89c/node_modules/esbuild/lib/main.js:710:30)
The path "@remix-run/node" is imported in app/entry.server.tsx but "@remix-run/node" was not found in your node_modules. Did you forget to install it?
Error: @remix-run/dev tried to access @remix-run/react, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.

Required package: @remix-run/react
Required by: @remix-run/dev@virtual:e293270790bda2411a3626e57e15862403457209cbe755a222c752c37c8f53870ac5708914fca9c46ad11f81505a4af613c8b5e4bba765909191bb5f14d3b656#patch:@remix-run/dev@npm%3A1.7.0#./.yarn/patches/@remix-run-dev-npm-1.7.0-fe40e11b54.patch::version=1.7.0&hash=2d868d&locator=remix-yarn-pnp-monorepo-broken-repro%40workspace%3A. (via /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/@remix-run-dev-patch-f7da19538b-3b067b8179.zip/node_modules/@remix-run/dev/dist/compiler/plugins/)

Require stack:
- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>    at Function.require$$0.Module._resolveFilename (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.pnp.cjs:20639:13)
    at Function.resolve (node:internal/modules/cjs/helpers:108:19)
    at /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/@remix-run-dev-patch-f7da19538b-3b067b8179.zip/node_modules/@remix-run/dev/dist/compiler/plugins/serverBareModulesPlugin.js:82:21
    at callback (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/unplugged/esbuild-npm-0.14.51-a22b50b89c/node_modules/esbuild/lib/main.js:930:34)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async handleRequest (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/unplugged/esbuild-npm-0.14.51-a22b50b89c/node_modules/esbuild/lib/main.js:710:30)
Error: @remix-run/dev tried to access react-dom, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.

Required package: react-dom (via "react-dom/server")
Required by: @remix-run/dev@virtual:e293270790bda2411a3626e57e15862403457209cbe755a222c752c37c8f53870ac5708914fca9c46ad11f81505a4af613c8b5e4bba765909191bb5f14d3b656#patch:@remix-run/dev@npm%3A1.7.0#./.yarn/patches/@remix-run-dev-npm-1.7.0-fe40e11b54.patch::version=1.7.0&hash=2d868d&locator=remix-yarn-pnp-monorepo-broken-repro%40workspace%3A. (via /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/@remix-run-dev-patch-f7da19538b-3b067b8179.zip/node_modules/@remix-run/dev/dist/compiler/plugins/)

Require stack:
- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>    at Function.require$$0.Module._resolveFilename (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.pnp.cjs:20639:13)
    at Function.resolve (node:internal/modules/cjs/helpers:108:19)
    at /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/@remix-run-dev-patch-f7da19538b-3b067b8179.zip/node_modules/@remix-run/dev/dist/compiler/plugins/serverBareModulesPlugin.js:82:21
    at callback (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/unplugged/esbuild-npm-0.14.51-a22b50b89c/node_modules/esbuild/lib/main.js:930:34)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async handleRequest (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/unplugged/esbuild-npm-0.14.51-a22b50b89c/node_modules/esbuild/lib/main.js:710:30)
The path "react-dom/server" is imported in app/entry.server.tsx but "react-dom/server" was not found in your node_modules. Did you forget to install it?
Error: @remix-run/dev tried to access react, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.

Required package: react (via "react/jsx-runtime")
Required by: @remix-run/dev@virtual:e293270790bda2411a3626e57e15862403457209cbe755a222c752c37c8f53870ac5708914fca9c46ad11f81505a4af613c8b5e4bba765909191bb5f14d3b656#patch:@remix-run/dev@npm%3A1.7.0#./.yarn/patches/@remix-run-dev-npm-1.7.0-fe40e11b54.patch::version=1.7.0&hash=2d868d&locator=remix-yarn-pnp-monorepo-broken-repro%40workspace%3A. (via /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/@remix-run-dev-patch-f7da19538b-3b067b8179.zip/node_modules/@remix-run/dev/dist/compiler/plugins/)

Require stack:
- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/<EMAIL_ADDRESS>    at Function.require$$0.Module._resolveFilename (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.pnp.cjs:20639:13)
    at Function.resolve (node:internal/modules/cjs/helpers:108:19)
    at /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-dev-virtual-bbd09feed6/0/cache/@remix-run-dev-patch-f7da19538b-3b067b8179.zip/node_modules/@remix-run/dev/dist/compiler/plugins/serverBareModulesPlugin.js:82:21
    at callback (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/unplugged/esbuild-npm-0.14.51-a22b50b89c/node_modules/esbuild/lib/main.js:930:34)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async handleRequest (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/unplugged/esbuild-npm-0.14.51-a22b50b89c/node_modules/esbuild/lib/main.js:710:30)

while the build technically succeeds, running yarn start will produce the following output:
/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.pnp.cjs:20639
      Error.captureStackTrace(firstError);
            ^

Error: react-router-dom tried to access react (a peer dependency) but it isn't provided by its ancestors; this makes the require call ambiguous and unsound.

Required package: react
Required by: react-router-dom@virtual:1aa7e1352cb23ad08d7bd7b2186b449bc35ee2f380ace5370abd3a51ac11d7c0a172bf5ad8ac02fb8c152fe5fecd50a67ae363ea21daf8d389772d998655971d#npm:6.3.0 (via /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/react-router-dom-virtual-6ac023fafa/0/cache/react-router-dom-npm-6.3.0-508f6547e5-77603a654f.zip/node_modules/react-router-dom/umd/)

Ancestor breaking the chain: @remix-run/dev@virtual:e293270790bda2411a3626e57e15862403457209cbe755a222c752c37c8f53870ac5708914fca9c46ad11f81505a4af613c8b5e4bba765909191bb5f14d3b656#npm:1.7.0
Ancestor breaking the chain: @remix-run/node@npm:1.7.0

Require stack:
- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/react-router-dom-virtual-6ac023fafa/0/cache/react-router-dom-npm-6.3.0-508f6547e5-77603a654f.zip/node_modules/react-router-dom/umd/react-router-dom.production.min.js
- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/react-router-dom-virtual-6ac023fafa/0/cache/react-router-dom-npm-6.3.0-508f6547e5-77603a654f.zip/node_modules/react-router-dom/main.js
- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-server-runtime-virtual-1aa7e1352c/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-server-runtime-virtual-1aa7e1352c/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-server-runtime-virtual-1aa7e1352c/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-express-virtual-801944238c/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/@remix-run-express-virtual-801944238c/0/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/cache/<EMAIL_ADDRESS>- /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/cache/<EMAIL_ADDRESS>    at Function.require$$0.Module._resolveFilename (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.pnp.cjs:20639:13)
    at Function.require$$0.Module._load (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.pnp.cjs:20493:42)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at /home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/react-router-dom-virtual-6ac023fafa/0/cache/react-router-dom-npm-6.3.0-508f6547e5-77603a654f.zip/node_modules/react-router-dom/umd/react-router-dom.production.min.js:11:79
    at Object.<anonymous> (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.yarn/__virtual__/react-router-dom-virtual-6ac023fafa/0/cache/react-router-dom-npm-6.3.0-508f6547e5-77603a654f.zip/node_modules/react-router-dom/umd/react-router-dom.production.min.js:11:305)
    at Module._compile (node:internal/modules/cjs/loader:1105:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
    at Object.require$$0.Module._extensions..js (/home/reda/Documents/Projects/remix-yarn-pnp-monorepo-broken-repro/.pnp.cjs:20683:33)
    at Module.load (node:internal/modules/cjs/loader:981:32)

reproduction repo: https://github.com/redabacha/remix-yarn-pnp-monorepo-broken-repro

You may want to read through https://github.com/remix-run/remix/issues/683

My npm workspaces monorepo is also failing since the upgrade to 1.7.0. Before everything worked just fine, also when downgrading to 1.6.7.

You may want to read through #683

yep good point. i've read through it all and it gives the impression that pnp is supported and working which doesn't seem to be the case yet given my example.

so i've found three solutions that all seem to work:

add react and react-dom as dependencies of your root level package.json
enable pnpMode: loose in your .yarnrc.yml
add these packageExtensions in your .yarnrc.yml (changing the package names appropriately to whatever runtime you're using),

packageExtensions:
  "@remix-run/dev@*":
    peerDependencies:
      react: "*"
      "react-dom": "*"
  "@remix-run/express@*":
    peerDependencies:
      react: "*"
      "react-dom": "*"
  "@remix-run/node@*":
    peerDependencies:
      react: "*"
      "react-dom": "*"
  "@remix-run/serve@*":
    peerDependencies:
      react: "*"
      "react-dom": "*"

with @remix-run/deno for example:
packageExtensions:
  '@remix-run/deno@*':
    peerDependencies:
      react: '*'
      'react-dom': '*'
  '@remix-run/dev@*':
    peerDependencies:
      react: '*'
      'react-dom': '*'

i went with option 3. to me it looks like the issue is caused by react-router-dom having peer dependencies on both react and react-router-dom that is unable to be resolved as esbuild is running from the context of the @remix-run/dev package which is not aware of the workspace level package.json for the remix app, only the root level package.json.
there's additionally some red herring warnings that come from remix, e.g:
The path "@remix-run/deno" is imported in server.ts but "@remix-run/deno" was not found in your node_modules. Did you forget to install it?
The path "@remix-run/react" is imported in app/entry.server.tsx but "@remix-run/react" was not found in your node_modules. Did you forget to install it?

this is because remix is using require.resolve here without specifying the paths field so it ends up looking at the wrong package.json (from @remix-run/dev instead of the main app package.json) for resolution.

@redabacha thanks for your various P/Rs to help out with Yarn PnP. My project is now working off of those forks to unblock us.
A question: does anyone have path alias imports working correctly? For example, this import import { Hello } from "~/components/Hello";  results in the following error:
[remix] The path "~/components/Hello" is imported in app/routes/hello-demo.tsx but "~/components/Hello" was not found in your node_modules. Did you forget to install it?
[remix] 💿 Rebuilt in 528ms
[remix] Error: Qualified path resolution failed: we looked for the following paths, but none could be accessed.
[remix]
[remix] Source path: /Users/mattste/Developer/vreps/majestic-vreps/apps/dashboard-v2/app/components/Hello
[remix] Not found: /Users/mattste/Developer/vreps/majestic-vreps/apps/dashboard-v2/app/components/Hello
[remix] Not found: /Users/mattste/Developer/vreps/majestic-vreps/apps/dashboard-v2/app/components/Hello.js
[remix] Not found: /Users/mattste/Developer/vreps/majestic-vreps/apps/dashboard-v2/app/components/Hello.json
[remix] Not found: /Users/mattste/Developer/vreps/majestic-vreps/apps/dashboard-v2/app/components/Hello.node
[remix]
[remix] Require stack:
[remix] - /Users/mattste/Developer/vreps/majestic-vreps/apps/dashboard-v2/build/index.js
[remix] - /Users/mattste/Developer/vreps/majestic-vreps/.yarn/__virtual__/@remix-run-serve-virtual-67dad97eda/0/cache/<EMAIL_ADDRESS>
My package.json has this line as shown in the example.
    "~": "link:./app"

With yarn version 3.2.4. none of these workarounds are working for me in my punlic repo
https://github.com/mwoodpatrick/yarn_monorepo/tree/remix-eurodance-stack
Running yarn install in this branch generates the errors below. Any pointers would be most appreciated
➤ YN0000: ┌ Resolution step
➤ YN0032: │ fsevents@npm:2.3.2: Implicit dependencies on node-gyp are discouraged
➤ YN0061: │ rollup-plugin-inject@npm:3.0.2 is deprecated: This package has been deprecated and is no longer maintained. Please use @rollup/plugin-inject.
➤ YN0032: │ node-addon-api@npm:1.7.2: Implicit dependencies on node-gyp are discouraged
➤ YN0061: │ stable@npm:0.1.8 is deprecated: Modern JS already guarantees Array#sort() is a stable sort, so this library is deprecated. See the compatibility table on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#browser_compatibility
➤ YN0061: │ source-map-resolve@npm:0.5.3 is deprecated: See https://github.com/lydell/source-map-resolve#deprecated
➤ YN0061: │ source-map-url@npm:0.4.1 is deprecated: See https://github.com/lydell/source-map-url#deprecated
➤ YN0061: │ resolve-url@npm:0.2.1 is deprecated: https://github.com/lydell/resolve-url#deprecated
➤ YN0061: │ urix@npm:0.1.0 is deprecated: Please see https://github.com/lydell/urix#deprecated
➤ YN0061: │ sane@npm:4.1.0 is deprecated: some dependency vulnerabilities fixed, support for node < 10 dropped, and newer ECMAScript syntax/features added
➤ YN0061: │ chokidar@npm:2.1.8 is deprecated: Chokidar 2 does not receive security updates since 2019. Upgrade to chokidar 3 with 15x fewer dependencies
➤ YN0061: │ fsevents@npm:1.2.13 is deprecated: fsevents 1 will break on node v14+ and could be using insecure binaries. Upgrade to fsevents 2.
➤ YN0061: │ uuid@npm:3.4.0 is deprecated: Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details.
➤ YN0061: │ querystring@npm:0.2.0 is deprecated: The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
➤ YN0032: │ nan@npm:2.17.0: Implicit dependencies on node-gyp are discouraged
➤ YN0032: │ evp_bytestokey@npm:1.0.3: Implicit dependencies on node-gyp are discouraged
➤ YN0000: ⠧ tslib@npm:^1.8.1
Killed

Running "yarn install: in the setup branch works fine
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0000: └ Completed
➤ YN0000: ┌ Link step
➤ YN0000: └ Completed
➤ YN0000: Done in 0s 81ms

Is this still an issue? Here v1.19.1 works fine in a monorepo with yarn workspaces, using pnp.

Cannot reproduce on 1.19.2 nor nightly. This was likely fixed in #4301 when we switched to esbuild's native Yarn PnP handling.

Not sure if this should be a separate issue, but I'm running Remix as one of the apps inside a yarn monorepo with workspaces (no pnp).
I'm getting the following errors, about 20 of those:
 warn  could not resolve "modes/src/.."
┃ You imported "modes/src/.." in app/routes/$slug.tsx,
┃ but that package is not in your `node_modules`.
┃ Did you forget to install it?
┗

I'm using the future.v2_dev, and all of the deps from the monorepo are defined in package.json inside the Remix app.
yarn 1.22.19, node v20.3.1, remix 1.19.3

@rista404 could you share what the modes/src/file import looks like in your app/routes/$slug.tsx?

@rista404 looks like modes/src/file will be interpreted as a modes dependency, so you'd need to configure path aliases to get this working as you intend. If you are having issues with that, feel free to open a separate issue.

@pcattori after upgrading to Remix v2, the warnings are gone. No code change from my side was needed.


JavaScript broken highlight

VSCode Version: 1.5.3
OS Version: Win10

Steps to Reproduce:

Open JS-file
add to begin: { el = data?true:false; }

Exp.: 'true' and 'false' are highlighted
Act.: 'false' is highlighted, but 'true' - not

This is fixed in the latest version of the JS grammar, it will probably come to stable in v1.7 though. You can try it out now by installing this extension https://marketplace.visualstudio.com/items?itemName=ms-vscode.typescript-javascript-grammar


Gif Result does not saves when biuld the project

Hi on unity testing application all works perfect, but when i build it ths gif doesn´t save.. any ideas?

Hi,
Do you run it on mobile or on desktop?

Sorry on desktop but already solved it... was on users folders I made mistake....thks for your quick response


Do not try to use syslog on Windows

Another incremental fix for #825. Is there a better way to do this?
Signed-off-by: anatoly techtonik<EMAIL_ADDRESS>

This pull request didn't trigger Jenkins as its author isn't in the whitelist.
To have this branch tested by Jenkins, comment "jenkins: ok to test"
To have a one time test done, comment "jenkins: test this please"

@stgraber strange. I see Jenking results here https://jenkins.linuxcontainers.org/job/lxd-trigger-github-pr/155/arch=i386,compiler=golang-1.3,restrict=lxd-priv/console

You forgot to run "go fmt ./..."

And yeah, it's strange that jenkins triggered. I wonder if the automatic comment is enough to trigger it, which would be pretty special :)

I'll change the comment to not include the magic strings, hopefully that'll do the trick :)

go fmt ./... is cool. There should be a GitHub plugin for that. =)

But note that I am currently on Windows machine and didn't test on Linux if syslog handler is initialized properly.

Looks like Linux is fine but you broke MacOS :)

@stgraber Done.


Could not properly place hole to a parent

I get the following error when running tippecanoe on a large polygon dataset:
tippecanoe -zg -P -f -o parcels-coalesce.mbtiles -D11 --no-polygon-splitting --coalesce-fraction-as-needed --include=id --include=parcel_intent --include=appellation nz_primary_parcels.geojson
For layer 0, using name "nz_primary_parcels"
nz_primary_parcels.geojson:290347: Reached EOF without all containers being closed
In JSON object {"type":"FeatureCollection","name":"nz_primary_parcels","crs":{"type":"name","properties":{"name":"urn:ogc:def:crs:EPSG::4167"}},"features":[]}
nz_primary_parcels.geojson:338068: Found ] at top level
2580390 features, 422301311 bytes of geometry, 35158737 bytes of separate metadata, 65201523 bytes of string pool
Choosing a maxzoom of -z11 for features about 215 feet (66 meters) apart
Choosing a maxzoom of -z13 for resolution of about 47 feet (14 meters) within features
tile 5/31/20 size is 1027657 with detail 11, >500000
Going to try keeping 46.22% of the features to make it fit
tile 5/31/19 size is 1291787 with detail 11, >500000
Going to try keeping 36.77% of the features to make it fit
tile 5/31/20 size is 746651 with detail 11, >500000
Going to try keeping 29.41% of the features to make it fit
tile 5/31/19 size is 827652 with detail 11, >500000
Going to try keeping 21.10% of the features to make it fit
tile 5/31/20 size is 592952 with detail 11, >500000
Going to try keeping 23.56% of the features to make it fit
tile 5/31/20 size is 529787 with detail 11, >500000
Going to try keeping 21.12% of the features to make it fit
tile 5/31/19 size is 621905 with detail 11, >500000
Going to try keeping 16.12% of the features to make it fit
tile 5/31/20 size is 503675 with detail 11, >500000
Going to try keeping 19.92% of the features to make it fit
tile 5/31/19 size is 544664 with detail 11, >500000
Going to try keeping 14.06% of the features to make it fit
tile 5/31/19 size is 511353 with detail 11, >500000
Going to try keeping 13.06% of the features to make it fit
Could not properly place hole to a parent.
Internal error: Polygon cleaning failed. Log in /tmp/wagyu.log

Contents of wagyu.log is:
Could not properly place hole to a parent.
[[[308,1234],[310,1234],[310,1236],[308,1236],[308,1234]],[[310,1234],[309,1235],[309,1234],[310,1234]],[[308,1235],[309,1235],[308,1236],[308,1235]],[[310,1235],[309,1235],[309,1234],[310,1235]],[[309,1232],[309,1231],[310,1232],[309,1232]],[[310,1232],[311,1232],[309,1231],[310,1232]],[[311,1233],[311,1232],[310,1233],[311,1233]],[[311,1232],[310,1232],[310,1231],[311,1232]],[[312,1232],[311,1232],[311,1231],[312,1232]],[[310,1234],[311,1233],[311,1234],[310,1234]],[[310,1235],[309,1234],[310,1234],[310,1235]],[[310,1234],[311,1234],[311,1235],[310,1234]],[[310,1235],[311,1235],[310,1236],[310,1235]],[[311,1234],[310,1234],[310,1233],[311,1234]],[[311,1234],[312,1233],[312,1234],[311,1234]],[[311,1234],[312,1235],[311,1235],[311,1234]],[[311,1235],[311,1236],[310,1235],[311,1235]],[[309,1235],[308,1237],[308,1236],[309,1235]],[[309,1238],[308,1237],[307,1238],[308,1237],[309,1238]],[[309,1239],[308,1239],[309,1238],[309,1239]],[[309,1237],[308,1238],[308,1237],[309,1237]],[[308,1239],[309,1239],[309,1240],[308,1239]],[[309,1239],[308,1240],[310,1239],[309,1239]],[[310,1236],[311,1237],[310,1237],[310,1236]],[[310,1237],[309,1238],[309,1237],[310,1237]],[[311,1236],[311,1235],[310,1236],[311,1236]],[[311,1236],[311,1237],[310,1236],[311,1236]],[[310,1238],[309,1238],[310,1237],[310,1238]],[[310,1239],[309,1239],[310,1238],[310,1239]],[[310,1240],[309,1239],[310,1239],[310,1240]],[[311,1238],[311,1237],[312,1238],[311,1238]],[[311,1239],[312,1238],[311,1238],[311,1239]],[[311,1239],[310,1238],[311,1238],[311,1239]]]

I have validated the source data in spatialite with Is_valid and all polygons are OGC valid.
Dataset used for the command is: https://www.dropbox.com/s/5fr0gxr8zs7jidt/nz_primary_parcels.geojson.gz?dl=1
Tippecanoe version: v1.34.3

Another questions why is tippecanoe warning about:
nz_primary_parcels.geojson:290347: Reached EOF without all containers being closed
In JSON object {"type":"FeatureCollection","name":"nz_primary_parcels","crs":{"type":"name","properties":{"name":"urn:ogc:def:crs:EPSG::4167"}},"features":[]}
nz_primary_parcels.geojson:338068: Found ] at top level

This geojosn file dataset has been created using ogr:
ogr2ogr -f GEOJSON nz_primary_parcels.geojson -t_srs EPSG:4167 nz-primary-parcels.gpkg

The warning is because -P makes Tippecanoe expect line-delimited GeoJSON, but your input file has a FeatureCollection wrapper around the whole thing. The warning is for the wrapper's extra '[' at the start and ']' at the end.
I'll download your data and see if I can reproduce the polygon problem.

Verified that this polygon still fails with the latest changes to Wagyu, so it is not just a matter of upgrading

The warning is because -P makes Tippecanoe expect line-delimited GeoJSON, but your input file has a FeatureCollection wrapper around the whole thing. The warning is for the wrapper's extra '[' at the start and ']' at the end.

Ok thanks.

Is there someway to see which feature caused this issue, so I can remove it and continue with my testing?

Anything I can do to help here?

It looks like the failing feature is
id: 7203175
appellation: Lot 1 DP 422905
parcel_intent: Fee Simple Title

according to debugging output added in https://github.com/mapbox/tippecanoe/pull/763

Thanks @ericfischer. I will check the feature. For the moment I've rolled back to tippecanoe v1.27.7 which is the last version I used that worked with this dataset.

It looks like the failing feature is

Just looked at the feature. Looks pretty ok to me. Very simple parcel: https://data.linz.govt.nz/x/67w3HU

Thanks. That is very interesting that it used to work. Version 1.27.7 was quite a while ago, but it does include a different version of Wagyu, so I can look at what changed between those versions.

Thank you.

Coincidentally I've just hit the same issue on the same dataset. Have you found any workarounds other than rolling back to v1.27.7 over the past few months?

Sorry, I haven't done anything on this, but I should probably just make it drop impossible holes instead of exiting with an error.

Hi All,
I am encountering the same problem with a large set offered by the Australian Government (ABS mesh data blocks). Is there any plan to resolve this error or is the work around to downgrade to v1.27.7?
Thanks
Cam

Same problem here.

Also faced the same problem with US Census Blocks and can confirm that downgrading to v1.27.7 worked.
For Mac users (credit to this SO answer):
brew uninstall tippecanoe
brew extract --version=1.27.7  tippecanoe homebrew/cask
brew install<EMAIL_ADDRESS>

@palmerj @Darkfish how were you able to resolve this issue?
@e-n-f I have the same issue in the new felt/tippecanoe repo.

@fischja Can you upload a copy of the data file you are having a problem with, and I'll take a look? I no longer have a copy of the nz_primary_parcels and the links above are broken.

@e-n-f are you able to access the data at this link: https://datafinder.stats.govt.nz/layer/111223-meshblock-2023-clipped-generalised/ ? If not I can try and upload the file directly.

Thanks. I'm downloading it from Koordinates now.

I wasn't able to immediately reproduce the problem:
➤ ogr2ogr -f GeoJSONSeq /vsistdout/ /vsizip//Users/enf/Downloads/lds-nz-primary-parcels-SHP.zip/nz-primary-parcels.shp  | gzip > lds-nz-primary-parcels.json.gz
➤ ogr2ogr -f GeoJSONSeq /vsistdout/ /vsizip//Users/enf/Downloads/lds-nz-primary-parcels-SHP.zip/nz-primary-parcels.2.shp  | gzip > lds-nz-primary-parcels.2.json.gz

➤ ./tippecanoe --version
tippecanoe v2.26.1

➤ ./tippecanoe -zg -f -o foo.mbtiles  --no-feature-limit --no-tile-size-limit -P ../lds-nz-primary-parcels*json.gz
For layer 0, using name "ldsnzprimaryparcels2"
For layer 1, using name "ldsnzprimaryparcels"
2691608 features, 566704879 bytes of geometry, 120922410 bytes of string pool
Choosing a maxzoom of -z12 for features typically 195 feet (60 meters) apart, and at least 27 feet (9 meters) apart
Choosing a maxzoom of -z13 for resolution of about 47 feet (14 meters) within features
  99.9%  13/7936/5251

Can you give an example of a data file and invocation that is failing for you?

Thanks @palmerj. @fischja, are you still seeing failures?


Yikes. A Unity asset package that stomps on my ProjectSettings directory!?

(this relates to installing via the Asset store)
Luckily I use version control but this could break people's projects. Assets are surely not meant to do that? I've never seen it before.
At the very least the asset store needs a warning in big glowing fiery text right at the top.
I can imagine this seriously breaking people's projects. Some of the changes seem pretty arbitrary and orthogonal to the purpose of this.
Look to see how SteamVR handles it - they have an editor script that offers to update selected settings and allows you to opt out.

The SteamVR plugin actually did this the same way for a long time. I'd argue it's on Unity to resolve UX issues in terms of package importing.
With the move to UPM packages I don't think there is a generic solution to this yet either - everyone seems to continue being forced to roll their own solution to add/modify project-wide settings.

Hi @andybak sorry to hear that.
Reading this https://unity3d.com/asset-store/sell-assets/submission-guidelines it seems like Unity should show at least a notification isn't it?
4.4.f The Project Settings of your project will be automatically included with any submission being uploaded in the “Complete Projects” category or subcategories. Users will receive a notification that their Project Settings will be replaced when importing your project.
I'm thinking if it would be better to change the project category from Complete project/system to something else like Tools/Integrations or something else, so it won't try to include the project settings, although I'm not sure about the side effects on that, I'll need to test it.

The SteamVR plugin actually did this the same way for a long time.

I started using SteamVR in 2017 and unless I'm misremembering they were using a script with in opt-out to change settings even back then.

I'd argue it's on Unity to resolve UX issues in terms of package importing.

I do agree with this.
In any case the current situation is going to break some projects for the kind of people least able to recover - inexperienced users who don't use version control and have poor back-up discipline. In the short term could you at least add a big warning for those people?
Beyond that - do you have a clear idea what settings changes are essential, which are recommended and which are optional?
Depending on the proportion of each - it might be as simple as documenting them rather than automating things.

I have just pushed a new release with the latests PR merged, and also changed the category of the project from Whole application to Scripting/Integration so it won't include the project settings.
Regarding the settings that should be useful to set are basically two, and I'll document them on the docs:

InputManager.asset: To do the buttons mapping
QualitySettings.asset: Not mandatory but useful for performance.

I hope that fixes your problem.
Thanks again for reporting.


More Mantine V6 updates

Hi @AnnMarieW how did you figure out the fix for ghost headings to be the use of 'href' instead of 'pathname'?

Well,I won’t know for sure until it’s deployed — I never saw those ghost heading when running locally.  However, it does update the URL correctly now, so I’m hoping that fixes it. 🤞


feat(generic/lbaas): add tests for the generic lbaas api

Description
Add  integration tests for the lbaas generic client API.
Release Note
Release note for CHANGELOG:

NONE

References

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Codecov Report

Merging #100 (6e0de6a) into syseng-689/test-cleanup (2b016f0) will increase coverage by 1.69%.
The diff coverage is 60.11%.

:exclamation: Current head 6e0de6a differs from pull request most recent head 49ddf56. Consider uploading reports for the commit 49ddf56 to get more accurate results

@@                     Coverage Diff                     @@
##           syseng-689/test-cleanup     #100      +/-   ##
===========================================================
+ Coverage                    57.16%   58.86%   +1.69%
===========================================================
  Files                           86       89       +3
  Lines                         4081     4242     +161
===========================================================
+ Hits                          2333     2497     +164
+ Misses                        1363     1334      -29
- Partials                       385      411      +26

Flag
Coverage Δ

integration
58.86% <60.11%> (+1.69%)
:arrow_up:

unittests
31.68% <0.00%> (-1.37%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/apis/lbaas/v1/loadbalancer_genclient.go
0.00% <0.00%> (ø)

pkg/lbaas/bind/bind.go
42.95% <ø> (ø)

pkg/lbaas/server/server.go
41.37% <ø> (ø)

pkg/apis/lbaas/v1/frontend_genclient.go
65.07% <52.38%> (+65.07%)
:arrow_up:

pkg/apis/lbaas/v1/backend_genclient.go
64.51% <53.84%> (+64.51%)
:arrow_up:

pkg/apis/lbaas/v1/server_genclient.go
67.24% <67.24%> (ø)

pkg/apis/lbaas/v1/bind_genclient.go
68.85% <68.85%> (ø)

pkg/apis/lbaas/v1/types.go
100.00% <100.00%> (ø)

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 2b016f0...49ddf56. Read the comment docs.


Move Synchronizer classes to their own files

Making the code easier to analyze, for example searching for a word in a file confines the search to one class. No contents are changed. The only possible errors would be compiler errors, but it was also spot checked by playing the game.

Clean. Though might be a good idea to run the run-cross-compile-test.sh script.

will do

Clean. Though might be a good idea to run the run-cross-compile-test.sh script.

will do

Actually I don't have the images locally. I'm going to merge since it won't affect halcyon-zero until the submodule hash is updated, so I can look at the build test on that PR


#33 add not request

Coverage increased (+0.05%) to 88.838% when pulling ce82ffc0c3fe18c33e40d4b36a18fd171c5526a4 on not-request into 46336b0eaa1dae308ff2ed81195734aa7d60078f on master.


[DUX-1223] Package in nixpkgs

From SyncLinear.com | DUX-1223

I didn't even have to do the work for this one! https://github.com/NixOS/nixpkgs/pull/308276


CHIP Framework returns an NSError, even when succeeding

Problem
It appears that we are not handing back nil when commands/requests succeed, but instead an NSError with success in it. We should return nil 👍
CHIP Accessory command sent. Error: Error Domain=CHIPErrorDomain Code=8 "Success." UserInfo={NSLocalizedDescription=Success.}

@woody-apple any idea if this is still an issue or who would know?

Still an issue, but Darwin

@woody-apple I believe this was fixed in #13072.  There is no more "CHIPSuccess" value in CHIPErrorDomain, and we convert CHIP_NO_ERROR to nil when converting it to NSError.


Fixed typos

Fixed typos in the docs

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Functions logging

Problem
Implements feature request https://github.com/aws-amplify/amplify-backend/issues/2058 .
Changes

Add types and converters in platform core for cdk enums
Add new package entry point in platform core to avoid loading cdk eagerly for other purposes (bundling)
Adds cdk as peer dep to platform core (it's already transitive dep via platform-types)
Adds type aliases in backend functions and backend ai packages.

DX

Validation
Added tests
Checklist

[ ] If this PR includes a functional change to the runtime behavior of the code, I have added or updated automated test coverage for this change.
[ ] If this PR requires a change to the Project Architecture README, I have included that update in this PR.
[ ] If this PR requires a docs update, I have linked to that docs PR above.
[ ] If this PR modifies E2E tests, makes changes to resource provisioning, or makes SDK calls, I have run the PR checks with the run-e2e label set.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@sobolk Why logging only and not all CDK supported parameters? See the conversation in #1971
I am grateful for this PR, it is definitely and improvement, just curious about the reasoning behind the limited scope

Thank you for the additional context. If someone really wants all the CDK knobs the can use CDK. Some trade offs are expected with a managed solution such as Amplify.
thank you to you and the other contributors for your work on Amplify!


Cannot migrate from babel-eslint

Currently in the process of integrating typescript in my codebase.
I tried to add the typescript plugin and replace the babel-eslint parser with typescript-eslint-parser in my .eslint
Unfortunately, running eslint will raise countless errors looking like
import/no-named-as-default-member: Resolve error: Expected ']' instead of '"' at line 6 column 5 of the JSON5 data. Still to read: "\"@babel/preset-types"

Have you seen that before ? I cannot find any mention of @babel/preset-types anywhere in my code, so I suppose it's a truncated version of @babel/preset-typescript, and I'm wondering why this happens

my .eslint
extends:
  - eslint-config-with-prettier
  - plugin:redux-saga/recommended
  - plugin:security/recommended

settings:
  react:
    version: 16.6.0
  import/resolver: babel-plugin-root-import

parser: typescript-eslint-parser

plugins:
  - immutable
  - redux-saga
  - security
  - typescript

parserOptions:
  ecmaVersion: 2018
  sourceType: "module"
  allowImportExportEverywhere: false
  codeFrame: false
  ecmaFeatures:
    legacyDecorators: true

globals:
  firebase: true
  requirejs: true
  window: true
  _: true
  expect: true
  jest: true
  # enzyme vars (check jestsetup.js)
  shallow: true
  render: true
  mount: true

env:
  amd: true # for require.js (request() and define())
  browser: true
  commonjs: true
  es6: true
  mocha: true

rules:
  class-methods-use-this: 1
  immutable/no-mutation: 2
  import/named: 1
  import/order: error
  import/no-extraneous-dependencies: 0
  jsx-a11y/anchor-is-valid:
  - error
  - components:
    - Link
    specialLink:
    - to
  no-restricted-syntax:
    - error
    - selector: 'ForInStatement'
      message: 'for..in loops iterate over the entire prototype chain, which is virtually never what you want. Use Object.{keys,values,entries}, and iterate over the resulting array.'
    - selector: 'LabeledStatement'
      message: 'Labels are a form of GOTO; using them makes code confusing and hard to maintain and understand.'
    - selector: 'WithStatement'
      message: '`with` is disallowed in strict mode because it makes code impossible to predict and optimize.'
  no-else-return:
    - "error"
    - allowElseIf: true
  one-var:
    - error
    - var: "always"
  prefer-destructuring:
    - error
    - object: false
  react/jsx-filename-extension: 0
  react/forbid-foreign-prop-types: 1
  strict: 0
  typescript/class-name-casing: "error"
  typescript/no-unused-vars: "error"
  typescript/type-annotation-spacing: "error"

my .tsconfig.json
{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "lib": ["es6", "dom"],
    "allowJs": true,
    "checkJs": true,
    "jsx": "react",
    "sourceMap": true,
    "outDir": "./dist_staging/",
    "rootDir": "src",

    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "noImplicitThis": true,

    "noImplicitReturns": true,

    "moduleResolution": "node",
    "esModuleInterop": true
  },
  "exclude": [
    "node_modules",
    "dist_*",
    "scripts",
    "webpack",
    "jest",
    "coverage",
    "config"
  ],
  "include": [
    "./src/**/*"
  ],
  "types": [
    "typePatches"
  ]
}

figured it out, my .babelrc was broken, unrelated to eslint-plugin-typescript :bowing_man:


Fix shaderpack crashes due to "TESSELATION" typo

I had the same issue as #171.
The start of the stack trace is

java.lang.NoSuchFieldError: TESSELATION_SHADERS

which is probably caused by this recent Iris update.
Fixing the typo in iris-flw-compat stopped the crashes for me.

If anyone else is interested, this is the build:
iris-flywheel-compat-fabric1.20.1+1.1.4.zip


SQL: Fix handling of CURRENT_TIMESTAMP and friends in non-UTC timezones.

Embarrassingly, there was a test for this, but the test case was wrong.

👍

:+1: after travis


Avoid to use volume for oracle

If you remove
VOLUME ["/u01/app/oracle"]

from Dockerfile, it will be not mounted by default (empty) so you can have static databases

Import a dump
save a tag with docker commit
Share image tagged for CI, testing, etc...

https://github.com/albfan/docker-oracle-12c/commit/3a9a3b5327a96d695a6a7fad1e7991b88e83945f

@albfan there was some issues on different platforms. Could you please play around Dockerfile/VOLUME and test it on Windows/Mac/Linux?
Thank you

@albfan it makes sense...

Sure, I can report feedback for Windows/Linux

Windows working correctly. I think that's enough to test this.
The only concern is to clearly document how to use existing databases with volume, but README is well documented

Just seen: https://github.com/MaksymBilenko/docker-oracle-12c/commit/4dd6591b811f0da5b47b01f927adcfb02f5484dd

But now we can not configure this volume from Kitematic.
Can we make some compromise solution?

Opps! https://github.com/docker/kitematic/issues/1923.
@filippetrovic add a volume because a third party app does not work without it seems wrong. You can always extend this dockerfile to have your volume but that's only a workaround for kitematic (someone needs to implement an add volume)

Same thoughts here.
But I'm not sure what is semantic of VOLUME keyword in Dockerfile.
However, I do not insist on reverting this change.


cannot serve

Hi, I posted in the Franklin slack and was asked to open an issue on GitHub. I have never opened an issue before so please let me know if there is anything else I should include.
I was just trying to follow the startup instructions but I couldn't make it past first serve.
julia> newsite("."; template="hyde")
✓ Website folder generated at "/home/rowan/Documents/franklin" (now the current directory).
→ Use serve() from Franklin to see the website in your browser.

julia> serve()
ERROR: TypeError: in typeassert, expected AbstractArray{Bool,N} where N, got Array{Any,1}
Stacktrace:
 [1] filter(::Function, ::UnitRange{Int64}) at ./array.jl:2312
 [2] deactivate_inner_blocks!(::Array{Franklin.OCBlock,1}, ::Array{Any,1}) at /home/rowan/.julia/packages/Franklin/5ZW0D/src/parser/ocblocks.jl:122
 [3] deactivate_inner_blocks! at /home/rowan/.julia/packages/Franklin/5ZW0D/src/parser/ocblocks.jl:98 [inlined]
 [4] #convert_md#125(::Bool, ::Bool, ::Bool, ::Bool, ::Bool, ::Function, ::String, ::Array{Franklin.LxDef,1}) at /home/rowan/.julia/packages/Franklin/5ZW0D/src/converter/markdown/md.jl:73
 [5] #convert_md at ./none:0 [inlined] (repeats 2 times)
 [6] #process_config#185(::Bool, ::Function) at /home/rowan/.julia/packages/Franklin/5ZW0D/src/manager/file_utils.jl:18
 [7] #process_config at ./none:0 [inlined]
 [8] #serve#204(::Bool, ::Bool, ::Int64, ::Bool, ::Bool, ::Bool, ::Bool, ::Bool, ::Bool, ::Bool, ::Bool, ::getfield(Franklin, Symbol("##206#209")), ::Bool, ::String, ::typeof(serve)) at /home/rowan/.julia/packages/Franklin/5ZW0D/src/manager/franklin.jl:76
 [9] serve() at /home/rowan/.julia/packages/Franklin/5ZW0D/src/manager/franklin.jl:62
 [10] top-level scope at none:0

I do not have any of the optional extras installed. Julia 1.1.1 on Ubuntu 20.04.1 LTS.

Thanks! You did the issue thing perfectly.
Re the actual problem I'm a bit stumped; if you try with another template like - say - sandbox, does it work?
Can you also indicate what version of Franklin you're using? using Pkg; Pkg.status() should do the trick.
Sorry about that!
Ps: the extra stuff is not related so no problem on that front

Aaaah wait wait wait; Franklin doesn't work with Julia < 1.3 so that's your issue most likely

thank you!! didn't even realise i was running an old version of julia -- updated and now serve works.

Wonderful, closing then but don't hesitate to reopen if you encounter other issues


Updates go version to 1.22

Chore

I think this can be closed due to this being merged: https://github.com/dapr/kit/pull/105


Nexus 3: Could not find package Nuget.CommandLine

Description
If I use Nexus 3 as nuget package repository (with default configured neget proxy to nuget.org), I got problems with paket. I don't know, if the problem is on the Nexus 3 side or on paket side. So I post the issue to both.
Problem 1:
If I try to resolve the package Nuget.CommandLine I got the following error by paket update command:
C:\Temp\NexusTest>.paket\paket.exe update
Paket version <IP_ADDRESS>
Resolving packages for group Main:
Paket failed with:
        Could not find versions for package Nuget.CommandLine on http://localhost:8081/repository/nuget-group.

Problem 2:
I build our solutions with FAKE. In Interaction with Nexus 3 the paket update  took very long, if I have FAKE in it (I think the problem here is on Nexus 3 side, because it tries to download all the versions of FAKE - and there are a lot of them). And it fails.
C:\Temp\NexusTest>.paket\paket.exe update
Paket version <IP_ADDRESS>
Resolving packages for group Main:
Paket failed with:
        Could not find versions for package FAKE on http://localhost:8081/repository/nuget-group.

Repro steps
I prepared a simple project to reporoduce the steps:
https://github.com/WebDucer/Nexus3PaketIssue

Install the Docker container for Nexus 3

docker run -d -p 2081:8081 --name nuget-repo sonatype/docker-nexus3

Use the project above to execute paket update against nuget.org or Nexus3 as source (comment the unneded sources out).

Expected behavior

paket update should resolve Nuget.CommandLine
paket update should update quicker for packages with a lot of versions

Actual behavior

paket update stops with error if the package Nuget.CommandLine is in it.
paket update need a lot of time, if package FAKE is in it.

Known workarounds
Using of two sources (nuget.org on the first place and Nexus 3 on the second).

why would the empty nexus docker container return versions for NuGet.CommandLine?

After the default installation of Nexus 3 this has three nuget repositories

Nuget proxy (cache for nuget.org => delegate the calls to nuget.org, if no package of desired version is in cache)
Hosted repository (repository to store internal nuget packages)
Group repository (bundle proxy and internal repositories under one URL)

So the call to the group should resolve the packages (works well with a lot of packages)
C:\Temp\NexusTest>.paket\paket.exe update
Paket version <IP_ADDRESS>
Resolving packages for group Main:
 - NUnit 3.4.1
Locked version resolution written to C:\Temp\NexusTest\paket.lock
Garbage collecting FAKE
Garbage collecting NuGet.CommandLine
8 seconds - ready.

C:\Temp\NexusTest>.paket\paket.exe update
Paket version <IP_ADDRESS>
Resolving packages for group Main:
 - FAKE 4.39.1
Locked version resolution written to C:\Temp\NexusTest\paket.lock
Garbage collecting NUnit
1 minute, 27 seconds - ready.

Your screeshot shows Nexus 2 installation, not Nexus 3. In Nexus 3 nuget repositories already configured.

I don't get the nexus 3  docker running
is your command line correct?

p 8081:8081 did the trick. container is running now

lol wtf is this thing doing? Caching all fake versions if you try to install one? WTF

I send already the request to sonatype for this :) Perhaps they have an answer to this strange behaviour.

regarding fake update: second update is much faster. So that's only nexus issue.

regarding NuGet.CommandLine: if you change casing to NuGet.CommandLine it works. so sonatype nexus has a casing issue.

I got the following answer from sonatype:

Hi Eugen,
For Problem 1, I have managed to get it to work if you change the package name from "Nuget.CommandLine" to "NuGet.CommandLine" in the file paket.dependencies.
For Problem 2, I agree it does take a long time.
This is what I see in the request logs of Nexus 3
<IP_ADDRESS> - - [07/Sep/2016:13:38:12 +0100] "GET /repository/nuget-group/FindPackagesById()?id='FAKE' HTTP/1.1" 200 101628 101
<IP_ADDRESS> - - [07/Sep/2016:13:38:12 +0100] "GET /repository/nuget-group/FindPackagesById()?$skip=40&id=%27FAKE%27 HTTP/1.1" 200 101720 109
<IP_ADDRESS> - - [07/Sep/2016:13:38:12 +0100] "GET /repository/nuget-group/FindPackagesById()?$skip=80&id=%27FAKE%27 HTTP/1.1" 200 101766 107
<IP_ADDRESS> - - [07/Sep/2016:13:38:12 +0100] "GET /repository/nuget-group/package-versions/FAKE?includePrerelease=true HTTP/1.1" 404 1823 555
<IP_ADDRESS> - - [07/Sep/2016:13:38:12 +0100] "GET /repository/nuget-group/Packages?$filter=tolower(Id)%20eq%20'fake' HTTP/1.1" 404 1823 1
<IP_ADDRESS> - - [07/Sep/2016:13:38:12 +0100] "GET /repository/nuget-group/FindPackagesById()?$skip=120&id=%27FAKE%27 HTTP/1.1" 200 102144 102
<IP_ADDRESS> - - [07/Sep/2016:13:38:12 +0100] "GET /repository/nuget-group/FindPackagesById()?$skip=160&id=%27FAKE%27 HTTP/1.1" 200 102439 104

I am not familiar with paket and we do not test with paket. Did this paket tool work fine with Nexus 2?
Kind Regards,
Mahendra

as I said: casing bug and to eager caching bug in nexus

Thanks for help.

Can I log the paket requests that goes to Nexus when I execute paket update?

-v will show you some. Also fiddler can help


feat: add aggregated view clusterroles for default user-facing roles

Description
Adds new aggregated view clusterroles for default user-facing roles. I have tested this on a multi-tenant Openshift cluster, and while I earlier was not allowed to see any trivy custom resources as a regular user, I can not view all resources:

Related issues

Close #173

Remove this section if you don't have related PRs.
Checklist

[x] I've read the guidelines for contributing to this repository.
[ ] I've added tests that prove my fix is effective or that my feature works.
[ ] I've updated the documentation with the relevant information (if needed).
[ ] I've added usage information (if the PR introduces new options)
[ ] I've included a "before" and "after" example to the description (if the PR is a user interface change).

I think this addition makes sense, would be good to add some docs about these new roles though

@JAORMX What kind of docs are you looking for regarding this? 🤔

LGTM 🚀


The o1 series models in OpenAI Comatible are unavailable

Which API Provider are you using?
OpenAI Compatible
Which Model are you using?
o1-mini
What happened?
o1 series model available
Steps to reproduce

Relevant API REQUEST output
400 Unsupported value: 'messages[0].role' does not support 'system' with this model.     (request id:<PHONE_NUMBER>2326790343636N33fsPxZ) (request id:<PHONE_NUMBER>2325408245561Q1SPYXHc) (request id:<PHONE_NUMBER>2325377591008u0YwWI8v)

Additional context
Actually, it needs to handle systemPrompt, temperature, and stream for o1 just like with openai native

Dear maintainer,
can you just open the model field name to free input, rather than dropdown? who long of a delay it would bebefore a company launch and update the static enums? one can enter pricing of their own if thats a concern , or add option ignore pricing!
lot of config is broken, you can derive concepts from "continue" extension than building from scratch.

here is a helper library, which auto fetch models! let me know if you need javascript version
from typing import Literal
AvailModels = Literal[
	"openai|gpt-4o",
	"openai|gpt-4",
	"openai|chatgpt-4o-latest",
	"openai|gpt-4o-mini",
	"openai|gpt-4-turbo",
	"openai|gpt-4-0613",
	"openai|gpt-3.5-turbo",
	"openai|gpt-4o-realtime-preview",
	"openai|gpt-4o-audio-preview",
	"openai|ft:gpt-3.5-turbo-0125:personal:doktor:8xHAc2HS",
	"openai|gpt-3.5-turbo-0125",
	"openai|gpt-4-turbo-preview",
	"openai|gpt-4-0125-preview",
	"openai|gpt-3.5-turbo-1106",
	"openai|gpt-4-1106-preview",
	"openai|gpt-3.5-turbo-instruct",
	"openai|gpt-3.5-turbo-16k",
	"openai|gpt-4o-2024-08-06",
	"openai|gpt-4o-2024-05-13",
	"openai|gpt-3.5-turbo-instruct-0914",
	"openai|gpt-4o-mini-2024-07-18",
	"openai|gpt-4-turbo-2024-04-09",
	"openai|gpt-4o-audio-preview-2024-10-01",
	"openai|gpt-4o-realtime-preview-2024-10-01",
	"anthropic|claude-3-5-sonnet-latest",
	"anthropic|claude-3-5-sonnet-20241022",
	"anthropic|claude-3-5-sonnet-20240620",
	"anthropic|claude-3-opus-latest",
	"anthropic|claude-3-opus-20240229",
	"anthropic|claude-3-sonnet-20240229",
	"anthropic|claude-3-haiku-20240307",
	"anthropic|claude-2.1",
	"anthropic|claude-2.0",
	"anthropic|claude-instant-1.2",
	"deepseek|deepseek-chat",
	"deepseek|deepseek-coder",
	"deepinfra|microsoft/WizardLM-2-8x22B",
	"deepinfra|meta-llama/Llama-3.2-90B-Vision-Instruct",
	"deepinfra|meta-llama/Llama-3.2-11B-Vision-Instruct",
	"deepinfra|meta-llama/Meta-Llama-3.1-405B-Instruct",
	"deepinfra|Qwen/Qwen2.5-72B-Instruct",
	"deepinfra|meta-llama/Meta-Llama-3.1-70B-Instruct",
	"deepinfra|meta-llama/Meta-Llama-3.1-8B-Instruct",
	"deepinfra|deepinfra/tts",
	"deepinfra|nvidia/Llama-3.1-Nemotron-70B-Instruct",
	"deepinfra|meta-llama/Meta-Llama-3.1-70B-Instruct-Turbo",
	"ollama|granite3-moe:latest",
	"ollama|llama3.1:8b-instruct-q6_K",
	"ollama|qwen2.5:latest",
	"ollama|mxbai-embed-large:latest",
	"ollama|bge-m3:latest",
	"ollama|deepseek-coder-v2:16b",
	"ollama|starcoder2:latest",
	"ollama|deepseek-coder-v2:16b-lite-instruct-q6_K",
	"google|gemini-1.5-flash",
	"google|gemini-1.5-pro"
]

available via pip install swamix

can you add exact step-by-step to reproduce in #602 ?

please include information like

Calcium-Ion/new-api proxy on localhost:9090 https://github.com/Calcium-Ion/new-api
o1-mini model
cline/cline vs code extension version #.## number(?)

and add your screenshot from https://discord.com/channels/1275535550845292637/1275535550845292640/1316386123798286410
having exact step-by-step to reproduce in #602 would help people in the future who are triaging, reproducing and debugging (if there's a bug) #602

the ask for exact step-by-step to reproduce is from me at https://discord.com/channels/1275535550845292637/1275535550845292640/1316459558994186251

can you add exact step-by-step to reproduce in #602 ?

please include information like

Calcium-Ion/new-api proxy on localhost:9090 https://github.com/Calcium-Ion/new-api
o1-mini model
cline/cline vs code extension version v#.#.# number(?)

and add your screenshot from https://discord.com/channels/1275535550845292637/1275535550845292640/1316386123798286410
having exact step-by-step to reproduce in #602 would help people in the future who are triaging, reproducing and debugging (if there's a bug) in #602

Comalot aka cumalot in Cline Discord #general channel replied:

Maybe I can use your word?

I replied:

yes

Comalot aka cumalot replied:

Get it

Ya thanks a lot

the ask for exact step-by-step to reproduce is from me at https://discord.com/channels/1275535550845292637/1275535550845292640/1316459558994186251

can you add exact step-by-step to reproduce in #602 ?

please include information like

Calcium-Ion/new-api proxy on localhost:9090 https://github.com/Calcium-Ion/new-api
o1-mini model
cline/cline vs code extension version v#.#.# number(?)

and add your screenshot from https://discord.com/channels/1275535550845292637/1275535550845292640/1316386123798286410
having exact step-by-step to reproduce in #602 would help people in the future who are triaging, reproducing and debugging (if there's a bug) in #602

Comalot aka cumalot in Cline Discord #general channel replied:

Maybe I can use your word?

I replied:

yes

Comalot aka cumalot replied:

Get it


Allow nested conditions

Allow Nested conditions in the check.
A lot of packages only use flat map for conditional exports, meaning in the era of ESM, we only have *.module.js for browser.
Example : Jest

@marvinhagemeister do you have any time to look at it ?
I can work on a proposal but first, it would be awesome to have your opinion on the proposed changes (in case I miss something)


fix: array appending and memory problems

Thanks for the PR. Can you add tests to expand the coverage?


[neutron_metadata] Add missing mount

With [1] merged, it requires shared mount
between ovn_metadata_agent and haproxy containers.
Also use variable instead of hardcoded /var/lib/neutron in neutron_dhcp_agent role.
[1] https://github.com/openstack-k8s-operators/edpm-ansible/pull/394

check-rdo

/lgtm

FYI the DNM patch passed with the fix included.


Create documentation for new multi-tenant aggregated view of saved objects [DOC]

What do you want to do?

[ ] Request a change to existing documentation
[x] Add new documentation
[ ] Report a technical problem with the documentation
[ ] Other

Tell us about your request.
OpenSearch security is working to make sharing objects within Dashboards and across tenants an easier and more intuitive experience. In the first stages of this effort, the team has created a new view on the Saved Objects tab in Dashboards, which aggregates all saved objects for all tenants that a user has permissions to.
When a user has access to multiple tenants, this aggregated view of saved objects will allow the user to see all saved objects, either created or shared by the user, and not have to switch between tenants to do so. This issue covers documentation for this new feature.
NOTE: the feature is currently in an experimental phase and will be noted as such in the documentation for now.
What other resources are available?
Dashboards object sharing (replace Dashboards tenants): issue #1869
Across-tenant Saved Object Aggregation View: issue #2249

See PR #1786

Post release fixes: an image and a typo.


undefined: HTMLElementImpl

Hi, I am doing something which wanted to use jquery in typescript, but I got a problem as followed.

when I use jquery to get Html element 'article' or 'body'. their HTMLElement is all undefined and I can't find the reason, do you have some advice?

Is there an actual error you're getting? It seems like vscode might just not understand that we hide our implementation in a symbol, which should not affect anything.

Please provide a small test case (not a screen shot) that we can run using node testfile.js and that produces the error.

Closing, happy to reopen if a repro case is provided.


Error pushing new branch with first letter Capital

Issue Type: Bug
When creating a new branch through VS Code an error is shown when the the branch name starts with a capital.
In this case I tried to create a branch with the name Rogier/PolicyGuidance

When pushing the new branch it will give an error.

If I than click on the branch, it is shown without a capital first letter.

After selecting it, push is successful

VS Code version: Code 1.41.1 (26076a4de974ead31f97692a0d32f90d735645c0, 2019-12-18T14:58:56.166Z)
OS version: Windows_NT x64 10.0.18362

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz (8 x 1896)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: enabledrasterization: enabledskia_renderer: disabled_offsurface_control: disabled_offsurface_synchronization: enabled_onvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
7.93GB (2.44GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (10)

Extension
Author (truncated)
Version

azurepolicyextension
Azu
0.0.22

armview
ben
0.3.3

gitlens
eam
10.2.0

azure-account
ms-
0.8.7

powershell
ms-
2019.12.0

vscode-typescript-tslint-plugin
ms-
1.2.3

azurerm-vscode-tools
msa
0.8.3

code-spell-checker
str
1.7.20

vscode-icons
vsc
9.6.0

arm-params-generator
wil
0.8.1

The problem is that you already have rogier and you're trying to create Rogier. Git actually splits branch names by / and creates folders in disk for each part. So Git can't create a Rogier folder since a rogier folder already exists.
This isn't a Code issue, but a git limitation.


Unknown Time Zone

When trying to get the forecast for an assortment of North American cities/towns, I get an error saying that the time zone for that city is unknown:
F:\tui>tom Halifax
ERROR: unknown time zone America/Halifax

Run `tom -h` for help!

Many thanks for reporting, @Dark-Sol. I will look into it.

 And does it work for you for other, e.g. European cities?

@mlange-42: I do get that location dialog before the error. I tried looking up the weather for London, UK but received the same error.

Oh! As an addendum, I am trying to run this on Windows 10. Maybe that has something to do with it?

Thanks @Dark-Sol!
I think I found the problem. The respective time zones are not available on your system. However, there is the Go package time/tzdata that ptovides them when imported.
Could you give the fix a try, please?
If you have Go installed, you can install the fixed version with
go install github.com/mlange-42/tom@fix-time-zone

Alternatively, you can download the binaries from the latest CI run: https://github.com/mlange-42/tom/actions/runs/12313852956
(scroll down to the bottom, section "Artifacts").

The new binary worked! :)

Ok, nice! I will prepare a new release with the fix. Thanks again for reporting!


[Feature][dataproxy] Add dataproxy metric statistics

Description
Add dataproxy metric statistics
Use case
No response
Are you willing to submit PR?

[ ] Yes, I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Does this issue need to be handled like #1866 ?

fixed by https://github.com/apache/incubator-inlong/pull/2057, so close it.


TODO: Test Chroma with python 3.11

https://github.com/chroma-core/docs/pull/122
maybe this is now resolved?

I have been using it with 3.11 on Mac M1.


Add support for proxy authentication

Adds support for proxies that require username and password authentication. Closes #2021
Adds parameters username and password in the proxy section of config.default.ini.php and updates lib/Configuration.php and lib\contents.php.

Closing as it is already supported. https://github.com/RSS-Bridge/rss-bridge/issues/2021#issuecomment-804631984


Chat AI

[x] merge missing changes from main
[x] update vscode requirement to 1.90 in package.json
[ ] finalise db2i chat commands

[ ] liam to cleanup build

[ ] add support for schema.name

[ ] both to review activity
[ ] adam to work on self command

[x] create VS Code setting to swap between many models

[x] somehow integrate ollama?

[x] https://github.com/ollama/ollama/blob/main/docs/api.md
[x] https://www.npmjs.com/package/ollama

[x] shim lm.sendChatRequest so we can add our own models (e.g. calling Ollama)

[ ] https://github.com/microsoft/vscode/issues/206265#issuecomment-2181192864
[ ] add more ollama settings (like url+port, etc)

[ ] wait for chat API to be available upstream

LGTM


Microsoft Exchange script

Enter the parameter format string for the script: '{CertThumbprint}' 'IIS,SMTP,IMAP' 1 '{CacheFile}' '{CachePassword}' '{CertFriendlyName}'
Can you tell me what these parameters mean? How do I get the corresponding values?

You could get them, but the whole idea is that the program executes the script for you. It will automatically replace the items between curly braces with the actual values. The way you set that up is by using the "full options" mode (M) and choosing a script installation step.

你可以得到它们，但整个想法是程序为你执行脚本。它会自动将花括号之间的项替换为实际值。您设置它的方式是使用“完整选项”模式（M）并选择脚本安装步骤。

I don't know where to get these actual values.

I need to use Exchange to create a self-signed certificate. And then replace it?

No, you just have to literally input '{CertThumbprint}' 'IIS,SMTP,IMAP' 1 '{CacheFile}' '{CachePassword}' '{CertFriendlyName}'. The program takes care of the rest.


incrby parameter order inconsistent

I encountered this:
r.zincrby("key",5,"member")
Gives an exception, eventhough this is the same order of parameters as redis has.
r.zincrby("key","member",5)
works however.
Comparison: r.zadd("key",5,"member") works the way it is supposed to.

Any news on this, coming from redis or other languages / libs like redigo this is a major gotcha and the long its left to fester the worse it gets.

Fixed in redis-py 3.0


Use Geometry class for raycasting

There's fully custom raycasting logic for selecting geometry: https://github.com/jarneson/godot-ply/blob/main/addons/ply/nodes/ply.gd#L141
We can just use Geometry from the engine.
Along the way this should make it easier to fix accidentally selecting things behind what we are trying to click

Looking into it.

From chat:
Convert code to ray casting to:

vert -> sphere
edge -> cylinder
face -> tris


Remote Debugging does not allow Docker containers

Because there is no way to discern what runtime a Docker container is running from the metadata, we don't allow remote debugging to any Docker container.  That being said, maybe we should just attempt to connect to the web app regardless and time out if it isn't working?
@fiveisprime

Container has custom start up logic that looks for ENV variable.  If it's set, it'll start the process in debug mode so if app setting debug remote is set, it'll run in debug mode.
Custom containers (ie Docker) won't necessarily have this logic so it's safer to just not allow users to remote debug via the extension.


question about webqsp_full train.How can I train the model(full)?

here's the error.
half pre_embedding is 400, rather full pre_embedding is 256, when I use provided checkpoint.
Traceback (most recent call last):
File "main_origin_backup.py", line 541, in
do_batch_norm=args.do_batch_norm)
File "main_origin_backup.py", line 351, in train
loss = model(question_tokenized=question_tokenized, attention_mask=attention_mask, p_head=positive_head, p_tail=positive_tail)
File "/data4/yhchen/miniconda3/envs/py3.6/lib/python3.6/site-packages/torch/nn/modules/module.py", line 532, in call
result = self.forward(*input, **kwargs)
File "/data4/yhchen/EmbedKGQA/KGQA/RoBERTa/model.py", line 342, in forward
pred = self.getScores(p_head, rel_embedding)
File "/data4/yhchen/EmbedKGQA/KGQA/RoBERTa/model.py", line 203, in ComplEx
re_score = re_head * re_relation - im_head * im_relation
RuntimeError: The size of tensor a (128) must match the size of tensor b (200) at non-singleton dimension 1

here's the error.
half pre_embedding is 400, rather full pre_embedding is 256, when I use provided checkpoint.
Traceback (most recent call last): File "main_origin_backup.py", line 541, in do_batch_norm=args.do_batch_norm) File "main_origin_backup.py", line 351, in train loss = model(question_tokenized=question_tokenized, attention_mask=attention_mask, p_head=positive_head, p_tail=positive_tail) File "/data4/yhchen/miniconda3/envs/py3.6/lib/python3.6/site-packages/torch/nn/modules/module.py", line 532, in call result = self.forward(*input, **kwargs) File "/data4/yhchen/EmbedKGQA/KGQA/RoBERTa/model.py", line 342, in forward pred = self.getScores(p_head, rel_embedding) File "/data4/yhchen/EmbedKGQA/KGQA/RoBERTa/model.py", line 203, in ComplEx re_score = re_head * re_relation - im_head * im_relation RuntimeError: The size of tensor a (128) must match the size of tensor b (200) at non-singleton dimension 1

Hi, have you solved this problem yet?


Updated Qt versions

Pull request checklist:

[ ] CHANGELOG.md was updated, if applicable

Description

Updated minimum required and latest Qt versions
Added Qt version check to chatterino.pro

As discused on Chatterino Discord, we now have methods in our code such as QOalette#placeholderText in https://github.com/Chatterino/chatterino2/blob/master/src/widgets/splits/Split.cpp#L321-L322 which were introduced in Qt 5.12.0, updated documentation to reflect those changes.

Darn, I didn't notice #2208 before opening this PR.

Duplicates #2210 but maybe this one is better

Yeah, I like this one better, closing #2208


[DO NOT MERGE] - Fix BQ27Z561 and LP5523 I2C repeated-stop operations

The main part of this PR is a possible fix for an I2C failure in our nRF52 system which hangs the bus and keeps SDA low indefinitely. The failure appears to be triggered when doing a read of bq27561 or lp5523 registers, if the write operation (first part of a write-read) fails and no STOP condition gets generated. The condition can be very difficult to reproduce, though it happens with some regularity if certain specific conditions are met which are too detailed to go into here.
The solution applied by this PR is to allow the following I2C read and STOP condition to go through even though the write has failed.
This fix is preliminary and testing is on going, though I want to submit it now for review and comments. A more thorough solution might be found by modifying hal_i2c_master_write in the nrf52xxx HAL to place a STOP on the bus if the write operation fails when the >last_op< argument is 0.
Also, the bq27z561 i2c timeout has been reduced from 1 second to 16 milliseconds, as the long timeout was holding up processing of default queue events.

@ccollins476ad I looked further into this and I think my changes in this PR are just a workaround for a bug in hal_i2c_master_write. In the case where last_op is 0 and an error takes place, EVENTS_STOPPED=0 doesn't ever happen, and I think that results in the bus being left without a stop condition.

@benmccrea, I see what you mean, and I think that is definitely worth trying.

Closing this in favor of opening a new PR with a more thorough fix.