sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: tour: automatic save of the last accessed tour page
Labels: NeedsInvestigation

I would like to suggest to add a new feature which is the automatic save of the last accessed tour page so the user could find himself again in the page that he left. I don't think newcomers will read all the everything in one shot.

Thx
Repository: TypeScript
Issue: Namespace elements cannot export without declaration
Labels: Suggestion,In Discussion

es6 modules can export module elements without declaration.

``` ts
import foo from 'foo';
export {foo}
```

Namespaces are not.

``` ts
import foo from 'foo';
namespace NS {
  export {foo} // not support syntax
  export var foo = foo; // invalid

  var bar = foo;
  export var foo = bar; // too redundant
}
```

Namespaces should support non-declaration export.

related: https://github.com/Microsoft/TypeScript/issues/5175
Repository: nvm
Issue: .bash_profile vs. .bashrc
Labels: installing nvm: profile detection,pull request wanted

On Mac OS X the `.bash_profile` is loaded by default, but the `.bashrc` file is not. When installing NVM it will write to the `.bashrc` file if it exists, but then won't be accessible at the command line. 

Adding `source ~/.bashrc` to the end of the `.bash_profile` makes the commands available but seems a bit awkward.  

Moving 

``` sh
export NVM_DIR="/Users/greg/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"  # This loads nvm
```

to the `.bash_profile` works too, and seems a more sensible way to go.

I'm thinking installing NVM should write to the `.bash_profile` over the `.bashrc` if both exist. At least I think that would play nicer with Mac OS X

Note: tried this on both OS X 10.10 & 10.11
Repository: TypeScript
Issue: Proposal: The internal modifier for classes
Labels: Suggestion,In Discussion

# The `internal` modifier

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 the
`internal` modifier to class members.
## Goals

This proposal aims to describe the static semantics of the `internal` modifier as it applies to members of a class (methods, accessors, and properties).
## Non-goals

This proposal does not cover any other use of the `internal` modifier on other declarations.
# Static Semantics
## Visibility

Within a _non-declaration_ file, a class member marked `internal` is treated as if it had `public`
visibility for any property access:

**source.ts**:

``` ts
class C {
    internal x: number;
}

let c = new C();
c.x = 1; // ok
```

When consuming a class from a _declaration_ file, a class member marked `internal` is treated as
if it had `private` visibility for any property access:

**declaration.d.ts**

``` ts
class C {
    internal x: number;
}
```

**source.ts**

``` ts
/// <reference path="declaration.d.ts" />
let c = new C();
c.x = 1; // error
```
## Assignability

When checking assignability of types within a _non-declaration_ file, a class member marked
`internal` is treated as if it had `public` visibility:

**source.ts**:

``` ts
class C {
    internal x: number;
}

interface X {
    x: number;
}

let x: X = new C(); // ok
```

If one of the types is imported or referenced from a _declaration_ file, but the other is defined
inside of a _non-declaration_ file, a class member marked `internal` is treated as if it had
`private` visibility:

**declaration.d.ts**

``` ts
class C {
    internal x: number;
}
```

**source.ts**

``` ts
/// <reference path="declaration.d.ts" />
interface X {
}

let x: X = new C(); // error
```

It is important to allow assignability between super- and subclasses from a declaration file
with overridden members marked `internal`. When both types are imported or referenced from a
_declaration_ file, a class member marked `internal` is treated as if it had `protected` visibility:

**declaration.d.ts**

``` ts
class C {
    internal x(): void;
}

class D extends C {
    internal x(): void;
}
```

**source.ts**

``` ts
/// <reference path="declaration.d.ts" />
let c: C = new D(); // ok
```

However, this does not carry over to subclasses that are defined in a _non-declaration_ file:

**declaration.d.ts**

``` ts
class C {
    internal x(): void;
}
```

**source.ts**

``` ts
/// <reference path="declaration.d.ts" />
class D extends C {
    internal x(): void; // error
}
```
Repository: youtube-dl
Issue: [archive.org] Add support for collections
Labels: request

```
css80@allied80 /cygdrive/c/Users/css80/Desktop
$ ./youtube-dl.exe --verbose https://archive.org/details/attentionkmartshoppers
[debug] System config: []
[debug] User config: []
[debug] Command-line args: [u'--verbose', u'https://archive.org/details/attentionkmartshoppers']
[debug] Encodings: locale cp1252, fs mbcs, out None, pref cp1252
[debug] youtube-dl version 2015.10.12
[debug] Python version 2.7.8 - Windows-8-6.2.9200
[debug] exe versions: ffmpeg N-75841-g5911eeb, ffprobe N-75841-g5911eeb
[debug] Proxy map: {}
[archive.org] attentionkmartshoppers: Downloading JSON metadata
ERROR: attentionkmartshoppers: Failed to parse JSON  (caused by ValueError('No JSON object could be decoded',)); please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
  File "youtube_dl\extractor\common.pyo", line 483, in _parse_json
  File "json\__init__.pyo", line 338, in loads
  File "json\decoder.pyo", line 366, in decode
  File "json\decoder.pyo", line 384, in raw_decode
ValueError: No JSON object could be decoded
Traceback (most recent call last):
  File "youtube_dl\YoutubeDL.pyo", line 660, in extract_info
  File "youtube_dl\extractor\common.pyo", line 290, in extract
  File "youtube_dl\extractor\archiveorg.pyo", line 37, in _real_extract
  File "youtube_dl\extractor\common.pyo", line 477, in _download_json
  File "youtube_dl\extractor\common.pyo", line 487, in _parse_json
ExtractorError: attentionkmartshoppers: Failed to parse JSON  (caused by ValueError('No JSON object could be decoded',)); please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

```
Repository: kubernetes
Issue: Label selector design doc
Labels: priority/backlog,kind/documentation,area/api,help wanted,sig/architecture,lifecycle/frozen

Capture design discussion from #15350, #341, #951, other PRs, and internal docs.
Repository: go
Issue: time: Parse too greedy when parsing some formats
Labels: NeedsDecision

1. What version of Go are you using (`go version`)?
   
   `$ go version go version devel +2d823fd Tue Oct 13 01:04:42 2015 +0000 linux/amd64`
2. What operating system and processor architecture are you using?
   
   linux/amd64
3. What did you do?
   
   Attempted to parse this time: `"618 AM MDT TUE OCT 13 2015"` with this format string: `"304 PM MST Mon Jan 02 2006`"
4. What did you expect to see?
   
   No parsing error, and a time.Time representing that moment.
5. What did you see instead?
   
   The parsing fails, and the error reported: `parsing time "618 AM MDT TUE OCT 13 2015": hour out of range`.  The hour is interpreted as `61`.
   
   The format works properly with a two digit hour.  It seems `getnum()` in time/format.go takes up to two characters whenever the second character is valid which leads to the issue.
6. Playground example with examples that fail and pass for the given format:
   
   http://play.golang.org/p/mZ-m7gJlvy

Apologies if my code is messy...

The format is used as a time/version stamp for the US National Weather Service in their forecast discussion products, for a real world example, http://www.wrh.noaa.gov/total_forecast/getprod.php?wfo=boi&pil=AFD&sid=BOI&version=1

Thank you.
Repository: rust
Issue: Can't import super
Labels: A-resolve,T-lang,C-bug

I'm not sure if this falls into the realm of something needing an RFC or not, but I expected this to work:

``` rust
mod a {
    use super as foo;
}
```

but it gives `error: expected identifier, found keyword `super``.

If I do it in an import list I get a different error:

``` rust
mod a {
    use super::{self as foo};
}
```

`error: unresolved import `super`. There is no `super` in `???``

(I suppose this also applies to `self`, but I can't think of a reason to do that.)

Edit: This seems to work as a substitute:

``` rust
mod a {
    mod foo { pub use super::super::*; }
}
```
Repository: go
Issue: x/mobile/cmd/gomobile: CGO_CFLAGS is overwritten during go bind -target=ios
Labels: mobile

hi, 
I faced an issue when I run gomobile bind with CGO_CFLAGS and CGO_LDFLAGS like

```
CGO_CFLAGS="-I/usr/local/include" \
CGO_LDFLAGS="-L/usr/local/lib" gomobile build -target=ios -v
```

but output told me that there a header file not found.
It turns out when we build ios, the CGO_CFLAGS and CGO_LDFLAGS are overwritten.
https://github.com/golang/mobile/blob/master/cmd/gomobile/env.go#L132

I have a way to workaround this:

```
index 5458bc2..00cb78c 100644
--- a/cmd/gomobile/env.go
+++ b/cmd/gomobile/env.go
@@ -119,8 +119,8 @@ func envInit() (err error) {
                "GOARM=7",
                "CC=" + clang,
                "CXX=" + clang,
-               "CGO_CFLAGS=" + cflags + " -arch " + archClang("arm"),
-               "CGO_LDFLAGS=" + cflags + " -arch " + archClang("arm"),
+               "CGO_CFLAGS=" + os.Getenv("CGO_CFLAGS") + " " + cflags + " -arch " + archClang("arm"),
+               "CGO_LDFLAGS=" + os.Getenv("CGO_LDFLAGS") + " " + cflags + " -arch " + archClang("arm"),
                "CGO_ENABLED=1",
        }
        darwinArm64Env = []string{
@@ -128,8 +128,8 @@ func envInit() (err error) {
                "GOARCH=arm64",
                "CC=" + clang,
                "CXX=" + clang,
-               "CGO_CFLAGS=" + cflags + " -arch " + archClang("arm64"),
-               "CGO_LDFLAGS=" + cflags + " -arch " + archClang("arm64"),
+               "CGO_CFLAGS=" + os.Getenv("CGO_CFLAGS") + " " + cflags + " -arch " + archClang("arm64"),
+               "CGO_LDFLAGS=" + os.Getenv("CGO_LDFLAGS") + " " + cflags + " -arch " + archClang("arm64"),
                "CGO_ENABLED=1",
        }

@@ -142,8 +142,8 @@ func envInit() (err error) {
                "GOARCH=386",
                "CC=" + clang,
                "CXX=" + clang,
-               "CGO_CFLAGS=" + cflags + " -mios-simulator-version-min=6.1 -arch " + archClang("386"),
-               "CGO_LDFLAGS=" + cflags + " -mios-simulator-version-min=6.1 -arch " + archClang("386"),
+               "CGO_CFLAGS=" + os.Getenv("CGO_CFLAGS") + " " + cflags + " -mios-simulator-version-min=6.1 -arch " + archClang("386"),
+               "CGO_LDFLAGS=" + os.Getenv("CGO_LDFLAGS") + " " + cflags + " -mios-simulator-version-min=6.1 -arch " + archClang("386"),
                "CGO_ENABLED=1",
        }
        darwinAmd64Env = []string{

```

let me know if you think this is an issue.
Repository: go
Issue: cmd/link: DWARF line tables seem to be off by 1 instruction
Labels: compiler/runtime

go version go1.5.1 darwin/amd64

I was noticing that values printed in the debugger often seem to be uninitialized when stepping past a line that initializes them. It appears that the DWARF line tables are advancing the line number one instruction too early. For example, with this go code

``` go
23 func main() {
24  lf, err := os.OpenFile("test", os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666)
25  if err != nil {
26      log.Fatalf("error opening file: %v", err)
27  }
28 ....
```

dwarfdump shows this for the line table:

```
0x000063e4: DW_LNE_set_address( 0x0000000004002e90 )
0x000063ef: DW_LNS_advance_line( 22 )
0x000063f1: address += 0,  line += 0
            0x0000000004002e90      1     23      0 is_stmt

0x000063f2: DW_LNS_advance_pc( 100 )
0x000063f4: address += 0,  line += 1
            0x0000000004002ef4      1     24      0 is_stmt

0x000063f5: DW_LNS_advance_pc( 70 )
0x000063f7: address += 0,  line += 1
            0x0000000004002f3a      1     25      0 is_stmt
```

It shows line 25 starting at 0x4002f3a. However, from the disassembly this appears to be the last instruction of line 24. Line 25 starts at 0x4002f42:

``` assembly
test`main.main:
    0x4002e90 <+0>:    movq   %gs:0x8a0, %rcx
    0x4002e99 <+9>:    leaq   -0x160(%rsp), %rax
    0x4002ea1 <+17>:   cmpq   0x10(%rcx), %rax
    0x4002ea5 <+21>:   jbe    0x4003d32                 ; <+3746> at test.go:23
    0x4002eab <+27>:   subq   $0x1e0, %rsp
    0x4002eb2 <+34>:   xorl   %eax, %eax
    0x4002eb4 <+36>:   movq   %rax, 0x1c0(%rsp)
    0x4002ebc <+44>:   movq   %rax, 0x1c8(%rsp)
    0x4002ec4 <+52>:   movq   %rax, 0x1d0(%rsp)
    0x4002ecc <+60>:   movq   %rax, 0x1d8(%rsp)
    0x4002ed4 <+68>:   movq   %rax, 0x170(%rsp)
    0x4002edc <+76>:   movq   %rax, 0x178(%rsp)
    0x4002ee4 <+84>:   movq   %rax, 0x130(%rsp)
    0x4002eec <+92>:   movq   %rax, 0x138(%rsp)
    0x4002ef4 <+100>:  leaq   0x3b6865(%rip), %rbx      ; go.string.* + 93856
    0x4002efb <+107>:  movq   %rbx, (%rsp)
    0x4002eff <+111>:  movq   $0xb, 0x8(%rsp)
    0x4002f08 <+120>:  movq   $0x20a, 0x10(%rsp)
    0x4002f11 <+129>:  movl   $0x1b6, 0x18(%rsp)
    0x4002f19 <+137>:  callq  0x40b8cb0                 ; os.OpenFile at file_unix.go:85
    0x4002f1e <+142>:  movq   0x20(%rsp), %rbx
    0x4002f23 <+147>:  movq   %rbx, 0x70(%rsp)
    0x4002f28 <+152>:  movq   0x28(%rsp), %rcx
    0x4002f2d <+157>:  movq   0x30(%rsp), %rdx
    0x4002f32 <+162>:  movq   %rdx, 0xe8(%rsp)
->  0x4002f3a <+170>:  movq   %rcx, 0xe0(%rsp)
    0x4002f42 <+178>:  cmpq   $0x0, %rcx
```
Repository: kubernetes
Issue: Write resource management overview
Labels: priority/backlog,sig/scheduling,area/isolation,sig/node,kind/feature,lifecycle/frozen,needs-triage

We need an overall design for how all our resource-management features should interact:
- horizontal pod autoscaling
- vertical pod autoscaling (initial and reactive)
- resource metrics APIs
- oversubscription
- scheduling (including taking resource usage into account)
- QoS
- out-of-resource killing
- rescheduling

cc @davidopp @fgrzadkowski @dchen1107 @vishh @derekwaynecarr
Repository: rust
Issue: Higher-ranked lifetime bounds give confusing errors
Labels: C-enhancement,A-diagnostics,A-lifetimes,T-compiler,A-higher-ranked

``` rust
#![allow(dead_code)]

fn x(_: &()) {}

trait HR {}
impl HR for fn(&()) {}
fn hr<T: HR>(_: T) {}

trait NotHR {}
impl<'a> NotHR for fn(&'a ()) {}
fn not_hr<T: NotHR>(_: T) {}

fn a<'a>() {
    let not_hr_func: fn(&'a ()) = x;
    let hr_func: fn(&()) = x;
    let hr_func2: for<'b> fn(&'b ()) = x;
    hr(not_hr_func);
    not_hr(hr_func);
    not_hr(hr_func2);
}

fn main() {}
```

gives

```
<anon>:17:5: 17:7 error: the trait `HR` is not implemented for the type `fn(&())` [E0277]
<anon>:17     hr(not_hr_func);
              ^~
<anon>:17:5: 17:7 help: see the detailed explanation for E0277
<anon>:17:5: 17:7 note: required by `hr`
<anon>:18:5: 18:11 error: the trait `NotHR` is not implemented for the type `fn(&())` [E0277]
<anon>:18     not_hr(hr_func);
              ^~~~~~
<anon>:18:5: 18:11 help: see the detailed explanation for E0277
<anon>:18:5: 18:11 note: required by `not_hr`
<anon>:19:5: 19:11 error: the trait `NotHR` is not implemented for the type `fn(&'b ())` [E0277]
<anon>:19     not_hr(hr_func2);
              ^~~~~~
<anon>:19:5: 19:11 help: see the detailed explanation for E0277
<anon>:19:5: 19:11 note: required by `not_hr`
error: aborting due to 3 previous errors
playpen: application terminated with error code 101
```

Summarizing, given the type declaration, we have the printed form:

| Declaration | Display |
| --- | --- |
| `fn(&'a ())` | `fn(&())` |
| `fn(&())` | `fn(&())` |
| `for<'b> fn(&'b ())` | `fn(&'b ())` |

So the non-higher-ranked type has its lifetime elided and is printed like a higher-ranked type, and higher-ranked types are sometimes printed without the quantifier but with the lifetime, looking like non-higher-ranked types.
Repository: go
Issue: spec: document that Alignof, Offsetof, and Sizeof do not evaluate their arguments
Labels: Documentation,NeedsInvestigation

At least in cmd/compile, unsafe.Alignof, unsafe.Offsetof, and unsafe.Sizeof do not evaluate their arguments: http://play.golang.org/p/4QE3mVrFaS

Although unsurprising and consistent with C/C++, the Go spec doesn't mention this.  It does say

> Calls to Alignof, Offsetof, and Sizeof are compile-time constant expressions of type uintptr.

but I don't think that's necessarily mutually exclusive with evaluating the argument expression.
Repository: go
Issue: spec: ambiguity in definition of alignment
Labels: Documentation,NeedsInvestigation

The spec (September 24, 2015) says:

> The following minimal alignment properties are guaranteed:
> 1. For a variable x of any type: unsafe.Alignof(x) is at least 1.
> 2. For a variable x of struct type: unsafe.Alignof(x) is the largest of all the values unsafe.Alignof(x.f) for each field f of x, but at least 1.
> 3. For a variable x of array type: unsafe.Alignof(x) is the same as unsafe.Alignof(x[0]), but at least 1.

While intuitive, this definition doesn't address structs with blank fields (because there's no valid x.f expression to access those fields) or zero-element arrays (because x[0] is an illegal expression, as 0 is a constant that's out of the array's bounds).

It seems like these can be addressed by changing the wording to something like:
1. The alignment of any type is at least 1.
2. The alignment of a struct type is at least as large as the alignment of each of its fields.
3. The alignment of an array type is the same as the alignment of its element type.

(The original definition repeats the "but at least 1" wording each time, but that seems redundant since nothing else indicates that rule 1 is mutually exclusive with rules 2 and 3.)
Repository: neovim
Issue: Uses `set_a_foreground` and `set_a_background` for invalid colour indexes
Labels: tui

I'm trying to debug a problem a user has relating to terminal rendering, and I'm looking over a `script` log of neovim's output. One thing that initially troubles me is there are places in the log where it sends

```
SGR 310
SGR 312
SGR 314
```

These aren't known to `libvterm`, nor can I find reference to them in any terminal docs I have to hand.

Looking more closely at the places they appear, it seems they're intended as colour formatting; e.g.

```
{ESC (B}{SGR *}{SGR 36}{SGR 48}0
{ESC (B}{SGR *}{SGR 312}{SGR 48}]
```

A careful reading of the `set_a_foreground` terminfo entry reveals a likely candidate:

```
set_a_foreground=\E[3%p1%dm
```

The parameter gets printed verbatim, as if in a call to

```
printf("\e[3%dm", param);
```

at which point we can surmise that these are coming from `set_a_foreground` called with a parameter value of 10, 12 or 14.

This is outside the range that should be allowed, because the terminfo starts by declaring

```
max_colors#8
```

It is important that `set_a_foreground` and `set_a_background` are not invoked with a number outside the range allowed by `max_colors`, or weird things may result.
Repository: go
Issue: runtime: merge .go files produced by cgo into their counterparts
Labels: compiler/runtime

Merge 
- `panic1.go` -> `panic.go`
- `defs1_darwin.go` + `defs2_darwin.go` -> `defs_darwin.go`
- etc

Discussed in https://groups.google.com/forum/#!topic/golang-nuts/yuh2fzooEpM

I'd like to work on this.
Repository: neovim
Issue: Vim may leave file named "4913" under certain conditions
Labels: bug-vim,filesystem

An interesting case was [mentioned](https://twitter.com/cortesi/status/654769811914780673): Neo/Vim (~~on Windows only?~~) [creates a temporary file](https://github.com/neovim/neovim/blob/536c0ba27e79929eb30850d8e11f2ed026930ab3/src/nvim/fileio.c#L2710) to check if a directory is writable and see the resulting ACL. 

> So, if you’re writing software that watches for file changes, you’ll find **Vim [creates and deletes file 4913](https://github.com/b4winckler/vim/blob/1f611c1f921bc219b44272f13a298cd8d97aa6f0/src/fileio.c#L3704) on almost every edit**. [ref](https://twitter.com/cortesi/status/654770457141350400)

vim_dev thread (2009): https://groups.google.com/d/msg/vim_dev/sppdpElxY44/v9fOtS1ji-cJ

```
3508 /* Close the file before removing it, on MS-Windows we
3509  * can't delete an open file. */
3510  close(fd);
3511  mch_remove(IObuff);
```

> There's a race condition between lines 3510 and 3511, wherein another process could open a handle to the file and thus prevent the delete from succeeding.  One class of software that is known to do this and cause problems is antivirus programs, which want to scan things for viruses as soon as they are created.  Another class of software that sometimes causes problems is local search programs, which want to index things as soon as they are created.  Such software can do their tasks unobtrusively if they are written carefully and using the mechanisms provided by the operating system, namely oplocks.  Unfortunately there are lots of bad virus scanners and indexers out there (lots of bad software in general!).
> 
> One solution which is very commonly used in Windows programs is to detect when a delete or rename operation fails (can be narrowed to specific error codes -- sharing violation and access denied), and retry a couple times with short delays in between.  The idea is to give the interfering process some time to finish whatever work it was doing with the file. ...  How many people out there have tried to delete a large hierarchy of files using "rd /s /q", and had it inexplicably fail to delete a few files?  Yet if you repeat the command it will generally succeed.  Most likely a virus scanner or search indexer got in the way and is now out of the way.
> 
> Another solution, which is cleaner but can only be used in cases where you know you want to delete a file immediately after closing its handle, is to **set the delete disposition on the file before closing the handle.**  There are a couple of ways using Windows APIs to do this.  One way is to pass FILE_FLAG_DELETE_ON_CLOSE to CreateFile() when opening the handle originally.  Another way is to send down a FileDispositionInfo using SetFileInformationByHandle() or equivalent.  (Essentially the DeleteFile() API just does the following: open a handle, set delete disposition, and close the handle; if we break apart these steps, we gain finer control.)
Repository: TypeScript
Issue: Formatting multiple-line comment doesn't normalize leading whitespaces
Labels: Bug,Help Wanted

``` typescript
function foo() {
    /*
        multiple line comment
    */
}
```

Formatter does not change `\t` character before `/*` into spaces. Is this also by design?