jiebi/CodeConvo huggingface dataset:
Change:
"torch/csrc/Generator.cpp", "torch/csrc/Size.cpp", "torch/csrc/Exceptions.cpp", <del> "torch/csrc/Tensor.cpp", </del> "torch/csrc/Storage.cpp", "torch/csrc/DynamicTypes.cpp", "torch/csrc/byte_order.cpp",

Discussion:
Trying to run on github actions via AWS instance gives me: I will of course set up now, but it shouldn't crash like that. May be it should use as a fallback? pt-2.0 cc
Is this a multitenant setup? Also curious which distro are you running, I was under the impression that most linux distros set home by default
this is AWS image. one default user. I think it's user, but it wants you to run as root, which is weird. I have manually now set to overcome this.
We should update triton to use pathlib or something
Change:
is_master_only=True, requires=["binary_linux_manywheel_3_7m_cu102_devtoolset7_build"], extra_props={ <del> "resource_class": "gpu.medium", </del> <ins> "resource_class": "gpu.nvidia.small", </ins> "use_cuda_docker_runtime": miniutils.quote((str(1))), }, ),

Discussion:
As it still using deprecated resource class, see See example of the failure in
Followup: we need to plan better --we knew it was gonna happen and none of us fixed it early enough. Action item: go through tasks about deprecation in sprint planning
Change:
class Dropout(Module): <del> r"""Randomly zeroes some of the elements of the input tensor. </del> <ins> r"""During training, randomly zeroes some of the elements of the input tensor with probability *p* using samples from a bernoulli distribution. </ins> The elements to zero are randomized on every forward call. <ins> This has proven to be an effective technique for regularization and preventing the co-adaptation of neurons as described in the paper `Improving neural networks by preventing co-adaptation of feature detectors`_ . Furthermore, the outputs are scaled by a factor of *1/(1-p)* during training. This means that during evaluation the module simply computes an identity function. </ins> Args: p: probability of an element to be zeroed. Default: 0.5 inplace: If set to True, will do this operation in-place. Default: false

Discussion:
"Randomly zeroes some of the elements of the input tensor. The elements to zero are randomized on every forward call." This is incorrect; the function also scales up by 1/(1-p), which the implementation correctly does.
Change:
del l1[i] return l1 <del> def _backward(self, method, input, gradOutput, scale): </del> <ins> def _backward(self, method, input, gradOutput, scale=1): </ins> isTable = isinstance(input, list) wasTable = isinstance(self.gradInput, list) if isTable: for i, module in enumerate(self.modules): <del> currentGradInput = getattr(module, method)(input, gradOutput[i], scale) </del> <ins> if method == 'updateGradInput': currentGradInput = module.updateGradInput(input, gradOutput[i]) elif method == 'backward': currentGradInput = module.backward(input, gradOutput[i], scale) </ins> if not isinstance(currentGradInput, list): raise RuntimeError("currentGradInput is not a table!")

Discussion:
Subclassing torch.Tensor with fails due to a on the latest nightly builds, whereas it previously worked without issue. Run this snippet of code: And you'll recieve an error message like this: Changing the to results in the exact same error message. There should be no error message as it should be working like it was previously in Torch 1.8.1 and below. I think that the issue started on Torch version: , and I can confirm that it still exists as of , . The issue started on the nightly builds at least 2 days ago, if that helps resolve things. It's been causing some of Captum's CircleCI tests to fail, and the tests show the first occurrence of the error on . cc
This is due to either or
I think the problem is I'm not supposed to delete because that means the super() call doesn't work. Instead, I should just verify that the passed in class is a subclass, then this should work.
Change:
-DCMAKE_CXX_FLAGS="$C_FLAGS $CPP_FLAGS" make install cp "lib/libnccl.so.1" "${INSTALL_DIR}/lib/libnccl.so.1" <del> ln -s "${INSTALL_DIR}/lib/libnccl.so.1" "${INSTALL_DIR}/lib/libnccl.so" </del> <ins> if [ ! -f "${INSTALL_DIR}/lib/libnccl.so" ]; then ln -s "${INSTALL_DIR}/lib/libnccl.so.1" "${INSTALL_DIR}/lib/libnccl.so" fi </ins> cd ../.. }

Discussion:
there is a bug. the code is from The code for installing cuda10.2 should be corrected to The code for installing cuda10.2 should be corrected to cc
Thank you for reporting the typo

This is how I implement the decoder of a sequence to sequence model I'm not sure about the new autograd mechanics but this worked in the previous version. If I didn't make the unrolling codes a function it will work. It will also work with CPU. I compiled from source with Python 2.7, CUDA 8.0 and Cudnn 6
Thanks for the minimal reproduction! It broke OpenNMT and a big internal model but we weren't looking forward to isolating what parts of those had the issue.
That's great, I'll take a look today. Thanks!
I've pushed a fix to .
How does the inference work in this case? I mean, once you train it how do you test it in the test phase?
Change:
For summation index :math:`j` given by `dim` and other indices :math:`i`, the result is <del> :math:`text{logsumexp}(x)_{i} = log sum_j exp(x_ij).` </del> <ins> .. math:: text{logsumexp}(x)_{i} = log sum_j exp(x_{ij}) </ins> If :attr:`keepdim` is ``True``, the output tensor is of the same size as :attr:`input` except in the dimension :attr:`dim` where it is of size 1.

Discussion:
Leaving this issue here for higher visibility. Originally reported by here: Also mentioned by Piggybacking off of this issue, has strange behavior (reported here: )
I have fixed this locally. Could I send a PR?
Yes, go ahead!
Change:
return g.op("Undefined") <ins> def Constant(g, value): return g.op("Constant", value_t=value) </ins> def add(g, self, other, alpha): if _scalar(alpha) != 1: return _unimplemented("add", "alpha != 1")

Discussion:
Hi! OS: Linux PyTorch version: 0.4.0a0+ How you installed PyTorch (conda, pip, source): source Python version: 3.6Context around what you are trying to do I am trying to convert layer with torch.indexselect() operation to onnx A script to reproduce the bug. Please try to provide as minimal of a test case as possible.Error messages and/or stack traces of the bug What is the right way to export torch.indexselect() operation?
It kind of sounds like we forgot to implement constant export, which is embarrassing and should be fixed.
Are there any chances it will be fixed soon?
I took a look, and actually, it's just a spurious warning, the model seems to export successfully into
Change:
return THC_float2half(0); #else THError("Cublas_Hdot requires CUDA 8.0+"); <del> return THC_half2float(0); </del> <ins> return THC_float2half(0); </ins> #endif } #endif

Discussion:
Hi, I was trying to update from source but I get an error "no suitable constructor exists to convert from "int" to "__half"" when trying to build I am working with python 2.7 cuda 7.5 and GCC 4.8.3 in openSUSE. Any suggest? Here is the output error when building from source:
ATen Excluded: set(['bernoulli', 'bernoulli']) [ 0%] Built target atenfilesaregenerated [ 0%] Building NVCC (Device) object [ 1%] Building NVCC (Device) object [ 1%] Building NVCC (Device) object [ 1%] Building NVCC (Device) object [ 1%] Building NVCC (Device) object [ 2%] Building NVCC (Device) object [ 2%] Building NVCC (Device) object [ 2%] Building NVCC (Device) object (77): error: no suitable constructor exists to convert from "int" to "half" (77): error: no suitable constructor exists to convert from "float" to "half" 2 errors detected in the compilation of "/tmp/tmpxft0000587a00000000-". CMake Error at (message): Error generating file recipe for target '' failed make[2]: [] Error 1 make[2]: Waiting for unfinished jobs.... CMakeFiles/Makefile2:194: recipe for target '' failed make[1]: [] Error 2 Makefile:129: recipe for target 'all' failed make: [all] Error 2
NVIDIA cuDNN v6.x or above
same problem here. gcc (Ubuntu 4.8.4), python 2.7, cuda 7.5, cuDNN 6.0.21
Same problem here. CUDA: v7.5 CUDNN: v6.0
Change:
} }; <ins> // Similar to shared_from_this. There's a problem that the Python object // and its cdata depend on each other being alive, so we can't keep // shared_ptrs as members, but we'd like to be able to manage the lifetime of // the objects using shared_ptrs in the C++ graph. The only way to get a new // shared_ptr that references them is through THPFunction_asFunction. When // called for the first time it will allocate a new shared_ptr and save a // weak_ptr in cdata_ptr attr. Later, when we try to take another reference, // we'll try to lock cdata_ptr and return its value if successful. Otherwise it // means that all shared_ptrs returned previously have been freed, so we can // create a new one. This ensures that this object is managed by at most one // shared_ptr control block at any time - a guarantee we depend on in other places // (e.g. we use weak_ptrs in SavedVariable because we know it won't go out of scope). </ins> std::shared_ptr<PyFunction> THPFunction_asFunction(THPFunction* self) { if (!self) { return std::shared_ptr<PyFunction>(); } Py_INCREF((PyObject*)self); <del> return std::shared_ptr<PyFunction>(&self->cdata, Decref()); </del> <ins> auto ptr = self->cdata_ptr.lock(); if (ptr) return ptr; ptr = std::shared_ptr<PyFunction>(&self->cdata, Decref()); self->cdata_ptr = ptr; return ptr; </ins> }

Discussion:
there is a bug. the code is from The code for installing cuda10.2 should be corrected to The code for installing cuda10.2 should be corrected to cc
Thank you for reporting the typo

This is how I implement the decoder of a sequence to sequence model I'm not sure about the new autograd mechanics but this worked in the previous version. If I didn't make the unrolling codes a function it will work. It will also work with CPU. I compiled from source with Python 2.7, CUDA 8.0 and Cudnn 6
Thanks for the minimal reproduction! It broke OpenNMT and a big internal model but we weren't looking forward to isolating what parts of those had the issue.
That's great, I'll take a look today. Thanks!
I've pushed a fix to .
How does the inference work in this case? I mean, once you train it how do you test it in the test phase?
Change:
x.__repr__() str(x) <ins> x = torch.DoubleTensor([1e-324, 1e-323, 1e-322, 1e307, 1e308, 1e309]) x.__repr__() str(x), </ins> def test_unsqueeze(self): x = torch.randn(2, 3, 4) y = x.unsqueeze(1)

Discussion:
on print(torch.DoubleTensor(1)) I got ZeroDivisionError: float division by zero but torch.DoubleTensor(0)) or torch.DoubleTensor(2)) work just fine. I work in Jupyter notebook pytorch 0.1.12
Note that returns undefined memory. Could you find the specific content of the tensor that gave this error, by printing ? I'm not sure if this bug has been fixed in the latest release already.
the error is pretty interesting. I restarted Jupyter notebook. # many freaking signatures: print(torch.FloatTensor(1)) print(torch.IntTensor(1)) print(torch.DoubleTensor(1)) # no error right after initial run. #print(torch.DoubleTensor(0)) print(torch.DoubleTensor(2)) print(torch.ByteTensor(1)) print(torch.CharTensor(1)) print(torch.ShortTensor(1)) print(torch.LongTensor(1)) steps to reproduce the error: 1). run, no errors 2) repeat, no error 3) uncomment ..DoubleTensor(0), run, got an error (see below): 4) comment ..DouleTensor(0), run still have this error 2.+24 [torch.FloatTensor of size 1] 7.+08 [torch.IntTensor of size 1] ZeroDivisionError Traceback (most recent call last) &lt;ipython-input-5-3629c250c505in &lt;module() 2 print(torch.FloatTensor(1)) 3 print(torch.IntTensor(1)) ----4 print(torch.DoubleTensor(1)) # ZeroDivisionError: float division by zero 5 #print(torch.DoubleTensor(0)) 6 print(torch.DoubleTensor(2)) C:UsersleogAppDataLocalcondacondaenvspy35libsite-packagestorch in str(self) 126 # characters to replace unicode characters with.

127 if sys.versioninfo (3,): --128 return (self) 129 else: 130 if hasattr(, 'encoding'): C:UsersleogAppDataLocalcondacondaenvspy35libsite-packagestorch in str(self) 284 return '[{} with no dimension]n'.format(torch.typename(self)) 285 elif self.ndimension() == 1: --286 strt = vectorstr(self) 287 elif self.ndimension() == 2: 288 strt = matrixstr(self) C:UsersleogAppDataLocalcondacondaenvspy35libsite-packagestorch in vectorstr(self) 270 if () &lt; PRINTOPTS.threshold: 271 return (strt + --272 'n'.join(ident + (val / scale) for val in self) + 273 'n') 274 else: C:UsersleogAppDataLocalcondacondaenvspy35libsite-packagestorch in &lt;genexpr(.0) 270 if () &lt; PRINT_OPTS.threshold: 271 return (strt + --272 'n'.join(ident + (val / scale) for val in self) + 273 'n') 274 else: ZeroDivisionError: float division by zero
Ok, I got a repro. Here is the failing case: Fails with the error you mentioned. This seems to be an edge case though, as both and works. The issue is in , where becomes zero because is a too large negative number. Maybe we should clip to be positive?
Change:
if (tensor->isCuda() != isCuda) { throw invalid_tensor(isCuda ? "CUDA" : "CPU", tensor->isCuda() ? "CUDA" : "CPU"); } <ins> if (tensor->type() != type) { throw invalid_tensor(thpp::toString(type), thpp::toString(tensor->type())); } </ins> } }

Discussion:
the error only happens in very specific conditions. (change the view of input tensor and use weight converted from numpy array.) The output of functional conv2d is far off in scale (e12 or so.)
this happens because generates double precision tensor by default, whereas torch generates single precision. We need to add guards for tensor types in THNN and THCUNN.
It's a problem with function, that only . Should be a simple fix.
Whoops! Yeah it just ignores the "thpp::Type type" parameter
what type is expected here?
a is a FloatTensor but weights is a DoubleTensor. Change: to: (or change a to (...).double())
cool thanks!
Change:
Py_INCREF(input_var); output_var = input_var; input_var_.creator = THPFunction_asFunction(self); <ins> input_var_.requires_grad = self->cdata.requires_grad; </ins> } else { // If the leaf Variable has been returned, we have to move it after the // current function to ensure the gradient is computed correctly.

Discussion:
import torch as th from torch.autograd import Variable x = Variable(th.Tensor([1 , 2 , 3]) , requiresgrad = False) y = Variable(th.Tensor([100]) , requiresgrad = True) x = x.cuda(0) y = y.cuda(0) x[0] = y print(x.requiresgrad) If ((0) (0)) is executed then the output is False, True otherwise. I think the result that x.requiresgrad = True is more natural.
I further checked some in-place operator in GPU mode(say, x = Variable(...).cuda(0) ), and find out that after the operation is done, the requiresgrad of the Variable doesn't change. For example: import torch as th from torch.autograd import Variable x = Variable(torch.Tensor([1]) , requiresgrad = False) y = Variable(torch.Tensor([2]) , requiresgrad = True) x = x.cuda(0) y = y.cuda(0) x.add(y) print(x.requires_grad) the output is False
It doesn't have to do with Variable holding a CUDA tensor, but rather with the fact that it's no longer a leaf. I've sent a fix in .
Thanks for the report!
Change:
return torch._C._cuda_getDeviceName(device) <ins> def get_device_capability(device): """Gets the cuda capability of a device. Arguments: device (int): device for which to return the name. This function is a no-op if this argument is negative. Returns: tuple(int, int): the major and minor cuda capability of the device """ if device >= 0: return torch._C._cuda_getDeviceCapability(device) </ins> @contextlib.contextmanager def stream(stream): """Context-manager that selects a given stream.

Discussion:
There's quite a few user-reports of installing the CUDA 7.5 binary of pytorch and then running on GTX 1080 / 1070, and there will be reports of installing 7.5 / 8.0 binaries and running on V100. Raising a user-warning in such situations and letting them know will fix the problem.
The version of CUDA used to compile the binary should be available thanks to this PR:
I think is a more robust way of getting the CUDA used to compile PyTorch, as currently if there are multiple CUDA installed in the machine, the heuristics used in might not match those used by CMake FindCUDA. I think that we should modify the to return the cuda version used during compilation. I have the impression that it will not require changing much because doesn't require cuda to execute. What do you think?
Change:
try: _loadlib() except Exception: <del> warnings.warn('cuDNN library not found. Check your LD_LIBRARY_PATH') </del> <ins> warnings.warn('cuDNN library not found. Check your {libpath}'.format( libpath={ 'darwin': 'DYLD_LIBRARY_PATH', 'win32': 'PATH' }.get(sys.platform, 'LD_LIBRARY_PATH'))) </ins> return False return True

Discussion:
The official website does not provide the torchvison version installation method. Here is the error message when torchvison 0.3.0 is used. torchvision/C.cpython-36m-x8664-linux- undefined symbol: ZN2at7getTypeERKNS6TensorE That should be caused by the mismatch version between pytorch-nightly and torchvision 0.3.0.
It should be that matches with , but they are not provided currently.
I tried installing it with pip as per , but now I get when importing . I did a similar thing on June 25th. It worked then. Any known fix for this?
do we document what to do here?
I finally solved this by building from source with Before running that make sure to upgrade and to use . Note: this will not work if you have on your system when building since you'd get version mismatch between and . Tested only on .
you build pytorch from source or just torchvision? or both of them.
I installed from conda with: I then cloned the repo and ran inside the repo. I guess this would also work if you do , but I haven't tried it.
Just a reminder (what I encountered just now): one should uninstall previous ` from source, or they can mix up and mess up everything.
There are nightlies for torchvision under Windows now.
I have problems using Pytorch with my Geforce RTX 3060, (sm86). I tried to install with help of : Create a new venv, based on python 3.7.10. Activate it. conda install pytorch-nightly cudatoolkit=10.0 -c pytorch (I also did it without the "=10.0") After this, Pytorch detects the sm86 with no errors, problem sm86 solved with pytorch-nightly Now, I have a problem with torchvision. tried installing torchvision with File "C:repovisiontorchvisionmodels", line 195, in Inception3 AttributeError: module '' has no attribute 'unused' tried installing torchvision version 0.3.0, from , but an error rose: tried installing torchvision at origin/master, from , but another error rose: Here is the list of packages installed:
Change:
transposedIndices.emplace_back(); } } <del> return std::make_tuple<>(self.permute(dims), std::move(transposedIndices)); </del> <ins> return std::make_tuple(self.permute(dims), std::move(transposedIndices)); </ins> } static std::vector<int64_t> computeLinearStride(const Tensor & tensor) {

Discussion:
In PyTorch master 0.4 , variables cannot be indexed. This used to work in PyTorch 0.2 :
This is breaking some of Pyro's inference algorithms on PyTorch master:
Change:
finally: torch.backends.cudnn.enabled = prev <ins> def test_rnn_args_check(self): input_size = 3 hidden_size = 5 num_layers = 2 batch_size = 4 seq_len = 6 num_directions = 1 def test(input_shape, hidden_shape, mode): for input, hidden in get_inputs(input_shape, hidden_shape, mode): model = getattr(nn, mode)(input_size, hidden_size, num_layers) self.assertRaises(RuntimeError, lambda: model(input, hidden)) correct_input_shape = (seq_len, batch_size, input_size) correct_hidden_shape = (num_layers * num_directions, batch_size, hidden_size) def update_tuple(tup, dim, delta): new_tup = list(tup) new_tup[dim] = delta return tuple(new_tup) def get_inputs(input_shape, hidden_shape, mode): '''returns list( tuple(input, hidden) ) where input, hidden are inputs to a model''' input = Variable(torch.randn(input_shape)) hidden = Variable(torch.randn(hidden_shape)) if mode is not 'LSTM': return [(input, hidden)] if hidden_shape == correct_hidden_shape: return [(input, (hidden, hidden))] good_hidden = Variable(torch.randn(correct_hidden_shape)) return [ (input, (hidden, good_hidden)), (input, (good_hidden, hidden)), ] rnn_modes = ['RNN', 'GRU', 'LSTM'] for mode in rnn_modes: # Incorrect input batch size input_shape = update_tuple(correct_input_shape, 1, -1) hidden_shape = correct_hidden_shape test(input_shape, hidden_shape, mode) # Incorrect hidden batch size input_shape = correct_input_shape hidden_shape = update_tuple(correct_hidden_shape, 1, -1) test(input_shape, hidden_shape, mode) # Incorrect input size input_shape = update_tuple(correct_input_shape, 2, -1) hidden_shape = correct_hidden_shape test(input_shape, hidden_shape, mode) # Incorrect hidden size input_shape = correct_input_shape hidden_shape = update_tuple(correct_hidden_shape, 2, -1) test(input_shape, hidden_shape, mode) # Incorrect hidden[0] input_shape = correct_input_shape hidden_shape = update_tuple(correct_hidden_shape, 0, -1) test(input_shape, hidden_shape, mode) </ins> def test_rnn_initial_hidden_state(self): rnn_modes = ['RNN', 'GRU', 'LSTM'] for mode in rnn_modes:

Discussion:
I run RNN sucessfully with the code. and I run embedding example. Then, got RuntimeError. I set to use nothing seems wrong. And the error info seems not the dim problem? The error is so strange.
What exactly do you mean by "embedding example"? Could you provide a code snippet that causes the RuntimeError?
To better reproduce the error, I use the official code example of The origin runs well: Due to use , I have to make batch first. And then , it raises error.
Thank you for the example! The say that setting means that the first dim of input is the batch, ie, input has size . however is unchanged, so the following should work: I do agree the error message could be better, though
Change:
make_variable(std::move(std::get<3>(tensors)))); } <del> std::vector<Variable> VariableType::as_variable(TensorList tl) const { </del> <ins> static std::vector<Variable> as_variable(TensorList tl) { </ins> std::vector<Variable> variables; for (auto& t : tl) { variables.emplace_back(make_variable(std::move(t)));

Discussion:
See Docker run fails with , which is due to the fact that is specified in docker container: Which results in: CI cc
Check that adding to manywheels image results in a failure:
Tentatively marking hi-pri since nightly testing are failing
This is resolved, here is the successful run: