text:
Prevent multiple post-release segments in pep440-pre style

tl;dr - pep440-pre doesn't check if the closest tag already contains a post release segment, resulting in a version string that PyPI rejects because there are multiple post release segments. The proposed change detects if a post release segment is present in the tag, and makes versioneer create dev releases for the next postN version instead of always post0.

For a number of projects (e.g. cmake, ninja), the main release segment of the version string matches the version number of the tool being packaged, and the post-release segment is used to indicate updates that just change the pip package but not the underlying tool.
Picking a style to use with versioneer that fits the tag/version workflow is tricky because none of the ones that append a +<local version> string can be uploaded to PyPI. The closest match to this versioning scheme is pep440-pre, but because new releases use tags in the form vX.Y.Z.postN, versioneer decides the version will be in the form vX.Y.Z.postN.post0.devN, which PyPI rejects because there are multiple post-release segments.
In addition, if the last release was vX.Y.Z.post0, the next post release would be vX.Y.Z.post1, so versioneer dev versions should be in the form vX.Y.Z.post1.devN. (This has the downside of if the next release won't be a post release -- but that same downside is true of the current implementation of the pep440-pre style.)
I've modified the pep440-pre style to check if a post release segment exists in the tag, and if so to increment the postN part of the rendered version to the appropriate value for the "next" post release. I think this handles the cases described above better than the existing pep440-pre implementation without breaking backwards compatibility. The one downside with what I have right now is it expects that tag to be the "normalized" form of the tag in that it doesn't handle synonyms like rev, r, or the alternative -, _, no segment separator, or - only variations of specifying a post release.
Any thoughts on making these changes to the existing style, or adding a new pep440-pre-noduplicatepost style? I think there are a few other of the pep440 styles that could also be updated to better handle a closest version tag that already includes pre/post/dev release segments.

I think I'm the closest person. I'll try to have a look soonish.

There are a few packages I've been holding off sending PRs to for using this modified version of the renderer -- if this PR seems like it is moving somewhere soon then I'll continue to hold off, since I'd much rather the changes get upstreamed to versioneer rather than maintaining my own fork.

Thanks! I'll update the docs to mention the new behavior. I think I'll make the None change too, since when looking at it again I realized that if the distance from the last tag is 0 it shouldn't increment the post release segment.

LGTM. Happy to merge if you're ready.

authors: effigies nightlark

repo: python-versioneer/python-versioneer

license: Unlicense


text:
Option to turn off Image Feed

The image feed is always there on the upper right corner, pls add an option to hide it.

The option "Show Image On Menu" seems like it should be the setting to disable the button, but that option appears to do nothing.

This is fixed, the button will only show if the image feed is closed and never if the setting is set to hidden

source: gharchive/issue

repo: pythongosssss/ComfyUI-Custom-Scripts

license: MIT

license_type: permissive

license_source: github-api


text:
🛑 Private Message Api is down

In 3ca1d5e, Private Message Api (https://privatemessages.roblox.com/) was down:

HTTP code: 503
Response time: 646 ms

Resolved: Private Message Api is back up in e60b3b5 after 11 minutes.

repo: pythoniaweb/roblox-status


text:
🛑 Node 2 is down

In ebfea03, Node 2 (http://nodeb.boomhost.ml/index.html) was down:

HTTP code: 504
Response time: 10801 ms

Resolved: Node 2 is back up in b0c6f02.

repo: pythoniaweb/statusboom


text:
🛑 Groups Api is down

In 1eb6c4b, Groups Api (https://groups.roblox.com/) was down:

HTTP code: 404
Response time: 134 ms

Resolved: Groups Api is back up in 181b830 after 11 minutes.


text:
Support for Fused Attention + FP8

Summary
Cuddn supports fused_attention with FP8 inputs.
See: https://docs.nvidia.com/deeplearning/cudnn/developer-guide/index.html#flash-fused-multi-head-att-fp8
There already exists a PR on PyTorch to add support for the Cudnn Backend to SDPA:https://github.com/pytorch/pytorch/pull/101916
This seems like a potential path attention support for FP8

https://github.com/pytorch/ao/issues/560

authors: drisspg vkuzo


text:
soundfile save test failing

🐛 Bug
I've tried to build torchaudio from the source but one test is consistently failing (backend/soundfile/save_test.py::TestFileObject::test_fileobj_flac). This happens on both my Linux and OSX machine.
To Reproduce
Steps to reproduce the behavior:

git clone https://github.com/pytorch/audio
cd audio
git submodule update --init --recursive
conda create -n temp2 -c pytorch-nightly pytorch
conda activate temp2
pip install typing pytest scipy numpy parameterized pyyaml
NO_CUDA=1 BUILD_SOX=1 MACOSX_DEPLOYMENT_TARGET=10.9 CC=clang CXX=clang++ python setup.py install (for linux machine, it is build with BUILD_SOX=1 python setup.py install)
export PATH="${PATH_TO_TORCHAUDIO}/audio/third_party/install/bin:${PATH}"
cd test/torchaudio_unittest
Pip install soundfile
pytest backend/soundfile/save_test.py (more specifically pytest backend/soundfile/save_test.py::TestFileObject::test_fileobj_flac)

Here is the pytest message by running (pytest backend/soundfile/save_test.py).
============================================================================================================================ test session starts =============================================================================================================================
platform linux -- Python 3.9.5, pytest-6.2.4, py-1.10.0, pluggy-0.13.1
rootdir: /data/home/yyyang/temp/audio
plugins: xdist-2.3.0, forked-1.3.0
collected 958 items

backend/soundfile/save_test.py ....................................................................................................................................................................................................................................... [ 24%]
...................................................................................................................................................................................................................................................................... [ 51%]
...................................................................................................................................................................................................................................................................... [ 78%]
.......................................................................................................................................................................................................F...                                                            [100%]
================================================================================================================================== FAILURES ==================================================================================================================================
______________________________________________________________________________________________________________________ TestFileObject.test_fileobj_flac ______________________________________________________________________________________________________________________

self = <torchaudio_unittest.backend.soundfile.save_test.TestFileObject testMethod=test_fileobj_flac>

    @skipIfFormatNotSupported("FLAC")
    @skipIfRocm
    def test_fileobj_flac(self):
        """Saving audio via file-like object works"""
>       self._test_fileobj('flac')

backend/soundfile/save_test.py:287:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
backend/soundfile/save_test.py:277: in _test_fileobj
    self.assertEqual(expected, found, atol=1e-4, rtol=1e-8)
/fsx/users/yyyang/conda/envs/torchaudio-upstream/lib/python3.9/site-packages/torch/testing/_internal/common_utils.py:1407: in assertEqual
    self.assertEqual(x_, y_, atol=atol, rtol=rtol, msg=msg,
/fsx/users/yyyang/conda/envs/torchaudio-upstream/lib/python3.9/site-packages/torch/testing/_internal/common_utils.py:1407: in assertEqual
    self.assertEqual(x_, y_, atol=atol, rtol=rtol, msg=msg,
/fsx/users/yyyang/conda/envs/torchaudio-upstream/lib/python3.9/site-packages/torch/testing/_internal/common_utils.py:1419: in assertEqual
    super().assertTrue(result, msg=self._get_assert_msg(msg, debug_msg=debug_msg))
E   AssertionError: False is not true : Scalars failed to compare as equal! Comparing -0.99993896484375 and 1.00006103515625 gives a difference of 2.0, but the allowed difference with rtol=1e-08 and atol=0.0001 is only 0.00010001000061035157!
============================================================================================================================== warnings summary ==============================================================================================================================
test/torchaudio_unittest/backend/soundfile/save_test.py: 10 warnings
  /data/home/yyyang/temp/audio/test/torchaudio_unittest/common_utils/wav_utils.py:77: WavFileWarning: Chunk (non-data) not understood, skipping it.
    sample_rate, data = scipy.io.wavfile.read(path)

-- Docs: https://docs.pytest.org/en/stable/warnings.html
========================================================================================================================== short test summary info ===========================================================================================================================
FAILED backend/soundfile/save_test.py::TestFileObject::test_fileobj_flac - AssertionError: False is not true : Scalars failed to compare as equal! Comparing -0.99993896484375 and 1.00006103515625 gives a difference of 2.0, but the allowed difference with rtol=1e-08 a...
================================================================================================================= 1 failed, 957 passed, 10 warnings in 6.80s =================================================================================================================

Expected behavior
The test should pass.
Environment

What commands did you used to install torchaudio (conda/pip/build from source)?
see above
If you are building from source, which commit is it?
533c2d47f7c03370a26b9744f9ec2093857fc43a
What does torchaudio.__version__ print? (If applicable)

>>> soundfile.__version__
'0.10.3'
>>> torchaudio.__version__
'0.10.0a0+533c2d4'
>>> scipy.__version__
'1.6.3'

OSX machine:
Collecting environment information...
PyTorch version: 1.10.0.dev20210618
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 11.4 (x86_64)
GCC version: Could not collect
Clang version: 12.0.5 (clang-1205.0.22.9)
CMake version: version 3.20.4
Libc version: N/A

Python version: 3.9 (64-bit runtime)
Python platform: macOS-10.16-x86_64-i386-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.20.3
[pip3] torch==1.10.0.dev20210618
[pip3] torchaudio==0.10.0a0+533c2d4
[conda] blas                      1.0                         mkl
[conda] mkl                       2021.2.0           hecd8cb5_269
[conda] numpy                     1.20.3                   pypi_0    pypi
[conda] pytorch                   1.10.0.dev20210618         py3.9_0    pytorch-nightly
[conda] torchaudio                0.10.0a0+533c2d4          pypi_0    pypi

Linux machine:
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.5 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: Could not collect
CMake version: version 3.19.6
Libc version: glibc-2.27

Python version: 3.9 (64-bit runtime)
Python platform: Linux-5.4.0-1041-aws-x86_64-with-glibc2.27
Is CUDA available: False
CUDA runtime version: 11.1.105
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Probably one of the following:
/usr/local/cuda-10.1/targets/x86_64-linux/lib/libcudnn.so.7.6.5
/usr/local/cuda-10.2/targets/x86_64-linux/lib/libcudnn.so.7.6.5
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn.so.8.0.5
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.0.5
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.0.5
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.0.5
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.0.5
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.0.5
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_ops_train.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_ops_train.so.8.0.5
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.20.3
[pip3] torch==1.10.0.dev20210618
[pip3] torchaudio==0.10.0a0+533c2d4
[conda] blas                      1.0                         mkl
[conda] cudatoolkit               10.2.89              hfd86e86_1
[conda] mkl                       2021.2.0           h06a4308_296
[conda] numpy                     1.20.3                   pypi_0    pypi
[conda] pytorch                   1.10.0.dev20210618 py3.9_cuda10.2_cudnn7.6.5_0    pytorch-nightly
[conda] torchaudio                0.10.0a0+533c2d4           dev_0    <develop>

Additional context

What will happen if you change the following line to return None?
https://github.com/pytorch/audio/blob/533c2d47f7c03370a26b9744f9ec2093857fc43a/torchaudio/backend/soundfile_backend.py#L286

With this change, the test would pass in both linux and OSX.
Is this a bug or just a version issue?

It means that the reference data created in test is different from the current implementation of torchaudi.save.
First, we need to check which one is correct. If you have time to look into this, here is the step;

Get the signal generated during the test.
The audio data is saved in byte buffer at https://github.com/pytorch/audio/blob/533c2d47f7c03370a26b9744f9ec2093857fc43a/test/torchaudio_unittest/backend/soundfile/save_test.py#L273
So dump the content into a file.
Something like the following,with open(self.get_temp_path(f'result.flac'), 'wb') as file_:
    file_.write(fileobj.read())

Run the test with TORCHAUDIO_TEST_TEMP_DIR=<some_directory> pytest torchaudio_unittest.backend.soundfile.save_test.TestFileObject -k flac so that intermediate files are saved after the test run.
Open the test.flac and result.flac with Audacity and check the signal shape. They are supposed to be linear.

I appears that soundfile is using "PCM_16" as default (link) when None is passed to subtype, and the default for PCM_24 is used for torchaudio.
I think the fix is to change this line
https://github.com/pytorch/audio/blob/533c2d47f7c03370a26b9744f9ec2093857fc43a/test/torchaudio_unittest/backend/soundfile/save_test.py#L266
to something like
        subtype = None
        if ext == 'wav':
            subtype = 'FLOAT'
        elif ext == 'flac':
            subtype = 'PCM_24

authors: mthrok yangarbiter

repo: pytorch/audio


text:
Camembert config and pytorch model

❓ Questions and Help
Hi @louismartin ,
I have read your paper and huggingface library about Camembert and it is very interesting!
I'm training a new RoBERTa model with fairseq library based also on the suggestions of your paper and I obtained the following files:

dict.txt: vocabulary coming from the sentencepiece model
sentencepiece.bpe.model
checkpoint_best.pt

However when I'm trying to load the model through the hugging face library CamembertModel as following:
model_path = "directory/to/checkpoints" model = CamembertModel.from_pretrained(model_path)
I get errors related to missing config.json file and pytorch_model.bin.
How did you get these files?
Currently, using the config.json from roberta (changing the vocabulary size) and saving my file checkpoint_best.py as pytorch_model.bin I resolved the errors but I'm not sure whether this approach is correct.
Could you provide more informations about it?
Thanks in advance!

You probably need to use the conversion script in the transformers library: https://github.com/huggingface/transformers/blob/master/transformers/convert_roberta_original_pytorch_checkpoint_to_pytorch.py

You probably need to use the conversion script in the transformers library: https://github.com/huggingface/transformers/blob/master/transformers/convert_roberta_original_pytorch_checkpoint_to_pytorch.py

Exactly, the config.json file is created with this conversion script

Thanks for the reply. I tried the script; however when I run the assert line 81
assert(roberta_layer.self_attn.in_proj_weight.shape == torch.Size((3 * config.hidden_size, config.hidden_size)))
It gives me an attribute error: AttributeError: 'MultiheadAttention' object has no attribute 'in_proj_weight'
Should I install a specific version of transformers or fairseq?
Furthermore, in the script snippet
config = BertConfig(         vocab_size=50265,         hidden_size=roberta.args.encoder_embed_dim,         num_hidden_layers=roberta.args.encoder_layers,         num_attention_heads=roberta.args.encoder_attention_heads,         intermediate_size=roberta.args.encoder_ffn_embed_dim,         max_position_embeddings=514,         type_vocab_size=1,         layer_norm_eps=1e-5, # PyTorch default used in fairseq     )
a vocab_size of 50265 is hard coded. I changed it based on my vocab size but maybe It would be awesome to set it as a parameter.
Thanks again for everything!

Hi @LeoDeep and all,
There's a known issue with the huggingface/transformers converter that will be resolved soon. Will also post here when done. Cheers!

Thanks for your reply @julien-c . I will keep looking at the issue in order to stay updated on the topic. Cheers to all and thanks for what you are doing

Hi @LeoDeep this is now fixed on master by https://github.com/huggingface/transformers/pull/1959

Hi @julien-c thanks for the update!
The script now is working like a charm.
Then I successfully loaded the model with the standard procedure as follow:
model = RobertaModel.from_pretrained("/content/model_folder")
I just have a concern when using the model RobertaForMaskedLM with
modelMaskedLM = RobertaForMaskedLM.from_pretrained('/content/pytorch_dump_folder')
The config files is loaded correctly but I receive some Info warnings about weights not initialized and used:
INFO:transformers.modeling_utils:loading weights file /content/pytorch_dump_folder/pytorch_model.bin
INFO:transformers.modeling_utils:Weights of RobertaForMaskedLM not initialized from pretrained model: ["lm_head.decoder.weight"]
INFO:transformers.modeling_utils:Weights from pretrained model not used in RobertaForMaskedLM: ["lm_head.weight"]
Reading https://github.com/huggingface/transformers/blob/master/transformers/modeling_utils.py (line 67) it makes sense not having some initialized weights for example if I'm loading the model for a SequenceClassificationTask. However, since the conversion script initializes a RobertaMaskedLM (I didn't use the classification head parameter) does it comes already with this weights? Should they be already availble from my saved pytorch_model.bin file?
Additional Info: I have the same behaviour when loading the standard roberta-base model.
Thanks again!

Which checkpoint exactly are you loading?
[If you want, you can share the checkpoint using our newly released upload CLI]

The process that I'm using is:

Taking checkpoint_best.pt from Roberta training (trained using the standard procedure fairseq-train https://github.com/pytorch/fairseq/blob/master/examples/roberta/README.pretraining.md
Convert it in config.json and pytorch_model.bin through the new updated scripts
Loading with  modelMaskedLM = RobertaForMaskedLM.from_pretrained("/content/pytorch_dump_folder")

Then I receive the INFO warning described. I also checked the lines (138 to 143) where weights from roberta are passed to hugging face model and it looks everything correct.
I don't know if this strange behaviour is related to my checkpoint but I received the warning even if I'm running your default roberta-base files:
modelTest = RobertaForMaskedLM.from_pretrained("roberta-base")
This is the output:
INFO:transformers.modeling_utils:loading weights file https://s3.amazonaws.com/models.huggingface.co/bert/roberta-base-pytorch_model.bin from cache at /root/.cache/torch/transformers/228756ed15b6d200d7cb45aaef08c087e2706f54cb912863d2efe07c89584eb7.49b88ba7ec2c26a7558dda98ca3884c3b80fa31cf43a1b1f23aef3ff81ba344e
INFO:transformers.modeling_utils:Weights of RobertaForMaskedLM not initialized from pretrained model: ['lm_head.decoder.weight']
INFO:transformers.modeling_utils:Weights from pretrained model not used in RobertaForMaskedLM: ['lm_head.weight']
I just have found also another issue here https://github.com/huggingface/transformers/issues/2202 that is reporting the same behaviour.

Thanks for investigating! This is now fixed, cf. https://github.com/huggingface/transformers/issues/2202

Tested and It works perfectly. I think it's time to close this issue!
Thanks again for your everything. Cheers to all!

Is there a way to convert from a PyTorch bin (obtained with Huggin Face) to a Roberta model? When I run this script:
from fairseq.models.roberta import RobertaModel
roberta= RortaModel.from_pretrained('/path/to/checkpoint/folder/',checkpoint_file='pytorch_model.bin')

I got this error:
File "/usr/local/lib/python3.6/dist-packages/fairseq/checkpoint_utils.py", line 162, in load_checkpoint_to_cpu
    args = state["args"]
KeyError: 'args'

I think I have the opposite problem

Indeed there's no conversion script in the opposite direction.
It should be pretty easy to do it yourself though.

@julien-c great thread this has come out to be.
What I want to do is pretrain Roberta from scratch using G-Cloud tpu with fairseq.
Then convert those .pt weights to pytorch.bin
What I want is I am using tensorflow or inference.
I convert pytorch.bin weights to tf_model.h5 right ?
OR can I directly convert .pt model to tensorflow_model.h5 etc ?
Thanks

Hi, I try to use the camembert-base model in order to fine tune it on my data. But I'm facing the same issue.
I downloaded camembert-base and in the folder I had the following files : dict.txt, model.pt and sentencepiece.bpe.model.
But When I launched this line :
lm_learner = BertLMLearner.from_pretrained_model(                             dataBunch=databunch_lm,                             pretrained_path='model/camembert-base',                             output_dir=MODEL_PATH,                             metrics=[],                             device=device_cuda,                             logger=logger,                             multi_gpu=False,                             logging_steps=50,                             is_fp16=False)
An error occured telling me that the config.json and pytorch_model.bin are missing. So I went to the git repo and I found the file configuration_camembert.py and found the following link : "camembert-base": "https://s3.amazonaws.com/models.huggingface.co/bert/camembert-base-config.json" where I got the config.json. And for the pytorch.bin model as I didn't find the file convert_camembert_to_pytorch I just went on this link "https://s3.amazonaws.com/models.huggingface.co/bert/camembert-base-pytorch_model.bin" and I found it. Why the convert file is missing for camembert-base but available for the other models (bert, roberta ...)
After I've done that I could launch the previous code but I faced this warning :
Some weights of CamembertForMaskedLM were not initialized from the model checkpoint at model/camembert-base and are newly initialized: ['lm_head.decoder.bias'] You should probably TRAIN this model on a down-stream task to be able to use it for predictions and inference.
Any suggestions, please ?
Thanks in advance for your answers :)

Did you try using the default 'camembert-base' shortcut instead of downloading the model manually and providing the full path 'model/camembert-base'?
lm_learner = BertLMLearner.from_pretrained_model( dataBunch=databunch_lm, pretrained_path='camembert-base', output_dir=MODEL_PATH, metrics=[], device=device_cuda, logger=logger, multi_gpu=False, logging_steps=50, is_fp16=False)

The warning is not a problem I think, it only says that the bias of the decoder of the lm head is initialized at random but it's not a problem if you are going to finetune it on your own data.

Yes I tried the default "camembert-base" shortcut and I face the same warning.
I'm just a bit worried that the model would be less performant with this warning, don't you think ?

The lm_head.decoder.bias is probably composed of very few weights so I don't think it's a problem.

@paulthemagno did you end up writing code for a conversion in the opposite direction? If so, it would be great if you could share it :)

@paulthemagno same here. I also need a script in the opposite direction.

authors: LeoDeep Yasminabouzbiba ajmeraji julien-c louismartin manueltonneau muhammadfahid51 myleott paulthemagno

repo: pytorch/fairseq

license: mit

license_source: bigquery


text:
Distributed training on tiny debug dataset with n_data < N_GPUs * batch_size fails silently due to unset dummy batch

The EpochBatchIterator uses empty lists as a fill value for the ShardedIterator used for distributed training. Normally this is handled by replacing the empty list by a dummy batch in Trainer.train_step, which in turn is set as the first batch the Trainer ever sees. However, if you're debugging distributed training with a mini dataset of size n_data < N_GPUs * batch_size, some Trainers will receive an empty list as their first ever batch and feed it straight to the model, which then breaks.
The breaking part is of course fine, all that's needed is to reduce batch size or increase dataset size, but if you're not familiar with the FairSeq internals (as was the case for me when this originally happened) this can be rather an opaque problem to debug, especially since distributed training tends to be challenging to debug already.
I'd suggest explicitly raising an exception with a suggestive error message if the dummy batch is none or empty when sample is none in Trainer.train_step.
To Reproduce
Run any distributed training command on data with n_data < N_GPUs * batch_size

Great idea, this is a known problem but I like your proposed solution


text:
How do I keep pre-training mBART?

Can you provide the script I can use to keep pretraining mBART? For example if I want to do more pretraining on one language, or to add a new language?
Thank you!

Can you provide the script I can use to keep pretraining mBART? For example if I want to do more pretraining on one language, or to add a new language?
Thank you!

Hello,
Have you got some updates?

Can you provide the script I can use to keep pretraining mBART? For example if I want to do more pretraining on one language, or to add a new language?
Thank you!

Hello,
Have you got some updates?

hello, have you got any progress?

authors: SunbowLiu firdota moyid


text:
Can we support class weight in the CEWithChunkedOutputLoss class

I am trying to add weights to the loss function. I think it would be nice to have it in the class function? The original class CrossEntropyLoss has weight as an arg.

This seems like a good idea - thanks @ye-jin-shop!
Just so I fully understand what you're trying to do, can you provide a small code example of how you would be using this weight argument?

This should be easy. We can add *args, **kwargs to the init, and something like this should work
class CEWithChunkedOutputLoss(torch.nn.Module):
  def __init__(self, num_output_chunks: int = 8, ignore_index: int = -100, *args, **kwargs):
          super().__init__()
          self.num_output_chunks = num_output_chunks
          self.ignore_index = ignore_index
          self.args = args
          self.kwargs = kwargs

      def compute_cross_entropy(
          self, logits: torch.Tensor, labels: torch.Tensor
      ) -> torch.Tensor:
          """
          Upcast logits to fp32 and compute cross entropy loss.
          """
          return F.cross_entropy(
              logits.float(), labels, ignore_index=self.ignore_index, *args, **kwargs
          )

i can test something like this next week, but if you want to contribute directly, i would be glad to review your PR. Let me know and i can give some pointers. Otherwise, i will post here when i get back to this

Hey @felipemello1. I am having other priorities right now. I will leave this to you (not urgent, but nice to have). Thank you for your support!

authors: felipemello1 joecummings ye-jin-shop

repo: pytorch/torchtune


text:
Disabling LoRA with compiled models

In PEFT, we've encountered a bunch of issues with LoRA when using compiled models. I was curious how torchtune solves these issues, so I checked one of them, namely disabling the LoRA adapter. It seems that torchtune runs into the same issue, as disabling does not work with compiled models.
To show this bug, I added the following tests to test_lora.py:
# torch v2.2.2
from torchtune.modules.peft.peft_utils import disable_adapter

...

    def test_disable_lora(self, inputs, lora_linear) -> None:
        enabled = lora_linear(inputs)

        with disable_adapter(lora_linear):
            disabled = lora_linear(inputs)

        # passes
        assert not torch.allclose(enabled, disabled, atol=1e-4, rtol=1e-4)

    def test_disable_lora_compiled(self, inputs, lora_linear) -> None:
        with disable_adapter(lora_linear):
            disabled_no_compile = lora_linear(inputs)

        lora_linear = torch.compile(lora_linear)
        enabled = lora_linear(inputs)

        with disable_adapter(lora_linear):
            disabled_compile = lora_linear(inputs)

        # both asserts fail
        assert not torch.allclose(enabled, disabled_compile, atol=1e-4, rtol=1e-4)
        torch.testing.assert_close(disabled_no_compile, disabled_compile)

For me, the first test for disabling LoRA works, as it doesn't use torch.compile. However, the second test fails, disabling has no effect on the model. Can you confirm that this is indeed an issue and are there any ideas/plans to resolve this in torchtune or PyTorch?

@BenjaminBossan thanks so much for this really interesting issue. @yf225 mentioned that he'd be very interested in taking a look at this. So I'll let him comment more intelligently on what might be going on here.

Looked into the issue - it's because torch.compile doesn't currently guard on the user NN module attribute (in this case .disabled), and thus mutating the attribute value did not trigger a recompile, which causes compiled output to be different from eager output.
Opened an issue on PyTorch github repo: https://github.com/pytorch/pytorch/issues/124717, we will follow up on this soon.

This should be fixed now per https://github.com/pytorch/pytorch/issues/124717#issuecomment-2157261609.

authors: BenjaminBossan kartikayk yf225


text:
Add changes to support MM eval

Context
What is the purpose of this PR? Is it to

[x] add a new feature
[ ] fix a bug
[ ] update tests and/or documentation
[ ] other (please add here)

Please link to any issues this PR addresses.
Changelog
What are the changes made in this PR?
*
Test plan
Please make sure to do each of the following if applicable to your PR. If you're unsure about any one of these just ask and we will happily help. We also have a contributing page for some guidance on contributing.

[x] run pre-commit hooks and linters (make sure you've first installed via pre-commit install)
[ ] add unit tests for any new functionality
[ ] update docstrings for any new or updated methods or classes
[ ] run unit tests via pytest tests
[x] run recipe tests via pytest tests -m integration_test
[x] manually run any new or modified recipes with sufficient proof of correctness
[ ] include relevant commands and any other artifacts in this summary (pastes of loss curves, eval results, etc.)

UX
If your function changed a public API, please add a dummy example of what the user experience will look like when calling it.
Here is a docstring example
and a tutorial example

[ ] I did not change any public API
[ ] I have added an example to docs or docstrings

please, if you make changes, and they are applicable to the other class, we should probably keep them in sync

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

Project coverage is 26.08%. Comparing base (50b24e5) to head (5df9212).
Report is 13 commits behind head on main.

Files with missing lines
Patch %
Lines

recipes/eleuther_eval.py
0.00%
173 Missing :warning:

tests/recipes/test_eleuther_eval.py
42.85%
4 Missing :warning:

Additional details and impacted files
@@             Coverage Diff             @@
##             main    #1669       +/-   ##
===========================================
- Coverage   71.11%   26.08%   -45.03%
===========================================
  Files         297      299        +2
  Lines       15120    15383      +263
===========================================
- Hits        10752     4013     -6739
- Misses       4368    11370     +7002

Flag
Coverage Δ

26.08% <1.66%> (-45.03%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

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

very very nice

What's a guy gotta do to see some outputs round here?

|                 Tasks                 |Version|Filter|n-shot|Metric|   |Value |   |Stderr|
|---------------------------------------|------:|------|------|------|---|-----:|---|-----:|
|mmmu_val                               |      0|none  |      |acc   |↑  |0.3233|±  |0.0271|
| - Art and Design                      |      0|none  |      |acc   |↑  |0.2000|±  |0.0656|
|  - Art                                |      0|none  |None  |acc   |↑  |0.1000|±  |0.1000|
|  - Art Theory                         |      0|none  |None  |acc   |↑  |0.2000|±  |0.1333|
|  - Design                             |      0|none  |None  |acc   |↑  |0.2000|±  |0.1333|
|  - Music                              |      0|none  |None  |acc   |↑  |0.3000|±  |0.1528|
| - Business                            |      0|none  |      |acc   |↑  |0.3200|±  |0.0680|
|  - Accounting                         |      0|none  |None  |acc   |↑  |0.3000|±  |0.1528|
|  - Economics                          |      0|none  |None  |acc   |↑  |0.3000|±  |0.1528|
|  - Finance                            |      0|none  |None  |acc   |↑  |0.2000|±  |0.1333|
|  - Manage                             |      0|none  |None  |acc   |↑  |0.5000|±  |0.1667|
|  - Marketing                          |      0|none  |None  |acc   |↑  |0.3000|±  |0.1528|
| - Health and Medicine                 |      0|none  |      |acc   |↑  |0.3600|±  |0.0706|
|  - Basic Medical Science              |      0|none  |None  |acc   |↑  |0.3000|±  |0.1528|
|  - Clinical Medicine                  |      0|none  |None  |acc   |↑  |0.5000|±  |0.1667|
|  - Diagnostics and Laboratory Medicine|      0|none  |None  |acc   |↑  |0.3000|±  |0.1528|
|  - Pharmacy                           |      0|none  |None  |acc   |↑  |0.3000|±  |0.1528|
|  - Public Health                      |      0|none  |None  |acc   |↑  |0.4000|±  |0.1633|
| - Humanities and Social Science       |      0|none  |      |acc   |↑  |0.4000|±  |0.0791|
|  - History                            |      0|none  |None  |acc   |↑  |0.2000|±  |0.1333|
|  - Literature                         |      0|none  |None  |acc   |↑  |0.5000|±  |0.1667|
|  - Psychology                         |      0|none  |None  |acc   |↑  |0.4000|±  |0.1633|
|  - Sociology                          |      0|none  |None  |acc   |↑  |0.5000|±  |0.1667|
| - Science                             |      0|none  |      |acc   |↑  |0.3000|±  |0.0585|
|  - Biology                            |      0|none  |None  |acc   |↑  |0.2000|±  |0.1333|
|  - Chemistry                          |      0|none  |None  |acc   |↑  |0.0000|±  |0.0000|
|  - Geography                          |      0|none  |None  |acc   |↑  |0.2000|±  |0.1333|
|  - Math                               |      0|none  |None  |acc   |↑  |0.4000|±  |0.1633|
|  - Physics                            |      0|none  |None  |acc   |↑  |0.7000|±  |0.1528|
| - Tech and Engineering                |      0|none  |      |acc   |↑  |0.3429|±  |0.0583|
|  - Agriculture                        |      0|none  |None  |acc   |↑  |0.2000|±  |0.1333|
|  - Architecture and Engineering       |      0|none  |None  |acc   |↑  |0.4000|±  |0.1633|
|  - Computer Science                   |      0|none  |None  |acc   |↑  |0.4000|±  |0.1633|
|  - Electronics                        |      0|none  |None  |acc   |↑  |0.3000|±  |0.1528|
|  - Energy and Power                   |      0|none  |None  |acc   |↑  |0.4000|±  |0.1633|
|  - Materials                          |      0|none  |None  |acc   |↑  |0.2000|±  |0.1333|
|  - Mechanical Engineering             |      0|none  |None  |acc   |↑  |0.5000|±  |0.1667|

source: gharchive/pull-request

authors: SalmanMohammadi codecov-commenter felipemello1 joecummings


text:
fp16 for deform_conv2d missing?

🐛 Bug

To Reproduce
This example below is copy pasted from https://pytorch.org/docs/stable/torchvision/ops.html
except dtypes are added.
The first part with float32 runs fine, but the second part with float16
produces error:

File "/home/hu-mka/venvs/pytorch/lib/python3.8/site-packages/torchvision/ops/deform_conv.py", line 67, in deform_conv2d
return torch.ops.torchvision.deform_conv2d(
RuntimeError: th_addmm not supported on CPUType for Half

Terveisin, Markus
input = torch.rand(5, 3, 10, 10, dtype=torch.float32)
kh, kw = 3, 3
weight = torch.rand(5, 3, kh, kw, dtype=torch.float32)
offset = torch.rand(5, 2 * kh * kw, 8, 8, dtype=torch.float32)
out = ops.deform_conv2d(input, offset, weight)
print(out)
input = torch.rand(5, 3, 10, 10, dtype=torch.float16)
kh, kw = 3, 3
weight = torch.rand(5, 3, kh, kw, dtype=torch.float16)
offset = torch.rand(5, 2 * kh * kw, 8, 8, dtype=torch.float16)
out = ops.deform_conv2d(input, offset, weight)
print(out)

Environment
(pytorch) hu-mka@humkaLenovo:~/Downloads$ python collect_env.py
Collecting environment information...
PyTorch version: 1.6.0
Is debug build: False
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A
OS: Ubuntu 20.04.1 LTS (x86_64)
GCC version: (Ubuntu 8.4.0-3ubuntu2) 8.4.0
Clang version: 10.0.0-4ubuntu1
CMake version: version 3.16.3
Python version: 3.8 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: 10.1.105
GPU models and configuration: GPU 0: GeForce GTX 1650 with Max-Q Design
Nvidia driver version: 450.80.02
cuDNN version: Probably one of the following:
/usr/local/cuda-10.0/targets/x86_64-linux/lib/libcudnn.so.7.6.5
/usr/local/cuda-10.1/targets/x86_64-linux/lib/libcudnn.so.7.6.5
HIP runtime version: N/A
MIOpen runtime version: N/A
Versions of relevant libraries:
[pip3] numpy==1.19.0
[pip3] pytorch-lightning==0.9.0
[pip3] torch==1.6.0
[pip3] torchfunc==0.2.0
[pip3] torchsummary==1.5.1
[pip3] torchvision==0.7.0
[pip3] torchviz==0.0.1
[conda] numpy                     1.19.1                   pypi_0    pypi

Thanks for opening the issue!
That's correct, for now we don't yet have mixed precision for deform_conv2d, but we should be adding support for it soon (together with the remaining ops that don't support it yet).

Thank you guys!!! Perfect timing!

repo: pytorch/vision


text:
Port test resize in test_transforms to pytest

Refactor Group J as mentioned in #3945

test_randomresized_params
test_resize

Thanks a lot @NicolasHug for the feedback, I'll make these changes and update the PR.
Btw, if possible, could you please help me with #3963 (Not Related to this PR)?

Sorry for the delay @NicolasHug. This is now ready for review. Please let me know if there are some changes you would like to suggest. Thanks a lot for being patient and guiding me through! :))


text:
Add --offline option

safety-db is now installable via pip, add it as an option.

I'd like to +1 this suggestion, and ask for a built-in option to use safety-db, as it allows external sources of build failure to be managed with dependabot like other external dependencies changing, rather than suddenly breaking a codebase which previously passed tests (although I understand that can be considered a feature in vulnerability scanning).

authors: efokschaner jayfk

repo: pyupio/safety


text:
usb.util.find_descriptor return NoneType

Discussed in https://github.com/pyusb/pyusb/discussions/428

Originally posted by DataconTom June  8, 2022

Please don't create a duplicate issue for a discussion unless it has already been concluded (in that discussion) that there's an actual bug or feature to be reported/requested.

authors: DataconTom jonasmalacofilho

repo: pyusb/pyusb


text:
Endpoint URLs not being updated from Datahub?

The Uniprot endpoint URL was updated in Datahub:
http://datahub.io/dataset/uniprot/resource/9acc7660-3c26-4fa5-b0dc-6f142455d6ba
The previous URL was http://beta.sparql.uniprot.org
The new URL is http://sparql.uniprot.org
The update was on 2015-07-22, but on 2015-07-31, the old endpoint is still appearing stating "Last update: Fri, 31 Jul 2015 12:00:52 GMT". The new endpoint has not appeared yet.
(Check that updates from DataHub are being considered correctly, and that the aggregate views are seeing and propagating those changes.)
[Reported by Thierry Lombardot by email]

The new endpoint appears in the system and the old one no longer does.

repo: pyvandenbussche/sparqles


text:
Release 0.1.9

Hi @pyvista/maintainers, pinging @germa89 for visibility.
I was wondering if I could make a release for the plugin, since we need to use the new flag introduced in #82
If that's okay, I will proceed.

Should we also get #80 in there?

Yes, that's a good idea! Let's merge that first

#80 is ready to merge (once green check blessing)

We should include also https://github.com/pyvista/pytest-pyvista/pull/87

I think we are all set.  Thanks all!

Close as it is released.

repo: pyvista/pytest-pyvista


text:
multibyte characters in widgets are not working

desired result:

(Label in chart title is equal to one in selection box, and it is corresponding)
actual result:

Now I'm facing two different problems:

Nothing happened when I select item in selection box
displayed character in selection box is garbled

To solve problem 1, I think you need to put ensure_ascii=False for json.dumps at L463 in holoviews/plotting/widgets/__init__.py
To solve second one, static_template at L64 in holoviews/plotting/renderer.py should be
static_template = """
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    {css}
    {js}
  </head>
  <body>
    {html}
  </body>
</html>
"""

My code is here:
import pandas
import holoviews
import bokeh
import hvplot.pandas

print('pandas', pandas.__version__)
print('holoviews', holoviews.__version__)
print('bokeh', bokeh.__version__)

holoviews.extension('bokeh')

df = pandas.DataFrame({
    'a': ['あ', 'あ', 'あ', 'あ', 'あ', 'い', 'い', 'い', 'い', 'う', 'う', 'う'],
    'b': [10, 11, 12, 11, 10, 20, 21, 22, 21, 31, 32, 31],
    'c': [0, 1, 2, 1, 0, 0, -1, -2, -1, 1, 2, 3]
})
line_plot_groupby = df.hvplot.line(x='c', y='b', groupby='a', dynamic=False)
renderer = holoviews.renderer('bokeh')
renderer.save(line_plot_groupby, 'line_plot_groupby')

pandas 0.25.0
holoviews 1.2.9.post67+g7dd50144
bokeh 1.3.1

Thanks for the detailed bug report. Would you be willing to submit a PR for the fixes?

Actually nevermind, the widgets are about to be replaced entirely.

Thanks for your reply.
I gave up submit PR for the fixes because it was really difficult to understand how my code should be tested.
Additionally, I think problem can be solved by two different approaches:

fix python code to dump json
fix javascript code to load json

I don't know which approach is better for holoviews. So I just put issue.

authors: archiba philippjfr

repo: pyviz/holoviews


text:
Refactored datashader operations and add new aggregators

Some refactoring of datashader operations to make it easier to implement new operations. Additionally adds an operation to aggregate Spikes:
Handles simple spikes:

Handles datetimes:

Handles Spikes with vdims:

[x] Add tests
[x] Add Spikes aggregator with and with values and positive and negative heights
[ ] Add Area aggregator
[ ] Add Spread aggregator
[ ] Add docs

Cc: @jlstevens @jbednar

so I'm not sure if it's worth implementing this more generally here already in anticipation?

I haven't changed anything about this and don't intend to.

Mostly wanted to do this so I can more easily implement the Segments aggregator in #3532.

Do need to know whether this addresses @jlstevens' needs though. I think to do what he was doing you need to create an NdOverlay of rasterized spikes with each with a fixed y_range and a RangeX stream.

Would also like to compare performance to Jean-Luc's implementation, here's 10x1M spikes:

I haven't changed anything about this and don't intend to.

Ok. It showed up in the new stuff, but was probably just reformatted.  Your description of of Jean-Luc's needs sounds accurate to me, but I'll let him weigh in on that.

Updated the gif, dask appears slower than pure pandas here.

Once we have segments it'll probably might be more (computationally but not memory) efficient to precompute a Segments element to represent Jean-Luc's plot type, because it can represent the upper and lower end of each event.

It showed up in the new stuff, but was probably just reformatted.

Yeah, lots of refactoring happening in this PR.

Am I right that this should make datashading the Area and Spread elements easier?  When I looked at it briefly a few months ago it looked like handling a variable number of kdims didn't fit well into the old structure.

Am I right that this should make datashading the Area and Spread elements easier?

In some ways yes, but I'll probably have to do some more refactoring to get those done. That said I might tackle those in this PR as well.

This is fantastic, thanks!
From the title of the PR, I was still expecting to implement spikes support on top of the refactored code so it is a pleasant surprise to see that Spikes support is what is being added here!

I think to do what he was doing you need to create an NdOverlay of rasterized spikes with each with a fixed y_range and a RangeX stream.

That is exactly the approach I am currently using. As for performance, I'll check out this branch to compare but I doubt there will be much difference. If what I am currently using is significantly faster for some reason, I'll report back.

Area and Spread aggregation now also done, will add some tests and then document those in the Large Data guide.

Ready to review and merge.

Cool, thanks!

Will add some more tests in the morning.

@philippjfr Thanks for all this! I see you have now added some unit tests and the travis tests are green. Merging.

authors: jbednar jlstevens jonmmease philippjfr


text:
where use "uia" backend, identify a control cost a long time.  It traverse all the control

Expected Behavior
app = Applicaion(backend="uia")
dlg = app["Dialog"]
dlg["Button1"].click_input()
it traverse all the control, like combobox will expand
dlg["Button2"].click_input()
it shouldn't traverse all the control
Actual Behavior
it traverse again, the combobox in the dialog expand again
Steps to Reproduce the Problem

Short Example of Code to Demonstrate the Problem
Specifications

Pywinauto version:
Python version and bitness:
Platform and OS:

app["Dialog"] it's only, so called, window specification - think about as a search criteria. So any time you work with it the control should be resolved again. Try to save a wrapper object of your dialog with: dlg = app["Dialog"].wrapper_object() and use it after.

repo: pywinauto/pywinauto


text:
missing bech32 depedency

Just added this gem to my repo, I also had to add bech32 as a gem.

Hi, could you elaborate on what your gem is and why it requires bech32? The eth gem does not implement any functionality that relies on bech32.

oh, I guess I'm pulling in https://github.com/se3000/ruby-eth instead of this newer gem. I'm confused then, both libraries say to install via gem install eth...

Ah right. You need to install eth 0.5.0 or later.

maybe worth noting that in https://github.com/q9f/eth.rb#installation ? anywise, feel free to close the ticket. I'm all set with this:
gem "eth", "~> 0.5.10", github: "q9f/eth.rb"


text:
Cant uninstall HACC

Description

It isnt possible to uninstall HACC
Environment
<What version of HACC are you running?>
<What environment is it? Hass.io on a Raspberry Pi 3B+? AMD64 Docker on Alpine 3.10?>
Hassio on RPI4
Steps to Reproduce

List out the
Steps to take to
Reproduce the issue

please see
https://community.home-assistant.io/t/hacc-home-assistant-command-center/134843/184?u=mariusthvdb
19-09-18 08:00:09 INFO (SyncWorker_2) [hassio.docker.interface] Remove image qjake/hacc-hassio-armv7 with latest and
19-09-18 08:00:09 WARNING (SyncWorker_2) [hassio.docker.interface] Can't remove image qjake/hacc-hassio-armv7: 400 Client Error: Bad Request ("invalid reference format")

```## Screenshots

<Paste or upload screenshots here.>

This is a known issue, waiting on this thread for a fix: https://github.com/home-assistant/hassio/issues/1280

Keeping open.

why was this closed??
bug is still alive and kicking on 101.2, as I have also reported on https://github.com/home-assistant/hassio/issues/1280

@Mariusthvdb The stale bot is a bit aggressive. I'll check the settings.
If you add a comment on a stale issue, it will "refresh" it, so to speak.

this is still an issue, so please keep open

Keep open.

As of Feb 7, I identified and fixed this issue. It will be released with v1.0 (or, tentatively being called "v1.1" now since there has been a lot of beta testing with "v1.0" already).
Closing as fixed!

Unfortunately I ran into the same problem. After I installed the addon HACC 0.6 I noticed that I could beter install the beta 1.019.
Uninstalling the addon results in an error. I tried to delete the container in portainer, update Home assistant and reboot the host as @Mariusthvdb mentioned in https://github.com/home-assistant/supervisor/issues/1280#issuecomment-558605230 suggested.
Unfortunately that didn't help.  Is there a way how i can remove the addon?

@nelbs You'll have to wait for a newer version (e.g. 1.0) to come out. The issue was in the addon configuration, and that is only fixed in the newer images that we have not released officially yet.
I want to say that someone else found a workaround for how to remove it but I'm not sure where or how exactly.

authors: Mariusthvdb nelbs qJake


text:
HADotNet - fix for empty sequence exception

Hi @qJake ,
I found a couple of issues when running a fresh installation related to empty sequence exception, please take a look at my simple suggestions.
Thanks

Thanks for fixing this!

authors: imalkevich qJake

repo: qJake/HADotNet


text:
Update MoxUnit

Following Matlab's change to remove support for external access to other scripts subfunctions, Octave 6.0+ reflected the same changes.
This breaks compatibility with the current MoxUnit version we have. The latest MoxUnit fixes this issue.

Another compatibility alert:
warning: isstr is obsolete and will be removed from a future version of Octave, please use ischar instead

Another compatibility alert:
warning: isstr is obsolete and will be removed from a future version of Octave, please use ischar instead

#422

#422

repo: qMRLab/qMRLab


text:
🛑 nitter.domain.glass is down

In 79295a0, nitter.domain.glass (https://nitter.domain.glass) was down:

HTTP code: 503
Response time: 297 ms

Resolved: nitter.domain.glass is back up in 6712e97 after 5 minutes.


text:
🛑 nitter.projectsegfau.lt is down

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

HTTP code: 503
Response time: 809 ms

Resolved: nitter.projectsegfau.lt is back up in 57a95ee after 28 minutes.


text:
🛑 nitter.projectsegfau.lt is down

In 7c9e3fa, nitter.projectsegfau.lt (https://nitter.projectsegfau.lt) was down:

HTTP code: 503
Response time: 388 ms

Resolved: nitter.projectsegfau.lt is back up in f803cc2 after 23 minutes.


text:
🛑 nitter.tiekoetter.com is down

In 66157ac, nitter.tiekoetter.com (https://nitter.tiekoetter.com) was down:

HTTP code: 502
Response time: 886 ms

Resolved: nitter.tiekoetter.com is back up in e15000d.


text:
🛑 notabird.site is down

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

HTTP code: 520
Response time: 95 ms

Resolved: notabird.site is back up in a98cbf9.


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

In cb66851, 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 65a490a after 16 minutes.


text:
Add missing integration tests

Add integration tests for the following topics:

Strategy deletion:
[x] MarathonReplaceStrategyIntegrationTest.testDelete()
[x] KubernetesReplaceStrategyIntegrationTest.testDelete()
[x] KubernetesResetStrategyIntegrationTest.testDelete()
Strategy update:
[x] GroupResourceIntegrationTest.testUpdate()
[x] AppResourceIntegrationTest.testUpdate()
[x] MarathonUpdateStrategyIntegrationTest
[x] KubernetesUpdateStrategyIntegrationTest
Deployer (use the test project to test them - should test everything):
[x] MarathonDeployer
[x] KubernetesDeployer

Implemented.

repo: qaware/gradle-cloud-deployer


text:
Does not work after update to Obsidian 1.2.7

Just updated to Obsidian 1.2.7 and the plugin does not work any more. All that happens is the obsidian search, cards are not displayed. Tried setting manual preview changing the display option (single vs cards etc). Nothing.

You might find Obsidian Float Search https://github.com/Quorafind/Obsidian-Float-Search. I love it.

Thank you! Great plugin, I rely on this a lot!

authors: tprotopopescu writtenfool


text:
支持elasticsearch7？

你好。请问支持最新的7吗

您好，我的开源项目 https://github.com/1340691923/ElasticView 支持ES7

repo: qax-os/ElasticHD


text:
Autofit cell width/height

Description
In excel, it is possible to autofit cell (column/row) size by double-clicking on the cols/rows border. Is it possible to add such a feature in excelize?
Output of go version:
go version go1.18.4 linux/amd64

Environment details (OS, Microsoft Excel™ version, physical, etc.):
OS: Fedora linux 36
opening xlsx files via LibreOffice but I suppose it doesn't metter here

This issue was duplicated with #92, #204, and #1209. I will close this issue and move on to discuss #92.

repo: qax-os/excelize


text:
Fix database upload

There seems to be a problem when uploading files directly from the database.
When i download the same file and upload it from the file system it works.

 Fix database upload of epitope-prediction files

#15

repo: qbicsoftware/vaccine-designer


text:
Remove Old Examples

We want to have less examples, which are cleaner and can be easily maintained.
List of examples removed:
Quickstart Text Search: Qdrant + Gemini
Quickstart Image Search: Qdrant + HuggingFace Spaces
Serverless Semantic Search
RAG with Qdrant and OpenAI
LangChain Chatbot
LangChain Step Back Prompting

@kacperlukawski I can create an archive repo with old code that you can refer back to.

@kacperlukawski I can create an archive repo with old code that you can refer back to.

They'll be visible in the repo history, so there is no need to ;)

authors: davidmyriel kacperlukawski

repo: qdrant/examples


text:
Add GDPR info in documentation page

Fix for #410

Looks like a good solution. Thank you.

authors: Xpirix anitagraser

repo: qgis/QGIS-Website


text:
IMP: Merging metadata handles overlapping metadata column names

Metadata files with overlapping column names can now be merged.
NOTE: This breaks some tests in q2cli, and it was not immediately apparent for myself or @ebolyen as to exactly where and why it broke those tests.

One thing that concerns me about this approach is that now the order of files specified really matters. If a user changes their specification order, well, they can wind up with totally different results. Some options:

maybe we can come up with deterministic sorting within the merge functionality?
generate some kind of hash-based id to refer to each metadata

Thoughts?

NOTE: This breaks some tests in q2cli, and it was not immediately apparent for myself or @ebolyen as to exactly where and why it broke those tests.

BTW, the test failures in q2cli maybe aren't surprising, there are a few tests specific to that interface's automatic merging functionality: https://github.com/qiime2/q2cli/blob/master/q2cli/tests/test_cli.py

What I am concerned about above is the case where a user accidentally swaps the order of their files in an invocation (using the cli here as an example, but the same issue applies when merging manually in the artifact API):
qiime longitudinal anova \
  --m-metadata-file faith_pd_a.qza \
  --m-metadata-file faith_pd_b.qza \
  --m-metadata-file sample_metadata.tsv \
  --p-formula " 'faith_pd [1]' ~ some_tsv_col * 'faith_pd [2]'" \
  --o-visualization foo.qzv

vs
qiime longitudinal anova \
  --m-metadata-file faith_pd_b.qza \
  --m-metadata-file faith_pd_a.qza \
  --m-metadata-file sample_metadata.tsv \
  --p-formula "'faith_pd [1]' ~ some_tsv_col * 'faith_pd [2]'" \
  --o-visualization foo.qzv

The second one swaps the order of the alpha diversity results, but doesn't handle updating the labels in the formula. This will change the interpretation of the formula, with no warning to the user.
If we did something to uniquely identify which file the overlapping columns came from, this would allow for the merge to not be influenced by the order:
qiime longitudinal anova \
  --m-metadata-file faith_pd_a.qza \
  --m-metadata-file faith_pd_b.qza \
  --m-metadata-file sample_metadata.tsv \
  --p-formula " 'faith_pd [45de1dd]' ~ some_tsv_col * 'faith_pd [31eb03b]'" \
  --o-visualization foo.qzv

vs
qiime longitudinal anova \
  --m-metadata-file faith_pd_b.qza \
  --m-metadata-file faith_pd_a.qza \
  --m-metadata-file sample_metadata.tsv \
  --p-formula " 'faith_pd [45de1dd]' ~ some_tsv_col * 'faith_pd [31eb03b]'" \
  --o-visualization foo.qzv

Both of these are the same. Now, the issue here is: "how do I know which hash belongs to which column? Maybe there is some utility exposed elsewhere (like a new .hash or .id property).
Other variations on this: still render out [1], [2], but sort the metadata files internally in some deterministic way, that way the order specified doesn't matter. Finally, we could also append the counter to the hash --- this would cause the command to error out on the user if they changed the order specified, which would be ideal IMO.

That last commit message should be "SQUASH: Fixed an if statement" but I guess the commit message didn't like the if. . . or I forgot it

That's a really good example @thermokarst, thanks! We weren't thinking of any actions like anova. I think I agree this could be more problematic than we thought originally.

What about something like this:
What if Metadata.merge required suffixes when dups are found? In the python API, this could look like anything, but the CLI will choose to use the filename (up to a distinct path) as the suffixes. This isn't initially customizable behavior in the CLI, if you want specific suffixes, then you have to use the Python API.
Then the CLI always does something sane (and relatively predictable), and in Python, that's totally up to you. In this case it's just an argument the CLI knows to pass automatically.
I think this sidesteps the problem of object artifacts not having a filepath and of needing to immediately creating a suffix syntax for the CLI right away

cc @gregcaporaso who was part of the initial discussion.

What if Metadata.merge required suffixes when dups are found?

@ebolyen do you mean that if merge finds duplicates it blocks and prompts the user to enter suffixes? Or that when merge finds duplicates it breaks and tells the user to rerun the command with suffixes for "xyz" files?

Or that when merge finds duplicates it breaks and tells the user to rerun the command with suffixes for "xyz" files?

The latter, it would probably expect a list in the same order as the arguments:
md1.merge(md2, md3, suffixes=['GG', 'SILVA', 'NewThing'])

Actually, one more thought on this:
List currently works this way as well:
--p-list 1
--p-list 2

is different from
--p-list 2
--p-list 1

However, the new CLI parser can do this now:
--p-list 1 2

which is kind of way better, should we be emphasizing similar things for metadata merging?
--m-whatever-file example.tsv artifacta.qza

I get that generally options are re-orderable, but that isn't true of of some of them.

@ebolyen would that look like all of the --m-metadata and other arguments for the method followed by a --p-list "file-ids"? Wouldn't that have the same issue @thermokarst brought up before where it isn't robust to them accidentally changing the order of the files they pass because the ids they provide aren't uniquely associated with that file? Come to think of it, doesn't them passing the ids through the Python API also have that same issue?

Sorry I didn't mean to suggest that they would do anything with the list as a suffix, rather we already have a List[X] type which has the same problem @thermokarst was describing.
And yes, if you pass a list in the wrong order, it will be wrong... So in that way, the hash is superior, since you can't mess that up, but you could make the anova formula wrong too.

Sorry I didn't mean to suggest that they would do anything with the list as a suffix, rather we already have a List[X] type which has the same problem @thermokarst was describing.

Ah ok

I will say, I've always kind of felt like the UUID is the natural key here, so if metadata files had a hash as well, it would make the columns super traceable, which I like.
Taxonomy [12c9566f-d05f-4067-af7d-8c830ac3cd3f]
ArbitraryDup [a79439c986e60c11601aeabadf4ec963]

I think @gregcaporaso mentioned disliking this since users probably don't know where these numbers come from. But I would be completely fine with that. Like @thermokarst mentioned, we could make a .hash and maybe inspect-metadata is a natural place for it. The only trouble is what to hash, it seems like maybe we serialize it pre-emptively and hash that? So that the metadata is normalized?

@ebolyen As long as we have a clear way for the user to know which file which column came from. I don't like the idea of them having to do any real digging to figure that out

So it sounds like the two options being discussed here are:

CLI (or more generally, interfaces that always operate on qza files?) defaults to using filenames or filepaths as suffixes; API has the user provide suffixes explicitly.
hash/uuid is used and new functionality is added to make that info easily accessible.

2 seems more labor intensive for the user (e.g., if a user has four different artifacts with the same column names, such as a volatility plot generated for four PCoA Results, they're going to have to look up the mapping each time they're trying to interpret the results). 1 is a little clunkier (we probably have to extend filenames out to filepaths sometimes so they're unique), but probably less labor intensive for the user - though sometimes this could get annoying too because they have to find the parts of the suffix that differ, which might be only a couple of characters in a big path.
What if we start with 2 since that sounds like reasonable default behavior? If it becomes a pain for users (we get a lot of forum questions about it), we could add optional suffixes in the future that could be included in addition to or in place of hash/uuid suffixes.

Sounds good to me! How do we want to define this hash? I'll throw out using .save() and the md5sum on it as a first approach.

How about converting the backing dataframe to bytes, then hashing that? We could memoize that to reduce the cost.

Wouldn't that look different every time as the python strings would be on the heap at different memory addresses each time you load the same file?

Not sure, I am AFK, but a quick Google search earlier implied that this would be deterministic

Oh, I see: https://stackoverflow.com/a/47800021/579416
I am a little nervous tying ourselves to a pandas API here, as that does eventually break, and this seems like less trodden territory, but it would definitely be faster.
@Oddant1, want to experiment with these approaches a bit and see how well they work?

https://github.com/qiime2/qiime2/pull/464/commits/70df03cca1c7f638fba87e55c2e9a487fe4c6e9c : This commit begins to implement some of the additional ideas we have discussed. Duplicated columns no longer append a simple number, they now append a hash of the file(s) that column came from. If the source file is a single artifact file the current behavior is to use that artifact's uuid. If the source file is a single .tsv it uses a hash of the DataFrame view of the .tsv. If the source is a file with actual history, it uses an XOR of all the hashes in the provenance. This means the metadata now keeps a record of both the artifacts it came from and all of the non-artifacts in its history.

Okay, the following skeleton :skull:  is an attempt to summarize some of the ideas in my last round or two of discussion, please take a look and let me know if you have any questions! :question:
class _MetadataBase:
    @property
    def artifacts(self):
        return tuple(self._artifacts)

    @property
    def tsvs(self):
        return tuple(self._tsvs)

    @property
    def dataframes(self):
        return tuple(self._dataframes)

    def __init__(self, index):
        ...
        self._artifacts = []
        self._tsvs = []
        self._dataframes = []
        ...

    # Note, this replaces the current `_add_artifacts`
    def _add_source_from_artifact(self, artifact: qiime2.Artifact):
        ...
        self._artifacts.append(artifact)

    def _add_source_from_tsv(self, md: qiime2.Metadata):
        ...
        self._tsvs.append(md)

    def _add_source_from_dataframe(self, md: qiime2.Metadata):
        ...
        self._dataframes.append(md)

    @property
    def _id(self):
        id_ = 0
        for source in self._artifacts:
            id_ = int(id_) ^ int(source.uuid)

        sum_file = tempfile.NamedTemporaryFile(prefix='md5-')
        for source in itertools.chain(self._dataframes, self._tsvs):
            source.save(sum_file.name)
            id_ = int(id_) ^ int(md5sum(sum_file.name), 16)
        sum_file.close()

        return id_

class Metadata(_MetadataBase):
    def __init__(self, dataframe):
        ...
        super().__init__(dataframe.index)
        ...
        self._add_source_from_dataframe(self)

class MetadataReader:
    def read(self, into, column_types=None):
        ...
        try:
            md = into(df)
            md._add_source_from_tsv(md)
            return md
        ...

class Artifact(Result):
    def _view(self, view_type, recorder=None):
        ...
        if view_type is qiime2.Metadata:
            result._add_source_from_artifact(self)
        ...

This is untested code, so YMMV, but the point is to illustrate the idea! :bulb:

@thermokarst the only reason I did it the way I did it and not that way is because using that method the metadata contains a reference to itself as a source which I didn't think made sense, but if you're fine with that happening/want that to happen I'm happy to implement it that way. It definitely simplifies some pieces of logic! Additionally, do you want a list of sources that are metadata from previous merges as well? I just kind of threw the "Merge" source_type in the last implementation because it seemed like something that was missing.

@thermokarst the only reason I did it the way I did it and not that way is because using that method the metadata contains a reference to itself as a source which I didn't think made sense

I understand your concern! It does feel a bit weird, but, we have been doing it for the ._artifacts for a while now and things generally seem to work, so I think I will take that success as motivation for expanding the idea.

do you want a list of sources that are metadata from previous merges as well?

Yes, I would like to do that (I left that part out of my skeleton, I didn't want to step on your toes too much! :feet:)

@property
def _id(self):
    id_ = 0
    for source in self._artifacts:
        id_ = int(id_) ^ int(source.uuid)

    sum_file = tempfile.NamedTemporaryFile(prefix='md5-')
    for source in itertools.chain(self._dataframes, self._tsvs):
        source.save(sum_file.name)
        id_ = int(id_) ^ int(md5sum(sum_file.name), 16)
    sum_file.close()

    return id_

With the current implementation of the id property, we want it to return the uuid of the source artifact if its source is only a single artifact, this is something @ebolyen decided upon. I think there are some arguments for changing it namely

All metadata ids will look the same if it is changed to a normal hex int
This sort of "initialize to 0 then xor with 0" logic can be used simplifying the id calculation

This is what the metadata looks like in that test in provenance right now. Notice the 'metadata.tsv'

This is the value that is supposed to be there

Looks like it has somehow gone from 'artifact1.uuid,artifact2.uuid:metadata.tsv' to just 'metadata.tsv'

I poked around a bit, and I think I know what's causing the failure in test_provenance.py the merged metadata column has no artifacts in its artifacts property. With the old way of doing things it should have had 2 artifacts in it's artifacts list, now it should only have one. Instead it has nothing. I'm not sure why because there are tests in test_metadata_column.py ensuring that columns taken from merged metadata retain their correct artifact.

I am co-assigning this PR to me, I will pull the code down and take a closer look at your question about the test failures. In the meantime you can continue to work on addressing my latest round of review.

I'm pretty sure I have new commits addressing all of those? I think I've identified the issue anyway. I never finished the artifacts property for metadata columns, I got side tracked and that code got left in a mangled state.

Note, as far as the bug in provenance is concerned, the previous test had two artifacts making up the source of the merged metadata column, we now only have one. Previously, the column had both artifacts the merged metadata it came from had, now it only has the artifact that produced the metadata it originally came from prior to any merging. If we do still want both of those artifacts there, we're going to need to change our approach

Ok, The provenance issue is not fixed, in fact it seems more bizarre now. It looks like sometimes it tracks both artifacts, and sometimes it doesn't? I'll leave that to you @thermokarst and do another pass over your review. I think the changes I made in my last commit made things a bit better.

Additionally, the test failure is now on the next assertion. It used to fail on the assertion on line 104, now it is failing on the assertion on line 107 (when it fails)

Hey @Oddant1 - I'm going back through old PRs to try and get some things cleaned up and merged. Can you resolve the conflicts above? Once that's fixed and pending successful CI, we can get a final review on this and get it merged!

We've decided to close this PR, now that we have a merge action in q2-metadata. That action supports merging of metadata when there are either overlapping ids or overlapping columns, but not both. This was partly enabled by the addition of the ImmutableMetadata type, which didn't exist when work on this PR started.
The underlying goal of this PR is still of interest (merge on the fly, without creation of a new artifact, and when there are potentially overlapping ids and overlapping columns), but it's considerably more work than adding the new action. We may circle back to reference this PR if we decide we need it in the future.

authors: Oddant1 ebolyen gregcaporaso lizgehret thermokarst


text:
Some questions about downsampling of point clouds

Hi there,
Really appreciate releasing your amazing work! I'm quite new to point clouds and I have some questions regarding downsampling of the point clouds.
Take 3DMatch as an example. The original raw dataset downloaded from PREDATOR is quite dense, and is preprocessed so that each grid size is 2.5cm. In your work, you further subsample the point clouds using KPConv (the first level downsampled points). My first question is what's the purpose of subsampling? Would a denser point cloud be more informative for registration?
Also, is there a specific reason you downsample the points further for dense point correspondences as I believe the preprocessed input data is already of density 2.5cm?
Last, is there a quick way to visualize the registration result for the 3DMatch benchmark? By running eval.py and test.py it seems to only produce the quantitative metrics.
Thanks for your patience and reply in advance!

In 3DMatch, the original raw point clouds are fused from 50 consecutive RGB-D frames, and usually have more than 100k points. One one hand, they cannot be processed directly because they are too large. On the other hand, we actually do not need such dense point clouds to effectively understand the scene. So that's why PREDATOR and other methods preprocessed the point clouds with a voxel size of 2.5cm.
The insight of the following grid subsampling in the KPConv-based backbone is similar with that of FPN in image recognition tasks. KPConv has a limited receptive field, but we all know that the context in a larger scope help. So that's why we further downsample the point clouds into multiple resolution levels. One of the advantages of grid subsampling is the near-uniform sampling density. This is rather important for our geometric structure embedding as we leverage the spatial consistency between two sets of superpoints.
For dense point correspondences, we choose the points on the second level for two reasons. First, the points voxelized by 2.5cm are still too dense and too difficult to distinguish. Consider two points which are 2.5cm apart on a chair. I don't think they have much differences in structure. Second, matching on the second level is more computationally-efficient.
For visualization, you can refer to #28 .

Thanks for your detailed answer! That clarifies everything.

Hi Qin,
Thanks again for your great answer previously. I have one further question regarding the subsampling list that wish you could please clarify a bit.
In the case of 3DMatch, I notice for each point cloud there are 3 subsamplings, of shape (10110, 38), (2850, 36), and (790, 36) respectively. I assume the first dimension corresponds to the number of downsampled points in each strided KPConv. Originally, there are 38059 points in the cloud.
My questions are how the numbers of downsampled points are determined, and what the second dimension of these subsamplings indicates. Sorry for any potential dumb questions, but really struggling to understand these.
Much appreciated for your patience and reply!

The number of downsampled points is adaptively determined by grid subsampling. It is not fixed for all point clouds. For example, the input point cloud is voxelized by 2.5cm, the point cloud at the second level is voxelized by 5cm, and the point cloud at the third level is voxelized by 10cm, etc.
The second number is the number of neighbors for each point. It is determined by two steps: first, compute the numbers of neighbors within a radius for all points; second, choose the number of neighbors that covers 80% of the points.

Many thanks!


text:
自己训练的模型总产生标记堆积问题，这是什么原因呢？

首先非常感谢作者开源 SOFA，这极大提高了我标记的速度。😄👍
我使用 3 小时的音频精标数据训练葡语的 sofa 模型，最终推理结果中有多处标记堆积的情况，不知道是哪出了问题，希望能得到帮助。标记堆积的情况如下图

@qiuqiao @yqzhishen

这个问题是比较常见的问题，当模型能力不是很强的时候就容易出现标记堆积。sofa v2将会尝试使用一个静态先验矩阵（来自论文One TTS Alignment to rule them all）来解决这个问题，可以期待一下sofa v2

这个问题是比较常见的问题，当模型能力不是很强的时候就容易出现标记堆积。sofa v2将会尝试使用一个静态先验矩阵（来自论文One TTS Alignment to rule them all）来解决这个问题，可以期待一下sofa v2

有计划什么时候推出 sofa v2 吗？很期待呢

authors: Alistair-zhong qiuqiao

repo: qiuqiao/SOFA


text:
feat: add typst blue header CV

Repo URL: https://github.com/cammellos/typst-blue-header-cv
Hello, thanks for the project!
In case you'd like to add the link to my repo, feel free to merge!
Thanks!

Thanks for the awesome contribution @cammellos !

authors: cammellos qjcg

repo: qjcg/awesome-typst


text:
Access evalulator apps

under access evauation sheet -> App access -> this visualization is displaying "the request exceeds memory limit".

Hi @ShankarQlik
Thanks for the issue, we suggest making a selection for several spaces to reduce the data shown in the table, or modifying to remove any columns you don't use. We'll leave the in-app table with all columns in, however, to make it easier for others to customize in future.

authors: ShankarQlik withdave

repo: qlik-oss/qlik-cloud-access-evaluator


text:
Test Issue - zmbbz

Test Body - tiytnabruq

Test Comment - bpaet

repo: qlikqaa/dummyrepo


text:
Test Issue - ocrsv

Test Body - cdejbfhaaa

Test Comment - joony


text:
Test Issue - yvkjf

Test Body - majsmtbrlt

Test Comment - mxzcx


text:
Test Issue - vzjll

Test Body - hhiptnkmbp

Test Comment - bgdsw


text:
Test Issue - tifyn

Test Body - vmyyadjkwa

Test Comment - ckbrx


text:
Test Issue - tkira

Test Body - dkxegfllcq

Test Comment - ibacn


text:
Test Issue - moind

Test Body - visyavgbbt

Test Comment - dbgja


text:
Test Issue - pldqd

Test Body - npgqadnorz

Test Comment - ckoqg


text:
Test Issue - zargb

Test Body - qfnxghhmov

Test Comment - snufj


text:
Test Issue - jlixs

Test Body - qlgiuyykgy

Test Comment - zeied


text:
Test Issue - qagtx

Test Body - mkhqhtivnw

Test Comment - spnxy


text:
Test Issue - cmthl

Test Body - smjayunmxw

Test Comment - xnutz


text:
Test Issue - keajd

Test Body - cjheirhwpe

Test Comment - tkytx


text:
Test Issue - qvuns

Test Body - vkqpwsmhbw

Test Comment - ijovv


text:
Test Issue - jblrv

Test Body - wozyixibpr

Test Comment - jorxj


text:
Test Issue - qmgkd

Test Body - dqvhzeykix

Test Comment - zpujg


text:
Test Issue - dzurb

Test Body - fwnrgazsxp

Test Comment - hcstw


text:
Test Issue - xdrbh

Test Body - srpphufhcm

Test Comment - jopox


text:
Test Issue - ndgvt

Test Body - qbvsnoouyf

Test Comment - xiqsg


text:
Test Issue - hzgzi

Test Body - zyezfxlknh

Test Comment - viwmt


text:
Test Issue - yfkxp

Test Body - qaadovekaj

Test Comment - cfocx


text:
Test Issue - adygk

Test Body - dgqwfpgadl

Test Comment - szbkj


text:
Test Issue - pbomo

Test Body - llfieacvfb

Test Comment - pmole


text:
Test Issue - jkhiu

Test Body - chmlziyqxi

Test Comment - oefwp


text:
Test Issue - evsdm

Test Body - guujxtmibt

Test Comment - vzypo


text:
Test Issue - nknte

Test Body - wlyscpqwci

Test Comment - sqpgu


text:
Test Issue - kimnh

Test Body - zojbjhrapl

Test Comment - upzfr


text:
Test Issue - hwoik

Test Body - coihdqdshj

Test Comment - xcpuk


text:
Test Issue - hevgp

Test Body - rsbkruijiz

Test Comment - wsnuj


text:
Test Issue - qpezs

Test Body - bqlzwwabrp

Test Comment - cdfgx


text:
Test Issue - nlkyi

Test Body - elyboxekbt

Test Comment - hsfnf


text:
Test Issue - hjmyi

Test Body - zibdnoijgk

Test Comment - vnbjx


text:
Test Issue - dntmf

Test Body - fibxrusthp

Test Comment - sofwb


text:
Test Issue - jjoew

Test Body - qezoxoyrmk

Test Comment - wogpu


text:
Docs enhancements for isObserveMode

I cannot find anything in the docs about the meaning of isObserveMode. I only see that sometimes it is true, sometimes false.

Oh my god, now the menu item caught my eye after almost 2 hours of searching. Unfortunately, there was nothing in the Doc Blocks and the Docs search did not find the result either.
Sorry 😂 Better make end of the day.

repo: qonversion/flutter-sdk


text:
System information page on start page

Hi,
Firstly i don’t know how bad this idea is to ask.
I am thinking to change the first page i.e. System Information page to some other module as per my wish.That means whenever i login to the webmin the first page to show would be my module.
Can this possible to do?If any chance of achieving this please let me know how it would be?
Thanks in advance.

Hi,
Goto Webmin->Webmin Configuration-> Index Page Options and set After login, always go to module to whatever you wish.

thanks a lot. :+1:

Don't mention it! :wink:

That is the least we can do it for your extraordinary work.. :)

authors: abhishekawanti qooob

repo: qooob/authentic-theme


text:
Add qx contrib publish

We want to make it as easy as possible for contrib authors to update their contributions. In particular, we want authors to update the dependency on a qooxdoo version so that contribs stay in sync and can automatically be discovered by qx contrib update. Even though it is a no-brainer to create a release on GitHub, the additional step might lead to updates to contribs not being published.
A new command qx contrib publish is intended to make this really easy. It could work this way:

In Manifest.json, update the qooxdoo-range value to include the version of the qooxdoo framework (As per version.txt).
In Manifest.json, based on a CLI option, increment the version number (patch, feature, breaking). For example qx contrib publish --feat would increment 1.0.1 to 1.1.0. Default would be --patch.
Push to master
Create a release with the tag vX.Y.Z according to the current version.

For this to work, the developer needs to provide a GitHub Access token, either via --token or by setting an environment variable GITHUB_ACCESS_TOKEN (Does this work on Windows?)

Enviroment variable should work with windows. Easier would be a --save_token parameter wich save's the token in the db  and tries to Access it from there.

@hkollmann @johnspackman Sure! Which db could this be saved to? The compiler's? John, what is the API for that?

I thought of the contrib repos_cache

No, I wouldn't want to do that - too risky since people might accidentally commit it to GitHub. That also could happen with the compiler db, of course, but that's a better maintained resource.

How about general preferences .json file, to be stored in home directory on *nix, and %APPDATA% on Windows?

For that reason, I somehow prefer the environment variable - that's more secure than any file-based solution...

plenty of apps store github tokens on disk though, think of using git from the command line

Yes, and we have https://github.com/qooxdoo/qooxdoo-cli/issues/20 to mitigate against accidental commit of sensitive and/or ephemeral data. But we should keep sensitive information at one central location and not spread it out over several files.

This made me curious about where git keeps its data, found this:

There are 3 default paths for the config file.
Repository itself: <your_git_repository>/.git/config
User home directory: ~/.gitconfig
System-wide directory: $(prefix)/etc/gitconfig
The --global option always use the home directory. Note that git will always try to read all of them. If it finds one, it loads it, and moves to the next one. Local takes precedence over global, which takes precedence over system-wide. It uses a simple key-merging algorithm.

from https://stackoverflow.com/a/7328869/2979698:

Implmented with fb47f853133e394947839c262a805fccd2d4182d.

authors: cboulanger hkollmann johnspackman

repo: qooxdoo/qooxdoo-cli


text:
PartLoader not working in build target

Using source target, when PartLoader.require is triggered, a success request to include the file is done.
But using build target, when PartLoader.require is triggered, a request with error ERR_FILE_NOT_FOUND is done.
This means that qx compiler does not make a copy of js file that is defined as part in compile.json

fixed in newer version

authors: AmjadKh hkollmann

repo: qooxdoo/qooxdoo-compiler


text:
crashing when using shaders

crashing when using shaders

Optifabric or iris?

I have the same issue on Iris

actually, there is a branch of sodium compatible with both immptl and iris.

ok. could you send link please? (i imagine this might not work because iris has its own version of sodium integrated)

The pr was merged into iris a few hrs ago

authors: DragonEggBedrockBreaking N-U-M-B-A-T Samisaprogrammer Sjskyler27

repo: qouteall/ImmersivePortalsMod


text:
Feat: Add 'jump_forwards' mapping preset.

Hi!
I sometimes have multiple snippets that have a similar name, and I would like to cycle through them in the cmp suggestion popup using tab. The default/recommended expand_or_jump_forwards does not allow this:

This adds a jump_forwards mapping "preset", which does not expand on tab:

Let me know if anything needs to be changed  or you don't feel this is needed - I am happy to keep having a 'compose' in my config.
Thanks for the great plugin!

LGTM

Great that you find it useful and contribute to it

authors: quangnguyen30192 schilkp smjonas


text:
🛑 otakusan is down

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

HTTP code: 0
Response time: 0 ms

Resolved: otakusan is back up in 411bc99.


text:
🛑 otakusan is down

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

HTTP code: 0
Response time: 0 ms

Resolved: otakusan is back up in 5134143 after 6 minutes.


text:
🛑 otakusan is down

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

HTTP code: 0
Response time: 0 ms

Resolved: otakusan is back up in 95d4b0b after 28 minutes.


text:
🛑 hako.re is down

In 56e77ff, hako.re (https://mangochan.site/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: hako.re is back up in c614b59 after 7 minutes.


text:
New lectures folder and some notebooks to go in it

Also deleted old copy of one of the files from tutorials.

Awesome, looks like notebooks don't render in the diff, so I'll take a look on Monday and merge this PR then.

Merging as drafts. Will move to regular folder once we've reviewed these notebooks.


text:
Add an explanation about cirq-ft's status to its PyPI page

cirq-ft is not a thing anymore, but it still exists on PyPI, and there's no pointer to Qualtran or other note about its status. We should do something about that. At minimum, there should be a note about its status, but perhaps it should be hidden or removed altogether.

Clarification added for anyone else who might be reading this: this issue cannot be solved by editing any file in the Cirq repo. The description where the notice needs to be put is on PyPI.

repo: quantumlib/Cirq


text:
when initializing wf with multiple sectors normalize before returning

Wavefunctions initialized over multiple sectors are nor normalized.
wfn_fqe = fqe.Wavefunction([[2, 0, 4], [2, -2, 4]], broken=None)
wfn_fqe.set_wfn(strategy="random")
wfn_fqe.print_wfn()
wfn.norm()  # this should be 1

This can be fixed by calling self.normalize() before returning from the initialization function.

@ncrubin calling self.normalize() in Wavefunction.set_wfn before returning indeed fixes this but breaks tests with strategy="ones" and strategy="zeros" wavefunctions.

`pytest wavefunction_test.py`
====================================== FAILURES =======================================
__________________________ WavefunctionTest.test_apply_nbody __________________________

self = <fqe.wavefunction_test.WavefunctionTest testMethod=test_apply_nbody>

    def test_apply_nbody(self):
        wfn = Wavefunction([[2, 0, 2]])
        wfn.set_wfn(strategy='random')

        fac = 3.14
        fop = FermionOperator('1^ 1', fac)
        hamil = sparse_hamiltonian.SparseHamiltonian(fop)
>       out1 = wfn._apply_few_nbody(hamil)

wavefunction_test.py:180:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
wavefunction.py:1260: in _apply_few_nbody
    out.set_wfn(strategy="zero")
wavefunction.py:780: in set_wfn
    self.normalize()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <fqe.wavefunction.Wavefunction object at 0x7fecc64709e8>

    def normalize(self) -> None:
        """Generte the wavefunction norm and then scale each element by that
        value.
        """
>       self.scale(1.0 / self.norm())
E       ZeroDivisionError: float division by zero

wavefunction.py:308: ZeroDivisionError
_________________________ WavefunctionTest.test_apply_number __________________________

self = <fqe.wavefunction_test.WavefunctionTest testMethod=test_apply_number>

    def test_apply_number(self):
        norb = 4
        test = numpy.random.rand(norb, norb)
        diag = numpy.random.rand(norb * 2)
        diag2 = copy.deepcopy(diag)
        e_0 = 0
        for i in range(norb):
            e_0 += diag[i + norb]
            diag2[i + norb] = -diag[i + norb]
        hamil = diagonal_hamiltonian.Diagonal(diag2, e_0=e_0)
        hamil._conserve_number = False
        wfn = Wavefunction([[4, 2, norb]], broken=['number'])
        # print(wfn.sectors())
        wfn.set_wfn(strategy='from_data', raw_data={(4, 2): test})
        # print(wfn.sectors())
        out1 = wfn.apply(hamil)
        # print(wfn.sectors())

        hamil = diagonal_hamiltonian.Diagonal(diag)
        wfn = Wavefunction([[4, 2, norb]])
        wfn.set_wfn(strategy='from_data', raw_data={(4, 2): test})
        out2 = wfn.apply(hamil)

        self.assertTrue(
            numpy.allclose(out1._civec[(4, 2)].coeff,
>                          out2._civec[(4, 2)].coeff))
E       AssertionError: False is not true

wavefunction_test.py:114: AssertionError
_______________________ WavefunctionTest.test_general_functions _______________________

self = <fqe.wavefunction_test.WavefunctionTest testMethod=test_general_functions>

    def test_general_functions(self):
        """Test general wavefunction members
        """
        test = Wavefunction(param=[[2, 0, 4]])
        test.set_wfn(strategy='ones')
>       self.assertEqual(1. + 0.j, test[(4, 8)])
E       AssertionError: (1+0j) != (0.25+0j)

wavefunction_test.py:73: AssertionError

Do you want to:

Change these failing tests?
Only call self.normalize with multiple-sector wavefunctions?
Make normalize an optional argument to Wavefunction.set_wfn (default False)?
Other?

Only call self.normalize with strategy="random" wavefunctions?

This seems like the right option in light of strategy="zeros" being a thing. I'll open a preemptive PR with this in case you agree.

authors: ncrubin rmlarose

repo: quantumlib/OpenFermion-FQE


text:
Resource estimation notebook for chemistry has (I think) a typo

In /bloqs/chemistry/resource_estimation.ipynb, the size of the data that needs to be loaded for the sparse simulation approach is given as O(N^3) but it should be O(N^4).

Asymptotically I think sparsity gains you 1/N saving assuming some
localization etc. Is that not the case? (Practically I imagine it may never
be seen)
On Wed, Dec 18, 2024 at 12:19 PM William J. Huggins <
@.***> wrote:

In /bloqs/chemistry/resource_estimation.ipynb, the size of the data that
needs to be loaded for the sparse simulation approach is given as O(N^3)
but it should be O(N^4).
—
Reply to this email directly, view it on GitHub
https://github.com/quantumlib/Qualtran/issues/1511, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC4JSVH2IBR6MQXIZW5PN7T2GHKDRAVCNFSM6AAAAABT3PMG62VHI2DSMVQWIX3LMV43ASLTON2WKOZSG42DQNRXHAZDENI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

There is a line in the THC paper about how it might save a factor of N^2 in the asymptotic limit with localization but I think it would be good to either put N^4 or have more discussion about it in the notebook, or both.

I don't think sparsity could save a factor of N^2? If I remember things correctly worst case there would be O(N^4) elements so QROAM cost of O(N^2), with sparsity I thought best case it would save you a factor of N (for large N) so O(N^{1.5}) QROAM cost. Happy to change it to N^4 though since I imagine the this might only kick in for impractically large systems

authors: fdmalone wjhuggins

repo: quantumlib/Qualtran


text:
Incompatibility with Quarkus 2.8.0

After upgrading to Quarkus 2.8.0 the extension is broken because of:
java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at io.quarkus.test.junit.QuarkusTestExtension.beforeEach(QuarkusTestExtension.java:410)
	...
Caused by: java.lang.NoSuchMethodError: 'java.lang.Object io.quarkus.test.junit.callback.QuarkusTestMethodContext.getOuterInstance()'
	at io.quarkiverse.test.junit.mockk.internal.SetMockkMockAsBeanMockCallback.beforeEach(SetMockkMockAsBeanMockCallback.kt:10)
	... 74 more

Thanks for reporting this. I will push a fix and publish a new version

@pschyma, I just released version 1.1.0 with the fix.

authors: glefloch pschyma

repo: quarkiverse/quarkus-mockk


text:
Revert "Fix Aquilon README"

Reverts quattor/aquilon#36
DO NOT MERGE. This mostly exists to allow us to track the PR that needs to go into the real upstream branch.

See also the proposal in #57 that may impact this particular issue.

@ned21 I can forcibly revert the upstream branch and re-open the original PR, which might be cleaner...

@jrha I think that @ned21 said it was just a reminder for MS and was not intended to be merged... I'd prefer that we close this issue after agreeing that the README contents should be moved to the web site as proposed in #57... I'm just waiting the green light to do it.

Let's discuss on Thursday. Forcibly reverting the upstream branch from our internal copy and re-opening the original PR might be the right way to go but let's discuss with Dave.

@ned21 I'll try to join tomorrow but I cannot promise. I don't really see why you would need to forcibly reverting the change. Is not pulling/merging this change to your internal copy enough? Git should make this pretty easy, shouldn't it?

It's not a question of what the technology can achieve, it's a question of what workflow we want to implement... discussing on Thursday is a good idea.

Sure the workflow discussion is important... but this particular case is probably not the most appropriate if we agree that the Aquilon documentation should not be in the same repo for the reason explained in #57. In this case, the README should be much shorter with a reference to the documentation wherever it is hosted (web site or ReadTheDocs).

@jouvin Unfortunately Dave cannot make this Thursday but should be able to make next week. We need the upstream branch to match our internal copy which has moved on since this was merged so to avoid merge conflicts it would be better to revert this and then we'll use it to practice how the process should work where we pull in the branch locally, put it through our internal pipeline and push it back out.
I agree #57 might/should change this. but now it's been merged we need to straighten out the upstream branch again so we can resume pushing out code.
@jrha - are you OK to force-push the branch and then re-open the PR? Dave and team will then test pulling down the PR and push it back out and confirm that process works for us for accepting patches.

I am not sure myself to make it tomorrow, so let's try to converge via this discussion... We are not far. It's fine with me to forcibly revert as long as the new contents make it somewhere, my previous messages could have been ambiguous. If there is an agreement about #57, I'd suggest no to reopen the PR after being reverted but rather put this contents on the Aquilon installation page on the web site (as part of https://github.com/quattor/quattor.github.com/pull/211?) and open a new PR in this repo to clean up the README file once we have agreed on the workflow. If it is agreed, I can take care of it.

@jouvin The stand-up is on Thursday, which is not tomorrow.
@ned21 I will revert the upstream branch this afternoon, unfortunately I cannot make the stand-up next week due to a meeting in Brighton.

@jrha thanks for the remark, travelling too much, I am a bit lost... I should be able to make it this week then... I'll ensure that I have an up-to-date copy of the merged PR and I'll add it to https://github.com/quattor/quattor.github.com/pull/211.

Original PR reverted, I've opened a copy in #61, this one can be closed now.

authors: jouvin jrha ned21

repo: quattor/aquilon