Describe the bug
When I pull the resize button of the code editor, it doesn't the resize the code in the editor.

To Reproduce
Steps to reproduce the behavior:

1. Click the resize button on the code editor and drag it down
2. The code doesn't resize

Expected behavior
I expected the code to resize as I drag down the button.

Screenshots
If applicable, add screenshots to

Describe the bug
When linting a file, it is useful to ensure exactly what file is being checked.

To Reproduce
Steps to reproduce the behavior:

1. checkout a repo
2. run inso lint spec ./spec.yaml
3. see FATAL error

Expected behavior
Expect the file to be read, loaded and linted properly.

Screenshots
n/a cli operation

**Desktop (please complete the following inf

Long story short

I've been using low-level machinery exposed by aiohttp for my framework.
When I learned about handle_signals=True I started testing it and it turned out that my process always exited with return code 1 on SIGTERM and SIGINT.

This was confusing and I thought that it's a bug. But then, after diving into the code deeper, I realized that with this option enabled, aioht

建议使用ConcurrentHashMap
eg:private final Map<Class, ObjectParamMetadata> classToMetadata = new ConcurrentHashMap, ObjectParamMetadata>();

此处s是否可

I've read many similar closed issues, but haven't found a good documented solution on what can I do as a consumer of ky package if I need to support e.g iOS 10.0 browser (that breaks on async/await support currently).

I agree that it's not related to ky itself, but can be a nice help for the consumers of the package.

In our particular can we don't use babel (we use typescript), so I'm

node-fetch currently completely ignoring Content-Length header while consuming response.
Fetch specification about handling Content-Length on server response says almost nothing:
https://fetch.spec.whatwg.org/#concept-http-network-fetch (see whatwg/fetch#67)

On other hand, we have a fetch-node specific extension to limit the size of the response.

My prop

In our codebase, we push RequestContext and immediately run some code with try-with-resources.
For example:

try (SafeCloseable ignored = ctx.push()) {
    logger.trace(decorate(msg));
}

If RequestContext provides run(Runnable) or call(Callable) we can reduce boilerplate code and simplify it.

ctx.run(() -> logger.trace(decorate(msg));

This is inspired by g