sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: youtube-dl
Issue: Twitter mobile links Unsupported error
Labels: request

Twitter mobile links are not downloading.
**Youtube-dl version:**
`2016.03.18
`

**Mobile Link Format**
[https://mobile.twitter.com/HananPak/media/grid?idx=0&tid=701050373990174724](https://mobile.twitter.com/HananPak/media/grid?idx=0&tid=701050373990174724)

**Output**

```
My prompt>./youtube-dl --verbose https://mobile.twitter.com/HananPak/media/grid?idx=0&tid=701050373990174724
[1] 19973
My prompt>[debug] System config: []
[debug] User config: []
[debug] Command-line args: [u'--verbose', u'https://mobile.twitter.com/HananPak/media/grid?idx=0']
[debug] Encodings: locale ISO-8859-1, fs ISO-8859-1, out ISO-8859-1, pref ISO-8859-1
[debug] youtube-dl version 2016.03.18
[debug] Python version 2.7.9 - Linux-3.16.0-4-amd64-x86_64-with-debian-8.1
[debug] exe versions: avconv 11.4-6, avprobe 11.4-6, rtmpdump 2.4
[debug] Proxy map: {}
[generic] grid?idx=0: Requesting header
WARNING: Falling back on generic information extractor.
[generic] grid?idx=0: Downloading webpage
[generic] grid?idx=0: Extracting information
ERROR: Unsupported URL: https://mobile.twitter.com/HananPak/media/grid?idx=0
Traceback (most recent call last):
  File "./youtube-dl/youtube_dl/extractor/generic.py", line 1314, in _real_extract
    doc = compat_etree_fromstring(webpage.encode('utf-8'))
  File "./youtube-dl/youtube_dl/compat.py", line 253, in compat_etree_fromstring
    doc = _XML(text, parser=etree.XMLParser(target=etree.TreeBuilder(element_factory=_element_factory)))
  File "./youtube-dl/youtube_dl/compat.py", line 242, in _XML
    parser.feed(text)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1642, in feed
    self._raiseerror(v)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1506, in _raiseerror
    raise err
ParseError: unbound prefix: line 1, column 2479
Traceback (most recent call last):
  File "./youtube-dl/youtube_dl/YoutubeDL.py", line 668, in extract_info
    ie_result = ie.extract(url)
  File "./youtube-dl/youtube_dl/extractor/common.py", line 320, in extract
    return self._real_extract(url)
  File "./youtube-dl/youtube_dl/extractor/generic.py", line 1961, in _real_extract
    raise UnsupportedError(url)
UnsupportedError: Unsupported URL: https://mobile.twitter.com/HananPak/media/grid?idx=0
```
Repository: kubernetes
Issue: Increase maximum pods per node
Labels: sig/scalability,sig/node,kind/feature,lifecycle/frozen,triage/accepted

As discussed on the sig-node call on March 22:

max-pods on kube-1.1 was 40, kube-1.2 is 110 pods per node.

We have use-cases expressed by customers for increased node vertical scalability.  This is (generally) for environments using fewer larger capacity nodes and perhaps running lighter-weight pods.

For kube-1.3 we would like to discuss targeting a 100 node cluster running 500 pods per node.  This will require coordination with @kubernetes/sig-scalability as it would increase the total pods-per-cluster.

/cc @kubernetes/sig-node @kubernetes/sig-scalability @dchen1107 @timothysc @derekwaynecarr @ncdc @smarterclayton @pmorie 

Thoughts?
Repository: go
Issue: cmd/cgo: godefs doesn't work nicely with multiple input files
Labels: compiler/runtime

It would be nice if the output of the command `cgo -godefs` with multiple input files resulted in a legal source file. Currently it duplicates the package declaration (and the generated comments) rendering the output useless without post-processing (since all the output goes straight to stdout):

```
$ cat a.go
package ex

/*
typedef int a;
*/
import "C"

type Atype C.a
```

```
$ cat b.go
package ex

/*
typedef int b;
*/
import "C"

type Btype C.b
```

```
$ go tool cgo -godefs a.go b.go
// Created by cgo -godefs - DO NOT EDIT
// cgo -godefs a.go b.go

package ex

type Atype int32
// Created by cgo -godefs - DO NOT EDIT
// cgo -godefs a.go b.go

package ex

type Btype int32
```

It would be nice if the output were instead:

```
$ go tool cgo -godefs a.go b.go
// Created by cgo -godefs - DO NOT EDIT
// cgo -godefs a.go b.go

package ex

type Atype int32

type Btype int32
```

This would be useful in situations where `cgo -godefs` requires extra/different information on different platforms. It is generally fairly easy to workaround though and the lack of this feature in previous versions of go might limit its usefulness.
Repository: go
Issue: runtime, cmd/compile: consider write barrier short-circuit when *dst == src
Labels: Performance,compiler/runtime

I did a quick and dirty instrumentation of `writebarrierptr` and found that when executing `cmd/compile` to build std, about 25% of calls on average had `*dst == src`. In that case, there's no need to do the actual assignment or gray any objects (I think). I don't know how (a)typical that 25% number is.

We should investigate whether checking for this and short-circuiting is a net performance gain, in general. There are multiple places in the stack this could occur:

(1) writebarrierptr (and friends)

Add

``` go
if *dst == src {
  return
}
```

to the beginning of the method.

(2) Wrapper routines

Add checks like:

``` go
if dst[1] != src[1] {
    writebarrierptr(&dst[1], src[1])
}
```

to the runtime routines that call `writebarrierptr`, like the wbfat.go routines, and `writebarrierstring` and friends. This is different than (1) insofar as it skips the `writebarrierptr` function call instead of having it return immediately.

(3) Generated code

We currently generate wb-calling code like:

``` go
if writeBarrier.enabled {
  writebarrierptr(dst, src)
} else {
  *dst = src
}
```

We could instead generate code like:

``` go
if *dst != src {
  if writeBarrier.enabled {
    writebarrierptr(dst, src)
  } else {
    *dst = src
  }
}
```

cc @aclements @randall77 

I don't plan to work on this soon, as I need to undistract myself.
Repository: You-Dont-Know-JS
Issue: "this & obj prototypes " - ch 4 : Suggestion. comments in code snippets to improve clarity
Labels: for second edition

Even though we have a sentence 

> Consider this loose pseudo-code (invented syntax) for inherited classes:

ahead of the code snippets showing pseudo-code. As I read along, I was thinking this probably is JS. may be ES6. And I read along, until i hit the mixins part. 

I felt that may be adding a comment in the top of pseudo code block ex. `//This is not JS. This is pseudo code.` might help a reader
Repository: rust
Issue: GDB hangs when debugging exe compiled with 1.9nightly under Windows
Labels: O-windows-gnu,C-bug

When I debugging this [](https://play.rust-lang.org/?gist=f8afbd583d102fc2f55f&version=nightly), the gdb hanged. Later I found whenever the GDB stepping out a function, it hangs.
![qq 20160323171401](https://cloud.githubusercontent.com/assets/2211542/13980936/23e04710-f11c-11e5-9da9-e1d0867492f4.png)

The mininum code to reproduce the issue is listed below
`
fn b()->i32{
    return 0;
}
fn a(){
    b();
}
fn main() {
    a();
}
`

![qq 20160323171942](https://cloud.githubusercontent.com/assets/2211542/13980978/540554c6-f11c-11e5-9fa0-2d7e9146c463.png)
Repository: react
Issue: Consider Special Casing Certain DOM Attributes to Accept Elements
Labels: Type: Feature Request,Component: DOM,React Core Team

The use case is for example, translation components rendering string content.

The HTML spec has some unfortunate attributes that behave kind of like content. It seems like they should be able to accept React elements. If I were to design a similar React component I would allow it to accept React elements.

Since we normalize usage we could in theory have it built-in to React that certain attributes like `placeholder`, `aria-label`, etc. could accept React components that render into strings.

That would probably have to go in after we figure out a way to render strings at the root of a React composite component.
Repository: rust
Issue: Tracking issue for integer methods for Wrapping
Labels: T-libs-api,B-unstable,C-tracking-issue,Libs-Tracked,Libs-Small

`u32` and other primitive integer types implement a number of bit-manipulation methods like `rotate_left`, but `Wrapping<_>` does not. At the moment this can be worked around with code like `Wrapping(x.0.rotate_left(n))` instead of `x.rotate_left(n)`.

It would be nice to implement:
- [x] `count_ones`
- [x] `count_zeroes`
- [x] `leading_zeroes`
- [x] `trailing_zeroes`
- [x] `rotate_left`
- [x] `rotate_right`
- [x] `swap_bytes`
- [x] `from_be` (?)
- [x] `from_le` (?)
- [x] `to_be`
- [x] `to_le`
- [x] `pow` (?)

Edit: Others added after https://github.com/rust-lang/rust/issues/32463#issuecomment-376663775
- [x] `is_power_of_two` (?)
- [x] `next_power_of_two` (?)
- [x] `min_value` (?)
- [x] `max_value` (?)
- [x] `from_str_radix` (?)
- [x] `reverse_bits`
- [x] `abs` ~~https://github.com/rust-lang/rust/pull/49393~~ https://github.com/rust-lang/rust/pull/50465
- [x] `signum` ~~https://github.com/rust-lang/rust/pull/49393~~ https://github.com/rust-lang/rust/pull/50465
- [x] `is_positive` ~~https://github.com/rust-lang/rust/pull/49393~~ https://github.com/rust-lang/rust/pull/50465
- [x] `is_negative` ~~https://github.com/rust-lang/rust/pull/49393~~ https://github.com/rust-lang/rust/pull/50465

and maybe other methods, for:
- `Wrapping<u8>`
- `Wrapping<u16>`
- `Wrapping<u32>`
- `Wrapping<u64>`
- `Wrapping<usize>`
- `Wrapping<i8>`
- `Wrapping<i16>`
- `Wrapping<i32>`
- `Wrapping<i64>`
- `Wrapping<isize>`

Edit: From https://github.com/rust-lang/rust/pull/50465
- [ ] Decide on correct behavior for `wrapping_next_power_of_two`
Repository: opencv
Issue: write/read of (at least) feature detector/descriptor extractor don't seem to work properly in the latest version 3.x
Labels: feature,category: features2d

### Information of the system
- OpenCV version: 3.1 (latest commit e792ee89dec696e22a0bef15f84fe13368326497)
- Host OS: Linux (Ubuntu 14.04)
- Compiler: GCC 4.8.2
### Part of the OpenCV library in which the issue appears.
- feature detector/descriptor extractor

Possibly other classes from `cv::Algorithm` are affected?
### Expected behavior
1. When the `write` function is called from a feature detector/descriptor extractor class, passing a `FileStorage`, a yaml/xml file should be created containing the value of the parameters.
2. When the `read` function is called from a feature detector/descriptor extractor class, it should change the values of the parameters of the algorithm.
### Actual behaviour
1. An empty file is written, with just the header of the yaml file (in case a yaml file is created).
2. The parameters do not change.
### Additional information

Note that I tried on OpenCV 2.4 (the latest version of the repository 762965897ac7ee08f14a52a398185b02ae522c5c) and it works.
### Code example to reproduce 1.

```
#include "opencv2/opencv.hpp"
#include "opencv2/features2d.hpp"
#include "opencv2/xfeatures2d.hpp"
#include "opencv2/xfeatures2d/nonfree.hpp"


int main()
{
  cv::Ptr<cv::ORB> feature_detector = cv::ORB::create();
  cv::FileStorage fs("params.yml", cv::FileStorage::WRITE);
  feature_detector->write(fs);
}
```
### Code example to reproduce 2.

```
#include "opencv2/opencv.hpp"
#include "opencv2/features2d.hpp"
#include "opencv2/xfeatures2d.hpp"
#include "opencv2/xfeatures2d/nonfree.hpp"


int main()
{
  cv::Ptr<cv::ORB> feature_detector = cv::ORB::create();
  cv::FileStorage fs("params.yml", cv::FileStorage::READ);
  feature_detector->write(fs.root());
}
```
Repository: youtube-dl
Issue: Naver tvcast : authentication issue
Labels: request

youtube-dl -v http://tvcast.naver.com/v/656759
[debug] System config: []
[debug] User config: []
[debug] Command-line args: [u'-v', u'http://tvcast.naver.com/v/656759']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2016.03.18
[debug] Python version 2.7.10 - Darwin-15.4.0-x86_64-i386-64bit
[debug] exe versions: none
[debug] Proxy map: {}
[Naver] 656759: Downloading webpage
ERROR: 19세 미만 청소년은 감상하실 수 없는 동영상으로
로그인 후 이용이 가능합니다.
Traceback (most recent call last):
  File "/usr/local/bin/youtube-dl/youtube_dl/YoutubeDL.py", line 668, in extract_info
    ie_result = ie.extract(url)
  File "/usr/local/bin/youtube-dl/youtube_dl/extractor/common.py", line 320, in extract
    return self._real_extract(url)
  File "/usr/local/bin/youtube-dl/youtube_dl/extractor/naver.py", line 52, in _real_extract
    raise ExtractorError(error, expected=True)
ExtractorError: 19\uc138 \ubbf8\ub9cc \uccad\uc18c\ub144\uc740 \uac10\uc0c1\ud558\uc2e4 \uc218 \uc5c6\ub294 \ub3d9\uc601\uc0c1\uc73c\ub85c
\ub85c\uadf8\uc778 \ud6c4 \uc774\uc6a9\uc774 \uac00\ub2a5\ud569\ub2c8\ub2e4.

19세 미만 청소년은 감상하실 수 없는 동영상으로
로그인 후 이용이 가능합니다. => Youth under the age of 19 will not be available after you log in to watch video.
Repository: rust
Issue: Specialization: allow some projection when typechecking an impl
Labels: A-trait-system,T-compiler,A-specialization,C-bug,requires-nightly,F-associated_type_defaults

The following example currently fails to compile:

``` rust
pub trait Foo {
    type TypeA;
    type TypeB: Bar<Self::TypeA>;
}

pub trait Bar<T> {
}

pub struct ImplsBar;
impl<T> Bar<T> for ImplsBar {
}

impl<T> Foo for T {
    type TypeA = u8;
    default type TypeB = ImplsBar;
}
```

with message:

```
<anon>:15:9: 15:12 error: the trait `Bar<u8>` is not implemented for the type `<T as Foo>::TypeB` [E0277]
<anon>:15 impl<T> Foo for T {
```

The problem seems to be that the type checker is using a projection of `TypeB` to actually check the impl's definition of `TypeB` against its bounds. But because it's marked `default`, the item cannot be projected.

In general, we should loosen up the rules on projections when checking an impl -- but doing so soundly is tricky. It clearly doesn't work to just allow _all_ projections to go through (a la "trans mode"), because in general items could be replaced in more specialized impls. But it _does_ seem reasonable to allow projecting _the current item being impled_ (for any trait ref covered by the impl), because any specialization of that item will be rechecked under its own constraints.
Repository: nvm
Issue: nvm_cheksum not found
Labels: shell: zsh,OS: Mac OS,needs followup,installing node: checksums

I cannot install anything with nvm via Binary. The checksum is always not found and it goes to installing from source.

``` shell
$ nvm install iojs
Downloading https://iojs.org/dist/v3.3.1/iojs-v3.3.1-darwin-x64.tar.gz...
######################################################################## 100.0%
nvm_checksum:2: = not found
Binary download failed, trying source.
Binary download failed, trying source.
Installing iojs from source is not currently supported
```

``` shell
nvm install node
Downloading https://nodejs.org/dist/v5.9.1/node-v5.9.1-darwin-x64.tar.gz...
######################################################################## 100.0%
nvm_checksum:2: = not found
Binary download failed, trying source.
Binary download failed, trying source.
######################################################################## 100.0%
Checksums empty
Now using node v5.9.1 (npm v3.7.3)
Creating default alias: default -> node (-> v5.9.1)
```

I am on OSX 10.11.4. Used brew install nvm. Running commands in ZSH.

Any idea what is causing this?
Repository: TypeScript
Issue: Proposal: Friend Declarations for classes
Labels: Suggestion,Awaiting More Feedback

_NOTE: This proposal is an alternative to the proposal in #5228._
## Overview

Often there is a need to share information on types within a program or package that should not be
accessed from outside of the program or package. While the `public` accessibility modifier allows
types to share information, is insufficient for this case as consumers of the package have access
to the information. While the `private` accessibility modifier prevents consumers of the package
from accessing information from the type, it is insufficient for this case as types within the
package also cannot access the information. To satisfy this case, we propose the addition of a _FriendDeclaration_ to classes:

``` ts
class A {
  friend createA;
  private constructor() { }
}

function createA() {
  return new A();
}
```

A _FriendDeclaration_ is a new declaration supported in the body of a _ClassDeclaration_ or _ClassExpression_ that indicates that the class, function, or namespace to which the supplied name resolves can treat the `private` and `protected` members of the class as if they were public.

The name referenced in the _FriendDeclaration_ is resolved relative to the _ClassDeclaration_. The name must be in scope.
## Grammar

&emsp;&emsp;_ClassElement:_  _( Modified )_
&emsp;&emsp;&emsp;_FriendDeclaration_

&emsp;&emsp;_FriendDeclaration:_
&emsp;&emsp;&emsp;`friend`&emsp;_FriendDeclarationNames_&emsp;`;`

&emsp;&emsp;_FriendDeclarationNames:_
&emsp;&emsp;&emsp;_EntityName_
&emsp;&emsp;&emsp;_FriendDeclarationNames_&emsp;`,`&emsp;_EntityName_
## Examples

**Instantiate a class with a private constructor:**

``` ts
class A {
  friend createA;
  private constructor() { }
}

function createA() {
  return new A();
}
```

**Extend a class with a private constructor:**

``` ts
class A {
  friend B;
  private constructor() { }
}

class B extends A {
}
```

**Access private members of an imported class:**

``` ts
// a.ts
import { update } from "./b";
export class A {
  friend update;
  private x: number;
}

// b.ts
import { A } from "./a";
export function update(a: A) {
  a.x = 1;
}
```
Repository: rust
Issue: Support death tests in libtest
Labels: T-libs-api,A-libtest,C-feature-accepted,T-testing-devex

I would like to be able to mark a test as a death test of some kind, like, running this code should trigger an `abort` (instead of just an unwind), an `exit` with a particular exit code, or an `assert` (in case `assert` doesn't unwind if, e.g. `panic=abort`).

This requires two fundamental ingredients, libtests needs to support:
- spawning test in different processes (that is, process spawning/setup and teardown)
- marking tests as death tests (and maybe indicate the type).

A way to mark a test as a _death test_ is important, since in the case in which `panic != abort` one still wants all the non death tests to happen within the same process for speed, but libtest stills need to spawn different processes for the _death tests_ only (so it needs a way to tell these apart).

For crates in which `panic == abort`, it would be nice if one could turn all tests into _death tests_ at the crate level. 

This issue is tangentially related to: https://github.com/rust-lang/rfcs/pull/1513

Google Test is probably the most famous unit-testing framework that supports these although in C++ other frameworks do as well. It usually takes 3k LOC C++ code to implement a "portable" process spawning/set up/tear down mechanism for spawning death tests, so it is quite a bit of machinery that might better belong outside of rustc.
Repository: nvm
Issue: `nvm_tree_contains_path` doesn't work on case-insensitive filesystems
Labels: bugs,OS: Mac OS,pull request wanted

Specifically, this can happen on a Mac, when the username isn't all lowercase (see https://github.com/creationix/nvm/issues/855#issuecomment-201570439).
Repository: go
Issue: runtime: hot vars and cache lines
Labels: NeedsInvestigation,compiler/runtime

Naive question. The runtime has a bunch of top-level vars, some of which are fairly hot, e.g. the writeBarrier struct (checked before every write barrier call), the debug struct (checked during every malloc for e.g. allocfreetrace), and the trace struct (to know whether tracing is enabled). Some are written a lot (writeBarrier), whereas others are read-mostly (debug, trace).

They are organized for readability and thus end up potentially scattered around the final binary. However, I wonder whether it would be better to ensure that all the hottest read-mostly variables are in a single cache line and ensure that the hottest read-write variables don't trigger false sharing.

Many of these aren't easy to move around and experiment with, because of compiler integration. So first: Any instincts about whether this is likely to matter in practice?

cc @dvyukov @aclements
Repository: go
Issue: net/http: mechanism to dynamically change MaxIdleConnsPerHost?
Labels: FeatureRequest

Please answer these questions before submitting your issue. Thanks!
- What version of Go are you using (`go version`)?

```
1.6
```
- What operating system and processor architecture are you using (`go env`)?

```
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/hernan/apps/go"
GORACE=""
GOROOT="/Users/hernan/apps/go/go-src/go"
GOTOOLDIR="/Users/hernan/apps/go/go-src/go/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/vw/ht0lksb16l199rbp98p7hhfr0000gn/T/go-build001484838=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
```
- What did you do?

It is not possible for clients of `http.Transport` to dynamically change MaxIdleConnsPerHost attribute. It would be great to have a `sync.RWMutex` as an attribute of `http.Transport`, so this is possible.

The use case is that for HTTP/1.1 Hosts, it would be nice for the client to have the possibility of adjusting max-idle connections base on usage.

The following gist shows the problem:
https://gist.github.com/go-loco/810fe53d8aee8879b8d1

Making the following changes to http.Transport would add this feature:

```
    // MaxIdleConnsPerHost, if non-zero, controls the maximum idle
    // (keep-alive) connections to keep per-host. If zero,
    // DefaultMaxIdleConnsPerHost is used.
    MaxIdleConnsPerHost int

    // MaxIdleConnsMutex, let you dynamically change the
    // MaxIdleConnsPerHost without creating a data race.
    //
    // Usage:
    //
    //  MaxIdleConnsMutex.Lock()
    //  MaxIdleConnsPerHost = newValue
    //  MaxIdleConnsMutex.Unlock()
    //
    MaxIdleConnsMutex sync.RWMutex
```

```
func (t *Transport) tryPutIdleConn(pconn *persistConn) error {

    t.MaxIdleConnsMutex.RLock()
    max := t.MaxIdleConnsPerHost
    t.MaxIdleConnsMutex.RUnlock()

    if t.DisableKeepAlives || max < 0 {
        return errKeepAlivesDisabled
    }
    if pconn.isBroken() {
        return errConnBroken
    }
    key := pconn.cacheKey

    if max == 0 {
        max = DefaultMaxIdleConnsPerHost
    }
...
```
Repository: go
Issue: cmd/cgo: cgo does not link dependencies into archives
Labels: compiler/runtime

Please answer these questions before submitting your issue. Thanks!
- What version of Go are you using (`go version`)?

`go version go1.6 darwin/amd64`
- What operating system and processor architecture are you using (`go env`)?

```
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/tamird/src/go"
GORACE=""
GOROOT="/Users/tamird/src/go1.6"
GOTOOLDIR="/Users/tamird/src/go1.6/pkg/tool/darwin_amd64"
GO15VENDOREXPERIMENT="1"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"
CXX="clang++"
CGO_ENABLED="1"
```
- What did you do?

Compiling https://github.com/cockroachdb/c-rocksdb with the LDFLAGS directives at the bottom of https://github.com/cockroachdb/c-rocksdb/blob/master/cgo_flags.go removed.

c-rocksdb is a "thin" wrapper around https://github.com/facebook/rocksdb which allows it to be built using the go toolchain. However, it depends on lz4, so we bring in http://github.com/cockroachdb/c-lz4 which is a similar wrapper.

Unfortunately, c-lz4 is being linked (by cmd/link?) in a later step than the external linking used for c-rocksdb, which causes missing symbols in c-rocksdb (hence the need for the LDFLAGS directives).

Is it possible to ask the toolchain to link c-lz4.a using external linking (in the "main" linking step in c-rocksdb)?