Test Loss: 41927.7059582 ??? With default hyper-parameters

xxx@xxxx:~/TimeMixer$ bash ./scripts/long_term_forecast/Weather_script/TimeMixer_unify.sh
Args in experiment:
Namespace(task_name='long_term_forecast', is_training=1, model_id='weather_96_96', model='TimeMixer', data='custom', root_path='./dataset/weather/', data_path='weather.csv', features='M', target='OT', freq='h', checkpoints='./checkpoints/', seq_len=96, label_len=0, pred_len=96, seasonal_patterns='Monthly', inverse=False, top_k=5, num_kernels=6, enc_in=21, dec_in=21, c_out=21, d_model=16, n_heads=4, e_layers=3, d_layers=1, d_ff=32, moving_avg=25, factor=3, distil=True, dropout=0.1, embed='timeF', activation='gelu', output_attention=False, channel_independence=1, decomp_method='moving_avg', use_norm=1, down_sampling_layers=3, down_sampling_window=2, down_sampling_method='avg', num_workers=10, itr=1, train_epochs=20, batch_size=128, patience=10, learning_rate=0.01, des='Exp', loss='MSE', lradj='TST', pct_start=0.2, use_amp=False, comment='none', use_gpu=True, gpu=0, use_multi_gpu=False, devices='0,1', p_hidden_dims=[128, 128], p_hidden_layers=2)
Use GPU: cuda:0

start training : long_term_forecast_weather_96_96_none_TimeMixer_custom_sl96_pl96_dm16_nh4_el3_dl1_df32_fc3_ebtimeF_dtTrue_Exp_0>>>>>>>>>>>>>>>>>>>>>>>>>>
train 36696
val 5175
test 10444
iters: 100, epoch: 1 | loss: 0.4307363
speed: 0.0692s/iter; left time: 389.1167s
iters: 200, epoch: 1 | loss: 0.4297568
speed: 0.0611s/iter; left time: 337.2267s
Epoch: 1 cost time: 17.889004945755005
Epoch: 1, Steps: 286 | Train Loss: 0.5415171 Vali Loss: 0.4307196 Test Loss: 0.1833659
Validation loss decreased (inf --> 0.430720).  Saving model ...
Updating learning rate to 0.0018082204734143938
iters: 100, epoch: 2 | loss: 0.3520306
speed: 0.1521s/iter; left time: 811.5801s
iters: 200, epoch: 2 | loss: 0.3565684
speed: 0.0618s/iter; left time: 323.7447s
Epoch: 2 cost time: 17.85987901687622
Epoch: 2, Steps: 286 | Train Loss: 0.4447075 Vali Loss: 0.4094866 Test Loss: 0.1705955
Validation loss decreased (0.430720 --> 0.409487).  Saving model ...
Updating learning rate to 0.005206596517931138
iters: 100, epoch: 3 | loss: 0.3173375
speed: 0.1528s/iter; left time: 771.3829s
iters: 200, epoch: 3 | loss: 0.3592640
speed: 0.0621s/iter; left time: 307.5004s
Epoch: 3 cost time: 17.934012413024902
Epoch: 3, Steps: 286 | Train Loss: 0.4251685 Vali Loss: 0.3993056 Test Loss: 0.1661765
Validation loss decreased (0.409487 --> 0.399306).  Saving model ...
Updating learning rate to 0.008601101999279598
iters: 100, epoch: 4 | loss: 0.3249778
speed: 0.1530s/iter; left time: 728.5612s
iters: 200, epoch: 4 | loss: 0.4692132
speed: 0.0622s/iter; left time: 289.8614s
Epoch: 4 cost time: 17.94803547859192
Epoch: 4, Steps: 286 | Train Loss: 0.4286626 Vali Loss: 0.4020122 Test Loss: 0.1657454
EarlyStopping counter: 1 out of 10
Updating learning rate to 0.009999998821672624
iters: 100, epoch: 5 | loss: 0.3110182
speed: 0.1529s/iter; left time: 684.4151s
iters: 200, epoch: 5 | loss: 5966753.5000000
speed: 0.0621s/iter; left time: 271.7755s
Epoch: 5 cost time: 17.991345167160034
Epoch: 5, Steps: 286 | Train Loss: 73039167.1294913 Vali Loss:<PHONE_NUMBER>563 Test Loss: 41927.7059582
EarlyStopping counter: 2 out of 10
Updating learning rate to 0.00990325594987406
iters: 100, epoch: 6 | loss: 27256.5839844
speed: 0.1534s/iter; left time: 642.9746s
iters: 200, epoch: 6 | loss: 40716.7031250
speed: 0.0625s/iter; left time: 255.5338s
Epoch: 6 cost time: 18.048863887786865
Epoch: 6, Steps: 286 | Train Loss: 61819.4581956 Vali Loss: 19785.5467773 Test Loss: 8566.0788152
EarlyStopping counter: 3 out of 10
Updating learning rate to 0.009618084470288236
iters: 100, epoch: 7 | loss: 42804.7265625
speed: 0.1541s/iter; left time: 601.9182s
iters: 200, epoch: 7 | loss: 14851.3417969
speed: 0.0624s/iter; left time: 237.5837s
Epoch: 7 cost time: 18.051480293273926
Epoch: 7, Steps: 286 | Train Loss: 30657.5081574 Vali Loss: 13869.5492432 Test Loss: 4513.3062156
EarlyStopping counter: 4 out of 10
Updating learning rate to 0.009155443362949628
iters: 100, epoch: 8 | loss: 9879.9335938
speed: 0.1534s/iter; left time: 555.0071s
iters: 200, epoch: 8 | loss: 26258.4062500
speed: 0.0624s/iter; left time: 219.5428s
Epoch: 8 cost time: 18.00772786140442
Epoch: 8, Steps: 286 | Train Loss: 23289.7381600 Vali Loss: 7120.0204468 Test Loss: 2942.5684035
EarlyStopping counter: 5 out of 10
Updating learning rate to 0.008533111666161134
iters: 100, epoch: 9 | loss: 6651.8051758
speed: 0.1532s/iter; left time: 510.6945s
iters: 200, epoch: 9 | loss: 7979.3217773
speed: 0.0624s/iter; left time: 201.8479s
Epoch: 9 cost time: 18.038314819335938
Epoch: 9, Steps: 286 | Train Loss: 13656.0039387 Vali Loss: 9894.2515869 Test Loss: 4533.5889727
EarlyStopping counter: 6 out of 10
Updating learning rate to 0.007775005238022703
iters: 100, epoch: 10 | loss: 7160.9116211
speed: 0.1537s/iter; left time: 468.3441s
iters: 200, epoch: 10 | loss: 11085.7910156
speed: 0.0624s/iter; left time: 183.7755s
Epoch: 10 cost time: 18.018856048583984
Epoch: 10, Steps: 286 | Train Loss: 11040.1564498 Vali Loss: 7765.1726685 Test Loss: 3500.1894863
EarlyStopping counter: 7 out of 10
Updating learning rate to 0.006910257683416708
iters: 100, epoch: 11 | loss: 21434.4316406
speed: 0.1536s/iter; left time: 424.1434s
iters: 200, epoch: 11 | loss: 4110.5146484
speed: 0.0624s/iter; left time: 166.1284s
Epoch: 11 cost time: 18.04583215713501
Epoch: 11, Steps: 286 | Train Loss: 8240.5528419 Vali Loss: 5190.9347229 Test Loss: 1577.0768572
EarlyStopping counter: 8 out of 10
Updating learning rate to 0.005972100765910645
iters: 100, epoch: 12 | loss: 3391.3840332
speed: 0.1540s/iter; left time: 381.0550s
iters: 200, epoch: 12 | loss: 22552.2753906
speed: 0.0625s/iter; left time: 148.4305s
Epoch: 12 cost time: 18.07685947418213
Epoch: 12, Steps: 286 | Train Loss: 7187.2250772 Vali Loss: 3726.9754517 Test Loss: 1578.9364279
EarlyStopping counter: 9 out of 10
Updating learning rate to 0.004996587329719809
iters: 100, epoch: 13 | loss: 3442.0224609
speed: 0.1533s/iter; left time: 335.4760s
iters: 200, epoch: 13 | loss: 2756.2189941
speed: 0.0624s/iter; left time: 130.3737s
Epoch: 13 cost time: 18.014405965805054
Epoch: 13, Steps: 286 | Train Loss: 7158.0969733 Vali Loss: 5071.9943359 Test Loss: 2097.3409002
EarlyStopping counter: 10 out of 10
Early stopping
testing : long_term_forecast_weather_96_96_none_TimeMixer_custom_sl96_pl96_dm16_nh4_el3_dl1_df32_fc3_ebtimeF_dtTrue_Exp_0<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
test 10444
test shape: (81, 128, 96, 21) (81, 128, 96, 21)
test shape: (10368, 96, 21) (10368, 96, 21)
mse:0.1661764234304428, mae:0.21156392991542816
rmse:0.40764743089675903, mape:0.5020378828048706, mspe:25357502.0
Args in experiment:
Namespace(task_name='long_term_forecast', is_training=1, model_id='weather_96_192', model='TimeMixer', data='custom', root_path='./dataset/weather/', data_path='weather.csv', features='M', target='OT', freq='h', checkpoints='./checkpoints/', seq_len=96, label_len=0, pred_len=192, seasonal_patterns='Monthly', inverse=False, top_k=5, num_kernels=6, enc_in=21, dec_in=21, c_out=21, d_model=16, n_heads=4, e_layers=3, d_layers=1, d_ff=32, moving_avg=25, factor=3, distil=True, dropout=0.1, embed='timeF', activation='gelu', output_attention=False, channel_independence=1, decomp_method='moving_avg', use_norm=1, down_sampling_layers=3, down_sampling_window=2, down_sampling_method='avg', num_workers=10, itr=1, train_epochs=20, batch_size=128, patience=10, learning_rate=0.01, des='Exp', loss='MSE', lradj='TST', pct_start=0.2, use_amp=False, comment='none', use_gpu=True, gpu=0, use_multi_gpu=False, devices='0,1', p_hidden_dims=[128, 128], p_hidden_layers=2)
Use GPU: cuda:0
start training : long_term_forecast_weather_96_192_none_TimeMixer_custom_sl96_pl192_dm16_nh4_el3_dl1_df32_fc3_ebtimeF_dtTrue_Exp_0>>>>>>>>>>>>>>>>>>>>>>>>>>
train 36600
val 5079
test 10348
iters: 100, epoch: 1 | loss: 0.5949332
speed: 0.0736s/iter; left time: 412.3825s
iters: 200, epoch: 1 | loss: 0.6008663
speed: 0.0653s/iter; left time: 359.0430s
Epoch: 1 cost time: 19.023356199264526
Epoch: 1, Steps: 285 | Train Loss: 0.6265348 Vali Loss: 0.5050493 Test Loss: 0.2290545
Validation loss decreased (inf --> 0.505049).  Saving model ...
Updating learning rate to 0.0018082286694699988
iters: 100, epoch: 2 | loss: 0.4368003
speed: 0.1606s/iter; left time: 853.6822s
iters: 200, epoch: 2 | loss: 0.6394349
speed: 0.0654s/iter; left time: 341.2403s
Epoch: 2 cost time: 18.83457350730896
Epoch: 2, Steps: 285 | Train Loss: 0.5097023 Vali Loss: 0.5010504 Test Loss: 0.2251554
Validation loss decreased (0.505049 --> 0.501050).  Saving model ...
Updating learning rate to 0.005206619683914479
iters: 100, epoch: 3 | loss: 0.5027322
speed: 0.1605s/iter; left time: 807.3658s
iters: 200, epoch: 3 | loss: 0.5735677
speed: 0.0655s/iter; left time: 322.8571s
Epoch: 3 cost time: 18.84622883796692
Epoch: 3, Steps: 285 | Train Loss: 0.4948312 Vali Loss: 0.4692470 Test Loss: 0.2095508
Validation loss decreased (0.501050 --> 0.469247).  Saving model ...
Updating learning rate to 0.008601126519745959
iters: 100, epoch: 4 | loss: 0.7092599
speed: 0.1600s/iter; left time: 759.4899s
iters: 200, epoch: 4 | loss: 0.3938503
speed: 0.0655s/iter; left time: 304.3535s
Epoch: 4 cost time: 18.848021268844604
Epoch: 4, Steps: 285 | Train Loss: 0.4878404 Vali Loss: 0.4703723 Test Loss: 0.2100072
EarlyStopping counter: 1 out of 10
Updating learning rate to 0.009999998813389152
iters: 100, epoch: 5 | loss: 0.4158416
speed: 0.1604s/iter; left time: 715.7460s
iters: 200, epoch: 5 | loss: 0.4023744
speed: 0.0654s/iter; left time: 285.3155s
Epoch: 5 cost time: 18.826069593429565
Epoch: 5, Steps: 285 | Train Loss: 0.4828563 Vali Loss: 0.4683839 Test Loss: 0.2124947
Validation loss decreased (0.469247 --> 0.468384).  Saving model ...
Updating learning rate to 0.009903253591993106
iters: 100, epoch: 6 | loss: 0.4359638
speed: 0.1606s/iter; left time: 670.6529s
iters: 200, epoch: 6 | loss: 0.5145217
speed: 0.0655s/iter; left time: 266.8324s
Epoch: 6 cost time: 18.856943607330322
Epoch: 6, Steps: 285 | Train Loss: 0.4796506 Vali Loss: 0.4690022 Test Loss: 0.2101424
EarlyStopping counter: 1 out of 10
Updating learning rate to 0.009618079853421842
iters: 100, epoch: 7 | loss: 0.5960991
speed: 0.1601s/iter; left time: 623.0693s
iters: 200, epoch: 7 | loss: 0.6308466
speed: 0.0655s/iter; left time: 248.4005s
Epoch: 7 cost time: 18.844536066055298
Epoch: 7, Steps: 285 | Train Loss: 0.4764077 Vali Loss: 0.4654915 Test Loss: 0.2081809
Validation loss decreased (0.468384 --> 0.465492).  Saving model ...
Updating learning rate to 0.009155436664521378
iters: 100, epoch: 8 | loss: 0.4419442
speed: 0.1602s/iter; left time: 577.6258s
iters: 200, epoch: 8 | loss: 0.5641533
speed: 0.0654s/iter; left time: 229.2836s
Epoch: 8 cost time: 18.828977584838867
Epoch: 8, Steps: 285 | Train Loss: 0.4711395 Vali Loss: 0.4669213 Test Loss: 0.2122254
EarlyStopping counter: 1 out of 10
Updating learning rate to 0.008533103143587874
iters: 100, epoch: 9 | loss: 0.3767900
speed: 0.1602s/iter; left time: 531.9960s
iters: 200, epoch: 9 | loss: 0.4241773
speed: 0.0655s/iter; left time: 210.8604s
Epoch: 9 cost time: 18.84018850326538
Epoch: 9, Steps: 285 | Train Loss: 0.4696788 Vali Loss: 0.4655947 Test Loss: 0.2091171
EarlyStopping counter: 2 out of 10
Updating learning rate to 0.007774995218822139
iters: 100, epoch: 10 | loss: 0.3299536
speed: 0.1606s/iter; left time: 487.4349s
iters: 200, epoch: 10 | loss: 0.4966879
speed: 0.0654s/iter; left time: 192.1428s
Epoch: 10 cost time: 18.850160121917725
Epoch: 10, Steps: 285 | Train Loss: 0.4663261 Vali Loss: 0.4718109 Test Loss: 0.2086317
EarlyStopping counter: 3 out of 10
Updating learning rate to 0.006910246552621103
iters: 100, epoch: 11 | loss: 0.3497610
speed: 0.1603s/iter; left time: 441.0321s
iters: 200, epoch: 11 | loss: 0.3784502
speed: 0.0655s/iter; left time: 173.7020s
Epoch: 11 cost time: 18.853699684143066
Epoch: 11, Steps: 285 | Train Loss: 0.4630501 Vali Loss: 0.4703967 Test Loss: 0.2108531
EarlyStopping counter: 4 out of 10
Updating learning rate to 0.005972088951270229
iters: 100, epoch: 12 | loss: 0.3815632
speed: 0.1602s/iter; left time: 395.0873s
iters: 200, epoch: 12 | loss: 0.4500147
speed: 0.0656s/iter; left time: 155.1679s
Epoch: 12 cost time: 18.86597967147827
Epoch: 12, Steps: 285 | Train Loss: 0.4593053 Vali Loss: 0.4724175 Test Loss: 0.2148597
EarlyStopping counter: 5 out of 10
Updating learning rate to 0.004996575285264588
iters: 100, epoch: 13 | loss: 0.3511541
speed: 0.1607s/iter; left time: 350.4397s
iters: 200, epoch: 13 | loss: 0.3464415
speed: 0.0656s/iter; left time: 136.5284s
Epoch: 13 cost time: 18.88262128829956
Epoch: 13, Steps: 285 | Train Loss: 0.4552088 Vali Loss: 0.4763499 Test Loss: 0.2151347
EarlyStopping counter: 6 out of 10
Updating learning rate to 0.004021193997714411
iters: 100, epoch: 14 | loss: 0.5604454
speed: 0.1611s/iter; left time: 305.4688s
iters: 200, epoch: 14 | loss: 0.3495321
speed: 0.0656s/iter; left time: 117.8210s
Epoch: 14 cost time: 18.897520542144775
Epoch: 14, Steps: 285 | Train Loss: 0.4506181 Vali Loss: 0.4754393 Test Loss: 0.2156542
EarlyStopping counter: 7 out of 10
Updating learning rate to 0.003083428444500124
iters: 100, epoch: 15 | loss: 0.4728407
speed: 0.1609s/iter; left time: 259.2434s
iters: 200, epoch: 15 | loss: 0.3594473
speed: 0.0655s/iter; left time: 98.9966s
Epoch: 15 cost time: 18.869282245635986
Epoch: 15, Steps: 285 | Train Loss: 0.4469513 Vali Loss: 0.4774691 Test Loss: 0.2158166
EarlyStopping counter: 8 out of 10
Updating learning rate to 0.002219316429926769
iters: 100, epoch: 16 | loss: 0.5374044
speed: 0.1606s/iter; left time: 212.9617s
iters: 200, epoch: 16 | loss: 0.3515621
speed: 0.0655s/iter; left time: 80.3071s
Epoch: 16 cost time: 18.862897157669067
Epoch: 16, Steps: 285 | Train Loss: 0.4417733 Vali Loss: 0.4801658 Test Loss: 0.2175966
EarlyStopping counter: 9 out of 10
Updating learning rate to 0.0014620652941147994
iters: 100, epoch: 17 | loss: 0.4957572
speed: 0.1602s/iter; left time: 166.7883s
iters: 200, epoch: 17 | loss: 0.4278955
speed: 0.0655s/iter; left time: 61.6600s
Epoch: 17 cost time: 18.845292806625366
Epoch: 17, Steps: 285 | Train Loss: 0.4374476 Vali Loss: 0.4815650 Test Loss: 0.2188107
EarlyStopping counter: 10 out of 10
Early stopping
testing : long_term_forecast_weather_96_192_none_TimeMixer_custom_sl96_pl192_dm16_nh4_el3_dl1_df32_fc3_ebtimeF_dtTrue_Exp_0<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
test 10348
test shape: (80, 128, 192, 21) (80, 128, 192, 21)
test shape: (10240, 192, 21) (10240, 192, 21)
mse:0.2081807404756546, mae:0.2515397369861603
rmse:0.4562682807445526, mape:0.5633121132850647, mspe:25455112.0
Args in experiment:
Namespace(task_name='long_term_forecast', is_training=1, model_id='weather_96_336', model='TimeMixer', data='custom', root_path='./dataset/weather/', data_path='weather.csv', features='M', target='OT', freq='h', checkpoints='./checkpoints/', seq_len=96, label_len=0, pred_len=336, seasonal_patterns='Monthly', inverse=False, top_k=5, num_kernels=6, enc_in=21, dec_in=21, c_out=21, d_model=16, n_heads=4, e_layers=3, d_layers=1, d_ff=32, moving_avg=25, factor=3, distil=True, dropout=0.1, embed='timeF', activation='gelu', output_attention=False, channel_independence=1, decomp_method='moving_avg', use_norm=1, down_sampling_layers=3, down_sampling_window=2, down_sampling_method='avg', num_workers=10, itr=1, train_epochs=20, batch_size=128, patience=10, learning_rate=0.01, des='Exp', loss='MSE', lradj='TST', pct_start=0.2, use_amp=False, comment='none', use_gpu=True, gpu=0, use_multi_gpu=False, devices='0,1', p_hidden_dims=[128, 128], p_hidden_layers=2)
Use GPU: cuda:0
start training : long_term_forecast_weather_96_336_none_TimeMixer_custom_sl96_pl336_dm16_nh4_el3_dl1_df32_fc3_ebtimeF_dtTrue_Exp_0>>>>>>>>>>>>>>>>>>>>>>>>>>
train 36456
val 4935
test 10204
iters: 100, epoch: 1 | loss: 0.6762619
speed: 0.0802s/iter; left time: 447.6532s
iters: 200, epoch: 1 | loss: 0.7450211
speed: 0.0717s/iter; left time: 392.8241s
Epoch: 1 cost time: 20.772141218185425
Epoch: 1, Steps: 284 | Train Loss: 0.7176838 Vali Loss: 0.6182648 Test Loss: 0.2868061
Validation loss decreased (inf --> 0.618265).  Saving model ...
Updating learning rate to 0.00180823692331512
iters: 100, epoch: 2 | loss: 0.6044372
speed: 0.1747s/iter; left time: 925.1899s
iters: 200, epoch: 2 | loss: 0.5523940
speed: 0.0717s/iter; left time: 372.3988s
Epoch: 2 cost time: 20.55257225036621
Epoch: 2, Steps: 284 | Train Loss: 0.5827757 Vali Loss: 0.5536075 Test Loss: 0.2660022
Validation loss decreased (0.618265 --> 0.553607).  Saving model ...
Updating learning rate to 0.005206643013182129
iters: 100, epoch: 3 | loss: 0.5766494
speed: 0.1750s/iter; left time: 877.4838s
iters: 200, epoch: 3 | loss: 0.5486959
speed: 0.0716s/iter; left time: 351.8329s
Epoch: 3 cost time: 20.537157773971558
Epoch: 3, Steps: 284 | Train Loss: 0.5633632 Vali Loss: 0.5502650 Test Loss: 0.2656547
Validation loss decreased (0.553607 --> 0.550265).  Saving model ...
Updating learning rate to 0.008601151212863664
iters: 100, epoch: 4 | loss: 0.6538562
speed: 0.1747s/iter; left time: 826.1667s
iters: 200, epoch: 4 | loss: 0.6420984
speed: 0.0717s/iter; left time: 331.7201s
Epoch: 4 cost time: 20.538926124572754
Epoch: 4, Steps: 284 | Train Loss: 0.5586641 Vali Loss: 0.5445257 Test Loss: 0.2642392
Validation loss decreased (0.550265 --> 0.544526).  Saving model ...
Updating learning rate to 0.009999998805018026
iters: 100, epoch: 5 | loss: 0.5255791
speed: 0.1752s/iter; left time: 778.9302s
iters: 200, epoch: 5 | loss: 0.5437405
speed: 0.0717s/iter; left time: 311.3697s
Epoch: 5 cost time: 20.580398559570312
Epoch: 5, Steps: 284 | Train Loss: 0.5525623 Vali Loss: 0.5473270 Test Loss: 0.2656774
EarlyStopping counter: 1 out of 10
Updating learning rate to 0.009903251217478603
iters: 100, epoch: 6 | loss: 0.5712382
speed: 0.1752s/iter; left time: 729.1598s
iters: 200, epoch: 6 | loss: 0.5956228
speed: 0.0718s/iter; left time: 291.4277s
Epoch: 6 cost time: 20.575769901275635
Epoch: 6, Steps: 284 | Train Loss: 0.5469062 Vali Loss: 0.5537988 Test Loss: 0.2652604
EarlyStopping counter: 2 out of 10
Updating learning rate to 0.009618075204015223
iters: 100, epoch: 7 | loss: 0.6023598
speed: 0.1744s/iter; left time: 675.9986s
iters: 200, epoch: 7 | loss: 0.6505283
speed: 0.0717s/iter; left time: 270.8363s
Epoch: 7 cost time: 20.550930738449097
Epoch: 7, Steps: 284 | Train Loss: 0.5425374 Vali Loss: 0.5475795 Test Loss: 0.2653736
EarlyStopping counter: 3 out of 10
Updating learning rate to 0.009155429918896733
iters: 100, epoch: 8 | loss: 0.4873362
speed: 0.1751s/iter; left time: 628.9643s
iters: 200, epoch: 8 | loss: 0.5438763
speed: 0.0717s/iter; left time: 250.5183s
Epoch: 8 cost time: 20.549409866333008
Epoch: 8, Steps: 284 | Train Loss: 0.5379630 Vali Loss: 0.5472488 Test Loss: 0.2629513
EarlyStopping counter: 4 out of 10
Updating learning rate to 0.008533094560975773
iters: 100, epoch: 9 | loss: 0.4517022
speed: 0.1747s/iter; left time: 578.2332s
iters: 200, epoch: 9 | loss: 0.4840907
speed: 0.0718s/iter; left time: 230.2531s
Epoch: 9 cost time: 20.570077657699585
Epoch: 9, Steps: 284 | Train Loss: 0.5332942 Vali Loss: 0.5556108 Test Loss: 0.2662907
EarlyStopping counter: 5 out of 10
Updating learning rate to 0.007774985129047554
iters: 100, epoch: 10 | loss: 0.4708846
speed: 0.1747s/iter; left time: 528.4759s
iters: 200, epoch: 10 | loss: 0.5694571
speed: 0.0718s/iter; left time: 209.9871s
Epoch: 10 cost time: 20.54496145248413
Epoch: 10, Steps: 284 | Train Loss: 0.5300522 Vali Loss: 0.5519323 Test Loss: 0.2673647
EarlyStopping counter: 6 out of 10
Updating learning rate to 0.00691023534342841
iters: 100, epoch: 11 | loss: 0.5525529
speed: 0.1752s/iter; left time: 480.2941s
iters: 200, epoch: 11 | loss: 0.5092630
speed: 0.0717s/iter; left time: 189.4442s
Epoch: 11 cost time: 20.616445064544678
Epoch: 11, Steps: 284 | Train Loss: 0.5261522 Vali Loss: 0.5618097 Test Loss: 0.2690014
EarlyStopping counter: 7 out of 10
Updating learning rate to 0.0059720770534224185
iters: 100, epoch: 12 | loss: 0.5237783
speed: 0.1754s/iter; left time: 431.0713s
iters: 200, epoch: 12 | loss: 0.5110543
speed: 0.0719s/iter; left time: 169.5107s
Epoch: 12 cost time: 20.627060413360596
Epoch: 12, Steps: 284 | Train Loss: 0.5216495 Vali Loss: 0.5661159 Test Loss: 0.2704441
EarlyStopping counter: 8 out of 10
Updating learning rate to 0.0049965631559892795
iters: 100, epoch: 13 | loss: 0.4331133
speed: 0.1759s/iter; left time: 382.2790s
iters: 200, epoch: 13 | loss: 0.4477478
speed: 0.0718s/iter; left time: 148.9245s
Epoch: 13 cost time: 20.607174396514893
Epoch: 13, Steps: 284 | Train Loss: 0.5160140 Vali Loss: 0.5630207 Test Loss: 0.2732388
EarlyStopping counter: 9 out of 10
Updating learning rate to 0.004021182103132853
iters: 100, epoch: 14 | loss: 0.4574574
speed: 0.1752s/iter; left time: 331.0030s
iters: 200, epoch: 14 | loss: 0.5201182
speed: 0.0718s/iter; left time: 128.4090s
Epoch: 14 cost time: 20.578966856002808
Epoch: 14, Steps: 284 | Train Loss: 0.5108669 Vali Loss: 0.5685348 Test Loss: 0.2741197
EarlyStopping counter: 10 out of 10
Early stopping
testing : long_term_forecast_weather_96_336_none_TimeMixer_custom_sl96_pl336_dm16_nh4_el3_dl1_df32_fc3_ebtimeF_dtTrue_Exp_0<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
test 10204
test shape: (79, 128, 336, 21) (79, 128, 336, 21)
test shape: (10112, 336, 21) (10112, 336, 21)
mse:0.2642389237880707, mae:0.29182228446006775
rmse:0.5140417814254761, mape:0.6117508411407471, mspe:22384474.0
Args in experiment:
Namespace(task_name='long_term_forecast', is_training=1, model_id='weather_96_720', model='TimeMixer', data='custom', root_path='./dataset/weather/', data_path='weather.csv', features='M', target='OT', freq='h', checkpoints='./checkpoints/', seq_len=96, label_len=0, pred_len=720, seasonal_patterns='Monthly', inverse=False, top_k=5, num_kernels=6, enc_in=21, dec_in=21, c_out=21, d_model=16, n_heads=4, e_layers=3, d_layers=1, d_ff=32, moving_avg=25, factor=3, distil=True, dropout=0.1, embed='timeF', activation='gelu', output_attention=False, channel_independence=1, decomp_method='moving_avg', use_norm=1, down_sampling_layers=3, down_sampling_window=2, down_sampling_method='avg', num_workers=10, itr=1, train_epochs=20, batch_size=128, patience=10, learning_rate=0.01, des='Exp', loss='MSE', lradj='TST', pct_start=0.2, use_amp=False, comment='none', use_gpu=True, gpu=0, use_multi_gpu=False, devices='0,1', p_hidden_dims=[128, 128], p_hidden_layers=2)
Use GPU: cuda:0
start training : long_term_forecast_weather_96_720_none_TimeMixer_custom_sl96_pl720_dm16_nh4_el3_dl1_df32_fc3_ebtimeF_dtTrue_Exp_0>>>>>>>>>>>>>>>>>>>>>>>>>>
train 36072
val 4551
test 9820
iters: 100, epoch: 1 | loss: 0.8142495
speed: 0.0949s/iter; left time: 524.2079s
iters: 200, epoch: 1 | loss: 0.6766396
speed: 0.0866s/iter; left time: 469.3050s
Epoch: 1 cost time: 24.730847358703613
Epoch: 1, Steps: 281 | Train Loss: 0.8068021 Vali Loss: 0.7239532 Test Loss: 0.3527675
Validation loss decreased (inf --> 0.723953).  Saving model ...
Updating learning rate to 0.001808262037764916
iters: 100, epoch: 2 | loss: 0.6173640
speed: 0.2044s/iter; left time: 1071.2935s
iters: 200, epoch: 2 | loss: 0.6137844
speed: 0.0867s/iter; left time: 445.8729s
Epoch: 2 cost time: 24.55042862892151
Epoch: 2, Steps: 281 | Train Loss: 0.6680108 Vali Loss: 0.6862536 Test Loss: 0.3416217
Validation loss decreased (0.723953 --> 0.686254).  Saving model ...
Updating learning rate to 0.005206713998138916
iters: 100, epoch: 3 | loss: 0.6730509
speed: 0.2076s/iter; left time: 1029.5066s
iters: 200, epoch: 3 | loss: 0.6434111
speed: 0.0866s/iter; left time: 420.6864s
Epoch: 3 cost time: 24.582441329956055
Epoch: 3, Steps: 281 | Train Loss: 0.6507671 Vali Loss: 0.6802924 Test Loss: 0.3408227
Validation loss decreased (0.686254 --> 0.680292).  Saving model ...
Updating learning rate to 0.008601226346554308
iters: 100, epoch: 4 | loss: 0.7849593
speed: 0.2058s/iter; left time: 962.6568s
iters: 200, epoch: 4 | loss: 0.6803224
speed: 0.0878s/iter; left time: 401.9479s
Epoch: 4 cost time: 24.905867099761963
Epoch: 4, Steps: 281 | Train Loss: 0.6441614 Vali Loss: 0.6722143 Test Loss: 0.3388726
Validation loss decreased (0.680292 --> 0.672214).  Saving model ...
Updating learning rate to 0.009999998779366193
iters: 100, epoch: 5 | loss: 0.6364537
speed: 0.2161s/iter; left time: 950.2600s
iters: 200, epoch: 5 | loss: 0.6571795
speed: 0.0883s/iter; left time: 379.2287s
Epoch: 5 cost time: 25.106192588806152
Epoch: 5, Steps: 281 | Train Loss: 0.6346934 Vali Loss: 0.6763712 Test Loss: 0.3437357
EarlyStopping counter: 1 out of 10
Updating learning rate to 0.009903243992354873
iters: 100, epoch: 6 | loss: 0.6608462
speed: 0.2095s/iter; left time: 862.1168s
iters: 200, epoch: 6 | loss: 0.5328134
speed: 0.0879s/iter; left time: 352.8371s
Epoch: 6 cost time: 24.89567756652832
Epoch: 6, Steps: 281 | Train Loss: 0.6301392 Vali Loss: 0.6720090 Test Loss: 0.3452646
Validation loss decreased (0.672214 --> 0.672009).  Saving model ...
Updating learning rate to 0.009618061057077049
iters: 100, epoch: 7 | loss: 0.5821897
speed: 0.2097s/iter; left time: 804.1047s
iters: 200, epoch: 7 | loss: 0.6629183
speed: 0.0870s/iter; left time: 324.9126s
Epoch: 7 cost time: 24.728896141052246
Epoch: 7, Steps: 281 | Train Loss: 0.6234477 Vali Loss: 0.6766704 Test Loss: 0.3424388
EarlyStopping counter: 1 out of 10
Updating learning rate to 0.009155409393803014
iters: 100, epoch: 8 | loss: 0.6022717
speed: 0.2096s/iter; left time: 745.0661s
iters: 200, epoch: 8 | loss: 0.6708240
speed: 0.0878s/iter; left time: 303.3604s
Epoch: 8 cost time: 24.855897903442383
Epoch: 8, Steps: 281 | Train Loss: 0.6200137 Vali Loss: 0.6743950 Test Loss: 0.3449188
EarlyStopping counter: 2 out of 10
Updating learning rate to 0.008533068446494351
iters: 100, epoch: 9 | loss: 0.6271792
speed: 0.2133s/iter; left time: 698.0489s
iters: 200, epoch: 9 | loss: 0.5900708
speed: 0.0876s/iter; left time: 277.9912s
Epoch: 9 cost time: 24.90035605430603
Epoch: 9, Steps: 281 | Train Loss: 0.6172251 Vali Loss: 0.6732223 Test Loss: 0.3422192
EarlyStopping counter: 3 out of 10
Updating learning rate to 0.0077749544287433045
iters: 100, epoch: 10 | loss: 0.6388667
speed: 0.2089s/iter; left time: 625.1309s
iters: 200, epoch: 10 | loss: 0.5596918
speed: 0.0877s/iter; left time: 253.6024s
Epoch: 10 cost time: 24.834704160690308
Epoch: 10, Steps: 281 | Train Loss: 0.6112832 Vali Loss: 0.6812492 Test Loss: 0.3471961
EarlyStopping counter: 4 out of 10
Updating learning rate to 0.006910201237096809
iters: 100, epoch: 11 | loss: 0.6107982
speed: 0.2092s/iter; left time: 567.1717s
iters: 200, epoch: 11 | loss: 0.7271204
speed: 0.0874s/iter; left time: 228.1348s
Epoch: 11 cost time: 24.82628321647644
Epoch: 11, Steps: 281 | Train Loss: 0.6062498 Vali Loss: 0.6967529 Test Loss: 0.3520924
EarlyStopping counter: 5 out of 10
Updating learning rate to 0.005972040851750663
iters: 100, epoch: 12 | loss: 0.5930983
speed: 0.2091s/iter; left time: 508.2303s
iters: 200, epoch: 12 | loss: 0.5886881
speed: 0.0874s/iter; left time: 203.6228s
Epoch: 12 cost time: 24.776528120040894
Epoch: 12, Steps: 281 | Train Loss: 0.6009362 Vali Loss: 0.6849611 Test Loss: 0.3488447
EarlyStopping counter: 6 out of 10
Updating learning rate to 0.00499652625018731
iters: 100, epoch: 13 | loss: 0.5866392
speed: 0.2081s/iter; left time: 447.2292s
iters: 200, epoch: 13 | loss: 0.5042546
speed: 0.0875s/iter; left time: 179.2445s
Epoch: 13 cost time: 24.757347345352173
Epoch: 13, Steps: 281 | Train Loss: 0.5950525 Vali Loss: 0.7007942 Test Loss: 0.3564042
EarlyStopping counter: 7 out of 10
Updating learning rate to 0.004021145911469944
iters: 100, epoch: 14 | loss: 0.5368530
speed: 0.2076s/iter; left time: 387.8565s
iters: 200, epoch: 14 | loss: 0.6062331
speed: 0.0877s/iter; left time: 155.0381s
Epoch: 14 cost time: 24.7646701335907
Epoch: 14, Steps: 281 | Train Loss: 0.5889814 Vali Loss: 0.7063530 Test Loss: 0.3574873
EarlyStopping counter: 8 out of 10
Updating learning rate to 0.0030833831550158746
iters: 100, epoch: 15 | loss: 0.4924599
speed: 0.2067s/iter; left time: 328.1095s
iters: 200, epoch: 15 | loss: 0.5690606
speed: 0.0870s/iter; left time: 129.3131s
Epoch: 15 cost time: 24.61445379257202
Epoch: 15, Steps: 281 | Train Loss: 0.5833323 Vali Loss: 0.6996056 Test Loss: 0.3548250
EarlyStopping counter: 9 out of 10
Updating learning rate to 0.0022192756776522196
iters: 100, epoch: 16 | loss: 0.5421556
speed: 0.2064s/iter; left time: 269.5861s
iters: 200, epoch: 16 | loss: 0.4972541
speed: 0.0871s/iter; left time: 105.0962s
Epoch: 16 cost time: 24.679931163787842
Epoch: 16, Steps: 281 | Train Loss: 0.5771793 Vali Loss: 0.7160063 Test Loss: 0.3596286
EarlyStopping counter: 10 out of 10
Early stopping
testing : long_term_forecast_weather_96_720_none_TimeMixer_custom_sl96_pl720_dm16_nh4_el3_dl1_df32_fc3_ebtimeF_dtTrue_Exp_0<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
test 9820
test shape: (76, 128, 720, 21) (76, 128, 720, 21)
test shape: (9728, 720, 21) (9728, 720, 21)
mse:0.345264196395874, mae:0.3470550775527954
rmse:0.5875918865203857, mape:0.677718460559845, mspe:23126632.0

Hi, I have conducted tests using both CPU and GPU and have encountered the loss explosion issue you mentioned. May I ask what versions of Python, torch, and CUDA you are using, as well as the specific GPU? This could be related to your runtime environment. Below is the log from my recent test using an A100：
Use GPU: cuda:0

start training : long_term_forecast_weather_96_96_TimeMixer_custom_ftM_sl96_ll0_pl96_dm16_nh8_el3_dl1_df32_fc3_ebtimeF_dtTrue_Exp_0>>>>>>>>>>>>>>>>>>>>>>>>>>
train 36696
val 5175
test 10444
iters: 100, epoch: 1 | loss: 0.3753206
speed: 0.1125s/iter; left time: 632.6095s
iters: 200, epoch: 1 | loss: 0.3650213
speed: 0.0963s/iter; left time: 531.6102s
Epoch: 1 cost time: 29.084431648254395
Epoch: 1, Steps: 286 | Train Loss: 0.4559769 Vali Loss: 0.4045496 Test Loss: 0.1651619
Validation loss decreased (inf --> 0.404550).  Saving model ...
Updating learning rate to 0.01
iters: 100, epoch: 2 | loss: 0.3403140
speed: 1.5760s/iter; left time: 8407.9784s
iters: 200, epoch: 2 | loss: 0.3347130
speed: 0.0959s/iter; left time: 501.9730s
Epoch: 2 cost time: 28.343204021453857
Epoch: 2, Steps: 286 | Train Loss: 0.4250036 Vali Loss: 0.4022082 Test Loss: 0.1644919
Validation loss decreased (0.404550 --> 0.402208).  Saving model ...
Updating learning rate to 0.005
iters: 100, epoch: 3 | loss: 0.3028832
speed: 1.5435s/iter; left time: 7792.9897s
iters: 200, epoch: 3 | loss: 0.3556193
speed: 0.0947s/iter; left time: 468.4591s
Epoch: 3 cost time: 27.956741094589233
Epoch: 3, Steps: 286 | Train Loss: 0.4147728 Vali Loss: 0.3992365 Test Loss: 0.1646327
Validation loss decreased (0.402208 --> 0.399237).  Saving model ...
Updating learning rate to 0.0025
iters: 100, epoch: 4 | loss: 0.3041284
speed: 1.5765s/iter; left time: 7509.0167s
iters: 200, epoch: 4 | loss: 0.4556009
speed: 0.0955s/iter; left time: 445.4644s
Epoch: 4 cost time: 28.11586308479309
Epoch: 4, Steps: 286 | Train Loss: 0.4078718 Vali Loss: 0.3988088 Test Loss: 0.1617702
Validation loss decreased (0.399237 --> 0.398809).  Saving model ...
Updating learning rate to 0.00125
iters: 100, epoch: 5 | loss: 0.2949091
speed: 1.5833s/iter; left time: 7088.2278s
iters: 200, epoch: 5 | loss: 0.5099045
speed: 0.0949s/iter; left time: 415.2986s
Epoch: 5 cost time: 28.256697416305542
Epoch: 5, Steps: 286 | Train Loss: 0.4033931 Vali Loss: 0.3990721 Test Loss: 0.1609277
EarlyStopping counter: 1 out of 10
Updating learning rate to 0.000625
iters: 100, epoch: 6 | loss: 0.3733408
speed: 1.5490s/iter; left time: 6491.8874s
iters: 200, epoch: 6 | loss: 0.3319999
speed: 0.0925s/iter; left time: 378.4997s
Epoch: 6 cost time: 27.6805522441864
source /opt/conda/bin/activate
conda activate base
Epoch: 6, Steps: 286 | Train Loss: 0.4002498 Vali Loss: 0.4013985 Test Loss: 0.1616626
EarlyStopping counter: 2 out of 10
Updating learning rate to 0.0003125
iters: 100, epoch: 7 | loss: 0.6016151
speed: 1.5663s/iter; left time: 6116.3414s
iters: 200, epoch: 7 | loss: 0.4443198
speed: 0.0929s/iter; left time: 353.2984s
Epoch: 7 cost time: 27.468426942825317
Epoch: 7, Steps: 286 | Train Loss: 0.3996443 Vali Loss: 0.3977090 Test Loss: 0.1613210
Validation loss decreased (0.398809 --> 0.397709).  Saving model ...
Updating learning rate to 0.00015625
iters: 100, epoch: 8 | loss: 0.3081976
speed: 1.5743s/iter; left time: 5697.4836s
iters: 200, epoch: 8 | loss: 0.3726347
speed: 0.0954s/iter; left time: 335.6610s
Epoch: 8 cost time: 27.83885407447815
Epoch: 8, Steps: 286 | Train Loss: 0.3982672 Vali Loss: 0.3980305 Test Loss: 0.1620593
EarlyStopping counter: 1 out of 10
Updating learning rate to 7.8125e-05
iters: 100, epoch: 9 | loss: 0.5365641
speed: 1.5665s/iter; left time: 5221.0898s
iters: 200, epoch: 9 | loss: 0.3724343
speed: 0.0960s/iter; left time: 310.3874s
Epoch: 9 cost time: 28.19004225730896
Epoch: 9, Steps: 286 | Train Loss: 0.3979731 Vali Loss: 0.3968561 Test Loss: 0.1611742
Validation loss decreased (0.397709 --> 0.396856).  Saving model ...
Updating learning rate to 3.90625e-05
iters: 100, epoch: 10 | loss: 0.4671008
speed: 1.5777s/iter; left time: 4807.3249s
iters: 200, epoch: 10 | loss: 0.3070258
speed: 0.0971s/iter; left time: 286.0706s
Epoch: 10 cost time: 28.16199278831482
Epoch: 10, Steps: 286 | Train Loss: 0.3965665 Vali Loss: 0.3990801 Test Loss: 0.1615544
EarlyStopping counter: 1 out of 10
Updating learning rate to 1.953125e-05
iters: 100, epoch: 11 | loss: 0.6498543
speed: 1.5710s/iter; left time: 4337.5387s
iters: 200, epoch: 11 | loss: 0.3345088
speed: 0.0938s/iter; left time: 249.5560s
Epoch: 11 cost time: 27.815724849700928
Epoch: 11, Steps: 286 | Train Loss: 0.3976659 Vali Loss: 0.4000468 Test Loss: 0.1616991
EarlyStopping counter: 2 out of 10
Updating learning rate to 9.765625e-06
iters: 100, epoch: 12 | loss: 0.4381566
speed: 1.5728s/iter; left time: 3892.6526s
iters: 200, epoch: 12 | loss: 0.5621059
speed: 0.0973s/iter; left time: 231.0085s
Epoch: 12 cost time: 28.15647864341736
Epoch: 12, Steps: 286 | Train Loss: 0.3960074 Vali Loss: 0.3980559 Test Loss: 0.1616852
EarlyStopping counter: 3 out of 10
Updating learning rate to 4.8828125e-06
iters: 100, epoch: 13 | loss: 0.2753164
speed: 1.5826s/iter; left time: 3464.3073s
iters: 200, epoch: 13 | loss: 0.6397113
speed: 0.0956s/iter; left time: 199.7189s
Epoch: 13 cost time: 28.209867477416992
Epoch: 13, Steps: 286 | Train Loss: 0.3974377 Vali Loss: 0.3994200 Test Loss: 0.1616747
EarlyStopping counter: 4 out of 10
Updating learning rate to 2.44140625e-06
iters: 100, epoch: 14 | loss: 0.5507306
speed: 1.5722s/iter; left time: 2991.8295s
iters: 200, epoch: 14 | loss: 0.2794026
speed: 0.0942s/iter; left time: 169.7589s
Epoch: 14 cost time: 27.93237328529358
Epoch: 14, Steps: 286 | Train Loss: 0.3971617 Vali Loss: 0.3962648 Test Loss: 0.1616808
Validation loss decreased (0.396856 --> 0.396265).  Saving model ...
Updating learning rate to 1.220703125e-06
iters: 100, epoch: 15 | loss: 0.2362812
speed: 1.5702s/iter; left time: 2539.0405s
iters: 200, epoch: 15 | loss: 0.5210038
speed: 0.0952s/iter; left time: 144.4564s
Epoch: 15 cost time: 27.919300079345703
Epoch: 15, Steps: 286 | Train Loss: 0.3972344 Vali Loss: 0.3991646 Test Loss: 0.1616832
EarlyStopping counter: 1 out of 10
Updating learning rate to 6.103515625e-07
iters: 100, epoch: 16 | loss: 0.2441869
speed: 1.5644s/iter; left time: 2082.2781s
iters: 200, epoch: 16 | loss: 0.3173642
speed: 0.0947s/iter; left time: 116.5348s
Epoch: 16 cost time: 28.07013177871704
source /opt/conda/bin/activate
conda activate base
Epoch: 16, Steps: 286 | Train Loss: 0.3973130 Vali Loss: 0.3976985 Test Loss: 0.1616816
EarlyStopping counter: 2 out of 10
Updating learning rate to 3.0517578125e-07
iters: 100, epoch: 17 | loss: 0.8181573
speed: 1.5765s/iter; left time: 1647.4591s
iters: 200, epoch: 17 | loss: 0.3754889
speed: 0.0966s/iter; left time: 91.3173s
Epoch: 17 cost time: 27.89303421974182
Epoch: 17, Steps: 286 | Train Loss: 0.3973716 Vali Loss: 0.3948824 Test Loss: 0.1616797
Validation loss decreased (0.396265 --> 0.394882).  Saving model ...
Updating learning rate to 1.52587890625e-07
iters: 100, epoch: 18 | loss: 0.2578862
speed: 1.5766s/iter; left time: 1196.6736s
iters: 200, epoch: 18 | loss: 0.3357456
speed: 0.0962s/iter; left time: 63.4233s
Epoch: 18 cost time: 27.98421311378479
Epoch: 18, Steps: 286 | Train Loss: 0.3964639 Vali Loss: 0.3991940 Test Loss: 0.1616804
EarlyStopping counter: 1 out of 10
Updating learning rate to 7.62939453125e-08
iters: 100, epoch: 19 | loss: 0.3234898
speed: 1.5751s/iter; left time: 745.0206s
iters: 200, epoch: 19 | loss: 0.2907747
speed: 0.0969s/iter; left time: 36.1467s
Epoch: 19 cost time: 28.47565507888794
Epoch: 19, Steps: 286 | Train Loss: 0.3972313 Vali Loss: 0.3985853 Test Loss: 0.1616802
EarlyStopping counter: 2 out of 10
Updating learning rate to 3.814697265625e-08
iters: 100, epoch: 20 | loss: 0.6489332
speed: 1.5610s/iter; left time: 291.9142s
iters: 200, epoch: 20 | loss: 0.3143170
speed: 0.0941s/iter; left time: 8.1840s
Epoch: 20 cost time: 27.963088274002075
Epoch: 20, Steps: 286 | Train Loss: 0.3974204 Vali Loss: 0.3994423 Test Loss: 0.1616799
EarlyStopping counter: 3 out of 10
Updating learning rate to 1.9073486328125e-08
testing : long_term_forecast_weather_96_96_TimeMixer_custom_ftM_sl96_ll0_pl96_dm16_nh8_el3_dl1_df32_fc3_ebtimeF_dtTrue_Exp_0<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
test 10444
test shape: (10444, 1, 96, 21) (10444, 1, 96, 21)
test shape: (10444, 96, 21) (10444, 96, 21)
mse:0.16167980432510376, mae:0.20934458076953888

Could you please print all your hyper parameters? Thanks

Could you please print all your hyper parameters? Thanks
The script we are currently using for testing is /scripts/long_term_forecast/Weather_script/TimeMixer_unify.sh.

So, you are using the same hyper parameters like me?  How is your test result in visual?
Namespace(task_name='long_term_forecast', is_training=1, model_id='weather_96_96', model='TimeMixer', data='custom', root_path='./dataset/weather/', data_path='weather.csv', features='M', target='OT', freq='h', checkpoints='./checkpoints/', seq_len=96, label_len=0, pred_len=96, seasonal_patterns='Monthly', inverse=False, top_k=5, num_kernels=6, enc_in=21, dec_in=21, c_out=21, d_model=16, n_heads=4, e_layers=3, d_layers=1, d_ff=32, moving_avg=25, factor=3, distil=True, dropout=0.1, embed='timeF', activation='gelu', output_attention=False, channel_independence=1, decomp_method='moving_avg', use_norm=1, down_sampling_layers=3, down_sampling_window=2, down_sampling_method='avg', num_workers=10, itr=1, train_epochs=20, batch_size=128, patience=10, learning_rate=0.01, des='Exp', loss='MSE', lradj='TST', pct_start=0.2, use_amp=False, comment='none', use_gpu=True, gpu=0, use_multi_gpu=False, devices='0,1', p_hidden_dims=[128, 128], p_hidden_layers=2)
I found a way to avoid loss exploration by set the lradj to 'type1' or 'type3'.
Thanks.

So, are you using the same hyper parameters like me? How is your test result in visual?
Namespace(task_name='long_term_forecast', is_training=1, model_id='weather_96_96', model='TimeMixer', data='custom', root_path='./dataset/weather/', data_path='weather.csv', features='M', target='OT', freq='h', checkpoints='./checkpoints/', seq_len=96, label_len=0, pred_len=96, seasonal_patterns='Monthly', inverse=False, top_k=5, num_kernels=6, enc_in=21, dec_in=21, c_out=21, d_model=16, n_heads=4, e_layers=3, d_layers=1, d_ff=32, moving_avg=25, factor=3, distil=True, dropout=0.1, embed='timeF', activation='gelu', output_attention=False, channel_independence=1, decomp_method='moving_avg', use_norm=1, down_sampling_layers=3, down_sampling_window=2, down_sampling_method='avg', num_workers=10, itr=1, train_epochs=20, batch_size=128, patience=10, learning_rate=0.01, des='Exp', loss='MSE', lradj='TST', pct_start=0.2, use_amp=False, comment='none', use_gpu=True, gpu=0, use_multi_gpu=False, devices='0,1', p_hidden_dims=[128, 128], p_hidden_layers=2)
I found a way to avoid loss exploration by set the lradj to 'type1' or 'type3'.
Thanks.

Indeed, using different schedulers can yield varying results, and factors such as the current execution environment, device model, and software versions can all have an impact. If adopting a different scheduler resolves your issue, then that is excellent.


Remove preprocessors

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (7412472) 100.00% compared to head (f147254) 100.00%.

Additional details and impacted files
@@            Coverage Diff             @@
##              main      #167    +/-   ##
==========================================
  Coverage   100.00%   100.00%
==========================================
  Files           71        62     -9
  Lines         1597      1442   -155
  Branches       157       139    -18
==========================================
- Hits          1597      1442   -155

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


1.0.8 brakes compatibility with Airbrake

Upgrading to Dragonfly 1.0.8 (from 1.0.7) causes
{
  "name":"Dragonfly::TempObject::Closed",
  "message":"can't read from tempfile as TempObject has been closed",
  "stack":"/Users/user/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/dragonfly-1.0.8/lib/dragonfly/temp_object.rb:177:in `tempfile'\n/Users/user/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/dragonfly-1.0.8/lib/dragonfly/temp_object.rb:86:in `file'\n/Users/user/.rbenv/versions/2.2.0/lib/ruby/gems/2.2"
}

Airbrake closes the file here: https://github.com/airbrake/airbrake/blob/v4.1.0/lib/airbrake/user_informer.rb#L32

do you have any more backtrace? I think this actually comes from somewhere calling TempObject#file

One error I'm encountering is when Tempfile#collect is called. See airbrake/airbrake#396


Questions about Analysis of Disentanglement in the paper

Hi, I read your amazing work: "Adversarial Graph Disentanglement", and then I have a question about the experimental part. In the V. EXPERIMENTAL RESULTS AND ANALYSIS,  E. Analysis of Disentanglement， you compute the component confusion matrix C to illustrate the correlations among the distributions in different component spaces.
The correlation score between the i-th and j-th component distributions is given by
.
I don't understand why this formula is used to calculate the correlation of two vector spaces.
Why is cosine similarity calculated between every two elements in these two spaces？
Why not compute the similarity between corresponding elements as a similarity measure for two vector spaces？that is Cij=1/Vsum(hu^ihu^j).
Finally, can you provide your code on computing the cosine similarity of two vector spaces?
I would appreciate it if you could.
Thank you!

Thanks for your attention to our work and the valuable question you have raised!
I don't know if I understand this correctly, I guess the similarity you mentioned Cij=1/Vsum(hu^ihu^j) is the dot product. Actually, the dot product similarity is practically equivalent to the cosine similarity we adopt in this work, since the vector h^i_u and h^j_v are normalized during the process of micro-disentanglement.
As for the associated codes, I will release them after I have reorganized. Plz stay tuned for this project!


[ip6] add API functions to enable multicast looping of a message

At the moment, C API does not allow to get/set the configuration flag which the message to be looped back to the Thread interface. It is important within the context of sending already prepared IPv6 mutlicast packets with otIp6Send().

@konradderda , the CLA check is failing. Can you help resolve?

@konradderda , the CLA check is failing. Can you help resolve?

@konradderda , checking in again on this. Can you help resolve?

@jwhui I am sorry for the delay. I resolved CLA issues few days ago. However, it seems that CI fails are not related to the change itself.


Helidon MP example for Google App Engine on Java 11 runtime

Helidon MP example for Google App Engine on Java 11 runtime
The example is built using Helidon MP Standalone Quikcstart MP with updates for the project to be deployable to Google App Engine Java 11 Standard Environment.
Detailed instructions in README.md file.
Fixes #issue

It's a good idea to open an issue first for discussion.

[x] I have followed Sample Format Guide
[x] pom.xml parent set to latest shared-configuration
[x] Appropriate changes to README are included in PR
[ ] API's need to be enabled to test (tell us)
[ ] Environment Variables need to be set (ask us to set them)
[ ] Tests pass (mvn -P lint clean verify)

(Note- Checkstyle passing is required; Spotbugs, ErrorProne, PMD, etc. ERROR's are advisory only)

[x] Please merge this PR for me once it is approved.

@googlebot I fixed it.

@googlebot I fixed it.

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.
ℹ Googlers: Go here for more info.

I have an agreement dated from Dec 2018, who can i contact to get this resolved?

@ksurendra Apparently your git configuration isn't correctly setup as it's reporting<EMAIL_ADDRESS>as the email you've set for your contributions.  I"m going to close this, so you can resubmit a cleaned up PR that passes the CLA bot, then I'll ask someone to review this, or do it myself.  You might wish to follow the steps outlined here: https://help.github.com/en/github/getting-started-with-github/set-up-git#setting-up-git

@ksurendra Apparently your git configuration isn't correctly setup as it's reporting<EMAIL_ADDRESS>as the email you've set for your contributions. I"m going to close this, so you can resubmit a cleaned up PR that passes the CLA bot, then I'll ask someone to review this, or do it myself. You might wish to follow the steps outlined here: https://help.github.com/en/github/getting-started-with-github/set-up-git#setting-up-git

Thanks @lesv . New PR https://github.com/GoogleCloudPlatform/java-docs-samples/pull/2972


Improve coverage

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 98.71%. Comparing base (d1a9a8e) to head (9ba49b0).

Additional details and impacted files
@@            Coverage Diff             @@
##           master       #8      +/-   ##
==========================================
+ Coverage   97.42%   98.71%   +1.28%
==========================================
  Files          16       16
  Lines         233      233
==========================================
+ Hits          227      230       +3
+ Misses          6        3       -3

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


Added Symptom Checklist

While using the app I didn't like that answers couldn't be changed or reviewed, so I made a checklist! Checklist items appear as the user answers the questions. The user can then review or edit their answers at any time and the calculation is updated.
Hopefully this is useful, please let me know if there is anything that needs changing.

Awesome. We used some refactored code with a number of bug fixes in the last few hours, so working on taking your checklist and integrating it with that now.

Completed!


Closed network issue

Ohai,
I'm working in an environment with no internet connection
Doing :allocate and :ready for machines works 100%.
However it fails when trying to do a :setup action.
The part where it creates and copies the client.pem and client.rb to the provisioned node succeeds.
Despite providing the [:convergence_options][:install_sh_url] with a value of a local install script url,
the run fails because it's trying to download the package from chef.io.
Any Ideas on how to force using a local URL for the package installation?
Thanks in advance.

Just come up with your own custom install bash script to basically download a chef package(rpm, deb) from a HTTP based server within your local network.
Or

by using machine_file resource to upload a RPM/DEB package to the provisioned node from your local path
then use machine_execute resource to install that uploaded package on the provisioned node


Repeating set: Adding/removing does not work and inconsistent across elements

Description
The "Add to set" button and "Remove from set" button do not work
They show up differently visually for address and individual names which include page text
Steps to reproduce

Add repeating set
Add individual names component
Add address component
Click on each and try to add / remove
See weirdness

Details

Browser: Chrome
Operating system: Mac
Environment: PR
Language: English
Viewport: Desktop

Expected behaviour
Does "Remove from set" delete or simply remove from nesting?
Do we need two "Add to set" links/buttons, the embedded and non-embedded?
Screenshots or videos
Private Zenhub Video

Tried address seems to work
https://github.com/user-attachments/assets/ae5919e8-1df2-48be-884f-e4388f03b85a

Ah, I was trying to select the card by clicking the general areas, not click inside the text input.
I did find something similar with move up move down -- where it loses focus and also stops working?
Private Zenhub Video

Another example of the inconsistency: inside vs. outside of a set?

Working on some fixes here
https://github.com/cds-snc/platform-forms-client/pull/4346

This works, assuming you click inside the text input for the form element label.


Revert Schema main method

Oops...

Codecov Report

Merging #2491 into master will increase coverage by 0.11%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #2491      +/-   ##
==========================================
+ Coverage   69.45%   69.56%   +0.11%
==========================================
  Files         848      848
  Lines       39562    39555       -7
  Branches     5332     5330       -2
==========================================
+ Hits        27479    27518      +39
+ Misses      10293    10243      -50
- Partials     1790     1794       +4

Impacted Files
Coverage Δ

...in/java/com/linkedin/pinot/common/data/Schema.java
80.93% <ø> (+2.55%)
:arrow_up:

...a/manager/realtime/RealtimeSegmentDataManager.java
50% <0%> (-25%)
:arrow_down:

...impl/dictionary/DoubleOnHeapMutableDictionary.java
64.44% <0%> (-17.78%)
:arrow_down:

...kedin/pinot/core/util/SortedRangeIntersection.java
83.82% <0%> (-7.36%)
:arrow_down:

...not/core/query/pruner/DataSchemaSegmentPruner.java
53.65% <0%> (-4.88%)
:arrow_down:

...e/operator/dociditerators/BitmapDocIdIterator.java
60.71% <0%> (-3.58%)
:arrow_down:

...mpl/dictionary/DoubleOffHeapMutableDictionary.java
72.72% <0%> (-1.82%)
:arrow_down:

...lix/core/realtime/PinotRealtimeSegmentManager.java
72.31% <0%> (-1.13%)
:arrow_down:

...inot/transport/netty/NettyTCPClientConnection.java
85.91% <0%> (-0.71%)
:arrow_down:

...regation/function/customobject/QuantileDigest.java
49.14% <0%> (ø)
:arrow_up:

... and 20 more

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 60337be...1cbcff2. Read the comment docs.


App doesn't handle changes to handle

Repro:

Login to app with handle
Change handle via website or something
try use app again. Things become blank

Fixed https://github.com/jenius-apps/beeskie/commit/9a18450e2387c75e0131ad7392689b2d80e6e3f9


refactor: added python 3 compatability

(Renamed base branch to match repo description)Added dictionary compatibility with python 3. In python 3, when iterating through dictionaries, one has to keep in mind that the methods ".values(), .keys(), and .values()" do not return actual lists. They return objects, which you can use to iterate over the keys and values. But you can easily typecast those objects into lists by using the list() function.

Approved


Running Prepare-Release for azure-messaging-servicebus 7.17.0 (May-2024 release)

API change check
API changes are not detected in this pull request.


avoid blocking Cassandra API calls

The blocking API is used way too much. We should use the async API. Most important is to improve this in the replay (iterator), but it should be revisited for all other things also, such as connect and prepare.

Continued here: https://github.com/akka/akka-persistence-cassandra/issues/6


Add ability to multi-add/drop songs into a playlist + auto-organize via game title

As title suggest. Latter being able to organize the song playlist automatically instead of doing it all manually when you have a lot of songs added, which is quite a pain to do.

We can have some stuff which automatically sort the songs next to their series/games, but multiple drag & drop looks very complicated at this time for very little gain.
Like add a new song, pick a game title, it orders it after the last song that has same series/game title for example.

Removing "Add ability to multi-add/drop songs into a playlist"
Will do auto-organize by game title

A tree view and auto-mapping was implemented as part of 1.54b. Closing.


Update readme with 8081 port number

@coderroggie: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Apollo Contributor License Agreement here: https://contribute.apollographql.com/

Thanks!


libpng pinning

@conda-forge-admin please rerender
https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=60738

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I rerendered the recipe in conda-forge/freetype-feedstock#31.

The relevant PR was merged, this can be closed.

The relevant PR was merged, this can be closed.


[Bug]: Clicking to initiate page crash again when there is variable configuration in data cleaning

ODC version
odc424
OB version

What happened?

What did you expect to happen?
The page will not crash
How can we reproduce it (as minimally and precisely as possible)?

Create data cleaning and clean up existing variable configurations
After successful creation, click to initiate again

Anything else we need to know?
No response
Cloud
No response

Fixed In Commit f35f340b944f118de92e7563716f08feb1f1bf37
------
咏和
Tue Mar 5 09:33:13 2024 +0800

pass


Add parsing for all object with serializable object or list of serializable object

Hi Maxime,
Could you elaborate a bit with an example?
Regards,
/gustav

currently it's impossible to return this item :)
class Account {
  int id;
  String mail;
  User me;
  List<User> family;
  Account(this.mail) : super();
}

class User {
  int id;
  String firstName;
  String lastName;
  User(this.firstName, this.lastName) : super();
}

@wibling ?

Hi Maxime,
Sorry for the long delay. I have been busy with other (unrelated) work.
For you example above it should work as is. I just tried it out by modifying the example/toyapi.dart file to also have a method that returns an Account as you describe it.


Multithreading support

It is currently extremely difficult to pass GeneticSim between threads because it has Box<dyn Fn>. It should be changed to be threadsafe.

should be fixed in https://github.com/HyperCodec/genetic-rs/pull/7/commits/c8e59b763fcf8606373d81efc0b9268e1bf9a647 but will keep this open for now.

now it has fully been fixed in https://github.com/HyperCodec/genetic-rs/pull/7/commits/99c5ea75c2ee1dfd3a265e97152cd77d9565d906.


gimpPlugins.farbfeld: init at 2019-08-12

Motivation for this change

Farbfeld format
Gimp plug-in for the farbfeld image format

Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 113585 at d53c2068 run on x86_64-linux 1

4 packages built:

gimp-with-plugins
gimpPlugins.farbfeld
glimpse-with-plugins
glimpsePlugins.farbfeld

3 suggestions:

warning: maintainers-missing
Package does not have a maintainer. Consider adding yourself?
Near pkgs/applications/graphics/gimp/plugins/default.nix:97:5:
   |
97 |     meta = {
   |     ^

warning: missing-phase-hooks
installPhase should probably contain runHook preInstall and runHook postInstall.
Near pkgs/applications/graphics/gimp/plugins/default.nix:95:5:
   |
95 |     installPhase = "installPlugin farbfeld";
   |     ^

warning: unused-argument
Unused argument: config.
Near pkgs/applications/graphics/gimp/plugins/default.nix:5:3:
  |
5 | { config, lib, pkgs }:
  |   ^

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 113585 run on x86_64-linux 1

4 packages built:

gimp-with-plugins
gimpPlugins.farbfeld
glimpse-with-plugins
glimpsePlugins.farbfeld

The following issues got detected with the above build packages.
Please fix at least the ones listed with your changed packages:

gimpPlugins.farbfeld:

Package does not have a maintainer. Consider adding yourself?
Near pkgs/applications/graphics/gimp/plugins/default.nix:99:5:
   |
99 |     meta = {
   |     ^

See: https://github.com/jtojnar/nixpkgs-hammering/blob/master/explanations/maintainers-missing.md
installPhase should probably contain runHook preInstall and runHook postInstall.
Near pkgs/applications/graphics/gimp/plugins/default.nix:95:5:
   |
95 |     installPhase = ''
   |     ^

See: https://github.com/jtojnar/nixpkgs-hammering/blob/master/explanations/missing-phase-hooks.md
Unused argument: config.
Near pkgs/applications/graphics/gimp/plugins/default.nix:5:3:
  |
5 | { config, lib, pkgs }:
  |   ^

gimp-with-plugins:

Unused argument: paths.
Near pkgs/build-support/trivial-builders.nix:284:12:
    |
284 |          , paths
    |            ^

glimpsePlugins.farbfeld:

Package does not have a maintainer. Consider adding yourself?
Near pkgs/applications/graphics/gimp/plugins/default.nix:99:5:
   |
99 |     meta = {
   |     ^

See: https://github.com/jtojnar/nixpkgs-hammering/blob/master/explanations/maintainers-missing.md
installPhase should probably contain runHook preInstall and runHook postInstall.
Near pkgs/applications/graphics/gimp/plugins/default.nix:95:5:
   |
95 |     installPhase = ''
   |     ^

See: https://github.com/jtojnar/nixpkgs-hammering/blob/master/explanations/missing-phase-hooks.md
Unused argument: config.
Near pkgs/applications/graphics/gimp/plugins/default.nix:5:3:
  |
5 | { config, lib, pkgs }:
  |   ^

glimpse-with-plugins:

Unused argument: paths.
Near pkgs/build-support/trivial-builders.nix:284:12:
    |
284 |          , paths
    |            ^


⚠ PrivateHD has degraded performance

In c5c503e, PrivateHD ($PHD) experienced degraded performance:

HTTP code: 200
Response time: 2294 ms

Resolved: PrivateHD performance has improved in af02482.


Resize in Crop And Lock

Description of the new feature / enhancement
To resize cropped reparent window
Scenario when this would be used?
When using fancy zones windows get auto resizing by fancy zones, it would be nice to get auto resizing for cropped window.
It is also useful in situations when u misresized and want to fix that.
Supporting information
No response

/dup #29732


Improve rules from files lifecycle in a live environment

Motivation
Storing rules from yaml files in the same ConfigMap than falco config, implies Helm upgrade always overwrites current rules with the ones from the rules/ folder. This could not be the desired behaviour since someone could delete all falco_rules.local.yaml rules unwittingly very easily, among other unintended rules update.
Am I missing something or is it a common problem?
Feature
Separate falco config and rules from files in two different ConfigMaps, adding an overwrite-rules flag in chart values so the user can choose to deploy only falco config changes preserving the current rules on an environment.
I'd be glad to do a PR to falco chart with required changes if you think it's a good feature :-)
Alternatives
N/A
Additional context
We manage custom false-positives in falco_rules.local.yaml (I think is the way to do it) and all the falco deployment with helm is automated using Ansible. We've faced that there's no way to ensure that custom rules are note deleted because of the way falco chart handles rules from files.
We don't have that problem with custom rules (which we use for specific rules for each environment) since it's updatable using values.yaml.

After doing some tests, I've realized there's no way to make helm not deleting (or not updating) a resource created by it if the referenced template changes between upgrade executions :-(
However, I still think it's a good idea to use a separate configmap for "fabric-rules" (i.e: rules coming from yaml files exclusively). This would make easier to implement a custom rules update strategy for each case, since the rules stored in this new ConfigMap could be moved directly to the correspondent chart template, in case you want to execute a helm upgrade and preserve current rules.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


Tec 560

Tests are missing 😭 Coming soon!

@keithamus issues should be all addressed 😊

Address the rest of these comments and I think this will be a perfect component 🎉 💯

@keithamus vertical scrolling added 💃

Bring it home! :rainbow:

I did a performance test. It turns out you actually allocate nothing, but the underlying thing allocates a lot! On every scroll event it creates 2 objects, and a lot of times it allocates a new function for setTimeout!

This is responsible for 50% of the allocations in my simple test:
						_timeouts.push(setTimeout(function() {
							_fireEvent('reached' + newPositionAtExtremity, { axis: axis });
						}, boundsCrossDelay || animationDuration));

It only fires when you've scrolled enough that it overflows, but it still causes jank in my quad core.
The rest of the allocations, although smaller, are caused by this function being called a lot:
		_getPosition = function _getPosition() {
			return {
				scrollLeft: -_lastScrollPosition.x,
				scrollTop: -_lastScrollPosition.y
			};
		};

It would be greatly improved with an Object.freeze() call. Also, there's a part where this object "shape" gets a surprise property:
			scrollEvent.cancelled = scrollCancelled;

This should have been set to false in the above _getPosition call.
Also, _updateScroll allocates 2 objects for every call:
			var gesture = {
				x: inputX - _gestureStart.x,
				y: inputY - _gestureStart.y
			};

			_eventHistory.push({ x: inputX, y: inputY, t: inputTime });
			if (_eventHistory.length > 30) {
				_eventHistory.splice(0, 15);
			}

The second instance should have been a circular buffer. The first one is actually only used inside the function so it should have been 2 variables.
Of course it's totally out of scope for this, would just like to let you know lol.

Few more tests and I'd say this is one of our best components, and I'd be super duper happy to merge.

Tests are coming up 🏇

@keithamus tests added!

none of the ft-scroller stuff is tested here... but I'm gonna let it slide to get this one out the door.


HASS' MQTT broker is deprecated, recommend to use Mosquitto addon

It seems embeded broker is deprecated: https://www.home-assistant.io/docs/mqtt/broker#embedded-broker-deprecated
In Hass.io is is super simple to install Mosquitto. How about to rewrite default config to support it by default?
"mqtt": {
    "base_topic": "zigbee2mqtt",
    "server": "mqtt://core-mosquitto",

I have no experience with zigbee2mqtt, but I'm already using Mosquitto. @iBobik I tried this server address, which I suppose is referring to the Mosquitto running locally, but sadly I don't see my client_id in the Mosquitto log.

And do dou see on client service that is connected to the broker?
Btw, I tried to restart zigbee2mqtt and this appeared in the broke’s log:
1565107350: Socket error on client mqttjs_f708684e, disconnecting.
1565107361: New connection from <IP_ADDRESS> on port 1883.
[INFO] found zigbee on Home Assistant
1565107362: New client connected from <IP_ADDRESS> as mqttjs_9d119010 (p2, c1, k60, u'zigbee').

2019 v 15:26, ambarusa<EMAIL_ADDRESS>

I have no experience with zigbee2mqtt, but I'm already using Mosquitto. @iBobik https://github.com/iBobik I tried this server address, which I suppose is referring to the Mosquitto running locally, but sadly I don't see my client_id in the Mosquitto log.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/danielwelch/hassio-zigbee2mqtt/issues/211?email_source=notifications&email_token=AAEV6WHQLRCPAVCPNPGJEG3QDF3WZA5CNFSM4IJGK6UKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3VEBBI#issuecomment-518668421, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEV6WH2N4OT5MMV3RAW36LQDF3WZANCNFSM4IJGK6UA.

I'm ok with updating the defaults here to something more sensible given the deprecation.


Freeze in random_chain generation during composing with specific primary model types

In Composer we have initial population generation stage that uses random_chain function for it. However, if we set GPComposerRequirements(primary=[data_operations_only]) it will probably freeze due to invalid chain configurations.
It happens due to chain validation: if chain contains more than one identical data_operation in primary_nodes it is invalid.

Probably, we should improve random_chain function - modify invalid chains if it occurs and log this operation.

Example of GP requirements that can also reproduce error:

Can’t reproduce this bug in newer version.


traverse dependents only for modified files

We don't need to traverse dependents of untouched files that failed before. This can reduce the files to check drastically if you fix several type errors...

Codecov Report

Merging #57 into master will increase coverage by 0.03%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #57      +/-   ##
==========================================
+ Coverage   94.15%   94.19%   +0.03%
==========================================
  Files           9        9
  Lines         445      448       +3
  Branches       56       58       +2
==========================================
+ Hits          419      422       +3
  Misses         26       26

Impacted Files
Coverage Δ

src/util/FileCache.ts
97.7% <100%> (+0.02%)
:arrow_up:

src/checker/IncrementalChecker.ts
96.15% <100%> (+0.07%)
:arrow_up:

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 e3b3b03...ef9f824. Read the comment docs.


Added Code Quality GitHub Action

Description

Added a GitHub action that runs tests and linter whenever code is pushed to dev or main.
Related Issue

Fixes #51
Motivation and Context

Had a recent problem in #50 where was getting a lint error when making a PR. Instead of having devs have to run the linter every time they pushed, wanted to do linting when the code was pushed.
How Has This Been Tested?

When code is pushed to this PR, the GitHub Action is run. All the actions need to pass to be able to merge this code.
Screenshots (if appropriate):

Hey @TAKANOME-DEV, I think I got the GitHub actions working but I'm not sure. Mind taking a look?

LGTM +1 After merging this pr, we will see if the cypress tests will pass sweat_smile

They pass already. Was wrestling with them a bit trying to get this to work. The GitHub Action will work but if the tests don't pass then the PR will be sad.

They pass already. Was wrestling with them a bit trying to get this to work.

Nice job :+1: :rocket:

The GitHub Action will work but if the tests don't pass then the PR will be sad.

Yeah, definitely :sweat_smile:


Trying to display motion vectors spits out an error every frame when MSAA 3D is enabled

Godot version
v4.1.3.stable.official [f06b6836a]
System information
Godot v4.1.3.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1650 (NVIDIA; <IP_ADDRESS>40) - Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz (4 Threads)
Issue description
This is the error:

Texture (binding: 0, index 0) needs the TEXTURE_USAGE_SAMPLING_BIT usage flag set in order to be used as uniform.
./servers/rendering/renderer_rd/uniform_set_cache_rd.h:129 - Condition "rid.is_null()" is true. Returning: rid
drivers/vulkan/rendering_device_vulkan.cpp:7208 - Condition "!uniform_set" is true.
Uniforms were never supplied for set (0) at the time of drawing, which are required by the pipeline

repeated over and over again.
I should also mention that I'm not using the mono version.
Steps to reproduce

Click the three-dots icon in the top left of the scene view.
Go to "Display Advanced" and select "Motion Vectors"

Minimal reproduction project
N/A

cc @clayjohn @DarioSamo

This might be fixed in 4.2 already. Would be worth checking if there is something we can cherry pick

This might be fixed in 4.2 already. Would be worth checking if there is something we can cherry pick

I just checked in Godot 4.2 beta 5. This issue isn't fixed yet.

I can't reproduce the issue in 4.2 beta5. Motion vectors look fine and don't report any errors. I tested in a high-complexity 3D scene that is mostly static objects.
Can you please upload an MRP so that we can see if something project-specific is causing the issue?

Update: I just created a new project from 4.2 beta5 and, for some reason, the motion vectors seem to work fine. I forgot to mention that the project in which the error is happening was ported over from 4.1.3, so that might be the issue.
It seems that the problem is indeed project specific. Thanks for helping me, you can close this issue if you want.
MRP.zip

Closing as no longer reproducible buy the OP

Reopening, as this occurs whenever MSAA is enabled.

It also happens to me when I try Display Advanced -> Normals. I'd say the the copy_to_fb.glsl shader needs a multi-sample version, where the source_color is declared appropiately. Alternatively, CopyEffects::copy_to_fb_rect(), and maybe others, should resolve to a temp buffer before running the shader.


Credentials Error

Not sure what to do. When I run the first test I get the following, first I logged the params, and then I logged the error,
Serverless: Bundling with Webpack...
Time: 343ms
Built at: 2018-2-26 17:38:39
    Asset      Size  Chunks             Chunk Names
create.js  1.51 KiB       0  [emitted]  create
Entrypoint create = create.js
   [0] external "aws-sdk" 42 bytes {0} [built]
   [1] external "uuid" 42 bytes {0} [built]
   [2] external "babel-runtime/core-js/json/stringify" 42 bytes {0} [built]
   [3] ./create.js 2.05 KiB {0} [built]

WARNING in configuration
The 'mode' option has not been set. Set 'mode' option to 'development' or 'production' to enable defaults for this environment.
params:  { TableName: 'notes',
  Item:
   { userId: 'USER-SUB-1234',
     noteId: '8e1ea2f0-1b56-11e8-a9f2-11680d2c2ad9',
     content: 'hello world',
     attachment: 'hello.jpg',
     createdAt:<PHONE_NUMBER>031 } }
error:  { Error: connect EHOSTUNREACH <IP_ADDRESS>:80
    at Object.exports._errnoException (util.js:1024:11)
    at exports._exceptionWithHostPort (util.js:1047:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1150:14)
  message: 'Missing credentials in config',
  code: 'CredentialsError',
  errno: 'EHOSTUNREACH',
  syscall: 'connect',
  address: '<IP_ADDRESS>',
  port: 80,
  time: 2018-02-27T00:38:43.112Z,
  originalError:
   { message: 'Could not load credentials from any providers',
     code: 'CredentialsError',
     errno: 'EHOSTUNREACH',
     syscall: 'connect',
     address: '<IP_ADDRESS>',
     port: 80,
     time: 2018-02-27T00:38:43.112Z,
     originalError:
      { code: 'EHOSTUNREACH',
        errno: 'EHOSTUNREACH',
        syscall: 'connect',
        address: '<IP_ADDRESS>',
        port: 80,
        message: 'connect EHOSTUNREACH <IP_ADDRESS>:80' } } }
{
    "statusCode": 500,
    "headers": {
        "Access-Control-Allow-Origin": "*",
        "Access-Control-Allow-Credentials": true
    },
    "body": "{\"status\":false}"
}

initially I didn't have the config file or the credentials added when I ran aws configure. I added a .aws directory and with added a .aws/config and .aws/credentials

The EHOSTUNREACH error seems like you were maybe behind a firewall or you had connection problems?
Has it ever worked for you?


[bugfix](multi catalog) fixed an issue in master where hive directory…

Fixed an issue in master where hive directory field separator was an empty string causing it to be core
Proposed changes
cherry-pick from #34589
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Feature: clicking on share chat takes a lot of time

Suggested solution
when clicking on the share chat it takes a bit of time to load the share buttons (mostly cause it creates the chat link in the backend)
it would be great to have a loading state their or something to let the user wait, I think this would not be needed if the threads feature was added since it would just copy the link.
https://github.com/open-sauced/app/issues/3527

A loading state would be ideal - it does have to go round trip through to the backend to generate the short link. We have some existing design elements that could help here too!

@jpmcb thanks for the comment
The related code:
https://github.com/open-sauced/app/blob/50c5d1111775d3aafd989fb48478dac304b553a0/components/StarSearch/StarSearchChat.tsx#L623-L666
The loading state should be added at the beginning of the async function and changed when the link is generated.
This could be a good first issue.

Hey @nickytonline, I am working on this feature to add a loading state to the share chat button. I have implemented the solution, but I'm having an issue. When I click the share button, it fails to fetch the share link and gives a "bad request" or "failed to create a share link" error. However, fetching stream chats or AI-generated chats works fine. I'll attach a video showing the problem and an image of the network fetch error that happens when it tries to fetch the share link. Tell me what I can do to resolve this issue
https://github.com/open-sauced/app/assets/105356967/9ef01d32-98b1-45d7-9438-ad3870c6d10e

Hi @ashudevcodes. Thanks for your interest in the issue, but it's already assigned to me and i astray have a fix for this.
Feel free to look at other issues that are not assigned to someone.


fix: Enable Pages from DevTools for Nuxt 4

🐛 The bug
The pages directory was created in the project root, vs the UI root (app).
🛠 To reproduce
n/a in dev ATM
🌈 Expected behavior
Set the compatibility in nuxt.config.ts file.
future: { compatibilityVersion: 4 },
Create the app/pages folder & files. Update the app.vue file. Refresh running pages.
ℹ Additional context
No response

Correction. If the app folder exists, and the App.vue file is nested in the folder it works as expected.


Backport "Fix #20271: Bring for comprehension spec up to date." to 3.6.2

Backports #21702 to the 3.6.2 branch.
PR submitted by the release tooling.
[skip ci]

No regressions detected in the community build up to release-3.6.2-backport-21891.
Reference


Implement Speakers module

Feature Request
Feature Description
Implement Speakers module since the Sessions module been implemented.

[x] List Speakers(#647)
[x] Tests for the module.

Would you like to work on the issue?
Yes

Fully implemented.

Speaker details are not shown along with the sessions they are speaking in

Implemented completely.


Backend adapters for storing job results (Elastic)

Define a "backend"  interfa e to store job information.

Won't need this since it everything will be handled by Ferrari server


ci: try different danger bot

:tada: This PR is included in version 2.0.1-rc.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

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


invalid character 'ÿ' looking for beginning of value

The default encoding is UTF-16 which yeilds invalid character 'ÿ' looking for beginning of value until converted into utf-8.

@sfxworks I didn't get the issue. Do you mean that when the values.yaml contains the character ÿ in the value (in the start or anywhere) then there's some issue? I just tried the below in the values.yaml
randomValue: happÿ

anotherRandomValue: ÿay

And it worked
...
        "anotherRandomValue": {
            "type": "string"
        },
...
       "randomValue": {
            "type": "string"
        },
...

Could you explain some more details about what's the issue you are facing and how to reproduce it?

Sorry, I am trying to say that when I run helm-schema-gen, the values.yaml.json is rendered and formatted in UTF-16, leading to helm to wonder what encoding the schema is in and failing to parse it. Can it default to UTF-8 or be set to the format the values file is in?

Ah! Didn't know about this. I'll check it out @sfxworks ! Thanks for bringing this up

@sfxworks Could you help me in reproducing the issue? I'm not able to reproduce it. Whenever I create the values.schema.json, it gets created in ASCII format somehow

$ file -I values.yaml
values.yaml: text/plain; charset=utf-8

$ file -I values.schema.json
values.schema.json: text/plain; charset=us-ascii


Want to add text watermark in tile format

Hello support,
I want to add user given text(watermark) in tile form on an image.
i am using below code. but its not working it put a single line with angle i given, where as i want text to be repeated until it reaches end of the image, i hope you understand what i mean.
$img = Image::make(storage_path('app'.DIRECTORY_SEPARATOR.'public'.DIRECTORY_SEPARATOR.$media->file_path));
// use callback to define details
$width = $img->width();
$height = $img->height();
            $data = $img->text($watermark, 15, 25, function($font) {
                        $font->file(public_path('frontend/fonts/Xerox Serif Wide.ttf'));
                        $font->size(36);
                        $font->color(array(0,0,0, 0.3));
                        $font->align('center');
                        $font->valign('top');
                        $font->angle(45);
                    })

Thanks

I think you need a loop which places the text on different positions, like:
    for($i = 15, $j = 25; $i < $width && $j < $height; $i += 40, $j += 40) {
        $data = $img->text($watermark, $i, $j, function($font) {
            $font->file(public_path('frontend/fonts/Xerox Serif Wide.ttf'));
            $font->size(36);
            $font->color(array(255,0,0, 0.3));
            $font->align('center');
            $font->valign('top');
            $font->angle(45);
        });
    }

hope this helps.

I would split this into two steps.

Create the watermark by writing text onto an transparent background
Use this watermark image as a parameter to call fill() and place it all over the target image


No slots available though calendar is empty

After following the video tutorial and copying code from this repo, I cannot make an apointment, though webhook execution is succesful.
{   "fulfillmentText": "I'm sorry, there are no slots available for Invalid Date.",   "outputContexts": [] }
{   "responseId": "39a299fc-1528-4b63-b49b-e988baa0c1f2-c8e3f272",   "queryResult": {     "queryText": "set appointment for drivers license Friday 10am",     "parameters": {       "time": "2022-01-26T10:00:00+03:00",       "date": "2022-01-28T12:00:00+03:00",       "AppointmentType": "Driver License"     },     "allRequiredParamsPresent": true,     "fulfillmentText": "I'm sorry, there are no slots available for Invalid Date.",     "fulfillmentMessages": [       {         "text": {           "text": [             "I'm sorry, there are no slots available for Invalid Date."           ]         }       }     ],     "intent": {       "name": "projects/test-chat-bot-app-321808/agent/intents/f2ee95db-be68-495a-90a8-6765e6dc413d",       "displayName": "Schedule Appointment"     },     "intentDetectionConfidence": 0.73469204,     "diagnosticInfo": {       "webhook_latency_ms": 82     },     "languageCode": "en",     "sentimentAnalysisResult": {       "queryTextSentiment": {}     }   },   "webhookStatus": {     "message": "Webhook execution successful"   } }

It is because the code expected the request date to have a negative time zone offset
const dateTimeStart = new Date(Date.parse(agent.parameters.date.split('T')[0] + 'T' + agent.parameters.time.split('T')[1].split('-')[0] + timeZoneOffset));

and in your request, you have a positive timezone offset, 2022-01-26T10:00:00+03:00, which leads to invalid date parsing.
You can fix this by modifying that line of code to accommodate both positive and negative timezone offset.
const dateTimeStart = new Date(Date.parse(agent.parameters.date.split('T')[0] + 'T' + agent.parameters.time.split('T')[1].split(/[-+]/)[0] + timeZoneOffset));


Preventing subtraction underflow in slowStart

Before this pull-request, the computation of slowStart contained a subtraction that can underflow:
registryCreated + 20 weeks - now

when the current timestamp is more than 20 weeks after the registry creation.  In unlucky cases the newAuction.registrationDate would become a point in the past.  This pull request avoids the subtraction when the underflow would occur.
I hope this time it's not an arithmetic misconception (like the one I made in #3).

Thanks for that. Being an uint I thought that it would automatically convert any negative number into 0.


Song screen doesn't scroll down to follow playback cursor

When the playback cursor goes off screen by playing the next row not visible on the Song screen, the screen does not scroll itself to follow the cursor so that the currently playing row is displayed on screen.
This is disorientating behaviour as there is no other way on the UI to see the currently playing row.
An added wrinkle here is that different rows can be playing in different tracks (columns). For that case I think it would be acceptable to try to show at least the left most playing columns currently playing row.

I don't quite agree on this one. The screens are mainly editing screens, and playback cursor is added as a visual aid, but don't think it should take over scrolling. What happens when you're looking at something and the screen needs to scroll and you're editing cursor is in the first row? does it disappear? move over to another row? Don't think either of those are desirable
The fact that the playing cursor could end up in two different screens and you'd have to make an arbitrary decision on which one to follow makes this even worse IMO.

@democloid good point about that! I was influenced on this by how Milkytracker does scroll with playback but its an option there to turn off and playing a bit more with it, I think you're right and it won't work well on the pT UI.


✨ Using inject for defineProps object syntax

What problem does this feature solve?
Hi 👋🏻
I'm building Anu and I find it's convenient (or must from user's perspective) to provide props defaults from user side for UI library. For example, if UI library has size prop and user wants button with small size in entire project then user have to write size="small" everywhere. Additionally, This causes problem if the designer decided the size the size from small to something else and developer has to replace the prop value each & every place 😬
<!-- Inconventient & Duplicate code -->
<Btn size="small">...</Btn>
<Btn size="small" other-prop="val">...</Btn>
<Btn size="small">...</Btn>
<Btn size="small" block>...</Btn>

This approache is similar to vuetify 3's global configuration where vuetify allows props defaults while intializing vue plugin.
When I was trying to implement above mentioned feature, I noticed I can't use provide/inject in defineProps' object syntax like below:
// `getAlertProps` is import from another file because we can't use variable from SFC for `defineProps`
const props = defineProps(getAlertProps())

// meta.ts
export const aAlertProps = {
  size: {
	type: string as PropType<'sm' | 'md' | 'xl'>,
	default: 'md'
  }
}

export const getProps = () => {
  /* Error: [Vue warn]: inject() can only be used inside setup() or functional components. */
  const defaults = inject(ANU_DEFAULTS)  // <------ 🫣 Can't use inject

  // Assume `defaults.alert` will have only defaults like `{ size: { default: 'sm' } }`
  return defu(aAlertProps, ...(defaults.alert || {}))
}

What does the proposed API look like?
IDK if this is even possible at Vue side, Maybe we can have vue macros from Kevin for this FR. Once, this is implemented we can use inject as shown in above code example for allowing user to change component's props defaults.
Additional notes

Maybe we can try this in Vue Macros first before officially adding it to core
Above FR just explains updating prop defaults via config (under the hood provide) however inject will allow updating props defaults when component is rendered inside certain components. For example, user might configure button to be size of xs when used inside table for saving space via config like this:

app.use(plugin, ({
  // other plugin config
  defaults: {
    ABtn: { size: 'sm' },
    ATable: { ABtn: { size: 'xs' } },
  }
})

After skimming vuetify's code I found that they uses getCurrentInstance()?.vnode.props for getting props applied to current component instance. I also implemented POC for anu's global prop defaults.
I just have to run the some piece of code at the start of each SFC.
Closing this as this can be achievable via this approach.


Switching Recognizer throws message box

Describe the bug
When switching the Recognizer Type,
Version
Version:  1.4.0-nightly.235590.f4de79
Electron: 8.2.4
Chrome: 80.0.3987.165
NodeJS: 12.13.0
V8: 8.0.426.27-electron.0

[X] Electron distribution
[ ] Chrome
[ ] Safari
[ ] Firefox
[ ] Edge

OS

[ ] macOS
[X] Windows
[ ] Ubuntu

To Reproduce
Steps to reproduce the behavior:

Load bot (using one from Tai)
Set Recognizer Type to Orchestrator recognizer
Message Box appears (see below)
It then resets back the Default Recognizer

Screenshots

@daveta are you able to reproduce this on a fresh project with latest nightly?


Flexbox performance issue

Quoted from: https://webplatformforembedded.github.io/Lightning/docs/renderEngine/flexbox

Lightning does not contain the bloated HTML CSS toolbox.
Instead, it only contains the useful Flexbox layout methodology.
The Lightning layout engine has some smart performance optimizations.
However, it is still rather CPU-intensive so it is best used for situations in which the flex items do not often change dimensions.

Q: Is there some performance issues if we have a carousel card if it has resized on focus/unfocus?
The point is that the flex is not used on the card itself but rather on the text items included.
Example:
static _template() {
return  {
clipping: true,
mount: 0.5,
BackgroundImage: {
mount: 0.5,
x: (w)=> w / 2,
y: (h) => h / 2
},
Overlay: {
mount: 0.5,
x: (w)=> w / 2,
y: (h) => h / 2,
rect: true,
color: color.overlay.overlay_200
},
TextContainer: {
mount: 0.5,
flex: {
direction: 'column',
alignContent: 'center',
justifyContent: 'center',
paddingTop: 20
},
Title: {
flexItem: {
alignSelf: 'center'
},
text: {
fontSize: 32,
fontFace: 'Medium',
textColor: color.button.text,
textAlign: 'center'
}
},
Underline: {
alpha: 0,
flexItem: {
alignSelf: 'center'
},
rect: true,
w: 120,
h: 4
}
}
};
}
Thank you.

Hi @MykhailoDz
The use case you're describing shouldn't be an issue. Of course, the more items you include in flex layout and the more forced recalculations happen (via dimension resize) the more CPU will be needed.
However, this does not mean you shouldn't use flex. When it comes to performance, general approach is profiling the app and making sure the code is clean and doesn't do anything unreasonable.
Best regards

Closing for now, please reopen if you have any further doubts.


Unexpected error while processing stanza event

I keep getting the 'Unexpected error while processing stanza event' error when processing incoming events. I've added extra validation in SystemAccessPoint.parseEncryptedUpdates that I will make a PR for.
TypeError: Cannot read property 'attrs' of undefined
at node_modules/freeathome-api/dist/lib/SystemAccessPoint.js:140:124

Hi,
I believe this was already fixed in #18. However I haven't released a new version yet so the fix is only available in the master version.


KIP-396: Add AlterConsumerGroup/List Offsets to AdminClient

Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@guozhangwang @vahidhashemian @bbejeck @harshach @cmccabe @hachikuji As you all voted on this KIP, can a few of you review the PR? Thanks

@guozhangwang @vahidhashemian @bbejeck @harshach @cmccabe @hachikuji I'd love to get this in 2.4, can you take a look? It's a relatively straight forward KIP/PR.

I couldn't help reviewing but this would be really helpful to the Kafka integration on Spark. Looking forward to the feature!

Thanks @hachikuji and @guozhangwang for the feedback!
I've pushed an update:

addressing all the minor issues
hiding the ListOffsetRequest magic values
adding some retry logic for fetching metadata. I've re-use the pattern from FindCoordinator.

I'm flying back to the UK tomorrow evening but I should be able to make more changes tomorrow if needed. If we're not happy with the metadata retry logic, maybe a temporary solution would be to remove it and keep using the Consumer in the consumer group tool for now. Then next week I can revisit it. What do you think?

@hachikuji  Thanks again for the review. I've pushed an update. I'll start adding coverage in KafkaAdminClientTest now

Gathering the TODOs we identified:

update deleteRecords() to not fail all partitions on error: https://github.com/apache/kafka/pull/7449 (https://github.com/apache/kafka/pull/7296#discussion_r331683309)
update methods using metadata to use MetadataOperationContext (https://github.com/apache/kafka/pull/7296#discussion_r330808723)
generalize MetadataOperationContext and ConsumerGroupOperationContext
update getAlterConsumerGroupOffsetsCall to only retry partitions with errors (https://github.com/apache/kafka/pull/7296#discussion_r331702031)
update MetadataOperationContext to only retry partitions with an error (https://github.com/apache/kafka/pull/7296#discussion_r331696091)
maybe include a top-level error in OffsetCommitResponse (https://github.com/apache/kafka/pull/7296#discussion_r331656313, https://github.com/apache/kafka/pull/7296#discussion_r330816433)
Allow Consumer.offsetsForTimes() to take an IsolationLevel: https://issues.apache.org/jira/browse/KAFKA-8975 (https://github.com/apache/kafka/pull/7296#discussion_r330818899)

@mimaison Note the compilation failure:
06:06:20 /home/jenkins/jenkins-slave/workspace/kafka-pr-jdk11-scala2.12/core/src/main/scala/kafka/admin/ConsumerGroupCommand.scala:394: not found: type AlterOffsetsOptions
06:06:20                     withTimeoutMs(new AlterOffsetsOptions)

Thanks @hachikuji, fixed

@mimaison I see the recent comments were marked resolved, but I don't see the changes. Are you still working on an update?

Yes I started making the changes but I haven't had the time to finish them
yet. I'll push an update tomorrow or Friday.
Sorry for the delay.
On Wed, 9 Oct 2019, 21:42 Jason Gustafson<EMAIL_ADDRESS>wrote:

@mimaison https://github.com/mimaison I see the recent comments were
marked resolved, but I don't see the changes. Are you still working on an
update?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/kafka/pull/7296?email_source=notifications&email_token=AAG4TPZ33VDOHJ5Y6CS26I3QNY62PA5CNFSM4ITUTAJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAZJBFI#issuecomment-540184725,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAG4TP3I4FVD63QMS5UHKK3QNY62PANCNFSM4ITUTAJQ
.

@hachikuji I've pushed an update

Thanks @hachikuji for the feedback, I've pushed another update

Thanks @hachikuji, I've updated the PR and rebased on trunk

retest this pleasee

LGTM!

Amazing! Thanks all for the every efforts on this!

Thanks guys, starting the Spark integration part.


Add pp to similar tools

You can add Adrian's tool pp to similar tools section.
description of pp:

pp
a preprocessor
pp allows embedding sh code in files of any type by nesting it inside the #!\n token, where \n is a new line. That means that if you'd like a simple loop or an if inside an HTML file for instance, you could use pp.
https://adi.onl/pp.html

Done,  thanks for the note !


Retry RPM build but not the test

mvn clean package builds RPM
but then mvn verify builds it again, at can fail independently during that stage -- https://github.com/prestosql/presto/runs/776013216

2020-06-16T10:11:55.3010416Z [ERROR] Failed to execute goal ca.vanzyl.provisio.maven.plugins:provisio-maven-plugin:1.0.9:provision (unpack) on project presto-server-rpm: Error provisioning assembly. java.nio.file.NoSuchFileException: /home/runner/work/presto/presto/presto-server-rpm/target/classes/presto-server-336-SNAPSHOT/lib/antlr4-runtime-4.7.1.jar -> [Help 1]

closing for now. we can revisit if needed


Rebase with upstream master

I rebase to upstream master and added proper Default value for service.loadBalancerSourceRanges.

lgtm!