sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: runtime: cgo stuck because of go signal handler went into dead loop if pid=1
Labels: NeedsDecision,compiler/runtime

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.19 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
Sure


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/root/go/pkg/mod"
GONOPROXY=
GONOSUMDB=
GOOS="linux"
GOPATH="/root/go"
GOPRIVATE=
GOPROXY="https://goproxy.cn,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.19"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2188387714=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on go.dev/play is best.
-->
The bug found in go1.10.3 at first, the I update go to go1.19, it happends too. I find the root case lives here: https://github.com/golang/go/blob/de475e8a66b0f530e074c68031a364ad2ebe2a95/src/runtime/signal_unix.go#L964

In almost all real cases the program is about to crash, but in my situation, it does not after `usleep`. But why, I cannot explain!!!.

Then I try fix it myself with the following patch:
```go
	raise(sig)
	// Give the signal a chance to be delivered.
	// In almost all real cases the program is about to crash,
	// so sleeping here is not a waste of time.
	usleep(1000)

	switch sig {
	case _SIGSEGV, _SIGABRT, _SIGFPE, _SIGILL, _SIGBUS:
		print("fatal error: unexpected signal during runtime execution\n")
		signame := signame(sig)
		if signame != "" {
			print("[signal ", signame)
		} else {
			print("[signal ", hex(sig))
		}
		print(" code=", hex(c.sigcode()), " addr=", hex(c.sigaddr()), "]\n")
		dieFromSignal(sig)

	default:
		// If the signal didn't cause the program to exit, restore the
		// Go signal handler and carry on.
		//
		// We may receive another instance of the signal before we
		// restore the Go handler, but that is not so bad: we know
		// that the Go program has been ignoring the signal.
		setsig(sig, abi.FuncPCABIInternal(sighandler))
	}
```


### What did you expect to see?
panic



### What did you see instead?
See #56649
Repository: yt-dlp
Issue: List of related videos
Labels: site-enhancement,triage

### 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](https://github.com/yt-dlp/yt-dlp#readme)
- [X] I've verified that I'm running yt-dlp version **2023.03.04** ([update instructions](https://github.com/yt-dlp/yt-dlp#update)) or later (specify commit)
- [X] I've searched [known issues](https://github.com/yt-dlp/yt-dlp/issues/3766) and the [bugtracker](https://github.com/yt-dlp/yt-dlp/issues?q=) for similar questions **including closed ones**. DO NOT post duplicates
- [X] I've read the [guidelines for opening an issue](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#opening-an-issue)

### Please make sure the question is worded well enough to be understood

Hello! Is there at the moment a possibility to get a list of related videos for a given video without downloading anything?

Thanks!

### 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

```shell
[debug] Command-line config: ['-vU']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version stable@2023.03.04 [392389b7d] (pip)
[debug] Python 3.9.2 (CPython x86_64 64bit) - Linux-5.10.0-21-amd64-x86_64-with-glibc2.31 (OpenSSL 1.1.1n  15 Mar 2022, glibc 2.31)
[debug] exe versions: ffmpeg 4.3.5-0, ffprobe 4.3.5-0, phantomjs broken, rtmpdump 2.4
[debug] Optional libraries: Cryptodome-3.9.7, brotli-1.0.9, certifi-2020.06.20, mutagen-1.45.1, pyxattr-0.7.2, sqlite3-2.6.0, websockets-10.3
[debug] Proxy map: {}
[debug] Extractor Plugins: KodicIE, porndeadIE
[debug] Loaded 1788 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Available version: stable@2023.03.04, Current version: stable@2023.03.04
yt-dlp is up to date (stable@2023.03.04)
```
Repository: angular
Issue: Allow injection tokens to be provided in the same way as services
Labels: feature,area: core,core: di,feature: under consideration

### Which @angular/* package(s) are relevant/related to the feature request?

core

### Description

Unlike services, injection tokens cannot be provided at the component/route level without using `useFactory/Value/Class`.

```ts
const BAR_TOKEN = new InjectionToken('Bar', {
  factory() {
    const foo = inject(FooService);
    return foo.bar;
  }
});
```

The `BAR_TOKEN` will be provided at the root level even if we don't use `providedIn: 'root'`. If we want to provide `BAR_TOKEN` at the component level, it cannot be provided in the following way:

```ts
@Component({
  providers: [BAR_TOKEN], // this will not work even if we defined `factory` for the `BAR_TOKEN`
})
export class BarComponent {}
```

To make it work, we need to explicitly specify its factory, although we have already defined `factory` in the `BAR_TOKEN` definition:

```ts
@Component({
  providers: [{ provide: BAR_TOKEN, useFactory: () => inject(FooService).bar }],
})
export class BarComponent {}
```


### Proposed solution

Unlike tokens, with services, we need to add `@Injectable({ providedIn: 'root' })` to provide them at the root level. I'd like to have the same behavior with injection tokens:

```ts
const BAR_TOKEN_1 = new InjectionToken('Bar', {
  providedIn: 'root',
  factory() {
    const foo = inject(FooService);
    return foo.bar;
  }
}); // BAR_TOKEN_1 is provided at the root level (no changes in this case)

const BAR_TOKEN_2 = new InjectionToken('Bar', {
  factory() {
    const foo = inject(FooService);
    return foo.bar;
  }
});

// BAR_TOKEN_2 is not provided anywhere by default,
// similar to `@Injectable()` that doesn't contain `{ providedIn: root }` config.
// However, `InjectionToken` with a factory can be provided in the following way:

@Component({
  providers: [BAR_TOKEN_2]
})
export class BarComponent {}
```
 

### Alternatives considered

We can use `inject...` functions instead of injection tokens:

```ts
export function injectBar() {
  const foo = inject(FooService);
  return foo.bar;
}
```

However, by using this approach, the `inject...` function body will be executed every time when it's invoked. On the other hand, if we are able to use injection tokens in the way that is described in the previous section, the injection token factory will be executed only the first time when it's injected.
Repository: godot
Issue: writeAsciiToMemory method encountered assert error when exported as html5
Labels: bug,platform:web,topic:porting

### Godot version

4.0.2

### System information

Windows11

### Issue description

```
index.js:790 
 Uncaught RuntimeError: Aborted(Assertion failed)
    at abort (index.js:790:10)
    at assert (index.js:407:3)
    at writeAsciiToMemory (index.js:8148:3)
    at index.js:8160:3
    at Array.forEach (<anonymous>)
    at _environ_get (index.js:8157:18)
    at __emscripten_environ_constructor (0bb02a0a:0x18f22b3)
    at __wasm_call_ctors (0bb02a0a:0x5a572)
    at callRuntimeCallbacks (index.js:3878:20)
    at initRuntime (index.js:641:2)


index.js:790 
 Uncaught (in promise) RuntimeError: Aborted(Assertion failed)
    at abort (index.js:790:10)
    at assert (index.js:407:3)
    at writeAsciiToMemory (index.js:8148:3)
    at index.js:8160:3
    at Array.forEach (<anonymous>)
    at _environ_get (index.js:8157:18)
    at __emscripten_environ_constructor (0bb02a0a:0x18f22b3)
    at __wasm_call_ctors (0bb02a0a:0x5a572)
    at callRuntimeCallbacks (index.js:3878:20)
    at initRuntime (index.js:641:2)
```

### Steps to reproduce

1. Exported project as h5:
```
......
index.html
index.wasm
......
```
2. Throw these files to nginx
3. Add 'Cross-Origin' settings
4. Start nginx
5. Open URL in Edge(112.0.1722.39)
6. Browser console show error
```

index.js:790 
 Uncaught RuntimeError: Aborted(Assertion failed)
    at abort (index.js:790:10)
    at assert (index.js:407:3)
    at writeAsciiToMemory (index.js:8148:3)
    at index.js:8160:3
    at Array.forEach (<anonymous>)
    at _environ_get (index.js:8157:18)
    at __emscripten_environ_constructor (0bb02a0a:0x18f22b3)
    at __wasm_call_ctors (0bb02a0a:0x5a572)
    at callRuntimeCallbacks (index.js:3878:20)
    at initRuntime (index.js:641:2)


index.js:790 
 Uncaught (in promise) RuntimeError: Aborted(Assertion failed)
    at abort (index.js:790:10)
    at assert (index.js:407:3)
    at writeAsciiToMemory (index.js:8148:3)
    at index.js:8160:3
    at Array.forEach (<anonymous>)
    at _environ_get (index.js:8157:18)
    at __emscripten_environ_constructor (0bb02a0a:0x18f22b3)
    at __wasm_call_ctors (0bb02a0a:0x5a572)
    at callRuntimeCallbacks (index.js:3878:20)
    at initRuntime (index.js:641:2)
```


### Minimal reproduction project

[godot-2d-demo.zip](https://github.com/godotengine/godot/files/11211191/godot-2d-demo.zip)
Repository: deno
Issue: Error running example of 'deno task dev'
Labels: bug,needs investigation,node compat,dx

My config (MX Linux 21.3):
```
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye

$ deno --version
deno 1.32.3 (release, x86_64-unknown-linux-gnu)
v8 11.2.214.9
typescript 5.0.3

$ node --version
v18.15.0

$ npm --version
9.5.0
```

Trying to follow the tutorial here:
[https://www.youtube.com/watch?v=MDPauM8fZDE](https://www.youtube.com/watch?v=MDPauM8fZDE)
[https://github.com/denoland/examples/tree/main/with-vue](https://github.com/denoland/examples/tree/main/with-vue)

```
$ deno run -A npm:create-vite-extra
✔ Project name: … myProject
✔ Select a template: › deno-vue
✔ Select a variant: › TypeScript

Scaffolding project in /myProject...

Done. Now run:

  cd myProject
  deno task dev

$ cd myProject
$ deno task dev
```

I get the error:
```
Task dev deno run -A --node-modules-dir npm:vite
failed to load config from /myProject/vite.config.mts
error when starting dev server:
TypeError: Cannot read properties of null (reading 'on')
    at ensureServiceIsRunning (file:///myProject/node_modules/.deno/esbuild@0.17.16/node_modules/esbuild/lib/main.js:2137:15)
    at build (file:///myProject/node_modules/.deno/esbuild@0.17.16/node_modules/esbuild/lib/main.js:2011:26)
    at bundleConfigFile (file:///myProject/node_modules/.deno/vite@4.2.1/node_modules/vite/dist/node/chunks/dep-79892de8.js:63875:26)
    at loadConfigFromFile (file:///myProject/node_modules/.deno/vite@4.2.1/node_modules/vite/dist/node/chunks/dep-79892de8.js:63851:31)
    at resolveConfig (file:///myProject/node_modules/.deno/vite@4.2.1/node_modules/vite/dist/node/chunks/dep-79892de8.js:63466:34)
    at createServer (file:///myProject/node_modules/.deno/vite@4.2.1/node_modules/vite/dist/node/chunks/dep-79892de8.js:62752:26)
    at CAC.<anonymous> (file:///myProject/node_modules/.deno/vite@4.2.1/node_modules/vite/dist/node/cli.js:734:30)
```

My 'deno.json' file:
```
{
  "tasks": {
    "dev": "deno run -A --node-modules-dir npm:vite",
    "build": "deno run -A --node-modules-dir npm:vite build",
    "preview": "deno run -A --node-modules-dir npm:vite preview",
    "serve": "deno run --allow-net --allow-read https://deno.land/std@0.157.0/http/file_server.ts dist/"
  }
}
```

My 'vite.config.mts' file:
```
import { defineConfig } from 'npm:vite@^4.0.4'
import vue from 'npm:@vitejs/plugin-vue@^4.0.0'

import 'npm:vue@^3.2.45'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [vue()],
})
```

My 'src/main.ts' file
```
import { createApp } from 'vue'
import './style.css'
import App from './App.vue'

createApp(App).mount('#app')
```

I didn't change anything in those 3 files. They were generated by Deno.

I suppose there is a version issue somewhere, but I've already searched Google (and even tried ChatGPT) for hours, and can't figure out what is causing the issue.
Repository: react
Issue: Bug: MessageChannel in Scheduler prevents Jest test from exiting
Labels: Status: Unconfirmed

React version: any
Scheduler version: any up to current (0.23.0)

## Steps To Reproduce

1. Create Jest unit test.
2. Select JSDom as test environment so that runtime will not have `setImmediate` function.
3. JSDom still does not implement `MessageChannel` https://github.com/jsdom/jsdom/issues/2448. If `MessageChannel` is required to test some important functionality, one can add an implementation from Node.js as recommended in comment https://github.com/jsdom/jsdom/issues/2448#issuecomment-536242756
    ```js
    window.MessageChannel = require('node:worker_threads').MessageChannel;
    ```
4. Add Scheduler or React as a dependency and require it in the test or one of the files under test.
5. Run test

Link to code example: https://github.com/victor-homyakov/scheduler-jest-jsdom-example

## The current behavior

Test is endless. Jest won't stop. Console shows a message
```
Jest did not exit one second after the test run has completed.

'This usually means that there are asynchronous operations that weren't stopped in your tests. Consider running Jest with `--detectOpenHandles` to troubleshoot this issue.
```

Running Jest with `--detectOpenHandles` outputs:

```
Jest has detected the following 1 open handle potentially keeping Jest from exiting:

  ●  MESSAGEPORT

    > 1 | require('scheduler');
        |                     ^

      at node_modules/scheduler/cjs/scheduler.development.js:569:17
```

## The expected behavior

Code at https://github.com/facebook/react/blob/5426af3d50ff706f3ebeb4764f838e0a3812bf9a/packages/scheduler/src/forks/Scheduler.js#L621 should `unref` the handle:

```js
  channel.port1.onmessage = performWorkUntilDeadline;
  // Allow the thread to exit if this is the only active handle in the event system
  if (channel.port1.unref) {
    channel.port1.unref();
  }
```
Repository: PowerToys
Issue: Run: Prioritize contiguous matches over characters appearing split up
Labels: Issue-Bug,Product-PowerToys Run,Needs-Triage

### Microsoft PowerToys version

0.68.1

### Installation method

GitHub

### Running as admin

No

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

Make a PowerToys Run search with a search term that appears contiguously in a rarely used application's name as well as another result where singular characters happen to show up with other characters in-between.

![image](https://user-images.githubusercontent.com/53344902/231468535-2e909a0c-25ab-4013-a546-9bdd6269498a.png)

Currently, it seems the only factor on what appears first in Run is the frequency at which it is selected and quality of the match is not taken into account in any way. This may often result in nonsensical prioritization in Run's suggestions. Attached screenshot shows a perfect example: Since I've frequently used run to hibernate my PC, searching for "inte" will show "H**i**ber**n**a**te**" above "**Inte**llij", "**Inte**l" and "**inte**rnal", all of which would be far more reasonable results. It's helpful that the search is fuzzy and can find results even when badly mistyped, but it still shouldn't raise extremely unlikely results above better ones, no matter how often they get picked. 

This happens with "Results order tuning" on or off. In fact, I've had it turned off all this time and the results still reflect frequency at which I've picked them in the past over more sensible choices.

It's incredibly unlikely that an user writing "ham" would be looking for "t**h**ing**am**abob" over "hammer", and this should reflect in the results Run returns.

### ✔️ Expected Behavior

A contiguous match of the search term should always appear before a result where the search terms appears split up since the latter often happens purely by chance.

### ❌ Actual Behavior

Only previous selections affect priority of results, even in cases where it makes little sense, even if results order tuning is turned off.

### Other Software

_No response_
Repository: godot
Issue: New CPUparticles2D emitters stop working after a while
Labels: topic:rendering,needs testing,topic:particles

### Godot version

v4.0.2.stable.official [7a0977ce2]

### System information

Windows 10, Geforce GTX 1660, NForward+

### Issue description

In my game I noticed particles are not emitted at all sometimes, so I managed to make the smallest as possible proof of concept to demonstrate the issue and eventually find a solution.
(I've found similar issues here where at the end the issue could not be demonstrated.)

Looks like a high explosiveness value causes the issue, even for new spawn particle emitters.

### Steps to reproduce

At every _process call a previously preloaded  scene consisting of a Sprite2D and a GPUParticle2D is spawned.
The sprite is used just to see where the particles should spawn.
This "fx" scene is removed when the emitter is not emitting anymore

After few seconds, the sprites along the emitters area still visible, but the emitters stop working.
After few more seconds, some random emitter works as it should, most of them do not.

Looks like I've reaches some limit, but 63 emitters does not seem much.

If you edit the explosiveness down to about 0.7-0.8 (in fx3.tscn), it starts behaving almost normally.

### Minimal reproduction project

[Test.zip](https://github.com/godotengine/godot/files/11212234/Test.zip)
Repository: pytorch
Issue: TracingContext.get().frame_summary_stack doesn't produce full stack trace
Labels: low priority,triaged,module: dynamo

### 🐛 Describe the bug

If you are here because an error message, comment on the issue to describe how you were affected, so we can help prioritize this issue.

TracingContext.get().frame_summary_stack doesn't report full backtraces; you'll only get frames from inside the region of code that dynamo traced through. In principle, we could also collect the regular backtrace from before callback entry and report that too.

@Chillee notes that it is good not to give too much information, and indeed the stack trace before calling into the model is probably not that useful. But if we have graph breaks inside the model, we may have lost useful context. Maybe only want the partial stack trace up to torch.compile? Not going to do it unless someone shouts.

### Versions

master

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @chauhang @aakhundov @soumith @anijain2305 @Xia-Weiwen @desertfire
Repository: flutter
Issue: Re-Enable FlutterEngineTest.CanOverrideBackgroundColor once deflaked
Labels: a: desktop,P2,c: flake,team-macos,triaged-macos

Step 17 from https://ci.chromium.org/ui/p/flutter/builders/try/Mac%20Engine%20Drone/158661/overview
```
[ RUN      ] FlutterEngineTest.CanOverrideBackgroundColor
../../flutter/shell/platform/darwin/macos/framework/Source/FlutterEngineTest.mm:173: Failure
Value of: rootLayer.backgroundColor != nullptr
  Actual: false
Expected: true
[  FAILED  ] FlutterEngineTest.CanOverrideBackgroundColor (24 ms)
```

https://github.com/flutter/engine/blob/main/shell/platform/darwin/macos/framework/Source/FlutterEngineTest.mm#L173

This is occasionally causing rolls to fail.

cc @cbracken for triage
Repository: storybook
Issue: [Bug]: Resetting scroll position on save on story larger than viewport height
Labels: bug,ui

### Describe the bug

If you save a story which has a height greater than the viewport height after you have scrolled, the scroll position is not persisted between saves and therefore makes developing tall stories a pain.

### To Reproduce

https://stackblitz.com/edit/github-zgj9ea-opneuf?file=stories%2FPage.tsx&preset=node

(page story, editing + saving resets the scroll position)

### System

```shell
Environment Info:

  System:
    OS: Linux 5.0 undefined
    CPU: (2) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
  Binaries:
    Node: 16.14.2 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 7.17.0 - /usr/local/bin/npm
  npmPackages:
    @storybook/addon-essentials: ^7.1.0-alpha.1 => 7.1.0-alpha.2 
    @storybook/addon-interactions: ^7.1.0-alpha.1 => 7.1.0-alpha.2 
    @storybook/addon-links: ^7.1.0-alpha.1 => 7.1.0-alpha.2 
    @storybook/blocks: ^7.1.0-alpha.1 => 7.1.0-alpha.2 
    @storybook/nextjs: ^7.1.0-alpha.1 => 7.1.0-alpha.2 
    @storybook/react: ^7.1.0-alpha.1 => 7.1.0-alpha.2 
    @storybook/testing-library: ^0.0.14-next.2 => 0.0.14-next.2
```


### Additional context

N/A
Repository: pytorch
Issue: torch.dist with minus norm returns tensor(0.), while with -inf can return result
Labels: module: distributions,triaged

### 🐛 Describe the bug

# with minus norm
```
import torch
arg_1_tensor = torch.rand([4], dtype=torch.float32)
arg_1 = arg_1_tensor.clone()
print(arg_1)
arg_2_tensor = torch.rand([4], dtype=torch.float32)
arg_2 = arg_2_tensor.clone()
print(arg_2)
arg_3 = -100
res = torch.dist(input=arg_1,other=arg_2,p=arg_3,)
print(res)
```
```
tensor([0.3692, 0.1006, 0.4169, 0.5297])
tensor([0.4667, 0.3731, 0.2566, 0.8941])
tensor(0.)
```

# with -inf norm
```
import torch
inf = float('inf')
arg_1_tensor = torch.rand([4], dtype=torch.float32)
arg_1 = arg_1_tensor.clone()
print(arg_1)
arg_2_tensor = torch.rand([4], dtype=torch.float32)
arg_2 = arg_2_tensor.clone()
print(arg_2)
arg_3 = -inf
res = torch.dist(input=arg_1,other=arg_2,p=arg_3,)
print(res)
```
```
tensor([0.2863, 0.5415, 0.4990, 0.6137])
tensor([0.1516, 0.4867, 0.1853, 0.8488])
tensor(0.0548)
```

I find this happens when norm is less than -40.

### Versions

pytorch version: 2.0.0
cuda : 118

cc @fritzo @neerajprad @alicanb @nikitaved
Repository: flutter
Issue: Design an implement a CLI to simplify local development with engine v2 build configs
Labels: team-infra,P3,triaged-infra

Some of the initial potential features:

- [ ] List available builds
- [ ] List sub-builds of a build
- [ ] Build an engine v2 locally
- [ ] Build all or part of the subbuilds locally
- [ ] Replicate a remote build environment locally, e.g. download deps, download sub-builds outputs, etc