Error occured after pre

Hello! Thanks for your work!
I'm faced with a trouble and hope you could help.
I'm trying to run train a model and I set batch_size=1 and epoches=20 by running

python` train.py --cfg_file cfgs/active-kitti_models/pv_rcnn_active_crb.yaml --batch_size 1  --epochs 20

And my config of active learning is:

ACTIVE_TRAIN:
METHOD: crb
AGGREGATION: mean
PRE_TRAIN_SAMPLE_NUMS: 100
PRE_TRAIN_EPOCH_NUMS: 40
TRAIN_RESUME: False
SELECT_NUMS: 100
SELECT_LABEL_EPOCH_INTERVAL: 40
TOTAL_BUDGET_NUMS: 600
ACTIVE_CONFIG:
K1: 5
K2: 3
BANDWIDTH: 5
CLUSTERING: kmeans++

The pre-train is finished without any error, but after this an error occured before the train start:

2023-11-16 02:15:08,630   INFO  Start training active-kitti_models/pv_rcnn_active_crb(select-100)
2023-11-16 02:15:08,631   INFO  ***** Start Active Pre-train *****
train: 100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 100/100 [02:13<00:00,  1.33s/it, total_it=4000]
epochs: 100%|████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 40/40 [1:28:31<00:00, 132.79s/it, loss=1.66, lr=0.00252]
2023-11-16 03:43:40,420   INFO  ***** Complete Active Pre-train *****
2023-11-16 03:43:40,421   INFO  ***** Start Active Train Loop *****
epochs:   0%|                                                                                | 0/240 [00:00<?, ?it/s*
found and enabled 3 Dropout layers for random sampling*                                                                                | 0/3612 [00:00<?, ?it/s]
evaluating_unlabelled_set_epoch_40: 100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 3612/3612 [12:53<00:00,  4.67it/s]
inf_grads_unlabelled_set_epoch_40: 100%|█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 500/500 [10:11<00:00,  1.22s/it]
--- {kmeans++} running time: 54.5201575756073 seconds for fc grads---████████████████████████████████████████████████████████████████████████████████████████| 500/500 [10:11<00:00,  1.18s/it]
--- Build the uniform distribution running time: 0.04799032211303711 seconds ---
global_density_div_for_epoch_40: 100%|███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 100/100 [04:52<00:00,  2.92s/it]
successfully saved selected frames for epoch 40 for rank 0███████████████████████████████████████████████████████████████████████████████████████████████████| 100/100 [04:52<00:00,  3.49s/it]
wandb: WARNING Step must only increase in log calls.  Step 4000 < 4001; dropping {'active_selection/num_bbox_Car': tensor(113, device='cuda:0')}.
wandb: WARNING Step must only increase in log calls.  Step 4000 < 4001; dropping {'active_selection/mean_points_Car': tensor(141.4796)}.
wandb: WARNING Step must only increase in log calls.  Step 4000 < 4001; dropping {'active_selection/median_points_Car': tensor(99.4700)}.
wandb: WARNING Step must only increase in log calls.  Step 4000 < 4001; dropping {'active_selection/variance_points_Car': tensor(22668.2227)}.
wandb: WARNING Step must only increase in log calls.  Step 4000 < 4001; dropping {'active_selection/num_bbox_Pedestrian': tensor(119, device='cuda:0')}.
wandb: WARNING Step must only increase in log calls.  Step 4000 < 4001; dropping {'active_selection/mean_points_Pedestrian': tensor(171.6909)}.
wandb: WARNING Step must only increase in log calls.  Step 4000 < 4001; dropping {'active_selection/median_points_Pedestrian': tensor(163.9500)}.
wandb: WARNING Step must only increase in log calls.  Step 4000 < 4001; dropping {'active_selection/variance_points_Pedestrian': tensor(2096.7180)}.
wandb: WARNING Step must only increase in log calls.  Step 4000 < 4001; dropping {'active_selection/num_bbox_Cyclist': tensor(46, device='cuda:0')}.
wandb: WARNING Step must only increase in log calls.  Step 4000 < 4001; dropping {'active_selection/mean_points_Cyclist': tensor(24.0983)}.
wandb: WARNING Step must only increase in log calls.  Step 4000 < 4001; dropping {'active_selection/median_points_Cyclist': tensor(20.5300)}.
wandb: WARNING Step must only increase in log calls.  Step 4000 < 4001; dropping {'active_selection/variance_points_Cyclist': tensor(989.8525)}.
wandb: WARNING Step must only increase in log calls.  Step 4000 < 4001; dropping {'active_selection/total_bbox_selected': tensor(278, device='cuda:0')}.
Batch_size of a single loader: 1
2023-11-16 04:12:39,231   INFO  Database filter by min points Car: 14357 => 13532
2023-11-16 04:12:39,233   INFO  Database filter by min points Pedestrian: 2207 => 2168
2023-11-16 04:12:39,233   INFO  Database filter by min points Cyclist: 734 => 705
2023-11-16 04:12:39,286   INFO  Database filter by difficulty Car: 13532 => 10759
2023-11-16 04:12:39,295   INFO  Database filter by difficulty Pedestrian: 2168 => 2075
2023-11-16 04:12:39,298   INFO  Database filter by difficulty Cyclist: 705 => 581
2023-11-16 04:12:39,313   INFO  Loading KITTI dataset
2023-11-16 04:12:39,547   INFO  Total samples for KITTI dataset: 3712
2023-11-16 04:12:39,812   INFO  Database filter by min points Car: 14357 => 13532
2023-11-16 04:12:39,814   INFO  Database filter by min points Pedestrian: 2207 => 2168
2023-11-16 04:12:39,814   INFO  Database filter by min points Cyclist: 734 => 705
2023-11-16 04:12:39,852   INFO  Database filter by difficulty Car: 13532 => 10759
2023-11-16 04:12:39,295   INFO  Database filter by difficulty Pedestrian: 2168 => 2075
2023-11-16 04:12:39,298   INFO  Database filter by difficulty Cyclist: 705 => 581
2023-11-16 04:12:39,313   INFO  Loading KITTI dataset
2023-11-16 04:12:39,547   INFO  Total samples for KITTI dataset: 3712
2023-11-16 04:12:39,812   INFO  Database filter by min points Car: 14357 => 13532
2023-11-16 04:12:39,814   INFO  Database filter by min points Pedestrian: 2207 => 2168
2023-11-16 04:12:39,814   INFO  Database filter by min points Cyclist: 734 => 705
2023-11-16 04:12:39,852   INFO  Database filter by difficulty Car: 13532 => 10759
2023-11-16 04:12:39,860   INFO  Database filter by difficulty Pedestrian: 2168 => 2075
2023-11-16 04:12:39,862   INFO  Database filter by difficulty Cyclist: 705 => 581
2023-11-16 04:12:39,873   INFO  Loading KITTI dataset
2023-11-16 04:12:40,086   INFO  Total samples for KITTI dataset: 3712
2023-11-16 04:12:40,088   INFO  Loading KITTI dataset
2023-11-16 04:12:40,342   INFO  Total samples for KITTI dataset: 3769
2023-11-16 04:12:40,493   INFO  **finished selection: reload init weights of the model
epochs:   0%|                                                                                | 0
/240 [29:00<?, ?it/s]
Traceback (most recent call last):
File "train.py", line 313, in
main()
File "train.py", line 255, in main
dist_train=dist_train
File "/home/CRB-active-3Ddet/tools/train_utils/train_active_utils.py", line 322, in train_model_active
model.load_state_dict(backbone_init_ckpt, strict=cfg.ACTIVE_TRAIN.METHOD!='llal') # strict=cfg.ACTIVE_TRAIN.METHOD!='llal'
File "/opt/conda/envs/crb/lib/python3.6/site-packages/torch/nn/modules/module.py", line 1483, in load_state_dict
self.class.name, "\n\t".join(error_msgs)))
RuntimeError: Error(s) in loading state_dict for PVRCNN:
Missing key(s) in state_dict: "backbone_3d.conv_input.0.weight", "backbone_3d.conv_input.1.weight", "backbone_3d.conv_input.1.bias", "backbone_3d.conv_input.1.running_mean", "backbone_3d.conv_input.1.running_var", "backbon
e_3d.conv1.0.0.weight", "backbone_3d.conv1.0.1.weight", "backbone_3d.conv1.0.1.bias", "backbone_3d.conv1.0.1.running_mean", "backbone_3d.conv1.0.1.running_var", "backbone_3d.conv2.0.0.weight", "backbone_3d.conv2.0.1.weight", "back
bone_3d.conv2.0.1.bias", "backbone_3d.conv2.0.1.running_mean", "backbone_3d.conv2.0.1.running_var", "backbone_3d.conv2.1.0.weight", "backbone_3d.conv2.1.1.weight", "backbone_3d.conv2.1.1.bias", "backbone_3d.conv2.1.1.running_mean"
, "backbone_3d.conv2.1.1.running_var", "backbone_3d.conv2.2.0.weight", "backbone_3d.conv2.2.1.weight", "backbone_3d.conv2.2.1.bias", "backbone_3d.conv2.2.1.running_mean", "backbone_3d.conv2.2.1.running_var", "backbone_3d.conv3.0.0
.weight", "backbone_3d.conv3.0.1.weight", "backbone_3d.conv3.0.1.bias", "backbone_3d.conv3.0.1.running_mean", "backbone_3d.conv3.0.1.running_var", "backbone_3d.conv3.1.0.weight", "backbone_3d.conv3.1.1.weight", "backbone_3d.conv3.
1.1.bias", "backbone_3d.conv3.1.1.running_mean", "backbone_3d.conv3.1.1.running_var", "backbone_3d.conv3.2.0.weight", "backbone_3d.conv3.2.1.weight", "backbone_3d.conv3.2.1.bias", "backbone_3d.conv3.2.1.running_mean", "backbone_3d
.conv3.2.1.running_var", "backbone_3d.conv4.0.0.weight", "backbone_3d.conv4.0.1.weight", "backbone_3d.conv4.0.1.bias", "backbone_3d.conv4.0.1.running_mean", "backbone_3d.conv4.0.1.running_var", "backbone_3d.conv4.1.0.weight", "bac
kbone_3d.conv4.1.1.weight", "backbone_3d.conv4.1.1.bias", "backbone_3d.conv4.1.1.running_mean", "backbone_3d.conv4.1.1.running_var", "backbone_3d.conv4.2.0.weight", "backbone_3d.conv4.2.1.weight", "backbone_3d.conv4.2.1.bias", "ba
ckbone_3d.conv4.2.1.running_mean", "backbone_3d.conv4.2.1.running_var", "backbone_3d.conv_out.0.weight", "backbone_3d.conv_out.1.weight", "backbone_3d.conv_out.1.bias", "backbone_3d.conv_out.1.running_mean", "backbone_3d.conv_out.
1.running_var", "pfe.SA_layers.0.mlps.0.0.weight", "pfe.SA_layers.0.mlps.0.1.weight", "pfe.SA_layers.0.mlps.0.1.bias", "pfe.SA_layers.0.mlps.0.1.running_mean", "pfe.SA_layers.0.mlps.0.1.running_var", "pfe.SA_layers.0.mlps.0.3.weig
ht", "pfe.SA_layers.0.mlps.0.4.weight", "pfe.SA_layers.0.mlps.0.4.bias", "pfe.SA_layers.0.mlps.0.4.running_mean", "pfe.SA_layers.0.mlps.0.4.running_var", "pfe.SA_layers.0.mlps.1.0.weight", "pfe.SA_layers.0.mlps.1.1.weight", "pfe.S
A_layers.0.mlps.1.1.bias", "pfe.SA_layers.0.mlps.1.1.running_mean", "pfe.SA_layers.0.mlps.1.1.running_var", "pfe.SA_layers.0.mlps.1.3.weight", "pfe.SA_layers.0.mlps.1.4.weight", "pfe.SA_layers.0.mlps.1.4.bias", "pfe.SA_layers.0.ml
ps.1.4.running_mean", "pfe.SA_layers.0.mlps.1.4.running_var", "pfe.SA_layers.1.mlps.0.0.weight", "pfe.SA_layers.1.mlps.0.1.weight", "pfe.SA_layers.1.mlps.0.1.bias", "pfe.SA_layers.1.mlps.0.1.running_mean", "pfe.SA_layers.1.mlps.0.
1.running_var", "pfe.SA_layers.1.mlps.0.3.weight", "pfe.SA_layers.1.mlps.0.4.weight", "pfe.SA_layers.1.mlps.0.4.bias", "pfe.SA_layers.1.mlps.0.4.running_mean", "pfe.SA_layers.1.mlps.0.4.running_var", "pfe.SA_layers.1.mlps.1.0.weig
ht", "pfe.SA_layers.1.mlps.1.1.weight", "pfe.SA_layers.1.mlps.1.1.bias", "pfe.SA_layers.1.mlps.1.1.running_mean", "pfe.SA_layers.1.mlps.1.1.running_var", "pfe.SA_layers.1.mlps.1.3.weight", "pfe.SA_layers.1.mlps.1.4.weight", "pfe.S
A_layers.1.mlps.1.4.bias", "pfe.SA_layers.1.mlps.1.4.running_mean", "pfe.SA_layers.1.mlps.1.4.running_var", "pfe.SA_layers.2.mlps.0.0.weight", "pfe.SA_layers.2.mlps.0.1.weight", "pfe.SA_layers.2.mlps.0.1.bias", "pfe.SA_layers.2.ml
ps.0.1.running_mean", "pfe.SA_layers.2.mlps.0.1.running_var", "pfe.SA_layers.2.mlps.0.3.weight", "pfe.SA_layers.2.mlps.0.4.weight", "pfe.SA_layers.2.mlps.0.4.bias", "pfe.SA_layers.2.mlps.0.4.running_mean", "pfe.SA_layers.2.mlps.0.
4.running_var", "pfe.SA_layers.2.mlps.1.0.weight", "pfe.SA_layers.2.mlps.1.1.weight", "pfe.SA_layers.2.mlps.1.1.bias", "pfe.SA_layers.2.mlps.1.1.running_mean", "pfe.SA_layers.2.mlps.1.1.running_var", "pfe.SA_layers.2.mlps.1.3.weig
ht", "pfe.SA_layers.2.mlps.1.4.weight", "pfe.SA_layers.2.mlps.1.4.bias", "pfe.SA_layers.2.mlps.1.4.running_mean", "pfe.SA_layers.2.mlps.1.4.running_var", "pfe.SA_layers.3.mlps.0.0.weight", "pfe.SA_layers.3.mlps.0.1.weight", "pfe.S
A_layers.3.mlps.0.1.bias", "pfe.SA_layers.3.mlps.0.1.running_mean", "pfe.SA_layers.3.mlps.0.1.running_var", "pfe.SA_layers.3.mlps.0.3.weight", "pfe.SA_layers.3.mlps.0.4.weight", "pfe.SA_layers.3.mlps.0.4.bias", "pfe.SA_layers.3.ml
ps.0.4.running_mean", "pfe.SA_layers.3.mlps.0.4.running_var", "pfe.SA_layers.3.mlps.1.0.weight", "pfe.SA_layers.3.mlps.1.1.weight", "pfe.SA_layers.3.mlps.1.1.bias", "pfe.SA_layers.3.mlps.1.1.running_mean", "pfe.SA_layers.3.mlps.1.
1.running_var", "pfe.SA_layers.3.mlps.1.3.weight", "pfe.SA_layers.3.mlps.1.4.weight", "pfe.SA_layers.3.mlps.1.4.bias", "pfe.SA_layers.3.mlps.1.4.running_mean", "pfe.SA_layers.3.mlps.1.4.running_var", "pfe.SA_rawpoints.mlps.0.0.wei
ght", "pfe.SA_rawpoints.mlps.0.1.weight", "pfe.SA_rawpoints.mlps.0.1.bias", "pfe.SA_rawpoints.mlps.0.1.running_mean", "pfe.SA_rawpoints.mlps.0.1.running_var", "pfe.SA_rawpoints.mlps.0.3.weight", "pfe.SA_rawpoints.mlps.0.4.weight",
"pfe.SA_rawpoints.mlps.0.4.bias", "pfe.SA_rawpoints.mlps.0.4.running_mean", "pfe.SA_rawpoints.mlps.0.4.running_var", "pfe.SA_rawpoints.mlps.1.0.weight", "pfe.SA_rawpoints.mlps.1.1.weight", "pfe.SA_rawpoints.mlps.1.1.bias", "pfe.S
A_rawpoints.mlps.1.1.running_mean", "pfe.SA_rawpoints.mlps.1.1.running_var", "pfe.SA_rawpoints.mlps.1.3.weight", "pfe.SA_rawpoints.mlps.1.4.weight", "pfe.SA_rawpoints.mlps.1.4.bias", "pfe.SA_rawpoints.mlps.1.4.running_mean", "pfe.
SA_rawpoints.mlps.1.4.running_var", "pfe.vsa_point_feature_fusion.0.weight", "pfe.vsa_point_feature_fusion.1.weight", "pfe.vsa_point_feature_fusion.1.bias", "pfe.vsa_point_feature_fusion.1.running_mean", "pfe.vsa_point_feature_fus
ion.1.running_var", "backbone_2d.blocks.0.13.weight", "backbone_2d.blocks.0.14.weight", "backbone_2d.blocks.0.14.bias", "backbone_2d.blocks.0.14.running_mean", "backbone_2d.blocks.0.14.running_var", "backbone_2d.blocks.0.16.weight
", "backbone_2d.blocks.0.17.weight", "backbone_2d.blocks.0.17.bias", "backbone_2d.blocks.0.17.running_mean", "backbone_2d.blocks.0.17.running_var", "point_head.cls_layers.0.weight", "point_head.cls_layers.1.weight", "point_head.cl
s_layers.1.bias", "point_head.cls_layers.1.running_mean", "point_head.cls_layers.1.running_var", "point_head.cls_layers.3.weight", "point_head.cls_layers.4.weight", "point_head.cls_layers.4.bias", "point_head.cls_layers.4.running_
mean", "point_head.cls_layers.4.running_var", "point_head.cls_layers.6.weight", "point_head.cls_layers.6.bias", "roi_head.roi_grid_pool_layer.mlps.0.0.weight", "roi_head.roi_grid_pool_layer.mlps.0.1.weight", "roi_head.roi_grid_poo
l_layer.mlps.0.1.bias", "roi_head.roi_grid_pool_layer.mlps.0.1.running_mean", "roi_head.roi_grid_pool_layer.mlps.0.1.running_var", "roi_head.roi_grid_pool_layer.mlps.0.3.weight", "roi_head.roi_grid_pool_layer.mlps.0.4.weight", "ro
i_head.roi_grid_pool_layer.mlps.0.4.bias", "roi_head.roi_grid_pool_layer.mlps.0.4.running_mean", "roi_head.roi_grid_pool_layer.mlps.0.4.running_var", "roi_head.roi_grid_pool_layer.mlps.1.0.weight", "roi_head.roi_grid_pool_layer.ml
ps.1.1.weight", "roi_head.roi_grid_pool_layer.mlps.1.1.bias", "roi_head.roi_grid_pool_layer.mlps.1.1.running_mean", "roi_head.roi_grid_pool_layer.mlps.1.1.running_var", "roi_head.roi_grid_pool_layer.mlps.1.3.weight", "roi_head.roi
grid_pool_layer.mlps.1.4.weight", "roi_head.roi_grid_pool_layer.mlps.1.4.bias", "roi_head.roi_grid_pool_layer.mlps.1.4.running_mean", "roi_head.roi_grid_pool_layer.mlps.1.4.running_var", "roi_head.shared_fc_layer.0.weight", "roi
head.shared_fc_layer.1.weight", "roi_head.shared_fc_layer.1.bias", "roi_head.shared_fc_layer.1.running_mean", "roi_head.shared_fc_layer.1.running_var", "roi_head.shared_fc_layer.4.weight", "roi_head.shared_fc_layer.5.weight", "roi
head.shared_fc_layer.5.bias", "roi_head.shared_fc_layer.5.running_mean", "roi_head.shared_fc_layer.5.running_var", "roi_head.cls_layers.0.weight", "roi_head.cls_layers.1.weight", "roi_head.cls_layers.1.bias", "roi_head.cls_layers
.1.running_mean", "roi_head.cls_layers.1.running_var", "roi_head.cls_layers.4.weight", "roi_head.cls_layers.5.weight", "roi_head.cls_layers.5.bias", "roi_head.cls_layers.5.running_mean", "roi_head.cls_layers.5.running_var", "roi_h
ead.cls_layers.7.weight", "roi_head.cls_layers.7.bias", "roi_head.reg_layers.0.weight", "roi_head.reg_layers.1.weight", "roi_head.reg_layers.1.bias", "roi_head.reg_layers.1.running_mean", "roi_head.reg_layers.1.running_var", "roi
head.reg_layers.4.weight", "roi_head.reg_layers.5.weight", "roi_head.reg_layers.5.bias", "roi_head.reg_layers.5.running_mean", "roi_head.reg_layers.5.running_var", "roi_head.reg_layers.7.weight", "roi_head.reg_layers.7.bias".
Unexpected key(s) in state_dict: "vfe.pfn_layers.0.linear.weight", "vfe.pfn_layers.0.norm.weight", "vfe.pfn_layers.0.norm.bias", "vfe.pfn_layers.0.norm.running_mean", "vfe.pfn_layers.0.norm.running_var", "vfe.pfn_layers.0.
norm.num_batches_tracked", "backbone_2d.blocks.2.1.weight", "backbone_2d.blocks.2.2.weight", "backbone_2d.blocks.2.2.bias", "backbone_2d.blocks.2.2.running_mean", "backbone_2d.blocks.2.2.running_var", "backbone_2d.blocks.2.2.num_b
atches_tracked", "backbone_2d.blocks.2.4.weight", "backbone_2d.blocks.2.5.weight", "backbone_2d.blocks.2.5.bias", "backbone_2d.blocks.2.5.running_mean", "backbone_2d.blocks.2.5.running_var", "backbone_2d.blocks.2.5.num_batches_tra
cked", "backbone_2d.blocks.2.7.weight", "backbone_2d.blocks.2.8.weight", "backbone_2d.blocks.2.8.bias", "backbone_2d.blocks.2.8.running_mean", "backbone_2d.blocks.2.8.running_var", "backbone_2d.blocks.2.8.num_batches_tracked", "ba
ckbone_2d.blocks.2.10.weight", "backbone_2d.blocks.2.11.weight", "backbone_2d.blocks.2.11.bias", "backbone_2d.blocks.2.11.running_mean", "backbone_2d.blocks.2.11.running_var", "backbone_2d.blocks.2.11.num_batches_tracked", "backbo
ne_2d.blocks.2.13.weight", "backbone_2d.blocks.2.14.weight", "backbone_2d.blocks.2.14.bias", "backbone_2d.blocks.2.14.running_mean", "backbone_2d.blocks.2.14.running_var", "backbone_2d.blocks.2.14.num_batches_tracked", "backbone_2
d.blocks.2.16.weight", "backbone_2d.blocks.2.17.weight", "backbone_2d.blocks.2.17.bias", "backbone_2d.blocks.2.17.running_mean", "backbone_2d.blocks.2.17.running_var", "backbone_2d.blocks.2.17.num_batches_tracked", "backbone_2d.de
blocks.2.0.weight", "backbone_2d.deblocks.2.1.weight", "backbone_2d.deblocks.2.1.bias", "backbone_2d.deblocks.2.1.running_mean", "backbone_2d.deblocks.2.1.running_var", "backbone_2d.deblocks.2.1.num_batches_tracked".

size mismatch for backbone_2d.blocks.0.1.weight: copying a param with shape torch.Size([64, 64, 3, 3]) from checkpoint, the shape in current model is torch.Size([128, 256, 3, 3]).
size mismatch for backbone_2d.blocks.0.2.weight: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([128]).
size mismatch for backbone_2d.blocks.0.2.bias: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([128]).
size mismatch for backbone_2d.blocks.0.2.running_mean: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([128]).
size mismatch for backbone_2d.blocks.0.2.running_var: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([128]).
size mismatch for backbone_2d.blocks.0.4.weight: copying a param with shape torch.Size([64, 64, 3, 3]) from checkpoint, the shape in current model is torch.Size([128, 128, 3, 3]).
size mismatch for backbone_2d.blocks.0.5.weight: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([128]).
size mismatch for backbone_2d.blocks.0.5.bias: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([128]).
size mismatch for backbone_2d.blocks.0.5.running_mean: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([128]).
size mismatch for backbone_2d.blocks.0.5.running_var: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([128]).
size mismatch for backbone_2d.blocks.0.7.weight: copying a param with shape torch.Size([64, 64, 3, 3]) from checkpoint, the shape in current model is torch.Size([128, 128, 3, 3]).
size mismatch for backbone_2d.blocks.0.8.weight: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([128]).
size mismatch for backbone_2d.blocks.0.8.bias: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([128]).
size mismatch for backbone_2d.blocks.0.8.running_mean: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([128]).
size mismatch for backbone_2d.blocks.0.8.running_var: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([128]).
size mismatch for backbone_2d.blocks.0.10.weight: copying a param with shape torch.Size([64, 64, 3, 3]) from checkpoint, the shape in current model is torch.Size([128, 128, 3, 3]).
size mismatch for backbone_2d.blocks.0.11.weight: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([128]).
size mismatch for backbone_2d.blocks.0.11.bias: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([128]).
size mismatch for backbone_2d.blocks.0.11.running_mean: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([128]).
size mismatch for backbone_2d.blocks.0.11.running_var: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([128]).
size mismatch for backbone_2d.blocks.1.1.weight: copying a param with shape torch.Size([128, 64, 3, 3]) from checkpoint, the shape in current model is torch.Size([256, 128, 3, 3]).
size mismatch for backbone_2d.blocks.1.2.weight: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.2.bias: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.2.running_mean: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.2.running_var: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.4.weight: copying a param with shape torch.Size([128, 128, 3, 3]) from checkpoint, the shape in current model is torch.Size([256, 256, 3, 3]).
size mismatch for backbone_2d.blocks.1.5.weight: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.5.bias: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.5.running_mean: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.5.running_var: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.7.weight: copying a param with shape torch.Size([128, 128, 3, 3]) from checkpoint, the shape in current model is torch.Size([256, 256, 3, 3]).
size mismatch for backbone_2d.blocks.1.8.weight: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.8.bias: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.8.running_mean: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.8.running_var: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.10.weight: copying a param with shape torch.Size([128, 128, 3, 3]) from checkpoint, the shape in current model is torch.Size([256, 256, 3, 3]).
size mismatch for backbone_2d.blocks.1.11.weight: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.11.bias: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.11.running_mean: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.11.running_var: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.13.weight: copying a param with shape torch.Size([128, 128, 3, 3]) from checkpoint, the shape in current model is torch.Size([256, 256, 3, 3]).
size mismatch for backbone_2d.blocks.1.14.weight: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.14.bias: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.14.running_mean: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.14.running_var: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.16.weight: copying a param with shape torch.Size([128, 128, 3, 3]) from checkpoint, the shape in current model is torch.Size([256, 256, 3, 3]).
size mismatch for backbone_2d.blocks.1.17.weight: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.17.bias: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.17.running_mean: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.blocks.1.17.running_var: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.deblocks.0.0.weight: copying a param with shape torch.Size([64, 128, 1, 1]) from checkpoint, the shape in current model is torch.Size([128, 256, 1, 1]).
size mismatch for backbone_2d.deblocks.0.1.weight: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.deblocks.0.1.bias: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.deblocks.0.1.running_mean: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.deblocks.0.1.running_var: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.deblocks.1.0.weight: copying a param with shape torch.Size([128, 128, 2, 2]) from checkpoint, the shape in current model is torch.Size([256, 256, 2, 2]).
size mismatch for backbone_2d.deblocks.1.1.weight: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.deblocks.1.1.bias: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.deblocks.1.1.running_mean: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for backbone_2d.deblocks.1.1.running_var: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([256]).
size mismatch for dense_head.conv_cls.weight: copying a param with shape torch.Size([18, 384, 1, 1]) from checkpoint, the shape in current model is torch.Size([18, 512, 1, 1]).
size mismatch for dense_head.conv_box.weight: copying a param with shape torch.Size([42, 384, 1, 1]) from checkpoint, the shape in current model is torch.Size([42, 512, 1, 1]).
size mismatch for dense_head.conv_dir_cls.weight: copying a param with shape torch.Size([12, 384, 1, 1]) from checkpoint, the shape in current model is torch.Size([12, 512, 1, 1]).

It seems that the size of some part of the model goes wrong, while i didn't change anything about the model structure, could you please help find out the solution?

Have you fixed this issue?


Use Operator Controller types vs. Rukpak types

In internal/controllers/common_controller.go:
rukpakv1alpha2 vs ocv1alpha1
Same for the other two unpack status conditions below.
		Type:               ocv1alpha1.TypeUnpacked,

Originally posted by @varshaprasad96 in https://github.com/operator-framework/operator-controller/pull/874#discussion_r1618011155

This was basically fixed, with the exception of a function-based API, done in #905.


Bring SE-0016's revision history in line with other proposals.

The proposal was tweaked post-acceptance in 4eae3025, but @dabrahams pointed out that we have a standard format for this now. No content change.
Look good, Dave?

LGTM.


Dispatcher link generation: Change ILinkGenerator interface to an abstract type to allow future expansion

From here: https://github.com/aspnet/Routing/pull/546/files#r195514062
Future design note:
This is pretty bare-bones for now which is fine. We might want this to be an abstract class. It's very likely this surface area will grow.
We also don't expect user code to implement this outside of maybe mocks for testing, so there's no real need to make it easy to do so.

https://github.com/aspnet/Routing/commit/aed2e244831f4aeb3ef5b3b5c33f4a053f70a9a2


Remove deprecated license_file from setup.cfg

Starting with wheel 0.32.0 (2018-09-29), the "license_file" option is deprecated.
https://wheel.readthedocs.io/en/stable/news.html
The wheel will continue to include COPYING, it is now included automatically:
https://wheel.readthedocs.io/en/stable/user_guide.html#including-license-files-in-the-generated-wheel-file

Also update a badge link.

Coverage drop expected, the test case for user.getArtistTracks failed (and marked xfail here) as it looks like Last.fm are now removing it from the API. See #298.
Will update/remove the deprecated method in another PR.


versions: Update kernel to 5.4.77

Update to latest LTS.
Signed-off-by: Archana Shinde<EMAIL_ADDRESS>

/test


CI on PR without attempting to merge master

Supersedes #905
Please refer to commit message for details.

Force-pushed with exact same code (different commit hash).


More than one instance of spotify-connect-web

I installed spotify-web-connect on two differen RPi2, but only one if them shows up in the devices list of the spotify app. Did I something wrong? Or is that by design?
I'm using the same app-key and the same premium account.
Any hint is very much appreciated.
In addition I experience the problem with the strange volume scaling, i.e. using the HW buttons of my phone/tablet controls the volume not smoothly, but starts at very low volume and increases towards the end of the scale exponentially. Is there any solution for that?
BR
André

No it should be possible to have as many clients as you want. Ihave 2 running all the time. But for sure you can only listen to one client at a time.
How do you start spotify connect? Chroot, docker or directly python?
There is one PR for better volume scaling. You can try this. Or you could look in my fork and in console_callbacks.py at the bottom. I used some crude code hack to have a better range.

Now I suppose I know why this happened. I just realized that both RPi2 have the same device-id. I think this is caused due to the fact, that I cloned the SD card.
In which step is this device-id generated? Do I have to install both devices separately?
Will give the new new console_callbacks.py a try. Hope that will improve. Thanks for this advice.

I'm gonna close this for now, feel free to re-open if you're still having problems


Instructions for adding local harp.gl modules into project

I've come across a few people (including myself) asking about configuration instructions on how to use the harp.gl modules from the github source. This way one can use the most recent features committed to master, but not yet available in the npm packages. Can we add a quick guide in this repository on how to do this?
cc @tomasberkeley

I did this once in my personal project:
https://github.com/ninok/harp-physics/commit/04d3b8db9e4c69319695a97d352420472020b4f9
For sure this deserves a separate section in the getting started guide. I created an internal ticket as well.

+1


Stream to Cloud/Live data/Chrome Extension - Serial Driver

With the Chrome plugin you used to be able to stream to the cloud via the serial port.  But now when i plug the microbit in - even with the serial being picked up and a com port active (Mbed serial driver) Chome no longer picks up the live data from the micro:Bit.
Has something changed or is this a bug?
Thanks

Stream to cloud feature was a prototype which we decided not to support at this moment (for various backend related issues).
Can you elaborate on your issue? Are you able to see data locally? Also if you let us know your reasons to stream to cloud. This will help us prioritize the feature.
Feature request: Stream to cloud.

I am excited to stream the data to cloud iot tools such as azure or
adafruit.io. I want the students to be able to visualize the data over
extended periods. I would also like to use iftt. I've noticed a few great
you tube videos showing streaming features. Also at the current time the
serial extension isn't working so it would be great to at least use that in
the meantime. Do you think web Bluetooth will be implemented on the make
code site it seams like a great fit. There are some demos showing the
microbit and web Bluetooth and it works well. Thanks
On Oct 15, 2017 8:07 PM, "Abhijith Chatra"<EMAIL_ADDRESS>wrote:
Stream to cloud feature was a prototype which we decided not to support at
this moment (for various backend related issues).
Can you elaborate on your issue? Are you able to see data locally? Also if
you let us know your reasons to stream to cloud. This will help us
prioritize the feature.
Feature request: Stream to cloud.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/pxt/issues/3232#issuecomment-336768994, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AZlqVCDcu8eYSP7vVyQgkjn9FsxkEB4Qks5ssshegaJpZM4P4ytR
.

Thanks @machinehistories. Have you tried our Windows 10 app for Adafruit Circuit playground express? https://www.microsoft.com/en-us/store/p/makecode-for- adafruit/9pgzhwsk0pgd
You should be able to stream data locally there. We will have discussion on stream to cloud.

Stream to cloud feature was a prototype which we decided not to support at this moment (for various >backend related issues).
Can you elaborate on your issue? Are you able to see data locally? Also if you let us know your reasons >to stream to cloud. This will help us prioritize the feature.

Thanks for the feedback.  I must be missing something or in the wrong group.  The stream to cloud feature is documented on the website as a feature (https://makecode.microbit.org/streaming) and the plugin V0.70 is on the webstore.  I'm specifically talking about this feature with the BBC Micro:bits implementation of PXT.
The URL shift that happened to makecode in July broke the feature.
Thanks - i'll see if I can find the right group
DAmian

How about the serial extension, is that fixed for windows 10? Like DAmian
mentioned there are definite issues with the file paths referenced in the
code for the extension. I am really sorry to hear that about not supporting
the stream function with the microbit. Considering the microbit has ble it
is a much better tool for teaching students about IOT applications. It
seams like a missed opportunity. How about a block that enables a webhook
or block that offers a connection to an external cloud service.  - jason
On Mon, Oct 16, 2017 at 9:40 AM, Abhijith Chatra<EMAIL_ADDRESS>wrote:

Thanks @machinehistories https://github.com/machinehistories. Have you
tried our Windows 10 app for Adafruit Circuit playground express?
https://www.microsoft.com/en-us/store/p/makecode-for-
adafruit/9pgzhwsk0pgd
You should be able to stream data locally there. We will have discussion
on stream to cloud.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/pxt/issues/3232#issuecomment-336946281, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AZlqVEEfbD1EnfFUMeH1qC2VxqXHhdFlks5ss4cDgaJpZM4P4ytR
.

Can you please let me know if the google serial extension is going to be
repaired to work with the new microbit/pxt site. thanks
On Mon, Oct 16, 2017 at 5:39 PM, jason pilarski<EMAIL_ADDRESS>wrote:

How about the serial extension, is that fixed for windows 10? Like DAmian
mentioned there are definite issues with the file paths referenced in the
code for the extension. I am really sorry to hear that about not supporting
the stream function with the microbit. Considering the microbit has ble it
is a much better tool for teaching students about IOT applications. It
seams like a missed opportunity. How about a block that enables a webhook
or block that offers a connection to an external cloud service.  - jason
On Mon, Oct 16, 2017 at 9:40 AM, Abhijith Chatra<EMAIL_ADDRESS>
wrote:

Thanks @machinehistories https://github.com/machinehistories. Have you
tried our Windows 10 app for Adafruit Circuit playground express?
https://www.microsoft.com/en-us/store/p/makecode-for-
adafruit/9pgzhwsk0pgd
You should be able to stream data locally there. We will have discussion
on stream to cloud.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/pxt/issues/3232#issuecomment-336946281,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AZlqVEEfbD1EnfFUMeH1qC2VxqXHhdFlks5ss4cDgaJpZM4P4ytR
.

It would be good to havethis back.  I used this in class and was a great demo.  We should be developing the microbit not removing features.Its still a documented feature in the online manual.  Im sure its more complicated but it is interesting this broke when the url moved again.On 21 Oct 2017 21:42, machinehistories<EMAIL_ADDRESS>wrote:Can you please let me know if the google serial extension is going to be
repaired to work with the new microbit/pxt site. thanks
On Mon, Oct 16, 2017 at 5:39 PM, jason pilarski<EMAIL_ADDRESS>wrote:

How about the serial extension, is that fixed for windows 10? Like DAmian
mentioned there are definite issues with the file paths referenced in the
code for the extension. I am really sorry to hear that about not supporting
the stream function with the microbit. Considering the microbit has ble it
is a much better tool for teaching students about IOT applications. It
seams like a missed opportunity. How about a block that enables a webhook
or block that offers a connection to an external cloud service.  - jason
On Mon, Oct 16, 2017 at 9:40 AM, Abhijith Chatra<EMAIL_ADDRESS>
wrote:

Thanks @machinehistories https://github.com/machinehistories. Have you
tried our Windows 10 app for Adafruit Circuit playground express?
https://www.microsoft.com/en-us/store/p/makecode-for-
adafruit/9pgzhwsk0pgd
You should be able to stream data locally there. We will have discussion
on stream to cloud.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/pxt/issues/3232#issuecomment-336946281,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AZlqVEEfbD1EnfFUMeH1qC2VxqXHhdFlks5ss4cDgaJpZM4P4ytR
.

—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or mute the thread.

Couple of different issues are discussed in this thread.
Update for Micro:bit extension for Chrome:
We are in the process of fixing the existing extension. As this involves a cumbersome release process, it is taking longer than expected. I will update as soon as the update is in the chrome store.
Installing an extension is still a barrier for lot of teachers. Website works on all devices and browsers.
For a long term design perspective, ideally we want to move to a pure web based solution such as webusb (https://wicg.github.io/webusb/) to access USB device and show serial data.  Although webusb is still in nascent stage and it will take years for the browsers to catch up.

Great news if tbe extension is being fixed.  It took a while to be 'allowed' this at my school so for it to stop working was frustrsitingOn 24 Oct 2017 19:29, Abhijith Chatra<EMAIL_ADDRESS>wrote:Couple of different issues are discussed in this thread.
Update for Micro:bit extension for Chrome:
We are in the process of fixing the existing extension. As this involves a cumbersome release process, it is taking longer than expected. I will update as soon as the update is in the chrome store.
Installing an extension is still a barrier for lot of teachers. Website works on all devices and browsers.
For a long term design perspective, ideally we want to move to a pure web based solution such as webusb (https://wicg.github.io/webusb/) to access USB device and show serial data.  Although webusb is still in nascent stage and it will take years for the browsers to catch up.
—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or mute the thread.

@damianburrin Just to clarify extension is used for serial data and if we implement WebUSB protocol and the serial data is available to browser natively it would serve your purpose as well right?
It would be great if you walk us through your usage of extension.

Exciting and glad to hear it is being fixed.
On Tue, Oct 24, 2017 at 3:40 PM, Abhijith Chatra<EMAIL_ADDRESS>wrote:

@damianburrin https://github.com/damianburrin Just to clarify extension
is used for serial data and if we implement WebUSB protocol and the serial
data is available to browser natively it would serve your purpose as well
right?
It would be great if you walk us through your usage of extension.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/pxt/issues/3232#issuecomment-339158083, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AZlqVCwVCFWwXMr4yQ_-OTc7gLd-aDxaks5svmdTgaJpZM4P4ytR
.

I don’t do anything “special” but it’s the stream to cloud native support with Azzure that i use and would really like back.
This is the youtube video that i use to support staff from my CAS hub https://www.youtube.com/watch?v=JQ-adInOCx4&list=PLvZXTXiQDCe7n5k7OqJONYOU6sIBQgHp1&index=15&t=1s and this worksheet i use to do a practical demo to teachers.  http://www.microbitsandbobs.co.uk/projects/Project_26_Making_a_Remote_Sensor.pdf
The tutorial i did for Lee Stott at Microsoft is half-way down this page https://blogs.msdn.microsoft.com/uk_faculty_connection/2016/08/01/getting-started-microbit-microsofts-new-www-codethemicrobit-com-environment/ which is what is use with my students
This feature was really nice as it introduced the idea of interconnectivity.  I tend to move from this to using App inventor with it IOT extension and make a remote temp sensor for my “Fizzy Pop” that sends a message to my phone when its at the optimal temperature.
Thank you for the support in trying to resolve the issues
Damian
From: Abhijith Chatra
Sent: Tuesday, October 24, 2017 11:40 PM
To: Microsoft/pxt
Cc: Damian ; Mention
Subject: Re: [Microsoft/pxt] Stream to Cloud/Live data/Chrome Extension - Serial Driver (#3232)
@damianburrin Just to clarify extension is used for serial data and if we implement WebUSB protocol and the serial data is available to browser natively it would serve your purpose as well right?
It would be great if you walk us through your usage of extension.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Damian's videos are what really got me excited about the microbit and
motivated me to purchase one. I was planning on using the stream to web
function as an intro to IOT in my class at Art Center College of Design. I
was really let down when I was preparing for my in class demo and realized
it didn't work.  In addition to the serial function being operational in
the microbit extension, I would like to be able to use the stream to web
feature. It just doesn't make sense to take away features preferably we
want to have access to more features not less. The coolest thing about the
microbit is that it can do a variety of things and it can be used a
fantastic inro to many different technologies. Please maintain support for
stream feature since it is just too important a topic to miss out on. -
jason
On Wed, Oct 25, 2017 at 3:22 AM, Damian<EMAIL_ADDRESS>wrote:

I don’t do anything “special” but it’s the stream to cloud native support
with Azzure that i use and would really like back.
This is the youtube video that i use to support staff from my CAS hub
https://www.youtube.com/watch?v=JQ-adInOCx4&list=
PLvZXTXiQDCe7n5k7OqJONYOU6sIBQgHp1&index=15&t=1s and this worksheet i use
to do a practical demo to teachers. http://www.microbitsandbobs.
co.uk/projects/Project_26_Making_a_Remote_Sensor.pdf
The tutorial i did for Lee Stott at Microsoft is half-way down this page
https://blogs.msdn.microsoft.com/uk_faculty_connection/
2016/08/01/getting-started-microbit-microsofts-new-www-
codethemicrobit-com-environment/ which is what is use with my students
This feature was really nice as it introduced the idea of
interconnectivity. I tend to move from this to using App inventor with it
IOT extension and make a remote temp sensor for my “Fizzy Pop” that sends a
message to my phone when its at the optimal temperature.
Thank you for the support in trying to resolve the issues
Damian
From: Abhijith Chatra
Sent: Tuesday, October 24, 2017 11:40 PM
To: Microsoft/pxt
Cc: Damian ; Mention
Subject: Re: [Microsoft/pxt] Stream to Cloud/Live data/Chrome Extension -
Serial Driver (#3232)
@damianburrin Just to clarify extension is used for serial data and if we
implement WebUSB protocol and the serial data is available to browser
natively it would serve your purpose as well right?
It would be great if you walk us through your usage of extension.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/pxt/issues/3232#issuecomment-339285000, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AZlqVOVEHDf_pduYrpSii9_XHSoO-xnIks5svwvRgaJpZM4P4ytR
.

Unfortunately, it seems that extensions do not have access to serial anymore. I don't think the Chrome extension can be supported going forward.

Adding on to Peli's reply.
Chrome has removed chrome.serial API for access from extension. It is not possible for the extension to access serial anymore.
We do think there is a genuine need for the access serial.  Our plan is to concentrate our efforts on webusb going forward. This will take a longer than we expected and will update you on our progress. Thanks for understanding.

Oh that is a shame.Hopefully the wrbusb will resolve thisOn 31 Oct 2017 18:47, Abhijith Chatra<EMAIL_ADDRESS>wrote:Adding on to Peli's reply.
Chrome has removed chrome.serial API for access from extension. It is not possible for the extension to access serial anymore.
We do think there is a genuine need for the access serial.  Our plan is to concentrate our efforts on webusb going forward. This will take a longer than we expected and will update you on our progress. Thanks for understanding.
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

Now that webusb is working in the beta editor do you think it's possible to put the stream to cloud function back in for testing.

Thanks for the request. Yes, with webusb we have access to serial now and seems to be working well. For streaming to cloud we still need to build a backend infrastructure (it was just a prototype in the past) and it has to be GDPR compliant. Can you please open a feature request on pxt-microbit with the scenario you need? There might be various other ways we could lighten up the scenario.


Cache for area-weighted regridder

This has been a major issue for several people, here are a few links to provide some context:
https://github.com/SciTools/iris/issues/2370
https://exxconfigmgmt:6391/browse/EPM-1542

The same is true for all of the regridders currently in iris I believe (Linear/Nearest/AreaWeighted).  No caching of weights and indices takes place.

i would like to put this together into a use case for some planned enhancement work we have for later this year
further comments and thoughts on this, to keep it in my notifications, are much appreciated

Use case: The AreaWeighted is currently the only conservative scheme.
AreaWeighted is ~1000 time slower than Linear or Nearest.
Is it necessary to have two ways of doing regridding?

pass a regridding scheme to the regrid method of a cube
create a Regridder object

If the weight creation is the most expensive step, a regridding function could return the weights explicitly, and feed them into the regridding function the next time. This would not add more complexity to the user than using Regridder objects, but would potentially be much simpler.
Testing the current caching method seems difficult. (Is it caching? Is it using the cache? it there a benefit using the cache?)

@tv3141 the current UI allows for a generic interface to regridding/interpolation and for the implementation details be hidden from the user.  This framework is what allows caching to be developed without changing the UI for users.
I think the issue you raise would be better approached by extending the docstrings which should highlight current capabilities and limitations.  help(iris.analysis.Linear) for example is rather lacking in necessary details.

The area-weighted regridding is done in a large loop over the target grid points. The weights are calculated inside the loop for each target grid point. The regridding is done in one step for all dimensions (time, levels).
https://github.com/SciTools/iris/blob/v1.12.x/lib/iris/experimental/regrid.py#L503
def _regrid_area_weighted_array(src_data, x_dim, y_dim,
                                src_x_bounds, src_y_bounds,
                                grid_x_bounds, grid_y_bounds,
                                grid_x_decreasing, grid_y_decreasing,
                                area_func, circular=False, mdtol=0):

    [...]

    # Simple for loop approach.
    for j, (y_0, y_1) in enumerate(grid_y_bounds):

        [...]

        for i, (x_0, x_1) in enumerate(grid_x_bounds):

            [...]

                data = src_data[tuple(indices)]

                # Calculate weights based on areas of cropped bounds.
                weights = area_func(y_bounds, x_bounds)

                [...]

                # Calculate weighted mean taking into account missing data.
                new_data_pt = _weighted_mean_with_mdtol(data,
                    weights=weights, axis=axis, mdtol=mdtol)

                # Insert data (and mask) values into new array.

                [...]

                new_data[tuple(indices)] = new_data_pt

    [...]

    return new_data

def _weighted_mean_with_mdtol(data, weights, axis=None, mdtol=0):
    """
    ...
    """
    res = ma.average(data, weights=weights, axis=axis)

    [...]

    return res

Profiling

around 3/4 of the time is spent in np.ma.average
weight calculation takes currently less than 10% of the time
linear complexity
largest factor: number of target grid points
run time is almost independent of source grid
increasing the amount of data (more time steps or levels) increases the run with a small linear factor

import cProfile
import pstats
import iris

areaweighted_regridder = iris.analysis.AreaWeighted().regridder(create_cube(*resolution['N768']), \
                                                                create_cube(*resolution['N96']))
cube = create_cube(*resolution['N768'], levels=3)
cProfile.run('areaweighted_regridder(cube)', 'aw_regrid.prof')
stats = pstats.Stats('aw_regrid.prof')
stats.strip_dirs()
stats.sort_stats('cumulative')
stats.print_stats()

Tue May  2 17:05:24 2017    aw_regrid.prof

         9573273 function calls (9573143 primitive calls) in 12.114 seconds

   Ordered by: cumulative time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000   12.114   12.114 <string>:1(<module>)
        1    0.000    0.000   12.114   12.114 _area_weighted.py:89(__call__)
        1    0.000    0.000   12.114   12.114 regrid.py:627(regrid_area_weighted_rectilinear_src_and_grid)
        1    0.487    0.487   12.110   12.110 regrid.py:405(_regrid_area_weighted_array)
    27648    0.070    0.000    9.490    0.000 regrid.py:353(_weighted_mean_with_mdtol)
--> 27648    0.270    0.000    9.400    0.000 extras.py:464(average)
   138241    1.139    0.000    3.060    0.000 core.py:2865(__array_finalize__)
    27648    0.066    0.000    2.861    0.000 core.py:3908(__truediv__)
    55296    0.230    0.000    2.842    0.000 core.py:1002(reduce)
   248833    1.224    0.000    2.785    0.000 core.py:2839(_update_from)
    27648    0.774    0.000    2.769    0.000 core.py:1109(__call__)
    ...
    27648    0.041    0.000    0.801    0.000 regrid.py:324(_spherical_area)  # weights

np.ma.average 10x slower than np.average
import numpy as np
print np.__version__

arr = np.random.rand(1,8,8,3)
w = np.random.rand(1,8,8,3)

print 'np.ma.average axis'
print np.ma.average(arr, weights=w, axis=(1,2))
%timeit a = np.ma.average(arr, weights=w, axis=(1,2))
print

print 'np.average axis'
print np.ma.average(arr, weights=w, axis=(1,2))
%timeit a = np.average(arr, weights=w, axis=(1,2))

1.12.1
np.ma.average axis
[[0.5558622851924222 0.5015630215812361 0.512327031679091]]
1000 loops, best of 3: 240 µs per loop

np.average axis
[[0.5558622851924222 0.5015630215812361 0.512327031679091]]
10000 loops, best of 3: 27.4 µs per loop

Even without mask np.ma.average is ~10x slower than the normal array version np.average. I do not understand why, identical lines of code have large differences in execution time.
import numpy as np
print np.__version__  # 1.12.1
from line_profiler import LineProfiler

arr = np.random.rand(1,8,8,3)
w = np.random.rand(1,8,8,3)

lp = LineProfiler()
lp_wrapper = lp(np.ma.average)
lp_wrapper(arr, weights=w)
lp.print_stats()

lp = LineProfiler()
lp_wrapper = lp(np.average)
lp_wrapper(arr, weights=w)
lp.print_stats()

Timer unit: 1e-06 s

Total time: 0.000392 s
File: ~/localdata/python_test/miniconda/envs/iris_new_np/lib/python2.7/site-packages/numpy/ma/extras.py
Function: average at line 521

Line #      Hits         Time  Per Hit   % Time  Line Contents
==============================================================
   521                                           def average(a, axis=None, weights=None, returned=False):

   572         1          105    105.0     26.8      a = asarray(a)
   573         1            4      4.0      1.0      m = getmask(a)
   574
   575                                               # inspired by 'average' in numpy/lib/function_base.py
   576
   577         1            1      1.0      0.3      if weights is None:
   578                                                   avg = a.mean(axis)
   579                                                   scl = avg.dtype.type(a.count(axis))
   580                                               else:
   581         1            6      6.0      1.5          wgt = np.asanyarray(weights)
   582
   583         1            3      3.0      0.8          if issubclass(a.dtype.type, (np.integer, np.bool_)):
   584                                                       result_dtype = np.result_type(a.dtype, wgt.dtype, 'f8')
   585                                                   else:
   586         1            3      3.0      0.8              result_dtype = np.result_type(a.dtype, wgt.dtype)
   587
   588                                                   # Sanity checks
   589         1            2      2.0      0.5          if a.shape != wgt.shape:

   605         1            1      1.0      0.3          if m is not nomask:
   606                                                       wgt = wgt*(~a.mask)
   607
   608         1           35     35.0      8.9          scl = wgt.sum(axis=axis, dtype=result_dtype)
   609         1          230    230.0     58.7          avg = np.multiply(a, wgt, dtype=result_dtype).sum(axis)/scl
   610
   611         1            1      1.0      0.3      if returned:
   612                                                   if scl.shape != avg.shape:
   613                                                       scl = np.broadcast_to(scl, avg.shape).copy()
   614                                                   return avg, scl
   615                                               else:
   616         1            1      1.0      0.3          return avg

Timer unit: 1e-06 s

Total time: 9.7e-05 s
File: ~/localdata/python_test/miniconda/envs/iris_new_np/lib/python2.7/site-packages/numpy/lib/function_base.py
Function: average at line 1021

Line #      Hits         Time  Per Hit   % Time  Line Contents
==============================================================
  1021                                           def average(a, axis=None, weights=None, returned=False):

  1095                                               # 3/19/2016 1.12.0:
  1096                                               # replace the next few lines with "a = np.asanyarray(a)"
  1097         1            3      3.0      3.1      if (type(a) not in (np.ndarray, np.matrix) and

  1106         1            3      3.0      3.1      if not isinstance(a, np.matrix):
  1107         1            7      7.0      7.2          a = np.asarray(a)
  1108
  1109         1            1      1.0      1.0      if weights is None:
  1110                                                   avg = a.mean(axis)
  1111                                                   scl = avg.dtype.type(a.size/avg.size)
  1112                                               else:
  1113         1            4      4.0      4.1          wgt = np.asanyarray(weights)
  1114
  1115         1            4      4.0      4.1          if issubclass(a.dtype.type, (np.integer, np.bool_)):
  1116                                                       result_dtype = np.result_type(a.dtype, wgt.dtype, 'f8')
  1117                                                   else:
  1118         1            3      3.0      3.1              result_dtype = np.result_type(a.dtype, wgt.dtype)
  1119
  1120                                                   # Sanity checks
  1121         1            2      2.0      2.1          if a.shape != wgt.shape:

  1137         1           32     32.0     33.0          scl = wgt.sum(axis=axis, dtype=result_dtype)
  1138         1           16     16.0     16.5          if (scl == 0.0).any():
  1139                                                       raise ZeroDivisionError(
  1140                                                           "Weights sum to zero, can't be normalized")
  1141
  1142         1           20     20.0     20.6          avg = np.multiply(a, wgt, dtype=result_dtype).sum(axis)/scl
  1143
  1144         1            1      1.0      1.0      if returned:
  1145                                                   if scl.shape != avg.shape:
  1146                                                       scl = np.broadcast_to(scl, avg.shape).copy()
  1147                                                   return avg, scl
  1148                                               else:
  1149         1            1      1.0      1.0          return avg

To learn more about np.ma.average, I copied its code in a Jupyer notebook, and started removing non-essential code. I noticed that running a copy of the function np.ma.average in the current namespace speeds it up more than 10x.  It also produces single precision results instead of double precision.
Any ideas what makes np.ma.average slow, and what causes the speed-up?
What determines the precision of the calculation?
import inspect
import numpy as np
print np.__version__  # 1.12.1

# imports for copied code
from numpy import asarray
from numpy.ma import getmask, nomask

def ma_average(a, axis=None, weights=None, returned=False):
    # copied code from
    # print inspect.getsourcefile(np.ma.average)

arr = np.random.rand(1,8,8,3)
w = np.random.rand(1,8,8,3)

print 'np.ma.average'
print np.ma.average(arr, weights=w, axis=(1,2))
%timeit a = np.ma.average(arr, weights=w, axis=(1,2))
print

print 'ma_average'
print ma_average(arr, weights=w, axis=(1,2))
%timeit a = ma_average(arr, weights=w, axis=(1,2))
print

print 'np.average'
print np.ma.average(arr, weights=w, axis=(1,2))
%timeit a = np.average(arr, weights=w, axis=(1,2))
print

np.ma.average
[[0.5798026614723218 0.45410607639507333 0.4378237178069648]]
1000 loops, best of 3: 238 µs per loop

ma_average
[[ 0.57980266  0.45410608  0.43782372]]
10000 loops, best of 3: 21.9 µs per loop

np.average
[[0.5798026614723218 0.45410607639507333 0.4378237178069648]]
10000 loops, best of 3: 27.4 µs per loop

np.ma.average calls a = asarray(a) to convert a into a masked array. When I copied the code I imported the wrong asarray function:
from numpy import asarray

when it should have been
from numpy.ma import asarray

This also makes the 'local' ma.average slow again, so things make sense again.
np.ma.average is much slower than np.average when applied to small unmasked arrays, because of the expensive conversion to a masked array np.ma.asarray(a), and np.multiply(arr) being much slower when called with a masked array.

I realised I perhaps neglected to mention that I would also really like to see caching implemented in iris :)
Really interesting observations on masked arrays.  Feels like quite a significant refactor to make this happen.
To make weights useful, these should also be accessible to the end user (examples where users might use them directly - applying them to sparse arrays) and secondly, perhaps having these cached to disk or something.  A lot to think about I think...

Re-order to be [..., y_dim, _dim].  See PR #3587
Ensure x_dim and y_dim.  See #3588
Optimise averaging:  Move averaging out of loop and refactor weights.  See #3589

Update from refinement meeting:
The current status of the work was discussed. We think completing it is achievable with approx:
•	½ day review work associated with re-jigging the current regrid_area_weighted_rectilinear_src_and_grid function
•	4 days refactoring the tests  (1 day for weights function, 1 day for __prepare, __perform, 1 day regridder, 1 day review comments)
•	1 day review work for the above
•	Assistance from the sprint team (e.g. setting up an Iris build, updating test data)
•	(This is additional to the ~week of scoping/dev work already undertaken by AVD)
This nicely aligns with the 5 days dev work that Emma/Andy are providing.

Optimisation AC - time to process a single cube is quicker than previously see #2370

The feature branch, upstream/area_weighted_regridding can be merged.
There are four outstanding items:

Some extra comments describing the regrid_info weight variables would be useful
The "jit" could be added in the future for further speed up
The ASV test needs further investigation as this should be demonstrated a speed up.  (Our other testing shows the optimization delivers speed-up)
The dtype of the data returned remains unchanged.  However, we think the current regridding should return the original data dtype, but it isn't necessarily doing this at present.

Hi @abooton apologies if this isn't useful or I'm too late, but for what it's worth:

Awesome stuff!  The issue of offline weights that you rightly keep off the table for this ticket might be worth talking about when you are ready - we have done this for our own ESMF regridder scheme.
I wonder what the implications are for memory usage here from these changes.  Do you have any thoughts?  - I think my gut would be that it would be that it should still be reasonable given the alternative approaches available which certainly give iris a lot more wiggle in this regard :)

...However, we think the current regridding should return the original data dtype...

I'm not 100% sure I have understood the context here but I would have thought it reasonable/flexible that area weighted regridding return data which relates to the source dtype by the following relation:
tgt_dtype = np.promote_types(src_dtype, 'float16')

Hope this helps in some way.
Merry Christmas!

The following quick check indicates we expect the ASV tests should have seen a noticeable improvement:
# commit  738093f1:  time: areawieghted_regridder 13.124 s  pre-optimisation
# commit  0d1ddb40:  time: areawieghted_regridder 1.575 s   post-optimisation

from iris import tests
import iris
from time import time

def regridding_test():
    file_path = tests.get_data_path(
                ["NetCDF", "global", "xyt", "SMALL_hires_wind_u_for_ipcc4.nc"]
            )
    cube = iris.load_cube(file_path)
    scheme_area_w = iris.analysis.AreaWeighted()
    ts = time()
    cube.regrid(cube, scheme_area_w)
    tf = time()
    print('areawieghted_regridder',round(tf - ts, 3), 's')

regridding_test()

Hi @cpelley,
Thanks for your thoughts.

Regarding the memory use:

I wonder what the implications are for memory usage here from these changes.  Do you have any thoughts?  - I think my gut would be that it would be that it should still be reasonable given the alternative approaches available which certainly give iris a lot more wiggle in this regard :)

We'd not specifically looked at this as the user requirement was for reducing computation time.  The regridder object now retains the weights (which may be similar in size to the 2D data array, or might be bigger as they are float64).  I would think the memory requried to average the data would be forin 2D diagnostics might be a bit more because 1) the weights are pushed into a additional array and 2) the src data is initially stored in an array larger than that of the target grid prior to computing the mean.  (Previously the weights and mean were computed independently by looping through every point on the target grid, so I think the memory would have been released between each calculation).  It should be noted that the total memory useage of the new code could easily be optimised in a future PR, by initally storing the weights in the numpy array structure required by the regridding "perform" code.  This further refactoring hasn't been done yet, as we didn't wish to introduce a bug into the weights calculations.

Regarding the data type:

I'm not 100% sure I have understood the context here but I would have thought it reasonable/flexible that area weighted regridding return data which relates to the source dtype by the following relation:
tgt_dtype = np.promote_types(src_dtype, 'float16')
To clarify, the changes here retain the current dtype behaviour.   However I was concerned that integer source data can be returned as type float.

src_dtype = np.int32
tgt_dtype = np.promote_types(src_dtype, 'float16')
print(tgt_dtype)
>> float64

...could easily be optimised in a future PR, by initally storing the weights in the numpy array structure required by the regridding "perform" code...

Awesome!  Yes this is how we made ESMF regridding approachable (the memory overhead there really is too large).  Do feel free to give me a shout for a chat if/when you think it might be useful to do so.

To clarify, the changes here retain the current dtype behaviour...

I don't think AreaWeighted/bilinear regridding should ever return integer types.  Performing area conservative regridding implies to me floats in the return since area calculations should be float.  The result needs to be always both locally and globally conservative.

I wonder what the implications are for memory usage here from these changes. Do you have any thoughts? - I think my gut would be that it would be that it should still be reasonable given the alternative approaches available which certainly give iris a lot more wiggle in this regard :)

@cpelley, using memory_profiler I generated the following plots by loading a cube (where cube.data.shape = (31, 160, 320)), then performing regridding 10 times:
using master, profiling regrid_area_weighted_rectilinear_src_and_grid:

using the feature branch, profiling _regrid_area_weighted_rectilinear_src_and_grid__prepare and _regrid_area_weighted_rectilinear_src_and_grid__perform:

The memory profiles are very similar, so these changes haven't made an impact on the memory usage :)

I think this is probably addressed by #3617
It's complicated, so need to spend some effort to confirm this is the case ?

The following quick check indicates we expect the ASV tests should have seen a noticeable improvement:
commit  738093f1:  time: areawieghted_regridder 13.124 s  pre-optimisation
commit  0d1ddb40:  time: areawieghted_regridder 1.575 s   post-optimisation

This has been addressed by #3660 - asv now demonstrates a change in performance at the appropriate commit.

closed by #3623
Outstanding (numba) acceptance criteria is "nice to have".


[question] How do new Docker 1.9.0 features (Swarm, Multi-Host networking) affect Rancher?

Should they play nicely (e.g. Rancher managed network and Docker multi-host network across the same set of hosts)?
Are there plans to use Docker's multi-host network feature to replace Rancher's implementation?
Are there any advantages of one over the other?
Are there any conflicts to be expected with Swarm?
Thx!!!

Here's some forum posts on this topic:
http://forums.rancher.com/t/rancher-networking-architecture-vs-libnetzwork-docker-1-9/685/3
http://forums.rancher.com/t/docker-1-9-multi-host-networking-swarm-etc/869

:heart_eyes_cat: AWESOME. Thank you for all of this!


React-Router v4: missing history in ContextRouter

According to documentation, the shape of ContextRouter is not valid because methods like push(), replace(), ... are passed as history object.

See #714 which corrects this exact issue.

#714 has been merged, I suppose this one could be closed !


ENG-1666: Explicitly add the "/api" path prefix to the FE api call

Should we change the .ftl files too?
exemple:
https://github.com/entando/entando-blueprint/blob/master/generators/entity-server/templates/ui/widgets/detailsWidget/bundle/details-widget.ftl.ejs#L6

Should we change the .ftl files too?
example:
https://github.com/entando/entando-blueprint/blob/master/generators/entity-server/templates/ui/widgets/detailsWidget/bundle/details-widget.ftl.ejs#L6

@avdev4j we don't, if your change also the service-url you will end up with ../api/api/..
However changing only the service-url and not changing the const resource =.. in the  ejs  is a possible alternative fix.

Should we change the .ftl files too?
example:
https://github.com/entando/entando-blueprint/blob/master/generators/entity-server/templates/ui/widgets/detailsWidget/bundle/details-widget.ftl.ejs#L6

@avdev4j the bundle if packaged that /api disappears, so it's not necessary. However make sense, so it's probably better to do it anyway


Fallback download artifacts

There is an issue with the latest Linux artifacts (GitHub fault)

Perhaps a good idea to give an older artifact that is available as release?
It's uncommon to happen but a good idea in case something fails.

I think this current behaviour is acceptable.

it makes the issue highly visible so it is resolved
the previous release can be downloaded below from the table
we release at a rate lately where this is only an issue for a day or so

I also think its confusing (though technically valid) UX to mix versions on what is supposed to be the latest release section.

I also agree that making it clear there was no release is the best option rather than being out of step between OS type (Although I was able to find a binary for 1.7.2570 and for every release in last 7 pages)
As long as we're greying out the Tux icon in the older binaries like we are doing for the latest release I think it's obvious enough and people will just skip back a build.

That's fine, if that's the decision, but I can almost guarantee we will get questions like

Where is the latest linux version (because they won't look down)
or
Why have you stopped making the emulator linux compatible?

I would suggest at least having a note in the popup to say to get a previous release from the links below or something, just to hold peoples hands a bit.

That's fine, if that's the decision, but I can almost guarantee we will get questions like
1. Where is the latest linux version (because they won't look down)
   or

2. Why have you stopped making the emulator linux compatible?

I would suggest at least having a note in the popup to say to get a previous release from the links below or something, just to hold peoples hands a bit.

Yeah, I did it in the mind of a regular user, while I'm very sure everyone at the PCSX2 team will get what to do which is not something I would think of for a normal user and to be frank there are so many styles and things different compared to other emulators.

I don't think we should design the site who lack the basic skills to look at the build list.
The other side of this argument is that accommodating for these kind of users is worth it due to the cost of our volunteers sanity in answering the same questions, if people are confident that this issue is so common that it's justified maybe it's worth doing.


Issue Title: Adding hover effect on color icons
resolve issue: #42
Type of change ☑
What sort of change have you made:

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist: ☑

[ ] My code follows the guidelines of this project.
[ ] I have performed a self-review of my own code.
[ ] I have commented my code, particularly wherever it was hard to understand.
[ ] I have made corresponding changes to the documentation.
[ ] My changes generate no new warnings.
[ ] I have added things that prove my fix is effective or that my feature works.
[ ] Any dependent changes have been merged and published in downstream modules.

How Has This Been Tested? ⚙
Describe how have you verified the changes made.
Tested it manually on my local setup

Hi @souvik-maity 👋🏻
Can you share us a screen-recorded video to see what changes you made?

https://github.com/singodiyashubham87/Draw-it-out/assets/145227417/397fa435-90ff-4275-ab58-819c8037751f

kindly check the changes made and consider merging it.

@souvik-maity Thanks for contributing! :)


Validation of payload of TrustedIsssuerRecord

Method validTrustedIssuerRecord   https://github.com/walt-id/waltid-ssikit/blob/0d978406056ce206271fc3bb1517e38b9a9226e3/src/main/kotlin/id/walt/auditor/VerificationPolicy.kt#L109 should be extended to validate the JWT as well as the decoded payload of the token.

Hello,
We are part of EBSI4RO and have been working in understanding EBSI and Walt.id and also have been looking over the Policies. We have just been added in the trusted issuer registry and our attributes do not match with the ones tested against in the mentioned method validTrustedIssuerRecord.
Here is our issuer entry with it’s attribute https://api.preprod.ebsi.eu/trusted-issuers-registry/v2/issuers/did%3Aebsi%3AzfPHQeMuKeSE7Ff35BcH7xL
At this moment I couldn’t find a TIR entry with the strings which the code is testing against for comparison.
As seen here: https://ec.europa.eu/cefdigital/wiki/display/EBSIDOC/Trusted+Issuers+Registry+API#attribute+data+model the hash represents the keccak256 hash of the payload and the body is base64 encoded content.
I believe there isn’t any reason to validate the hash, considering it is being used as an identifier, but instead decode the base64 body which would result in something like:
{
   "@context":"https://ebsi.eu",
   "type":"attribute",
   "name":"issuer",
   "data":"5d50b3fa18dde32b384d8c6d096869de"
}

I haven’t been able to figure out what the data represents, but seems that the name and type field might be more appropriate to test against.
Also, is it safe to assume we will always have this entry at the first index of the attributes array?


refactor(ndt_scan_matcher): integrate ndt_align_srv into ndt_scan_matcher_core.cpp

Description
This pull request solves the problem that ndt_align_srv is implemented twice in pose_initialization_module.cpp and map_update_module.cpp in ndt_scan_matcher.
The ndt_align_srv has been modified to be implemented only once in ndt_scan_matcher_core.cpp.
Tests performed
By using AWSIM, I confirmed
(1) Initial position estimation is successful, and then the vehicle can run normally.
(2) Initial position estimation can be redone multiple times
Effects on system behavior
There is no change in behavior seen from outside the package.
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

@kminoda
Thank you very much for the review.
I made sure that Autoware works properly with the sample rosbag when the use_dynamic_map_loading is both true and false.


Add sanjana-rathish Markdown

Project Request

Proejct Request to Add [your name] markdown file and route

Field
Description

Name
Sanjana Rathish

Email
<EMAIL_ADDRESS>

Github
SanjanaRathish

What do you what to contribute to:

[ ] HackFest GDSC Contributor
[ ] Hacktober Fest Contributor

Please add your github link instead of github username.


MNT: rerender

Hi! This is the friendly automated conda-forge-webservice.
I've started rerendering the recipe as instructed in #39.
If I find any needed changes to the recipe, I'll push them to this PR shortly. Thank you for waiting!
Here's a checklist to do before merging.

[ ] Bump the build number if needed.

Fixes #39

@traversaro - I opened this PR for debugging; it seems like the issue seen in #38 is indeed triggered (somehow) by the changes in libboost.


Agenda for April 30, 2024

This will be a meeting for All-Sigs but will include a section on future planning and roadmap highlighting for after the next release and onward.

After the all sigs portion, I would like to discuss our maintainer structure and propose a small change to nominate a 'lead maintainer' who can act as a tie breaker when/if needed.

After the all sigs portion I would like to discuss how the community wants to determine the future of O3DE for the second half of 2024. What major initiatives should we undertake? We know we need to improve asset build times (either via an asset cache server or other means). Do we start planning for untangling the renderer from O3DE proper, but making sure the renderer is the default for O3DE. How far down the path of GenAI do we want to go? Do we want to try to convince a contributor or two to work on a particle system for O3DE? Any and all thoughts are welcome.


inherit from a normal python class

Initial Checks

[X] I have searched Google & GitHub for similar requests and couldn't find anything
[X] I have read and followed the docs and still think this feature is missing

Description
Hay,
thanks for maintaining such a great lib.
I noticed that the functionality of the BaseModel is a bit limited.
Thus I would like to have the support the enhance a normal class from python with the functionality of a BaseModel.
So the user does not have to know from minute 0 that he will use BaseModel.
what is possible now
class Base(BaseModel):
    foo:str
    bar:str

class A(Base):
    bas: str

A.__fields__, A(foo="abc",bar="xyz",bas=123)

outputs:
({'foo': ModelField(name='foo', type=str, required=True),
  'bar': ModelField(name='bar', type=str, required=True),
  'bas': ModelField(name='bas', type=str, required=True)},
 A(foo='abc', bar='xyz', bas='123'))

what I would like to have
class Base:
    foo:str
    bar:str

class A(BaseModel,Base):
    bas: str

A.__fields__, A(foo="abc",bar="xyz",bas=123)

current output:
({'bas': ModelField(name='bas', type=str, required=True)}, A(bas='123'))

Implementing this would hold the DRY principle and could simplify  the ORM methology https://pydantic-docs.helpmanual.io/usage/models/#orm-mode-aka-arbitrary-class-instances
Thanks in advance and looging forward to the discussion!
Affected Components

[ ] Compatibility between releases
[X] Data validation/parsing
[ ] Data serialization - .dict() and .json()
[ ] JSON Schema
[X] Dataclasses
[ ] Model Config
[ ] Field Types - adding or changing a particular data type
[ ] Function validation decorator
[ ] Generic Models
[ ] Other Model behaviour - construct(), pickling, private attributes, ORM mode
[ ] Settings Management
[ ] Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.

I don't agree about this. V2 will support lots of forms of validation, but this seems outside the bounds of what we want to support.


perf

perf

this isn't non specific this is wiring our tests up to a very specific binary https://perf.wiki.kernel.org/index.php/Main_Page


src/imgs missing from the repo

When freshly cloned and running the program, it complains with: File src/imgs/ is missing!

My bad, I've configured the .gitignore to not include the folder, will push a fix in a few.


Update network for Application Gateway deployment

Updated example network address space to be RFC1918 compliant.  The <IP_ADDRESS>/8 space is publicly addressable.

@techbunny : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#label:"aq-pr-triaged"


ipdb

Hi, how to use ipdb to debug code in this codebase? THX!

maybe you can try the ipdb in a single GPU mode.


Only calculate streaming in conditional logic

I'm also thinking we might be able to streamline the buffering logic in conditional_http_tween with the compression_tween as they both do buffering it seems. If that change is desirable I'll make it in this PR as well.

Hi @SethMichaelLarson, I'm not sure I understand the goal of this change. What is this fixing?

Since this is run per-request we could combine the buffering logic in the compression tween and the identical buffering logic in the compression tween. I switched the if conditions around so the faster one breaks before the "slower" one.


Add aria-labels to buttons

It is best practise to label buttons if they only contain icons.
Therefore I added a little text to each button using aria-label attribute. To enable translations they can be customized using props.
Also see https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-label_attribute for aria-label.

Thanks for the contribution! This is now available in v4.2.0

Wow, that was fast, many thanks! :D


Apply projectHealth recommendations to language-jvm

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle test and merge

The merge queue build has started. Click here to see all failures if any.


Skip switching branches

Idea
I want to skip switching branches to the base branch and back entirely when all reports are supplied initially.
Description
We are working with a fork workflow and all PRs are from forked repositories. That means switching back to the PR branch fails because that branch does not exists on the origin repository.
We generate the base coverage report on the main branch and save it with actions/cache for further usage in PRs. This way we can provide the base coverage report without the need to run the tests twice each PR. It works good, the base report is used and running the tests is skipped. But still the branch is beeing switched to master and back afterwards, which fails.
Switched to a new branch 'master'
branch 'master' set up to track 'origin/master'.
Switching to base branch ended
Begin base coverage collection...
Begin installing dependencies...
Installing dependencies skipped
Installing dependencies ended
Begin running tests...
Running tests skipped
Running tests ended
Begin collecting coverage...
Loading code coverage from file: coverage/base-report.json
Collecting coverage ended
Begin parsing coverage...
Parsing coverage ended
Base coverage collection ended
Begin switching back to original branch...
/usr/bin/git fetch --all --depth=1
Fetching origin
/usr/bin/git checkout -f chore/EPNG-8726-compare-coverage-with-base
error: pathspec 'chore/EPNG-8726-compare-coverage-with-base' did not match any file(s) known to git
Switching back to original branch failed
Error: Error: The process '/usr/bin/git' failed with exit code 1
Error: The process '/usr/bin/git' failed with exit code 1
    at jp._setResult (/home/runner/work/_actions/artiomtr/jest-coverage-report-action/v2/dist/index.js:10:17263)
    at jp.CheckComplete (/home/runner/work/_actions/artiomtr/jest-coverage-report-action/v2/dist/index.js:10:16853)
    at ChildProcess.<anonymous> (/home/runner/work/_actions/artiomtr/jest-coverage-report-action/v2/dist/index.js:10:15[84](https://github.com/ePages-de/ng-merchant-ui/runs/5392613155?check_suite_focus=true#step:10:84)6)
    at ChildProcess.emit (node:events:3[90](https://github.com/ePages-de/ng-merchant-ui/runs/5392613155?check_suite_focus=true#step:10:90):28)
    at maybeClose (node:internal/child_process:1064:16)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:301:5)
Switching back to original branch ended

I found the issue #199 which initially asked for the exact same feature. But in the end the solution only was to switched the branch back again, which causes issues with fork PRs.
Alternatives
Do not fail on git errors.
Or switch back to the PR branch that the checkout action uses. This line is from the checkout step log of our workflow:
/usr/bin/git checkout --progress --force refs/remotes/pull/2475/merge

Additional context

workflow file
      - name: Checkout
        uses: actions/checkout@v3
        # We need full history
        with:
          fetch-depth: 0

      - name: Get coverage cache
        uses: actions/cache@v2
        with:
          key: base-coverage-${{ github.ref }}
          restore-keys: base-coverage
          path: ./coverage/base-report.json

      - name: Setup node
        uses: actions/setup-node@v2
        with:
          node-version: '16.14.0'
          cache: 'yarn'
      - name: Install project dependencies
        run: yarn --frozen-lockfile

      - name: Run linting
        run: yarn lint
      - name: Run tests
        run: yarn test --runInBand --coverage --coverageThreshold '{}' --testLocationInResults --json --outputFile=./coverage/report.json

      - uses: artiomtr/jest-coverage-report-action@v2
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          package-manager: yarn
          coverage-file: ./coverage/report.json
          base-coverage-file: ./coverage/base-report.json
          annotations: all
          skip-step: all

I have encountered the same issue.
I am providing both coverage-file and base-coverage-file, but the actions still tries to switch to the base branch.
I think I have a fix for this, I will try to open a PR soon.


Fixes spaCy export

In lieu of seemingly abandoned PR #264.

@c-w any thoughts about this?

@Hironsan do you have any feedback?


Option to hide hostname?

Hi @legolord208 - you can hide the hostname by removing it as a segment. See https://github.com/banga/powerline-shell#adding-removing-and-re-arranging-segments for details.

:+1:


Fix antialiasing for beginning/end of line in canvas_item_add_polyline

This PR adds AA to the beginning/end (horizontal) border on the line + adds corners to prevent artifacts:

This would fix (partially): https://github.com/godotengine/godot/issues/57882 (I didn't touch Line2D since it uses a different method to draw, maybe later I would fix it too in another PR)

Could border_size be set to 1.0?
2.0 looks a bit blurry to me and 1.0 matches 3.x better.

2.0 looks a bit blurry to me and 1.0 matches 3.x better.

You may want to consider setting it to 0.625 by default, which (empirically) results in good antialiasing while keeping lines sharp.

@maiself, @Calinou Maybe adding an extra parameter would be better? - then the user will control the size of the border of AA.

Could border_size be set to 1.0?

Done

@maiself, @Calinou Maybe adding an extra parameter would be better? - then the user will control the size of the border of AA.

That would be nice to support, but I still think the default should be more conservative to look more crisp :slightly_smiling_face:


Unique on all columns

Java toc currently get one package from Get-Unique
Fixed the problem on checking all columns. Since the packages with same service name are not that many, the call does not take that many time.
Before fix:
core service only returns 'azure-core'
After fix:
core service returns all core packages, e.g. 'azure-core-okhttp', 'azure-core-test' etc

The following pipelines have been queued for testing:java - templatejava - template - testsjs - templatenet - templatenet - template - testspython - templatepython - template - tests You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejava - template - testsjs - templatenet - templatenet - template - testspython - templatepython - template - tests You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejava - template - testsjs - templatenet - templatenet - template - testspython - templatepython - template - tests You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejava - template - testsjs - templatenet - templatenet - template - testspython - templatepython - template - tests You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejava - template - testsjs - templatenet - templatenet - template - testspython - templatepython - template - tests You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejava - template - testsjs - templatenet - templatenet - template - testspython - templatepython - template - tests You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejava - template - testsjs - templatenet - templatenet - template - testspython - templatepython - template - tests You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejava - template - testsjs - templatenet - templatenet - template - testspython - templatepython - template - tests You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejava - template - testsjs - templatenet - templatenet - template - testspython - templatepython - template - tests You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow


Added functions to plot heatmaps. Various fixes

This also fixes issue https://github.com/johned0/gnuplot_c/issues/1

Hi Thomas,
Bugfix: ylable and xlable initisalisation was flipped
Difficult one this. I think the labels look more consistent when at the ends of the axes to which they refer.
Setting xrange and yrange using the existing values xMax and yMax
gpc_plot_xy doesn't use xMax and yMax. It uses dimension (because it is square) and this value is written to plotHandle->scalingMode.
Fixed the formatting character to match datatype unsigned int. %d cau…
Agreed.
Added functions gpc_init_heatmap (alias) and gpc_plot_heatmap
If I've understood the heatmap modifications it is purely to support unsigned int data (rather than char).
I think updating the image examples to support unsigned int might actually be a better solution.
Fixed /dev/nul to /dev/null for platforms other than Windows
This won't work with gcc under Windows I think we need to use my suggestion, in reply to your comment :
#if ((__unix) || (MACH))                        // Linux / OS X
#define GNUPLOT_CMD "gnuplot > /dev/null 2>&1"  // Pipe the text output to null for higher performance
#else
#define GNUPLOT_CMD "gnuplot > /dev/nul 2>&1"   // Pipe the text output to null for higher performance
#endif    #endif
Cheers,
John


support capacitor 6

can you please update the library to support capacitor 6?

👀 We've just linked this issue to our internal tracker and notified the team. Thank you for reporting, we're checking this out!

Hi @yakovyarmo, please use release 8.0.0-beta.3 for now. We plan to have a stable version as soon as possible.
Closing but feel free to reopen if you have other issues!

FYI 8.0.0-beta.4 is available now


Data Binding and Theming - Theming Issue

When incorporating Theming into Unity scene, all aspects of the theme that is being switched to work except the fonts for text items do not change as set in the Style Sheet and Theme Profile. Not sure what I am missing.  Have tried following the samples and everything seems correct.
Your setup (please complete the following information)

Unity Version - 2021.3.4f1
MRTK Version - MRTK3

Target platform (please complete the following information)

HoloLens 2

Figured the issue out.  Had to check that all the font styles were not set to normal


Change wording of SL to remove SRE responsibility for deleting cluster

Change wording of SL so that customer knows they need to delete their cluster and that it's not SRE responsibility.
https://issues.redhat.com/browse/OSD-18891

Seems like prow is failing on https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/builds/setting-up-trusted-ca but that link is not part of this PR

/approve

/lgtm