text:
meta device issue with float8 delayed scale

repro:
CONFIG_FILE="./train_configs/llama3_8b.toml" ./run_llama_train.sh --float8.enable_float8_linear --float8.enable_fsdp_float8_all_gather --float8.scaling_type_weight "delayed" --metrics.log_freq 1 --training.steps 3 --checkpoint.enable_checkpoint --checkpoint.interval 2

  traceback : Traceback (most recent call last):
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/distributed/elastic/multiprocessing/errors/__init__.py", line 355, in wrapper
      return f(*args, **kwargs)
    File "/data/users/weif/torchtitan/train.py", line 301, in main
      pred = model(input_ids)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1736, in _wrapped_call_impl
      return self._call_impl(*args, **kwargs)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1844, in _call_impl
      return inner()
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1790, in inner
      result = forward_call(*args, **kwargs)
    File "/data/users/weif/torchtitan/torchtitan/models/llama/model.py", line 439, in forward
      h = layer(h, self.freqs_cis)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1736, in _wrapped_call_impl
      return self._call_impl(*args, **kwargs)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1844, in _call_impl
      return inner()
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1769, in inner
      args_kwargs_result = hook(self, args, kwargs)  # type: ignore[misc]
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/distributed/_composable/fsdp/_fsdp_state.py", line 67, in fsdp_hook_wrapper
      return torch._dynamo.disable(func, recursive=True)(*args, **kwargs)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/_dynamo/eval_frame.py", line 629, in _fn
      return fn(*args, **kwargs)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/distributed/_composable/fsdp/_fsdp_state.py", line 234, in _pre_forward
      args, kwargs = self._fsdp_param_group.pre_forward(module, args, kwargs)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/distributed/_composable/fsdp/_fsdp_param_group.py", line 314, in pre_forward
      self.unshard(self.unshard_async_op)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/distributed/_composable/fsdp/_fsdp_param_group.py", line 243, in unshard
      self._all_gather_result = foreach_all_gather(
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 116, in decorate_context
      return func(*args, **kwargs)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/distributed/_composable/fsdp/_fsdp_collectives.py", line 139, in foreach_all_gather
      param_all_gather_inputs = _get_param_all_gather_inputs(fsdp_params)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 116, in decorate_context
      return func(*args, **kwargs)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/distributed/_composable/fsdp/_fsdp_collectives.py", line 217, in _get_param_all_gather_inputs
      param_all_gather_inputs[i] = fsdp_param.all_gather_inputs
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/distributed/_composable/fsdp/_fsdp_param.py", line 702, in all_gather_inputs
      ) = sharded_local_tensor.fsdp_pre_all_gather(self.mesh_info.mesh)
    File "/data/users/weif/ao/torchao/float8/fsdp_utils.py", line 408, in fsdp_pre_all_gather
      float8_tensor = hp_tensor_to_float8_delayed(
    File "/data/users/weif/ao/torchao/float8/float8_scaling_utils.py", line 105, in hp_tensor_to_float8_delayed
      return hp_tensor_and_scale_to_float8(
    File "/data/users/weif/ao/torchao/float8/float8_tensor.py", line 254, in hp_tensor_and_scale_to_float8
      return _ToFloat8ConstrFunc.apply(
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/autograd/function.py", line 575, in apply
      return super().apply(*args, **kwargs)  # type: ignore[misc]
    File "/data/users/weif/ao/torchao/float8/float8_tensor.py", line 170, in forward
      tensor_scaled = tensor.to(torch.float32) * scale
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/_prims_common/wrappers.py", line 289, in _fn
      result = fn(*args, **kwargs)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/_prims_common/wrappers.py", line 141, in _fn
      result = fn(**bound.arguments)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/_refs/__init__.py", line 1064, in _ref
      output = prim(a, b)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/_refs/__init__.py", line 1671, in mul
      return prims.mul(a, b)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/_ops.py", line 723, in __call__
      return self._op(*args, **kwargs)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/_library/fake_impl.py", line 95, in meta_kernel
      return fake_impl_holder.kernel(*args, **kwargs)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/_library/utils.py", line 20, in __call__
      return self.func(*args, **kwargs)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/library.py", line 1190, in inner
      return func(*args, **kwargs)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/_library/custom_ops.py", line 614, in fake_impl
      return self._abstract_fn(*args, **kwargs)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/_prims/__init__.py", line 402, in _prim_elementwise_meta
      utils.check_same_device(*args_, allow_cpu_scalar_tensors=True)
    File "/home/xxx/.conda/envs/pytorch-3.10/lib/python3.10/site-packages/torch/_prims_common/__init__.py", line 742, in check_same_device
      raise RuntimeError(msg)
  RuntimeError: Tensor on device meta is not on the expected device cuda:1!

cc @vkuzo

without debugging, my guess would be something like:

model is created on device meta
checkpoint is loaded with device cuda, but it does not have the extra buffers for delayed scaling

I can take a look next week, unless someone gets to it faster

checkpoint is loaded with device cuda, but it does not have the extra buffers for delayed scaling

if running the repo for the 1st time, torchtitan/output/checkpoint folder will be empty. the model won't load checkponits but the error is still there. We do meta init and call init_weights to move model from meta to cuda. buffers for delayed scaling might need some treatment

I can take a look next week, unless someone gets to it faster

thanks!

I see, then this line is relevant: https://github.com/pytorch/ao/blob/e85c1a318b06bbdb3b8c7f92f3257999864446b0/torchao/float8/float8_linear.py#L648
We'll have to think if we can figure out to do this automatically without introducing one more API.  If not, we'll have to design such as API.

sounds plausible.

I see, then this line is relevant: https://github.com/pytorch/ao/blob/e85c1a318b06bbdb3b8c7f92f3257999864446b0/torchao/float8/float8_linear.py#L648
We'll have to think if we can figure out to do this automatically without introducing one more API. If not, we'll have to design such as API.

I see. it sounds plausible

I really don't love this solution, but we could do something like this: https://github.com/pytorch/ao/pull/1292.  Thoughts?

I really don't love this solution, but we could do something like this: pytorch/ao#1292. Thoughts?

thanks for the fix!

opening as the fix isn't landed yet :)

authors: vkuzo weifengpy

repo: pytorch/torchtitan


text:
Add nightly CI for pytorch nightly

Would be good to support latest pytorch nightlies so we're not surprised when pytorch version updates. Should add some CI that runs w / pytorch nightly in addition to the pytorch existing CI.

Resolved by #663

source: gharchive/issue

authors: joecummings rohan-varma

repo: pytorch/torchtune

license_type: permissive

license_source: github-api


text:
Add QAT support for distributed finetuning

Summary: This commit adds the option to run quantization-aware training (QAT) during finetuning. QAT refers to "fake quantizing" the weights and activations during training, which performs the following transformation on the inputs but still keeps all intermediate values in floating point:
x_q = clamp((x_bf16 / scale) + zp)
x_fq = (x_q - zp) * scale

Currently only 8-bit per token dynamic activations + 4-bit grouped per channel weights (8da4w) is supported. Users can enable this by specifying a QAT quantizer in their config files:
tune run --nnodes 1 --nproc_per_node 8 full_finetune_distributed \
  --config llama3/8B_full \
  quantizer._component_=torchtune.utils.quantization.Int8DynActInt4WeightQATQuantizer \
  quantizer.groupsize=256 \
  qat_enable_fake_quant_step=1000

# or add this to your config file
# quantizer:
#   _component_: torchtune.utils.quantization.Int8DynActInt4WeightQATQuantizer
#   groupsize: 256

Test Plan:
Initial results for Llama2 demonstrate that QAT is able to recover the loss in accuracy from quantization by about half for some tasks (last two rows):

hellaswag

wikitext

arc_easy

arc_challenge

acc
acc_norm
word_perplexity
byte_perplexity
bits_per_byte
acc
acc_norm
acc
acc_norm

No quant
59.659%
76.927%
12.183
1.596
0.674
76.010%
72.054%
48.720%
47.867%

PTQ
57.150%
74.945%
12.995
1.615
0.692
75.968%
70.118%
46.416%
45.904%

QAT
58.504%
76.170%
12.199
1.596
0.675
76.431%
71.928%
47.184%
48.123%

PTQ degradation
-2.509%
-1.982%
+0.812
+0.019
+0.018
-0.042%
-1.936%
-2.304%
-1.963%

QAT degradation
-1.155%
-0.757%
+0.016
+0.000
+0.001
0.421%
-0.126%
-1.536%
0.256%

By the way, the tests are failing due to torchtune's dependency on an old version of torchao, which doesn't have QAT support yet. We're about to release 0.2.0 on the torchao side (aiming early next week), so the tests won't pass until then.

Hi @kartikayk, thanks for the comments, responding inline:

Do we plan on adding other quantization methods? Or whats the long term support plan for this?
Yes, in the long term we do plan to support other QAT configurations (e.g. 2- or 3-bit weight only if we can get good results), that's why I kept the quantizer specification general.

We need a lot of documentation here to make sure users understand what this actually means. Is this reasonably well understood by the general audience? for example, I'm not sure about all of the details here. We also need to consider how to lower the bar for adopotion here. I think this needs a tutorial or a deepdive added to the torchtune docs.

For sure. Should I add the README in this PR and add the tutorial separately?

Hi @kartikayk, thanks for the comments, responding inline:

Do we plan on adding other quantization methods? Or whats the long term support plan for this?

Yes, in the long term we do plan to support other QAT configurations (e.g. 2- or 3-bit weight only if we can get good results), that's why I kept the quantizer specification general.

We need a lot of documentation here to make sure users understand what this actually means. Is this reasonably well understood by the general audience? for example, I'm not sure about all of the details here. We also need to consider how to lower the bar for adopotion here. I think this needs a tutorial or a deepdive added to the torchtune docs.

For sure. Should I add the README in this PR and add the tutorial separately?

Should I add the README in this PR and add the tutorial separately?

I think a tutorial/deep-dive in the docs would be really helpful. You can add some details on what the quantization methods mean as well - I think this will be very useful and make the flow more noob friendly.
Here are some pointers:

Example PR with a tutorial (checkout the e2e_flow.rst file): https://github.com/pytorch/torchtune/pull/690/files and this with the LoRA tutorial: https://github.com/pytorch/torchtune/pull/368
Working with the live docs in torchtune: https://github.com/pytorch/torchtune/blob/main/CONTRIBUTING.md#building-docs

I don't mind this as a follow up.
@ebsmothers let me know if you have differing thoughts on this.

Thanks for the PR! I think I'm in agreement with most everything that's been said already: (1) separate recipe for QAT (I agree this will make it easier to scale once we add other quant techniques anyways) and (2) add some kind of tutorial but as a follow-up (also happy to provide any pointers or guidance you need in advance).

Update: I think I've addressed all the comments and this PR is ready from my side. Do you have other comments @ebsmothers @kartikayk?
Note that landing is blocked right now on the torchao 0.3 release (currently scheduled for 6/26). This is because QAT was only added in torchao 0.2, but the following error was not fixed until torchao 0.3, so there's no other way to get the QAT feature unless we want to rely on nightlies, which we don't.
  File "/__w/_temp/conda_environment_9553124795/lib/python3.8/site-packages/torchtune/modules/common_utils.py", line 12, in <module>
    from torchao.dtypes.nf4tensor import NF4Tensor
  File "/__w/_temp/conda_environment_9553124795/lib/python3.8/site-packages/torchao/__init__.py", line 14, in <module>
    from . import _C
ImportError: /__w/_temp/conda_environment_9553124795/lib/python3.8/site-packages/torchao/_C.cpython-38-x86_64-linux-gnu.so: undefined symbol: _ZN5torch3jit11parseSchemaERKSs

Codecov Report
Attention: Patch coverage is 8.95522% with 244 lines in your changes missing coverage. Please review.

Project coverage is 25.91%. Comparing base (52e3283) to head (c110f45).
Report is 1 commits behind head on main.

Files
Patch %
Lines

recipes/qat_distributed.py
0.00%
212 Missing :warning:

tests/recipes/test_qat_distributed.py
48.57%
18 Missing :warning:

torchtune/utils/quantization.py
46.15%
7 Missing :warning:

recipes/quantize.py
0.00%
5 Missing :warning:

tests/recipes/test_configs.py
33.33%
2 Missing :warning:

:exclamation:  There is a different number of reports uploaded between BASE (52e3283) and HEAD (c110f45). Click for more details.
HEAD has 2 uploads less than BASE
| Flag | BASE (52e3283) | HEAD (c110f45) |
|------|------|------|
||4|2|

Additional details and impacted files
@@             Coverage Diff             @@
##             main     #980       +/-   ##
===========================================
- Coverage   66.69%   25.91%   -40.79%
===========================================
  Files         184      186        +2
  Lines        8578     8822      +244
===========================================
- Hits         5721     2286     -3435
- Misses       2857     6536     +3679

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

source: gharchive/pull-request

authors: andrewor14 codecov-commenter ebsmothers kartikayk


text:
Incorrect accuracy for ImageNet pretrain model

In the documentation, it says resnet50 has the error rate of 23.85, that is, the accuracy of 76.15. However, after running the test script here, I get the accuracy of 76.13.
Other models are not tested. But obviously, there are inconsistencies here.

I've just re-run this model using the reference scripts and I indeed got the same results as you, 76.13. I've tried running with and without benchmark mode in cudnn, as well as without cudnn, and all gave the same result.
The question now is if this was a small typo when @colesbury added the numbers in https://github.com/pytorch/vision/pull/94, or if there are some small numerical differences between the implementation somewhere that affects the results?
cc @soumith

This has been fixed in https://github.com/pytorch/vision/pull/3360

authors: fmassa youkaichao

repo: pytorch/vision


text:
Add unittest job to CircleCI

Remove unittest from conda build, and add them as independent unittest jobs.
So unittests will not triggered at every conda build and test in an independent test env.
test at https://github.com/pytorch/vision/pull/2332

Generally LGTM, please remember to remove the windows legacy build jobs and its job spec.

thank you, they have been moved.

Thanks for the PR!
I think that we might now be missing our single CUDA CI that was effectively running CUDA tests, which was torchvision_linux_py3.8_cu102_cuda . So we would need to add back a CUDA CI test before we can merge this, otherwise we won't be able to check for CUDA correctness (now it only compiles torchvision, but doesn't run any tests).
@seemethere could you also have a look?

Do you mean to run unit tests with CUDA? There is already one named unittest_linux_gpu that is testing with CUDA 10.1. Or you just want to add one for CUDA 10.2? I don't think we should run tests through conda-build anymore. It's just a waste of time.

@peterjc123

There is already one named unittest_linux_gpu that is testing with CUDA 10.1.

I might be missing something, but the CI is not running any test named unittest_*_gpu I believe?

@fmassa They run only on master. Maybe we should make them run in PRs.

They run only on master. Maybe we should make at least one of them run in PRs, right?

Yes, they should run in PRs as well. I see that it has been updated now, thanks!

Maybe we don't need all CUDA tests running on every PR (would be expensive?), but only a small subset -- before we only had one CI running CUDA tests on Linux and Windows, maybe we could keep the same here?
cc @seemethere for thoughts

Maybe we don't need all CUDA tests running on every PR (would be expensive?), but only a small subset -- before we only had one CI running CUDA tests on Linux and Windows, maybe we could keep the same here?
cc @seemethere for thoughts

if we only put unittest_gpu_py3.8 on pr and others on master?

@guyang3532

if we only put unittest_gpu_py3.8 on pr and others on master?

That sounds good to me, although I would also put unittest_windwos_gpu_py3.8 on every PR as well


text:
[WIP] Transforms documentation clean-up

A documentation clean-up that concerns transform.py functional.py functional_pil.py functional_tensor.py for issue #3071.
@datumbox After some initial checking, there are somethings I'm not certain:

Does the Sequence type represent only list and tuple in torchvision? I find that in Python other types (e.g. strings) can also count as a Sequence. Maybe we should clear it up in the docs, like maybe just say list or tuple.
Does the Posterize operation also only support uint8 images in PIL? I'm inclined to add "only support L or RGB" to all related transforms like I did with invert(). But maybe we can just let PIL throw the OSError.
Should we also add "This transform supports both PIL and Tensor, ..." in the documentation for AutoAugment as well?
Maybe we could delete the private function docs, as mentioned by @vfdev-5 here.

And there are some other things I found after cleaning the docs up, maybe they can be addressed in the future:

In Pad (or RandomCrop, it also uses padding), it seems tensors only support single value fill. Also I'm not sure whether str is really needed here by PIL, what is the use case here?
Some type checking is also Sequence, maybe we should check explicitly for tuple and list. Or is this the intended implementation?

To add on @vfdev-5:

Does the Posterize operation also only support uint8 images in PIL? I'm inclined to add "only support L or RGB" to all related transforms like I did with invert(). But maybe we can just let PIL throw the OSError.

Yes it's only supported in PIL when the image is uint8. In this case it's important to clarify to the users that the tensor should be of data type uint8. Currently an image can be RGB but represented as floats. If that's the case, the transform won't work.

Should we also add "This transform supports both PIL and Tensor, ..." in the documentation for AutoAugment as well?

Not necessary because supporting a transform in both backends is our default. We only specific when something is not supported in any of the two backends.

Not necessary because supporting a transform in both backends is our default. We only specific when something is not supported in any of the two backends.

Maybe we should remove that support both backend statement for other docs as well?

Yes, sequence is also a string. I'd say here it is implicitly assumed that string input for, for example, size="abc" is completely wrong... also isinstance(size, Sequence) is a bit shorter then isinstance(size, (list, tuple)).

Does that need to be like unified in the doc to use sequence everywhere or int and tuple everywhere? @vfdev-5

Yes, sequence is also a string. I'd say here it is implicitly assumed that string input for, for example, size="abc" is completely wrong... also isinstance(size, Sequence) is a bit shorter then isinstance(size, (list, tuple)).

Does that need to be like unified in the doc to use sequence everywhere or int and tuple everywhere? @vfdev-5

Yes, in the docs it is nice to unify the type description. In the code this may be not possible due to torchscript...

Yes, in the docs it is nice to unify the type description. In the code this may be not possible due to torchscript..

I agree. Torchscript might give you headaches. Perhaps ensure that our doc is consistent everywhere using Sequences in this PR and follow up with the proposed changes on another one if TorchScript plays nice?

I made some further changes based on above reviews. Let me know if I forgot something or got something wrong!
@vfdev-5 @datumbox
Also TODOs in future PRs maybe:

Try check only for number and sequence in the code.
Try unify tensor and PIL Image in pad().

@voldemortX Apologies if I was not very clear. It's not our intention to mark the specific files with underscores at this point.
A very bad side-effect of doing so is we lose the entire git-blame history, so such changes need to be justified. Please revert the name change and I'll check again your PR once it's done.

Sorry... Should I revert all commits?

Sorry... Should I revert all commits after 08fba9b?

No worries mate. :) You can just undo the filename change in a new commit or revert the specific commit or however else you prefer. When we merge the PRs, the history is squashed so there will be no side-effects on master.

@datumbox Is this new commit ok?

After seeing this issue #3206 , we might need to also clarify the doc for erase(). I think it does support batch input (although the same randomness across the whole batch) right?

Yes it does but the input needs to be a tensor, not a PIL image.

authors: datumbox vfdev-5 voldemortX


text:
Partioner to support more data types

Partitioner currently supports CSV. We need to extend the mechanism to make it more generic and support other implementations, like Apache Parquet

WIP

repo: pywren/pywren-ibm-cloud


text:
最后的效果没有代码吗？？？？？？

最后的效果没有代码吗？？？？？？优惠券

没有。这是使用在其他项目上的效果，你自己调整一下颜色属性就好了。demo是其他两张图的效果

没有最后一张的效果，还以为都有呢

license_source: bigquery


text:
🛑 nitter.lunar.icu is down

In fd3d4c2, nitter.lunar.icu (https://nitter.lunar.icu) was down:

HTTP code: 0
Response time: 0 ms

Resolved: nitter.lunar.icu is back up in 881ca03 after 23 minutes.

license: MIT


text:
🛑 nitter.projectsegfau.lt is down

In 47e7270, nitter.projectsegfau.lt (https://nitter.projectsegfau.lt) was down:

HTTP code: 503
Response time: 383 ms

Resolved: nitter.projectsegfau.lt is back up in 062cdec after 1 hour, 9 minutes.


text:
🛑 nitter.cutelab.space is down

In 9167180, nitter.cutelab.space (https://nitter.cutelab.space) was down:

HTTP code: 0
Response time: 0 ms

Resolved: nitter.cutelab.space is back up in 78ba512 after 53 minutes.


text:
🛑 nitter.sethforprivacy.com is down

In 0107736, nitter.sethforprivacy.com (https://nitter.sethforprivacy.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: nitter.sethforprivacy.com is back up in c844735.


text:
🛑 notabird.site is down

In 77719fa, notabird.site (https://notabird.site) was down:

HTTP code: 520
Response time: 68 ms

Resolved: notabird.site is back up in 9a33dfd.


text:
🛑 notabird.site is down

In d62fbb7, notabird.site (https://notabird.site) was down:

HTTP code: 520
Response time: 71 ms

Resolved: notabird.site is back up in 6091363.


text:
🛑 notabird.site is down

In f0a4bfa, notabird.site (https://notabird.site) was down:

HTTP code: 520
Response time: 84 ms

Resolved: notabird.site is back up in 767135d after 53 days, 48 minutes.


text:
🛑 nitter.tiekoetter.com is down

In 132146c, nitter.tiekoetter.com (https://nitter.tiekoetter.com) was down:

HTTP code: 502
Response time: 903 ms

Resolved: nitter.tiekoetter.com is back up in ad0b434 after 54 days, 4 hours, 34 minutes.


text:
🛑 notabird.site is down

In 1b4987b, notabird.site (https://notabird.site) was down:

HTTP code: 520
Response time: 109 ms

Resolved: notabird.site is back up in 2ef4b90 after 32 minutes.


text:
🛑 notabird.site is down

In 6ee23fc, notabird.site (https://notabird.site) was down:

HTTP code: 520
Response time: 76 ms

Resolved: notabird.site is back up in 3dea095.


text:
🛑 nitter.us.projectsegfau.lt is down

In 2d6d737, nitter.us.projectsegfau.lt (https://nitter.us.projectsegfau.lt) was down:

HTTP code: 0
Response time: 0 ms

Resolved: nitter.us.projectsegfau.lt is back up in 0122947 after 1 hour, 4 minutes.


text:
Issue #1021: replace hub_mode

replaced hub_mode by optional capabilities.provider

@candelaripoli, your code can't be compiled:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) on project carina-utils: Compilation failure: Compilation failure:
[ERROR] /opt/jenkins/workspace/carina/onPullRequest-carina/carina-utils/src/main/java/com/qaprosoft/carina/core/foundation/utils/Configuration.java:[28,70] package com.qaprosoft.carina.core.foundation.webdriver.core.capability does not exist
[ERROR] /opt/jenkins/workspace/carina/onPullRequest-carina/carina-utils/src/main/java/com/qaprosoft/carina/core/foundation/utils/Configuration.java:[551,40] cannot find symbol
[ERROR]   symbol:   class CapabilitiesLoader
[ERROR]   location: class com.qaprosoft.carina.core.foundation.utils.Configuration
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :carina-utils

authors: candelaripoli vdelendik

repo: qaprosoft/carina


text:
Product Maintenance: deselecting a product still allows archiving

Is your feature request related to a problem? Please describe.
After a product has been deselected it is still possible to archive this product.
Describe the solution you'd like
Deselecting should "reset" the selection and therefore not allow to archive the previously selected product. Maybe introduce an optional to account for deselection events.

 Product Maintenance: deselecting a product still allows archiving #547


text:
Add report question button

In case there are any issues with certain questions (e.g. missing answer, only one sentence for the question)

Make the report question button open a modal providing different options, including:

Incorrect category / subcategory
Missing / incorrectly formatted question / answer
Incorrectly parsed my answer

repo: qbreader/website


text:
save_screenshot does not overwrite screenshot.png

Describe the bug
ClickIcon makes comparison against screenshot.png.
However this only works once as save_screenshot is not overwriting screenshot.png when new is taken but renames those as screenshot_000, etc.. If there is multiple Icon related keywords in test suite those latter ones are failing because of this.
I believe this only happens in Linux and is pyautogui/scrot -related issue with newer Python versions (at least i haven't noticed it before with older versions).

Hi,
Thanks for reporting this. I may not understand the use case fully. Can you elaborate it a bit? Any snippet of script that could reproduce this?
Best regards,
Tuomas

I dont have log (this came from customer) and it's already fixed using workaround but i am trying to explain:
We have script like this:
ClickIcon   some_image
Do something else
ClickIcon   some_other_image
Now when we reach that first ClickIcon it takes screenshot.png and after that makes comparision if screenshot.png matches to some_image = all is good.
Problem appears when we reach ClickIcon some_other_image. It again takes screenshot, but as we already have screenshot.png in our folder it names this new one to screenshot_000.png instead of overwriting screenshot.png. However comparision is still made against screenshot.png, which in this case is obviously wrong picture and we are getting Fail.

I believe combination where this happened was Ubuntu, Python 3.7 or 3.8 and newest QWeb

Ok, thanks for the clarification. Sounds weird, but we'll debug this.

Could not repro this with Ubuntu and python 3.7/3.8. Turns out you need a newer scrot version which is included in Ubuntu 20; the default operation of scrot is different.
Since this is not yet fixed in pyautogui, we fixed this by removing the file. Fix should be included in release 1.0.5 later this week.

authors: mikalindh tkoukkari

repo: qentinelqi/qweb


text:
UnblockNeteaseMusic Settings?

Is there anywhere i can put my server ip and port to use my self-hosted unblockneteasemusic ?

是自带的UnblockMusic用不了吗？

是自带的UnblockMusic用不了吗？

Yes, VIP Music isn't playable for me, i'm from overseas

Yes, VIP Music isn't playable for me, i'm from overseas

我刚刚测试了下，在开启全局代理的情况下，测试了发现可以正常解锁VIP歌曲。
你关掉UnblockMusic服务再试试看？

我刚刚测试了下，在开启全局代理的情况下，测试了发现可以正常解锁VIP歌曲。
你关掉UnblockMusic服务再试试看？

Yes, VIP Music isn't playable for me, i'm from overseas

https://github.com/qier222/YesPlayMusic/issues/115#issuecomment-770158353

Yes, VIP Music isn't playable for me, i'm from overseas

https://github.com/qier222/YesPlayMusic/issues/115#issuecomment-770158353

authors: HatsuneMona qier222 zzinggame


text:
Publish qirlib to crates.io

We should consider publishing qirlib so that Rust users can more easily depend on it. Some things to consider:

API review.
A more recent version of Inkwell needs to be published first.

Yes please! +100 to this one :)

repo: qir-alliance/pyqir


text:
最大key加载量为2w，可以提高下最大key加载量吗

OS
mac os
VERSION
1.5.9
ISSUE DESCRIPTION
目前key的最大加载量只能设置为2w，可以提高下key大数量限制么

如果为了直接显示出所有key的话，可以直接点击“加载更多” 旁边的 “加载全部”按钮即可

可以谢谢，但是有时候还是在操作上会有点误解。
因为它的key感觉是随机缺少的，如果能提高key的最大数量限制就更好了。

authors: qishibo tanchichong

repo: qishibo/AnotherRedisDesktopManager


text:
Add fswap gate

Add apply_fswap_gate function to python/ffsim/gates/basic_gates.py.
This gate swaps two fermionic modes. Under the Jordan-Wigner transform, this gate has the following matrix when applied to neighboring qubits:
[[1, 0, 0, 0]
 [0, 0, 1, 0]
 [0, 1, 0, 0]
 [0, 0, 0, -1]

It looks like it can be implemented with a combination of tunneling_interaction, num_interaction, and num_num_interaction. Maybe there is a smarter way.

Actually, I think it can be implemented with a single call to apply_orbital_rotation. Swapping modes i and j corresponds to an orbital rotation described by the identity matrix with columns i and j swapped.

repo: qiskit-community/ffsim


text:
Update Sphinx theme

Summary
Updates to new Ecosystem theme.

Pull Request Test Coverage Report for Build 6301640619

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 77.632%

Totals

Change from base Build 6122556618:
0.0%

Covered Lines:
118

Relevant Lines:
152

💛  - Coveralls

How does this relate to #40?

@mrossinek: This project is being taken over by @arnaucasau, I'll close the other PR

Since this takes over from #40 but that was still a draft, should this also be considered a draft or is this actually good to go? I do not know if you have any timeline in mind/want to sync this with some other documentation aspects or if this is decoupled and can be merged any time.

Sorry for the poor communication. Yes this PR is ready to be reviewed and can be merged at any time.

authors: arnaucasau coveralls frankharkins mrossinek

repo: qiskit-community/qiskit-nature-pyscf


text:
An error occurred downloading the database

Database building started at 2023-12-07 17:48:50.178062.
Reading NCBI taxonomy database... done.
Total number of TaxIDs: 2545202.
Reading RefSeq assembly summary... done.
Total number of genomes: 344111.
Genome categories: bacteria, archaea, fungi, viral, plant
Running Command: rsync --list-only --no-motd rsync://ftp.ncbi.nlm.nih.gov/genomes/refseq/
Downloading genome list per RefSeq category...
bacteria: 325433
archaea: 1889
fungi: 564
viral: 14992
plant: 175
Done.
Traceback (most recent call last):
File "/home/lx_sky6/software/miniconda3/envs/neoHGT/lib/python3.11/site-packages/pandas/core/indexes/base.py", line 3652, in get_loc
return self._engine.get_loc(casted_key)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "pandas/_libs/index.pyx", line 147, in pandas._libs.index.IndexEngine.get_loc
File "pandas/_libs/index.pyx", line 176, in pandas._libs.index.IndexEngine.get_loc
File "pandas/_libs/hashtable_class_helper.pxi", line 7080, in pandas._libs.hashtable.PyObjectHashTable.get_item
File "pandas/_libs/hashtable_class_helper.pxi", line 7088, in pandas._libs.hashtable.PyObjectHashTable.get_item
KeyError: '# assembly_accession'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/lx_sky6/yt/soft/neoHGT/scripts/neoHGT", line 88, in
main()
File "/home/lx_sky6/yt/soft/neoHGT/scripts/neoHGT", line 27, in main
module(args)
File "/home/lx_sky6/software/miniconda3/envs/neoHGT/lib/python3.11/site-packages/neoHGT-2.0b3-py3.11.egg/neoHGT/database.py", line 153, in call
self.retrieve_categories()
File "/home/lx_sky6/software/miniconda3/envs/neoHGT/lib/python3.11/site-packages/neoHGT-2.0b3-py3.11.egg/neoHGT/database.py", line 393, in retrieve_categories
self.df = self.df[self.df['# assembly_accession'].isin(asmset)]
~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/lx_sky6/software/miniconda3/envs/neoHGT/lib/python3.11/site-packages/pandas/core/frame.py", line 3761, in getitem
indexer = self.columns.get_loc(key)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/lx_sky6/software/miniconda3/envs/neoHGT/lib/python3.11/site-packages/pandas/core/indexes/base.py", line 3654, in get_loc
raise KeyError(key) from err
KeyError: '# assembly_accession'

Am also getting this issue, if you got any solution, please share here

Am also getting this issue, if you got any solution, please share here

Hi @zzlzef The issue was fixed in the master branch. If you update HGTector with:
pip install git+https://github.com/qiyunlab/HGTector.git

It should work. Thanks!

authors: Mohsin0911 qiyunzhu taotaoyuan zzlzef

repo: qiyunlab/HGTector


text:
ImageNet pre-trained weights link

could you give the ImageNet pre-trained weights link, thanks.

[https://github.com/qjadud1994/Text_Detector/blob/master/Pytorch/weights/readme.md](click here)

@qjadud1994 is tensorflow version also available? thx


text:
Test Issue - ssodf

Test Body - owvsazstst

Test Comment - ckheq

repo: qlikqaa/dummyrepo


text:
Test Issue - btthy

Test Body - sncrvxlfps

Test Comment - wxrsp


text:
Test Issue - sqioa

Test Body - gwavrmczou

Test Comment - mqscf


text:
Test Issue - tlybn

Test Body - cyikhyffnw

Test Comment - uhjbz


text:
Test Issue - biocy

Test Body - ovyhwbsfzt

Test Comment - frwuq


text:
Test Issue - toikb

Test Body - ymbgqylaez

Test Comment - wqslo


text:
Test Issue - httfj

Test Body - zjsuojxyvj

Test Comment - znlfs


text:
Test Issue - jzciy

Test Body - wlaaswruqn

Test Comment - scshi


text:
Test Issue - irsrq

Test Body - fdvmhkclvc

Test Comment - jsjkn


text:
Test Issue - fnvji

Test Body - uxrtxazvye

Test Comment - rpcnq


text:
Test Issue - cklwk

Test Body - apwkcqvfec

Test Comment - bznfj


text:
Test Issue - bqvyo

Test Body - sgtnfexpaq

Test Comment - fpahm


text:
Test Issue - gntmw

Test Body - snrnwgglqr

Test Comment - cqcpa


text:
Test Issue - jhjso

Test Body - nzkmydesrs

Test Comment - hujti


text:
Test Issue - yrcka

Test Body - nmlkzpemwi

Test Comment - eevwg


text:
Test Issue - uwzqq

Test Body - cnwfzphwfa

Test Comment - gdygv


text:
Test Issue - uckvq

Test Body - kboqbdolap

Test Comment - hflks


text:
Test Issue - pvihl

Test Body - xfdezofvof

Test Comment - gheng


text:
Test Issue - zledq

Test Body - tomsdemyjk

Test Comment - wyiah


text:
Test Issue - xskxc

Test Body - fecygldmzi

Test Comment - prbqe


text:
Test Issue - mtuop

Test Body - fjnscslfmy

Test Comment - nealm


text:
Test Issue - mdkov

Test Body - isxfcnptpw

Test Comment - cevmy


text:
Test Issue - mwphz

Test Body - bjsnvzhiuk

Test Comment - nivqk


text:
Test Issue - zpkmn

Test Body - tfotqbjmhn

Test Comment - erbmd


text:
Test Issue - rofwy

Test Body - ommmhtqdob

Test Comment - cbjga


text:
Test Issue - onawr

Test Body - eqzktksvur

Test Comment - nstbe


text:
Test Issue - pwvlz

Test Body - whbyggfzhr

Test Comment - cpnrq


text:
Test Issue - mlkkp

Test Body - dtjoulzmch

Test Comment - bmgza


text:
Test Issue - rmhnc

Test Body - iwhhrjnpkg

Test Comment - jcymd


text:
Pages blank on direct links

If you try to link directly to a page say http://page:10000/dhcpd/list_leases.cgi it will show a blank page, however the source of the page has all of the content.
This breaks features which redirect you such as the setting to change user password at first login.
Please see the attached link:
http://imgur.com/a/BHiSR
Latest version of Webmin & Theme.

Actually it was targeted in the latest release, 17.80. Cab you make the screenshot of the sourse starting from the top?

http://pastebin.com/GrPDJ69M
or

You've upgraded, right. 17.80 solves this issue.

I'm sorry - you're right, you must have just released this?!
All is working :) Amazing. Thank you.

Yes, couple of hours ago.
Thanks, you're welcome.

Hello!
I have installed version 17.84 of this version and I have exactly same problem. Blank page after login and I can only navigate using urls.

You must hard reload browser's cache manually. It will be done automatically again in 17.85+.

authors: Reverze qooob zackoch

repo: qooob/authentic-theme


text:
Crash when loading into a world with Optifine 1.16.1 G2

On Forge 32.0.98 with Optifine G2 and Immersive Portals 0.24 I crash when trying to load into a world.
Forge Crash.txt
I get roughly the same crash with Fabric 0.8.9, Immersive Portals 0.24, Optifabric 1.1.0  and Optifine G2
Fabric Crash.txt

OptiFine is incompatible with Immersive Portals.
The Fabric crash seems to be... completely unrelated to OptiFine, though?

About the fabric version crash, try to upgrade the fabric loader to the latest version

@Leo40Git As I tested Optifine g2 is compatible with this mod 0.24 fabric

Sorry, I think I attached the wrong crash for Fabric. I've edited it and re uploaded the correct one.

The solution is to turn off render regions

repo: qouteall/ImmersivePortalsMod


text:
Facing issue while converting Darknet YOLO model to keras model

I was trying to convert A Darknet YOLO model to keras model using convert.py file. using the following command:
python3 convert.py yolov3.cfg yolov3.weights model_data/yolo.h5
the command gives following output and does not produce any yolo.h5 file
Using TensorFlow backend.
2020-05-01 21:11:18.581791: W tensorflow/stream_executor/platform/default/dso_loader.cc:55] Could not load dynamic library 'libnvinfer.so.6'; dlerror: libnvinfer.so.6: cannot open shared object file: No such file or directory; LD_LIBRARY_PATH: /usr/local/cuda-10.0/lib64
2020-05-01 21:11:18.581919: W tensorflow/stream_executor/platform/default/dso_loader.cc:55] Could not load dynamic library 'libnvinfer_plugin.so.6'; dlerror: libnvinfer_plugin.so.6: cannot open shared object file: No such file or directory; LD_LIBRARY_PATH: /usr/local/cuda-10.0/lib64
2020-05-01 21:11:18.581948: W tensorflow/compiler/tf2tensorrt/utils/py_utils.cc:30] Cannot dlopen some TensorRT libraries. If you would like to use Nvidia GPU with TensorRT, please make sure the missing libraries mentioned above are installed properly.
Loading weights.
Weights Header:  0 2 0 [32013312]
Parsing Darknet config.
Traceback (most recent call last):
  File "convert.py", line 262, in <module>
    _main(parser.parse_args())
  File "convert.py", line 85, in _main
    cfg_parser.read_file(unique_config_file)
  File "/usr/lib/python3.6/configparser.py", line 718, in read_file
    self._read(f, source)
  File "/usr/lib/python3.6/configparser.py", line 1080, in _read
    raise MissingSectionHeaderError(fpname, lineno, line)
configparser.MissingSectionHeaderError: File contains no section headers.
file: '<???>', line: 7
'<!DOCTYPE html>\n'

You need to install TensorRT 6. But you may need to do a few dependency checks like CUDA version.
https://docs.nvidia.com/deeplearning/tensorrt/install-guide/index.html#downloading

这是来自QQ邮箱的假期自动回复邮件。你好，我最近正在休假中，无法亲自回复你的邮件。我将在假期结束后，尽快给你回复。

You need to install TensorRT 6. You may need to do a few dependency checks like CUDA version.
https://docs.nvidia.com/deeplearning/tensorrt/install-guide/index.html#downloading

You need to install TensorRT 6. You may need to do a few dependency checks like CUDA version.
https://docs.nvidia.com/deeplearning/tensorrt/install-guide/index.html#downloading

Don't forget to do ldconfig after installations.

You need to install TensorRT 6. BUT you may need to do a few dependency checks like CUDA version.

You need to install TensorRT 6. BUT you may need to do a few dependency checks like CUDA version.

You need to install TensorRT 6. BUT you may need to do a few dependency checks like CUDA version.
Nvidia Pages

You need to install TensorRT 6. BUT you may need to do a few dependency checks like CUDA version.
https://docs.nvidia.com/deeplearning/tensorrt/install-guide/index.html#downloading


text:
🛑 Testamentaria is down

In a2d254c, Testamentaria (https://testamentaria.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Testamentaria is back up in 5562969.

repo: qtekfun/upptime


text:
🛑 hako.re is down

In 2e8a58a, hako.re (https://mangochan.site/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: hako.re is back up in 39cf270.


text:
🛑 kokocon is down

In b8ae229, kokocon (http://kokocon.net/) was down:

HTTP code: 500
Response time: 217 ms

Resolved: kokocon is back up in 72b3b08 after 7 minutes.


text:
🛑 otakusan is down

In f5d299c, otakusan (https://otakusan.net/LightNovel) was down:

HTTP code: 0
Response time: 0 ms

Resolved: otakusan is back up in f9d186b after 9 minutes.


text:
🛑 otakusan is down

In c10d75e, otakusan (https://otakusan.net/LightNovel) was down:

HTTP code: 0
Response time: 0 ms

Resolved: otakusan is back up in 2b0e531 after 13 minutes.


text:
404 on model, relative values and user pages

Fixes #1947.

https://quri-hub-git-hub-404-quantified-uncertainty.vercel.app/users/notfound
https://quri-hub-git-hub-404-quantified-uncertainty.vercel.app/users/berekuk/models/notfound
https://quri-hub-git-hub-404-quantified-uncertainty.vercel.app/users/berekuk/relative-values/notfound

repo: quantified-uncertainty/squiggle


text:
Update pandas version

Description
According to https://github.com/quantumblacklabs/kedro/blob/master/setup.py#L41 Kedro requires pandas>=0.24, <1.0.4 due to this issue. According to https://github.com/pandas-dev/pandas/issues/34467#issuecomment-644069002 this issue has been fixed.
Context
pandas 1.0.3 causes a dependency with Modin, which requires v1.0.5. This has been causing me trouble with conda environment solving, and prints ugly errors from Modin or Kedro.

Shared dependencies with issue https://github.com/quantumblacklabs/kedro/issues/489  if upgrading to pandas 1.1.0. Independent if upgrading to 1.0.5.

@JMBurley I'm kinda amazed that you reported #489 less than 1 minute after I reported this
(closing as duplicate)

authors: JMBurley crypdick

repo: quantumblacklabs/kedro


text:
kedro.io.core.DataSetError: Failed while saving data to data set MemoryDataSet(). can't pickle _thread.RLock objects

Description
Context
I have an experiment session class that need to pass in every steps of the pipeline to log my model metrics etc. But I get an error
kedro.io.core.DataSetError: Failed while saving data to data set MemoryDataSet().
can't pickle _thread.RLock objects

Steps to Reproduce
Repository: https://github.com/noklam/kedro_pickle_bug

from trains import Task

def init_exp_logger():
    task = Task.init(project_name="demo_bug", task_name="demo_bug", output_uri=None)
    return task

def dummy_function(exp_logger):
    print("dummy")

def create_pipeline(**kwargs):
    return Pipeline([
        node(
            func=init_exp_logger,
            inputs=None,
            outputs="exp_logger",
            name="init_exp_logger",
        ),
        node(
            func=dummy_function,
            inputs="exp_logger",
            outputs=None,
            name="dummy_function`",
        ),]
    )

Your Environment
Include as many relevant details about the environment in which you experienced the bug:

Kedro version used (pip show kedro or kedro -V): 0.16.5
Python version used (python -V): 3.7.5
Operating system and version: Window 10

Hi! https://github.com/noklam/kedro_pickle_bug seems to be an empty repo, but I think I know what might cause this. By default MemoryDataSet tries to deepcopy on save/load https://github.com/quantumblacklabs/kedro/blob/master/kedro/io/memory_data_set.py#L84, and I think one of your input/output are not serialisable (e.g Tensorflow object etc.). You can modify the copy_mode in MemoryDataSet as described in https://kedro.readthedocs.io/en/stable/10_tools_integration/01_pyspark.html?#use-memorydataset-with-copy-mode-assign-for-non-dataframe-spark-objects I hope this helps :)

Closing this issue, but feel free to re-open it if you have any follow-up question :) There's a community-driven discourse page and you are more than welcome to join https://discourse.kedro.community/ :)

@921kiyo
Sorry for the late reply!  I use copy_mode : assign and it works. Is there any drawback if not using deepcopy?

Glad it worked :) We use deepcopy by default as a safeguard for not mutating the original data in memory. With assign, if you mutate an assigned list, it will change the original list. For example,
a = [1,2]
b = a
b[0] = 10
print(a) -> [10,2]


text:
Handle the case when on_stuck_return is a function returning None

#1083
Please check if you agree with the argument type for on_stuck_raise. Is Union[None, X] or Optional[X] preferred by the way?

I prefer Optional[X] but not enough to consider it a problem.

Automerge: started

authors: CirqBot Strilanc andbe91

repo: quantumlib/Cirq


text:
Add {Frozen}Circuit.from_moments to construct circuit by moments.

In our internal code almost all circuits are constructed with explicit moments rather than using an insertion strategy because we want to control the alignment of ops. Here we add a from_moments classmethod on Circuit and FrozenCircuit which takes any number of OP_TREE args and converts each one to a Moment in the resulting circuit. This gives a convenient way to construct circuits without cluttering the code with multiple calls to Moment.
Also adds special cases in both the Circuit and FrozenCircuit constructors to handle constructing from a single circuit or a sequence of moments.

On another look, the Circuit and FrozenCircuit constructors work as desired in their initial shape when passed arguments that are all Moment-s.  I think we can do this by adding a single from_moments() method to the AbstractCircuit base without adding more branching and an extra mirrored code to Circuit and FrozenCircuit.  Please see eba2657cbedd6eca3dba55d7d06e583eceeff7a3...1c3368f266e2c0231a3843eac2f75cc6ccdb24fa.
These can be pulled in with
git pull https://github.com/pavoljuhas/Cirq.git pr5805-move-from_moments-to-AbstractCircuit

I'd like the avoid the constructor overhead associated with using the insertion strategies in these cases. For example, even with #5332 to optimize circuit construction with the EARLIEST strategy, we still have to create dicts to track indexes of qubits, measurement keys, and control keys, iterate over each moment and analyze the moment operations. If we already know we have a sequence of moments, we can avoid all that overhead, and since circuit construction is a very common operation when taking data I think this is worthwhile.

@pavoljuhas, thanks for the review. I've reverted the constructor changes, and instead implemented this in terms of a _from_moments classmethod which replaces the older _with_sliced_moments. I think this is much cleaner, and avoids cluttering the constructors. The docstring on AbstractCircuit._from_moments explains the reason for having this method. PTAL

authors: maffoo pavoljuhas


text:
Add ResponseDemux

Part of #5996
This was first prototyped in https://github.com/quantumlib/Cirq/pull/5982 as _ResponseListener, but this version operates a bit differently: StreamError responses are now handled.
Leaving this as draft until the request client and stream handler are implemented, in case requirements to this class change.
cc @maffoo @wcourtney

I don't see any changes. Looks like maybe you meant to rename the file but didn't git add the new file?

That's exactly it 😂 so that's how you create an empty PR...
Updated

I'm also considering whether this can be made more general eventually and potentially be added to duet. In the current form, the demux logic depends on the response type.

Added cancellation handling. The cancellation callback of making a CancelQuantumJob() unary call will be passed into the demux upon initialization.
The goal is for users to be able to cancel a job by pressing Ctrl-C during a sampler.run() call. As a result, the job will be cancelled regardless of the stream request type.

Ready for review. Usage of this class can be found here

Syncing with @maffoo on stream client design offline. This implementation could potentially be out of date.

This is now stale with respect to the latest design. Closing.

authors: maffoo verult


text:
Revert "adding inplace=True to all the time evolution"

This reverts commit 9278671c538baeff861b102bda68f1d66e5646e0.
This was causing a break for this tutorial: https://quantumai.google/openfermion/fqe/tutorials/fermi_hubbard
To repro the break:
In the above tutorial, change the install line to:
!pip install git+https://github.com/quantumlib/OpenFermion-FQE@9278671c538baeff861b102bda68f1d66e5646e0
and run. Changing to the commit before:
!pip install git+https://github.com/quantumlib/OpenFermion-FQE@138e7584e03311dab12d0889d3415687afbb7f5b
works just fine.

It's easy to revert the original commit but it will result in performance degradation of other code, so it's better to properly fix. The root problem is that the "algorithm" directory is not part of the FQE itself and is not unit-tested thoroughly, although it is embedded in the repository. The tested part of low_rank.py is correctly working but it is not covered 100%.
Can you tell us what function is breaking the example?
@ncrubin what would you want to do?

I opened #109 and will fix the tutorial now. I would close this. Will address #109 with another PR.

I believe @awhite862 is fixing the tutorial today.  So no need to revert.

The problem is that inplace should be set to false for the givens rotation quadratic evolution in algorithms.

The root problem is that the "algorithm" directory is not part of the FQE itself and is not unit-tested thoroughly, although it is embedded in the repository. The tested part of low_rank.py is correctly working but it is not covered 100%.

The way I see it is the library is currently in some kind of "mildly broken state" since the tutorial doesn't work. This change (while it hurts performance) will put it back in a (more) working state, so that anybody who installs the library is less at risk of getting strange outputs/errors. From there it's much easier to take the code from a slow and working state to a more well tested state and then finally a state where it is still working and back at high performance like before.
The longer we leave this tutorial and the library in this "mildly broken state" instead of reverting to the known and "less broken" state, the more users we are likely impacting with a negative experience. For this reason I'm fairly opposed to trying to directly fix the tutorial and tests and functionality all at once instead of quickly rolling the change back so things are working, adding more tests, identifying the root cause and then recovering the performance.

There will be a PR in a few min.
FYI - I am not suggesting to change the tutorial, it's just that deepcopy has to be done outside the loop. Currently, it is doing deepcopy of many GBs (depending on the parameters) thousands of times.

authors: MichaelBroughton ncrubin shiozaki

repo: quantumlib/OpenFermion-FQE


text:
[Resource] Silq

Silq is a high-level quantum programming language:
https://silq.ethz.ch/
This should serve as inspiration for

interoperability: parse or emit silq code
features: automatic uncomputation?
examples: they have a nice library of examples. We should be able to express these programs as well

Just please don't make me type unicode ℕ to program please.

authors: dabacon mpharrigan

repo: quantumlib/Qualtran


text:
AWS Quarkus Lambda Client

Quarkus implementation for AWS Lambda Client

@scrocquesel - PR is approved and merged

@all-contributors please add @tpenakov  for code

@tpenakov Thank you for your contribution

Hey @scrocquesel ,
I am glad that I finally managed to contribute to my favorite framework.
Do you want me to help you with creating an example application?
For me, it is important to have a sample where the other lambda can be called from LambdaClient?

@scrocquesel - there might be a maven artifact name collision with this AWS Lambda?
What do you think?

@scrocquesel - there might be a maven artifact name collision with this AWS Lambda?
What do you think?

Not the same package group per see

Hey @scrocquesel ,
I am glad that I finally managed to contribute to my favorite framework.
Do you want me to help you with creating an example application?
For me, it is important to have a sample where the other lambda can be called from LambdaClient?

@tpenakov you may create a quick start project https://github.com/quarkusio/quarkus-quickstarts
This is usually this quickstart we use for the  documentation with a step by step explanation.

@scrocquesel - there might be a maven artifact name collision with this AWS Lambda?
What do you think?

Not the same package group per see

Hey @scrocquesel ,
Based on Amazon Lambda Client documentation when you create a project you are using the following maven command:
mvn io.quarkus.platform:quarkus-maven-plugin:3.6.0:create \
    -DprojectGroupId=org.acme \
    -DprojectArtifactId=amazon-lambda-quickstart \
    -DclassName="org.acme.lambda.QuarkusLambdaSyncResource" \
    -Dpath="/sync" \
    -Dextensions="resteasy-reactive-jackson,amazon-lambda"
cd amazon-lambda-quickstart

I am not certain which artifact will be used here, but it is misleading in all cases.

@scrocquesel - there might be a maven artifact name collision with this AWS Lambda?
What do you think?

Not the same package group per see

Hey @scrocquesel , Based on Amazon Lambda Client documentation when you create a project you are using the following maven command:
mvn io.quarkus.platform:quarkus-maven-plugin:3.6.0:create \
    -DprojectGroupId=org.acme \
    -DprojectArtifactId=amazon-lambda-quickstart \
    -DclassName="org.acme.lambda.QuarkusLambdaSyncResource" \
    -Dpath="/sync" \
    -Dextensions="resteasy-reactive-jackson,amazon-lambda"
cd amazon-lambda-quickstart

I am not certain which artifact will be used here, but it is misleading in all cases.

@tpenakov You are right. It fails with multiple matches. Should be io.quarkiverse.amazonservices:quarkus-amazon-lambda to avoid any conflict. Would you mind create an issue or open a PR ?

Ok.
I will create a new PR...

@tpenakov we will have the same issue with the server extension. It will match both. Yes, this is unfortunate.
@gsmet WDYT ? Regarding amazon-lambda, we now have two extensions with the same short name. One from quarkiverse and one from quarkus. Should we trick the convention used for all other clients or modify documentation of both extension to use the fqn ?

authors: scrocquesel tpenakov

repo: quarkiverse/quarkus-amazon-services


text:
Allow for configuration of the composed Hub4j GitHub instance

Thank you for all the work in maintaining this excellent Quarkus extension! I'd like to use it more, but am currently having a hard time customizing the Hub4j GitHub API that is managed by this extension. Right now, my use case is primarily the following

Specify a RateLimitChecker via this GitHubBuilder API
Specify a RateLimitHandler via this GitHubBuilder API

However, I could envision needing to customize the GitHubclient further with any of the other APIs or experimenting with other GitHubConnectors.
I know that for some of these other options, like instance endpoint, you provide an option for a configuration directly via this extension. Are you open to other configuration options for all of the various ways to configure a Hub4j GitHub instance? Would you rather allow the user to optionally have a CDI Provider for the GitHub instance that this extension optionally consumes? or would you support a seam for the consumer of this extension to configure the GitHubBuilder after the defaults have been set by this extension but before the GitHubBuilder.build() method is called? Let me know what you think makes sense; I would be happy to contribute this change or provide feedback on possible implementations.

Thanks for the kind words :).
I think it would have value for sure.
Maybe we could to support a GitHubCustomizer bean in the same way we do for ObjectMapperCustomizer in core Quarkus.
The GitHubCustomizer would have a customize(GitHubBuilder) method.
What I'm not entirely sure of is if we would want the same for the installation client and the application client.
Maybe we should have something like that:

Apply all GitHubCustomizer with the default qualifier to both (and we would do that first so that you can override things more specifically if needed)
Apply all GitHubCustomizer with a @InstallationClient qualifier to the installation client
Apply all GitHubCustomizer with a @ApplicationClient qualifier to the application client

Note that we could also start by only implementing the first one and see if people have further needs.
If that works for you and you're willing to implement it, you're very welcome!

Also, maybe a good idea to apply the hardcoded config last as you could easily shoot yourself in the foot if you override them.
We might have to separate the ones we apply first from the ones we apply last at some point, but with the current values we set, I think we should set all the hardcoded/configured ones last.

The GitHubCustomizer approach makes sense to me, I like the flexibility this gives us!

Also, maybe a good idea to apply the hardcoded config last as you could easily shoot yourself in the foot if you override them.

If you're open to it, I'd ideally like to implement this the other way around (allowing people to potentially shoot themselves in the foot for the purpose of customizability). We've previously had success running a GitHub app with HTTP/2 and the OkHttpConnector rather than the prescribed defaults of HTTP 1.1. In general, having the flexibility to experiment and override the defaults would be helpful for understanding GitHub behavior as it evolves.

Fine by me!
We can start with that and adjust if people complain.
The ones I wanted to enforce were:
                .withAppInstallationToken(installationToken.getToken())
                .withEndpoint(checkedConfigProvider.restApiEndpoint())

Because you shouldn't have any need to customize this.
As for the rest, I agree you should be able to override them.

Agreed!

authors: gsmet ryandens

repo: quarkiverse/quarkus-github-app


text:
Release workflow is not working

The latest release wasn't completed successfully.
See: https://github.com/quarkiverse/quarkus-openapi-generator/actions/runs/9959114713/job/27523391547

@ricardozanini @mcruzdev @fjtirado would any of you guys have the bandwidth to look into this? I'm quite busy for now.

I can do this

@mcruzdev ping me on Zulip if you need help.

Probably I will have time to do this one at night

Hello guys, not much related to this, i am playing around with server generator and looking at the reactive configuration, seems like it only available on 3.0.0-SNAPSHOT which requires local build. May i know when will be the plan for 3.0.0 version release published? Many thanks in advance

@hungchu0912 it will be available in the next release as soon as we fix it.

@mcruzdev the release is still failing after your fix. Can you take a second look?
https://github.com/quarkiverse/quarkus-openapi-generator/actions/runs/10267122592/job/28406928335

@hbelmiro it seems our token as expired or is invalid:
2024-08-06T13:18:41.2717327Z [INFO] [ERROR] Remote staging finished with a failure: Failed to deploy artifacts: Could not transfer artifact io.quarkiverse.openapi.generator:quarkus-openapi-generator-deployment:jar.asc:2.4.4 from/to ossrh (https://s01.oss.sonatype.org:443/service/local/staging/deployByRepositoryId/ioquarkiverse-3049): authentication failed for https://s01.oss.sonatype.org:443/service/local/staging/deployByRepositoryId/ioquarkiverse-3049/io/quarkiverse/openapi/generator/quarkus-openapi-generator-deployment/2.4.4/quarkus-openapi-generator-deployment-2.4.4.jar.asc, status: 401 Content access is protected by token

@gastaldi do you know if something changes in the Quarkus release CI?

@ricardozanini the release workflow changed some time ago, I have created some PRs migrating, but it appears that some repositories were missing.
https://github.com/quarkiverse/quarkus-openapi-generator/pull/757 should fix it

Still failing...
fatal: ambiguous argument 'docs/modules/ROOT/pages/includes/attributes.adoc': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
fatal: pathspec 'docs/modules/ROOT/pages/includes/attributes.adoc' did not match any files
Error: Process completed with exit code 128.

https://github.com/quarkiverse/quarkus-openapi-generator/actions/runs/10273287271/job/28427408231
Seems related to @mcruzdev changes.

Seems related to @mcruzdev changes.

oh noes! 😆
@mcruzdev can you please take a look? At least the permissions problem have been solved by @gastaldi 🙏

@hbelmiro shouldn't we keep this one opened?

Sorry for delay, I was out today... but happy that the was solved!

@hbelmiro shouldn't we keep this one opened?

@gastaldi just sent a fix: https://github.com/quarkiverse/quarkus-openapi-generator/pull/759 🤞🏽

I have to pay a beer to @gastaldi some day.

@ricardozanini noted 😉

https://github.com/quarkiverse/quarkus-openapi-generator/actions/runs/10274149171/job/28430223597

You guys rock!! Thank you @gastaldi @mcruzdev @ricardozanini

authors: gastaldi hbelmiro hungchu0912 mcruzdev ricardozanini

repo: quarkiverse/quarkus-openapi-generator


text:
Using user-supplied RX and TX buffers, removing const-generics

This is a first stab at updating minimq to remove const generics and take the smoltcp path of user-supplied buffers. This should drastically cut down on stack and RAM usage for end users.
Fixes #92
Fixes #112

@jordens I'm still working on removing the const generics from the session state, but I think that's going to be a larger follow-up PR, so let's land this one as-is.

repo: quartiq/minimq


text:
inline math highlighting

Something is not quite right with our inline math highlighting:

This has been resolved (we went back to inheriting from the built-in VS Code math highlighting)

authors: cscheid jjallaire

repo: quarto-dev/quarto-vscode


text:
QScript should use objects rather than arrays to carry context

QScript currently builds a lot of arrays, which it then peels apart later in order to carry along information that it needs (often duplication, one side of which will be transformed while the other must be preserved).  The problem is when this introduces undefinedness, connectors are being implicitly expected to maintain sparse arrays throughout the computation pipeline, which is not always an assumption that backends can satisfy.  Objects do not have this flaw, as objects are sparse by definition, and thus qscript would not be making any assumption to use objects rather than arrays as its context structure.
So rather than something that builds an array [.foo, .foo] and later derefs [0] or [1], it would build an object {"0": .foo, "1": .foo} and later deref .0 or .1.

Completed with the switch to QSU.

authors: alissapajer djspiewak

repo: quasar-analytics/quasar


text:
Create a WordBreakCompoundRewriter variant for German

The WordBreakCompoundRewriter uses a dictionary of words (= a Lucene index field) to test if a word can be split into parts. The split will be allowed if all parts exist in the dictionary as words.
While this strategy works in many cases for German, there also exist compounding strategies that involve a morphological change of the modifier word so that a simple test 'split into parts' + 'lookup' will miss these cases. For example, the word 'baumwolljacke' (cotton jacket) is composed of 'baumwolle' + 'jacke' so that a simple split 'baumwolljacke => baumwoll + jacke' would not find 'baumwolle' in the dictionary because of the missing 'e'.
S. Langer. 1998. Zur Morphologie und Semantik von Nominalkomposita. (Tagungsband der 4. Konferenz zur Verarbeitung natürlicher Sprache (KONVENS)) lists 19 patterns of morphological change that can be found in German compound creation. The idea is to apply at least the most productive patterns before looking up the word splits in the dictionary. (see - https://www.cis.uni-muenchen.de/~stef/veroeffentlichungen/konvens1998.pdf, p.6)

Implemented via PR #99

repo: querqy/querqy


text:
Hibernate 5 3 fix proper solution

My attempt at fixing querydsl#2326

Some Firebird test failed with GDS Exception. 335544721.
From what I see in Firebird tracker, this is an issue in Firebird:
http://tracker.firebirdsql.org/browse/JDBC-306
@Shredder121
Maybe we can merge it and release querydsl 5.
All other code refactorings and removal of deprecated functionalities could be move to querydsl 6.
I think releasing querydsl that could support Hibernate 5.2 or 5.3 would be welcomed by many.

repo: querydsl/querydsl


text:
Append system default new line when generating code.

Changed AbstractCodeWriter to append system default line separator when appending new lines to code generated by querydsl.
This PR fixes #2352

@jwgmeligmeyling Can somebody review this pull request? It is my first try at contributing so I opted for a simple problem with tag good first problem.


text:
Updated .md docs to reflect configuration/config.yml change to config…

Updated README.md and other '.md' docs to reflect this change to use config/config.yaml instead of configuration/config.yml

Thanks!

authors: cjarvs skluck

repo: quickenloans-mcp/mcp-panthor

license: mit


text:
Repeated crashes

I'm experiencing repeated crashes; both versions 1.5.3 and 1.5.2 have crashed for me. I've attached multiple crash reports here (zipped). I don't know what to look for in the reports to help identify what the problem might be.
quicksilver crashes.zip

Some are from what’s reported in #2319. Others are from ion loading. I see those myself, but it’s not going to be easy to fix 100%. Here’s a test build that hopefully fixes it. https://cl.ly/3z1a2q1u1n3y
Please let us know if you encounter any problems with it.

No worries. I've used Quicksilver since Tiger and I'm not proposing to stop. I'll try the build you've offered and let you know what happens.

Hi @StuartRob ,
It's been a while since we've heard from you, and hopefully skurfer's build fixed the issue for you! If you're still facing an issue with the latest version of Quicksilver, please create a new issue.
Thanks!

authors: StuartRob pjrobertson skurfer

repo: quicksilver/Quicksilver


text:
Plugins have hex or float CFBundleVersions

It looks like CFBundleVersions are supposed to be [MAJOR].[MINOR].[PATCH] formatted, but currently the majority are using hex:
$ awk '/CFBundleVersion/ { getline; split($0, arr, /[<>]/); print arr[3] }' **/Info.plist  | head
1C
1.0
12C
25
287
A9
47
45
2
120C

Further, bltrversion assumes hex and chokes on formats that can't be interpreted as hex: https://github.com/quicksilver/Quicksilver/blob/9300d8893504ff06debfc61da1fbfe6bf54c4479/Quicksilver/Tools/bltrversion#L38
For the moment, I propose that we:

if ambiguous assume hex and increment by 1, which preserves backwards compatibility
fallback to [MAJOR].[MINOR](.[PATCH])? if there are any .

auto-increment only the rightmost part

Sound OK?

Makes sense to me. I hate the hex numbers. But I guess they were considered easier to increment. It looks like your PR chooses to just increment the [PATCH] setting?
As much as I'd like to get rid of the hex strings, it'll be a fair amount of testing work because:

Server handling - I'm pretty sure the qs0.qsapp.com server currently only handles Hex versions
In-app updating/checking. The app right now compares version numbers based on hex. We'd need to edit the code to compare based on X.Y.Z format. Then any older QS versions that don't have this code would choke if they got an X.Y.Z format from the update server, but expected a hex.

As part of re-building all of the plug-ins, I started ripping out bltrversion. It was failing and has maybe always been more trouble than it’s worth because it took so much fiddling.

You would often have to manually adjust the version to avoid bumping it by 50 instead of 1.
Xcode changed the order it did things, so you would end up building before the script ran. This meant that the plug-in you built was still using the old version, and that the version in the repo didn’t match the built product. You could get around it by building again, then manually putting the version back 1.

I think it has value as a documentation generator if we can get it working again (and get it to run before the bundle is created).

It looks like your PR chooses to just increment the [PATCH] setting?

Yes -- I wasn't sure what the analogous change would be as compared to incrementing an int by 1. Because it runs so frequently, I thought patch update seemed the most appropriate which would allow us to manually make it major or minor when finalizing the version number update.

I think it has value as a documentation generator if we can get it working again (and get it to run before the bundle is created).

This is my thinking. We use bltrversion just for turning Documentation.mdown into HTML for the PLIST.
We either go back to 'manually' updating the plugin version or only using Github Actions to build all our plugins, then have a separate script for the Github action that increments the build number.
Regarding this issue, I'm still inclined to say we shouldn't change from HEX to decimal X.Y.Z. Just because it'll break our update server and I don't really want to be messing with that - it's worked well for 10 years and if it aint broke don't fix it.

We use bltrversion just for turning Documentation.mdown into HTML for the PLIST.

And it should still apply QS_BACKWARDS_COMPATIBILITY_BREAK. (Forgot about that feature.) We should rename it, though. Not a big deal since we have to manually add it back to most Xcode projects anyway.

We either go back to 'manually' updating the plugin version or only using Github Actions to build all our plugins, then have a separate script for the Github action that increments the build number.

I prefer manual since only a human can really determine what the displayed version should be anyway.

I'm still inclined to say we shouldn't change from HEX to decimal X.Y.Z. Just because it'll break our update server

Agree.

I prefer manual since only a human can really determine what the displayed version should be anyway.

Sounds reasonable to me, but I'm not the one building the plugins 🙈  But you idea might be to adapt what I said here and have the github action only trigger on a commit with a commit message like: UPDATE PLUGIN: 1.9.0
Then the version number could be gleaned from that.
But again, it might actually be simpler for the time being to stick with just manually building. And it's not like we're going to have to keep rebuilding them all the time (unless Apple decides to release a new architecture every couple of months :/ )
But for this issue specifically: moving to X.Y.Z for CFBundleVersion: we'll stick to #HorribleHex for now.
I'll close this now, but feel free to keep the discussion up on Hex and the Github action building if need be.

GitHub has good support for workflows that run only on e.g. pushing a tag
We could easily create an action that:

runs on the push of a tag
clones QS (master? latest release?)
builds QS
replaces the version in Info.plist with that from the tag
build the plugin
If all succeeds, runs qs-push-plugin using a repo secret for the password

Disadvantage of this would be that we would have to manually keep the tag and the version in sync
Maybe something to think about eventually. Currently I'm running into so many issues just building the plugins that I think this may be a ways off before it would save any effort anyway.

authors: n8henrie pjrobertson skurfer


text:
allow for multiple cases in DEFINE-ERROR-MAP

This fixes a small issue with the DEFINE-ERROR-MAP macro, in which it would not correctly handle > 1 cases.
For example,
(sbcl-librarian:define-error-map test-map :int 0
  (warning (condition) 0)
  (t (condition) 1))

would not expand properly under the previous version.

OK, cool. Weren't we thinking of getting rid of error-map at some point?

authors: karlosz kilimanjaro

repo: quil-lang/sbcl-librarian


text:
Re-appearance of symbols for latest dashboard change when a non-dashboard-affecting slider is moved

Hard to phrase, but here is an attempt:
Changing certain sliders does not affect the dashboard quantities at all; however, when doing so the increase/decrease arrows for the previous change re-appear in the dashboard.
This is best illustrated by an example. Set all trucks to be electric in the demand of car technology, and then change the slider for efficiency improvement combustion engine trucks. One would expect the dashboard quantities not to change at all, because there are no combustion engine trucks in existence. This is indeed observed; however, one does see the arrows reflecting the previous change (in this case, of setting all trucks to be electric) re-appear in the dashboard. This might give the user the impression that the quantities in the dashboard do change because of these symbols, while in fact they don't.
It's also worth noting that these symbols do not appear if enough time has passed between the previous change and changing a slider that does not affect the dashboard quantities.
Re-assign at will.
P.S. My sincerest apologies for this horrifying title.

This behaviour is as old as the ETM. I kinda got used to it but that is not a reason to correct it. It would be better IMO if the arrows disappear as you touch a new slider that does not change anything.
Assigning @antw to pick this up after the deploy.

Assigning @grdw .

Took my some reading but I get the issue. :sweat_smile:
The current implementation is that it 'animates' away after 30s

IMO if the arrows disappear as you touch a new slider that does not change anything.

I would love that aswell but the event is triggered >5 times when dragging one slider. Also checking if a slider 'did nothing' overall is harder than I thought. I wasted too much time on this (consider it a "I probably need a very speedy introduction to Backbone in combination with Coffeescript").
The fix I came up with is not letting the arrows stay on the field for 30 seconds. That's too long. How about 2 seconds? That way you see that it changed and that's it.

Fixed with: https://github.com/quintel/etmodel/commit/2e44b75db124f68c1f6c5ff7ace5b5d5e73f5727

authors: ChaelKruip RobTerwel grdw jorisberkhout

repo: quintel/etmodel


text:
Multi year charts: changing slider settings does not work

Changing slider settings in the MYC front-end does not work.
MYC for a random French scenario: setting the sliders in the MYC tool does not work.

I also made link to MYC for previously made scenario's. Remarkably I find that in this case I can change sliders through the MYC front-end.
MYC for a mix of self-made scenario's: setting the sliders in the MYC tool does work.

Oh darn! This is because of https://github.com/quintel/etengine/issues/1209, where protected scenarios were made to be read-only. MYC scenarios are marked as protected when we create them, and this results in being unable to move the sliders.
I'll discuss this with Chael and Nora in our sprint meeting on Monday (it's not urgent IMO since practically no one uses this feature).

authors: DorinevanderVlies antw


text:
[Airbrake] [Staging] undefined method `round' for "-8,9":String

Airbrake error: #7301
Airbrake project: ETMoses
Error type: NoMethodError
Error message: undefined method `round' for "-8,9":String
Where: testing_grounds#show
Occurred at: Jul 05, 2016 12:21:26 UTC
First seen at: Jul 05, 2016 12:21:26 UTC
Occurrences: 1 (1 since last deploy on Jul 05, 2016 10:34:45 UTC)
URL: https://beta-moses.energytransitionmodel.com/testing_grounds/577
File: [PROJECT_ROOT]/app/views/testing_grounds/show.html.haml
Backtrace:
[PROJECT_ROOT]/app/views/testing_grounds/show.html.haml:79:in block (2 levels) in _app_views_testing_grounds_show_html_haml___2863853698922015541_70251869660580
[PROJECT_ROOT]/app/views/testing_grounds/show.html.haml:74:in each
[PROJECT_ROOT]/app/views/testing_grounds/show.html.haml:74:in block in _app_views_testing_grounds_show_html_haml___2863853698922015541_70251869660580
[PROJECT_ROOT]/app/views/testing_grounds/show.html.haml:62:in _app_views_testing_grounds_show_html_haml___2863853698922015541_70251869660580

@grdw Unless you had some sort of quick fix in mind when you self-assigned this, I think we should close this issue. It falls under the category of the "Input Validation" milestone and I don't think we need more issues describing incorrect inputs.

Not really. I just self-assign myself to these airbrake issues, because otherwise it doesn't turn up in anyone's filter.

Let's close it then. I want to try something with dry-validation as soon as we have time, but in the short-term we will have to do without. I'll look into this LES and fix the broken value.

authors: antw dennisschoenmakers grdw

repo: quintel/etmoses


text:
Business cases do not re-calculate when strategies are updated

See LES 313 for example.

Since this is only - not working on the production environment - the most easy fix would be to merge all the changes that are related to the business cases to the production environemnt.

Can we identify the issue and cherry-pick the relevant commit onto the production branch? I think we should have another production deploy of Moses soon, but this would be good enough for the short-term.

Can we identify the issue and cherry-pick the relevant commit onto the production branch?

Yes. That's basically what I was trying to say.

@dennisschoenmakers is doing a demo at the moment. Please wait an hour or so before deploying production!

The problem is that the Moses scenario points to ETEngine scenario 434138. ETEngine has no such scenario.
ETEngine production scenarios are currently numbered in the 200,000s, while staging is in the 400,000s. I'm not clear how production Moses could take scenarios from staging ETEngine, and I'm sure I deleted all the scenarios on Moses production during the deploy last week.
The created_at field is "2015-09-27 13:24:33" which is three days before the deploy. Did these scenarios get imported manually somehow?
404 Resource Not Found
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/rest-client-1.6.7/lib/restclient/abstract_response.rb:48:in `return!'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/rest-client-1.6.7/lib/restclient/request.rb:230:in `process_result'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/rest-client-1.6.7/lib/restclient/request.rb:178:in `block in transmit'
/home/ubuntu/.rbenv/versions/2.1.1/lib/ruby/2.1.0/net/http.rb:853:in `start'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/rest-client-1.6.7/lib/restclient/request.rb:172:in `transmit'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/rest-client-1.6.7/lib/restclient/request.rb:64:in `execute'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/rest-client-1.6.7/lib/restclient/request.rb:33:in `execute'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/rest-client-1.6.7/lib/restclient.rb:68:in `get'
/var/www/etmoses/releases/20150930151452/lib/et_engine_connector.rb:67:in `public_send'
/var/www/etmoses/releases/20150930151452/lib/et_engine_connector.rb:67:in `et_api_request'
/var/www/etmoses/releases/20150930151452/lib/et_engine_connector.rb:42:in `merit'
/var/www/etmoses/releases/20150930151452/app/models/market/from_market_model_builder.rb:63:in `merit_curve'
/var/www/etmoses/releases/20150930151452/app/models/market/from_market_model_builder.rb:54:in `convert_tariff'
/var/www/etmoses/releases/20150930151452/app/models/market/from_market_model_builder.rb:33:in `block in relations'
/var/www/etmoses/releases/20150930151452/app/models/market/from_market_model_builder.rb:27:in `map'
/var/www/etmoses/releases/20150930151452/app/models/market/from_market_model_builder.rb:27:in `relations'
/var/www/etmoses/releases/20150930151452/app/models/market/from_market_model_builder.rb:18:in `data'
/var/www/etmoses/releases/20150930151452/app/models/market/from_market_model_builder.rb:11:in `to_market'
/var/www/etmoses/releases/20150930151452/app/models/market.rb:59:in `from_market_model'
/var/www/etmoses/releases/20150930151452/app/services/finance/business_case_calculator.rb:40:in `market'
/var/www/etmoses/releases/20150930151452/app/services/finance/business_case_calculator.rb:32:in `row'
/var/www/etmoses/releases/20150930151452/app/services/finance/business_case_calculator.rb:23:in `block in cells'
/var/www/etmoses/releases/20150930151452/app/services/finance/business_case_calculator.rb:21:in `map'
/var/www/etmoses/releases/20150930151452/app/services/finance/business_case_calculator.rb:21:in `cells'
/var/www/etmoses/releases/20150930151452/app/services/finance/business_case_calculator.rb:10:in `block in rows'
/var/www/etmoses/releases/20150930151452/app/services/finance/business_case_calculator.rb:9:in `map'
/var/www/etmoses/releases/20150930151452/app/services/finance/business_case_calculator.rb:9:in `rows'
/var/www/etmoses/releases/20150930151452/app/services/finance/business_case_creator.rb:16:in `financials'
/var/www/etmoses/releases/20150930151452/app/services/finance/business_case_creator.rb:10:in `calculate'
/var/www/etmoses/releases/20150930151452/app/jobs/business_case_calculator_job.rb:12:in `perform'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/backend/base.rb:94:in `block in invoke_job'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:61:in `call'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:61:in `block in initialize'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:66:in `call'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:66:in `execute'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:40:in `run_callbacks'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/backend/base.rb:91:in `invoke_job'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/worker.rb:204:in `block (2 levels) in run'
/home/ubuntu/.rbenv/versions/2.1.1/lib/ruby/2.1.0/timeout.rb:91:in `block in timeout'
/home/ubuntu/.rbenv/versions/2.1.1/lib/ruby/2.1.0/timeout.rb:101:in `call'
/home/ubuntu/.rbenv/versions/2.1.1/lib/ruby/2.1.0/timeout.rb:101:in `timeout'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/worker.rb:204:in `block in run'
/home/ubuntu/.rbenv/versions/2.1.1/lib/ruby/2.1.0/benchmark.rb:294:in `realtime'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/worker.rb:203:in `run'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/worker.rb:280:in `block in reserve_and_run_one_job'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:61:in `call'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:61:in `block in initialize'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:66:in `call'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:66:in `execute'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:40:in `run_callbacks'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/worker.rb:280:in `reserve_and_run_one_job'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/worker.rb:187:in `block in work_off'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/worker.rb:186:in `times'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/worker.rb:186:in `work_off'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/worker.rb:150:in `block (4 levels) in start'
/home/ubuntu/.rbenv/versions/2.1.1/lib/ruby/2.1.0/benchmark.rb:294:in `realtime'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/worker.rb:149:in `block (3 levels) in start'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:61:in `call'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:61:in `block in initialize'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:66:in `call'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:66:in `execute'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:40:in `run_callbacks'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/worker.rb:148:in `block (2 levels) in start'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/worker.rb:147:in `loop'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/worker.rb:147:in `block in start'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/plugins/clear_locks.rb:7:in `call'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/plugins/clear_locks.rb:7:in `block (2 levels) in <class:ClearLocks>'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:79:in `call'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:79:in `block (2 levels) in add'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:61:in `call'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:61:in `block in initialize'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:79:in `call'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:79:in `block in add'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:66:in `call'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:66:in `execute'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/lifecycle.rb:40:in `run_callbacks'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/worker.rb:146:in `start'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/command.rb:124:in `run'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/command.rb:112:in `block in run_process'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/daemons-1.2.2/lib/daemons/application.rb:265:in `call'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/daemons-1.2.2/lib/daemons/application.rb:265:in `block in start_proc'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/daemons-1.2.2/lib/daemons/daemonize.rb:84:in `call'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/daemons-1.2.2/lib/daemons/daemonize.rb:84:in `call_as_daemon'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/daemons-1.2.2/lib/daemons/application.rb:269:in `start_proc'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/daemons-1.2.2/lib/daemons/application.rb:295:in `start'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/daemons-1.2.2/lib/daemons/controller.rb:56:in `run'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/daemons-1.2.2/lib/daemons.rb:193:in `block in run_proc'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/daemons-1.2.2/lib/daemons/cmdline.rb:88:in `call'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/daemons-1.2.2/lib/daemons/cmdline.rb:88:in `catch_exceptions'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/daemons-1.2.2/lib/daemons.rb:192:in `run_proc'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/command.rb:110:in `run_process'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/command.rb:91:in `block in daemonize'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/command.rb:89:in `times'
/var/www/etmoses/shared/bundle/ruby/2.1.0/gems/delayed_job-4.0.6/lib/delayed/command.rb:89:in `daemonize'
bin/delayed_job:5:in `<main>'

Did these scenarios get imported manually somehow?

Yes.

Closing.

@grdw please remove the offending LESses again from the production database to prevent future issues.

authors: ChaelKruip antw grdw


text:
Add AnyStatus to Tools

Tools/AnyStatus - VS Gallery
AnyStatus is a free and open source Visual Studio Extension that helps developers maintain a healthy development environment and quickly diagnose issues by providing tools to monitor resources and applications on-premise or in the cloud.
With AnyStatus you can monitor HTTP servers, send Ping requests, check TCP ports, monitor GitHub Issues, monitor CI builds on Team Foundation Server, Jenkins, TeamCity, AppVeyor...and much more. All from within Visual Studio.

Thank You

repo: quozd/awesome-dotnet


text:
Feature / Add Juz / Siparah marks for Ayat.

Title of change

Add juz/siparah marks for ayaat. from request #652 and #371

Checklist

[x] Unit tests written
[x] Manually tested
[x] Prettier & ESLint were run
[x] New dependencies are included in package-lock.json

Screenshot

@ahmedre @mmahalwy @ahmedelgabri can you guys have a look at this, and review the UI.thanks guys.

Deployed to: http://staging.quran.com:33010

rebuild

@Dhul-Husni this is so close! :) excited for it to ship

Deployed to: http://staging.quran.com:33011

Deployed to: http://staging.quran.com:33013

@mmahalwy  will fix the tooltip bug in the next PR and make necessary changes inshaAllah

rebuild

Deployed to: http://staging.quran.com:33021

authors: Dhul-Husni ahmedre mmahalwy naveed-ahmad sabeurthabti


text:
Can we work with moment in UTC mode?

E.g. when creating the moment I want to do this:
moment.utc('datetime string', 'format string', true) not
moment.('datetime string', 'format string', true)
As per the moment docs:
By default, moment parses and displays in local time.
If you want to parse or display a moment in UTC, you can use moment.utc() instead of moment().
This brings us to an interesting feature of Moment.js. UTC mode.
Could this be added as a prop - to use moment in UTC mode?

did you find a workaround for this? i also need this

basically no. the date was displayed to the users in local time. we converted it to UTC to send to our back-end.

authors: foodaka justinwyllie

repo: quri/react-bootstrap-datetimepicker


text:
🛑 Adguard Home DoT is down

In 8191cc9, Adguard Home DoT ($AG_DOT) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Adguard Home DoT is back up in 54f621c.

repo: quyleanh/upptime


text:
🛑 Adguard Home DoT is down

In e04e593, Adguard Home DoT ($AG_DOT) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Adguard Home DoT is back up in 9c36258.


text:
🛑 Adguard Home DoT is down

In fccd7e3, Adguard Home DoT ($AG_DOT) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Adguard Home DoT is back up in f4c496d.


text:
🛑 Adguard Home DoT is down

In 1990d3b, Adguard Home DoT ($AG_DOT) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Adguard Home DoT is back up in c04d8f5 after 7 minutes.


text:
🛑 Adguard Home DoT is down

In 559e7e2, Adguard Home DoT ($AG_DOT) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Adguard Home DoT is back up in f442829 after 43 minutes.


text:
Proposed changes to reduce VRAM usage. Potentially quantize larger models on consumer hardware.

Hello everyone,
Recently I noticed a lack of 4-bit quantized versions of Google/flan-ul2 on HF, and so, decided to set out to quantize the model on my 4090.
I struggled with this for a bit due to my own oversights, but during my debugging, I found a section of code that, if run on the CPU, does NOT take long to run, and yet, if run on the GPU, requires a significant allocation of memory. Thus I propose the following changes inside of t5_sequential() in the t5.py script file:
        del layer
        del gptq
        gc.collect()
        torch.cuda.empty_cache()

        inps, outs = outs, inps

    # do this part on CPU, because GPU runs out of memory
    dev = 'cpu'

    model.encoder.final_layer_norm = model.encoder.final_layer_norm.to(dev)
    model.encoder.dropout = model.encoder.dropout.to(dev)

    encoder_hidden_states = model.encoder.final_layer_norm(inps.cpu())
    encoder_hidden_states = model.encoder.dropout(encoder_hidden_states)

    model.encoder.final_layer_norm = model.encoder.final_layer_norm.cpu()
    model.encoder.dropout = model.encoder.dropout.cpu()

    dev = 'cuda:0'
    encoder_hidden_states = encoder_hidden_states.to(dev)
    inps = inps.to(dev)
    # end of CPU section

At the moment, I'm not actually certain whether or not using gc.collect() is entirely necessary, but it also doesn't hurt. The real memory saving changes come from running model.encoder.final_layer_norm and model.encoder.dropout on the CPU. This (combined with --n_samples 256 and PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:512) enabled me to quantize a 20b model on my 4090 where I otherwise would not have been able to. Or at least, not with that size of sample count.
Note: Use of gc.collect() requires adding import gc somewhere (preferably near the top) in the file.

neat

Hello everyone,
Recently I noticed a lack of 4-bit quantized versions of Google/flan-ul2 on HF, and so, decided to set out to quantize the model on my 4090.
I struggled with this for a bit due to my own oversights, but during my debugging, I found a section of code that, if run on the CPU, does NOT take long to run, and yet, if run on the GPU, requires a significant allocation of memory. Thus I propose the following changes inside of t5_sequential() in the t5.py script file:
        del layer
        del gptq
        gc.collect()
        torch.cuda.empty_cache()

        inps, outs = outs, inps

    # do this part on CPU, because GPU runs out of memory
    dev = 'cpu'

    model.encoder.final_layer_norm = model.encoder.final_layer_norm.to(dev)
    model.encoder.dropout = model.encoder.dropout.to(dev)

    encoder_hidden_states = model.encoder.final_layer_norm(inps.cpu())
    encoder_hidden_states = model.encoder.dropout(encoder_hidden_states)

    model.encoder.final_layer_norm = model.encoder.final_layer_norm.cpu()
    model.encoder.dropout = model.encoder.dropout.cpu()

    dev = 'cuda:0'
    encoder_hidden_states = encoder_hidden_states.to(dev)
    inps = inps.to(dev)
    # end of CPU section

At the moment, I'm not actually certain whether or not using gc.collect() is entirely necessary, but it also doesn't hurt. The real memory saving changes come from running model.encoder.final_layer_norm and model.encoder.dropout on the CPU. This (combined with --n_samples 256 and PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:512) enabled me to quantize a 20b model on my 4090 where I otherwise would not have been able to. Or at least, not with that size of sample count.
Note: Use of gc.collect() requires adding import gc somewhere (preferably near the top) in the file.

Hey, thank you for your flan-ul2 quant! I really appreciate it. Very useful model, but unfortunately overlooked due to the flood of llamas..
Seeing your work, I tried to quantize a flan-t5-xxl but the resulting file outputs nonsense.
Also, while quantizing the error reported per layer seems large (10s~100s) although I am not familiar with the normal range.
I tried to monkey patch here and there, but as a novice in programming I am at my wits end.
Can you please point me in the right direction, or share your modifications to the t5 branch?

Hey, thank you for your flan-ul2 quant! I really appreciate it. Very useful model, but unfortunately overlooked due to the flood of llamas..
Seeing your work, I tried to quantize a flan-t5-xxl but the resulting file outputs nonsense. Also, while quantizing the error reported per layer seems large (10s~100s) although I am not familiar with the normal range. I tried to monkey patch here and there, but as a novice in programming I am at my wits end.
Can you please point me in the right direction, or share your modifications to the t5 branch?

Aside from the change listed in this issue, I've made no other change. I don't know why your quantized model isn't working really, but according to the config.json files, flan-ul2 is bfloat16 while flan-t5-xxl is float32. I'm not sure if this makes a difference or not, but it may. I also don't know which flan-t5-xxl model you downloaded. The repo has several formats it looks like. I'd recommend only getting the bin files and double check their SHA256 against what is listed on HF. Sorry I couldn't be more help.

authors: sigjhl sigmareaver xXwatermelon