sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: youtube-dl
Issue: Unsupported URL: http://www.funshion.com/vplay/m-56999/
Labels: site-support-request

When trying to access the above url, I got:

```
youtube-dl "http://www.funshion.com/vplay/m-56999/" --verbose
[debug] System config: []
[debug] User config: []
[debug] Command-line args: ['http://www.funshion.com/vplay/m-56999/', '--verbose']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2014.05.19
[debug] Python version 2.7.6 - Linux-3.13.0-24-generic-x86_64-with-Ubuntu-14.04-trusty
[debug] Proxy map: {}
[generic] m-56999: Requesting header
WARNING: Falling back on generic information extractor.
[generic] m-56999: Downloading webpage
[generic] m-56999: Extracting information
ERROR: Unsupported URL: http://www.funshion.com/vplay/m-56999/; please report this issue on https://yt-dl.org/bug . Be sure to call youtube-dl with the --verbose flag and include its complete output. Make sure you are using the latest version; type  youtube-dl -U  to update.
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/youtube_dl/extractor/generic.py", line 418, in _real_extract
    doc = parse_xml(webpage)
  File "/usr/local/lib/python2.7/dist-packages/youtube_dl/utils.py", line 1406, in parse_xml
    return xml.etree.ElementTree.XML(s.encode('utf-8'), **kwargs)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1300, 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: mismatched tag: line 45, column 2
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/youtube_dl/YoutubeDL.py", line 516, in extract_info
    ie_result = ie.extract(url)
  File "/usr/local/lib/python2.7/dist-packages/youtube_dl/extractor/common.py", line 163, in extract
    return self._real_extract(url)
  File "/usr/local/lib/python2.7/dist-packages/youtube_dl/extractor/generic.py", line 687, in _real_extract
    raise ExtractorError('Unsupported URL: %s' % url)
ExtractorError: Unsupported URL: http://www.funshion.com/vplay/m-56999/; please report this issue on https://yt-dl.org/bug . Be sure to call youtube-dl with the --verbose flag and include its complete output. Make sure you are using the latest version; type  youtube-dl -U  to update.
```

Thanks,
Repository: youtube-dl
Issue: Download YouTube playlists in order if the URL specifies a starting video
Labels: request

Example: https://www.youtube.com/watch?v=3Fz-X9dV2yc&list=PL0F37DF458A2AFFF8

This should start with 3Fz-X9dV2yc and loop around.
Repository: nvm
Issue: Run correct npm completion script
Labels: feature requests

I have the following line in my .bash_profile:

```
source ~/.nvm/v0.10.28/lib/node_modules/npm/lib/utils/completion.sh
```

That seems kind of fragile. Is there a better way, or could a better way be written?
Repository: rust
Issue: rustdoc: provide summary views
Labels: T-rustdoc,C-feature-request

When viewing a specific type, rustdoc currently spreads out information about the applicable methods, arranging them by trait and including documentation per method.

While this is an important view to have, it would often be very useful to see a single summary list of method signatures that apply to a given type. Something close to what you see currently when you view a trait.

These methods could be listed as a separate summary section, or through some kind of slide out (see the "synopsis" button at http://hackage.haskell.org/package/vector-0.10.9.2/docs/Data-Vector.html for example). They can be hyperlinks to more detailed documentation.
Repository: youtube-dl
Issue: Add an option to show just the progress.
Labels: request

At the moment, you can use `--quiet` to show no output, and you can use `--verbose` to show lots of output, but there are no options to show just the progress.
Repository: rust
Issue: replace the implementation of inline functions
Labels: I-slow,C-enhancement,A-codegen,I-compiletime,T-compiler,C-optimization

Rust's implementation of `#[inline]` functions is far from ideal. It's a major contributor to both slow compile times and bloated binaries.

There are an enormous number of `#[inline]` functions in the standard libraries, and most have far more than one layer of inner `#[inline]` function calls. The work to convert these functions to LLVM IR, optimize and translate to machine code is duplicated for every single crate. The `inline` pass is not used at `--opt-level=0` and `--opt-level=1`, so the result is wasted time and duplicated code without any benefits.

It is possible to implement `#[inline]` functions without duplicating the work of converting to LLVM IR and optimizing. The compiler can also _entirely_ avoid any duplicated function bodies when the optimization level is not high enough for `inline`, the function is used as a function pointer or it is above the threshold.

Before compiling all of the functions in a library crate, Rust should create an LLVM module with all of the externally reachable inline functions in the crate. It will run the optimization passes on this LLVM module before continuing to compile, and it end up stored as metadata in the `rlib` or dynamic library in the bytecode format.

The compiler will then continue on with the compilation of the _other_ functions in the crate. The work to generate optimized LLVM IR from the externally reachable `#[inline]` is already complete and can be reused. These functions will _not_ be marked internal, because other crates will be able to call through to these.

Now, when Rust is compiling another crate, it can start by fetching the LLVM bytecode for the required inline functions. These functions will be marked `available_externally` and use the original symbol from the source library, so that if inlining does not occur there will be _no duplicate code_. At `--opt-level=0` and `--opt-level=1`, it can simply generate an external call immediately and ignore the bytecode blob.

It would also be possible to leverage this for instantiations of generic functions, by making the instantiations already done by the library available externally as LLVM bytecode blobs in the metadata.
Repository: youtube-dl
Issue: Unable to extract from: http://www.frogtoon.com
Labels: site-support-request

youtube-dl --verbose http://www.frogtoon.com/Track/Horus/Peregrination+016+(February+2014)
[debug] System config: []
[debug] User config: []
[debug] Command-line args: ['--verbose', 'http://www.frogtoon.com/Track/Horus/Peregrination+016+(February+2014)']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2014.05.19
[debug] Python version 2.7.5 - Darwin-13.2.0-x86_64-i386-64bit
[debug] Proxy map: {}
[generic] Peregrination+016+(February+2014): Requesting header
WARNING: Falling back on generic information extractor.
[generic] Peregrination+016+(February+2014): Downloading webpage
[generic] Peregrination+016+(February+2014): Extracting information
ERROR: Unsupported URL: http://www.frogtoon.com/Track/Horus/Peregrination+016+(February+2014); please report this issue on https://yt-dl.org/bug . Be sure to call youtube-dl with the --verbose flag and include its complete output. Make sure you are using the latest version; type  youtube-dl -U  to update.
Traceback (most recent call last):
  File "/usr/local/bin/youtube-dl/youtube_dl/extractor/generic.py", line 418, in _real_extract
    doc = parse_xml(webpage)
  File "/usr/local/bin/youtube-dl/youtube_dl/utils.py", line 1406, in parse_xml
    return xml.etree.ElementTree.XML(s.encode('utf-8'), **kwargs)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 1300, in XML
    parser.feed(text)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 1642, in feed
    self._raiseerror(v)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 1506, in _raiseerror
    raise err
ParseError: not well-formed (invalid token): line 21, column 312
Traceback (most recent call last):
  File "/usr/local/bin/youtube-dl/youtube_dl/YoutubeDL.py", line 516, in extract_info
    ie_result = ie.extract(url)
  File "/usr/local/bin/youtube-dl/youtube_dl/extractor/common.py", line 163, in extract
    return self._real_extract(url)
  File "/usr/local/bin/youtube-dl/youtube_dl/extractor/generic.py", line 687, in _real_extract
    raise ExtractorError('Unsupported URL: %s' % url)
ExtractorError: Unsupported URL: http://www.frogtoon.com/Track/Horus/Peregrination+016+(February+2014); please report this issue on https://yt-dl.org/bug . Be sure to call youtube-dl with the --verbose flag and include its complete output. Make sure you are using the latest version; type  youtube-dl -U  to update.
Repository: neovim
Issue: Improve output messages
Labels: documentation,localization

While working on #780, I found that the output messages could be improved in some respects, e.g.:
-  Format string parameters (file names, variable names, ...) are sometimes at the end of a message ("Too many arguments for function: %s"), sometimes inline ("Argument of %s must be a List").
-  Format string parameters are sometimes put in quotes.
- Some messages are split into multiple parts, e.g. [message for E325](https://github.com/neovim/neovim/blob/master/src/nvim/memline.c#L3180). It's harder to translate such partial strings because some context is missing.
- For error messages, words are sometimes capitalized after colons ("E682: **I**nvalid ..." vs "E363: **p**attern ...")
- Minor wording differences, e.g. "cscope" is sometimes written "Cscope".
- All-caps messages, e.g. "(NFA) COULD NOT OPEN %s !"

Fixing such issues should be pretty easy if there's an agreement on a "message style". The big downside, however, is that changes in the messages would probably require manually updating all existing translations afterwards (although the old translations might be recognized as "fuzzy" translations). If it is possible to create an `en.po` "translation", this could be circumvented while still improving at least some messages.
Repository: You-Dont-Know-JS
Issue: "es6 & beyond": great proxy example
Labels: for second edition

https://mail.mozilla.org/pipermail/es-discuss/2014-June/037445.html
Repository: three.js
Issue: CSS based size by default?
Labels: Enhancement

I'm just curious but have you considered making CSS based sizing the default? If you did less code would have to change for various use cases

For example many samples do stuff like this

```
camera = new THREE.PerspectiveCamera( 
    50, window.innerWidth / window.innerHeight, 1, 1000 );
```

And or they set 

```
renderer.setSize( window.innerWidth, window.innerHeight );
```

But if instead you based the size of the canvas off its `clientWidth` and `clientHeight` then it would just always work. The user can make container and set it's CSS to any size. For example

```
<style>
html, body {
   width: 100%;
   height: 100%;
   margin: 0px;
   padding: 0px;
   overflow: hidden;  // make sure no scrollbar
}
#c {
   width: 100%;
   height: 100%;
}
</style>
<body>
  <canvas id="c"></canvas>
</body>
```

And it just works. If they change the canvas to be some specific size like

```
#c {
  width: 400px;
  height: 300px;
}
```

Then it still just works.

If they put the canvas inside some other containers  (say they are making an editor and there's a side tab) it all just works.  Whereas the way three is now you always have to go muck with the code for a different use cases.

You'd have to stop mucking with `style.width` and `style.height` inside three but as it is it seems like three is fighting the web platform instead of embracing it.

Thoughts?

To be clear see these samples. They all use exactly the same JavaScript (in fact they're all pointing to the same JavaScript file).  Because they use CSS and `clientWidth`, `clientHeight` nothing needs to change

Full size window with user created canvas
http://greggman.com/downloads/examples/three-by-css/three-by-css-01.html

80% size with user created canvas (size the window)
http://greggman.com/downloads/examples/three-by-css/three-by-css-02.html

Inline for article with user created canvas
http://greggman.com/downloads/examples/three-by-css/three-by-css-03.html

Full size window using container div where three.js makes the canvas
http://greggman.com/downloads/examples/three-by-css/three-by-css-by-container-01.html

80% size with using container div where three.js makes the canvas (size the window)
http://greggman.com/downloads/examples/three-by-css/three-by-css-by-container-02.html

Inline for article using container span where three.js makes the canvas
http://greggman.com/downloads/examples/three-by-css/three-by-css-by-container-03.html

No container div, uses the body, three.js creates the canvas
http://greggman.com/downloads/examples/three-by-css/three-by-css-body-only.html

This one is same as inline but uses `box-sizing: box-border;` which mean even though the container is set to 400px/300px the border is subtracted from the inside so the canvas needs to be 390/290 and again it just works because that's what `clientWidth` and `clientHeight` are.
http://greggman.com/downloads/examples/three-by-css/three-by-css-by-container-04.html
Repository: neovim
Issue: remove B0_FNAME_SIZE_CRYPT
Labels: refactor

based on original vim source, seems B0_FNAME_SIZE_CRYPT and B0_FNAME_SIZE_NOCRYPT were for encryption, which was removed.  Investigate if these are needed now. Maybe @schmee can look into it?
Repository: youtube-dl
Issue: Request to show xMiB instead of percentage downloaded
Labels: request

This is a feature request to show:
[download]  36.4MiB of 333MiB @...
as alternative to:
[download]  20.5% of 213MiB @...
Repository: youtube-dl
Issue: request: Per service configuration
Labels: request

I love having the option to configure youtube-dl globaly, but it would be great to be able to specify options per service, so like one directory for YouTube, another for SoundCloud and another for Twitch.  
I would presume it should look something like this:  

```
[all]
--no-part

[youtube]
-o "%(uploader)s\%(title)s.%(ext)s"

[youtube:playlists]
-o "%(uploader)s\%(playlist)s\%(title)s.%(ext)s"
--ignore-errors

[soundcloud]
--audio-format m4a

[udemy]
--username MyUsername
--password MyPassword

[twitch]
--username MyUsername
--password MyPassword
```

I hope you get the basic gist.  
Thank you :)
Repository: rust
Issue: Better temporary lifetimes (tracking issue for RFC 66)
Labels: A-lifetimes,B-RFC-approved,T-lang,T-compiler,C-tracking-issue,S-tracking-design-concerns

Tracking issue for rust-lang/rfcs#66: better temporary lifetimes.

Some unresolved questions to be settled when implementing:
1. This implies that the lifetimes of temporaries is not known until after typeck. I think this is ok but it is a phase change which can sometimes be tricky (currently temporary lifetimes are known before typeck).
2. We have to specify the precise rules over when a temporary is extended. There are various subtle cases to be considered:
- Clearly we must consider whether the parameter type is a reference with a lifetime that also appears in the return type. Does the variance in the return type matter? (I think: no, too subtle and not worth it.)
- When do we decide what the type of the parameter is? Do we consider the _declared type_, the _type after inference_, or a hybrid?

Some examples where this matters:

```
fn identity<T>(x: T) -> T { x }

// Are these the same or different?

foo(&3);
foo::<&int>(&3);
```

My take: Probably we should just consider the fully inferred type.

### Unresolved questions

* [ ] Resolve the concern about semantic changes described in [comment](https://github.com/rust-lang/rust/issues/15023#issuecomment-635464546).
Repository: youtube-dl
Issue: Unsupported URL: http://www.fifa.com/worldcup/videos/highlights/match=300186483/index.html
Labels: site-support-request
Repository: react
Issue: Support asynchronous server rendering (waiting for data before rendering)
Labels: Type: Feature Request,Component: Server Rendering,Component: Component API,Resolution: Backlog

It would seriously ease the process of building something isomorphic if componentWillMount could return a promise and that react would delay rendering until that promise is resolved. I have seen attempt of doing something like that in react-router and rrouter, however giving this responsibility to each component instead of a router module would make more sense for me.
Repository: youtube-dl
Issue: Add support for ligonier.org (was: ERROR: Unsupported URL:)
Labels: site-support-request

Here is the verbose output:

~$ youtube-dl --verbose http://www.ligonier.org/rym/broadcasts/video/why-god-man-june-2014/
[debug] System config: []
[debug] User config: []
[debug] Command-line args: ['--verbose', 'http://www.ligonier.org/rym/broadcasts/video/why-god-man-june-2014/']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2014.06.24.1
[debug] Python version 2.7.6 - Linux-3.13.0-29-generic-x86_64-with-Ubuntu-14.04-trusty
[debug] Proxy map: {}
[generic] why-god-man-june-2014: Requesting header
WARNING: Falling back on generic information extractor.
[generic] why-god-man-june-2014: Downloading webpage
[generic] why-god-man-june-2014: Extracting information
ERROR: Unsupported URL: http://www.ligonier.org/rym/broadcasts/video/why-god-man-june-2014/; please report this issue on https://yt-dl.org/bug . Be sure to call youtube-dl with the --verbose flag and include its complete output. Make sure you are using the latest version; type  youtube-dl -U  to update.
Traceback (most recent call last):
  File "/usr/local/bin/youtube-dl/youtube_dl/extractor/generic.py", line 451, in _real_extract
    doc = parse_xml(webpage)
  File "/usr/local/bin/youtube-dl/youtube_dl/utils.py", line 1406, in parse_xml
    return xml.etree.ElementTree.XML(s.encode('utf-8'), **kwargs)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1300, 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: mismatched tag: line 196, column 2
Traceback (most recent call last):
  File "/usr/local/bin/youtube-dl/youtube_dl/YoutubeDL.py", line 516, in extract_info
    ie_result = ie.extract(url)
  File "/usr/local/bin/youtube-dl/youtube_dl/extractor/common.py", line 167, in extract
    return self._real_extract(url)
  File "/usr/local/bin/youtube-dl/youtube_dl/extractor/generic.py", line 741, in _real_extract
    raise ExtractorError('Unsupported URL: %s' % url)
ExtractorError: Unsupported URL: http://www.ligonier.org/rym/broadcasts/video/why-god-man-june-2014/; please report this issue on https://yt-dl.org/bug . Be sure to call youtube-dl with the --verbose flag and include its complete output. Make sure you are using the latest version; type  youtube-dl -U  to update.
Repository: youtube-dl
Issue: Veehd - downloads don't work for long videos
Labels: broken-IE

Hi

Veehd downloads do not work for long videos. 

Throws error of '**Unable to extract config json**'

It seems that a "link expired" page is served instead of the desired player page with the <object>.

The proper page is only served after sending a POST request which I believe creates a cookie.

I do not have the technical ability to implement this but below is a detailed analysis.

---

Two sample videos:
short -> http://veehd.com/video/4686958
long -> http://veehd.com/video/1901703

When visit the respective player pages:
short -> view-source:[link to short vid player](http://veehd.com/vpi?h=NDY4Njk1OHw0ODB8ODQ4LjM1fGZsYXNofDF8MTgtMjExfDE0MDM1NDc4ODF8OTV8MXxhZGY4ODNmZmMxNWNlMDRmZjQ1N2UyMzI4Mjc3YTQxYg==&nsfw=0&do=s&s=95.34&vt=VGltZSBMYXBzZSBWaWV3IGZyb20gU3BhY2UgKCBJU1Mp)
long -> view-source:[link to long vid player](http://veehd.com/vpi?h=MTkwMTcwM3w0ODB8ODQ4LjM1fGZsYXNofDN8MjEtMjExfDE0MDM1NjI5Njd8NDMyfDB8Y2FkZDhkZWNjZTdiNDI4NGUwZTFmMTRhNzE4MWM4MmU=&nsfw=0&do=s&s=431.85&vt=TkFTQSBBU1RST05BVVQgTEVBRFMgVE9VUiBPRiBTUEFDRSBTVEFUSU9OIElOIEhE)
You can see that the long video serves a page with the text "link expired"
whereas the short video serves a page with the desired player <object>.
See 'player_path' in [veehd.py](https://github.com/rg3/youtube-dl/blob/master/youtube_dl/extractor/veehd.py)
## 

Looking through the inline javascript of the original video page,
it becomes apparent that a POST request is sent.
Specifically through the function 'prepare_server'.
The function executes the following line:

```
$[_0x3c5a[4]](_0x3c5a[2],{p:1,ts:ts,sgn:sgn,v:_0x3c5a[3]});
```

Which translates to:

```
$["post"]("/xhrp", {p:1,ts:ts,sgn:sgn,v:"c"} );
```

The global variables 'ts' and 'sgn' vary with each video and can be found in the inline javascript.

Once the post request is manually sent, the player page for the long video now returns the desired player <object> rather than the "link expired" text.

Below is a sample of the response
## 

```
Request URL:    http://veehd.com/xhrp
Request Method:     POST
Status Code:    HTTP/1.1 200 OK
Request Headers **:**:**.000
X-Requested-With:   XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:29.0) Gecko/20100101 Firefox/29.0
Referer:    http://veehd.com/video/1901703
Pragma: no-cache
Host:   veehd.com
DNT:    1
Content-Type:   application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 58
Connection: keep-alive
Cache-Control:  no-cache
Accept-Language:    en-US,en;q=0.5
Accept-Encoding:    gzip, deflate
Accept: */*

Sent Cookie
PHPSESSID:  fbqn1en1okhn3b00wuiok5329
Request Body
p=1&ts=1403562967&sgn=bff481f6488fc50b9ba2ff1cd3c319b1&v=c

Response Headers Δ539ms
Vary:   Accept-Encoding
Server: nginx
Pragma: no-cache
Expires:    Thu, 19 Nov 1981 08:52:00 GMT
Date:   Wed, 18 Jun 2014 06:34:21 GMT
Content-Type:   text/html
Content-Length: 21
Content-Encoding:   gzip
Connection: keep-alive
Cache-Control:  no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Accept-Ranges:  bytes
Received Cookie
plugin: 1
Response Body Δ0ms
1
```
Repository: neovim
Issue: Drop support for various :execute cmd/:UserCmd variants
Labels: vimscript,compatibility

Variants in question:
1. Commands that change execution flow in cycles:
   
   ```
   execute 'break'
   command UserBreak continue
   ```
   
   I do not know why these may be used.
2. Return statements. Examples:
   
   ```
   execute 'return' expr
   ```
   
   may be used as a replacement for `return eval(expr)`,
   
   ```
   command -nargs=1 LoggedReturn :let __r=<args> | call LogReturnValue(expand('<sfile>'), __r) | return __r
   ```
   
   may be used for logging returns. One may also use this variant to implement one kind of function decorators: those that modify return value after function was run (note: commands have full access to function scope).
3. (Already discussed?) partial function definition:
   
   ```
   execute 'function Abc()'
       " Function body
   endfunction
   ```
   
   . This may be used for things like decorating functions, but it is very hard to implement, especially given that `:execute` may actually be `:UserCommand`.
4. (Already discussed AFAIR) Incomplete block entry commands:
   
   ```
   execute 'if' expr
   execute 'while' expr
   execute 'for x in' expr
   ```
5. (Already discussed, just adding here for completeness) Incomplete `:append`-like commands.

Discussed 3, 4 and 5 were discussed because they are not supported by parser and thus are very hard to implement. New 1 and 2 are much easier to implement, but I think that code with 1. smells and 2. is hacky enough I never saw it in the wild (untested BTW) and thus is not worth supporting. I probably have not seen 2. due to `&verbose` option. Or because those who know that this is possible (there should not be too much people knowing about this hack) consider this solution too hacky. Due to the variety of possible uses of 2. I am asking here whether anybody have seen it actually used.