Transitive loading of @types/node breaks Request/Response (etc.) types

As per https://github.com/DefinitelyTyped/DefinitelyTyped/pull/66824 which was merged recently and released in<EMAIL_ADDRESS>Node.js now defines its own Request, Response, etc. types via undici-types.
While this is great in Node environments, it completely messes with the Request and Response (maybe others?) types defined by @cloudflare/workers-types.
Example code that used to work before:
type SomeType = {
	foo: string
};
const response = await fetch(...);
const json = await response.json<SomeType>()

Now has a type error with: Expected 0 type arguments, but got 1..
Or:
const country = request?.cf?.country;

Now has a type error with `Property 'cf' does not exist on type 'Request'.
Or:
new Request(..., request);

Now has a type error with:
Argument of type 'Request' is not assignable to parameter of type 'RequestInit'.
  Types of property 'referrerPolicy' are incompatible.
    Type 'string' is not assignable to type 'ReferrerPolicy | undefined'.

Why load @types/node?
This is a fair question, and you generally don't need to load @types/node at all, and in fact, I don't directly. But, many dependencies that people use, do in fact require @types/node, including the likes of @types/pg, which is loaded by @neondatabase/serverless.
It seems that once this newer version of @types/node is loaded into memory at all, it just overrides the globally defined Request/Response/fetch types from @cloudflare/workers-types.
Full reproduction
See the following github repo: https://github.com/Cherry/workers-node-types-issue-repro.
This showcases an example package that loads @types/node, and if you comment in/out the import you'll see the type errors now show up.
Workaround
My current workaround for this is to pin @types/node via npm overrides, with this in my package.json:
{
	"overrides": {
		"@types/node": "20.8.3"
	}
}

It's a very naive and short-term workaround, but works for now.

Diagnosis
It appears that this ends up running into some fundamental TypeScript issues. I am not an expert here, but what I understand is happening is that TypeScript imports your tsconfig.json types field first, then overrides it with anything imported from a dependency. If you have even a single dependency that overrides a global type that you’re using from @cloudflare/workers-types, then too bad, that type is overridden.
This is a big and hard to solve problem, because TypeScript automatically emits /// <reference types="node" /> any time a dependency uses a Node global. My pnpm why @types/node is showing tens of projects with these globals; it’s infeasible for me to personally patch or PR each of these dependencies to fix their projects, even if you buy that those projects have made some mistake in the first place.
Unfortunately, TypeScript can’t fix this problem without a much bigger rearchitecture (microsoft/TypeScript#18588; the strict-env proposal has also stalled). If there’s any silver lining to this, I guess it’s that it would also break other WinterCG projects that use TypeScript like this (IIRC the only one would be @edge-runtime/types, and only if they have a similar type incompatibility; Deno and others do their global type checking differently or just use @types/node).
Aside: A better, cheap workaround
A slightly better workaround than the above would be to add the following to a global.d.ts in your project:
declare module "@types/node" {
  declare const value: unknown;
  export default value;
}

This will limit the damage of neutralising @types/node to just the projects you’re using Workers in, and allow you to keep @types/node unpinned for actual node projects (such as scripts or other packages in a monorepo).
The long-term, idiomatic solutions
TypeScript 5.0 includes a new compilerOptions directive, customConditions. This means the compiler can now resolve package.json exports conditions to locate types depending on the runtime/conditions that are present. In short, this means that packages which emit a /// <reference types="node" /> can scope this to just be imported by the node condition, or to remove it for the workerd condition. This is the TypeScript equivalent of a bundler’s conditions directive (ex. ESBuild), and you use it in much the same way.
However, as we’ve found with the workerd condition in the ecosystem, this requires every package to update to split their exports. I’m not convinced this is feasible. An easier solution would be for @types/node to add a workerd condition with a no-op export, like so:
"exports": {
    "workerd": {
        "types": "./noop.d.ts"
    },
    "default": {
        "types": "./index.d.ts"
    }
}

(Or, if we want to get more involved, we could have one with a subset of @types/node that doesn’t include the incompatible globals; or even one that just imports @cloudflare/workers-types, which would obviate the need for users to add it to their tsconfig.json and just use customConditions—but this feels wrong).
I’ll hit up the DefinitelyTyped team and see what they think—an opinion from Cloudflare would be greatly appreciated here also :)
TL;DR just give me a patch
First, add this to your tsconfig.json:
{
    "compilerOptions": {
        "customConditions": ["workerd", "worker", "browser"],
    }
}

Second, patch @types/node/package.json using your package manager to add:
"exports": {
    "workerd": {
        "types": "./noop.d.ts"
    },
    "default": {
        "types": "./index.d.ts"
    }
}

(You don’t need to create ./noop.d.ts, it’ll just silently fail which is what you want)

This is fantastic insight, thank you so much for the detailed response!
I'm unfortunately in a project where I do value having the types for node:crypto, so noop-ing everything is less than ideal, but this seems like a better workaround for folks who don't need any Node types for the nodejs_compat flag.

I'm unfortunately in a project where I do value having the types for node:crypto, so noop-ing everything is less than ideal, but this seems like a better workaround for folks who don't need any Node types for the nodejs_compat flag.

If you use "types": ["@cloudflare/workers-types", "node/crypto"] alongside the above workaround, you might be able to get this to work?

Yes that might be a possible workaround, with loading @types/node/crypto, @types/node/buffer etc. explicitly.

Reading Andrew’s comments, it looks like the way forward is for Cloudflare (or the community) to maintain their own fork of @types/node with the above changes, and encouraging users to override their dependencies. I think it would be enough for that package to just /// <reference types="node" /> for index.node.d.ts, and have a blank file at index.workerd.d.ts, in which case it could just have a peer dependency on @types/node and never have to update its resolutions? But I’m not super well-versed with package magic.

Now that @types/node v18 has been updated to include fetch types, I suspect this issue will show up a lot more frequently. So it’s worth also adding that there are a few ways to handle having multiple versions of @types/node in your project that need patching:

Patch every version (boring, slow)
Frequently run pnpm -r upgrade @types/node (or equivalent) to upgrade to the latest satisfiable versions. In my monorepo this got me down to a patch for v18 and v20
Pin @types/node to the version you’re using and just patch it once

I have gone with (3), which looks like (package.json):
"pnpm": {
  "patchedDependencies": {
    "<EMAIL_ADDRESS>"patches/<EMAIL_ADDRESS>  },
  "overrides": {
    "@types/node": "^20.0.0"
  }
},

For me, this means updating the patch whenever @types/node updates, but usually that just involves renaming the file cause their package.json isn’t going to change a tonne.

I am trying to get a similar patch, is this the most up to date version?

Should work, are you having any problems with it? I also gave instructions on how to re-create the patch for any @types/node version if it’s not working…

Thanks @huw for getting back so quickly
Here is what I have so far outlined in this PR: https://github.com/Helicone/helicone/pull/1140/files
However, it is still not finding the Node types
src/lib/secureCache.ts:51:28 - error TS2591: Cannot find name 'Buffer'. Do you need to install type definitions for node? Try `npm i --save-dev @types/node` and then add 'node' to the types field in your tsconfig.

51   const encryptedContent = Buffer.from(encrypted.content, "hex");
                              ~~~~~~

Could you please explain what you’re trying to achieve in a broader sense?
The error you have posted occurs because secureCache.ts is trying to use Buffer, which is a Node-only API. This API will not run in Cloudflare Workers unless you enable node_compat or nodejs_compat. You will either need to enable one of those flags or remove the dependency on Buffer to get your code to run.
This issue is about something different, which is that sometimes when importing third-party libraries, they will also import types from Node into the global typespace, which can cause code to type-check correctly when it shouldn’t (for example, if you wrote code with Buffer but you wanted to run it in Workers, this code might type-check fine even if it can’t actually run!). You can use the patch above to improve the correctness of your type-checking, but this will have no bearing on whether the libraries you depend on will actually need Buffer in the first place.
It sounds like you might trying to do the opposite, which is to import the Node types (remember, you will also need to enable node_compat or nodejs_compat in your wrangler.toml). You can do that by adding types: ["node"] to your tsconfig.json#compilerOptions.
If this doesn’t make sense or you’re having more problems, can I ask you to ask this in the Cloudflare Discord? I can’t be 100% sure without more context, but it doesn’t sound like your problem is relevant to this issue.

@huw Happy to chat more on discord but that link seems to be broken.
Can you friend me? #justin75 and we can pick up from there?

This link should
Work, but just so we're clear I don't have the time to help you there, I'm just redirecting you to the right place to ask for it :)

Thanks! No worries, I appreciate your time @huw thanks

For anyone else running into this issue here is what I am trying to solve....
Problem - type conflicts
We keep getting type conflicts within our edittors and when trying to build our project.

```
src/lib/providerCalls/call.ts:63:3 - error TS2741: Property 'webSocket' is missing in type 'import("/Users/justin/Documents/repos/promptzero/helicone/worker/node_modules/.pnpm/undici-types@5.26.5/node_modules/undici-types/fetch").Response' but required in type 'import("/Users/justin/Documents/repos/promptzero/helicone/worker/node_modules/.pnpm/@cloudflare+workers-types@4.20231121.0/node_modules/@cloudflare/workers-types/index").Response'.
63   return response;
~~~~~~
node_modules/.pnpm/@cloudflare+workers-types@4.20231121.0/node_modules/@cloudflare/workers-types/index.ts:1073:12
1073   readonly webSocket: WebSocket | null;
~~~~~~~~~
'webSocket' is declared here.

The issue is because there are two version of Response/Request and fetch that were added to node types 20^.
<img width="599" alt="image" src="https://github.com/cloudflare/workerd/assets/26822232/9f50e2bf-ccc4-4903-8892-6b9122933e50">

# Solutions
I tried to use @huw's solution [here](https://github.com/Helicone/helicone/pull/1140/files) however, I was still getting a ton of different compile and type checking issues.

using pnpm to override the node types version to 18 works for now but this is not a long term solution

"pnpm": {
"overrides": {
"@types/node": "18.15.3"
}
},

Thank you all for your help!

@huw thanks for https://github.com/cloudflare/workerd/issues/1298#issuecomment-1756830290, that was very helpful.
Just a note for anyone else who runs into this: some libraries (like Next.js) try to find a package's package.json, and this will fail with this patch. By default, package.json is considered to be exported, but if there is an explicit exports entry, it needs to be manually included there: https://github.com/nodejs/node/issues/33460 / https://github.com/uuidjs/uuid/issues/444
So our patch looks like this (as you can't mix ./ and prefixless exports):
diff --git a/noop.d.ts b/noop.d.ts
new file mode 100644
index<PHONE_NUMBER>000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
diff --git a/package.json b/package.json
index c902b012556ed4bca4b8038a0f4523ce3cb76287..07f730b9d31475f59e108de66e832122ee57c3c6 100644
--- a/package.json
+++ b/package.json
@@ -226,5 +226,12 @@
     },
     "typesPublisherContentHash": "e270b1ec6520966a2cb0578fa33386344f78258bc0bd109a3e4b315d052e2b62",
     "typeScriptVersion": "4.5",
-    "nonNpm": true
+    "nonNpm": true,
+    "exports": {
+        "./workerd": {
+            "./types": "./noop.d.ts"
+        },
+        "./types": "./index.d.ts",
+        "./package.json": "./package.json"
+    }
 }

Hitting this while migrating my Workers from Service Workers to ESM (by force, not choice), and in turn having to migrate from Jest to Vitest. This is painful.
The docs already recommend pinning a specific Vitest version, do we also need to pin @types/node?

@punkeel https://developers.cloudflare.com/workers/languages/typescript/#transitive-loading-of-typesnode-overrides-cloudflareworkers-types

Potentially could be fixed if we generate node types on the fly based on node compat flags (aka Types as a Service).

Hello! Just to say that using overwrite or resolutions in package.json is not working for us, as we use a monorepo (nx) and they have a bug that requires a nodejs version at least 20.12.2 :(  (which conflicts with the v20.8.3 advised here)
So we are basically blocked currently 😅
Related nx issue: https://github.com/nrwl/nx/issues/22998

@Lp-Francois - I think you are saying that Nx requires Node.js 20.12.2 or above to work (at runtime).
The workaround suggested is only about locking down the "types" of Node.js to 20.8.3.
Are you saying that locking the types is somehow breaking your builds when using Nx?

Hey @petebacondarwin, it gives me No matching export in<EMAIL_ADDRESS>for import "Response" when starting locally my worker using wrangler.
  "resolutions": {
    "@types/node": "20.8.3"
  }

I tried using 20.8.1, 20.8.3, 20.9.0 for the types and 20.8.1, 20.9.0, 20.12.2 as node version (with a yarn install in between). I thought the runtime version could be an issue :/
Also, as we have different projects with nx others than cloudflare workers, I am afraid than a global override in a monorepo is not the best option, as it could cause type issues 🤔

FYI, TypeScript 5.6 will pretty much require a newer version of @types/node to pick up a number of iterator type updates (iterator methods / improved correctness); the workaround of pinning back to an old version is not going to be viable after that.

I struggled with this issue for a whole day and resolved it by using the --experimental-include-runtime option added to the wrangler types command in Wrangler v3.66.1 (the doc incorrectly says 3.66.0).
Don't forget to uninstall @cloudflare/workers-types and add the path of the generated runtime types file to the compilerOptions.types field in your project's tsconfig.json file:
{
	"compilerOptions": {
		"types": ["./.wrangler/types/runtime.d.ts"]
	}
}

@Cherry this issue is being fixed here: https://github.com/cloudflare/workerd/pull/2708

Closing as this is now fixed.

If this is considered fixed, may I ask for total clarity if this workaround that still exists in the cloudflare docs is no longer deemed necessary? https://developers.cloudflare.com/workers/languages/typescript/#transitive-loading-of-typesnode-overrides-cloudflareworkers-types

@prblackburn the workaround still exists, because it assumes that you are using @cloudflare/workers-types. So unless you are moving to wrangler types --experimental-include-runtime to generate your runtime types, then you will need this suggested workaround.

Ok... so as of today 12/5/2024, if one is using wrangler types --experimental-include-runtime, how does one import { Buffer } from 'node:buffer'?

@ms-ati - does adding nodejs_compat compat flag and then installing @types/node not work for you?


Revision of English description in README.md

@Takeuchi-Lab-LM
@koichi609
I would appreciate it if you would agree to my revision.

Fixed typos and justified the texts of README.md
Made (just a little bit of...) clear English description on the input example (太郎の本を健が捨てた)

Added an interlinear glossing following Leipzig Glossing Rules

Added the syntax highlighting for getpas.py

Any comments and suggestions are welcome.

@CLRafaelR
Many thanks for this review.

  • Added an interlinear glossing following Leipzig Glossing Rules

This is very helpful. I would like to follow the glossing.

• Added the syntax highlighting for getpas.py

I would appreciate your revision! That’s great.
koichi609

2020/01/14 15:53、CLRafaelR<EMAIL_ADDRESS>@Takeuchi-Lab-LM
@koichi609
I would appreciate it if you would agree to my revision.
• Fixed typos and justified the texts of README.md
• Made (just a little bit of...) clear English description on the input example (太郎の本を健が捨てた)
• Added an interlinear glossing following Leipzig Glossing Rules
• Added the syntax highlighting for getpas.py
Any comments and suggestions are welcome.
You can view, comment on, or merge this pull request online at:
https://github.com/Takeuchi-Lab-LM/python_asa/pull/8
Commit Summary
• Connected remote and local
• Resolved conflict
• Change: Tried to receive the change from the original repo
• Fix typos
• Fix some English description
• Fix Eng desc
• Merge branch 'master2'
• Fix typos and add interlinear gloss (following Leipzig Glossing Rules)
• Deleted my personal file
• Improved README.md
• Improved README.md again
• conflicting...
• Conflict resolved
• Revision
• Deleted obsolete cabocha directory
File Changes
• M README.md (54)
Patch Links:
• https://github.com/Takeuchi-Lab-LM/python_asa/pull/8.patch
• https://github.com/Takeuchi-Lab-LM/python_asa/pull/8.diff
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.


signing of arbitrary 32 byte digest not working with az keyvault key sign

Describe the bug
It is expected that the digest passed to az keyvault key sign be an arbitrary 32 byte sha-256 checksum.
The example uses only characters 1-9.  Passing most valid ascii characters appears to be accepted, however many byte codes cause an exception due to the underlying python trying to convert the input to utf-8
For reference the failing sum (as hex text) is 3650d9b8ccb170c41127ba357e7777fae64f650d1115da5264c36589398f3d07
Example, passing exactly 32 bytes in:
az keyvault key sign -a RS256 --digest sha256sum manifest | cut -d " " -f 1| xxd -r -p --id https://
'utf-8' codec can't encode character '\udcc4' in position 5: surrogates not allowed
equivalent:
az keyvault key sign -a RS256 --digest echo 3650d9b8ccb170c41127ba357e7777fae64f650d1115da5264c36589398f3d07 |  xxd -r -p --id https://
Attempts to debug where different string lengths are confounded by the system reporting a rest API error about the size of the input to the base64 encoding which is applied by the az tool.
Related command
az keyvault key sign
Errors
'utf-8' codec can't encode character '\udcc4' in position 5: surrogates not allowed
Issue script & Debug output
az keyvault key sign -a RS256 --digest echo 3650d9b8ccb170c41127ba357e7777fae64f650d1115da5264c36589398f3d07 |  xxd -r -p --id https://
Expected behavior
A valid response such as when I enter a byte input that doesn't happen to contain illegal utf-8 encoded characters, or support for passing the binary value as hex characters.
Environment Summary
azure-cli                         2.53.0
core                              2.53.0
telemetry                          1.1.0
Dependencies:
msal                            1.24.0b2
azure-mgmt-resource             23.1.0b2
Python location '/opt/az/bin/python3'
Extensions directory '/home/mbrown13/.azure/cliextensions'
Python (Linux) 3.10.10 (main, Sep 20 2023, 06:07:28) [GCC 7.5.0]
Legal docs and information: aka.ms/AzureCliLegal
Your CLI is up-to-date.
Additional context
The changing the encoding configuration for this input may be the correct solution
.decode('utf8','surrogateescape')

Thank you for opening this issue, we will look into it.

I think it is not clear enough that this issue is a bug.
At this moment, it is impossible to sign anything using the azure cli, unless its hash happens to be text, which is very unlikely.
Additionally, the error message states that the digest value should be encoded with base64url, which is not the case. This would make it work.

This answer is superficial.  The fact that the errors are reported incorrectly is well known in the community, these are underlying API errors that are always reported by the backend.  Simply try passing a key of the correct size for the selected algorithm with base64 encoding, the CLI will report a error that the input is too large.  The only input size it will accept is the exact number of BYTES required for the selected algorithm.

This answer is superficial. The fact that the base64 errors are reported incorrectly is well known in the community, these are underlying API errors that are always reported by the backend. Simply try passing a key of the correct size for the selected algorithm with base64 encoding, the CLI will report a error that the input is too large. The only input size it will accept is the exact number of BYTES required for the selected algorithm.

Indeed, it is well know that the error message is wrong, and it is also well know that the command line expects the bytes of the hash, rather than their hex encoding. However, it is not possible to pass arbitrary bytes to as a bash command line argument, which is what makes this issue a :bug:.

To the best of my understanding, without the fix for this issue the only reasonable way to use key vault keys is to download the private part, use it, and then immediately discard. Which, diminishes the value of key vault as such.

To the best of my understanding, without the fix for this issue the only reasonable way to use key vault keys is to download the private part, use it, and then immediately discard. Which, diminishes the value of key vault as such.

You can use the rest api:
curl -s -X POST -H "Authorization: Bearer ${BEARER}" -H "Content-Type:application/json" -H "Accept:application/json" "https://da-vault.vault.azure.net/keys/da-key/01234567890123456789012345678901/sign?api-version=7.4" -d '{ "alg" : "ES256", "value" : "AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8=" }'

To the best of my understanding, without the fix for this issue the only reasonable way to use key vault keys is to download the private part, use it, and then immediately discard. Which, diminishes the value of key vault as such.

You can use the rest api:
curl -s -X POST -H "Authorization: Bearer ${BEARER}" -H "Content-Type:application/json" -H "Accept:application/json" "https://da-vault.vault.azure.net/keys/da-key/01234567890123456789012345678901/sign?api-version=7.4" -d '{ "alg" : "ES256", "value" : "AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8=" }'

That worked, thanks!

My Organization has taken a similar (and agreed, less secure) approach and just given up on using an actual key-vault keys.  We are just storing key pairs as base64 encoded secrets in key-vault and write our own scripts to actually handle the encoding/decoding properly.  This also gives us the flexibility to move to a entirely different service provider easily.

@evelyn-ys any update on this bug. The functionality of keyvault as a kms is now at the moment useless

You can use the rest api:

the rest api worked for me for RSA keys but not for EC keys so far

@evelyn-ys any update on this bug?
I can't believe a cli tool expecting a byte input

Sorry for late response and fix. Can anybody verify if https://github.com/Azure/azure-cli/pull/30521 works for your scenario?


master do not compile on foxy

I've done a git pull on my previously downloaded version on the master, and the compilation failed. The reason being a missing include and the use of a method for the logger that is only supported in galactic or latest versions of ROS2 of rclcpp. In the patch, there are the changes I had to apply to have it compile successfully.
compile.txt
Would it be possible to have a conditional compilation for the set_level method in the logger?
I belive that If galactic is needed, then it shall be properly stated.
I'm using foxy updated from the official repo in binary form, and running under Ubuntu 20.04.3 LTS, with g++ 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)

This issue is relevant: #179

Although the  seems to be not needed in galactic, from a programming point of view, the inclusion of needed header for used methods is a good practice instead of relying on other packages including them, especially if they are standard libraries.
As far as the set_level, I understand that now the master is for galactic, however, since it is a simple call to enable debugging it seems a minor change, and it might be conditioned to be in the galactic branch of ROS2 and disable in the other case, or using the proper code to enable that.
These are just suggestions, and of course you are free to consider them or ignore thus closing this issue.

Hi all,
As said in #179, master points to Galactic. But, I understand that removing only this call, which is not critical, could make it compile also in Foxy. I will be happy to accept a PR only removing this call. Please, @roveri-marco , instead of attaching patch files, contribute following the usual way, as I described some time ago in https://github.com/IntelligentRoboticsLabs/ros2_planning_system/issues/168#issuecomment-994393296 .
Best
Francisco

Hi Francisco and all,
Sure I'll do as suggested in the forthcoming days.
Best
Marco

Fixed in #187


Deprecate cairo_project.toml in favour of Scarb.toml

Checklist

[x] Relevant issue is linked
[ ] Docs updated/issue for docs created
[ ] Added relevant tests
[ ] checklist from #1737

Merge asap to avoid conflicts with rust rewrites.
Docs + additional tests can be done in another PR

Remember about updating default template and docs (in separate PRs)


Ranges are not usable in device contexts

The whole gko::range ecosystem doesn't work in device code, since it uses some __host__ functions and classes like std::forward, std::array, and after fixing that I can't seem to get the ROCm compiler to find the constructor for a gko::range<gko::accessor::row_major<ValueType, 2>> - my best guess is there are some issues with variadic templaces in device code.
Does anybody see a way to solve this (except for rewriting the whole range/accessor system?)

This seems to be no longer relevant, as we are now using ranges and accessors for mixed precision ELL #717


Clarify why merging into another container is a bad idea

Description
Just a change to the README - I tend to read 'YMMV' as 'might need some jiggling', but it's a bit more serious than jiggling. :) I think being explicit about the particular implementation details is more useful here.
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:

[n/a] Includes unit tests
[n/a] Adds integration tests if needed.

See the contribution guide for more details.
Reviewer Notes

[ ] The code flow looks good.
[ ] Unit tests and or integration tests added.

Release Notes
Describe any changes here so maintainer can include it in the release notes, or delete this block.
Examples of user facing changes:
- Made explicit in the README the main reasons for not merging into a different container.

While I'm writing, it may be relevant to mention my particular use-case:
We're wanting to run our Teamcity CI agents in GKE/Autopilot. To build our application, the agents need more than just the plain agent, so we want to customise the image with that additional tooling. We want that customisation-build to happen in Autopilot too.
I haven't yet been able to find if there's a simple mechanism for containers running within Autopilot to launch-and-wait-for other containers also inside Autopilot, and we can't merge kaniko into the TC agent containers because unpacking the TC image overwrites the running TC agent. It seems we want our agents to launch kaniko with something equivalent to 'kubectl run' - if there's a known mechanism for achiving that within Autopilot, it would be nice to have a link to it mentioned near the Known Issues!


Frames skipped in Python testing

Does this issue occur when all extensions are disabled?: Yes

Version: 1.71.2 (Universal)
OS: Darwin arm64 21.6.0
Steps to Reproduce:

Debug in Python testing
Step into external library
Frames skipped; asked me to turn justMyCode in settings.json
Try to create settings.json and add justMyCode: false
Frames are still skipped

Where should I put justMyCode: false?

/extPython

It looks like this is caused by the Python extension. Please file the issue to the Python extension repository. Make sure to check their issue reporting template and provide them relevant information such as the extension version you're using. See also our issue reporting guidelines for more information.
Happy Coding!


Vagrant still falls back to rsync with VBox 5.0.12 Guest Additions installed ok

d:\PHPProjects\ootalks\vagrant-php-bootstrap>vagrant reload
==> default: Attempting graceful shutdown of VM...
==> default: Checking if box 'centos/7' is up to date...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Forwarding ports...
    default: 80 (guest) => 8080 (host) (adapter 1)
    default: 5432 (guest) => 5432 (host) (adapter 1)
    default: 6379 (guest) => 6379 (host) (adapter 1)
    default: 5672 (guest) => 5672 (host) (adapter 1)
    default: 15672 (guest) => 15672 (host) (adapter 1)
    default: 9300 (guest) => 9200 (host) (adapter 1)
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: <IP_ADDRESS>:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Remote connection disconnect. Retrying...
==> default: Machine booted and ready!
GuestAdditions 5.0.12 running --- OK.
==> default: Checking for guest additions in VM...
==> default: Configuring and enabling network interfaces...
==> default: Rsyncing folder: /cygdrive/d/PHPProjects/ootalks/vagrant-php-bootst
rap/ => /home/vagrant/sync
There was an error when attempting to rsync a synced folder.
Please inspect the error message below for more info.

Host path: /cygdrive/d/PHPProjects/ootalks/vagrant-php-bootstrap/
Guest path: /home/vagrant/sync
Command: rsync --verbose --archive --delete -z --copy-links --chmod=ugo=rwX --no
-perms --no-owner --no-group --rsync-path sudo rsync -e ssh -p 2222 -o ControlMa
ster=auto -o ControlPath=C:/Users/Vlad/AppData/Local/Temp/ssh.954 -o ControlPers
ist=10m -o StrictHostKeyChecking=no -o IdentitiesOnly=true -o UserKnownHostsFile
=/dev/null -i 'd:/PHPProjects/ootalks/vagrant-php-bootstrap/.vagrant/machines/de
fault/virtualbox/private_key' --exclude .vagrant/ /cygdrive/d/PHPProjects/ootalk
s/vagrant-php-bootstrap/ vagrant@<IP_ADDRESS>:/home/vagrant/sync
Error: rsync: Failed to exec ssh: No such file or directory (2)
rsync error: error in IPC code (code 14) at pipe.c(85) [sender=3.1.0]
rsync: safe_read failed to read 4 bytes [sender]: Resource temporarily unavailab
le (11)
rsync error: error in rsync protocol data stream (code 12) at io.c(251) [sender=
3.1.0]

d:\PHPProjects\ootalks\vagrant-php-bootstrap>

    if OS.windows?
      config.vm.synced_folder project_folder_local, project_local_vm
    else
      config.vm.synced_folder project_folder_local, project_local_vm, type: "nfs", mount_options: ['nolock,vers=3,udp,noatime,actimeo=1']
    end

You haven't provided enough information for me to be sure but it's likely the box has a vagrantfile packaged with it. The load order of configurations prefers a vagrantfile packaged with the box. So, if the box does have a packaged vagrantfile, you will always have to specify a type in your own configuration, you can't rely on default values.

Opps!  This is a vagrant file of the box:
Vagrant.configure("2") do |config|
  config.vm.base_mac = "525400d3eba4"
  config.vm.synced_folder ".", "/home/vagrant/sync", type: "rsync"
end

Should this be reported as a bug? Why rsync type is hardcoded here? This causes problem for Windows users.

This causes problems with all users, not just Windows. I've seen this trend recently with other distributions packing vagrantfiles in the boxes and it caused much confusion when one of our boxes worked one week but not the next. We now have to specify type: "virtualbox" in our VagrantFile, and though that type doesn't seem to be documented anywhere, it works fine.
They are using rsync because they don't have a license to distribute the guest additions iso.

Thanks for helping out @vinnyrose!


Crash: choco install visualstudio2017-workload-azure -y crashes Powershell at first run

On a Windows 10 fresh VM, we run the following and it kills the powershell instance, even if we use & or Start-Process.
If we try to run it a second time it works and does not kill the powershell instance -
For example:
$process = START-PROCESS powershell -Command {choco install visualstudio2017-workload-azure -y} -PassThru -Wait
See attached:
chocolatey.log
choco.summary.log
Complete setup file:
dev_machine_setup.zip

Another example which didn't work:
$process = START-PROCESS powershell $file_path -PassThru -Wait
It calls another ps script executes one-line command "choco install visualstudio2017-workload-azure -y"

I have a hypothesis, but I'll need the Visual Studio logs to confirm it: $Env:Temp\chocolatey\dd_*.log
(The Azure PowerShell installer had a nasty habit of killing powershell.exe processes - Azure/azure-powershell#2130. I also found this: https://github.com/MicrosoftDocs/visualstudio-docs/issues/301)

Xin – can you load the logs on the GitHub issue please?
Thanks!
-MG-
From: Jakub Berezanski<EMAIL_ADDRESS>Sent: Thursday, March 1, 2018 2:35 PM
To: jberezanski/ChocolateyPackages<EMAIL_ADDRESS>Cc: Mauro Giusti<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [jberezanski/ChocolateyPackages] Crash: choco install visualstudio2017-workload-azure -y crashes Powershell at first run (#35)
I have a hypothesis, but I'll need the Visual Studio logs to confirm it: $Env:Temp\chocolatey\dd_*.log
(The Azure PowerShell installer had a nasty habit of killing powershell.exe processes - Azure/azure-powershell#2130https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-powershell%2Fissues%2F2130&data=04|01|maurgi%40microsoft.com|74216052e2fe49e94cfb08d57fc4b3b9|72f988bf86f141af91ab2d7cd011db47|1|0|636555405181494577|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D|-1&sdata=Z5JIH4vcIhZ3Bv68Wy946sFSvuFCC8U9jN2W%2B0LDaJY%3D&reserved=0. I also found this: MicrosoftDocs/visualstudio-docs#301https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fvisualstudio-docs%2Fissues%2F301&data=04|01|maurgi%40microsoft.com|74216052e2fe49e94cfb08d57fc4b3b9|72f988bf86f141af91ab2d7cd011db47|1|0|636555405181494577|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D|-1&sdata=NLMe4khm4E1NuaLfYHX3rxZZIN8%2FqNy1n2%2BbrM19zJs%3D&reserved=0)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjberezanski%2FChocolateyPackages%2Fissues%2F35%23issuecomment-369755065&data=04|01|maurgi%40microsoft.com|74216052e2fe49e94cfb08d57fc4b3b9|72f988bf86f141af91ab2d7cd011db47|1|0|636555405181494577|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D|-1&sdata=01w9S9xCRi%2BBTdv3n0ddKrop2HL%2BH%2BfBGRk2bluhRyQ%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAMh6mOqWvZlHyj-DILmLwU9UmiMQO-Icks5taHeggaJpZM4SZDC_&data=04|01|maurgi%40microsoft.com|74216052e2fe49e94cfb08d57fc4b3b9|72f988bf86f141af91ab2d7cd011db47|1|0|636555405181494577|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D|-1&sdata=gJOqnmx%2Fip3W78qiUfvFJdwjLet2sIHzd5m7xbQkVpE%3D&reserved=0.

Thank you Jakub, please see the attached logs.
Thank you!
Xin
logs-a.zip
logs-b.zip
logs-c.zip

Yes, I believe I was right.
In dd_setup_20180301211242_002_Microsoft.Azure.PowerShell.log:
MSI (s) (C4!CC) [21:13:16:602]: PROPERTY CHANGE: Adding WixCloseApplicationsDeferred property. Its value is 'powershell.exe7150000powershell_ise.exe7150000'.
MSI (s) (C4!CC) [21:13:16:602]: Doing action: WixCloseApplicationsDeferred

This is the Azure PowerShell installer killing all powershell.exe and powershell_ise.exe processes. So it wasn't fixed after all, at least not in version 5.0.0 installed by Visual Studio. 😞
In the workstation setup script at my company we work around it by renaming the PowerShell executable (actually, copying it under a new name, such as posh.exe) and using it to run the relevant portion of the workstation config process.

Thanks a lot for figuring this out! That’s a nice workaround. I’ll try it :)


Mast: Watch pmicert.page.tl

Mast requests the watch of the watch_keyword pmicert\.page\.tl. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

pmicert\.page\.tl has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Rejected by NobodyNada in Charcoal HQ. Reason: 'I watched it without seeing the PR: https://chat.stackexchange.com/transcript/message/55119094#55119094'


replace Mapbox with WikiMedia Maps

I've decided for Wikimedia Maps (https://maps.wikimedia.org/), because it's free (and still have clean design).
Actually also /content/datenschutz.md should be adapted as well, because it is still containing MapBox related data protection statements. Not sure what to write or copy there: https://www.wikimedia.de/datenschutz/  or  https://foundation.wikimedia.org/wiki/Privacy_policy

Lets focus on technical issues first. The deploy preview (https://deploy-preview-204--hungry-heisenberg-4bd67f.netlify.app/mitmachen/) does not work for me (Firefox 81.0.2), because Uncaught Error: No value provided for variable {Z}

Ah, Wikimedia blocks external users: https://stackoverflow.com/a/60247585

Do you have an idea why all map tiles have scale(1.0613) applied through css?

Ok, Carto works, as https://carto.com/basemaps/ says, it is free for non-commercial projects.

Closing in favour of #212

Closing in favour of #212


Feature/render indent lines at correct levels

@CrossR following our discussion a little while ago on discord I've tweaked the indent lines so they don't render a guide for the first level of indentation and the last resulting in:

Not sure if the image conveys the change correctly but the aim was to have indents render more in line with the way that sublime or vscode renders them as they seem not to render the first and the deepest level of indentation per line

@CrossR thanks for the review re. the 0 column tbh I was thinking that that would have to be configurable at some point as I can very easily see it being raised as an issue down the line since that behaviour isn't going to be universally expected I think users will probably want the option of choosing.
Re. the file types I started off working off of how vim-indent-guides works and it gives a user the option to select per filetype tbh that list can probably be greatly expanded although I think its still very useful to be able to select where you want them to show as for example you might not want them in markdown (I know I wouldn't) or some other file for some other reason, without an option a user is stuck either turning them on or off with no more granular control


Make git automatically remove trailing whitespace before committing

https://stackoverflow.com/questions/591923/make-git-automatically-remove-trailing-whitespace-before-committing (answer with 36 votes).

Close this, it is not required now.


Turret there are no some settings in multiplayer

playing sandbox in singleplayer , in turret :   there is a parameter : bullets per shot, Tracer every x bullets.
But if i change to multiplayer (2 players, 4 players...)   They disappear

There's some multiplayer limits imposed. I think they should be removed and replaced with cvars.
https://github.com/wiremod/wire/blob/master/lua/wire/stools/turret.lua#L97-L102
https://github.com/wiremod/wire/blob/master/lua/entities/gmod_wire_turret.lua#L117-L119
https://github.com/wiremod/wire/blob/master/lua/entities/gmod_wire_turret.lua#L123-L125


Update for new Github URL location

Update to URLs due to announcement of TFSec takeover.
https://github.com/aquasecurity/tfsec

Thanks for the PR @alastairhm ! I just merged #4 since it came in first, though.

No worries, beaten to the punch :)


Show the zoom value next to the scaleBarOverlay

Please note: issues related to or caused by osmbonuspack will be closed with a
suggestion to open an issue at https://github.com/MKergall/osmbonuspack
(feel free to delete whatever doesn't apply)
Issue Type
[* ] Question
[ ] Bug
[ ] Improvement
[ ] Build system related
[ ] Performance
[ ] Documentation
Description and/or steps/code to reproduce the problem
Hi,
I would like to display the zoom value next to the scale bar, how can we do that, please?
Regards
Michel Guenin
Environment
If it's a bug, version(s) of android this affects:
All
Version of osmdroid the issue relates to:
6.1.2

@Conan42 What do you mean with "zoom value"? Something like an integer from 0 to 19? A float?

a floating "x12.5" for example next to the scale bar

It is not supported out of the box. You can add a positioned TextView over the MapView in your XML layout.
Register a MapListener to read out the zoom level after each zoom event. You should use the DelayedMapListener version with a small delay for performance reasons (in the sample code below 100ms).
Kotlin sample code:
        map.addMapListener(DelayedMapListener(object : MapListener {
            override fun onScroll(event: ScrollEvent): Boolean {
                // handle scroll event
                return false
            }

            override fun onZoom(event: ZoomEvent): Boolean {
                // handle zoom event
                // update textview
                val df = DecimalFormat("##.#")
                txtZoomLevel.text = "x" + df.format(event.zoomLevel)
                return false
            }
        }, 100))

looks like this is answered, reopen if there are further questions


Update faqs.md

Proposed changes
"[...] zones you have access too" -> "to"
Just a simple typo fix :)

Thanks, @jeffhuys :)


Searchability report for API signatures and error messages

Add error messages in docs (FYI: @0x777 , @ecthiender).
Ensure API signatures and error messages have anchor tags
check for searchability

Why @rikinsk why?

@dsandip I felt it was done. Albeit with low quality. I guess a opening a new more specific issue would make more sense


Update bins.rs

Changed parameter name from b -> bin now matches other for loop naming

Thanks for your interest, but I'd rather not accept any refactoring changes, especially minor ones like this.


Error logging into iCloud Service

Home Assistant release: 0.34.2
Python release: 3.4.2
Component/platform: device_tracker
Description of problem:
Dec  5 21:05:17 raspberrypi hass[15796]: ERROR:pyicloud.base.http:statusCode = UnknownServerError, IOException sending request http://p23-accountservicevip:80/api/get_account_by_appleid_password, Timeout waiting for connection from pool
Dec  5 21:05:17 raspberrypi hass[15796]: ERROR:homeassistant.components.device_tracker.icloud:Error logging into iCloud Service: ('Invalid email/password combination.', PyiCloudAPIResponseError('statusCode = UnknownServerError, IOException sending request http://p23-accountservicevip:80/api/get_account_by_appleid_password, Timeout waiting for connection from pool',))
Dec  5 21:05:17 raspberrypi hass[15796]: ERROR:homeassistant.components.device_tracker.icloud:No ICLOUDTRACKERS added
Dec  5 21:05:17 raspberrypi hass[15796]: ERROR:homeassistant.components.device_tracker:Error setting up platform icloud

Problem-relevant configuration.yaml entries and steps to reproduce:
device_tracker:
  platform: icloud
  username: !secret icloud_username
  password: !secret icloud_password

I haven't changed my username and password and 20 minutes ago the device_tracker worked in 0.33

OK, figured out what happened.
Previously I was using login name<EMAIL_ADDRESS>It worked perfectly fine and it was linked to<EMAIL_ADDRESS>After 0.34.2 this stopped working.
Just for fun I changed the email to<EMAIL_ADDRESS>and voila! It works now.


feat: shrink bboxes by top left

Closes #1573.
Summary

update shrink_bbox() to keep top left rather than center

Evaluation
Run the following command for this PDF.
PYTHONPATH=. python examples/custom-layout-order/evaluate_xy_cut_sorting.py <file_path> <strategy>

This new fix seems to resulted in test failure in one pdf test. Let's make sure we check that first. Other than that, the code makes sense to me!

slight improvement in one case, overall not much of a difference.


Request to append an Interesting Mad Science GitHubRepo

Yo dudes.
I'm would like you guys check this repo,
https://github.com/feross/awesome-mad-science
and append this to mad-science topic.
Best wishes. Eu.

That list doesn't seem maintained.


Add a new verify-std subcommand to Kani

This subcommand will take the path to the standard library.
It will then use cargo build -Z build-std to build the custom standard
library and verify any harness found during the build.
Call out

So far I only performed manual tests. I'm going to add a few unit tests and a script in the next revision.

Resolves #3226
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

@jaisnan do you prefer a follow up PR?

@jaisnan do you prefer a follow up PR?

I do in this case, but only for the sake of speed here.


Panic when macro has doc comment argument

Here's a program that causes rustfmt (v0.4) to panic:
macro_rules! define_something {
    ($type_name:ident, #[$description:meta]) => {
        /// This represents a
        #[$description]
        /// that does blah blah blah.
        pub struct $type_name {
            _phantom: std::marker::PhantomData<()>,
        }
    }
}

define_something!(Foo, /** foo-thing */);

fn main() {
}

This kind of macro worked with rustfmt v0.3.
Here's the backtrace:
thread '<main>' panicked at 'explicit panic', /home/craig/.multirust/toolchains/stable/cargo/registry/src/github.com-88ac128001ac3a9a/syntex_syntax-0.30.0/src/errors/mod.rs:360
stack backtrace:
   1:     0x7f04b5c74220 - sys::backtrace::tracing::imp::write::hf7e21f48f7cb711bEju
   2:     0x7f04b5c76795 - panicking::default_handler::_<closure>::closure.42502
   3:     0x7f04b5c7623f - panicking::default_handler::hac4d0be12e3129d2Gwy
   4:     0x7f04b5c67ef6 - sys_common::unwind::begin_unwind_inner::hf13a3e016c1e78e1bct
   5:     0x7f04b59012e7 - sys_common::unwind::begin_unwind::h2616575216763365083
                        at ../src/libstd/sys/common/unwind/mod.rs:227
   6:     0x7f04b5916a6a - errors::DiagnosticBuilder<'a>.Drop::drop::hd72ad825f3e530645Ed
                        at /home/craig/art/rustfmt/<std macros>:3
   7:     0x7f04b574cd5c - syntax..errors..DiagnosticBuilder::drop.23354::h25602577c29d5f8d
   8:     0x7f04b58eb716 - core..result..Result<syntax..ptr..P<syntax..ast..Expr>, syntax..errors..DiagnosticBuilder>::drop.29930::h04e9c3c0ad27d039
   9:     0x7f04b57ce330 - macros::rewrite_macro::h683530a5fa37a240dno
                        at src/macros.rs:83
  10:     0x7f04b57be761 - visitor::FmtVisitor<'a>::visit_mac::h668550e50e5ac2df5Of
                        at src/visitor.rs:390
  11:     0x7f04b57bd50e - visitor::FmtVisitor<'a>::visit_item::hafde62ea9b31d7belEf
                        at src/visitor.rs:256
  12:     0x7f04b57d28a3 - visitor::FmtVisitor<'a>::walk_mod_items::h7a7428ee1356ac90STf
                        at src/visitor.rs:460
  13:     0x7f04b57279ae - visitor::FmtVisitor<'a>::format_separate_mod::h5ae0d4856f87fed2HWf
                        at src/visitor.rs:499
  14:     0x7f04b5724570 - fmt_ast::h11ec60f69209ee0dIZo
                        at src/lib.rs:281
  15:     0x7f04b57507e2 - format::h69a33b3cbc35198aA8o
                        at src/lib.rs:422
  16:     0x7f04b5750ac3 - run::h4ba396162e16379119o
                        at src/lib.rs:432
  17:     0x7f04b56dfe90 - execute::hf0c687af362492387ga
                        at src/bin/rustfmt.rs:236
  18:     0x7f04b56f2e49 - main::hf1be1d729aa9052fmpa
                        at src/bin/rustfmt.rs:245
  19:     0x7f04b5c75ec4 - sys_common::unwind::try::try_fn::h9896872240422604242
  20:     0x7f04b5c737f8 - __rust_try
  21:     0x7f04b5c75b50 - rt::lang_start::h0d9dcd8707a91319Uoy
  22:     0x7f04b56f43c9 - main
  23:     0x7f04b4abcb44 - __libc_start_main
  24:     0x7f04b56d82f8 - <unknown>
  25:                0x0 - <unknown>

This exact snippet does not crash in master or 0.6.2.
Also no crash when cargo-fmt is run on the https://github.com/chill-rs/chill master branch.
Probably fixed (or the snippet is not quite enough to reproduce it)

@cmbrandenburg can you confirm that this is fixed please?


ExcelDataReader does not read 1st row AFTER headers for each sheet in a workbook

First off, thank you for this library!
Hoping that I am just missing something really simple as to why this row doesn't appear in the results but I am attempting to read workbooks that have around 40+ worksheets worth of data. No matter how I adjust the header, I can never get the 1st row (after header, before rows 2+ of the data I need) of a worksheet to show up in the console. This happens for every worksheet in the workbook and I also tried to run this against a 'dummy' .xlsx file that is a single worksheet with only 5 columns but I get the same results there too. I'll provide some context up front in case it could help troubleshoot the issue.
DataBinderOptions = Any
Using 'pre-defined' ExcelSchema that specifies 11 columns.
The header row is not guaranteed to be the same for every worksheet
Snippet of a worksheet below.

So in this example, row 11 does not show up in the console but every other row appears. I can provide code here as needed but if you need access to an excel file, I would need to clean it up prior to providing it.

public class TMSSExcelSchema
    {
        /// <summary>
        /// Provides TMSS specific schema information.
        /// </summary>
        /// <returns></returns>
        public static ExcelSchema GetTMSSHeadersSchema()
        {
            Schema schema =
                new Schema.Builder()
                .Add("Time", "Time", typeof(string))
                .Add("Group", "Group", typeof(string))
                .Add("POI", "POI", typeof(string))
                .Add("Lesson Designator (POI File #)/Title", "Title", typeof(string))
                .Add("Resources", "Resources", typeof(string))
                .Add("Uniform", "Uniform", typeof(string))
                .Add("Hours", "Hours", typeof(string))
                .Add("Hours TDC", "Hours TDC", typeof(string))
                .Add("Instr:Student", "Instr:Student", typeof(string))
                .Add("Instr Req", "Instructor Required", typeof(string))
                .Add("Notes", "Notes", typeof(string))
                //.Add("Name", "Name", typeof(string))
                //.Add("Reports\nTo", "ReportsTo", typeof(string))
                //.Add("Job\nTitle", "JobTitle", typeof(string))
                //.Add("Number\nof\nDirect\nReports", "NumberofDirectReports", typeof(string))
                //.Add("Department", "Department", typeof(string))
                //.Add("Location", "Location", typeof(string))
                //.Add("Instr:Student", "Instr:Student", typeof(string))
                .Build();

            ExcelSchema tmssSchema = new ExcelSchema(true, schema);
            return tmssSchema;
        }
    }

Sent the excel file to you

Not only did you fix my originally reported issue of retrieving the 1st row but you went above and beyond in breaking down how I can stop the reader between the dates. This works perfectly. In hindsight, I should have spent more time reading the Sylvan.Data documentation and examples.
Thank you so much!


[Executor]Update LineResult.output for eager flow to dict

Description
Eager flow's LineResult.output will be it's original type, convert to dict since experiment scenario will expect it as a dict.
This pull request primarily focuses on two updates in the src/promptflow directory. The first update is in the _script_executor.py file, where the output of the _exec_line function is now ensured to be a mapping like dag flow. The second update is in the test_flow_test.py file, where a new test case test_eager_flow_with_dataclass_output has been added to verify the output of a flow with dataclass output.
Here are the key changes:

src/promptflow/promptflow/executor/_script_executor.py: The output of the _exec_line function has been updated to ensure it is a mapping like dag flow. This is achieved by changing the LineResult object to use output_dict instead of output.

src/promptflow/tests/sdk_cli_test/e2etests/test_flow_test.py: A new test case test_eager_flow_with_dataclass_output has been added. This test case checks if the output of a flow with dataclass output is a dictionary and matches the expected output.
Please add an informative description that covers that changes made by the pull request and link all relevant issues.

All Promptflow Contribution checklist:

[ ] The pull request does not introduce [breaking changes].
[ ] CHANGELOG is updated for new features, bug fixes or other significant changes.
[ ] I have read the contribution guidelines.
[ ] Create an issue and link to the pull request to get dedicated review from promptflow team. Learn more: suggested workflow.

General Guidelines and Best Practices

[ ] Title of the pull request is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

Offline synced, won't convert to dict in exec_line and will handle afterwards.


Doesn't auto choose XDR when making a cross-domain request

As a user of XHR, I would expect it to realize when the request will require CORS and choose to use XDR. This is mostly an issue on browsers like IE8 and IE9 where a CORS request requires the usage of XDomainRequest.

Thanks for reporting. I had that issue too. Over a year ago, when I was not involved with this project yet.
It's a wontfix kind of issue.
It only (not mostly) affects really old IEs and if you are using xdr you have to be aware of a lot of limitations anyway. Eg. Can't set or read any headers.
Detecting if the request is cross domain is also not as easy as we'd want to. So it'd be a big chunk of code added for eberyone while only very few users have any doubts if they are crossing domain boundaries or not on a particular request.
Having said all that, I'm open to pull requests with a small and elegant solution I couldn't come up with ;)
But it'd have to be complete. No half measures like handling only absolute urls or so. It should require no documentation.

Do you think something like https://github.com/videojs/video.js/blob/stable/src/js/xhr.js#L80-L84 is sufficient or are there some more usecase you can think off that won't be covered?

There's a better implementation than what I linked above in videojs/video.js#2633

That's still a lot of code for a library of the size of xhr anyway. We could distribute a separate library with that feature (assuming it doesn't exist already)
it's like with the qs package. We got requests to include that too, but it's better off as an optional thing you can add.

What about making it in an require('xhr/ie')? or require('xhr/cors')?

Yes, xhr/ie was considered before. This is yet another reason to finally do that.
Dropping all that mess to a separate file would be such a relief.

Should this be closed?

I'm keeping it open because people don't search closed issues and this is a wontfix.
I'll close it when we separate out old IE support


Add support for user defined script to generate labels.

The idea here is piped|configs.
--labels=/usr/bin/generate_json_or_yml_nvp_thunk.sh |
This is nice because different folks could create their own script files to detect:
cluster/rack awareness
gpu capabilities
over provisioning mechanics ...
discussion can be found here: https://github.com/docker/swarm/issues/239

@timothysc Why not just do docker -d $(generate_labels) ?
I must say I dislike the weird =| syntax, that would be yet another thing to support.

The syntax is pretty well defined, however I suppose you could also use strike_exec.
It looks like you were implying variable substation above, where enabling execution output could eliminate (1:N) steps necessary to start the daemon, and easing automation for those who tend to enjoy concise packed statements.
FWIW this is not a new idea, and exists in several clustering & batch systems.

Can you provide a few examples of other popular systems that support this kind of thing (preferably with links to documentation that details how to use it and why it's supported)?  I'm with @tiborvass here; I don't see any benefit you can't get with the shell already today without any code changes.

@vieux @tiborvass @tianon
Most common reference is here: http://research.cs.wisc.edu/htcondor/manual/v8.3/3_3Configuration.html#SECTION00431400000000000000
IIRC it was taken from other batch systems.
The primary benefit is automation in large, heterogeneous, multi-department environments, labels become a mechanism for discovery, constraint matching, accounting, and limits.
If you were to leverage envs, it can become quite messy if our set is large, and potentially non-conformant in the case where labels enable their own expression syntax, because then you need to "escape all the strings".
If docker is to provide facilities to enable higher order systems to leverage, then this would be useful.

@timothysc I'm not sure you're following what the other folks are saying.  You want to run a program and use the output as the input to the --label option.  They're saying you can do that via the shell today. The disagreement is just about the syntax, $(exe_name) vs exe_name |
We don't need to have docker re-invent what the shell already supports and people are used to.
I think we can close this.

Closing since I think we all agree it's better to use shell substitution to handle this rather than building this handling in docker itself.
Thanks for the proposal!

You can also use a --labels-file if that's more convenient.


feat!: Make Summary Box more flexible

Summary
Makes the SummaryBox component more flexible, separating out SummaryBoxHeading and SummaryBoxHeading into their own components.
Is NOT backwards compatible.
Related Issues or PRs
Closes #1916
How To Test

Try the SummaryBox Storybook story to ensure it still displays properly
Screenshots (optional)

I'm wondering if it would be worth breaking out the headingLevel change into its own issue/PR from the breaking change so that the headingLevel flexibility can be incorporated as a minor non-breaking change before the breaking change.

@Igarfinkle when merging this, please make sure that the commit body of the merge commit contains some verbiage like
BREAKING CHANGE: SummaryBox now exposes sub-components (SummaryBoxHeading and SummaryBoxContent) for a more compositional API. Consumers will need to update their implementation to match.


ReportCapableInterface should overload run(), not _run_interface()

Could you elaborate on the justification?
On Nov 26, 2016 11:27 PM, "Shoshana Berleant"<EMAIL_ADDRESS>wrote:

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/niworkflows/issues/30, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOkpysBGaOg9D0rio-DhMNrdCtg9SgQks5rCTDSgaJpZM4K9Fbx
.

If we overload run(), merging ReportCapableInterface with BaseInterfaceis a simple matter of copying the ReportCapableInterface.run() code into BaseInterface.run() (which is too big, but that's another concern). For now, overloading _run_interface() works perfectly well (aside from some complicated error handling and passing), but when we merge the interfaces, it will entail a lot of changes because BaseInterface._run_interface() is abstract by design (raises NotImplementedException).
I originally wrote ReportCapableInterface as overloading run(), but that doesn't work for some reason, so Ross switched to _run_interface() for now. It is puzzling, because according to the architecture of nipype it ~should~ work.

I don't think it makes sense to merge this functionality into BaseInterface

after all not all Interfaces will be capable of generating reports. The
original design we discussed (notes from the meeting here:
https://github.com/poldracklab/fmriprep/issues/176) involved a mixin class
instead of modification of BaseInterface. This solution seems better and
can still be incorporated into nipype.

I currently don't see advantages of refactoring the code to use run()
(especially considering other burning issues), but we can discuss further
tomorrow.
On Nov 27, 2016 8:09 PM, "Shoshana Berleant"<EMAIL_ADDRESS>wrote:

If we overload run(), merging ReportCapableInterface with BaseInterfaceis
a simple matter of copying the ReportCapableInterface.run() code into
BaseInterface.run() (which is too big, but that's another concern). For
now, overloading _run_interface() works perfectly well (aside from some
complicated error handling and passing), but when we merge the interfaces,
it will entail a lot of changes because BaseInterface._run_interface() is
abstract by design (raises NotImplementedException).
I originally wrote ReportCapableInterface as overloading run(), but that
doesn't work for some reason, so Ross switched to _run_interface() for
now. It is puzzling, because according to the architecture of nipype it
should work.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/niworkflows/issues/30#issuecomment-263179623,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOkp21_D6TFp5OPRilfzkOAqyW-kk3xks5rClQPgaJpZM4K9Fbx
.

Ah, there has been a miscommunication. I thought the mixin was a temporary
solution for niworkflows, but that it would be merged into nipype as a
superclass or into BaseInterface. The reason is that nipype has no multiple
inheritance at all, which I assumed is by policy. Unfortunately Report
Input/Output Spec classes cannot be implemented as mixins because they must
inherit from TraitSpec (@oesteban). There are some principled reasons to
avoid multiple inheritances:
https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem. python
does have a neat way to solve this, which we are taking advantage of in
niworkflows, but it's not standard to programming, and seeing as lots of
contributers to nipype are not native pythonistas (or even programmers), it
seems like a good idea to avoid tricky pitfalls. If we think nipype's dev
community won't care about the mixin/multiple inheritance, then we can
leave ReportCapableInterface alone.
@rwblair since you were in this conversation, how did you interpret things?
(I just thought of a third option, which would be creating decorators to
achieve the composition of BaseInterface and ReportCapableInterface.)
On Sun, Nov 27, 2016 at 8:37 PM Chris Filo Gorgolewski <
<EMAIL_ADDRESS>wrote:

I don't think it makes sense to merge this functionality into BaseInterface

after all not all Interfaces will be capable of generating reports. The
original design we discussed (notes from the meeting here:
https://github.com/poldracklab/fmriprep/issues/176) involved a mixin class
instead of modification of BaseInterface. This solution seems better and
can still be incorporated into nipype.

I currently don't see advantages of refactoring the code to use run()
(especially considering other burning issues), but we can discuss further
tomorrow.
On Nov 27, 2016 8:09 PM, "Shoshana Berleant"<EMAIL_ADDRESS>wrote:

If we overload run(), merging ReportCapableInterface with BaseInterfaceis
a simple matter of copying the ReportCapableInterface.run() code into
BaseInterface.run() (which is too big, but that's another concern). For
now, overloading _run_interface() works perfectly well (aside from some
complicated error handling and passing), but when we merge the
interfaces,
it will entail a lot of changes because BaseInterface._run_interface() is
abstract by design (raises NotImplementedException).
I originally wrote ReportCapableInterface as overloading run(), but that
doesn't work for some reason, so Ross switched to _run_interface() for
now. It is puzzling, because according to the architecture of nipype it
should work.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/poldracklab/niworkflows/issues/30#issuecomment-263179623
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAOkp21_D6TFp5OPRilfzkOAqyW-kk3xks5rClQPgaJpZM4K9Fbx
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/niworkflows/issues/30#issuecomment-263182018,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVoREHiDHdALBqJsIJfOa1PPUXzcbv8ks5rClqKgaJpZM4K9Fbx
.

It seems that report capable input/output specs are currently implemented as mixins - see: https://github.com/poldracklab/niworkflows/blob/master/niworkflows/interfaces/registration.py#L12. I gather that this solution can and does work (if it doesn't we will discover it soon).
The general discussion on what is easier for the nipype community is very valuable, but I feel it should take place when this functionality will be proposed for integration as PR to nipy/nipype. I would prefer to avoid costly preemptive refactoring efforts and submit that PR with the current solution and solicit comments.


parser: fix TableName and DeleteStmt

What problem does this PR solve?

In MySQL 5.7 , phrases like .identifier is valid as TableName, while TiDB not. for example, CREATE table .t (a bigint) is valid in MySQL 5.7 but failed in TiDB for now.
#189 tried to implement Restore for DeleteStmt, but there's a little mistake: the .* syntax should not be defined as part of TableName. It should be defined as an independent term and be used in DeleteStmt only, as is defined in MySQL Parser

Check List
Tests

Unit test
Integration test
Manual test (add detailed scripts or steps below)

Code changes
N / A
Side effects
N / A
Related changes

Need to cherry-pick to the release branch
Need to update the documentation
Need to be included in the release note

CREATE table .t (a bigint)

Since this is invalid in MySQL 8.0 I don't think we want to support this. WDYT @leoppro @tangenta

CREATE table .t (a bigint)

Since this is invalid in MySQL 8.0 I don't think we want to support this. WDYT @leoppro @tangenta

But currently TiDB and the Parser is mainly MySQL 5.7 compatible, and it seems long way for TiDB and the users to migrate to MySQL 8.0's behavior. I'm not sure if we should ignore the MySQL 5.7 compatible issues now....
BTW, What's the compatibility strategy do we hold for the Parser now?  As I've mentioned in #506 , currently the Parser seems a mixture of MySQL 5.7, MySQL 8.0 and MariaDB.

@spongedu We intend to be eventually compatible with 8.0 (pingcap/tidb#7968), so if a missing 5.7 feature is deprecated or removed on 8.0 we won't support it (unless it is trivial). Example of such rejected feature requests: pingcap/tidb#3685, pingcap/tidb#4025, pingcap/tidb#10092.

@spongedu We intend to be eventually compatible with 8.0 (pingcap/tidb#7968), so if a missing 5.7 feature is deprecated or removed on 8.0 we won't support it (unless it is trivial). Example of such rejected feature requests: pingcap/tidb#3685, pingcap/tidb#4025, pingcap/tidb#10092.

OK.

@kennytm @leoppro @tangenta  PTAL

@crazycs520  PTAL :)

@spongedu Please help resolve the confliting files.

@SunRunAway  PTAL :)


Should work with text emails

As per #1, this should allow the package to work with simple emails.

This is good. But just wondering if we ever want to show both html and text versions, if the user supplies both values?

I'm not sure where that would make sense, but the docs say html and/or text. I'm not even sure how Meteor would handle it...

It's a good start. Merged. You can refer to this StackOverflow question if curious.


Server information should be cleared when following redirect

See backport PR 1900, this is required along wth 1900.
(cherry picked from commit e01f7ff372293da71724ced0815d02048c8b96dc)
Conflicts:
proxy/http/HttpTransact.h

going to add this to PR 1900


chore: Remove compiled CSS assets

Following up on https://github.com/eslint/new.eslint.org/pull/178#issuecomment-1079531902. These were already gitignored, so I just needed to delete them:
https://github.com/eslint/new.eslint.org/blob/51f32f03d55932d9864044a95fd2fcc77b7845e0/.gitignore#L13

Closing in favor of #180.


Mermaid flowchart doesn't seem to be supported

Hi,
It seems the mermaid flowchart isn't supported. I tried to work around by switching from "flowchart" to "graph", but subgraph can't interact with other components. Below is an example that the extension is not able to display. Can you help me check what the issue is?
flowchart TD
    subgraph sub
        direction LR
        a --> c
        b --> c
    end
    1 --> sub
    sub --> 2
    2 -->|info| 3

I got here by trying to show a git graph - but I think the problem is the same. In my case I needed to remove the %%{init:{ ... from the start of the mermaid, and add a trailing colon : after gitGraph (neither change is required for valid mermaid syntax)

Looking into the code I think the issue is in the recognition of mermaid charts. There is a regex to check for valid charts - and this will not match flowchart:
matchRegex: /^(sequenceDiagram|graph\s+\w{2}|gantt|classDiagram|pie|gitGraph:|erDiagram|journey)\s*\n/,

It will also (unsurprisingly!) not match any of the other new diagram types added since August 2020
2 options would be:

find the missing graph types (from mermaid releases and update the regex

this would work until the next new type is added
it would not support the %%{init{ unless that was also added to the regex (care should be taken to allow for whitespace / new lines within the above)

remove the regex for matching and always assume that a mermaid block may be valid and send it to the service

mermaid is robust to errors and this way the extension would show the mermaid error image if the mermaid syntax is invalid
this extension would be automatically as up to date with mermaid releases as the kroki.io service

I have the same problem with the mermaid flowchart diagram. Would it be possible to get this fixed?
The plugin otherwise is very useful!


Create Sign in / Welcome page

PR: #11
#4

[x] Placeholder messaging text
[x] Layout
[x] Button to sign in with Github

Screenshots:

This is already completed in #11 by @partiallymisplaced


Fix issue#534: Adding Lightboxes for Crop Images

Added CSS for lightbox to the crop cover-img
Added CSS for smaller crop images to turn colorful from grayscale ones

Hopefully, what I've done will fix #534

Coverage remained the same at 99.297% when pulling 11e560ca7d9312ecf595b4ef1530819fcd995b6e on TanSA05:tansa05issue534 into e9c14a23585497778cbfaf94c8c97844d7f4ff06 on openfarmcc:master.

Coverage remained the same at 99.297% when pulling be1c2068e64c4454c69c15b52f04ec36f0f89dea on TanSA05:tansa05issue534 into e9c14a23585497778cbfaf94c8c97844d7f4ff06 on openfarmcc:master.


Improve footer white 10

footer-white-10 fix responsiveness for 360px devices

@Rajdip019 @rupsha014 Please assign this to me

@RavindraP04  go ahead


Avoid searching for Jupyter when using Raw Kernels (when Python runtime isn't necessary)

Today even when a user is working on non-python kernels, we attempt to look for Jupyter, even when this isn't required.

Again, testing has been covered in other issues.
Bascially in the past even when using raw kernels, we'd perform a search for an Interpreter that supports Jupyter.
Now that code path isn't executed anymore.


Twitter next version support

Hello from Twitter Developer Relations!
First of all: Thank You, for building on our API, and for supporting our developer communities! You, and many projects like this one, are among the reasons why Twitter data is much-appreciated by developers. We historically haven't built libraries and SDKs - the communities, YOU, have done so - and I'm here to tell you how much we appreciate that, and that we know you're around! In a recent survey I conducted, PHP was a very high usage language, so we do understand that very many web and PHP developers want to interact on Twitter.
We're currently building a brand new API platform that (over time) will replace the current one. I would love to connect with you on any plans to add support for Twitter Developer Labs to twitter-lite! We're looking to be much more focused on proper API versioning, and are basing our specification on OpenAPI. One thing I unfortunately cannot offer, and I know we already spoke about on Twitter, is a change to data volumes on streams - but it's something I'll continue to champion for you if I can.
Thank you again for building for our platform.

Hi @andypiper, thanks for checking in! We've already added support for annotations and are looking forward to future developments of your new API :)

I would love to connect with you on any plans to add support for Twitter Developer Labs to twitter-lite!

Bad copy paste? 😅


Deleted/tests

Deleted these tests because based on our design decision these components are going to change radically. New tests will need to be written.

Nice work!


A number of fixes that needed to be made to first-init.command to get cluster rebuilt

Fix issue with vagrant scp complaining about no "default" machine because host name was not provided
Fix issue with spinner not working properly (division by 0 and stderr causing new lines to be printed over and over)
Fix issue with kibe-system namespace (not present) used by SkyDNS and Kube-UI yaml config files

It's still broken even with these fixes, so I'd hold off on a release

ok, will not release a new binary yet. very busy do not have much time to test it myself

namespace gets created automatically by provisioning  SkyDNS and Kube-UI, tested on k8s v1.0.6
 kubectl --namespace=kube-system get services NAME       LABELS                                                                         SELECTOR           IP(S)            PORT(S) kube-dns   k8s-app=kube-dns,kubernetes.io/cluster-service=true,name=kube-dns              k8s-app=kube-dns   <IP_ADDRESS>      53/UDP                                                                                53/TCP kube-ui    k8s-app=kube-ui,kubernetes.io/cluster-service=true,kubernetes.io/name=KubeUI   k8s-app=kube-ui    <IP_ADDRESS>   80/TCP
Latest release of App will not have an option to create that namespace


When I save my js file, vs code format my source code,It is so bad

VSCode Version: Code 1.6.1 (9e4e44c19e393803e2b05fe2323cf4ed7e36880e, 2016-10-13T16:21:53.542Z)
OS Version: Windows_NT ia32 10.0.10586
Extensions: lonefy.vscode-JS-CSS-HTML-formatter-0.2.1

Steps to Reproduce:
When I save my js file, "vs code" format my source code,It is so bad.
Like so:
[
'text'
, 'radio'
, 'checkbox'
].forEach
When I hit ctrl + s,code format like this below:
[
'text', 'radio', 'checkbox'
].forEach

@advxp thank you for opening this issue. It looks like you have a formatter extension installed. Can you uninstall the extension and try again? If the issue is for the extension please open this issue in the extension's repo.

Closing until more info is obtained.


d3.layout.pie: return arcs in original data order.

Fixes #406.

Looks good. Thank you for adding tests!


Performance issue (resolving of generic types)

Performance issue (resolving of generic types)
container.RegisterType(typeof(ISomeGenericClass<>), typeof(SomeGenericClass<>));

To Reproduce
Resolve generic type e.g ISomeGenericClass several times. "Cold" time resolving will be equal to "Hot"
Example of ISomeGenericClass usage:
	public interface ISomeGenericClass<T> where T: class
	{
	}

	public class TestClass: ITestClass
	{
		public TestClass(ISomeGenericClass<Class1> )
		{
		}
	}

Additional context
It causes 100% CPU when you have a lot of generic types (each resolve is "cold" and requires more CPU time then "Hot")
Workaround
Register generic types explicit:
container.RegisterType(typeof(ISomeGenericClass<Class1>), typeof(SomeGenericClass<Class1>));
container.RegisterType(typeof(ISomeGenericClass<Class2>), typeof(SomeGenericClass<Class2>));
container.RegisterType(typeof(ISomeGenericClass<Class3>), typeof(SomeGenericClass<Class3>));

Wich .NET version and runtime environment?
I do use Unit Container in some large Enterprise class applications using the same scenario, for around one decade, and never got such issue.
Neither on Full .NET Framework, nor with .NET Core, or either in mixed scenarios (.NET Standard + MVC 5 on .NET Framework 4.5, then 4.6 and actually on 4.7)

@Ruslan-Dulina

Resolve generic type e.g ISomeGenericClass several times. "Cold" time resolving will be equal to "Hot"

When you register:
RegisterType(typeof(ISomeGenericClass<>), typeof(SomeGenericClass<>));

you instruct Unity to always create new (Transient Lifetime) closed generic type from a 'factory' SomeGenericClass<>.
Generics are always created from scratch by design (since version 1) and since it is a transient lifetime the creation process repeated over and over...

We use <TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion> MVC4.
Before we used  <package id="Unity" version="4.0.1" targetFramework="net451" /> and this registration
RegisterType(typeof(ISomeGenericClass<>), typeof(SomeGenericClass<>));

worked without any issues
For example 4.0.1 when we resolve SomeController with dependecy on ISomeGenericClass<Class1>
For first request time around 30 ms
Second request time around 3 ms
Third request time around 3 ms
...
For example 5.8.11 when we resolve SomeController with dependecy on ISomeGenericClass<Class1>
For first request time around 30 ms
Second request time around 30 ms
Third request time around 30 ms
...
From our dumps(CPU 100%) I see that all threads are stuck somewhere there:
(System.Reflection.Emit.DynamicMethod.CreateDelegate(System.Type, System.Object)), calling (stub for System.Runtime.CompilerServices.RuntimeHelpers._CompileMethod(System.IRuntimeMethodInfo)) (System.Linq.Expressions.Compiler.LambdaCompiler.Compile(System.Linq.Expressions.LambdaExpression, System.Runtime.CompilerServices.DebugInfoGenerator)), calling (System.Linq.Expressions.Compiler.LambdaCompiler.CreateDelegate()) (Unity.ObjectBuilder.BuildPlan.DynamicMethod.DynamicMethodBuildPlanCreatorPolicy.CreatePlan(Unity.Builder.IBuilderContext, Unity.Builder.INamedType)), calling (System.Linq.Expressions.Compiler.LambdaCompiler.Compile(System.Linq.Expressions.LambdaExpression, System.Runtime.CompilerServices.DebugInfoGenerator))

Wasn't you using some other lifetime manager? Maybe configuring It from web.config, and it's not being configured with the new package?
As @ENikS explained, with transient lifetime manager (default), the resolve times should be near the same, as it's being build every time.


feat(servicerelease):get offer(services) in_review and active state

New Endpoint to Get all services in status "in Review" & "ACTIVE"
ref:- CPLP-2417

@qxz2mqe can we get this ready for a new review by Philip and Norbert tomorrow before lunch?

@jjeroch It is ready for review and philip has reviewed and approved it

@jjeroch It is ready for review and philip has reviewed and approved it

@qxz2mqe alright can you have a look into the conflicts as soon as you have finished the work on the /provided endpoint, ideally afterwards we can merge it


Add tukorea

Tech University of Korea
Official Website URL : https://www.tukorea.ac.kr/

@dd-q I am sorry, the domain tukorea.ac.kr is removed from our trusted domains list because it was abused in the past. If you are the student of this school, please enroll to GitHub Student Developer Program. Then apply for JetBrains educational subscription with your GitHub account (GitHub tab at https://www.jetbrains.com/shop/eform/students).


M3U8 Downloading with YT-DLP by passing data as a parameter

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

[X] I understand that I will be blocked if I intentionally remove or skip any mandatory* field

Checklist

[X] I'm asking a question and not reporting a bug or requesting a feature
[X] I've looked through the README
[X] I've verified that I have updated yt-dlp to nightly or master (update instructions)
[X] I've searched known issues and the bugtracker for similar questions including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue

Please make sure the question is worded well enough to be understood
i tried to send get request with data as a parameter:
import requests

x=requests.get(
  'https://livepullsm.facecast.live/live/23331_sm_9cc3wn78.m3u8?txSecret=dc703b3b5c9e353c2538de0c518358d2&txTime=65BB30AD',
  data={'systoken': '43d0a1d8176ea2df98f14547ee5dee56'})

print(x.text)

it return this:
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-ALLOW-CACHE:NO
#EXT-X-MEDIA-SEQUENCE:1706680207
#EXT-X-TARGETDURATION:3
#EXTINF:1.954,
23331_sm_9cc3wn78-1706680207.ts?txspiseq=106387013612687064120
#EXTINF:2.008,
23331_sm_9cc3wn78-1706680208.ts?txspiseq=106387013612687064120
#EXTINF:2.061,
23331_sm_9cc3wn78-1706680209.ts?txspiseq=106387013612687064120

taking those systoken as a params won't work, i tried this:
requests.get('https://livepullsm.facecast.live/live/23331_sm_9cc3wn78.m3u8?txSecret=dc703b3b5c9e353c2538de0c518358d2&txTime=65BB30AD&systoken=43d0a1d8176ea2df98f14547ee5dee56')

and it return none.
The question is:
I'm trying to download the same url on yt-dlp but i don't really know how do i pass the data. i hope you can help me to find the way to do that.
Provide verbose output that clearly demonstrates the problem

[X] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[X] If using API, add 'verbose': True to YoutubeDL params instead
[X] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
Error: [debug] Command-line config: ['-vU', 'https://livepullsm.facecast.live/live/23331_sm_9cc3wn78.m3u8?txSecret=dc703b3b5c9e353c2538de0c518358d2&txTime=65BB30AD&systoken=43d0a1d8176ea2df98f14547ee5dee56']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8 (No ANSI), error utf-8 (No ANSI), screen utf-8 (No ANSI)
[debug] yt-dlp version<EMAIL_ADDRESS>from yt-dlp/yt-dlp [f10589e34] (pip)
[debug] Python 3.9.18 (CPython x86_64 64bit) - Linux-5.15.0-1051-aws-x86_64-with-glibc2.36 (OpenSSL 3.0.11 19 Sep 2023, glibc 2.36)
[debug] exe versions: ffmpeg 5.1.4-0 (setts), ffprobe 5.1.4-0, phantomjs 2.1.1
[debug] Optional libraries: Cryptodome-3.20.0, brotli-1.1.0, certifi-2023.11.17, mutagen-1.47.0, requests-2.31.0, sqlite3-3.40.1, urllib3-2.2.0, websockets-12.0
[debug] Proxy map: {}
[debug] Request Handlers: urllib, requests, websockets
[debug] Loaded 1798 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
[debug] Identified a direct video link
ERROR: [generic] Failed to download m3u8 information: HTTP Error 403: Forbidden (caused by ); please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
  File "/usr/local/lib/python3.9/site-packages/yt_dlp/extractor/common.py", line 718, in extract
    ie_result = self._real_extract(url)
  File "/usr/local/lib/python3.9/site-packages/yt_dlp/extractor/generic.py", line 2420, in _real_extract
    formats, subtitles = self._extract_m3u8_formats_and_subtitles(url, video_id, 'mp4', headers=headers)
  File "/usr/local/lib/python3.9/site-packages/yt_dlp/extractor/common.py", line 1968, in _extract_m3u8_formats_and_subtitles
    res = self._download_webpage_handle(
  File "/usr/local/lib/python3.9/site-packages/yt_dlp/extractor/common.py", line 906, in _download_webpage_handle
    urlh = self._request_webpage(url_or_request, video_id, note, errnote, fatal, data=data, headers=headers, query=query, expected_status=expected_status)
  File "/usr/local/lib/python3.9/site-packages/yt_dlp/extractor/common.py", line 863, in _request_webpage
    raise ExtractorError(errmsg, cause=err)

  File "/usr/local/lib/python3.9/site-packages/yt_dlp/YoutubeDL.py", line 4082, in urlopen
    return self._request_director.send(req)
  File "/usr/local/lib/python3.9/site-packages/yt_dlp/networking/common.py", line 114, in send
    response = handler.send(request)
  File "/usr/local/lib/python3.9/site-packages/yt_dlp/networking/_helper.py", line 204, in wrapper
    return func(self, *args, kwargs)
  File "/usr/local/lib/python3.9/site-packages/yt_dlp/networking/common.py", line 325, in send
    return self._send(request)
  File "/usr/local/lib/python3.9/site-packages/yt_dlp/networking/_requests.py", line 343, in _send
    raise HTTPError(res, redirect_loop=max_redirects_exceeded)
yt_dlp.networking.exceptions.HTTPError: HTTP Error 403: Forbidden

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

Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/yt_dlp/extractor/common.py", line 850, in _request_webpage
    return self._downloader.urlopen(self._create_request(url_or_request, data, headers, query))
  File "/usr/local/lib/python3.9/site-packages/yt_dlp/YoutubeDL.py", line 4114, in urlopen
    raise _CompatHTTPError(e) from e
yt_dlp.networking.exceptions._CompatHTTPError: HTTP Error 403: Forbidden

Return Code: 1
PiD: 114

You cant. Write a dedicated extractor instead, and provide it as a plugin

if that m3u8 is for a livestream, then it's not even possible with a dedicated extractor, since ffmpeg cannot send POST request data

that is sad.

hm, but it's not post request.

regardless of GET vs POST, ffmpeg still cannot send the payload

maybe see if it works sending the data params as the query instead?

i see.

no it does not, i sended as a params, but it returns none.

well, admins of facecast maybe don't want anyone to scrape their m3u8 url, even after i found that systoken as payload works by lucky.

hum interessante fiz uma gambirra q baixou os .ts files


Edit Loans - Container Catalog Numbers not displaying

When I am adding a container to a loan, the catalog number does not show up next to the loan in the loan items display, making it hard to track from the task.
The catalog number (if assigned one as a container) should show up next to the container so it is findable.

@mjy @jlpereira can I bump this issue up to fix? It is confusing to those creating loans and those receiving loans.


[ENH]: move materialization into operator

Description of changes
Summarize the changes made by this PR.

Improvements & Bug fixes

...

New functionality

...

Test plan
How are these changes tested?

[ ] Tests pass locally with pytest for python, yarn test for js, cargo test for rust

Documentation Changes
Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the docs repository?

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#3166  👈 (View in Graphite)
#3165
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Superseded by https://github.com/chroma-core/chroma/pull/3357 (moved to new branch, easier than rebasing).


chore(main): release 1.6.1

:robot: I have created a release beep boop
1.6.1 (2024-12-02)
Bug Fixes

do not log silly thing on sigTerm (#56) (a965974)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v1.6.1
:sunflower:


Target .NET Standard/Core

Codecov Report

Merging #27 into master will decrease coverage by 0.54%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #27      +/-   ##
==========================================
- Coverage   90.12%   89.57%   -0.55%
==========================================
  Files          54       54
  Lines         729      729
  Branches       66       66
==========================================
- Hits          657      653       -4
- Misses         69       72       +3
- Partials        3        4       +1

Impacted Files
Coverage Δ

toofz.NecroDancer.Leaderboards/GZipHandler.cs
92.3% <0%> (-7.7%)
:arrow_down:

...cer.Leaderboards/Steam/WebApi/SteamWebApiClient.cs
97.22% <0%> (-2.78%)
:arrow_down:

...z.NecroDancer.Leaderboards/toofz/ToofzApiClient.cs
95.23% <0%> (-2.39%)
:arrow_down:

...Leaderboards/Steam/ClientApi/SteamClientAdapter.cs
27.17% <0%> (-1.09%)
:arrow_down:

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 98f5425...b83b5d9. Read the comment docs.


Body-related errors of requests over HTTP/2 are swallowed by Hyper

Errors emitted by the HttpBody impl sent as a request body through the HTTP/2 client are not returned to the caller.
https://github.com/hyperium/hyper/blob/8a05f8eec133793899c94dcbf1520eee3b91aa50/src/proto/h2/client.rs#L243-L247
I understand that this is because contrary to HTTP/1, the request body can be sent at the same as the response is received, so Hyper doesn't wait before returning the response, but that also means that the errors completely disappear and Hyper only notices something went wrong when trying to receive the response body, at which point it returns to the caller an error about the stream being reset.
Any ideas on how to improve that? Maybe we should implement an Extension that lets us await on a one-time channel to get the error?

Are they completely swallowed? I think in all cases, they will bubble out the other sides. For instance, if the error comes from the h2 SendStream, it's likely from a stream or connection error. That will appear when polling for the response data. If the error is from the HttpBody, it will force sending a reset code, which the generic error will appear again when polling for the response data.
Well, I suppose if sending the body is the only thing left, you've already received the response and the full response body, then there'd be no way to see the error. Is that the situation you mean?

By swallowed I mean we lose the exact reason that caused the error. Our system emits some errors on purpose and those should not be logged as they are completely expected behaviour, unfortunately they surface as a generic error as you said.

What do you think of introducing a public extension in Hyper, something like:
type BoxError = Box<dyn Error + Send + Sync>;

fn request_body_poll_error_extension() -> (RequestBodyPollErrorExtension, RequestBodyPollErrorReceiver);

impl Future for RequestBodyPollErrorReceiver {
    type Output = Result<BoxError, Cancelled>;
}

In the implementation, RequestBodyPollErrorExtension and RequestBodyPollErrorReceiver would just be wrappers over Sender<BoxError> and Receiver<BoxError> from futures::channel::oneshot.
To use that extension, the user calls request_body_poll_error_extension and installs the returned RequestBodyPollErrorExtension in the request's extensions before passing it to the Hyper client.
The h1 support then completely disregards the extension, as it returns request body poll errors directly when sending the request before receiving the response.
On the h2 side, things get interesting.
First, we can patch this snippet to make pipe be a future that properly returns the error without silencing it:
https://github.com/hyperium/hyper/blob/8a05f8eec133793899c94dcbf1520eee3b91aa50/src/proto/h2/client.rs#L243-L247
Then, in this snippet, we make the eagerly poll fulfill the callback directly if an error has been returned already:
https://github.com/hyperium/hyper/blob/8a05f8eec133793899c94dcbf1520eee3b91aa50/src/proto/h2/client.rs#L251-L252
If the eager poll is pending, we look up the RequestBodyPollErrorExtension and we wrap pipe in a new future that will send any poll error on the onetime channel, there:
https://github.com/hyperium/hyper/blob/8a05f8eec133793899c94dcbf1520eee3b91aa50/src/proto/h2/client.rs#L259-L264
If the Hyper client returns Ok(response) to the user, the user is then free to check the RequestBodyPollErrorReceiver it kept, either on error while receiving the response body, or until the receiver returns Ok(error) (meaning the body was not sent successfully) or Err(Cancelled) (meaning the body was successfully sent).

That last part makes me wonder: how can a user even check that their request body was successfully sent over h2, if they are not polling that the response body was properly received?

Given the last sentence of my previous comment, maybe the actual mechanism we need is some sort of "request body send observer", that we can await on until the request body was successfully grabbed and sent or an error was returned by poll_data.


[FEATURE] Support saving of lists and dicts in a formatted way, including other SavesProjectID or Asset instances

Is your feature request related to a problem? Please describe.
When saving a Scene, SavedAttributes can only be saved properly if they are one of the following types: str, int, float, SavesProjectID (including Asset), Vector, Quaternion, RGB, HSV. However, it is also useful to support saving lists or dicts of these types, which could even support nesting.
Describe the solution you'd like
Such a format would be similar to YAML, with a few differences: the list format would have a different prefix other than - , the dict keys would be any of the above types properly formatted (maybe apart from the floating-point classes since they would rarely match) and indents would be 4 spaces instead of 2.
Describe alternatives you've considered
Currently, the SavableStruct has a similar format but does not support nesting.
Additional context
This would make Button be able to save the kwargs argument in the Scene file.

Typechecking must be implemented somehow, which means the type given to SavedAttributes needs to be from typing.GenericAlias or something similar.
Undecided if recursive structures should be allowed.
The existing SavableStruct class decorator has promising code.


[Bug]: Kyverno-policies helm chart has hardcoded Kubernetes version annotations

Kyverno Version
1.12
Kubernetes Version
1.28
Kubernetes Platform
Other (specify in description)
Description
When deploy policies using Kyverno-policies helm chart 3.2.5 I can see Chart.yaml is specified kubeVersion: '>=1.25.0-0' and appVersion: v1.12.5.
When I view effective yaml of policies I see:
kyverno.io/kyverno-version: 1.6.0
policies.kyverno.io/minversion: 1.6.0
kyverno.io/kubernetes-version: "1.22-1.23"

There is no value I can change this.
Steps to reproduce

helm repo add kyverno https://kyverno.github.io/kyverno/
helm template kyverno/kyverno-policies --version 3.2.5 | grep kyverno.io/kyverno-version
helm template kyverno/kyverno-policies --version 3.2.5 | grep kyverno.io/kubernetes-version

Expected behavior
I would like to have a value in values.yaml using which I can control this behavior
Screenshots
No response
Kyverno logs
No response
Slack discussion
No response
Troubleshooting

[X] I have read and followed the documentation AND the troubleshooting guide.
[X] I have searched other issues in this repository and mine is not recorded.

Thanks @sergey198828 for creating the issue.
kyverno.io/kyverno-version: 1.6.0 should be updated upon each new Kyverno release. Feel free to raise a PR for the fix.
kyverno.io/kubernetes-version: "1.22-1.23" should be the Kubernetes versions we tested and verified, they don't seem to be updated though.

Thanks @realshuting, opened Pull request.
https://github.com/kyverno/kyverno/pull/11258


Create container with port forwarding

This PR resolves https://github.com/alexsteinerde/docker-client-swift/issues/8 by adding the ability to create containers with port forwarding. The changes are non-breaking:

DockerClient#createContainer(...) updated to take a third portBindings parameter that is an array of PortBindings (defaulting to empty array - no port forwarding). (See doc comment for details) of PortBinding.
DockerClient#start(...) updated to return an array of PortBindings -indicating the the actual port bindings. This is mainly for use cases where the client makes a request to forward to a random available host port (hostPort=0), such that the client is able to get the actual bound port. If the requested hostPort is non-0, the return value should just be what the client provided.

Changes were made to the Docker JSON model to support this.

Thanks for the PR.
I'll look into this.
By the way the following fork of this repository implemented a lot more functionality. Maybe you want to check it out as well:
https://github.com/m-barthelemy/DockerSwift

I just noticed, that this doesn't compile under Linux because the Network framework isn't available there.
Is there a reason to use typed IPv4 and IPv6 addresses there?

I just noticed, that this doesn't compile under Linux because the Network framework isn't available there. Is there a reason to use typed IPv4 and IPv6 addresses there?

My main reason for using typed addresses (vs just strings) is to try and make it harder for client codes to make mistakes (by passing in arbitrary strings, for instance). I had not considered Linux support, but would like to support it.
Do you happen to know if there are Swift typed IP address implementations other than what's in Network? If not, we can just use strings. I quickly looked through SwiftNIO and didn't find anything.

I didn't find a typed IP implementation as well. There is the SocketAddress type but that also holds the port and is a too heavy type for this problem in my opinion.