jiebi/CodeConvo huggingface dataset:
Change:
return self.clone(); } <del> std::vector<int64_t> to_arg_sizes(TensorList tensors, int64_t dim) { </del> <ins> static std::vector<int64_t> to_arg_sizes(TensorList tensors, int64_t dim) { </ins> std::vector<int64_t> arg_sizes(tensors.size()); for (size_t i = 0; i < tensors.size(); ++i) { arg_sizes[i] = tensors[i].size(dim);

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:
Change:
self._test_broadcast_helper(group, group_id, rank) @unittest.skipIf(BACKEND != 'gloo', "Only Gloo backend supports CUDA allReduce") <ins> @skip_if_no_cuda_distributed </ins> def test_broadcast_cuda(self): group, group_id, rank = self._init_global_test() self._test_broadcast_helper(group, group_id, rank, True)

Discussion:
is causing a crash when we try to build pytorch. Crash looks like this: (all times in US/West) Our 7AM, 8AM builds and earlier were all fine but 9AM, 10AM, 11AM builds all crashed with that same traceback. The new import was in which I think went in between 8AM and 9AM today See command below: See here if needed for : <!-- A clear and concise description of what you expected to happen. --Please copy and paste the output from our (or fill out the checklist below manually). You can get the script and run it with: PyTorch Version (e.g., 1.0): building from master OS (e.g., Linux): linux How you installed PyTorch (, , source): source Build command you used (if compiling from source): see above under 'reproduce' Python version: 3.6
maybe easier to read for build command used:
please try in the CircleCi environment?
in our build script seems to have fixed this. Thanks !
Change:
self.assertEqual(res1, res2, 0) self.assertEqual(res1, res3, 0) <ins> def _test_overdetermined(a, b, expectedNorm): m = a.size()[0] n = a.size()[1] assert(m > n) def check_norm(a, b, expected_norm, gels_result): # Checks |ax - b| and the residual info from the result n = a.size()[1] # The first n rows is the least square solution. # Rows n to m-1 contain residual information. x = gels_result[:n] resid_info = gels_result[n:] resid_norm = (torch.mm(a, x) - b).norm() self.assertEqual(resid_norm, expectedNorm, 1e-8) self.assertEqual(resid_info.norm(), resid_norm, 1e-8) a_copy = a.clone() b_copy = b.clone() res1 = torch.gels(b, a)[0] self.assertEqual(a, a_copy, 0) self.assertEqual(b, b_copy, 0) check_norm(a, b, expectedNorm, res1) ta = torch.Tensor() tb = torch.Tensor() res2 = torch.gels(b, a, out=(tb, ta))[0] self.assertEqual(a, a_copy, 0) self.assertEqual(b, b_copy, 0) check_norm(a, b, expectedNorm, res2) res3 = torch.gels(b, a, out=(b, a))[0] check_norm(a_copy, b_copy, expectedNorm, res3) self.assertEqual(res1, tb, 0) self.assertEqual(res1, b, 0) self.assertEqual(res1, res2, 0) self.assertEqual(res1, res3, 0) </ins> # basic test expectedNorm = 0 a = torch.Tensor(((1.44, -9.96, -7.55, 8.34),

Discussion:
b = (600,1) A = (600,2) X, = (b,A) X.size() #torch.Size([2, 1]) Y, = (b.cuda(),A.cuda()) Y.size() #torch.Size([600, 1])
that is interesting. says that the first rows returned ( here) include the solution of the least-squares problem. I've verified that the first 2 rows of X and Y are the same so you can probably use that for now while we figure out what the rest of the output is.
Change:
pytorch-linux-trusty-py3.6-gcc5.4-test pytorch-linux-trusty-py3.6-gcc7.2-build pytorch-linux-trusty-py3.6-gcc7.2-test <ins> pytorch-linux-trusty-py3.6-gcc7-build pytorch-linux-trusty-py3.6-gcc7-test </ins> pytorch-linux-trusty-pynightly-build pytorch-linux-trusty-pynightly-test pytorch-win-ws2016-cuda9-cudnn7-py3-build

Discussion:
We're not testing against CUDA 9.2 and we should. C.f. We should test against GCC 7 (because this is how Anaconda is building the packages), AND we should use test with this in OS X, because CUDA 9.2 now supports the default xcode shipped on OS X.
Building PyTorch with CUDA 9.2 for 7.0 compute compatibility devices produces quite worrisome warnings: warning : Instruction 'vote' without '.sync' may produce unpredictable results on sm70 and later architectures warning : Instruction 'vote' without '.sync' is deprecated since PTX ISA version 6.0 and will be discontinued in a future PTX ISA version warning : Instruction 'shfl' without '.sync' is deprecated since PTX ISA version 6.0 and will be discontinued in a future PTX ISA version warning : Instruction 'shfl' without '.sync' may produce unpredictable results on sm70 and later architectures
CUDA 9.2 CI on macOS is done in
Change:
.. automethod:: rsqrt .. automethod:: rsqrt_ .. automethod:: scatter_ <ins> .. automethod:: scatter_add_ </ins> .. automethod:: select .. automethod:: set_ .. automethod:: share_memory_

Discussion:
is not available in the docs page, but the doc string has been in . This was mentioned earlier in

Oh, bilinear, I missed that last time I looked at it. I'll add a docstring.

returns nothing. Might be useful to have some linter in the build process to find Python functions missing

Pytorch 0.4.0 gives a segmentation fault with dilated 2D convolutions over a specific size. import torch import as nn model = nn.Conv2d(inchannels=64, outchannels=64, kernelsize=5, dilation=2) model(([1, 64, 1166, 1166])) # This runs model(([1, 64, 1167, 1167])) # This crashes PyTorch version: 0.4.0 Is debug build: No CUDA used to build PyTorch: 9.1.85 OS: CentOS Linux 7 (Core) GCC version: (GCC) 4.8.5 (Red Hat 4.8.5-28) CMake version: version 2.8.12.2 Python version: 3.6 Is CUDA available: Yes CUDA runtime version: 8.0.61 GPU models and configuration: GPU 0: GeForce GTX 1080 Ti GPU 1: TITAN X (Pascal) GPU 2: Quadro K2200 Nvidia driver version: 390.59 cuDNN version: Probably one of the following: /usr/local/cuda- /usr/local/cuda- /usr/local/cuda-7.5/lib64/libcudnnstatic.a /usr/local/cuda- /usr/local/cuda-8.0/lib64/libcudnn_static.a
do you think this is the same as the segfault you showed me a week ago on convolution?
ah yes. int overflow. I only fixed conv3d because I didn’t want to hurt perf. I’ll fix all of them.

This should be an easy one.. The function is implemented, just no sign of it in the docs.
Change:
if config.triton.autotune_at_compile_time: self.kernel_autotune_calls.writeline(line) if zero_fill: <del> # TODO: remove this function to use the default WrapperCodegen behavior after service platform has zero_() symbol # default behavior is f"workspace.zero_(){self.ending}" self.writeline( f"AOTI_TORCH_ERROR_CODE_CHECK(aoti_torch_zero_(workspace.get())){self.ending}" ) </del> <ins> if isinstance(nbytes, sympy.Expr): self.writeline(f"workspace.zero_(){self.ending}") else: # TODO: remove this function to use the default WrapperCodegen behavior after service platform has zero_() symbol # default behavior is f"workspace.zero_(){self.ending}" self.writeline( f"AOTI_TORCH_ERROR_CODE_CHECK(aoti_torch_zero_(workspace.get())){self.ending}" ) </ins> if config.triton.autotune_at_compile_time: self.kernel_autotune_calls.writeline(f"workspace.zero_(){self.ending}")

Discussion:
Repro: Error: cc
Un-assign myself to let work on it.
, I can't reproduce the issue. The is no longer in the codebase. I gave a try of , which worked well. Could you double check if you can reproduce the issue?
Yes, I can still reproduce with your cmdline. Can you retry after deleting your local cache?
Change:
INCLUDE(CheckCXXSourceCompiles) <ins> # disable some verbose warnings IF (MSVC) set(CMAKE_CXX_FLAGS "/wd4267 /wd4251 /wd4522 /wd4522 /wd4838 /wd4305 /wd4244 /wd4190 /wd4101 /wd4996 /wd4275 ${CMAKE_CXX_FLAGS}") ENDIF(MSVC) </ins> # windef.h will define max/min macros if NOMINMAX is not defined IF(MSVC) add_definitions(/DNOMINMAX)

Discussion:
That's pretty big! In contrast, an OS X build log is only 1.3M. Is there a reason they have to be this big? CC
My guess is that it's because of warnings. I remember having to get through thousands of them when looking for the error that failed the build.
Yes, the major part of them are warnings. And some of them is not fixable. We can hide them using some flags on the compilers.
And this build configuration actually contains both the CPU and GPU build, which may also be a possible reason.
The reduced log size after PR is about 1.2M.
Change:
END_HANDLE_TH_ERRORS } <ins> PyObject * THCPModule_getDeviceCapability_wrap(PyObject *self, PyObject *arg) { HANDLE_TH_ERRORS THPUtils_assert(THPUtils_checkLong(arg), "invalid argument to getDeviceCapability"); long device = THPUtils_unpackLong(arg); cudaDeviceProp prop; THCudaCheck(cudaGetDeviceProperties(&prop, device)); return Py_BuildValue("(ii)", prop.major, prop.minor); END_HANDLE_TH_ERRORS } </ins> PyObject * THCPModule_getCurrentStream_wrap(PyObject *self) { HANDLE_TH_ERRORS

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:
Other Operations ~~~~~~~~~~~~~~~~~~~~~~ <ins> .. autofunction:: bincount </ins> .. autofunction:: cross .. autofunction:: diag .. autofunction:: diagflat

Discussion:
is not available in the docs page, but the doc string has been in . This was mentioned earlier in

Oh, bilinear, I missed that last time I looked at it. I'll add a docstring.

returns nothing. Might be useful to have some linter in the build process to find Python functions missing

Pytorch 0.4.0 gives a segmentation fault with dilated 2D convolutions over a specific size. import torch import as nn model = nn.Conv2d(inchannels=64, outchannels=64, kernelsize=5, dilation=2) model(([1, 64, 1166, 1166])) # This runs model(([1, 64, 1167, 1167])) # This crashes PyTorch version: 0.4.0 Is debug build: No CUDA used to build PyTorch: 9.1.85 OS: CentOS Linux 7 (Core) GCC version: (GCC) 4.8.5 (Red Hat 4.8.5-28) CMake version: version 2.8.12.2 Python version: 3.6 Is CUDA available: Yes CUDA runtime version: 8.0.61 GPU models and configuration: GPU 0: GeForce GTX 1080 Ti GPU 1: TITAN X (Pascal) GPU 2: Quadro K2200 Nvidia driver version: 390.59 cuDNN version: Probably one of the following: /usr/local/cuda- /usr/local/cuda- /usr/local/cuda-7.5/lib64/libcudnnstatic.a /usr/local/cuda- /usr/local/cuda-8.0/lib64/libcudnn_static.a
do you think this is the same as the segfault you showed me a week ago on convolution?
ah yes. int overflow. I only fixed conv3d because I didn’t want to hurt perf. I’ll fix all of them.

This should be an easy one.. The function is implemented, just no sign of it in the docs.
Change:
ENDFUNCTION() ################################################################################ <ins> if(${CMAKE_VERSION} VERSION_LESS "2.8.12") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") else(${CMAKE_VERSION} VERSION_LESS "2.8.12") if(${CMAKE_VERSION} VERSION_LESS "3.1") add_compile_options(-std=c++11) # CMake 2.8.12 to 3.1 endif(${CMAKE_VERSION} VERSION_LESS "3.1") endif(${CMAKE_VERSION} VERSION_LESS "2.8.12") </ins> IF(NOT Torch_FOUND) FIND_PACKAGE(Torch REQUIRED)

Discussion:
Currently, CMake 3.0 or higher is required for THPP. This is annoying for building from source on Ubuntu 14.04 systems, as default CMake is 2.8, and updating it requires either compiling from source or adding some random repos:
it should work fine if you change it to 2.8. I'm testing this out in a sec, and will push it into master
Nope, it does not for me.
Change:
import torch from functools import reduce from ._utils import _range <ins> from sys import float_info __MIN_LOG_SCALE = math.ceil(math.log(float_info.min * float_info.epsilon, 10)) </ins> class __PrinterOptions(object):

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:
std::vector<bool> *is_variable_input; char has_freed_buffers; <ins> // See a comment in THPFucntion_asFunction for details about this field. std::weak_ptr<torch::autograd::PyFunction> cdata_ptr; </ins> torch::autograd::PyFunction cdata; };

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:
IF "%CMAKE_GENERATOR%"=="Ninja" ( IF "%CC%"== "" set CC=cl.exe IF "%CXX%"== "" set CXX=cl.exe <del> set MAKE_COMMAND=cmake --build . --target install --config Release -- -j%NUMBER_OF_PROCESSORS% || exit /b 1 </del> <ins> set MAKE_COMMAND=cmake --build . --target install --config %BUILD_TYPE% -- -j%NUMBER_OF_PROCESSORS% || exit /b 1 </ins> ) ELSE ( <del> set MAKE_COMMAND=msbuild INSTALL.vcxproj /p:Configuration=Release </del> <ins> set MAKE_COMMAND=msbuild INSTALL.vcxproj /p:Configuration=%BUILD_TYPE% </ins> ) )

Discussion:
The current master triggers the following error messages from Visual Studio 2015 (Debug build): 2------ Build started: Project: ATen, Configuration: Debug x64 ------ 2cl : Command line error D8016: '/Ox' and '/RTC1' command-line options are incompatible ... 14LINK : fatal error LNK1104: cannot open file '....srcATenDebug' It appears that they are triggered by *.c files in the ATen project, like "srcTHvectorAVX.c"
Why do you need Debug build?
Isn't ATen meant to support both Debug and Release builds? FYI I'm involved with the project at which does support both build configurations, and we would like to be able to link our project with ATen.
Well, you can remove the flags in as a workground.
We should patch this file to ignore this flag when building the library in debug mode. It shouldn't be too hard
I catched similar errors , when I Tryed to build Debug Version I try to build Release and catched next errors e:pytorchatensrcatencpuvec256vec256int.h(184): note: see reference to function template instantiation 'at::vec256::anonymous-namespace'::Vec256<int16t::blend<1(at::vec256::anonymous-namespace'::Vec256<int16t)' being compiled 28e:pytorchatensrcatencpuvec256vec256int.h(147): error C3861: 'mm256extract_epi16': identifier not found What I should do?
There're two issues in your description. The first question is easy. You'll also have to specify the flag to 1. The second question is about your compiler. I guess you are using VS2015 or earlier versions of VS2017. Make sure the version in the output is 19.11 after your enter in CMD.
Yes I am using VS2015. My Compiler is 19.0.2. Must I use VS 2017 in any case?
Sorry, but the answer is yes. The AVX2 functions was in VS2017 and they are used in PyTorch. So VS2017 19.11 is a must.
No problem:) Thank you.
Change:
libs = ['TH', 'THS', 'THNN'] if WITH_CUDA: libs += ['THC', 'THCS', 'THCUNN'] <del> if WITH_NCCL and not SYSTEM_NCCL: </del> <ins> if WITH_NCCL and not WITH_SYSTEM_NCCL: </ins> libs += ['nccl'] libs += ['THPP', 'libshm', 'ATen', 'nanopb'] if WITH_DISTRIBUTED:

Discussion:
Currently, you can have a libnccl on your system, and pytorch setup favors that instead of compiling one itself from source. The code that takes care of this is: However, this breaks gloo build because gloo gets a path to NCCL via:
I got the error during the installation: Is it related to this problem?
that's a dupe of
no, that's a consequence of , now you have to do before compiling. I think you don't want to do recursive submodule update, because that will pull in gtest and another copy of nccl.
Alternatively we can pass new flags to gloo to prevent it from using its own NCCL
Thanks works for me.
You can prevent it from using its own nccl, but its cmake still has to be able to find some nccl.
I think should be sufficient. I'm testing.
fixes it when we dont have an external NCCL and pytorch compiles it's own NCCL?
I don't see how NCCLEXTERNAL fixes anything, looks like in gloo NCCLEXTERNAL is used just to set dependency if gloo is compiling its own nccl (which we don't want in any case).
The only thing I tested when I was that the vendored nccl was not being built (even if its submodule was checked out); I tested this by adding an to one of the headers. I'll test with the other configurations.
Actually, there are a few bugs here. First, even though GLOOFLAGS looks like it's setting NCCLROOTDIR: it actually isn't because the gloo invocation is which expands to but only is passed to cmake. Suppose you fix this. nccl is still not going to be picked up, because INSTALLDIR is PyTorch's local install dir, but if you disabled nccl builds, there will never actually be a nccl here. So cmake is just going to do it's standard search to find a nccl somewhere. Inversely, if you ever built nccl, and then turn it off, we will keep picking up that locally built version until you delete it. So we shouldn't do that. Suppose you fix this.

Then I think gloo will (continue to) correctly pick up system nccl and be built with it, and the final thing to fix is that build of PyTorch csrc doesn't know how to search for nccl headers somewhere. This is probably related to . I wonder, maybe we shouldn't do any autodetection at all, and force the user to pass us the include and library paths of nccl if they want to build with system.
FYI, I committed a change to gloo to stop bundling NCCL itself. It will now happily pick up whatever NCCL you give it through NCCLROOTDIR or by trying to find it in the standard systems paths. See facebookincubator/gloo You do have to set to make Gloo try and find it and compile in support.
So to fix this, you should be able to not specify anything aside from if you want to use system NCCL, and add if you have some custom location (either a PyTorch bundled version or a custom install altogether).
Change:
static void setattr(jit::Node* n, jit::Symbol name, const at::IntList& v)  { n->is_(name, v); } static void setattr(jit::Node* n, jit::Symbol name, bool v)                { n->i_(name, v); } static void setattr(jit::Node* n, jit::Symbol name, double v)              { n->f_(name, v); } <del> template<unsigned long N> </del> <ins> template<std::size_t N> </ins> static void setattr(jit::Node* n, jit::Symbol name, std::array<bool, N> v) { n->is_(name, std::vector<int64_t>(v.begin(), v.end())); } VariableType::VariableType(Context* context, Type* baseType)

Discussion:
Hello, I'm trying to build pytorch (I tried both v3_buildfix and master branch) on a raspberry pi 3 but i'm getting that error: Note: I'm building without CUDA and DISTRIBUTED support. OS: Ubuntu 16.04 (Mate) gcc: arm-linux-gnueabihf-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.5) 5.4.0 cmake: v3.5.1
Can you try building with and let me know if that fixes it?
Thanks, it compiles now ;)
Change:
last_epoch (int): The index of last epoch. Default: -1. Example: <del> >>> # Assuming optimizer uses lr = 0.5 for all groups </del> <ins> >>> # Assuming optimizer uses lr = 0.05 for all groups </ins> >>> # lr = 0.05     if epoch < 30 >>> # lr = 0.005    if 30 <= epoch < 80 >>> # lr = 0.0005   if epoch >= 80

Discussion:
Hi, In the is written: "lr values are [0.05, 0.005, ...]." If I understand it correctly, it should be [0.5, 0.05, 0.005, ...].
That is correct. Please feel free to send a PR to fix it! (otherwise, I can)
If you don't mind to change it yourself, I'm not contributor yet and don't want to start just for one comment. I guess is the same case.
Change:
"test_mm_plus_mm2_cuda_dynamic_shapes": test_torchinductor.TestFailure( ("cuda_wrapper",), is_skip=True ), <del> "test_consecutive_split_cumprod_cuda_dynamic_shapes": test_torchinductor.TestFailure( ("cuda_wrapper",), is_skip=True ), </del> }

Discussion:
Repro: Error: cc
Un-assign myself to let work on it.
, I can't reproduce the issue. The is no longer in the codebase. I gave a try of , which worked well. Could you double check if you can reproduce the issue?
Yes, I can still reproduce with your cmdline. Can you retry after deleting your local cache?
Change:
throw std::runtime_error(ss.str()); } <ins> static void checkIndexTensorTypes(TensorList indices) { for (auto& tensor : indices) { if (tensor.defined()) { auto& type = tensor.type(); auto scalarType = type.scalarType(); if (scalarType != kLong && scalarType != kByte) { throw std::runtime_error("tensors used as indices must be long or byte tensors"); } } } } </ins> static std::vector<Tensor> expandByteTensors(const Tensor & self, TensorList indices) { // Expands byte tensors (masks) into the equivalent indexing by LongTensors std::vector<Tensor> result;

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: