jiebi/CodeConvo huggingface dataset:
Code change:
return (hasattr(torch._C, '_cuda_isDriverSufficient') and torch._C._cuda_isDriverSufficient()) <del> def _lazy_init(): global _initialized, _cudart if _initialized: return </del> <ins> def _load_cudart(): system = platform.system() lib_name = 'libcudart.' + ('dylib' if system == 'Darwin' else 'so') lib_paths = [ lib_name, os.path.join(torch._C._cuda_getLibPath(), lib_name), os.path.join('/usr/local/cuda/lib64', lib_name), os.path.join('/usr/local/cuda/lib', lib_name), ] for path in lib_paths: try: return ctypes.cdll.LoadLibrary(path) except OSError: pass raise RuntimeError("couldn't find libcudart. Make sure CUDA libraries " "are installed in a default location, or that they're in " + ("DYLD_LIBRARY_PATH" if system == 'Darwin' else "LD_LIBRARY_PATH") + ".") def _check_driver(): </ins> if not hasattr(torch._C, '_cuda_isDriverSufficient'): raise AssertionError("Torch not compiled with CUDA enabled") if not torch._C._cuda_isDriverSufficient():

Related discussion:
text: right now if is not in LDLIBRARYPATH, though it was found at compile-time, these lines will fail: Avoid this, by idk doing something... I think i have a few good ideas.
We need to add /usr/local/cuda/lib64 (or that's mac dir) to the rpath of _C
the problem i dont think is to add it to rpath, it's because we
Right. We could try with the default cuda installation path if it's not found from LDLIBRARYPATH.
Actually, do we really want to use the compile path? We should try to detect it at runtime, right? Or are we going to ship CUDA libs in our binaries?
we first load using runtime paths, and if it fails, fallback to path known at compile time.
I fear this is going to get brittle, especially if you are shipping CUDA libs. e.g. a user swaps HW and picks up a new driver and/or toolkit. As says, I'm pretty sure you want to use the runtime paths. Similarly, CUDA 7.5 won't run on Pascal and we have a cudnn built for 7.5 that will not do the right thing on CUDA 8, so those need to go together. If a user installs the CUDA bits via deb/rpm the right things are supposed to happen. If you push bits, we need to figure out how to make sure things line up. But this is perhaps a much larger packaging conversation.
Yeah, I've implemented it to first try loading it without any path and then try and . I'll push the commit tomorrow.
Code change:
extern PyObject * THCPModule_initialSeed(PyObject *_unused); extern PyObject * THCPModule_cudaHostAllocator(PyObject *_unused); extern PyObject * THCPModule_cudaSynchronize(PyObject *_unused); <ins> extern PyObject * THCPModule_getLibPath(PyObject *_unused); </ins> #endif static PyMethodDef TorchMethods[] = {

Related discussion:
text: right now if is not in LDLIBRARYPATH, though it was found at compile-time, these lines will fail: Avoid this, by idk doing something... I think i have a few good ideas.
We need to add /usr/local/cuda/lib64 (or that's mac dir) to the rpath of _C
the problem i dont think is to add it to rpath, it's because we
Right. We could try with the default cuda installation path if it's not found from LDLIBRARYPATH.
Actually, do we really want to use the compile path? We should try to detect it at runtime, right? Or are we going to ship CUDA libs in our binaries?
we first load using runtime paths, and if it fails, fallback to path known at compile time.
I fear this is going to get brittle, especially if you are shipping CUDA libs. e.g. a user swaps HW and picks up a new driver and/or toolkit. As says, I'm pretty sure you want to use the runtime paths. Similarly, CUDA 7.5 won't run on Pascal and we have a cudnn built for 7.5 that will not do the right thing on CUDA 8, so those need to go together. If a user installs the CUDA bits via deb/rpm the right things are supposed to happen. If you push bits, we need to figure out how to make sure things line up. But this is perhaps a much larger packaging conversation.
Yeah, I've implemented it to first try loading it without any path and then try and . I'll push the commit tomorrow.
Code change:
.. math:: f(X) = sqrt[p]{sum_{x in X} x^{p}} <del> - At p = infinity, one gets Max Pooling - At p = 1, one gets Average Pooling </del> <ins> - At p = infinity, one gets Max Pooling - At p = 1, one gets Sum Pooling (which is proportional to Average Pooling) </ins> Args: kernel_size: a single int, the size of the window

Related discussion:
text: The math rendering doesn't end where it should, making the text after it difficult to read: <img width="719" alt="screen shot 2018-03-12 at 5 07 03 pm" src="https://user-"
Thanks for the report! Would you be interested in submitting a PR that fixes it?
Sure, I can give it a try!
This is being fixed in this PR
Code change:
np.float, np.int64, np.int32, <ins> np.int16, </ins> np.uint8 ] for dtype in dtypes:

Related discussion:
text: Should we add a ShortTensor Type, or just convert int16 to IntTensor ?
We already have a type available in pytorch. We have to enable conversion in the relevant function here:
Auto travis-ci failed at python2.7 :(
Do you have any plan to support int8 numpy conversion while you have too?
Char tensor uses char which is not guaranteed to be signed by the C standard. We'd need to change our C code to use a
I try , it complains , any idea?
The error message is quite self explanatory. PyTorch doesn't support tensors at the moment.