Easy issue1 php

Description
This PHP program, located in the index.php file, concatenates two predefined strings, "Hello, " and "World!", using the concatenation operator (.), resulting in the combined string "Hello, World!". It then prints this concatenated string to the terminal when executed. This program demonstrates a basic string manipulation operation in PHP.
Additional Context

Merged

This is an automated message from Fork, Commit, Merge [BOT].

Thank you for your contribution! Your pull request has been merged. The files have been reset for the next contributor.
What's next?
If you're looking for more ways to contribute, I invite you to check out my other projects. Just click here to find more. These projects contain real issues that you can help resolve. You can also check out the Influences section in the README to find more projects similar to this one.
Also please leave a star to this project if you feel it helped you, i would really appreciate it.
I look forward to seeing your contributions!


upgraded vcs dependencies

The commit message (and PR name) could be improved to more easily reflect the changes. Also, it's considered good practice to use an infinitive verb in the commit name ("upgrade" instead of "upgraded"), and capitalise the first work. For example:

Upgrade Resin VCS to v2.0.0.

You're missing this vcs call in examples.coffee: https://github.com/resin-io/resin-cli/blob/master/lib/actions/examples.coffee#L94.


[Help] Training problem (how to fix this problem?)

I tried to test Training with sample data
my dataset
path,id,relpath,num_frames,height,width,aspect_ratio,fps,resolution,aes,text,num_frames_y
/home/hed/Open-Sora/sample_data/sample_data_split/big_buck_bunny_240p_1mb_scene-0.mp4,big_buck_bunny_240p_1mb_scene-0,big_buck_bunny_240p_1mb_scene-0.mp4,126,240,320,0.75,15.0,76800,4.688505172729492,bunny,126
/home/hed/Open-Sora/sample_data/sample_data_split/big_buck_bunny_240p_5mb_scene-1.mp4,big_buck_bunny_240p_5mb_scene-1,big_buck_bunny_240p_5mb_scene-1.mp4,69,240,320,0.75,15.0,76800,4.362994194030762,big bunny,69
/home/hed/Open-Sora/sample_data/sample_data_split/big_buck_bunny_240p_5mb_scene-5.mp4,big_buck_bunny_240p_5mb_scene-5,big_buck_bunny_240p_5mb_scene-5.mp4,32,240,320,0.75,15.0,76800,4.103738784790039,bunny,32
/home/hed/Open-Sora/sample_data/sample_data_split/big_buck_bunny_240p_5mb_scene-8.mp4,big_buck_bunny_240p_5mb_scene-8,big_buck_bunny_240p_5mb_scene-8.mp4,147,240,320,0.75,15.0,76800,4.822460174560547,bunny,147
...

download video (from https://sample-videos.com/)
and follow data_processing until  3.2 Filter by aesthetic scores. (Cause i have generate caption issue)
I just want to test Training so I wrote caption myself
And run Training Script
torchrun --standalone --nproc_per_node 1  scripts/train.py  configs/opensora-v1-2/train/stage1.py  --data-path /home/hed/Open-Sora/merged_file.csv
I don't think it's trained normally
Could you kindly advise me on how to fix this issue?
(opensora-inf) hed@test-opensora-a100-spot-roy:~/Open-Sora$ torchrun --standalone --nproc_per_node 1     scripts/train.py     configs/opensora-v1-2/train/stage1.py     --data-path /home/hed/Open-Sora/merged_file.csv
/home/hed/miniconda3/envs/opensora-inf/lib/python3.9/site-packages/colossalai/pipeline/schedule/_utils.py:19: UserWarning: torch.utils._pytree._register_pytree_node is deprecated. Please use torch.utils._pytree.register_pytree_node instead.
  _register_pytree_node(OrderedDict, _odict_flatten, _odict_unflatten)
/home/hed/miniconda3/envs/opensora-inf/lib/python3.9/site-packages/torch/utils/_pytree.py:254: UserWarning: <class 'collections.OrderedDict'> is already registered as pytree node. Overwriting the previous registration.
  warnings.warn(
[2024-07-24 07:57:17] Experiment directory created at outputs/005-STDiT3-XL-2
[2024-07-24 07:57:17] Training configuration:
 {'adam_eps': 1e-15,
 'bucket_config': {'1024': {1: (0.05, 36)},
                   '1080p': {1: (0.1, 5)},
                   '144p': {1: (1.0, 475),
                            51: (1.0, 51),
                            102: ((1.0, 0.33), 27),
                            204: ((1.0, 0.1), 13),
                            408: ((1.0, 0.1), 6)},
                   '2048': {1: (0.1, 5)},
                   '240p': {1: (0.3, 297),
                            51: (0.4, 20),
                            102: ((0.4, 0.33), 10),
                            204: ((0.4, 0.1), 5),
                            408: ((0.4, 0.1), 2)},
                   '256': {1: (0.4, 297),
                           51: (0.5, 20),
                           102: ((0.5, 0.33), 10),
                           204: ((0.5, 0.1), 5),
                           408: ((0.5, 0.1), 2)},
                   '360p': {1: (0.2, 141),
                            51: (0.15, 8),
                            102: ((0.15, 0.33), 4),
                            204: ((0.15, 0.1), 2),
                            408: ((0.15, 0.1), 1)},
                   '480p': {1: (0.1, 89)},
                   '512': {1: (0.1, 141)},
                   '720p': {1: (0.05, 36)}},
 'ckpt_every': 2,
 'config': 'configs/opensora-v1-2/train/stage1.py',
 'dataset': {'data_path': '/home/hed/Open-Sora/merged_file.csv',
             'transform_name': 'resize_crop',
             'type': 'VariableVideoTextDataset'},
 'dtype': 'bf16',
 'ema_decay': 0.99,
 'epochs': 10,
 'grad_checkpoint': True,
 'grad_clip': 1.0,
 'load': None,
 'log_every': 1,
 'lr': 0.0001,
 'mask_ratios': {'image_head': 0.05,
                 'image_head_tail': 0.025,
                 'image_random': 0.025,
                 'image_tail': 0.025,
                 'intepolate': 0.005,
                 'quarter_head': 0.005,
                 'quarter_head_tail': 0.005,
                 'quarter_random': 0.005,
                 'quarter_tail': 0.005,
                 'random': 0.05},
 'model': {'enable_flash_attn': True,
           'enable_layernorm_kernel': True,
           'freeze_y_embedder': True,
           'from_pretrained': None,
           'qk_norm': True,
           'type': 'STDiT3-XL/2'},
 'num_bucket_build_workers': 8,
 'num_workers': 1,
 'outputs': 'outputs',
 'plugin': 'zero2',
 'record_time': False,
 'scheduler': {'sample_method': 'logit-normal',
               'type': 'rflow',
               'use_timestep_transform': True},
 'seed': 42,
 'start_from_scratch': False,
 'text_encoder': {'from_pretrained': 'DeepFloyd/t5-v1_1-xxl',
                  'model_max_length': 300,
                  'shardformer': True,
                  'type': 't5'},
 'vae': {'from_pretrained': 'hpcai-tech/OpenSora-VAE-v1.2',
         'micro_batch_size': 1,
         'micro_frame_size': 17,
         'type': 'OpenSoraVAE_V1_2'},
 'wandb': False,
 'warmup_steps': 1000}
[2024-07-24 07:57:18] Building dataset...
[2024-07-24 07:57:18] Dataset contains 26 samples.
[2024-07-24 07:57:18] Number of buckets: 626
INFO: Pandarallel will run on 8 workers.
INFO: Pandarallel will use Memory file system to transfer data between the main process and workers.
[2024-07-24 07:57:18] Building buckets...
[2024-07-24 07:57:18] Bucket Info:
[2024-07-24 07:57:18] Bucket [#sample, #batch] by aspect ratio:
{'0.56': [2, 0], '0.57': [1, 0], '0.72': [8, 0], '0.75': [5, 0]}
[2024-07-24 07:57:18] Image Bucket [#sample, #batch] by HxWxT:
{}
[2024-07-24 07:57:18] Video Bucket [#sample, #batch] by HxWxT:
{('240p', 51): [1, 0],
 ('256', 102): [1, 0],
 ('256', 51): [8, 0],
 ('144p', 102): [2, 0],
 ('144p', 51): [4, 0]}
[2024-07-24 07:57:18] #training batch: 0, #training sample: 16, #non empty bucket: 7
[2024-07-24 07:57:18] Building models...
/home/hed/miniconda3/envs/opensora-inf/lib/python3.9/site-packages/huggingface_hub/file_download.py:1150: FutureWarning: `resume_download` is deprecated and will be removed in version 1.0.0. Downloads always resume when possible. If you want to force a new download, use `force_download=True`.
  warnings.warn(
Loading checkpoint shards: 100%|███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 2/2 [00:26<00:00, 13.03s/it]
[2024-07-24 07:58:06] [Diffusion] Trainable model params: 1.12 B, Total model params: 1.12 B
[extension] Compiling the JIT cpu_adam_x86 kernel during runtime now
[extension] Time taken to compile cpu_adam_x86 op: 0.6594498157501221 seconds
[extension] Compiling the JIT fused_optim_cuda kernel during runtime now
[extension] Time taken to compile fused_optim_cuda op: 0.5570011138916016 seconds
[2024-07-24 07:58:08] mask ratios: {'random': 0.05, 'intepolate': 0.005, 'quarter_random': 0.005, 'quarter_head': 0.005, 'quarter_tail': 0.005, 'quarter_head_tail': 0.005, 'image_random': 0.025, 'image_head': 0.05, 'image_tail': 0.025, 'image_head_tail': 0.025, 'identity': 0.8}
[2024-07-24 07:58:08] Preparing for distributed training...
[2024-07-24 07:58:08] Boosting model for distributed training
[2024-07-24 07:58:08] Training for 10 epochs with 0 steps per epoch
[2024-07-24 07:58:08] Beginning epoch 0...
Epoch 0: 0it [00:00, ?it/s]
INFO: Pandarallel will run on 8 workers.
INFO: Pandarallel will use Memory file system to transfer data between the main process and workers.
[2024-07-24 07:58:08] Building buckets...
[2024-07-24 07:58:09] Bucket Info:
[2024-07-24 07:58:09] Bucket [#sample, #batch] by aspect ratio:
{'0.56': [2, 0], '0.57': [1, 0], '0.72': [9, 0], '0.75': [4, 0]}
[2024-07-24 07:58:09] Image Bucket [#sample, #batch] by HxWxT:
{}
[2024-07-24 07:58:09] Video Bucket [#sample, #batch] by HxWxT:
{('240p', 51): [1, 0],
 ('256', 102): [1, 0],
 ('256', 51): [9, 0],
 ('144p', 102): [1, 0],
 ('144p', 51): [4, 0]}
[2024-07-24 07:58:09] #training batch: 0, #training sample: 16, #non empty bucket: 7
[2024-07-24 07:58:09] Beginning epoch 1...
Epoch 1: 0it [00:00, ?it/s]
INFO: Pandarallel will run on 8 workers.
INFO: Pandarallel will use Memory file system to transfer data between the main process and workers.
[2024-07-24 07:58:09] Building buckets...
[2024-07-24 07:58:09] Bucket Info:
[2024-07-24 07:58:09] Bucket [#sample, #batch] by aspect ratio:
{'0.56': [2, 0], '0.57': [1, 0], '0.72': [4, 0], '0.75': [9, 0]}
[2024-07-24 07:58:09] Image Bucket [#sample, #batch] by HxWxT:
{}
[2024-07-24 07:58:09] Video Bucket [#sample, #batch] by HxWxT:
{('360p', 51): [1, 0],
 ('240p', 51): [1, 0],
 ('256', 102): [2, 0],
 ('256', 51): [3, 0],
 ('144p', 51): [9, 0]}
[2024-07-24 07:58:09] #training batch: 0, #training sample: 16, #non empty bucket: 6
[2024-07-24 07:58:09] Beginning epoch 2...
Epoch 2: 0it [00:00, ?it/s]
INFO: Pandarallel will run on 8 workers.
INFO: Pandarallel will use Memory file system to transfer data between the main process and workers.
[2024-07-24 07:58:09] Building buckets...
[2024-07-24 07:58:10] Bucket Info:
[2024-07-24 07:58:10] Bucket [#sample, #batch] by aspect ratio:
{'0.56': [2, 0], '0.57': [1, 0], '0.72': [5, 0], '0.75': [8, 0]}
[2024-07-24 07:58:10] Image Bucket [#sample, #batch] by HxWxT:
{}
[2024-07-24 07:58:10] Video Bucket [#sample, #batch] by HxWxT:
{('240p', 51): [1, 0],
 ('256', 51): [6, 0],
 ('144p', 102): [2, 0],
 ('144p', 51): [7, 0]}
[2024-07-24 07:58:10] #training batch: 0, #training sample: 16, #non empty bucket: 6
[2024-07-24 07:58:10] Beginning epoch 3...
Epoch 3: 0it [00:00, ?it/s]
INFO: Pandarallel will run on 8 workers.
INFO: Pandarallel will use Memory file system to transfer data between the main process and workers.
[2024-07-24 07:58:10] Building buckets...
[2024-07-24 07:58:11] Bucket Info:
[2024-07-24 07:58:11] Bucket [#sample, #batch] by aspect ratio:
{'0.57': [3, 0], '0.72': [10, 0], '0.75': [3, 0]}
[2024-07-24 07:58:11] Image Bucket [#sample, #batch] by HxWxT:
{}
[2024-07-24 07:58:11] Video Bucket [#sample, #batch] by HxWxT:
{('256', 102): [2, 0], ('256', 51): [11, 0], ('144p', 51): [3, 0]}
[2024-07-24 07:58:11] #training batch: 0, #training sample: 16, #non empty bucket: 4
[2024-07-24 07:58:11] Beginning epoch 4...
Epoch 4: 0it [00:00, ?it/s]
INFO: Pandarallel will run on 8 workers.
INFO: Pandarallel will use Memory file system to transfer data between the main process and workers.
[2024-07-24 07:58:11] Building buckets...
[2024-07-24 07:58:12] Bucket Info:
[2024-07-24 07:58:12] Bucket [#sample, #batch] by aspect ratio:
{'0.56': [1, 0], '0.57': [2, 0], '0.72': [9, 0], '0.75': [4, 0]}
[2024-07-24 07:58:12] Image Bucket [#sample, #batch] by HxWxT:
{}
[2024-07-24 07:58:12] Video Bucket [#sample, #batch] by HxWxT:
{('240p', 51): [1, 0],
 ('256', 102): [3, 0],
 ('256', 51): [8, 0],
 ('144p', 102): [1, 0],
 ('144p', 51): [3, 0]}
[2024-07-24 07:58:12] #training batch: 0, #training sample: 16, #non empty bucket: 6
[2024-07-24 07:58:12] Beginning epoch 5...
Epoch 5: 0it [00:00, ?it/s]
INFO: Pandarallel will run on 8 workers.
INFO: Pandarallel will use Memory file system to transfer data between the main process and workers.
[2024-07-24 07:58:12] Building buckets...
[2024-07-24 07:58:13] Bucket Info:
[2024-07-24 07:58:13] Bucket [#sample, #batch] by aspect ratio:
{'0.56': [1, 0], '0.57': [2, 0], '0.72': [9, 0], '0.75': [4, 0]}
[2024-07-24 07:58:13] Image Bucket [#sample, #batch] by HxWxT:
{}
[2024-07-24 07:58:13] Video Bucket [#sample, #batch] by HxWxT:
{('256', 102): [3, 0],
 ('256', 51): [8, 0],
 ('144p', 102): [1, 0],
 ('144p', 51): [4, 0]}
[2024-07-24 07:58:13] #training batch: 0, #training sample: 16, #non empty bucket: 7
[2024-07-24 07:58:13] Beginning epoch 6...
Epoch 6: 0it [00:00, ?it/s]
INFO: Pandarallel will run on 8 workers.
INFO: Pandarallel will use Memory file system to transfer data between the main process and workers.
[2024-07-24 07:58:13] Building buckets...
[2024-07-24 07:58:13] Bucket Info:
[2024-07-24 07:58:13] Bucket [#sample, #batch] by aspect ratio:
{'0.56': [3, 0], '0.72': [5, 0], '0.75': [8, 0]}
[2024-07-24 07:58:13] Image Bucket [#sample, #batch] by HxWxT:
{}
[2024-07-24 07:58:13] Video Bucket [#sample, #batch] by HxWxT:
{('256', 102): [1, 0],
 ('256', 51): [4, 0],
 ('144p', 102): [3, 0],
 ('144p', 51): [8, 0]}
[2024-07-24 07:58:13] #training batch: 0, #training sample: 16, #non empty bucket: 6
[2024-07-24 07:58:13] Beginning epoch 7...
Epoch 7: 0it [00:00, ?it/s]
INFO: Pandarallel will run on 8 workers.
INFO: Pandarallel will use Memory file system to transfer data between the main process and workers.
[2024-07-24 07:58:14] Building buckets...
[2024-07-24 07:58:14] Bucket Info:
[2024-07-24 07:58:14] Bucket [#sample, #batch] by aspect ratio:
{'0.56': [3, 0], '0.72': [7, 0], '0.75': [6, 0]}
[2024-07-24 07:58:14] Image Bucket [#sample, #batch] by HxWxT:
{}
[2024-07-24 07:58:14] Video Bucket [#sample, #batch] by HxWxT:
{('360p', 51): [1, 0],
 ('240p', 51): [1, 0],
 ('256', 102): [1, 0],
 ('256', 51): [6, 0],
 ('144p', 102): [1, 0],
 ('144p', 51): [6, 0]}
[2024-07-24 07:58:14] #training batch: 0, #training sample: 16, #non empty bucket: 7
[2024-07-24 07:58:14] Beginning epoch 8...
Epoch 8: 0it [00:00, ?it/s]
INFO: Pandarallel will run on 8 workers.
INFO: Pandarallel will use Memory file system to transfer data between the main process and workers.
[2024-07-24 07:58:14] Building buckets...
[2024-07-24 07:58:15] Bucket Info:
[2024-07-24 07:58:15] Bucket [#sample, #batch] by aspect ratio:
{'0.56': [3, 0], '0.72': [9, 0], '0.75': [4, 0]}
[2024-07-24 07:58:15] Image Bucket [#sample, #batch] by HxWxT:
{}
[2024-07-24 07:58:15] Video Bucket [#sample, #batch] by HxWxT:
{('240p', 51): [3, 0],
 ('256', 51): [9, 0],
 ('144p', 102): [1, 0],
 ('144p', 51): [3, 0]}
[2024-07-24 07:58:15] #training batch: 0, #training sample: 16, #non empty bucket: 4
[2024-07-24 07:58:15] Beginning epoch 9...
Epoch 9: 0it [00:00, ?it/s]
(opensora-inf) hed@test-opensora-a100-spot-roy:~/Open-Sora$

hello,I meet some problem need to communicate with you.do you have Wechat?

Did you train normally after reducing the batch_size according to my method yesterday? Is the inference effect of your trained model normal?


Include dotnet3.1 in v4 powershell7 coretools

Copied mechanism for using dotnet 3.1 from each of the other powershell dockerfiles to the core-tools dockerfile in response to a bug filed earlier today.  This should make dotnet 3.1 available in these images. But, I need some help to understand how I can test to ensure that this fix resolves the bug
https://github.com/Azure/azure-functions-docker/issues/590
PR information

[x] The title of the PR is clear and informative.
[x] There are a small number of commits, each of which has an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[x] If applicable, the PR references the bug/issue that it fixes in the description.
[ ] New Unit tests were added for the changes made and CI is passing.

Thanks @CooperLink for the PR

But, I need some help to understand how I can test to ensure that this fix resolves the bug

With changes in your PR - please see https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-function-linux-custom-image?tabs=in-process%2Cbash%2Cazure-cli&pivots=programming-language-csharp#build-the-container-image-and-test-locally to run functions host and verify E2E.
Also - please see https://github.com/Azure/azure-functions-docker/pull/405 for automated test - if possible please merge the this PR as well

Not super familiar with PowerShell but I think we might just need to change the base image from 6 to 3.1. Core Tools is self contained and doesn’t need .NET 6 to run.

As for testing, not sure how other Core Tools containers are tested but I think we need to ensure the func commands work to create and run an app in the container. This is how I test manually: docker run --rm -it -p 7071:7071 $IMAGE_NAME bash
mkdir app && cd app
func new --worker-runtime powershell -t HttpTrigger -n HttpTrigger
func start

Thank you @anthonychu I just updated the images. I also tested setting up a powershell application which worked just fine.  Thank you for your assistance.  I agree that dotnet6 is unnecessary for these images as they do not build the host repo

Please rebase PR

Rebased. Merging


problems with work of papertrail gem for rails 4.2

hello!
papertrail list, shows something like #User:0x00000004a9df90 instead<EMAIL_ADDRESS>problem appears after updating rails to 4.2. (rails 4.1.8 all works correctly)
P.S. i'll allready create an issue in papertrail repo https://github.com/airblade/paper_trail/issues/452
P.P.S. in screenshot
#User:0x00000004a9df90 instead<EMAIL_ADDRESS>it's for version rails 4.2.
correct email showed, then i'll rollback rails to 4.1.8

It looks like there is a pull request out a fix.
For now, I'm monkey patching it in by putting the following code in config/initializers/rails_admin_user_for_paper_trail.rb:
RailsAdmin::ApplicationController.module_eval do
  def user_for_paper_trail
    _current_user.try(:id) || _current_user
  end
end

(suggestions for a more elegant alternative welcome!)

fixed/


[IOTDB-2061] Add max cached buffer size and max concurrent sub query parameter

I'm not sure about the sh and bat syntax is correct or not. If you are reviewing, please have a look

Coverage decreased (-0.02%) to 67.334% when pulling f39fd50ece913f3af38939ec54f3ae5feee34a03 on maxCachedBuffer into f5a7b990d902402b0d738ca18f0f587330db87e7 on master.


⚠ DesiTorrents has degraded performance

In fde4650, DesiTorrents ($DST) experienced degraded performance:

HTTP code: 200
Response time: 7382 ms

Resolved: DesiTorrents performance has improved in f63d7f1 after 6 minutes.


items.query has mandatory FeedOptions

Package Name: @azure/cosmos
Package Version: v3.4.2
Operating system: Linux
[X ] nodejs

version: 10.4.1

[ ] browser

name/version:

[ ] typescript

version: 3.6.3

Is the bug related to documentation in

[ ] README.md
[X] source code documentation
[ ] SDK API docs on https://docs.microsoft.com

Describe the bug
The doc states that the container.items.query<T>()method has 2 parameters SqlQuerySpec and FeedOptions, the second one is supposed to be optional, but the Typescript definition file states that its mandatory.
To Reproduce
Steps to reproduce the behavior:
1.
Expected behavior
The second parameter FeedOptions should be optional
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

Thanks, @abouroubi. I have already addressed in #6258. We should have a release out in the next few days.


Rule-based engine doesn't respect specified languages

Rule-based engine is ignoring list of languages loaded in LanguageDetector.
LanguageDetectorBuilder
            .fromLanguages(ENGLISH, SPANISH).build()
            .detectLanguageOf(text = "你好，世界")

will return CHINESE, where I expect to receive UNKNOWN.

Hah, good catch @krzysztofpcy. Thank you. I'm going to fix this soon.


Add mp2p_icp for indexing

Please Add This Package to be indexed in the rosdistro.
iron
The source is here:
https://github.com/MOLAorg/mp2p_icp
Checks

[X] All packages have a declared license in the package.xml
[X] This repository has a LICENSE file
[X] This package is expected to build on the submitted rosdistro

NOTE: This package is right now already published within another package ("mola") but in the next release it will be released as an independently package & git repository, hence this PR.

Same as https://github.com/ros/rosdistro/pull/39210#issuecomment-1856575288.

Comments solved in original thread; plus <license file=...> attribute added upstream.

I'll reopen this one after #39311 to avoid problems.


Consistent guidelines spec links, especially in CSS

It seems like it might be useful to have some consistent guidelines for linking to specifications.
With CSS specs, there are several variations to consider. First, the publishing status:

Editor's Draft URLs start with drafts.csswg.org/…, and represent the latest thinking of the spec editors. However, these are drafts. While they're publicly visible, they are not necessarily stable, or agreed-on, and are not considered to be 'published' for public use.
Published specification URLs all start with www.w3.org/TR/…. While Working Drafts may still change, publishing those changes requires group consensus. At this point, even as the status moves from WD to Candidate Recommendation or beyond, the URL will remain more reliable.

I think we should always use TR links when they are available for a feature. Hopefully it's rare that browsers ship a feature before it reaches any published consensus. When looking at an Editor's Draft, there is always a link at the top to the Latest published version of that spec.
Which leads us to the fact that CSS specs are versioned. For every 'module' (eg css-cascade) there are several layers of link specificity:

Per-publication 'dated', e.g. https://www.w3.org/TR/2021/WD-css-cascade-4-20211015/
Per-level 'versioned', e.g. https://www.w3.org/TR/css-cascade-4/
Per-module 'current' level, e.g. https://www.w3.org/TR/css-cascade/

I'm not exactly sure how the 'current' level is determined. For css-cascade that is currently pointing to css-cascade-4, even though levels 5 & 6 are well established (defining layers and scope). I imagine the 'current' spec is the lowest level that still has a Working Draft status?
I expect it's best to optimize for long-term accuracy. Years after a feature has shipped, the 'current' link should still give a relatively accurate and up-to-date definition of the feature.
My proposal:
When linking to a CSS specification:

Prefer the 'current' TR link, without any level version number.
If the feature does not yet appear in the 'current' level, prefer the versioned TR link where that feature is defined (e.g. css-cascade-5 for layers, and css-cascade-6 for scope)
If no published specification includes the feature, then link the Editor's Draft

Ideally, non-current links get updated over time. I don't know if that's something that can be automated?
I don't think this issue exists in the HTML specification, unless we want to specify linking to the single-page vs multi-page version? It's a massive page all together, so might be best pointing people to the multi-page URL? But I'm not sure if one is more stable than the other.
I have no experience with TC39.

In looking at the peer datasets, it looks like Caniuse uses published versions, and BCD uses drafts, and I suspect we are using drafts because we build our draft/specs from BCD data.

I totally get that there are caveats with any approach here, but it seems to me like unpublished drafts are not the best compromise. When a level is written as a diff spec, the ED is also a diff - so provides no advantage. And the fact that ED's get ahead of published specs is as much a risk as it is helpful. EDs are (intentionally) used to draft ideas for discussion, and are very likely to change before getting published.
For features that can be linked in the 'current' WD, that provides the most resilience long-term. The link will still be relevant, even as the feature is updated in newer levels of the spec. In all cases, I think it's reasonable to link directly to ID's within the spec. Ideally those are carried over from one level to the next - working in both diff and non-diff levels.
In the same way this project opens issues on BCD, I think people should feel free to open issues on CSSWG - requesting an update to what is current, or requesting the group re-publish an outdated spec.

Tagging @tidoust for a point of view on this, which I feel he will have.
I can't bring anything constructive to the conversation myself, other than, yes, we use ED here because this is how BCD did it too.
On why BCD did it this way, maybe @Elchi3 can help us with some history from that project.

From a web-features perspective, I would personally favor following the same convention as that used in BCD, given the close ties that exist between the projects. Now, I wouldn't mind if BCD changed its approach and started linking to published versions where possible. One practical argument could be that CSS Editor's Drafts are hosted on a more "fragile" server with stricter rate limits.
A key issue remains that published versions of some CSS specs remain outdated compared to their Editor's Draft, making linking to them less appealing from a documentation perspective (when developers follow a link to a spec, they usually want to access the most up-to-date spec text).
If we were to adopt a "prefer TR links" approach, I would not necessarily switch to the "current" level if the feature was updated in a more recent level. The proposal seems sound otherwise. Dated URLs are best avoided no matter what.
That's a side note but, in the end, what matters more to me is which fragments get used: whenever possible, we should favor stable IDs, meaning links to exported definitions or headings, as raised in https://github.com/w3c/webref/issues/1198#issuecomment-2025154720. And that we have tooling in place to validate the URLs and fragments, which should be doable using data in Webref (@Elchi3 explored automatic validation for BCD in https://github.com/mdn/browser-compat-data/pull/23958, ideally that would be completed to warn about links to unstable identifiers). Even with stable identifiers, there is no guarantee that a fragment remains in the spec from one level to the next. Unversioned URLs also need validation over time.


Shader annotate uniform

This change is required with the new (upcoming) Naga (and already works with what we currently use).

LGTM!


⚠ Bofrost.de has degraded performance

In 222ca32, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1868 ms

Resolved: Bofrost.de performance has improved in b58a370 after 11 minutes.


Cli Application doesn't work.

When I load and allow the CLI file for enigma on my PC, the terminal just flashes at me with a whole bunch of red texts for .1 of a second and then closes. I was able to get this screenshot of it though.

BTW, i've searched countless times for a tutorial but there seems to be no sign of your product anywhere else on the internet.

it'd really help if you could get a clearer screenshot using a screen recorder or something, this is blurry to the point of being unreadable 😭

it'd really help if you could get a clearer screenshot using a screen recorder or something, this is blurry to the point of being unreadable 😭

No, it was a screenshot. It's just that I wasnt too sure if it had any vital information that I probably wouldn't like getting leaked. I dont work on terminal really often so I wasn't sure. My apologies.

Are you able to scroll up to the top of the logs and post what is there, along with the last 2 or so lines? The stack trace is all internal to .NET stuff that I can't figure out.

BTW, i've searched countless times for a tutorial but there seems to be no sign of your product anywhere else on the internet.

Enigma is super new to the point no tutorial exists, yet.

It instantly does that right as I run steam vr and detects the headset.

That's all I know for now, I cant just scroll up because it apears for a 5th of a second.

Can you try to run the application by running it from a command prompt/terminal? Also, can you try this on V.0.4.0? There is a possibility it is not copying openvr_api.dll, which gave a lengthy error instead of a human-readable error. (It also probably makes whatever trackers you have actually work, because that was a problem pre-V.0.3.1.)

Alright, so what command should I put in the terminal?

enigma-cli.exe can be run with nothing extra to run. You can add --debug for more logging, although it may not give much more with this error.

enigma-cli.exe can be run with nothing extra to run. You can add --debug for more logging, although it may not give much more with this error.

Your command prompt is not in the right directory to run the program.
You might want to find a guide on how to run an executable from the command prompt. They can probably explain it better than I could.

Your command prompt is not in the right directory to run the program. You might want to find a guide on how to run an executable from the command prompt. They can probably explain it better than I could.

alright here it is, i succsessfuly ran it through terminal but it does the same thing.

I figured out the problem, my config folder that it's been trying to find is in my other SSD storage.

I have just created V.0.4.1 that should patch this error, but does not fix the underlying cause. Enigma currently assumes the location of this config folder, but it doesn't check any other place. I couldn't find online how you are meant to figure this out; they just give me the path that Enigma already assumes.
Because of that, V.0.4.1 will get you working, but I am renaming the issue and leaving it open until the root cause is resolved.

when will you be able to add hip tracking?

PS everything works fine! 👍

when will you be able to add hip tracking?

Hip trackers ("Waist" in OpenVR terminology) are supported by Enigma, but not by Nexus VR Character Model. Nexus VR Character Model questions should be separate GitHub Issues for that project, but to answer that here: it is not planned due to no clear way to implement them in V3, and the math being far beyond what I can handle for V2.


Update buckets to uniform access control

I don't think that this was an option when this project was first set up. But it would be nice not to have to set the ACL on every object.

[ ] reach out to app geo and ask about converting buckets to uniform
[ ] make the switch to uniform on buckets
[ ] set bucket-level ACL
[ ] remove ACL code in honeycomb

We plan on giving this a try with the new NAIP layers...


Cargo fails to run when an optional dependency is missing

#!/usr/bin/env bash

set -e

cd /tmp
[ -d cargo-optional-deps ] && rm -rf cargo-optional-deps
cargo new cargo-optional-deps
cd cargo-optional-deps

cargo build
cat >> Cargo.toml <<EOF
optional_dep_does_not_exist = { version = "1.0", optional = true }
EOF
cargo build

Fails with

error: no matching package named optional_dep_does_not_exist found (required by cargo-optional-deps)

I did not expect this because the dependency is not required as per http://doc.crates.io/manifest.html#the-features-section:

optional dependencies, which enhance a package, but are not required; and

I'm running into this behavior while integrating Cargo into a private build system that wants control over dependencies. As such, I need to elide optional dependencies by default in this system's dependency list.
I'm opening this issue to get some input on:

Would ignoring missing optional dependencies for inactive features be a problem for Cargo?
I tried to look through existing issues - has something like this been discussed before?
An idea about resourcing/priority of the feature and how it fits into the roadmap for Cargo's integration with existing systems.

Thanks for the report! This is currently expected behavior, however, as Cargo will asset that all dependencies exist (optional, platform-specific, or not) to generate a lock file.
Can you describe your use case a bit for depending on optional dependencies that don't exist? There may be another way to tackle the same problem!

The build system at my company is dependency aware. It uses this knowledge to trigger rebuilds. For example, if A depends on B and then B is built, so too will A. In this manner, a commit to a package will land up running a build (e.g. run tests, static analysis) for everything that is using it. The dependencies are listed in a package config file and are broken down by "build", "normal", "test" and "runtime" dependencies.
The "third party" import process for Rust crates involves a step where we use the crates.io API to map the dependencies onto internal packages. Thus, the dependencies in Cargo.toml land up being in the package config (normal) dependencies section while dev-dependencies land up in build/test dependencies. When we build a package, our build system processes the dependencies and builds a Cargo registry (the "soon to be deprecated" variant) that has precisely the crates we need.
The impedance mismatch is that our build system doesn't have a concept of optional dependencies. Thus we're stuck between two extremes: "all optional dependencies go in the package config" and "no optional dependencies go in the package config". After an internal discussion, we decided the latter was much better. The story in this world is that if you (package A) want to consume a crate (package B) and turn on an optional dependency (package C), then you need to depend on A + C and enable the feature in your Cargo.toml.
If we went for the "put all optional dependencies in the package config" we'd have a bunch of issues such as triggering unnecessary rebuilds, potentially running into licensing issues and so forth. Less is more.

It's likely that "platform specific" will also cause similar issues, but I haven't thought through that too deeply.

Ok thanks for the explanation @marcbowes! I wonder if there may be a good balance to strike here perhaps.
So the reason that Cargo needs optional dependencies is that when generating a lock file for a crate it'll ensure that the lock file doesn't change depending on what you do with the crate (test, build with features, etc). This means that even though some compiles don't use all the dependencies it instead requires all deps to be present at all times.
This sounds like a case, though, where there's definitely an impedance mismatch between your internal build system and "idiomatic Cargo". In that sense it may be best to follow the "build system integration" threads and features to see how we can better accommodate your build system. When you say "there is no way we're going to use crates.io" my guess is you don't mean that you won't use crates from crates.io but rather you won't be directly downloading from crates.io (which is totally ok!). We basically want to make sure that we're empowering and enabling anyone who just wants to use code from crates.io!
One thought I had when writing this is that maybe some "shim crates" could work for now? You're right that pulling in unused crates could have license problems and such like that, but you may also be able to have a set of crates that are "stubbed out" which are empty and contain no dependencies and fail to compile. That way if you accidentally pull it in you know that something needs to be updated to really import the crate.

So the reason that Cargo needs optional dependencies is that when generating a lock file

I think you've hit the nail on the head here. I'm not sure "lock files" are necessary in our system which has its ways of ensuring reproducible builds. Our package template for Rust projects has a .gitignore for Cargo.lock.

but rather you won't be directly downloading from crates.io

Yup, exactly. Sorry for the ambiguity. We have an "import" process to pull an external dependency into our build system. That process is aware of crates.io.

One thought I had when writing this is that maybe some "shim crates" could work for now?

I'm open to the idea but also skeptical. Right now I don't care about 32 bit, Windows, etc. There are trees of dependencies I don't need to worry about if I just remove them. That works great because I can just scrub them from the Cargo.toml and nothing breaks. Optionals are harder because enabling the feature becomes impossible without "unscrubbing" the manifest on demand.

In that sense it may be best to follow the "build system integration" threads and features to see how we can better accommodate your build system

Yeah, I am (trying to). If something in particular is worth investigation, I'd appreciate if you could ping me.

Has any further thought been given to what a solution here might look like? I'd be happy to help with implementation if there's a decision about what should be done. Currently, we're checking in a huge number of vendored crates into the fuchsia tree because they're pulled in as optional dependencies of something or other, and I'd like to make it possible to omit them.

Hi Folks,
I hit the same problem with an use case that I believe is quite reasonable.
My project redisql has an open source part and a close source part.
For my own sanity, I was keeping everything in the same cargo folder and using a git submodule to a private repo for the close source part.  Like this: https://github.com/RedBeardLab/rediSQL
Now users correctly report that they cannot build it: https://github.com/RedBeardLab/rediSQL/issues/29#issue-314814341
Is there any way around it?
Cheers,
Simone

@siscia unfortunately there's no workaround at this time, although https://github.com/rust-lang/cargo/issues/5133 may be workable if the dependency is placed behind a Cargo feature

I've just hit the exact same situation as @siscia, where I have an open source project with an optional proprietary component that adds a few extra features. I'm currently working around it by checking in an empty package to the open source project, and then instructing users to overwrite that with the proprietary code if they need it, but this is pretty bad ergonomically.

@acfoltzer Cargo does avoid requiring optional dependencies when you use cargo install. So if you create a "directory registry" with the one crate in it, and then cargo install the crate by name from that registry, cargo will build and install the crate without requiring optional dependencies.

Has a decision been made for this issue?
I have encountered a case where it is really needed.
In fact, one of my dependencies is optional, and needs a crate that is generated locally. I want to be able to build my project without this dependency when its feature isn't used, and get a compile error if I try to build with this feature and the generated code is missing.
Is there no possible workaround for now?

I'd like to add another "me too" case. I'm working on packaging crates in Fedora. We cannot use crates.io directly, and all crates that are needed during the package build  process must be packaged as RPMs. Not all crates are packaged (for various reasons, sometimes lack of resources, sometimes we don't want to package something), and we want to use cargo build with some optional features disabled and without those crates installed. This is very close to the situation described in the original report for this bug, except that this is a public distro so everything is in the open.
Right now the only workable solution seems to be to edit Cargo.toml files to remove the optional dependencies we don't want to enable, but that is a terrible hack and makes it much harder to automate the whole process.

Somehow Firefox manages to build without optional dependencies in the tree... But I'm not sure how that even works :).

Here's why the Firefox thing works if anyone's curious: https://mozilla.logbot.info/servo/20180917#c15322773

Here is my solution https://github.com/Qeenon/Amadeus/commit/56a1892fc0b5e6630caf9ade67345f5259f08761

@alexcrichton Is there any progress?
I'm using tokio in a project that is built with wasm, and tokio has mio as an optional dependency.
Obviously, I didn't put any features that use mio when i put tokio in cargo.toml, but maybe it's because of this issue, when I do cargo check, it keeps checking with mio.
The moment mio enters the cargo check? Of course, everything explodes. mio doesn't support wasm.
It's very unfortunate. I put mio as optional, but cargo check keeps putting mio in. It's an optional dependency, but why!?
I can't use rust-analyzer properly because of this (rust-analyzer uses cargo check)

Here's why the Firefox thing works if anyone's curious: https://mozilla.logbot.info/servo/20180917#c15322773

LogBot was decommissioned, but here’s that conversation extracted from the archive:
2018-09-17T09:56:19 #servo <emilio> SimonSapin: around? Can I ask you a cargo question?
2018-09-17T09:56:40 #servo <emilio> SimonSapin: so I wanted to unify Gecko's and Servo's style/Cargo.toml
2018-09-17T09:56:51 #servo <emilio> SimonSapin: which right now differ on:
2018-09-17T09:57:36 #servo <emilio> https://www.irccloud.com/pastebin/77W5Ampk/t.diff
2018-09-17T09:58:27 #servo <emilio> SimonSapin: I thought moving the gecko_debug bit somewhere else I'd be able to unify them, since Gecko uses without problems crates that refer to non-existing path that are optional
2018-09-17T09:59:01 #servo <emilio> SimonSapin: but even after that I'm not able to make cargo cope :)
2018-09-17T09:59:08 #servo <emilio> SimonSapin: any idea?
2018-09-17T09:59:13 #servo <emilio> nox: ^ In case you're around
2018-09-17T09:59:40 #servo <SimonSapin> looking
2018-09-17T10:02:33 #servo <emilio> SimonSapin: (in particular, note how gecko builds just fine with `atoms = {path = "../atoms", optional = true}` even though that path is nowhere in m-c). I _assumed_ that that was because of the feature cargo needed to bother looking at the nsstring Cargo.toml, but I'm wrong apparently.
2018-09-17T10:02:42 #servo <SimonSapin> Does Gecko really do that? I think Cargo wants to resolve the full potential dependency graph before doing feature selection
2018-09-17T10:03:26 #servo <emilio> SimonSapin: well it does afaik, but the gecko build may be more complex than just `cargo build` I guess
2018-09-17T10:03:42 #servo <emilio> SimonSapin: maybe I should ask #build instead :)
2018-09-17T10:03:53 #servo <SimonSapin> uh
2018-09-17T10:04:26 #servo <SimonSapin> emilio: I was gonna say, I think I made those changes when removing nsstring bindings from servo/servo, but we could make it an empty crate there instead
2018-09-17T10:04:41 #servo <SimonSapin> but now I wonder how things work out for servo_atoms in gecko
2018-09-17T10:05:11 #servo <emilio> SimonSapin: yeah, that's the other alternative, but I thought there should be a way to make this work... I'll figure out how Gecko does the dependency graph bits.
2018-09-17T10:06:24 #servo <SimonSapin> servo atom is indeed not present in https://searchfox.org/mozilla-central/source/Cargo.lock
2018-09-17T10:23:38 #servo <emilio> SimonSapin: 12:22 <@ted> i have no idea why that works, sorry!
2018-09-17T10:23:47 #servo <SimonSapin> eh
2018-09-17T10:23:55 #servo <emilio> SimonSapin: magic.gif :)
2018-09-17T10:25:07 #servo <emilio> https://github.com/rust-lang/cargo/issues/4544 is open, as expected
2018-09-17T10:25:07 #servo <crowbot> Issue #4544: Cargo fails to run when an *optional* dependency is missing - https://github.com/rust-lang/cargo/issues/4544
2018-09-17T10:25:33 #servo <emilio> oh well
2018-09-17T10:26:16 #servo <emilio> SimonSapin: I may look at what's going on in there if I find some spare time, oh well
2018-09-17T10:26:17 #servo <ted> i would not be surprised to find that it works by accident
2018-09-17T10:26:36 #servo <emilio> ted: yeah, me neither... To bad that now we depend on it heavily :(
2018-09-17T10:27:13 #servo <emilio> ted: do you know what are the biggest differences from a normal `cargo build` in `m-c`? I guess mostly vendored stuff I guess?
2018-09-17T10:27:25 #servo <emilio> s/I guess?//
2018-09-17T10:27:56 #servo <ted> we do write out .cargo/config to do source replacement for vendoring
2018-09-17T10:28:01 #servo <ted> but we also pass a ton of options to cargo
2018-09-17T10:28:14 #servo <ted> https://dxr.mozilla.org/mozilla-central/source/config/rules.mk#957
2018-09-17T10:28:55 #servo <ted> i guess we always run `cargo rustc` not `cargo build`
2018-09-17T10:33:22 #servo <paul> standups: working on making the compositor more embedder friendly: optional at startup, support multiple windows, not bound to the embedder thread.
2018-09-17T10:33:22 #servo <standups> Ok, submitted #59981 for https://www.standu.ps/user/paul/
2018-09-17T10:40:25 #servo <emilio> SimonSapin: ted: Oh, figured out
2018-09-17T10:40:45 #servo <emilio> SimonSapin: ted: (RUST_LOG=cargo is amazing)
2018-09-17T10:41:06 #servo <emilio> SimonSapin: ted: It was erroring in cargo::core::workspace: find_members
2018-09-17T10:41:16 #servo <emilio> SimonSapin: ted: Gecko excludes `servo/` from the workspace
2018-09-17T10:41:23 #servo <ted> aha
2018-09-17T10:41:59 #servo <SimonSapin> uh… so in gecko, the style crate is a path dependency but not a workspace member?
2018-09-17T10:42:14 #servo <SimonSapin> I’m not even sure what that means
2018-09-17T10:42:19 #servo <emilio> SimonSapin: if I add `exclude = ["components/style"]` to servo, it works. Now, I guess we don't really want to do that, but maybe excluding just the non-existing path works well enough
2018-09-17T10:43:08 #servo <emilio> SimonSapin: well, the side effects are nice, imho...
2018-09-17T10:43:28 #servo <ted> SimonSapin: i think it's just because servo defines its own workspace?
2018-09-17T10:43:33 #servo <ted> or maybe because of this, i can't remember
2018-09-17T10:43:42 #servo <SimonSapin> emilio: I mean I don’t know what the other effects are
2018-09-17T10:44:06 #servo <SimonSapin> emilio: does it it work to exclude only support/ ?
2018-09-17T10:45:11 #servo <emilio> SimonSapin: nope, `Unable to update file:///home/emilio/src/moz/servo/support/gecko/nsstring`
2018-09-17T10:46:15 #servo <emilio> SimonSapin: curious what that does to the lockfile, here's the patch:
2018-09-17T10:46:30 #servo <emilio> https://www.irccloud.com/pastebin/4cgrcEGa/t.diff
2018-09-17T10:46:44 #servo <emilio> SimonSapin: I guess it's expected
2018-09-17T10:47:09 #servo <emilio> SimonSapin: (but still, lol)
2018-09-17T10:48:43 #servo <emilio> ted: so Servo used to define its own workspace when we vendored the whole thing, but now we don't, yet we rely on that for everything not to blow up :D
2018-09-17T10:48:58 #servo <ted> heh
2018-09-17T10:49:24 #servo <SimonSapin> I think nested workspaces are ignored, though
2018-09-17T10:51:13 #servo <emilio> SimonSapin: I guess the best way forward for me is to land a cargo patch to not hard-error when broken optional dependencies are found... Does that sound right?
2018-09-17T10:51:36 #servo <emilio> SimonSapin: that should allow us to remove the weird `exclude =` thing as well in Gecko
2018-09-17T10:52:09 #servo <SimonSapin> emilio: I don’t know if the cargo maintainers will want to take that patch, but it may be worth a try
2018-09-17T10:52:38 #servo <SimonSapin> maybe file an issue first in case they don’t, so you don’t do the work if it’s not gonna land
2018-09-17T10:54:37 #servo <emilio> SimonSapin: looks like the patch is trivial to write so I may as well test it and submit it.

We also hit this just now.
We have a few internal crates (as path dependencies) that we'd like to optionally enable when a local dev feature is enabled, but we want those crates to never be required in any capacity by our public users.
We now have to either:

patch Cargo.toml locally and add those dependencies in, which is not ergonomic on the dev side.
add dummy crates and require the users to work form a workspace with those in, which is also very very ugly

I believe this is a very common use case that I've seen and used in most of the projects I've worked on in my career so far.
I am also open to any horrible hacks and/or suggestions on how to work around this 😅

We hit the same issue with an mix of open source and private optional dependencies.
We have a public crate A that has an optional dependencies on a private crate B (behind a feature). Cargo is failing to resolve the private crate for anyone who uses A even though it's behind a feature flag that not enabled.


Add Northampton School For Boys (NSB)

Institution/School Name
Northampton School For Boys
Instiution/School Website
Website URL
Email Users
Please place an x between the square brackets if yes

[x] Students
[ ] Academic/Teaching Staff
[ ] Other/Support Staff
[ ] Alumni

Education Levels
Please place an x between the square brackets if yes

[ ] Post-graduate research
[ ] Graduate School
[ ] College (University) or Undergraduate School or equivalent
[ ] Community College or equivalent
[x] High School or equivalent
[ ] Elementary School or equivalent

@choco-green Pull request merged. Thank you!


Bug in getting hours in DateTimePicker

Thank you for reporting an issue, suggesting an enhancement, or asking a question. We appreciate your feedback - to help the team understand your
needs please complete the below template to ensure we have the details to help. Thanks!
Please check out the documentation to see if your question is already addressed there. This will help us ensure our documentation is up to date.
Category
[ ] Enhancement
[X ] Bug
[X ] Question
Version
Please specify what version of the library you are using: [  1.19.0   ]
If you are not using the latest release, please update and see if the issue is resolved before submitting an issue.
Expected / Desired Behavior / Question
I'm pulling a date/time field value from a SharePoint Online List in a REACT webpart.
The data that I'm getting back is a JSON Object and the format looks like this:

Observed Behavior
When I add this to a DateTimePicker Control as show below:

I'm getting an error from within the control itself that indicates "getHours" is not a function.

The line of code here appears to point to a function that perhaps I needed to install?

I hope I'm just doing something wrong and that this is not a bug
Thanks!

getHours() is a function available in Date instance.
You should do:
const d = new Date(this.props.StartDt);
<DateTimePicker
  value={d} />

Thanks AJIXuMuk,
The approach that I got working is clunky and I like yours better and will try that (see my approach below).
I feel that more robust documentation on usage is really needed for these great controls....

ok - so, here is the class that pulls the data and places it correctly in the controls:

@mpalmer-sps - I agree that documentation is not always as good as it could be.
But for this specific situation the documentation is correct:

Property
Type
Required
Description

value
Date
no
Default value of the DatePicker, if any


Add New character info

32FF was added recently for new Japanese era. Please add to the dll.

Done: https://github.com/GoldenCrystal/NetUnicodeInfo/blob/3048572384726eef2eed58ebac25bcefab4be286/UnicodeInformation.Tests/UnicodeInfoTests.cs#L54
Unicode 12.1 will be available in version 2.4 of the package.


IP Anonymization

Is it possible to enable IP Anonymization, as in the gtag.js documentation?
I tried passing it on the global config but I'm not sure it's doing anything.

I'm sorry but "I'm not sure" is not enough for me.
I tried it and it works like any other argument.
if you have an issue, create a repository that proves it and I will take a look

Am I correct that the right way to use it is the following?
Vue.use(VueGtag, {
  config: {
    id: "UA-1234567-1",
    params: {
      anonymize_ip: true,
    },
  },
});

@WolfgangDrescher correct


Update restore-statements-headeronly-transact-sql.md

Add new columns. See more discussions here: https://github.com/MicrosoftDocs/sql-docs/issues/7879

Replaced by internal PR.


chore: Dependencies & Docs

The "merge-me" action is failing until @christian-bromann makes some changes, so the dev deps are out of date.

update lockfile version to v2
update dev deps to latest v7 WDIO
fix reported vulnerabilities in dev deps
update changelog file
update nvmrc file to the current v14 LTS version.

The "merge-me" action is failing until @christian-bromann makes some changes,

What changes are you expecting me do to? I don't have a replacement for it yet. Feel free to use anything that works.

The "merge-me" action is failing until @christian-bromann makes some changes,

What changes are you expecting me do to? I don't have a replacement for it yet. Feel free to use anything that works.

When I get time over the next week I plan to introduce an alternative that uses only GitHub's actions. I had tagged you since you had added it.

Cheers! Yeah would love if we could roll out a better action to all projects as it takes me almost an hour every week to keep up with all these manual merges.

Please go ahead and merge.

Please go ahead and merge.

I'm not a maintainer/collaborator here, which is why I end up pinging you and @chmanie to merge things

Oh sorry, I just invited you. Welcome to the team!

If main branch is green feel free to trigger the release workflow with the appropriate semver bump. Let me know if you have any questions.

Oh sorry, I just invited you. Welcome to the team!

Happy this finally happened :) welcome @tehhowch and thanks for all the great work!


Validate that a user includes a memo when they are sending a transfer to an exchange.

Issue
Users often do not understand that a memo is REQUIRED when sending a transfer to an exchange. This pull request includes code that will validate the memo field on the transfer form when the "TO" field is that of a known exchange.
Changes:

src/wallet/Transfer.js

added validateMemo method
call validateMemo when user input exchange in to field
ensure validateMemo not called when recipient is not an exchange

Thank you for your contribution @netuoso, can you solve these ESLint errors?
107:5   error  Unexpected var, use let or const instead            no-var
  115:54  error  Trailing spaces not allowed                         no-trailing-spaces
  155:19  error  'authenticated' is assigned a value but never used  no-unused-vars
  155:34  error  'user' is assigned a value but never used           no-unused-vars
  157:5   error  Unexpected var, use let or const instead            no-var
  160:49  error  Expected '===' and instead saw '=='                 eqeqeq
  164:7   error  Unnecessary return statement                        no-useless-return
  165:12  error  Unnecessary 'else' after 'return'                   no-else-return

@bonustrack Ok. Made most the changes. Didn't make the changes related to user and authenticated since I didn't add or alter those.

I found out some issues, sorry for late review.
When i manually type bittrex on transfer modal, by default the memo show an error like this:

The error should appear only if i click submit and memo is empty or if i focus on the field memo and unfocus while the field is still empty.
For reproduce:

go here: https://busy-master-pr-1071.herokuapp.com/@fabien
click on the 3 dot menu transfer
change fabien to bittrex
the error should appear
even if you change bittrex to fabien, the error stay

Also

The base of the pull request should be master instead of new-design due to recent changes
The ESLint error should be fixed by removing authenticated and user vars

Will you do these changes @netuoso or @jm90m ?

Closing this PR, I'll take over it since it has been sometime... new PR is here: https://github.com/busyorg/busy/pull/1160


Don't add snapshot_kind: text to snapshots

This was extremely simple, sorry to leave it hanging.
Will do a self-review tomorrow to confirm I haven't missed anything

horray, thanks!!

One thing I did miss — this will remove existing snapshot_kind: text. Ideally we'd keep those, or it's going to be a lot more churn.
(shows the cost of leaving it for a while — I remember thinking this at the time)

OK, I realize it's not tractable to have it retain snapshot_kind: text. So now making changes to any snapshots (or running --force-update-snapshots)  that have snapshot_kind: text will remove that metadata item.
I personally disagree with merging this. From the attached issue explaining the original change:

I appreciate it's some aesthetic churn. But OTOH it only appears when updating snapshots. And for those who care about the cleanliness of diffs, doing a single run of --force-update-snapshots will update everything in a single commit. And in general it's important for insta to be able to evolve the snapshot format, albeit in the specific case we could have traded away consistency in metadata to reduce changes.

Merging this adds some additional churn (though admittedly more so since I took a couple weeks to do this).
But I weigh @mitsuhiko 's opinion highly, and appreciate some of the trade for being able to move quickly is occasionally reverting things. So I'll merge now, and release in a few days unless there are any second thoughts.

thx for merging!!! Can't wait to switch to the new version :)


Makes codeclimate/php-test-reporter a dev dependency.

Hey @Crell!
I am incorporating this into an API I'm working on and was curious whether or not the test reporter from CodeClimate was a production dependency of the package. Anywho, figured I'd frame the question as a PR in case it was more appropriate as a dev-dependency. If not, feel free to close!
Thanks for taking this on; looks great!

That does make a lot more sense, thanks. :smile:


RAW signing via fireblocks API

Hello, I'm trying to sign a delegate transaction via the fireblocks RAW signing API.
Their method takes the transaction serialized in hexadecimal.
Here is my code on how to build the transaction:
import { FireblocksSDK, PeerType, TransactionOperation } from 'fireblocks-sdk';
import { coin } from "@cosmjs/proto-signing";
import { MsgDelegate } from "cosmjs-types/cosmos/staking/v1beta1/tx";
import { toHex } from "@cosmjs/encoding";
import { makeSignDoc, serializeSignDoc } from "@cosmjs/amino";

const fs = require('fs');

const apiSecret = fs.readFileSync('./fireblocks_secret.key', 'utf8');
const apiKey = 'xxx';
const fireblocks = new FireblocksSDK(apiSecret, apiKey);

(async () => {
  const vault = await fireblocks.getVaultAccountsWithPageInfo({
    namePrefix: 'account name',
  });

  const vaultId = vault.accounts[0].id;

  try {
    const msg = MsgDelegate.fromPartial({
      delegatorAddress: 'cosmos19c9fdh488vqjclltwp68jm50ydwyh36jqeatev',
      validatorAddress: 'cosmosvaloper178h4s6at5v9cd8m9n7ew3hg7k9eh0s6wptxpcn',
      amount: coin('5000', "uatom"),
    });

    const memo = "Use your power wisely";
    const feeAmount = coin(5193, "uatom");
    const sendMsg = {
      type: "/cosmos.staking.v1beta1.MsgDelegate",
      value: msg,
    };

    const fee = {
      amount: [feeAmount],
      gas: '300000',
    };

    const accountNumber = 698081;
    const sequence = 0;

    const doc = makeSignDoc(
      [sendMsg],
      fee,
      'theta-testnet-001',
      memo,
      accountNumber,
      sequence,
    );

    const encoded = toHex(serializeSignDoc(doc));

    const res = await fireblocks.createTransaction({
      assetId: 'ATOM_COS_TEST',
      note: 'Automated ATOM staking transaction',
      source: {
        type: PeerType.VAULT_ACCOUNT,
        id: vaultId,
      },
      operation: TransactionOperation.RAW,
      extraParameters: {
        rawMessageData: {
          messages: [
            {
              content: encoded,
            },
          ],
        },
      },
    });
    console.log('success:', res);
  } catch (err) {
    console.log(err);
  }
})();

Do you see any issue with this code? When submitting this, the transaction is "submitted" for signing but marked as "failed" in fireblocks.

I don't know fireblocks at all. makeSignDoc, serializeSignDoc } from "@cosmjs/amino" is used for sign mode Amino JSON. Is this what you want?

I got it working eventually. Solution is to use a SigningStargateClient. This can be closed thanks!

Did you manage using SigningStargateClient with a fireblocks signing interface? That would be pretty amazing. Do you have a repo you can share?

Yeah I did, we are keeping our repo private for the moment unfortunately.

Nice!
And congratz to ourself for designing this great interface :D

@nooxx hi, can u give an example of use for SigningStargateClient in this issue? it will be helpful for those who also want to delegate using fireblocks

@webmaster128 i already completed the raw signing via fireblocks API and it may be useful for other custodian user that need partial signing from their custodian, can i put the documentation for it? if yes, where?

We were able to achieve this - gist if you want to follow our steps


Generic type with constant not recognized

module foo<Type, SIZE>;

struct Foo
{
  Type[SIZE] x;
}

module bar;
import foo;

def Bar = Foo<int, 16>;

the last ; is highlighted with an error

I've uploaded a version 0.0.10 which should address this issue.

Closing as fixed.


New clean and shiny architecture

New clean and shiny architecture
This commit makes our architecture more simple and clean.
It introduces:

PhantomPage - host page for the main execution context
CustomPage moved to its own file (header + source)
Config renamed to Settings
QtWebKit dropped support for old compilers, so we can safely use precompiled headers - config.h
decoupled page renderer. I moved page renderer to its own class to solve problems
with printing a web page to PDF. With this new class, we can use clipRect for PDF

This architecture is more stable and consumes less memory because
of correct QObject relations. All nested (dependent) object
will be deleted correctly.

Tests update:
  172 passed
   30 failed
   19 failed as expected
    1 had errors
    2 skipped

Tests update (Linux):
23.178s elapsed
  176 passed
   20 failed
    8 failed as expected
    7 had errors
    2 skipped

@Vitallium which version of qt did you use for this feature?

@Vitallium : Can you double-check your changes on  System::~System() ?
It seems that you have inverted the logic (previous code : tests for !null pointers. now : tests for null pointers).

@GehDoc

I did it again...
https://github.com/ariya/phantomjs/commit/928d635349c2ef14b11c4715f2b70b94c78bc3f4
Thank you!

@jesg 5.9.1. Qt 5.8 has a critical bug fix for QtNetwork. Plus, I want to try new Qt light build for PJS. Just to clarify, minimum supported version is 5.7.1.

@Vitallium sounds good to me :)

This should be milestone based on this.
Will try and resolve conflicts and finally merge.


Add Qdrant Usage back to the example

Hello,
The previous example was outdated and no longer used Qdrant. The client was created but not passed to the StorageContext
I've verified that the notebook runs without errors from start to end

Thanks for updating!


Deprecate boil

The boil function is a light wrapper around Array.prototype.reduce that adds a null check and a graceful failure for non-array-like objects. It seems generally useless and encourages the bad practice of implicit null handling.
If anyone believes boil is worth keeping, please explain your perspective below.

Ahh, I guess the advantage is primarily the types, which prevent the reducer from returning a type not assignable to the array's element type.
Closing!


Picking No when prompted to call method after deployment results in error

When using the StandaloneERC20 as per the guide if you pick "No" when asked to call a function after deployment, an error is produced.
? Pick a contract to instantiate @openzeppelin/contracts-ethereum-package/StandaloneERC20
? Pick a network development
√ Deploying @openzeppelin/contracts-ethereum-package dependency to network dev-1564745320775
All contracts are up to date
? Do you want to call a function on the instance after creating it? No
Possible initialization method (initialize) found in contract. Make sure you initialize your instance.
Invalid JSON RPC response: ""

Reproduce by following above flow.
Recommended fix: remove Yes/No option from contracts that can't be deployed without those an init function being called.
💻 Environment

Windows 10 + Cmder
<EMAIL_ADDRESS>openzeppelin-cli 2.5.1

Thanks for reporting @Swader. This sounds more like a problem in openzeppelin-cli. Would you mind reporting this at forum.openzeppelin.com?

Sure thing


Laravel Framework uses swiftmailer dependency which is abandoned

Laravel Version: 8.74.0
PHP Version: 8.0.10
Database Driver & Version: 10.4.21-MariaDB

Description:
Package swiftmailer/swiftmailer is abandoned, you should avoid using it. Use symfony/mailer instead.
Steps To Reproduce:
If symfony/mailer works well, we can change swiftmailer to symfony/mailer in composer.json file

Search the issue tracker before posting


feat: add privacy policy rule reordering

Why
This adds the ability to direct privacy policies to do "smart reordering" of the rules within a policy. The benefit here is that we can optimize the policy at evaluation time to do less-computationally-expensive rules earlier in the hopes that they are definitive in their evaluation results and therefore we don't evaluate the later more-computationally-expensive rules.
This comes with some notable caveats though so it is an opt-in behavior. The caveats are:

Sometimes SKIP rules are used to do things like log, dry-run, etc. In this case, if they are reordered in an unexpected way, they may not log or execute.
Sometimes rule execution order matters. Example:

AllowRule1 - Allow rule that checks if X is true and allows if so, otherwise skips
AllowRule2 - Allow rule that throws a hard exception if X is false, but always Allows.
In this instance, a non-reorderable policy with [AllowRule1, AllowRule2] would never throw a hard exception.
But if allowed to be reorderable, AllowRule2 may run before AllowRule1 (depending on complexity).
It is best not to write non-reorderable rules.

How

Change privacy rule subclasses to make them categorize themselves into AllowOrSkip, Skip, or DenyOrSkip. (AllowOrDeny is not allowed).
Add complexity field to privacy policy rules. This is programmer-defined. Getting it wrong isn't the end of the world since it just means that the policy execution will be slightly more expensive at worst (not incorrect).
Add rule ordering and tests for the functionality.

Test Plan
Run tests.

Going to look into the suggestion about just doing the ordering validation via a lint rule. Will re-open if we decide to go with this.


Plugin Excluding KONOSUBA -An Explosion on This Wonderful World! English Dub

Plugin Excluding KONOSUBA -An Explosion on This Wonderful World! English Dub. Show is visible with filter settings switched off but when said to only show English Dubs. Konosuba gets excluded and hidden
Latest Chrome Version
Filter On

Filter Off

Sorry about that I did not get time to investigate this issue earlier, Usually when something is hidden when it should be it implies that CR did not follow their own standard for naming, which also means that it might only break for that particular episode. So to investigate this I went to week of 2023-04-17 which has Episode 1 of KONOSUBA -AN EXPLOSION ON THIS WONDERFUL WORLD! (ENGLISH DUB).
Unfortunately I am unable to reproduce this issue,

The inability to reproduce could imply:

CR fixed the title of the show
Chrome did not auto update your extension to the latest version

If you want to check what version of extension you have,

Go to the extension management page

Click on 'Details'

The version number as of right now should be 1.1.2

Alternatively you could try to remove and re-add the extension. Please let me know if the issue still persist.


fix: expand list of fallback stun and turn servers

:tada: This PR is included in version 1.2.4 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Updated QAOA implementation

Summary
This is an update to the QAOA implementation as it has been moved to qiskit-terra.
Changes in this PR:

A new class QAOACircuit is introduced that extends BlueprintCircuit and replaces QAOAVarForm.
QAOAVarForm is now removed and is no longer in use in the implementation.
QAOA tests are copied from qiskit-optimization and modified for use in qiskit-terra. Tests in optimization to be removed once they are accepted in terra.

@Cryoris good point, yes, should be moved to the circuit library. I am fine with QAOAAnsatz as well, if this is more consistent with the other names.

@Cryoris good point, yes, should be moved to the circuit library. I am fine with QAOAAnsatz as well, if this is more consistent with the other names.

@Cryoris

Could we change the name of QAOACircuit? None of the other ansatz circuits have the word "circuit" in them, but they're just called TwoLocal RealAmplitudes PauliTwoDesign etc. Maybe QAOAAnsatz? Also, I feel we should put this circuit in the circuit library with all other Ansatzes, it seems like the more natural place where people would look for it.

Renamed to QAOAAnsatz.
What's the point of moving the circuit class and leaving the algorithm QAOA class where it is now? The algorithm does not make much sense without the circuit and vice versa. So, I believe they should stay together.

Could you also add some tests for the QAOA<Circuit, Ansatz>?

Sorry, but I don't understand this notation in context of python and QAOA implementation.

@Cryoris

Could we change the name of QAOACircuit? None of the other ansatz circuits have the word "circuit" in them, but they're just called TwoLocal RealAmplitudes PauliTwoDesign etc. Maybe QAOAAnsatz? Also, I feel we should put this circuit in the circuit library with all other Ansatzes, it seems like the more natural place where people would look for it.

Renamed to QAOAAnsatz.
What's the point of moving the circuit class and leaving the algorithm QAOA class where it is now? The algorithm does not make much sense without the circuit and vice versa. So, I believe they should stay together.

Could you also add some tests for the QAOA<Circuit, Ansatz>?

Sorry, but I don't understand this notation in context of python and QAOA implementation.

Also, I feel we should put this circuit in the circuit library with all other Ansatzes, it seems like the more natural place where people would look for it.

I think it would be a lot easier for people to see that library had ansatzes if that were the name of the folder - as it is I am still pointing out to people that we have these circuits there as its not so obvious to many.

What's the point of moving the circuit class and leaving the algorithm QAOA class where it is now? The algorithm does not make much sense without the circuit and vice versa. So, I believe they should stay together.

I guess its a choice. We had chosen to keep the ansatz along with the algo since, unlike the others it was not dependent on a simple num_qubits but on the operator. As such I wonder whether we should allow the cost_operator to be set later in an analogous way to num_qubits. Though while VQE knows to set num_qubits it does not know about setting cost operator which is just done by QAOA. If things were done more this way then QAOA could look more like VQE in terms of setting var form params on the var form and being given one, i.e. we might not need to pass 'p' and 'mixer' via the algo to get it to the var form. Of course at this point, since it looks so much like VQE, if VQE supported passing an operator when needed to a var form, or setting num_qubits as needed, then QAOA would not be needed as such, though having it there as an algo makes it more visible even though today its a simple extension of VQE.
One other observation, if the ansatz is moved to the circuit library then I think the qaoa algo should be moved up a level and the folder eliminated as it makes little sense to have that structure there then.

Also, I feel we should put this circuit in the circuit library with all other Ansatzes, it seems like the more natural place where people would look for it.

I think it would be a lot easier for people to see that library had ansatzes if that were the name of the folder - as it is I am still pointing out to people that we have these circuits there as its not so obvious to many.

What's the point of moving the circuit class and leaving the algorithm QAOA class where it is now? The algorithm does not make much sense without the circuit and vice versa. So, I believe they should stay together.

I guess its a choice. We had chosen to keep the ansatz along with the algo since, unlike the others it was not dependent on a simple num_qubits but on the operator. As such I wonder whether we should allow the cost_operator to be set later in an analogous way to num_qubits. Though while VQE knows to set num_qubits it does not know about setting cost operator which is just done by QAOA. If things were done more this way then QAOA could look more like VQE in terms of setting var form params on the var form and being given one, i.e. we might not need to pass 'p' and 'mixer' via the algo to get it to the var form. Of course at this point, since it looks so much like VQE, if VQE supported passing an operator when needed to a var form, or setting num_qubits as needed, then QAOA would not be needed as such, though having it there as an algo makes it more visible even though today its a simple extension of VQE.
One other observation, if the ansatz is moved to the circuit library then I think the qaoa algo should be moved up a level and the folder eliminated as it makes little sense to have that structure there then.

The point of moving the circuit to the library is that we have all circuits in one place. So whenever you need an ansatz or a special circuit you go to the library instead of looking other submodules 🙂

The algorithm does not make much sense without the circuit and vice versa.

But it doesn't matter where the circuit lives, does it? We can as well do from qiskit.circuit.library import instead of from .qaoa_ansatz import in the algorithm.
@woodsp-ibm Yeah if we put QAOA there I agree it makes sense to have something better than n_local.

The point of moving the circuit to the library is that we have all circuits in one place. So whenever you need an ansatz or a special circuit you go to the library instead of looking other submodules 🙂

The algorithm does not make much sense without the circuit and vice versa.

But it doesn't matter where the circuit lives, does it? We can as well do from qiskit.circuit.library import instead of from .qaoa_ansatz import in the algorithm.
@woodsp-ibm Yeah if we put QAOA there I agree it makes sense to have something better than n_local.

The point of moving the circuit to the library is that we have all circuits in one place. So whenever you need an ansatz or a special circuit you go to the library instead of looking other submodules 🙂

OK, where should it be place in the library then? Yes, I will eliminate qaoa package and move the algo up in the structure.

The point of moving the circuit to the library is that we have all circuits in one place. So whenever you need an ansatz or a special circuit you go to the library instead of looking other submodules 🙂

OK, where should it be place in the library then? Yes, I will eliminate qaoa package and move the algo up in the structure.

Could you just put it in qiskit.circuit.library.n_local for now? Then we can further discuss if that folder needs restructuring/renaming. But since users anyways import from qiskit.circuit.library we can still do that later.

Could you just put it in qiskit.circuit.library.n_local for now? Then we can further discuss if that folder needs restructuring/renaming. But since users anyways import from qiskit.circuit.library we can still do that later.

In regards of this comment above to which I did not really see response/thought.

I guess its a choice. We had chosen to keep the ansatz along with the algo since, unlike the others it was not dependent on a simple num_qubits but on the operator. As such I wonder whether we should allow the cost_operator to be set later in an analogous way to num_qubits. Though while VQE knows to set num_qubits it does not know about setting cost operator which is just done by QAOA. If things were done more this way then QAOA could look more like VQE in terms of setting var form params on the var form and being given one, i.e. we might not need to pass 'p' and 'mixer' via the algo to get it to the var form. Of course at this point, since it looks so much like VQE, if VQE supported passing an operator when needed to a var form, or setting num_qubits as needed, then QAOA would not be needed as such, though having it there as an algo makes it more visible even though today its a simple extension of VQE.

This change makes the ansatz an external object but its still created internally in QAOA with things like mixer and reps being passed through QAOA constructor in order to build out the ansatz. This is different than VQE where the Ansatz is built out and passed in. Here though the operator in its entirety needs to be passed to the var form though, not just the num_qubits as is done with VQE. Maybe we don't want to go as far as this in the refactor for now; and just leave QAOA building the ansatz out internally. Making it more visible and separately instantiatable it does seem like one is part way there.

In regards of this comment above to which I did not really see response/thought.

I guess its a choice. We had chosen to keep the ansatz along with the algo since, unlike the others it was not dependent on a simple num_qubits but on the operator. As such I wonder whether we should allow the cost_operator to be set later in an analogous way to num_qubits. Though while VQE knows to set num_qubits it does not know about setting cost operator which is just done by QAOA. If things were done more this way then QAOA could look more like VQE in terms of setting var form params on the var form and being given one, i.e. we might not need to pass 'p' and 'mixer' via the algo to get it to the var form. Of course at this point, since it looks so much like VQE, if VQE supported passing an operator when needed to a var form, or setting num_qubits as needed, then QAOA would not be needed as such, though having it there as an algo makes it more visible even though today its a simple extension of VQE.

This change makes the ansatz an external object but its still created internally in QAOA with things like mixer and reps being passed through QAOA constructor in order to build out the ansatz. This is different than VQE where the Ansatz is built out and passed in. Here though the operator in its entirety needs to be passed to the var form though, not just the num_qubits as is done with VQE. Maybe we don't want to go as far as this in the refactor for now; and just leave QAOA building the ansatz out internally. Making it more visible and separately instantiatable it does seem like one is part way there.

Wrt this comment:

I guess its a choice. We had chosen to keep the ansatz along with the algo since, unlike the others it was not dependent on a simple num_qubits but on the operator. As such I wonder whether we should allow the cost_operator to be set later in an analogous way to num_qubits. Though while VQE knows to set num_qubits it does not know about setting cost operator which is just done by QAOA. If things were done more this way then QAOA could look more like VQE in terms of setting var form params on the var form and being given one, i.e. we might not need to pass 'p' and 'mixer' via the algo to get it to the var form. Of course at this point, since it looks so much like VQE, if VQE supported passing an operator when needed to a var form, or setting num_qubits as needed, then QAOA would not be needed as such, though having it there as an algo makes it more visible even though today its a simple extension of VQE.

It's true that with the QAOAAnsatz as external object we should just be able to do something like
qaoa = VQE(QAOAAnsatz(), optimizer)
qaoa.compute_minimum_eigenvalue(operator)

I personally think keeping an explicit QAOA class still makes sense for visibility and users that are not yet familiar with the connection between VQE and QAOA. However we can clearly point that out in the documentation.

Wrt this comment:

I guess its a choice. We had chosen to keep the ansatz along with the algo since, unlike the others it was not dependent on a simple num_qubits but on the operator. As such I wonder whether we should allow the cost_operator to be set later in an analogous way to num_qubits. Though while VQE knows to set num_qubits it does not know about setting cost operator which is just done by QAOA. If things were done more this way then QAOA could look more like VQE in terms of setting var form params on the var form and being given one, i.e. we might not need to pass 'p' and 'mixer' via the algo to get it to the var form. Of course at this point, since it looks so much like VQE, if VQE supported passing an operator when needed to a var form, or setting num_qubits as needed, then QAOA would not be needed as such, though having it there as an algo makes it more visible even though today its a simple extension of VQE.

It's true that with the QAOAAnsatz as external object we should just be able to do something like
qaoa = VQE(QAOAAnsatz(), optimizer)
qaoa.compute_minimum_eigenvalue(operator)

I personally think keeping an explicit QAOA class still makes sense for visibility and users that are not yet familiar with the connection between VQE and QAOA. However we can clearly point that out in the documentation.


NOISSUE - Update CoAP docs

Signed-off-by: Dušan Borovčanin<EMAIL_ADDRESS>

Codecov Report

Merging #257 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #257   +/-   ##
=======================================
  Coverage   90.59%   90.59%
=======================================
  Files          18       18
  Lines         904      904
=======================================
  Hits          819      819
  Misses         57       57
  Partials       28       28

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update db6165a...d9aece9. Read the comment docs.


CoreOS deployment fails on certs generation

fatal: [k8s-cavemen-vaueo8 -> localhost]: FAILED! => {"changed": false, "failed": true, "invocation": {"module_args": {"dest": "/home/smana/kargo/roles/kubernetes/secrets/files/openssl.conf", "src": "openssl.conf.j2"}, "module_name": "template"}, "msg": "Failed to get information on remote file (/home/smana/kargo/roles/kubernetes/secrets/files/openssl.conf): MODULE FAILURE"}

Can you precise the 'ansible host' OS ?

I'm running ansible from a Fedora host, the default python interpreter is python3. That could be related.
Well maybe it's just caused by my deployment server, i'm still digging.

solved by https://github.com/kubespray/kargo/pull/225, waiting for tests


envoy: Update to 1.13.3

Signed-off-by: Jarno Rajahalme<EMAIL_ADDRESS>The host proxy is updated to Envoy release 1.13.3

test-me-please

test-me-please

test-me-please

test-me-please

Coverage decreased (-0.02%) to 36.93% when pulling 7d0a55e29c75740dc681e858421e28351d22bd89 on pr/jrajahalme/envoy-update-2020-06-30 into 7856a775f5f731098b5b828adfb6da32913a51eb on master.

Checked cilium-envoy --version off of this PR on dev VM:
vagrant@runtime1:~/go/src/github.com/cilium/cilium$ cilium-envoy --version

cilium-envoy  version: 0a9743dda269a0b0039c9db3cf7e0a637caad7a9/1.13.3/Modified/RELEASE/BoringSSL

test-gke


Fix RawFeatureVector for failing test case

Summary
Fixes #829
Details and comments
With this fix, the code shown in the failing sample works fine. And I changed it to random seed whereby before it would fail quite quickly and now it passed looping 100K times in total.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>3
Details

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.001%) to 91.681%

Totals

Change from base Build<PHONE_NUMBER>9:
0.001%

Covered Lines:
4640

Relevant Lines:
5061

💛  - Coveralls


Change machine word constructors to have no default argument.

This is meant to prevent confusion/surprise with respect to other primitives
whose value can be compared using is ${PrimitiveName}. Machine words
are special primitives that can have multiple values, and comparing
with is ${MachineWord} is currently equivalent to comparing to zero.
Incidentally, fixing this also alerts us to the bug in #1920.
We should hold off on merging this PR until after #1927 is merged.

Rebased after merging #1927.  This is ready to merge.


test_format_rst_without_filter fails with wcwidth>=0.2.10

With a modern version of wcwidth this test fail. Looks like docutils is not raising any error anymore.
______________________________________________ TestGetLicenses.test_format_rst_without_filter ______________________________________________

self = <test_piplicenses.TestGetLicenses testMethod=test_format_rst_without_filter>

    @unittest.skipIf(
        sys.version_info < (3, 6, 0),
        "To unsupport Python 3.5 in the near future",
    )
    def test_format_rst_without_filter(self) -> None:
        piplicenses.importlib_metadata.distributions = (
            importlib_metadata_distributions_mocked
        )
        format_rst_args = ["--format=rst"]
        args = self.parser.parse_args(format_rst_args)
        table = create_licenses_table(args)

        self.assertIn("l", table.align.values())
        self.assertTrue(table.border)
        self.assertTrue(table.header)
        self.assertEqual("+", table.junction_char)
        self.assertEqual(RULE_ALL, table.hrules)
>       with self.assertRaises(docutils.utils.SystemMessage):
E       AssertionError: SystemMessage not raised

test_piplicenses.py:579: AssertionError

@danigm Thanks for the very detailed report.
I will attempt to delete the broken test case.

@danigm This problem was fixed in the master branch.
Also, since you seem to be the maintainer of the OS package, I have shipped v4.3.4 of pip-licenses as a release tag.


HttpRequestMessage default version

To enable HTTP/2, you need to set HttpRequestMessage version to the Version(2, 0). But the default version of HttpRequestMessage is already Version(2, 0).
If the message version hasn't been set manually, what will be the protocol version?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: d458030b-3efb-197f-6ac7-9fd4e2296218
Version Independent ID: 6d01409e-fca6-10a3-2def-13ce28c9b210
Content: What's new in .NET Core 3.0
Content Source: docs/core/whats-new/dotnet-core-3-0.md
Product: dotnet-core
GitHub Login: @Thraka
Microsoft Alias: adegeo

Hello. The default is 1.1.
Here is a test app:
class Program
{
    static void Main(string[] args)
    {
        var client = new HttpClient() { BaseAddress = new Uri("https://microsoft.com") };

        using (var response = client.GetAsync("/").Result)
            Console.WriteLine($"HTTP Version is: {response.Version}\n.NET Core Version: {System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription}");

        Console.ReadKey();
    }
}

The output:
HTTP Version is: 1.1
.NET Core Version: .NET Core 3.0.0

Let me know if you have any other questions.

Thank you, but the documentation says, that default version of HttpRequestMessage is 2.0 since .NET Core 2.1. You showed that the default is 1.1. I think there is a mistake in the docs.

I've done the same example in the .NET Core 2.2 and .NET Core 3.0.
class Program
{
    static async Task Main(string[] args)
    {
        var client = new HttpClient() {BaseAddress = new Uri("https://microsoft.com")};

        using (var request = new HttpRequestMessage(HttpMethod.Get, "/") {Version = new Version(2, 0)})
        using (var response20 = await client.SendAsync(request))
            Console.WriteLine(
                $"Request version is {request.Version}\nHTTP Version is: {response20.Version}\n.NET Core Version: {System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription}");

        using (var request = new HttpRequestMessage(HttpMethod.Get, "/"))
        using (var response11 = await client.SendAsync(request))
            Console.WriteLine(
                $"Request version is {request.Version}\nHTTP Version is: {response11.Version}\n.NET Core Version: {System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription}");

        Console.ReadKey();
    }
}

Output in the .NET Core 3.0:
Request version is 2.0
HTTP Version is: 2.0
.NET Core Version: .NET Core 3.0.0
Request version is 1.1
HTTP Version is: 1.1
.NET Core Version: .NET Core 3.0.0

Output in the .NET Core 2.2:
Request version is 2.0
HTTP Version is: 1.1
.NET Core Version: .NET Core 4.6.28008.02
Request version is 2.0
HTTP Version is: 1.1
.NET Core Version: .NET Core 4.6.28008.02

So, the default version of request in the .NET Core 3.0 isn't a 2.0.

Awesome, thank you for linking to where you found that information. I'll look into it.


Material Icons styles are insufficiently protected from the application styles

Have you read the FAQ and checked for duplicate open issues?
Yes
What version of Shaka Player are you using?
v3.0.0
Can you reproduce the issue with our latest release version?
Yes
Can you reproduce the issue with the latest code from master?
Yes
Are you using the demo app or your own custom app?
Custom app, internal to Google
If custom app, can you reproduce the issue using our demo app?
No
What browser and OS are you using?
ChromeOS 83, Chrome Linux 83
What are the manifest and license server URIs?
N/A
What did you do?
In the context of a specific, internal application, the material design icons in the UI are the wrong size in v3.0.0.
Google's font server hosts this icon font along with CSS to use it, and we build this into our compiled CSS using LESS.  It turns out that in b0217f5e6f6fc4e29843ee1e6ad732e15993db53, we changed the font name without changing the class name we used.  This means that the styles from Google's CSS file aren't being applied to those elements any more.
In our demo, this went unnoticed.  In the internal app I mentioned, the application styles take over, and the icons are the wrong size.

I think we should do two things to fix this:

We should fix the icon class names everywhere so that the upstream styles from the font server are applied.
Since we depended on the 24px font-size in those styles, but didn't realize it, we should explicitly add font-size: 24px to our own styles in context of the UI controls, to make sure we are further protected from hypothetical application styles that happen to apply to the same font.


Owner of mounted container dir is inconsistent

When trying to mount a mount a host directory into a container to a path that does not currently exist, the uid/gid of the created directory does not always match the uid/gid of the host directory that was mounted.
Host A is mounting the volume with the same owner as the host dir:
~$ id -u
1000
~$ stat -c '%u' `pwd`
1000
~$ docker run --rm -it -v `pwd`:/foobar ubuntu:14.04 stat -c '%u' /foobar
1000

Host B is always mounting the volume with root as the owner:
~$ id -u
1001
~$ stat -c '%u' `pwd`
1001
~$ docker run --rm -it -v `pwd`:/foobar ubuntu:14.04 stat -c '%u' /foobar
0

The inconsistency was very surprising to me. I suspect the difference is related to the storage driver (Host A used devicemapper, Host B uses AUFS), but I suppose it could be something else (e.g. docker version: 1.11 vs 1.10). More docker info output follows:
Host A:
Server Version: 1.11.0
Storage Driver: devicemapper
 Pool Name: docker-8:4-1052225-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: ext4
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 16.83 GB
 Data Space Total: 107.4 GB
 Data Space Available: 4.988 GB
 Metadata Space Used: 14.27 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.133 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt dm.no_warn_on_loop_devices=true
` to suppress this warning.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.122 (2016-04-09)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host bridge null
Kernel Version: 4.4.5-1-ARCH
Operating System: Arch Linux
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.709 GiB

Host B:
Server Version: 1.10.2
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 905
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: host bridge null
Kernel Version: 3.13.0-79-generic
Operating System: Ubuntu 14.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 3.676 GiB

scratch that... despite simplifying the original commands for a repro, I wound up making the same sets of typos on Host B by trying to mount host directories that didn't exist...


WIP: Release v0.8.0

Work in progress!
@larmog Here you may comment. It's still possible to send PRs to dev as normal
This PR will update as I work more on the release

The problem with docker-multinode is that the volume "data" that get mounted in /srv/kubernetes is of type "emptyDir". When the apiserver POD dies (and it will on arm) and restarts it will generate new certificates. This makes all services that talks to apiserver fail with "unknown certificate auth".
I've made a small script that copies /etc/kubernetes from hyperkube and modifies the volume to be "hostPath". It the mounts the new /etc/kubernetes files to the kubelet docker container, and it seems to work.
I've also modified common.sh so that it keeps etcd data between restarts.

I've also modified common.sh so that it keeps etcd data between restarts.

Good catch! Feel free to send a PR against kube-deploy with this, otherwise I'll do it

Ok, here it is: https://github.com/kubernetes/kube-deploy/pull/175

Yeah, finally!
Let's release v0.8.0!


Tool Help - CC toolbox Table to Elipse GPTool

Tool help revisions and recommendations
TableToEllipseToolHelp.docx

This was merge to dev in #173.  Closing this issue.


Add generic inference for multiple pipelines

This PR enables generic inference for different pipelines. I also created templates.
Some examples I used to test the limits of the system:

Audio to Audio: Asteroid speech enhancement example
Automatic Speech Recognition: pyctdecode + transformers ASR
Feature Extraction: Fasttext.
Image Classification: FastAI example dog vs cat classifier
Structured Data Classification: sklearn wine (clone of julien)

TODO: Add tests to Docker and run the e2e test
FYI @nateraw @mishig25

@lewtun You can ’fork’ them with
git clone https://huggingface.co/templates/$TEMPLATE
cd $TEMPLATE
git remote set-url origin https://huggingface.co/lewtun/$TEMPLATE
git push [--force]

no?

Pretty much what Julien just said. You could also add --depth 1 so it does not copy the whole repo history.
That's a good question and we should probably add a how to clone section in the card.

yes, adding @julien-c's code snippet in the how to clone button would be very useful!

Hi @Narsil, I've done a high-level cleanup to use a single Pipeline instead of multiple repeating same code. I hope this looks better!

This looks SSOOOOO much better ! and with pipc ache to boot, very nice :)


New version: DirectTrajectoryOptimization v0.2.0

Registering package: DirectTrajectoryOptimization
Repository: https://github.com/thowell/DirectTrajectoryOptimization.jl
Created by: @thowell
Version: v0.2.0
Commit: 30bb55e1e3d0030e338145c75fb4e336c27be206
Reviewed by: @thowell
Reference: https://github.com/thowell/DirectTrajectoryOptimization.jl/commit/30bb55e1e3d0030e338145c75fb4e336c27be206#commitcomment-69297261
Description: A Julia package for constrained trajectory optimization using direct methods.

@thowell  please see the message above.  Once you fix the automerge issues you can register again the new revision without changing the version number and this pull request will be automatically updated.
[noblock]


Rwang.fixrate

Change default to .txt since .txt won't be rate limited.

@Rexwang8 you need to resolve some merge conflicts before we can merge this.


Harden github workflow against injection

Prevents theoretical image: ghcr.io/oasisprotocol/runtime-builder:main; echo injected in
https://github.com/oasisprotocol/oasis-sdk/blob/2057e22fac35f61159e6ae2871b99e047bb5f500/.github/workflows/ci-reproducibility.yml#L45-L48

(added quotes; around new vars only)


Radio option disabled tooltip

need this to implement

code lgtm!
Shouldn't there be a demo link automatically posted here?

@gdostie since i am not pointing to master i think this is ignored, so is the coverage