Why the train loss is higher than the validation and test?

I was running the code in Colab T4GPU Etth2 patchTST supervised.
`Args in experiment:
Namespace(random_seed=2021, is_training=1, model_id='336_96', model='PatchTST', data='ETTh2', root_path='./dataset//all_six_datasets/ETT-small', data_path='ETTh2.csv', features='M', target='OT', freq='h', checkpoints='./checkpoints/', seq_len=336, label_len=48, pred_len=96, fc_dropout=0.3, head_dropout=0.0, patch_len=16, stride=8, padding_patch='end', revin=1, affine=0, subtract_last=0, decomposition=0, kernel_size=25, individual=0, embed_type=0, enc_in=7, dec_in=7, c_out=7, d_model=16, n_heads=4, e_layers=3, d_layers=1, d_ff=128, moving_avg=25, factor=1, distil=True, dropout=0.3, embed='timeF', activation='gelu', output_attention=False, do_predict=False, num_workers=10, itr=1, train_epochs=100, batch_size=128, patience=100, learning_rate=0.0001, des='Exp', loss='mse', lradj='type3', pct_start=0.3, use_amp=False, use_gpu=True, gpu=0, use_multi_gpu=False, devices='0,1,2,3', test_flop=False)
Use GPU: cuda:0

start training : 336_96_PatchTST_ETTh2_ftM_sl336_ll48_pl96_dm16_nh4_el3_dl1_df128_fc1_ebtimeF_dtTrue_Exp_0>>>>>>>>>>>>>>>>>>>>>>>>>>
train 8209
val 2785
test 2785
Epoch: 1 cost time: 2.1643295288085938
Epoch: 1, Steps: 64 | Train Loss: 0.6763266 Vali Loss: 0.3606680 Test Loss: 0.4046726
Validation loss decreased (inf --> 0.360668).  Saving model ...
Updating learning rate to 0.0001
Epoch: 2 cost time: 1.7166812419891357
Epoch: 2, Steps: 64 | Train Loss: 0.5844589 Vali Loss: 0.2609031 Test Loss: 0.3279925
Validation loss decreased (0.360668 --> 0.260903).  Saving model ...
Updating learning rate to 0.0001
Epoch: 3 cost time: 1.7202339172363281
Epoch: 3, Steps: 64 | Train Loss: 0.4991248 Vali Loss: 0.2373687 Test Loss: 0.2988000
Validation loss decreased (0.260903 --> 0.237369).  Saving model ...
Updating learning rate to 0.0001
Epoch: 4 cost time: 1.7069125175476074
Epoch: 4, Steps: 64 | Train Loss: 0.4619388 Vali Loss: 0.2229405 Test Loss: 0.2888060
Validation loss decreased (0.237369 --> 0.222940).  Saving model ...
Updating learning rate to 9e-05
Epoch: 5 cost time: 1.7258367538452148
Epoch: 5, Steps: 64 | Train Loss: 0.4415994 Vali Loss: 0.2171950 Test Loss: 0.2827333
Validation loss decreased (0.222940 --> 0.217195).  Saving model ...
Updating learning rate to 8.1e-05
Epoch: 6 cost time: 1.7511725425720215
Epoch: 6, Steps: 64 | Train Loss: 0.4314346 Vali Loss: 0.2150504 Test Loss: 0.2809727
Validation loss decreased (0.217195 --> 0.215050).  Saving model ...
Updating learning rate to 7.290000000000001e-05
Epoch: 7 cost time: 1.7013769149780273
Epoch: 7, Steps: 64 | Train Loss: 0.4257249 Vali Loss: 0.2145968 Test Loss: 0.2784564
Validation loss decreased (0.215050 --> 0.214597).  Saving model ...
Updating learning rate to 6.561e-05
Epoch: 8 cost time: 1.7248353958129883
Epoch: 8, Steps: 64 | Train Loss: 0.4217108 Vali Loss: 0.2132926 Test Loss: 0.2776138
Validation loss decreased (0.214597 --> 0.213293).  Saving model ...
Updating learning rate to 5.904900000000001e-05
Epoch: 9 cost time: 1.7173840999603271
Epoch: 9, Steps: 64 | Train Loss: 0.4192884 Vali Loss: 0.2128644 Test Loss: 0.2769505
Validation loss decreased (0.213293 --> 0.212864).  Saving model ...
Updating learning rate to 5.3144100000000005e-05
Epoch: 10 cost time: 1.8021619319915771
Epoch: 10, Steps: 64 | Train Loss: 0.4169750 Vali Loss: 0.2115794 Test Loss: 0.2763964
Validation loss decreased (0.212864 --> 0.211579).  Saving model ...
Updating learning rate to 4.782969000000001e-05
Epoch: 11 cost time: 1.7141728401184082
Epoch: 11, Steps: 64 | Train Loss: 0.4154261 Vali Loss: 0.2118243 Test Loss: 0.2759447
EarlyStopping counter: 1 out of 100
Updating learning rate to 4.304672100000001e-05
Epoch: 12 cost time: 1.706538200378418
Epoch: 12, Steps: 64 | Train Loss: 0.4144730 Vali Loss: 0.2105129 Test Loss: 0.2758228
Validation loss decreased (0.211579 --> 0.210513).  Saving model ...
Updating learning rate to 3.874204890000001e-05
Epoch: 13 cost time: 1.717226505279541
Epoch: 13, Steps: 64 | Train Loss: 0.4131817 Vali Loss: 0.2107882 Test Loss: 0.2753261
EarlyStopping counter: 1 out of 100
Updating learning rate to 3.486784401000001e-05
Epoch: 14 cost time: 1.7399539947509766
Epoch: 14, Steps: 64 | Train Loss: 0.4124877 Vali Loss: 0.2098478 Test Loss: 0.2757070
Validation loss decreased (0.210513 --> 0.209848).  Saving model ...
Updating learning rate to 3.138105960900001e-05
Epoch: 15 cost time: 1.800302267074585
Epoch: 15, Steps: 64 | Train Loss: 0.4110149 Vali Loss: 0.2112466 Test Loss: 0.2749723
EarlyStopping counter: 1 out of 100
Updating learning rate to 2.824295364810001e-05
Epoch: 16 cost time: 1.7359976768493652
Epoch: 16, Steps: 64 | Train Loss: 0.4097658 Vali Loss: 0.2106580 Test Loss: 0.2749432
EarlyStopping counter: 2 out of 100
Updating learning rate to 2.541865828329001e-05
Epoch: 17 cost time: 1.7370517253875732
Epoch: 17, Steps: 64 | Train Loss: 0.4094254 Vali Loss: 0.2105749 Test Loss: 0.2748891
EarlyStopping counter: 3 out of 100
Updating learning rate to 2.287679245496101e-05
Epoch: 18 cost time: 1.7441661357879639
Epoch: 18, Steps: 64 | Train Loss: 0.4085028 Vali Loss: 0.2104510 Test Loss: 0.2746597
EarlyStopping counter: 4 out of 100
Updating learning rate to 2.0589113209464907e-05
Epoch: 19 cost time: 1.7556688785552979
Epoch: 19, Steps: 64 | Train Loss: 0.4091201 Vali Loss: 0.2114273 Test Loss: 0.2745993
EarlyStopping counter: 5 out of 100
Updating learning rate to 1.8530201888518416e-05
Epoch: 20 cost time: 1.740110158920288
Epoch: 20, Steps: 64 | Train Loss: 0.4080682 Vali Loss: 0.2092140 Test Loss: 0.2747724
Validation loss decreased (0.209848 --> 0.209214).  Saving model ...
Updating learning rate to 1.6677181699666577e-05
Epoch: 21 cost time: 1.7416722774505615
Epoch: 21, Steps: 64 | Train Loss: 0.4075525 Vali Loss: 0.2114391 Test Loss: 0.2744769
EarlyStopping counter: 1 out of 100
Updating learning rate to 1.5009463529699919e-05
Epoch: 22 cost time: 1.7436606884002686
Epoch: 22, Steps: 64 | Train Loss: 0.4080877 Vali Loss: 0.2100424 Test Loss: 0.2745726
EarlyStopping counter: 2 out of 100
Updating learning rate to 1.3508517176729929e-05
Epoch: 23 cost time: 1.7580888271331787
Epoch: 23, Steps: 64 | Train Loss: 0.4069620 Vali Loss: 0.2099439 Test Loss: 0.2743274
EarlyStopping counter: 3 out of 100
Updating learning rate to 1.2157665459056936e-05
Epoch: 24 cost time: 1.7594590187072754
Epoch: 24, Steps: 64 | Train Loss: 0.4066456 Vali Loss: 0.2096140 Test Loss: 0.2744710
EarlyStopping counter: 4 out of 100
Updating learning rate to 1.0941898913151242e-05
Epoch: 25 cost time: 1.7444617748260498
Epoch: 25, Steps: 64 | Train Loss: 0.4067152 Vali Loss: 0.2105653 Test Loss: 0.2744342
EarlyStopping counter: 5 out of 100
Updating learning rate to 9.847709021836118e-06
Epoch: 26 cost time: 1.7528653144836426
Epoch: 26, Steps: 64 | Train Loss: 0.4071409 Vali Loss: 0.2101815 Test Loss: 0.2743181
EarlyStopping counter: 6 out of 100
Updating learning rate to 8.862938119652508e-06
Epoch: 27 cost time: 1.7296009063720703
Epoch: 27, Steps: 64 | Train Loss: 0.4065424 Vali Loss: 0.2101335 Test Loss: 0.2743031
EarlyStopping counter: 7 out of 100
Updating learning rate to 7.976644307687255e-06
Epoch: 28 cost time: 1.7801082134246826
Epoch: 28, Steps: 64 | Train Loss: 0.4055321 Vali Loss: 0.2105002 Test Loss: 0.2742938
EarlyStopping counter: 8 out of 100
Updating learning rate to 7.178979876918531e-06
Epoch: 29 cost time: 1.752854585647583
Epoch: 29, Steps: 64 | Train Loss: 0.4062736 Vali Loss: 0.2107588 Test Loss: 0.2743371
EarlyStopping counter: 9 out of 100
Updating learning rate to 6.4610818892266776e-06
Epoch: 30 cost time: 1.7650232315063477
Epoch: 30, Steps: 64 | Train Loss: 0.4063427 Vali Loss: 0.2104823 Test Loss: 0.2742883
EarlyStopping counter: 10 out of 100
Updating learning rate to 5.8149737003040096e-06
Epoch: 31 cost time: 1.7491166591644287
Epoch: 31, Steps: 64 | Train Loss: 0.4054611 Vali Loss: 0.2088941 Test Loss: 0.2742677
Validation loss decreased (0.209214 --> 0.208894).  Saving model ...
Updating learning rate to 5.23347633027361e-06
Epoch: 32 cost time: 1.8110325336456299
Epoch: 32, Steps: 64 | Train Loss: 0.4051607 Vali Loss: 0.2109981 Test Loss: 0.2741714
EarlyStopping counter: 1 out of 100
Updating learning rate to 4.710128697246249e-06
Epoch: 33 cost time: 1.814404010772705
Epoch: 33, Steps: 64 | Train Loss: 0.4040284 Vali Loss: 0.2108487 Test Loss: 0.2741989
EarlyStopping counter: 2 out of 100
Updating learning rate to 4.239115827521624e-06
Epoch: 34 cost time: 1.7568163871765137
Epoch: 34, Steps: 64 | Train Loss: 0.4055045 Vali Loss: 0.2101851 Test Loss: 0.2741915
EarlyStopping counter: 3 out of 100
Updating learning rate to 3.815204244769462e-06
Epoch: 35 cost time: 1.7631947994232178
Epoch: 35, Steps: 64 | Train Loss: 0.4058457 Vali Loss: 0.2100938 Test Loss: 0.2742004
EarlyStopping counter: 4 out of 100
Updating learning rate to 3.4336838202925152e-06
Epoch: 36 cost time: 1.7559540271759033
Epoch: 36, Steps: 64 | Train Loss: 0.4042997 Vali Loss: 0.2104393 Test Loss: 0.2741138
EarlyStopping counter: 5 out of 100
Updating learning rate to 3.090315438263264e-06
Epoch: 37 cost time: 1.8273789882659912
Epoch: 37, Steps: 64 | Train Loss: 0.4051889 Vali Loss: 0.2105755 Test Loss: 0.2742157
EarlyStopping counter: 6 out of 100
Updating learning rate to 2.7812838944369375e-06
Epoch: 38 cost time: 1.7628061771392822
Epoch: 38, Steps: 64 | Train Loss: 0.4054591 Vali Loss: 0.2107125 Test Loss: 0.2742336
EarlyStopping counter: 7 out of 100
Updating learning rate to 2.503155504993244e-06
Epoch: 39 cost time: 1.7907121181488037
Epoch: 39, Steps: 64 | Train Loss: 0.4051344 Vali Loss: 0.2105941 Test Loss: 0.2741874
EarlyStopping counter: 8 out of 100
Updating learning rate to 2.2528399544939195e-06
Epoch: 40 cost time: 1.778426170349121
Epoch: 40, Steps: 64 | Train Loss: 0.4048844 Vali Loss: 0.2100071 Test Loss: 0.2742252
EarlyStopping counter: 9 out of 100
Updating learning rate to 2.0275559590445276e-06
Epoch: 41 cost time: 1.8147203922271729
Epoch: 41, Steps: 64 | Train Loss: 0.4053577 Vali Loss: 0.2090154 Test Loss: 0.2742776
EarlyStopping counter: 10 out of 100
Updating learning rate to 1.8248003631400751e-06
Epoch: 42 cost time: 1.8106694221496582
Epoch: 42, Steps: 64 | Train Loss: 0.4058025 Vali Loss: 0.2098368 Test Loss: 0.2742032
EarlyStopping counter: 11 out of 100
Updating learning rate to 1.6423203268260676e-06
Epoch: 43 cost time: 1.7889034748077393
Epoch: 43, Steps: 64 | Train Loss: 0.4042823 Vali Loss: 0.2099250 Test Loss: 0.2741432
EarlyStopping counter: 12 out of 100
Updating learning rate to 1.4780882941434609e-06
Epoch: 44 cost time: 1.7906208038330078
Epoch: 44, Steps: 64 | Train Loss: 0.4041702 Vali Loss: 0.2096843 Test Loss: 0.2741599
EarlyStopping counter: 13 out of 100
Updating learning rate to 1.3302794647291146e-06
Epoch: 45 cost time: 1.7851519584655762
Epoch: 45, Steps: 64 | Train Loss: 0.4053837 Vali Loss: 0.2096516 Test Loss: 0.2742423
EarlyStopping counter: 14 out of 100
Updating learning rate to 1.1972515182562034e-06
Epoch: 46 cost time: 1.8485832214355469
Epoch: 46, Steps: 64 | Train Loss: 0.4050943 Vali Loss: 0.2101437 Test Loss: 0.2741430
EarlyStopping counter: 15 out of 100
Updating learning rate to 1.077526366430583e-06
Epoch: 47 cost time: 1.777778148651123
Epoch: 47, Steps: 64 | Train Loss: 0.4059505 Vali Loss: 0.2098159 Test Loss: 0.2741998
EarlyStopping counter: 16 out of 100
Updating learning rate to 9.697737297875248e-07
Epoch: 48 cost time: 1.8135738372802734
Epoch: 48, Steps: 64 | Train Loss: 0.4047638 Vali Loss: 0.2100287 Test Loss: 0.2741700
EarlyStopping counter: 17 out of 100
Updating learning rate to 8.727963568087723e-07
Epoch: 49 cost time: 1.8284835815429688
Epoch: 49, Steps: 64 | Train Loss: 0.4055362 Vali Loss: 0.2096763 Test Loss: 0.2741248
EarlyStopping counter: 18 out of 100
Updating learning rate to 7.855167211278951e-07
Epoch: 50 cost time: 1.798884391784668
Epoch: 50, Steps: 64 | Train Loss: 0.4044474 Vali Loss: 0.2092623 Test Loss: 0.2741421
EarlyStopping counter: 19 out of 100
Updating learning rate to 7.069650490151056e-07
Epoch: 51 cost time: 1.8458547592163086
Epoch: 51, Steps: 64 | Train Loss: 0.4046243 Vali Loss: 0.2099508 Test Loss: 0.2741397
EarlyStopping counter: 20 out of 100
Updating learning rate to 6.36268544113595e-07
Epoch: 52 cost time: 1.8398337364196777
Epoch: 52, Steps: 64 | Train Loss: 0.4045866 Vali Loss: 0.2097042 Test Loss: 0.2741141
EarlyStopping counter: 21 out of 100
Updating learning rate to 5.726416897022355e-07
Epoch: 53 cost time: 1.7948007583618164
Epoch: 53, Steps: 64 | Train Loss: 0.4026537 Vali Loss: 0.2108110 Test Loss: 0.2740823
EarlyStopping counter: 22 out of 100
Updating learning rate to 5.15377520732012e-07
Epoch: 54 cost time: 1.796067237854004
Epoch: 54, Steps: 64 | Train Loss: 0.4041865 Vali Loss: 0.2096090 Test Loss: 0.2741497
EarlyStopping counter: 23 out of 100
Updating learning rate to 4.6383976865881085e-07
Epoch: 55 cost time: 1.8623394966125488
Epoch: 55, Steps: 64 | Train Loss: 0.4055809 Vali Loss: 0.2102339 Test Loss: 0.2740812
EarlyStopping counter: 24 out of 100
Updating learning rate to 4.174557917929298e-07
Epoch: 56 cost time: 1.819002628326416
Epoch: 56, Steps: 64 | Train Loss: 0.4046756 Vali Loss: 0.2101153 Test Loss: 0.2742102
EarlyStopping counter: 25 out of 100
Updating learning rate to 3.7571021261363677e-07
Epoch: 57 cost time: 1.8020164966583252
Epoch: 57, Steps: 64 | Train Loss: 0.4042921 Vali Loss: 0.2098823 Test Loss: 0.2742269
EarlyStopping counter: 26 out of 100
Updating learning rate to 3.381391913522731e-07
Epoch: 58 cost time: 1.781646728515625
Epoch: 58, Steps: 64 | Train Loss: 0.4023844 Vali Loss: 0.2097825 Test Loss: 0.2741038
EarlyStopping counter: 27 out of 100
Updating learning rate to 3.043252722170458e-07
Epoch: 59 cost time: 1.801849365234375
Epoch: 59, Steps: 64 | Train Loss: 0.4056277 Vali Loss: 0.2095982 Test Loss: 0.2742191
EarlyStopping counter: 28 out of 100
Updating learning rate to 2.7389274499534124e-07
Epoch: 60 cost time: 1.8106637001037598
Epoch: 60, Steps: 64 | Train Loss: 0.4036580 Vali Loss: 0.2098972 Test Loss: 0.2741767
EarlyStopping counter: 29 out of 100
Updating learning rate to 2.465034704958071e-07
Epoch: 61 cost time: 1.7544925212860107
Epoch: 61, Steps: 64 | Train Loss: 0.4042776 Vali Loss: 0.2092048 Test Loss: 0.2741373
EarlyStopping counter: 30 out of 100
Updating learning rate to 2.218531234462264e-07
Epoch: 62 cost time: 1.799748182296753
Epoch: 62, Steps: 64 | Train Loss: 0.4044871 Vali Loss: 0.2099020 Test Loss: 0.2741574
EarlyStopping counter: 31 out of 100
Updating learning rate to 1.9966781110160376e-07
Epoch: 63 cost time: 1.8225650787353516
Epoch: 63, Steps: 64 | Train Loss: 0.4040244 Vali Loss: 0.2100120 Test Loss: 0.2739767
EarlyStopping counter: 32 out of 100
Updating learning rate to 1.797010299914434e-07
Epoch: 64 cost time: 1.8303875923156738
Epoch: 64, Steps: 64 | Train Loss: 0.4052188 Vali Loss: 0.2099989 Test Loss: 0.2741511
EarlyStopping counter: 33 out of 100
Updating learning rate to 1.6173092699229907e-07
Epoch: 65 cost time: 1.79451322555542
Epoch: 65, Steps: 64 | Train Loss: 0.4053198 Vali Loss: 0.2093047 Test Loss: 0.2741008
EarlyStopping counter: 34 out of 100
Updating learning rate to 1.4555783429306916e-07
Epoch: 66 cost time: 1.7962408065795898
Epoch: 66, Steps: 64 | Train Loss: 0.4035531 Vali Loss: 0.2104188 Test Loss: 0.2741628
EarlyStopping counter: 35 out of 100
Updating learning rate to 1.3100205086376224e-07
Epoch: 67 cost time: 1.8021390438079834
Epoch: 67, Steps: 64 | Train Loss: 0.4055579 Vali Loss: 0.2104181 Test Loss: 0.2741275
EarlyStopping counter: 36 out of 100
Updating learning rate to 1.1790184577738603e-07
Epoch: 68 cost time: 1.810896396636963
Epoch: 68, Steps: 64 | Train Loss: 0.4058300 Vali Loss: 0.2097863 Test Loss: 0.2741243
EarlyStopping counter: 37 out of 100
Updating learning rate to 1.0611166119964742e-07
Epoch: 69 cost time: 1.810041904449463
Epoch: 69, Steps: 64 | Train Loss: 0.4048844 Vali Loss: 0.2094992 Test Loss: 0.2741615
EarlyStopping counter: 38 out of 100
Updating learning rate to 9.550049507968268e-08
Epoch: 70 cost time: 1.7844066619873047
Epoch: 70, Steps: 64 | Train Loss: 0.4039441 Vali Loss: 0.2104695 Test Loss: 0.2741447
EarlyStopping counter: 39 out of 100
Updating learning rate to 8.595044557171442e-08
Epoch: 71 cost time: 1.7985899448394775
Epoch: 71, Steps: 64 | Train Loss: 0.4049230 Vali Loss: 0.2101472 Test Loss: 0.2741033
EarlyStopping counter: 40 out of 100
Updating learning rate to 7.735540101454298e-08
Epoch: 72 cost time: 1.8101081848144531
Epoch: 72, Steps: 64 | Train Loss: 0.4044941 Vali Loss: 0.2099488 Test Loss: 0.2740869
EarlyStopping counter: 41 out of 100
Updating learning rate to 6.961986091308869e-08
Epoch: 73 cost time: 1.8383808135986328
Epoch: 73, Steps: 64 | Train Loss: 0.4044523 Vali Loss: 0.2102703 Test Loss: 0.2741061
EarlyStopping counter: 42 out of 100
Updating learning rate to 6.265787482177981e-08
Epoch: 74 cost time: 1.770869493484497
Epoch: 74, Steps: 64 | Train Loss: 0.4057866 Vali Loss: 0.2096028 Test Loss: 0.2741747
EarlyStopping counter: 43 out of 100
Updating learning rate to 5.639208733960184e-08
Epoch: 75 cost time: 1.797130823135376
Epoch: 75, Steps: 64 | Train Loss: 0.4045157 Vali Loss: 0.2106047 Test Loss: 0.2741838
EarlyStopping counter: 44 out of 100
Updating learning rate to 5.075287860564165e-08
Epoch: 76 cost time: 1.8030922412872314
Epoch: 76, Steps: 64 | Train Loss: 0.4034024 Vali Loss: 0.2100367 Test Loss: 0.2741746
EarlyStopping counter: 45 out of 100
Updating learning rate to 4.567759074507749e-08
Epoch: 77 cost time: 1.7932078838348389
Epoch: 77, Steps: 64 | Train Loss: 0.4046166 Vali Loss: 0.2097695 Test Loss: 0.2740767
EarlyStopping counter: 46 out of 100
Updating learning rate to 4.1109831670569744e-08
Epoch: 78 cost time: 1.8020799160003662
Epoch: 78, Steps: 64 | Train Loss: 0.4030784 Vali Loss: 0.2091450 Test Loss: 0.2741565
EarlyStopping counter: 47 out of 100
Updating learning rate to 3.6998848503512764e-08
Epoch: 79 cost time: 1.7950432300567627
Epoch: 79, Steps: 64 | Train Loss: 0.4049116 Vali Loss: 0.2105238 Test Loss: 0.2741542
EarlyStopping counter: 48 out of 100
Updating learning rate to 3.3298963653161496e-08
Epoch: 80 cost time: 1.7550172805786133
Epoch: 80, Steps: 64 | Train Loss: 0.4059545 Vali Loss: 0.2089495 Test Loss: 0.2741537
EarlyStopping counter: 49 out of 100
Updating learning rate to 2.996906728784534e-08
Epoch: 81 cost time: 1.7906570434570312
Epoch: 81, Steps: 64 | Train Loss: 0.4031522 Vali Loss: 0.2097577 Test Loss: 0.2741734
EarlyStopping counter: 50 out of 100
Updating learning rate to 2.697216055906081e-08
Epoch: 82 cost time: 2.3685061931610107
Epoch: 82, Steps: 64 | Train Loss: 0.4041427 Vali Loss: 0.2094271 Test Loss: 0.2741428
EarlyStopping counter: 51 out of 100
Updating learning rate to 2.427494450315473e-08
Epoch: 83 cost time: 1.779212474822998
Epoch: 83, Steps: 64 | Train Loss: 0.4040385 Vali Loss: 0.2094695 Test Loss: 0.2741523
EarlyStopping counter: 52 out of 100
Updating learning rate to 2.1847450052839257e-08
Epoch: 84 cost time: 1.778573751449585
Epoch: 84, Steps: 64 | Train Loss: 0.4038752 Vali Loss: 0.2098419 Test Loss: 0.2741503
EarlyStopping counter: 53 out of 100
Updating learning rate to 1.9662705047555332e-08
Epoch: 85 cost time: 1.7763221263885498
Epoch: 85, Steps: 64 | Train Loss: 0.4048391 Vali Loss: 0.2088083 Test Loss: 0.2741368
Validation loss decreased (0.208894 --> 0.208808).  Saving model ...
Updating learning rate to 1.7696434542799797e-08
Epoch: 86 cost time: 1.82301926612854
Epoch: 86, Steps: 64 | Train Loss: 0.4055296 Vali Loss: 0.2092915 Test Loss: 0.2740907
EarlyStopping counter: 1 out of 100
Updating learning rate to 1.5926791088519817e-08
Epoch: 87 cost time: 1.782050371170044
Epoch: 87, Steps: 64 | Train Loss: 0.4054545 Vali Loss: 0.2093168 Test Loss: 0.2741685
EarlyStopping counter: 2 out of 100
Updating learning rate to 1.4334111979667836e-08
Epoch: 88 cost time: 1.797612190246582
Epoch: 88, Steps: 64 | Train Loss: 0.4031411 Vali Loss: 0.2100785 Test Loss: 0.2740988
EarlyStopping counter: 3 out of 100
Updating learning rate to 1.2900700781701054e-08
Epoch: 89 cost time: 1.8229186534881592
Epoch: 89, Steps: 64 | Train Loss: 0.4051060 Vali Loss: 0.2101304 Test Loss: 0.2741939
EarlyStopping counter: 4 out of 100
Updating learning rate to 1.161063070353095e-08
Epoch: 90 cost time: 1.8107361793518066
Epoch: 90, Steps: 64 | Train Loss: 0.4056356 Vali Loss: 0.2109791 Test Loss: 0.2741085
EarlyStopping counter: 5 out of 100
Updating learning rate to 1.0449567633177854e-08
Epoch: 91 cost time: 1.8436458110809326
Epoch: 91, Steps: 64 | Train Loss: 0.4044930 Vali Loss: 0.2085991 Test Loss: 0.2741357
Validation loss decreased (0.208808 --> 0.208599).  Saving model ...
Updating learning rate to 9.404610869860069e-09
Epoch: 92 cost time: 1.8070034980773926
Epoch: 92, Steps: 64 | Train Loss: 0.4049517 Vali Loss: 0.2098995 Test Loss: 0.2741151
EarlyStopping counter: 1 out of 100
Updating learning rate to 8.464149782874063e-09
Epoch: 93 cost time: 1.791562795639038
Epoch: 93, Steps: 64 | Train Loss: 0.4044298 Vali Loss: 0.2099953 Test Loss: 0.2741124
EarlyStopping counter: 2 out of 100
Updating learning rate to 7.617734804586658e-09
Epoch: 94 cost time: 1.8094542026519775
Epoch: 94, Steps: 64 | Train Loss: 0.4042742 Vali Loss: 0.2098850 Test Loss: 0.2740951
EarlyStopping counter: 3 out of 100
Updating learning rate to 6.855961324127991e-09
Epoch: 95 cost time: 1.828190565109253
Epoch: 95, Steps: 64 | Train Loss: 0.4050080 Vali Loss: 0.2096854 Test Loss: 0.2741583
EarlyStopping counter: 4 out of 100
Updating learning rate to 6.170365191715193e-09
Epoch: 96 cost time: 1.8119406700134277
Epoch: 96, Steps: 64 | Train Loss: 0.4039116 Vali Loss: 0.2106151 Test Loss: 0.2741201
EarlyStopping counter: 5 out of 100
Updating learning rate to 5.5533286725436726e-09
Epoch: 97 cost time: 1.808847427368164
Epoch: 97, Steps: 64 | Train Loss: 0.4049788 Vali Loss: 0.2096705 Test Loss: 0.2741672
EarlyStopping counter: 6 out of 100
Updating learning rate to 4.997995805289306e-09
Epoch: 98 cost time: 1.7819063663482666
Epoch: 98, Steps: 64 | Train Loss: 0.4048662 Vali Loss: 0.2096142 Test Loss: 0.2741997
EarlyStopping counter: 7 out of 100
Updating learning rate to 4.498196224760375e-09
Epoch: 99 cost time: 1.8054022789001465
Epoch: 99, Steps: 64 | Train Loss: 0.4050980 Vali Loss: 0.2100110 Test Loss: 0.2741385
EarlyStopping counter: 8 out of 100
Updating learning rate to 4.048376602284338e-09
Epoch: 100 cost time: 1.8459892272949219
Epoch: 100, Steps: 64 | Train Loss: 0.4042387 Vali Loss: 0.2093764 Test Loss: 0.2740815
EarlyStopping counter: 9 out of 100
Updating learning rate to 3.643538942055904e-09
testing : 336_96_PatchTST_ETTh2_ftM_sl336_ll48_pl96_dm16_nh4_el3_dl1_df128_fc1_ebtimeF_dtTrue_Exp_0<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
test 2785
mse:0.2741357684135437, mae:0.3360080420970917, rse:0.41826650500297546
`

I think the reason is out-of-distribution problem, isn't it?

i encountered the same problem in various models of diff papers. It confuses me too.


update branches to sync

Add 1.9/0.9 release series branches to sync.
Remove old, unmaintained branches from all of them.

/hold
Until CAPM3 1.9 exists too.

/cc @kashifest

/lgtm

/unhold
Branches exist now


SpectralCube.reproject does not properly update headers of resulting image

When I reproject a cube, it does not appear to update the header with the new WCS. I've put a minimal working example before. The headers for regridCube and otherCube are identical. My assumption was that the regridded CRPIX* etc in the  header would match that of the base cube. See below for an example.
# Now let's test my fix for the reprojection in spectral cube
from spectral_cube import SpectralCube

baseCubeFits = 'NGC2903_HCN_rebase3_smooth1.3_hanning1.new_smooth.fits'
baseCube =SpectralCube.read(baseCubeFits)

otherDataFits='NGC2903_heracles_gauss15_fixedheader.fits'
otherCube = SpectralCube.read(otherDataFits)

regridCube = otherCube.spectral_interpolate(baseCube.spectral_axis)
regridCube.reproject(baseCube.header)

regridCube.write('test_regridcube.fits',overwrite=True)

baseCube.header
# NAXIS   =                    3
# NAXIS1  =                   85
# NAXIS2  =                   86
# NAXIS3  =                  132
# CRPIX1  =                 71.5 / Pixel coordinate of reference point
# CRPIX2  =                 32.5 / Pixel coordinate of reference point
# CRPIX3  =               -28.75 / Pixel coordinate of reference point
# CDELT1  = -0.00057096828855099 / [deg] Coordinate increment at reference point
# CDELT2  =  0.00057096828855099 / [deg] Coordinate increment at reference point
# CDELT3  =    9.909510480999799 / [m/s] Coordinate increment at reference point
# CUNIT1  = 'deg'                / Units of coordinate increment and value
# CUNIT2  = 'deg'                / Units of coordinate increment and value
# CUNIT3  = 'km s-1  '           / Units of coordinate increment and value
# CTYPE1  = 'RA---TAN'           / Right ascension, gnomonic projection
# CTYPE2  = 'DEC--TAN'           / Declination, gnomonic projection
# CTYPE3  = 'VRAD'               / Radio velocity (linear)
# CRVAL1  =<PHONE_NUMBER>674 / [deg] Coordinate value at reference point
# CRVAL2  =      21.495097040103 / [deg] Coordinate value at reference point
# CRVAL3  =     -389.27897335034 / [m/s] Coordinate value at reference point

otherCube.header
# NAXIS   =                    3
# NAXIS1  =                  277
# NAXIS2  =                  389
# NAXIS3  =                   58
# CRPIX1  =                138.0 / Pixel coordinate of reference point
# CRPIX2  =                194.0 / Pixel coordinate of reference point
# CRPIX3  =                  1.0 / Pixel coordinate of reference point
# CDELT1  =         -0.000555556 / [deg] Coordinate increment at reference point
# CDELT2  =          0.000555556 / [deg] Coordinate increment at reference point
# CDELT3  =       -20806.4589844 / [m/s] C
# CUNIT1  = 'deg'                / Units of coordinate increment and value
# CUNIT2  = 'deg'                / Units of coordinate increment and value
# CUNIT3  = 'm/s'                / Units of coordinate increment and value
# CTYPE1  = 'RA---TAN'           / Right ascension, gnomonic projection
# CTYPE2  = 'DEC--TAN'           / Declination, gnomonic projection
# CTYPE3  = 'VRAD'               / Radio velocity (linear)
# CRVAL1  =<PHONE_NUMBER>3 / [deg] Coordinate value at reference point
# CRVAL2  =        21.5026699071 / [deg] Coordinate value at reference point
# CRVAL3  =        1145354.01586 / [m/s] Coordinate value at reference point

regridCube.header
# NAXIS   =                    3
# NAXIS1  =                  277
# NAXIS2  =                  389
# NAXIS3  =                  132
# CRPIX1  =                138.0 / Pixel coordinate of reference point
# CRPIX2  =                194.0 / Pixel coordinate of reference point
# CRPIX3  =                  1.0 / Pixel coordinate of reference point
# CDELT1  =         -0.000555556 / [deg] Coordinate increment at reference point
# CDELT2  =          0.000555556 / [deg] Coordinate increment at reference point
# CDELT3  =      9909.5104809998 / [m/s] Coordinate increment at reference point
# CUNIT1  = 'deg'                / Units of coordinate increment and value
# CUNIT2  = 'deg'                / Units of coordinate increment and value
# CUNIT3  = 'm/s'                / Units of coordinate increment and value
# CTYPE1  = 'RA---TAN'           / Right ascension, gnomonic projection
# CTYPE2  = 'DEC--TAN'           / Declination, gnomonic projection
# CTYPE3  = 'VRAD'               / Radio velocity (linear)
# CRVAL1  =<PHONE_NUMBER>3 / [deg] Coordinate value at reference point
# CRVAL2  =        21.5026699071 / [deg] Coordinate value at reference point
# CRVAL3  =     -94471.036540596 / [m/s] Coordinate value at reference point

I've played with the code in SpectralCube.reproject and I believe the issue is with https://github.com/radio-astro-tools/spectral-cube/blob/b93d1b4c9a6fb25bccda7b6ec45d7d2c6110b8f1/spectral_cube/spectral_cube.py#L2583
The header is taken from self and is the original header for the reprojected cube, not the reprojected header. I tried passing a simple header, but got errors later on about multiple header keywords in BaseSpectralCube. I don't know enough about how classes work to fix that issue.
Creating a new SpectralCube instance does work with the oldheader and meta does work. See below for example.
data = regridCube.unitless_filled_data[:]
oldheader = regridCube.header
newheader = baseCube.header ## still m/s
newwcs = wcs.WCS(newheader)
shape_out = tuple([newheader['NAXIS{0}'.format(i + 1)] for i in range(newheader['NAXIS'])][::-1])
outarray = None

newcube, newcube_valid = reproject_interp((data,
                                           oldheader),
                                          newwcs,
                                          output_array=outarray,
                                          shape_out=shape_out,
                                          order='bilinear')
newcube.shape
# (132, 86, 85)

#that's right.

test = SpectralCube(newcube,newwcs,header=oldheader,meta=regridCube.meta)
test.write('test_spectralcubemethod.fits')
test.header
# WCSAXES =                    3 / Number of coordinate axes
# CRPIX1  =                 71.5 / Pixel coordinate of reference point
# NAXIS   =                    3
# NAXIS1  =                   85
# NAXIS2  =                   86
# NAXIS3  =                  132
# CRPIX2  =                 32.5 / Pixel coordinate of reference point
# CRPIX3  =               -28.75 / Pixel coordinate of reference point
# CDELT1  = -0.00057096828855099 / [deg] Coordinate increment at reference point
# CDELT2  =  0.00057096828855099 / [deg] Coordinate increment at reference point
# CDELT3  =      9909.5104809998 / [m/s] Coordinate increment at reference point
# CUNIT1  = 'deg'                / Units of coordinate increment and value
# CUNIT2  = 'deg'                / Units of coordinate increment and value
# CUNIT3  = 'm/s'                / Units of coordinate increment and value
# CTYPE1  = 'RA---TAN'           / Right ascension, gnomonic projection
# CTYPE2  = 'DEC--TAN'           / Declination, gnomonic projection
# CTYPE3  = 'VRAD'               / Radio velocity (linear)
# CRVAL1  =<PHONE_NUMBER>674 / [deg] Coordinate value at reference point
# CRVAL2  =      21.495097040103 / [deg] Coordinate value at reference point
# CRVAL3  =     -389278.97335034 / [m/s] Coordinate value at reference point

# Matches baseCube header above.

@aakepley -- I added checks for the output WCS in the reprojected cube (#589). However, I couldn't reproduce this issue on my machine.
Just checking for a simple fix: Is there a typo in this line?
regridCube.reproject(baseCube.header)

vs.
regridCube = regridCube.reproject(baseCube.header)

The latter should return the reprojected cube but the former regridCube will only be the spectrally-interpolated from the previous line.

Doh! Tried the above and that fixes it. Is the SpectralCube convention to always return a new cube rather than modify in place? If so, I will stick a big post-it on my computer to remind me.

Oh good! Yes, to avoid making additional copies of the data, functions will return a new cube.
Flagging this as something that needs to be highlighted in the docs!


coding guidelines: comply with MISRA C:2012 Rule 13.3

In particular:

avoided ++/-- on volatile

avoided to have more than one ++/-- in for third clause

moved ++/-- before or after the value use

avoided pointless ++/--

replaced consecutive ++ with a single +=

Signed-off-by: Abramo Bagnara<EMAIL_ADDRESS>

I have no problem with the post-indexing removal. I can see the point
of such change. I think you should split it out into a PR of its own
so that the least controvertial changes could go in faster.
BTW there is that hunk:
-               while (*--buf == '0') {
-                       ;
+               --buf;
+               while (*buf == '0') {
+                       --buf;
                }

Can't you turn that into the following instead:
                do {
                    --buf;
                } while (*buf == '0');

That's clearer and shorter too.
That being said ...
I do strongly disagree with qualifying small literals. Referring to a
conversation we had a while ago:
void foo(my_type_t x) { if (x < 5U) { bar(x); } }

Here things will go wrong the moment my_type_t is signed and x is
negative. Whereas:
void foo(my_type_t x) { if (x < 5) { bar(x); } }

Here you'll get the proper behavior all the time whether my_type_t
is signed or not. The principle of least surprise is respected.
So I stand by my statement that qualified small literals is evil and
MISRA is wrong on that one. This overzealous qualifying of small literals
must stop. It should not be encouraged unless it is warranted by an
explicit purpose like bitmask operations where shifting the sign bit
would create issues. Otherwise it is just useless and ugly.
This goes for arithmetic operations too.

So... to recap, I'm fine with the top commit. Not so much with the
other ones.

Can't you turn that into the following instead:
                do {
                    --buf;
                } while (*buf == '0');

That's clearer and shorter too.

I agree, changed now.

This touches a lot of subsystems in a single patch, often in code that looks edge-casey and poorly exercised in CI (in particular I know for sure there's no unit test anywhere of the EFI console output).
If one of these turns out to regress something that we only notice a few months in the future, this is going to be a very hard patch to revert to test, given how many lines it is. Suggest splitting the changes out into separate patches by subsystem/driver.

I don't understand what you write: the commit touches only 14 files and none of them is under subsys or drivers folders.

I think the pr should be split in more commits with more information about the changes. Also some changes make the code more bureaucratic to read, but in general the changes look good to me.


ground items categories

During my grinding of certain monsters i came across the issue where i wanted to separate the drops i got by category of items instead of value a.e. herbs, weapons/gear (maybe metal types) ingredients, etc...
I would love to see an option to choose either "color drops based on value (ge/ ha)" or "color drops based on categories "
we currently have the ability to "ignore" and "highlight" items, if pre existing categories are an issue i would love an option to group the drops myself
the drop highligh beams could also be enabled/disabled per group instead of value+

Duplicate of #12274


fix(files): Handle unparsible filenames

PR related to this trello task --> https://trello.com/c/HOENdPtH

:tada: This PR is included in version 1.24.10 :tada:
Your semantic-release bot :package::rocket:


not working after configuration

I have new Mac with apple chip
Model Name:	MacBook Pro
Model Identifier:	MacBookPro18,2
Chip:	Apple M1 Max
Configure exactly as was in instruction
source ~/tools/zsh-git-prompt/zshrc.sh PROMPT='%B%m%~%b$(git_super_status) %# '
But I do not see any effect from git prompt

This repo isn't being maintained. Use https://github.com/zsh-git-prompt/zsh-git-prompt


Improve docs for health checker and system stats configs

I hope this change will clarify how to setup the health checkers, as I was confused about this - there was no documentation or example to follow here.
This also adds a link to the system stats config in the problem daemon types table, for convenience.

/ok-to-test
/lgtm

/remove approve


Feature request: Qt 5.12 support

What would it take to add Qt 5.12 support?

Added some minor fixes to build against 5.12 on linux,
did not test rest, also did not test how HW acceleration works with it.

Great! I will check.

Hmmm...
ai@ELDERORB:~/Projects/QtAVPlayer$ qmake
Info: creating cache file /home/ai/Projects/QtAVPlayer/.qmake.cache

Running configuration tests...
Done running configuration tests.

Configure summary:

Qt AVPlayer:
  FFmpeg ................................. yes
  va_x11 ................................. no
  va_drm ................................. no

Qt is now configured for building. Just run 'make'.
Once everything is built, you must run 'make install'.
Qt will be installed into '/home/ai/Qt/5.12.10/gcc_64'.

Prior to reconfiguration, make sure you remove any leftovers from
the previous build.

ai@ELDERORB:~/Projects/QtAVPlayer$ make
cd src/ && ( test -e Makefile || /home/ai/Qt/5.12.10/gcc_64/bin/qmake -o Makefile /home/ai/Projects/QtAVPlayer/src/src.pro ) && make -f Makefile
make[1]: Entering directory '/home/ai/Projects/QtAVPlayer/src'
cd avplayer/ && ( test -e Makefile || /home/ai/Qt/5.12.10/gcc_64/bin/qmake -o Makefile /home/ai/Projects/QtAVPlayer/src/avplayer/avplayer.pro ) && make -f Makefile
Project MESSAGE: perl -w /home/ai/Qt/5.12.10/gcc_64/bin/syncqt.pl -module QtAVPlayer -version 6.0.0 -outdir /home/ai/Projects/QtAVPlayer -builddir /home/ai/Projects/QtAVPlayer /home/ai/Projects/QtAVPlayer
<srcbase> = /home/ai/Projects/QtAVPlayer
<bldbase> = /home/ai/Projects/QtAVPlayer
<outbase> = /home/ai/Projects/QtAVPlayer
QtAVPlayer: created fwd-include header(s) for <srcbase>/src/avplayer/ { qavaudiocodec_p.h (1), qavaudioframe_p.h (1), qavaudiooutput.h (2), qavcodec_p.h (1), qavcodec_p_p.h (1), qavdemuxer_p.h (1), qavframe_p.h (1), qavframe_p_p.h (1), qavhwdevice_d3d11_p.h (1), qavhwdevice_mediacodec_p.h (1), qavhwdevice_p.h (1), qavhwdevice_vaapi_drm_egl_p.h (1), qavhwdevice_vaapi_x11_glx_p.h (1), qavhwdevice_videotoolbox_p.h (1), qavpacket_p.h (1), qavpacketqueue_p.h (1), qavplanarvideobuffer_cpu_p.h (1), qavplanarvideobuffer_gpu_p.h (1), qavplayer.h (2), qavvideocodec_p.h (1), qavvideoframe_p.h (1), qtavplayerglobal.h (1), qtavplayerglobal_p.h (1) }
QtAVPlayer: created version header
QtAVPlayer: created master header
QtAVPlayer: created headers.pri file
make[2]: Entering directory '/home/ai/Projects/QtAVPlayer/src/avplayer'
perl /home/ai/Qt/5.12.10/gcc_64/mkspecs/features/data/unix/findclasslist.pl < QtAVPlayer.version.in > QtAVPlayer.version
g++ -pipe -O2 -g -std=c++1y -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall -W -Wvla -Wdate-time -D_REENTRANT -fPIC -DQT_NO_FOREACH -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_AVPLAYER_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB -DQT_GUI_LIB -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_GUI_LIB -DQT_CORE_LIB -D_REENTRANT -I. -I../../include -I../../include/QtAVPlayer -I../../include/QtAVPlayer/6.0.0 -I../../include/QtAVPlayer/6.0.0/QtAVPlayer -I/home/ai/Qt/5.12.10/gcc_64/include/QtMultimedia/5.12.10 -I/home/ai/Qt/5.12.10/gcc_64/include/QtMultimedia/5.12.10/QtMultimedia -I/home/ai/Qt/5.12.10/gcc_64/include -I/home/ai/Qt/5.12.10/gcc_64/include/QtMultimedia -I/home/ai/Qt/5.12.10/gcc_64/include/QtNetwork -I/home/ai/Qt/5.12.10/gcc_64/include/QtGui/5.12.10 -I/home/ai/Qt/5.12.10/gcc_64/include/QtGui/5.12.10/QtGui -I/home/ai/Qt/5.12.10/gcc_64/include/QtGui -I/home/ai/Qt/5.12.10/gcc_64/include/QtConcurrent -I/home/ai/Qt/5.12.10/gcc_64/include/QtCore/5.12.10 -I/home/ai/Qt/5.12.10/gcc_64/include/QtCore/5.12.10/QtCore -I/home/ai/Qt/5.12.10/gcc_64/include/QtCore -I.moc -isystem /usr/include/libdrm -isystem /usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/home/qt/openssl-1.1.1g/include -I/home/ai/Qt/5.12.10/gcc_64/mkspecs/linux-g++ -x c++-header -c ../../include/QtAVPlayer/QtAVPlayerDepends -o .pch/Qt5AVPlayer.gch/c++
g++ -c -include .pch/Qt5AVPlayer -pipe -O2 -g -std=c++1y -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall -W -Wvla -Wdate-time -D_REENTRANT -fPIC -DQT_NO_FOREACH -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_AVPLAYER_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB -DQT_GUI_LIB -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_GUI_LIB -DQT_CORE_LIB -D_REENTRANT -I. -I../../include -I../../include/QtAVPlayer -I../../include/QtAVPlayer/6.0.0 -I../../include/QtAVPlayer/6.0.0/QtAVPlayer -I/home/ai/Qt/5.12.10/gcc_64/include/QtMultimedia/5.12.10 -I/home/ai/Qt/5.12.10/gcc_64/include/QtMultimedia/5.12.10/QtMultimedia -I/home/ai/Qt/5.12.10/gcc_64/include -I/home/ai/Qt/5.12.10/gcc_64/include/QtMultimedia -I/home/ai/Qt/5.12.10/gcc_64/include/QtNetwork -I/home/ai/Qt/5.12.10/gcc_64/include/QtGui/5.12.10 -I/home/ai/Qt/5.12.10/gcc_64/include/QtGui/5.12.10/QtGui -I/home/ai/Qt/5.12.10/gcc_64/include/QtGui -I/home/ai/Qt/5.12.10/gcc_64/include/QtConcurrent -I/home/ai/Qt/5.12.10/gcc_64/include/QtCore/5.12.10 -I/home/ai/Qt/5.12.10/gcc_64/include/QtCore/5.12.10/QtCore -I/home/ai/Qt/5.12.10/gcc_64/include/QtCore -I.moc -isystem /usr/include/libdrm -isystem /usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/home/qt/openssl-1.1.1g/include -I/home/ai/Qt/5.12.10/gcc_64/mkspecs/linux-g++ -o .obj/qavaudiooutput.o qavaudiooutput.cpp
qavaudiooutput.cpp:13:10: fatal error: libavutil/time.h: No such file or directory
 #include "libavutil/time.h"
          ^~~~~~~~~~~~~~~~~~
compilation terminated.
Makefile:1936: recipe for target '.obj/qavaudiooutput.o' failed
make[2]: *** [.obj/qavaudiooutput.o] Error 1
make[2]: Leaving directory '/home/ai/Projects/QtAVPlayer/src/avplayer'
Makefile:46: recipe for target 'sub-avplayer-make_first' failed
make[1]: *** [sub-avplayer-make_first] Error 2
make[1]: Leaving directory '/home/ai/Projects/QtAVPlayer/src'
Makefile:48: recipe for target 'sub-src-make_first' failed
make: *** [sub-src-make_first] Error 2

ai@ELDERORB:~/Projects/QtAVPlayer$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.5 LTS
Release:        18.04
Codename:       bionic
WSL

Maybe because ffmpeg installed without pkg-config support... Any ideas where can I find right ffmpeg for ubuntu 18?

FFmpeg ................................. yes
shows that it is visible using pkg-config
btw what is the version ?
$ pkg-config --version libavutil
0.29.1

ai@ELDERORB:~/Projects/QtAVPlayer$ pkg-config --version libavutil
0.29.1
weird. will do completely clean build

Okay, I see... With a completely clean build:
ai@ELDERORB:~/Projects/QtAVPlayer-upstream$ qmake
Info: creating stash file /home/ai/Projects/QtAVPlayer-upstream/.qmake.stash
Info: creating cache file /home/ai/Projects/QtAVPlayer-upstream/.qmake.cache
Running configuration tests...
Checking for FFmpeg... no
Checking for va_drm... no
Checking for va_x11... no
Done running configuration tests.
Configure summary:
Qt AVPlayer:
FFmpeg ................................. no
va_x11 ................................. no
va_drm ................................. no
Qt is now configured for building. Just run 'make'.
Once everything is built, you must run 'make install'.
Qt will be installed into '/home/ai/Qt/5.12.10/gcc_64'.
Prior to reconfiguration, make sure you remove any leftovers from
the previous build.
... which means previous one was 'pre-configured' because I didn't clean it completely from my experiments with QtAVPlayer (where I passed FFMPEG path via environment variable).
So, seems like my ffmpeg version doesn't have related *.pc files. Google-ing atm, but seems like its not so easy to find right pkg-config-friendly ffmpeg for ubuntu 18.04....

But then I tried to build example:
ai@ELDERORB:~/Projects/QtAVPlayer-upstream/examples/qml_video$ make
g++ -c -pipe -O2 -g -fno-exceptions -Wall -W -D_REENTRANT -fPIC -DQT_NO_FOREACH -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_AVPLAYER_LIB -DQT_QTMULTIMEDIAQUICKTOOLS_LIB -DQT_MULTIMEDIA_LIB -DQT_QUICK_LIB -DQT_GUI_LIB -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_CONCURRENT_LIB -DQT_CORE_LIB -D_REENTRANT -I. -I. -I../../include -I../../include/QtAVPlayer -I/home/ai/Qt/5.12.10/gcc_64/include -I/home/ai/Qt/5.12.10/gcc_64/include/QtMultimediaQuick -I/home/ai/Qt/5.12.10/gcc_64/include/QtMultimediaQuick/5.12.10 -I/home/ai/Qt/5.12.10/gcc_64/include/QtMultimediaQuick/5.12.10/QtMultimediaQuick -I/home/ai/Qt/5.12.10/gcc_64/include/QtMultimedia/5.12.10 -I/home/ai/Qt/5.12.10/gcc_64/include/QtMultimedia/5.12.10/QtMultimedia -I/home/ai/Qt/5.12.10/gcc_64/include/QtMultimedia -I/home/ai/Qt/5.12.10/gcc_64/include/QtQuick -I/home/ai/Qt/5.12.10/gcc_64/include/QtGui/5.12.10 -I/home/ai/Qt/5.12.10/gcc_64/include/QtGui/5.12.10/QtGui -I/home/ai/Qt/5.12.10/gcc_64/include/QtGui -I/home/ai/Qt/5.12.10/gcc_64/include/QtQml -I/home/ai/Qt/5.12.10/gcc_64/include/QtNetwork -I/home/ai/Qt/5.12.10/gcc_64/include/QtCore/5.12.10 -I/home/ai/Qt/5.12.10/gcc_64/include/QtCore/5.12.10/QtCore -I/home/ai/Qt/5.12.10/gcc_64/include/QtConcurrent -I/home/ai/Qt/5.12.10/gcc_64/include/QtCore -I.moc -isystem /usr/include/libdrm -isystem /usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/home/qt/openssl-1.1.1g/include -I/home/ai/Qt/5.12.10/gcc_64/mkspecs/linux-g++ -o .obj/main.o main.cpp
main.cpp: In function ‘int main(int, char**)’:
main.cpp:27:14: error: ‘class QDeclarativeVideoOutput’ has no member named ‘videoSurface’
p.vo(vo->videoSurface());
^~~~~~~~~~~~

great, videoSurface() exists after 5.15.
So it would hard to render in 5.12, it would need custom quick item.

Actually 'QAbstractVideoSurface' seems to exist in 5.12 too (and set via setProperty into 'QDeclarativeVideoRendererBackend') so it theory it should be possible to access it, right? The only issue is that it is not created automatically on creation QDeclarativeVideoOutput (createBackend is not called in a constructor in 5.12). But in theory if I find the way to access that property, should be possible, right?

great, pushed to master an example:
class Source : public QObject
{
    Q_OBJECT
    Q_PROPERTY(QAbstractVideoSurface *videoSurface READ videoSurface WRITE setVideoSurface)
public:

    QAbstractVideoSurface* videoSurface() const { return m_surface; }
    void setVideoSurface(QAbstractVideoSurface *surface)
    {
        m_surface = surface;
    }

    QAbstractVideoSurface *m_surface = nullptr;
 };

 Source src;
 vo->setSource(&src);
 if (src.m_surface)
    p.vo(src.m_surface);

5.12 is supported now.

Just checked - works on ubuntu 18.04 (wsl) with 5.12.10! Thanks!


Library Documentation Guidelines updated

Compressed all the Templates into one file, and replaced the Documentation Guidelines with that file. Other minor updates to Documentation sections.

OK. Please squash.

@alandefreitas OK, squashed!


Direct manipulation of mol2 files

I'd like to include in openmoltools few functions to perform simple manipulation of mol2 files without the need of external dependencies such as openeye. In particular, I need to

read/modify residue name
read net charge
normalize net charge to sum to the nearest integer

Since the library is organized by "tools" rather than functionality, I was thinking about creating a new module called fileio.py in which to include functions for direct manipulation.
The implementation would look like
>>> mol2_file = Mol2File('path/to/molecule.mol2')
>>> mol2_file.resname = 'MOL'
>>> mol2_file.resname
MOL
>>> mol2_file.normalize_charge()
>>> mol2_file.net_charge
1.0

the first implementation will support only files with a single molecule.
If you agree with this I'll open a PR and implement it.

Alternatively, should this be implemented in parmed since this is already an openmoltools dependency?

Yes. In fact, there is already some functionality related to your example in ParmEd at my request. For example, I believe Jason put in something like a fix_charges functionality which adjusts the charges to be closer to an integer.
(This is also in the pipeline from OpenEye, as OpenEye mol2 files did not originally have enough precision in the charges.)

See https://github.com/MobleyLab/SolvationToolkit/blob/89bcfa7e11693a20c23f2c7ad8522f3599c0bd81/solvationtoolkit/solvated_mixtures.py#L385 for a use of fix_charges from parmed.
And yes, I'm absolutely for putting the functionality you want into parmed rather than here. Parmed is starting to have a much larger life of its own than openmoltools does, so mol2 manipulation should certainly be handled there if at all possible.

The resname functionality you want is probably in parmed already, too.

Terrific! This will save me quite some time, thank you!


Remove v2v product features from core

... and move them to v2v repo: https://github.com/ManageIQ/manageiq-v2v/pull/990

:+1:

The matching PR in v2v is merged (https://github.com/ManageIQ/manageiq-v2v/pull/990), so we should merge this one too.

@martinpovolny Could you review / merge this one please? The related v2v PR is already merged and it seems that 3 weeks old unmerged PR does not seem to bother anyone.

@mzazrivec Travis is failing in manageiq-api. I think this PR is the cause?
  1) API configuration (config/api.yml) collections identifiers contains only valid miq_feature identifiers
     Failure/Error: expect(dangling).to be_empty
       expected `#<Set: {"conversion_host"}>.empty?` to return true, got false
     # ./spec/lib/api/api_config_spec.rb:34:in `block (4 levels) in <top (required)>'

@simaishi It seems so. I'll take a look. Thanks.

@simaishi https://github.com/ManageIQ/manageiq-api/pull/622 should fix it (hopefuly).

Thanks @mzazrivec


544 merge check

All API stuff is finally in

Codecov Report

Merging #46 (9e84f22) into master (6bb7ee2) will decrease coverage by 3.64%.
The diff coverage is 5.88%.

@@            Coverage Diff             @@
##           master      #46      +/-   ##
==========================================
- Coverage   50.13%   46.49%   -3.65%
==========================================
  Files          18       18
  Lines        1085     1084       -1
==========================================
- Hits          544      504      -40
- Misses        541      580      +39

Impacted Files
Coverage Δ

data_processing/services/delta_io_service.py
0.00% <0.00%> (-23.15%)
:arrow_down:

data_processing/radiology/proxy_table/generate.py
53.90% <16.66%> (+0.82%)
:arrow_up:

data_processing/common/custom_logger.py
47.36% <0.00%> (-52.64%)
:arrow_down:

data_processing/common/config.py
65.45% <0.00%> (-3.64%)
:arrow_down:

Continue to review full report at Codecov.

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


scipy 1.12.0 building from source issue with cython 0.29.36

Describe your issue.
I am unable to build scipy 1.12.0 or 1.13.0 from sources . ``
Reproducing Code Example
i am trying build using - https://docs.scipy.org/doc/scipy-1.12.0/building/index.html#building-from-source-to-use-scipy

I am using python 3.12.1 and took care of all dependencies -
    "meson-python>=0.15.0,<0.16.0", # working with 0.15.x series at branch time
    "Cython>=0.29.35,!=3.0.3,<3.1.0",  # when updating version, also update check in meson.build
    "pybind11>=2.10.4,<2.12.0", # working with 2.11.x series at branch time
    "pythran>=0.15.0,<0.16.0", # working with 0.15.x series at branch time

when i run pip install . -v --no-build-isolation , i get error

Error message
test_env) bash-4.4$ pip install . -v --no-build-isolation
Using pip 24.0 from /tmp/test_env/lib/python3.12/site-packages/pip (python 3.12)
Processing /tmp/scipy/scipy
  Running command Preparing metadata (pyproject.toml)
  + meson setup /tmp/scipy/scipy /tmp/scipy/scipy/.mesonpy-dmgyrizw -Dbuildtype=release -Db_ndebug=if-release -Db_vscrt=md --native-file=/tmp/scipy/scipy/.mesonpy-dmgyrizw/meson-python-native-file.ini
  The Meson build system
  Version: 1.4.0
  Source dir: /tmp/scipy/scipy
  Build dir: /tmp/scipy/scipy/.mesonpy-dmgyrizw
  Build type: native build
  Project name: scipy
  Project version: 1.13.0
  C compiler for the host machine: cc (gcc 8.5.0 "cc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-18.0.6)")
  C linker for the host machine: cc ld.bfd 2.30-123
  C++ compiler for the host machine: c++ (gcc 8.5.0 "c++ (GCC) 8.5.0 20210514 (Red Hat 8.5.0-18.0.6)")
  C++ linker for the host machine: c++ ld.bfd 2.30-123

  ../meson.build:1:0: ERROR: Unknown compiler(s): [['0.29.36']]
  The following exception(s) were encountered:
  Running `0.29.36 -V` gave "[Errno 2] No such file or directory: '0.29.36'"

  A full log can be found at /tmp/scipy/scipy/.mesonpy-dmgyrizw/meson-logs/meson-log.txt

SciPy/NumPy/Python version and system information
scipy 1.12.0
numpy 1.26.4
python 3.12.1

Sory dor false alarm. some of my env setting causing this build failure.


feature: lock application

please provide a way to lock the wallet (without having to close the wallet, that is).

Came here to ask for this. I've setup feather to lock itself after some minutes, but I'd like to request the ability to lock it immediately, ideally with a hotkey like Ctrl+L.
Also, I don't know if this is already the case, but it would be ideal if the wallet could continue to sync with the blockchain in the background while locked -- it just wouldn't display anything in the UI (of course not allow sending funds) without the password being entered.

scanning the blockchain for transactions that concern your wallet is very quick, you won't have to wait for too long at startup if your wallet is not open all the time. this is especially true if you run a full node locally.

Some folks need to use Tor and have ISPs that routinely spike to 30% packet loss several times per hour, so unfortunately it's not so quick for some users.

"fake locking" (blanking the UI) would leave keys in the memory

That's fair, and I'm grateful for the attention to this. Can you please just update the UI to make it clear that sync has stopped when it's locked? I wasn't sure if I had to unlock it to continue the sync or not.
Just a note on the "lock screen" saying that "sync is currently stopped while locked" would be fine.

Immediate locking (Ctrl+L) is implemented in: e5a61c6e2fb3e79092a7c40334c05635e2fc4a95
Note: Synchronization continues in the background. Feather can't currently protect against an attacker dumping process memory to extract private keys or wallet passwords. I'm interested in supporting this threat model, but I need a better understanding of Qt's memory model to determine if this is feasible.

does this mean that when Feather currently auto-locks, private keys and the wallet password can similarly be dumped from the memory?

Yes.

also, why is the password stored in the memory?

It's cached in wallet/api (part of Monero, used by most wallets except CLI), but appears to serve no real purpose.
After analyzing VM memory dumps, I can only find secret key material where it is expected. It looks like Qt isn't spraying sensitive information all over the place, which is good.
Here is what needs to happen to move towards better security against memory attacks:

The Polyseed is currently stored in the wallet cache. This was done because we can't derive a Polyseed from the secret spend key and we can't touch the .keys file without breaking wallet file compatibility. The Polyseed should be stored encrypted in memory. Upstreaming Polyseed (so it is stored in .keys) is on the to-do list.

Wallet password caching should be removed from wallet/api. Password verification should use wallet2::verifyPassword instead of comparing against the cached value. This causes a slight delay when opening dialogs that require the password or when unlocking the wallet.

The secret spend key should be encrypted when the wallet is locked. This mode is already supported by wallet2, but needs some plumbing from our side to make it work. Some additional changes are necessary to allow synchronization to continue in the background (monero-project/monero/pull/8619).

Use something like sodium_memzero to securely wipe memory from password entry dialogs and the Keys and Seed dialog  when they are closed.

Note: all of the above can only protect against an attacker learning your secret spend key from a memory dump. It can still be used to learn your secret view key, transaction metadata, contacts, etc. It will also not protect against an attacker that has access to your machine without you knowing it. If you enter your password after the system is compromised, they will obviously be able to learn the secret spend key.
Related ideas:

Lock all opened wallets when the screen is locked. Might be difficult to do cross-platform, but a best effort can be made.

Trade-offs:

Pwd entry to spend
Pwd entry to receive output
Sync when locked

Unencrypted spendkey
☒
☒
☑

Spendkey encrypted on lock
☒
☒
☑*

Spendkey encrypted after initial sync
☑
☑
☑*

* with monero-project/monero/pull/8619
I don't see any real downsides to encrypting the spendkey on lock, so this should become the default behavior after these changes are implemented.
I would like to point out that a generic solution exists for the snatch-and-run attack scenario that these measures help protect against: https://www.buskill.in. Its author happens to participate in this thread ;)

:) Ah, distinct between spend and view keys allows sync. I <3 Monero!
Since it seems that sync is not blocked with lock, can we also make that clear to the user? Can we have a message on the lockscreen that says "wallet is locked. sync is ongoing." or something?

The secret spend key should be encrypted when the wallet is locked

Small comment: in https://github.com/monero-project/monero/pull/8619, I simply wipe the spend key from memory when the wallet locks instead of encrypting it, and then when the user inputs their password to unlock the wallet, it'll re-read the encrypted key from disk and decrypt it.
unattended wallets (like RPC and GUI) would need a bit more plumbing to work nicely with wallet2's wallet_keys_unlocker; I figured this was a simpler approach.


Cors

Coverage remained the same at 44.685% when pulling b3f0570762fac21c748d200ae48ee89c5ea35735 on cors into 26ef52030429355cc34c643c0c4bf7561bfdf112 on master.


Leap micro53

One minor thing: If you keep old .lst files for 5.2 (or maybe use separate commit for them) - the diff would be smaller.  :) Alright, next time I will keep this in my mind. Thanks a lot Andrii


Update to encrypted sharedpreferences

Create new Encrypted Sharedpreferences Manager Class

There seems to be no problem with the code, so I'll merge it. 😄


Variants of ,sra

Unless the GM is rolling all the attacks, the player probably wont know the evade and soak of the target. Variants of the ,sra command that roll just just the attack and spits out damage and a separate one that takes in hits and damage and rolls evade and soak might be useful.

Fox had a similar concern about the possible use of Edge in the middle of the sequence.
There are certainly dramatic moments where the player might not know the defenses of the target, or the ultimate results might want to be hidden. In those cases, the player could just type 0 as the value for evade or soak and it'd still print the results of each step, and then the GM can fill in the gaps.
I'll try to keep it in mind as we go, and maybe add something later, so I'll just leave this as an open issue for a while.


stable/chart] Pods failing with no such file.

Describe the bug
While deploying Master-Slave sentinel cluster, their pods are failing with /run.sh: No such file or directory in both master & slave entrypoint.
Version of Helm and Kubernetes:
Helm: SemVer:"v2.13.1"
Major:"1", Minor:"14"
Which chart:
Redis master-slave sentinel deployment
What happened:
I'm trying to deploy Master-slave with Sentinel using below command:
helm install --name my-release-redis --set sentinel.image.registry="private-one",sentinel.image.repository="bitnami/redis-sentinel",sentinel.image.tag="latest",cluster.enabled=true,sentinel.enabled=true,master.persistence.storageClass=openebs-cstor,master.persistence.size=200M,slave.persistence.storageClass=openebs-cstor,slave.persistence.size=120M,image.registry="private-one",image.repository="bitnami/redis-sentinel",image.tag="latest" -f values.yaml  stable/redis --tiller-namespace=k8stest-solr --namespace=k8stest-solr
Output:
kubectl logs pod/my-release-redis-master-0 -n k8stest-solr --all-containers=true
/bin/bash: line 15: /run.sh: No such file or directory
1:X 26 Jun 2019 12:23:01.279 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1:X 26 Jun 2019 12:23:01.279 # Redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=1, just started
1:X 26 Jun 2019 12:23:01.279 # Configuration loaded
1:X 26 Jun 2019 12:23:01.282 * Running mode=sentinel, port=26379.
1:X 26 Jun 2019 12:23:01.282 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
1:X 26 Jun 2019 12:23:01.287 # Sentinel ID is 0eea02acb2121f0bccd82f37ebe7e12aef8f54b4
1:X 26 Jun 2019 12:23:01.287 # +monitor master mymaster <IP_ADDRESS> 6379 quorum 2
1:X 26 Jun 2019 12:24:01.330 # +sdown master mymaster <IP_ADDRESS> 6379
kubectl logs pod/my-release-redis-slave-0 -n k8stest-solr --all-containers=true
/bin/bash: line 20: /run.sh: No such file or directory
*** FATAL CONFIG FILE ERROR ***
Reading the configuration file, at line 4

'sentinel monitor mymaster my-release-redis-master-0.my-release-redis-headless.k8stest-solr.svc.cluster.local 6379 2'
Can't resolve master instance hostname.

What you expected to happen:
To be deployed master-slave sentinel cluster
How to reproduce it (as minimally and precisely as possible):
Used above command to deploy a redis  cluster on K8s cluster.
Anything else we need to know:
We're using our own docker registry and openebs as persistenance storage.

Hi @deepak71 ,
I guess it could be related to your command. I am not sure if you can specify a --set option and also a -f, but in case this is possible as you put the -f after the --set maybe it overrides the values of the --set parameters.
To override values in a chart, use either the '--values' flag and pass in a file
or use the '--set' flag and pass configuration from the command line.  To force string
values in '--set', use '--set-string' instead. In case a value is large and therefore
you want not to use neither '--values' nor '--set', use '--set-file' to read the
single large value from file.

	$ helm install -f myvalues.yaml ./redis

or

	$ helm install --set name=prod ./redis

or

	$ helm install --set-string long_int=1234567890 ./redis

or
    $ helm install --set-file multiline_text=path/to/textfile

You can specify the '--values'/'-f' flag multiple times. The priority will be given to the
last (right-most) file specified. For example, if both myvalues.yaml and override.yaml
contained a key called 'Test', the value set in override.yaml would take precedence:

	$ helm install -f myvalues.yaml -f override.yaml ./redis

You can specify the '--set' flag multiple times. The priority will be given to the
last (right-most) set specified. For example, if both 'bar' and 'newbar' values are
set for a key called 'foo', the 'newbar' value would take precedence:

	$ helm install --set foo=bar --set foo=newbar ./redis

To check the generated manifests of a release without installing the chart,
the '--debug' and '--dry-run' flags can be combined. This will still require a
round-trip to the Tiller server.

If --verify is set, the chart MUST have a provenance file, and the provenance
file MUST pass all verification steps.


Validation error notification isn't displayed for composition 1-to-M field

Enviroment:
Jmix version: 1.0.999-SNAPSHOT
Jmix Studio plugin version: 1.1.SNAPSHOT3273-211
IntelliJ version: IntelliJ IDEA 2021.1.3 (Ultimate Edition)
TC:

Open attached project -> Run Jmix app -> Run React app
Open react app in a browser -> Login -> Open Customers List
Create new Customer -> click add entities near Partcomp
Create new Part entity -> set age value > 10 -> set name value with length < 5  -> Ok
Return to Customer editor -> Open dev tools, network tab -> click Submit button

AR:
GraphQL errors are displayed in responce preview, validation error notification isn't displayed for Partcomp field:

ER:
Validation error is displayed like this:

Frontend
Before example-react-app update the environment:
The error in composition one to many doesn't have array nesting.

Validation works, but it's the wrong field error path. It has to be compositionO2Mattr[0].quantity

After example-react-app update the environment:
The error doesn't have information about the error.

scr-jmix project updated, now this issue could be reproduced on query
mutation {
  upsert_scr_CompositionO2MTestEntity(compositionO2MTestEntity: {
    deeplyNestedO2Mattr: [
      {name: "123456"}
    ]
  }) {
    _instanceName
  }
}

Frontend part of the issue could be implemented usin 1.0.0 jjmix version.
Backend works incorrect on 1.0.999-SNAPSHOT issue created https://github.com/Haulmont/jmix-graphql/issues/180


Using mysql with flutter

Hey I am very new to all of this and these questions may sound stupid. I don't need to know step by step instructions, I just want to know if it is possible.
To preface this, I am an intern practicing with app development and could maybe use the app i'm creating.

I was told that the company i work for has an existing database in mysql in conjunction with PHP (backed by a firewall) that my app could benefit from. I was wondering if it is at all possible and secure to call from this in my flutter app and not from firebase.

Would the sqljocky dependency help me out?

Also if there is any documentation that could help me with all of this that would be greatly appreciated.

thank you

Flutter as a client library doesn't really have any relation with the type of database you are using in your back-end.
You just have to expose a web API where you can do http requests from the Flutter side.
What you need is  simple :

Ask your co-workers to give you the API documentation of the backend of your company's system.
Get a Flutter HTTP library.
Call that API from the client (Flutter mobile app) get the response, it's most of time in Json, transform the Json into plain objects.
Render the data into your mobile app.


1.2.3

? Relocate outdated reset styles into mixins (? should be done by autoprefix)
? less, ? stylus
? test: additional test cases for popular js libraries (sandbox)
? scss config by condition variables for enabling normalization features
? example for postcss ( or plugin )
? doc: link to https://gitter.im/frontent-issues/community
? test: override reset styles by custom (a (:hover, :visited etc.), input)
? doc: features and secondary (more detailed) features
[ ] select reset for dropdown component by mixins
[ ] examples for structured elements wrapped by mixins and extended by variables
[x] css support + CDN
[x] sys: remove yarn.lock
[ ] html {  scroll-behavior: smooth; }

Chrome 81 feature(bug) with disabled scroll for reduced animation system parameter
  html {
      scroll-behavior: smooth;
  }

   /* Chrome 81+ fix */
  @media (prefers-reduced-motion: reduce) {
    .my-smooth-container {
      scroll-behavior: smooth;
    }
  }


get instanceGUID from DirectInputDevice

It would be nice to get the instanceGUID from DirectInputDevice's, just like the product GUID.
It is actually accessible (see here), but is not stored in the DirectInputDevice object.
I suggest storing that as an object variable (string) and having it accessible via an get_instance_guid()-method.
Here's a sample implementation:
i = device_instance.contents.guidInstance
self.instance_guid = (f"{i.Data1:08x}-{i.Data2:04x}-{i.Data3:04x}-" +
           "".join(f"{x:02x}" for x in i.Data4[:2]) +
           "-" + "".join(f"{x:02x}" for x in i.Data4[2:]))

This can certainly be added if it's useful.
Same question as my comment in your other issue:  Any reason why not just expose the struct directly?

This can certainly be added if it's useful. Same question as my comment in your other issue: Any reason why not just expose the struct directly?

no reason. i'm not that deep into ctypes and pyglet, but i guess you want to encapsulate everything into python, right?
Maybe a GUID-class would be a good solution for this and #1050

I'm sorry, but why is this closed?
Is this rejected?
In 2eb3cfe you changed how the productGUID is retrieved, but there is still no implementation for the instanceGUID.

This was just an oversight. The instance guid has also been added in the development branch.


triton requirement is out of date

Attempting to use jax-triton nightly fails on CUDA with
 File "/home/michael/.local/lib/python3.10/site-packages/jax/_src/interpreters/mlir.py", line 1433, in jaxpr_subcomp
    ans = rule(rule_ctx, *rule_inputs, **eqn.params)
  File "/home/michael/.local/lib/python3.10/site-packages/jax_triton/triton_lib.py", line 383, in triton_kernel_call_lowering
    kernel, specialization = get_or_create_triton_kernel(
  File "/home/michael/.local/lib/python3.10/site-packages/jax_triton/triton_lib.py", line 252, in get_or_create_triton_kernel
    module = code_gen.ast_to_ttir(
TypeError: ast_to_ttir() got an unexpected keyword argument 'target'

This appears to be because requirements.txt lists triton_nightly-2.1.0.dev20230714011643, but a newer triton nightly is actually required.
(That version doesn't have a 'target' argument to ast_to_ttir).
I would around this by installing triton_nightly-2.1.0.dev20231014192330, but it would be great to have correct dependencies.

Thanks for investigating, I probably won't get around to this for a week or so. A PR is greatly appreciated though!


SwiftyJSON not compiling with socket.io-swift

I have added socket.io and swiftyjson manually to my project. But my app is not compiling and showing issue.--> invalid redeclaration of JSON.
I have also attached the sample project.
SocketWithSwiftyJSON.zip

You should consider to use CocoaPod or Carthage to manage swift module.

The latest Socket.IO works for me. One thing need more consideration is:  JSON is a typealias of  [String: Any] in Socket.IO.
See https://github.com/nuclearace/Socket.IO-Client-Swift/blob/163a770abc4842250d31b8662354d0df190c2885/Source/SocketTypes.swift#L45

@wongzigii  What to do if duplicate typealias  "JSON" was defined ?

@yonlau You can specific the JSON with namespace, SwiftyJSON.JSON or SocketIO.JSON.


Use of undeclared type 'JSQMessageData'

I got this error message when trying to add model.
/Users/MNurdin/Documents/iOS/xxxxx/Models/Message.swift:11:27: Use of undeclared type 'JSQMessageData'

Model code
class Message : NSObject, JSQMessageData {

Even i already tried import JSQMessage, but still not successful.
import JSQMessage

I got this error message after that
/Users/MNurdin/Documents/iOS/xxxxx/Models/Message.swift:10:8: No such module 'JSQMessage'

Please advice. Thank you.

are you sure you have the bridging header done right ? doing #import "JSQMessages.h" is sufficient to get everything into swift.

Yes, I'm pretty sure.

Just use JSQMessagesViewController:
import JSQMessagesViewController


NunitoSans font from package google_fonts 2.2.0 does not look right

Steps to Reproduce

add google_fonts to project
use code below (text with NunitoSans font)

Expected results: NunitoSans Google fonts

Actual results:

import 'package:flutter/material.dart';
import 'package:google_fonts/google_fonts.dart';

class TestPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Text(
          'Almost before we knew it, we had left the ground.',
          style: GoogleFonts.nunitoSans(),
        ),
      ),
    );
  }
}

There's probably an error in the run logs. Can you provide the output of flutter run -v?

log.txt

Thanks, I'm seeing that the font is applied but the look doesn't match the website's look, possible that we just need to update the font on the backend


texture integration

Hello guys,
I have done some work to integrate texture editor with our stack.  Basically I created a new XML Store (cf. https://github.com/kaschioudi/texture/blob/xmlps/examples/XMLPSXMLStore.js) and modified package.js (from jats-editor folder) to use my new store instead of the example store. Then I ran npm run bundle to generate the bundle.
The editor is successfully loaded and rendered. However I don't understand how texture loads resources.
For instance, when I load texture on a page with the following url  http://domain.com/manager/editor/id/1510. Then for  <graphic xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="media/image1.png" ...> the editor tries to fetch the resource from http://domain.com/manager/editor/id/media/image1.png instead of http://domain.com/manager/editor/id/*1510*/media/image1.png.
Did I miss a step in the integration process?
My changes are available here: https://github.com/kaschioudi/texture
Thank you for your assistance.

@axfelix

Hey currently resources need to have a fully qualified url in the XML to work. However we should add an URL resolver, that can be configured. JATS also specified a baseurl attribute that could be use for resolving asset urls.

This is what OJS does currently for static HTML articles -- we've gotten some questions from users wanting to upload their own pre-prepared JATS for use with the Lens Viewer that shipped in OJS 3.0:

For HTML documents, we're rewriting filenames. JMs will have pre-uploaded a set of images/CSS/etc. to go with the HTML.

For each of these, we look at the original filename (as it was on the system from which it was uploaded). We look for href="that_filename.jpg" in the HTML, and rewrite that with the proper URL.
From the user's perspective, they just use straight-up filenames. I suggest we try keeping the same convention.

Basically, we need to figure out how we're going to make external media make sense in the context of OJS3 + Texture + our conversion stack hooks.


Manually selecting a reconciliation match returns the grid to page 1.

Original author: staringmonkey (May 14, 2010 14:09:53)
What steps will reproduce the problem?

From the header of a data column select Reconcile -> Start Reconciling.
Select and appropriate topic and click Start Reconciling.
Wait for the reconcile to complete.
Click the "next page" link.
Find a cell that which has several possible reconciliation matches and
click the check-mark or double-check-mark image.

What is the expected output? What do you see instead?
Reconciliation is completed correctly, however, grid is returned to page
one.  This makes it nearly impossible to complete manual reconciliation for
large datasets.
What version of the product are you using? On what operating system?
SVN HEAD on OSX.
Please provide any additional information below.
Original issue: http://code.google.com/p/google-refine/issues/detail?id=33

@wetneb Does this happen on your working branch any longer with Wikidata new parts ? If not, then let's close this out noting so.

@thadguidry yes this is unfortunately still current (it is not specific to freebase).

Here is a visual example. As you can see, I'm on pages 91-100. But as soon as I make a reconciliation, I come back to page 1.

See also #569 - similar issue (user is returned to start (row 1) of project), but in relation to a different action ("Apply to all identical cells" on manual cell edit)

@wetneb @ostephens We'll use this #33 as the primary issue for the annoyance by users.  I think we should open a new issue that captures the Enhancement introduction of a new "Reconcile Mode" that doesn't flip back to row 1, but keeps the Reconcile -> Facets -> By Judgement enabled with selected as "None" as the default.  And that facet can't go away until they unclick "Reconcile Mode".  We can also add other features to this "Reconcile Mode" as needed (some default behaviors that get enabled or some special handling).

They click on a button to start "Reconcile Mode".  (perhaps next to records link)
User is given a message "Reconcile Mode is now ON"
The By Judgement facet then shows a count of all rows selected in "none" and 0 "matched" rows.
User begins reconciling with dialogs.
By Judgement facet stays enabled and cannot be removed.
User wants to stop "Reconcile Mode" and clicks some button and is given a message "Reconcile Mode is now OFF".
By Judgement facet goes away.

Thoughts?

I am not sure such a "Reconcile Mode" would offer much value over the current workaround: that is already what the facet does. I was thinking of a dedicated UI for matching (separate from the grid view) which would be optimized for that.

Then how do you propose we make this issue go away and not so frustrating for users?

Yes.  Or for this issue only, it could also be done by simply making sure the page is preserved when we apply an operation, but it might not be worth investing too much effort in that if we want to migrate to a scrollable grid in the end.

Agreed.  I'd rather us focus on a dedicated UI with a scrollable grid for Reconciling.

Document summarizing the approaches @lisa761 and I have been thinking about to solve this issue:
https://docs.google.com/document/d/1zw_Nj0O5KNRmEIPwc6gNTF4tdhSYWDEOVYPAr-F5gi4/edit#

Thanks for summarizing the options. From a user's point of view, I think their ideal outcome is that screen gets re-rendered in a minimal fashion, ie any updates that are required get made in situ with the rest of the grid being unchanged and fixed in the same position. Any rows which are no longer visible should smoothly "melt" away with their neighbors being smoothly scrolled into place.
Obviously there are going to be pathological cases where the entire screen ends up getting repainted anyway, but, ideally, for smaller updates, the user should be able to visually track what's happening and retain their context. Of course, the benefit of the "ideal" solution needs to be weighed against the implementation cost.

At least in 3.4.1, master and 4.0, the original issue only affects the dataset-wide operations (Match All Identical Cells / Search for match -> Match other cells with same content). The single-cell operations (Match this Cell / Search for match -> Match this cell only) remain on the current page. (We might want to update the issue title for that.)
Based on that, maybe it would be an improvement to flip the default of Match other cells with same content to Match this cell only. This would provide the user a more basic, but working default workflow. I'd also imagine that with a conscious decision to match all cells, the jumping behavior would appear less buggy and more like a missing feature ('right, I changed the entire dataset, so now I'm at the beginning again'). It might also make sense to flip the visual order of Match other cells with same content / Match this cell only to correspond to the ordering of the Match this Cell / Match All Identical Cells buttons.

I would like to propose a solution to this issue based on the new architecture developed in the 4.0 branch. I have not implemented it yet, but I want to discuss the implications here first.
For technical reasons, the API offered by the backend has changed in the new architecture. To fetch a given page of rows, the frontend had to provide three things: the configuration of the engine (row/records mode and facets), the number of rows to skip before the beginning of the page, and the size of the page itself. With the new architecture, instead of providing the number of rows to skip before the page, we provide the row number of the first row to start displaying in the page. That is not necessarily the same thing if some rows have been filtered out by facets.
This internal API change is an opportunity to change the user interface too. Instead of letting the user input a page number, this new API invites us to let the user provide the row number of the first row to show. On its own, I do feel like (at least hope) this is not harming the usability much. But the reason why I am mentioning this here is that I feel like this suggests a surprisingly easy fix for this long standing issue.
Whenever the user applies an operation that affects multiple rows (such as a reconciliation judgment), we could just preserve those new pagination settings, re-fetch the contents of that page, rerender, and done.
This approach did not make sense before, because preserving the page number is not meaningful: if your action affects earlier rows which are now excluded by a facet, then your view of the grid will jump forward, skipping rows (which is a problem if you are in the process of scanning the grid from start to end, for instance when reviewing reconciliation results). But if we are preserving the row number of the first row to start the page at, this problem disappears. There might still be a little move (for instance because the first row of the page is now filtered away by a facet), but we have the guarantee that no row will be skipped.
Given that we still do not have infinite scrolling, there is also the question of whether the scrolling in the current page should be preserved. Given that the content of the page can still change in pretty arbitrary ways (existing rows becoming filtered out by facets, new rows coming in) I would still automatically scroll back to the top of the page.
Given that it's so simple to implement, I might just do that so that people can try it out - it's probably a lot easier!

This would also solve a related issue, #570.
I realized it's not quite as simple to implement as I thought because if we still want to provide a button to go to the previous page (which we surely do), we need to:

either remember on which row that page started - which implies keeping a stack of all previous page starts if the user clicks "Previous" multiple times. And still, that does not give a perfect result because changes in the grid and faceting could mean that the pages get offset.

or change the backend so that it supports a different kind of page request, supplying:

the engine config
the first row number to follow the page to fetch
the size of the page

and still support the other sorts of requests (to go to the next page). With that solution I think we can get exactly the natural, expected behaviour. I think it is doable.

@tfmorris @wetneb  should we re-open to remind us that this needs to be addressed in master ?

It should be addressed by #6546 which was merged in master. Are you still able to reproduce this issue on the master branch? If so, it would be worth reopening this indeed.

It came up as part of the user request in the survey. I wanted to link to the correct issue and provide an update on its status

@wetneb I'm trying to test this with master because I do think this was still happening, but not getting far today because I keep getting these console errors when trying to manually match (typing in a wood species name, suggest finds it, I click on the QID element, then the dialog goes away, but no match is performed and I get this error):
404 (Not Found)
GET > https://wikidata.reconci.link/search?filter=(all%20mid:Q27684975)&output=(notable:/client/summary%20(description%20citation%20provenance)%20type)&key=null

Checked out master, then git pull https://github.com/wetneb/OpenRefine.git 6746-fix-dialog-closing
Still the same 404 error as above in Edge browser console.  It throws that 404 error in the console RIGHT WHEN I hover over any suggested QID in the drop down.  If I hover over another QID in suggest dropdown that I want to manually apply, I get the repeated error in the console.

@thadguidry could you open a separate issue about that then?

@wetneb Just tested again with a new project with 7 pages.  It works fine, no matter if I "Match this Cell", or "Search for match" and manually choose from dropdown.  The reconciliationstays on the grid page that I am on, and I can navigate to a first or last page, or any page, manually apply a few matches, and it stays on the page I'm on.
The above works no matter if Judgement Facet has a selection on "none" or no selection filtering.
I'd say this is fixed!


Rotation on 3D transform animation track doesn't work

Godot version:

3.2.1 stable official
OS/device including version:

Geforce 750 TI, GLES3
Issue description:

when using a 3d transform track adding rotation information to keys is simply ignored
(P.S. why does the editors axis lines intersect at (0.5, 0, 0) ?)
Steps to reproduce:
add a 3d transform track to an object, change the rotation information, observe no change.
Minimal reproduction project:

no rotation.zip

It's not working because the rotation is a quaternion, and not the regular rotation degrees.
To work on transforms, it's best to edit the object in the editor, and not in the inspector:

(P.S. why does the editors axis lines intersect at (0.5, 0, 0) ?)

I don't see it, the axis are aligned at (0, 0, 0). Maybe the confusion is coming from your object, which is slight to the left of the origin?


drain_filter for hashmaps?

Hi,
I saw the RFC for https://github.com/rust-lang/rust/issues/43244, and was wondering if there was an equivalent need for drain_filter-esque behaviour with hashmaps? I've thought about using drain and then reconstructing another HashMap, but I would like to avoid the cost of that.
I also thought about using retain and putting items that weren't retained into a Vec, but I can't take ownership of the items being removed unless I clone/copy them.
In this case, I'm trying to minimize the number of allocations I'm making while taking some items out of a hashmap and putting them into a buffer passed in from elsewhere. The main issue with the retain approach is the inability to not take ownership.
I might be able to dig into the raw api to get something, but I was wondering if this was common enough to be added to the safe api.
I can't seem to find another RFC for this anywhere, and I'm not sure if this is the relevant place to request this, but I thought since this was the underlying implementation for the hashmap it would be good to request it here.
Thanks!

Porting drain_filter to HashMap shouldn't be too difficult if you base it on the implementation of retain. I don't think there would be any objections to adding this feature. Feel free to submit a PR here first, and in libstd afterwards.


build: upgrade fuels to 0.95.0

Summary
Updates all fuels versions to the the latest verisons as well as  @fuels/connectors and @fuels/react, removes deprecated  @fuel-wallet/sdk , @fuel-wallet/types as they have been consolidated into fuels
LICENSE:
The Fuel Support team submits this PR to help you use the fuel SDKs. It is provided "as is"
and without warranty for any purpose. We are not participants in the project at hand.
All the rights of this code are reserved to the authors of this repository.

Superseded by #505

@maschad - please close as this is superseded by #505


Define and scope the use cases and doc requirements for the first release

The plan for the first release is documented in this slide deck and discussed in the community call dated 7th July 2022. The record of the meeting is available from the following link
We are targeting three scenarios for the first release.

Developer: Run CC on your laptop, no confidential computing HW deps
Local: Run CC with local/offline attestation, no CC HW deps
Production (dev preview): Run CC with remote attestation on top of CC HW

This issue aims to create a shared understanding of the scenarios, document the key user stories,  identify documentation requirements and get feedback.
Terminologies

Confidential Containers (CoCo) Software Stack: This includes confidential containers (CoCo) runtime (e.g. Kata, enclave-cc), CoCo operator, and Attestation Service. The CoCo runtime will be running in a Kubernetes cluster.
Workload: This is the application container image(s) deployed as a Kubernetes POD.
Confidential Computing (CC) capable hardware: This is the server hardware with CC capabilities (e.g. AMD SEV-SNP/TDX/SE/SGX etc.)

Developer scenario
User stories

As a developer working in the CoCo software stack, I should be able to deploy the complete stack on my development environment for dev/test activities

Local Scenario
User stories

As a developer working in the CoCo software stack, I should be able to deploy the complete stack on my development environment for dev/test activities
As a workload developer, I should be able to deploy and test my workload on top of the CoCo stack
As a workload developer, I should be able to create confidential container images

** Dev preview Scenario **
User stories

As a developer working in the CoCo software stack, I should be able to deploy the complete stack on CC capable hardware for dev/test activities
As a workload developer, I should be able to deploy and test my workload on the CoCo stack running in CC capable hardware.
As a workload developer, I should be able to create confidential container images

We will also need to document the following from a workload standpoint.

How to create signed container images?
How to create encrypted container images?
How to use encrypted secrets with signed container images?
How to deploy sample workloads?

encrypting nginx image and deploying the same
signing ngnix image and using an encrypted secret which get displayed in plaintext from a page served via nginx.
...

From a CoCo software stack standpoint, we need to document the following.

Supported/Tested hardware
Deployment of CoCo runtime via CoCo operator
Deployment of Attestation Service (AS)

cc @fitzthum @sameo @ariel-adam @dcmiddle @fidencio

@bpradipt is this issue still relevant or can be closed?
If it's still relevant to what release do you think we should map it to (mid-November, end-December, mid-February etc...)?


Release v0.42.0

Issue #, if available: N/A
Description of changes: new release!
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

need to finish https://github.com/aws-cloudformation/cfn-python-lint/pull/1799 before getting a release out


feat(theme): multiple themes and presets configuration

Easily configure multiple themes and presets for out cute long-tailed bushtit now.

Color presets in tailwind.config.js
Themes selector in HeaderView.component.jsx
Add theme names to constants.config.theme

Convert to draft again. Need to migrate the bookmark database.

感觉应该👌但还是麻烦您看看了 @starsJuly