[ 1037.829768] GLBL_DSC_DAT1_RSVD_1                     [31,28]   0x0
[ 1037.829768] GLBL_DSC_DAT1_EVT_SPC_C2H                [27,22]   0x0
[ 1037.829769] GLBL_DSC_DAT1_EVT_SP_H2C                 [21,16]   0x0
[ 1037.829769] GLBL_DSC_DAT1_DSC_SPC_C2H                [15, 8]   0x0
[ 1037.829770] GLBL_DSC_DAT1_DSC_SPC_H2C                [ 7, 0]   0x0
[ 1037.829773] GLBL_DSC_ERR_LOG2                        0x27c     0x2800280  41943680
[ 1037.829774] GLBL_DSC_ERR_LOG2_OLD_PIDX               [31,16]   0x280
[ 1037.829774] GLBL_DSC_ERR_LOG2_NEW_PIDX               [15, 0]   0x280
[ 1037.829775] eqdma_hw_error_process detected DMA engine error
[ 1037.843411] onic:error_intr_handler: Error IRQ fired on Funtion#0: index=7, vector=272
[ 1037.843418] eqdma_hw_error_process: Global Err Reg(0x248) = 0x4
[ 1037.843420] addr = 0x00000254 val = 0x00100000
[ 1037.843426] GLBL_DSC_ERR_STS                         0x254     0x100000   1048576
[ 1037.843429] GLBL_DSC_ERR_STS_RSVD_1                  [31,26]   0x0
[ 1037.843431] GLBL_DSC_ERR_STS_PORT_ID                 [   25]   0x0
[ 1037.843432] GLBL_DSC_ERR_STS_SBE                     [   24]   0x0
[ 1037.843433] GLBL_DSC_ERR_STS_DBE                     [   23]   0x0
[ 1037.843435] GLBL_DSC_ERR_STS_RQ_CANCEL               [   22]   0x0
[ 1037.843436] GLBL_DSC_ERR_STS_DSC                     [   21]   0x0
[ 1037.843437] GLBL_DSC_ERR_STS_DMA                     [   20]   0x1
[ 1037.843439] GLBL_DSC_ERR_STS_FLR_CANCEL              [   19]   0x0
[ 1037.843440] GLBL_DSC_ERR_STS_RSVD_2                  [18,17]   0x0
[ 1037.843442] GLBL_DSC_ERR_STS_DAT_POISON              [   16]   0x0
[ 1037.843443] GLBL_DSC_ERR_STS_TIMEOUT                 [    9]   0x0
[ 1037.843444] GLBL_DSC_ERR_STS_FLR                     [    8]   0x0
[ 1037.843446] GLBL_DSC_ERR_STS_TAG                     [    6]   0x0
[ 1037.843447] GLBL_DSC_ERR_STS_ADDR                    [    5]   0x0
[ 1037.843449] GLBL_DSC_ERR_STS_PARAM                   [    4]   0x0
[ 1037.843450] GLBL_DSC_ERR_STS_BCNT                    [    3]   0x0
[ 1037.843451] GLBL_DSC_ERR_STS_UR_CA                   [    2]   0x0
[ 1037.843452] GLBL_DSC_ERR_STS_POISON                  [    1]   0x0
[ 1037.843458] GLBL_DSC_ERR_LOG0                        0x25c     0xc0000043 -1073741757
[ 1037.843459] GLBL_DSC_ERR_LOG0_VALID                  [   31]   0x1
[ 1037.843461] GLBL_DSC_ERR_LOG0_SEL                    [   30]   0x1
[ 1037.843462] GLBL_DSC_ERR_LOG0_RSVD_1                 [29,13]   0x0
[ 1037.843464] GLBL_DSC_ERR_LOG0_QID                    [12, 0]   0x43
[ 1037.843469] GLBL_DSC_ERR_LOG1                        0x260     0x280014   2621460
[ 1037.843470] GLBL_DSC_ERR_LOG1_RSVD_1                 [31,28]   0x0
[ 1037.843472] GLBL_DSC_ERR_LOG1_CIDX                   [27,12]   0x280
[ 1037.843473] GLBL_DSC_ERR_LOG1_RSVD_2                 [11, 9]   0x0
[ 1037.843475] GLBL_DSC_ERR_LOG1_SUB_TYPE               [ 8, 5]   0x0
[ 1037.843476] GLBL_DSC_ERR_LOG1_ERR_TYPE               [ 4, 0]   0x14
[ 1037.843481] GLBL_DSC_DBG_DAT0                        0x270     0x0        0
[ 1037.843483] GLBL_DSC_DAT0_RSVD_1                     [31,30]   0x0
[ 1037.843484] GLBL_DSC_DAT0_CTXT_ARB_DIR               [   29]   0x0
[ 1037.843485] GLBL_DSC_DAT0_CTXT_ARB_QID               [28,17]   0x0
[ 1037.843487] GLBL_DSC_DAT0_CTXT_ARB_REQ               [16,12]   0x0
[ 1037.843488] GLBL_DSC_DAT0_IRQ_FIFO_FL                [   11]   0x0
[ 1037.843490] GLBL_DSC_DAT0_TMSTALL                    [   10]   0x0
[ 1037.843491] GLBL_DSC_DAT0_RRQ_STALL                  [ 9, 8]   0x0
[ 1037.843493] GLBL_DSC_DAT0_RCP_FIFO_SPC_STALL         [ 7, 6]   0x0
[ 1037.843494] GLBL_DSC_DAT0_RRQ_FIFO_SPC_STALL         [ 5, 4]   0x0
[ 1037.843496] GLBL_DSC_DAT0_FAB_MRKR_RSP_STALL         [ 3, 2]   0x0
[ 1037.843497] GLBL_DSC_DAT0_DSC_OUT_STALL              [ 1, 0]   0x0
[ 1037.843501] GLBL_DSC_DBG_DAT1                        0x274     0x0        0
[ 1037.843503] GLBL_DSC_DAT1_RSVD_1                     [31,28]   0x0
[ 1037.843504] GLBL_DSC_DAT1_EVT_SPC_C2H                [27,22]   0x0
[ 1037.843506] GLBL_DSC_DAT1_EVT_SP_H2C                 [21,16]   0x0
[ 1037.843507] GLBL_DSC_DAT1_DSC_SPC_C2H                [15, 8]   0x0
[ 1037.843509] GLBL_DSC_DAT1_DSC_SPC_H2C                [ 7, 0]   0x0
[ 1037.843513] GLBL_DSC_ERR_LOG2                        0x27c     0x2800280  41943680
[ 1037.843515] GLBL_DSC_ERR_LOG2_OLD_PIDX               [31,16]   0x280
[ 1037.843516] GLBL_DSC_ERR_LOG2_NEW_PIDX               [15, 0]   0x280
[ 1037.843518] eqdma_hw_error_process detected DMA engine error
[ 1048.031802] onic:qdma_request_wait_for_cmpl: qdma3b000-MM-67: req 0x00000000b58b1766, R,4190208,0/65536000,0x0, done 0, err 0, tm 10000.
[ 1048.044054] onic:qdma_descq_dump: qdma3b000-MM-67: 0x43/0x43, desc sz 1024/0, pidx 639, cidx 640
[ 1048.044464] onic 0000:3b:00.0: reconic-mm: Close onic_cdev.

read log on <IP_ADDRESS>:
sudo env LD_LIBRARY_PATH=$LD_LIBRARY_PATH ./read -r <IP_ADDRESS> -i <IP_ADDRESS> -p /sys/bus/pci/devices/0000\:3b\:00.0/resource2 -z 128 -l host_mem -d /dev/reconic-mm -c -u 22222 -t 11111 --dst_qp 2 -g 2>&1 | tee client_debug.log
src_ip_str = <IP_ADDRESS>
dst_ip_str = <IP_ADDRESS>
Info: mac_addr_t = 00:0a:35:f7:81:e1
Info: PCIe resource file: /sys/bus/pci/devices/0000:3b:00.0/resource2
Info: QP allocated at: host_mem
Info: Device - /dev/reconic-mm
Info: src_ip = <IP_ADDRESS>
Info: Found network interface: enp59s0
Info: mac_addr_t = 00:0a:35:54:60:02
Info: Creating rn_dev
/users/qianyich/RecoNIC/lib/reconic.c:301:create_rn_dev(): Info: scr(=4)) file open successfully
create_rn_dev - testing2
/users/qianyich/RecoNIC/lib/reconic.c:146:get_buffer_paddr(): Info: get_buffer_paddr - Page frame: 0x2f6b400
/users/qianyich/RecoNIC/lib/reconic.c:151:get_buffer_paddr(): Info: get_buffer_paddr - distance from page boundary: 0x0
/users/qianyich/RecoNIC/lib/reconic.c:155:get_buffer_paddr(): Info: get_buffer_paddr - Physical address of buffer: 0x2f6b400000
Info: pre-allocated hugepage buffer vir addr = 0x7f93bf000000, physical addr = 0x2f6b400000
Info: Configuring 8 windows in QDMA AXI bridge BDF, each has 128GB mapping
/users/qianyich/RecoNIC/lib/reconic.c:198:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_ADDR_TRANSLATE_ADDR_LSB=0x16420, bdf_addr_low=0x0
/users/qianyich/RecoNIC/lib/reconic.c:199:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_ADDR_TRANSLATE_ADDR_MSB=0x16424, bdf_addr_high=0x0
/users/qianyich/RecoNIC/lib/reconic.c:200:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_MAP_CONTROL_ADDR=0x16430, bdf_win_config=0xc2000000
/users/qianyich/RecoNIC/lib/reconic.c:198:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_ADDR_TRANSLATE_ADDR_LSB=0x16440, bdf_addr_low=0x0
/users/qianyich/RecoNIC/lib/reconic.c:199:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_ADDR_TRANSLATE_ADDR_MSB=0x16444, bdf_addr_high=0x20
/users/qianyich/RecoNIC/lib/reconic.c:200:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_MAP_CONTROL_ADDR=0x16450, bdf_win_config=0xc2000000
/users/qianyich/RecoNIC/lib/reconic.c:198:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_ADDR_TRANSLATE_ADDR_LSB=0x16460, bdf_addr_low=0x0
/users/qianyich/RecoNIC/lib/reconic.c:199:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_ADDR_TRANSLATE_ADDR_MSB=0x16464, bdf_addr_high=0x40
/users/qianyich/RecoNIC/lib/reconic.c:200:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_MAP_CONTROL_ADDR=0x16470, bdf_win_config=0xc2000000
/users/qianyich/RecoNIC/lib/reconic.c:198:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_ADDR_TRANSLATE_ADDR_LSB=0x16480, bdf_addr_low=0x0
/users/qianyich/RecoNIC/lib/reconic.c:199:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_ADDR_TRANSLATE_ADDR_MSB=0x16484, bdf_addr_high=0x60
/users/qianyich/RecoNIC/lib/reconic.c:200:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_MAP_CONTROL_ADDR=0x16490, bdf_win_config=0xc2000000
/users/qianyich/RecoNIC/lib/reconic.c:198:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_ADDR_TRANSLATE_ADDR_LSB=0x164a0, bdf_addr_low=0x0
/users/qianyich/RecoNIC/lib/reconic.c:199:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_ADDR_TRANSLATE_ADDR_MSB=0x164a4, bdf_addr_high=0x80
/users/qianyich/RecoNIC/lib/reconic.c:200:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_MAP_CONTROL_ADDR=0x164b0, bdf_win_config=0xc2000000
/users/qianyich/RecoNIC/lib/reconic.c:198:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_ADDR_TRANSLATE_ADDR_LSB=0x164c0, bdf_addr_low=0x0
/users/qianyich/RecoNIC/lib/reconic.c:199:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_ADDR_TRANSLATE_ADDR_MSB=0x164c4, bdf_addr_high=0xa0
/users/qianyich/RecoNIC/lib/reconic.c:200:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_MAP_CONTROL_ADDR=0x164d0, bdf_win_config=0xc2000000
/users/qianyich/RecoNIC/lib/reconic.c:198:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_ADDR_TRANSLATE_ADDR_LSB=0x164e0, bdf_addr_low=0x0
/users/qianyich/RecoNIC/lib/reconic.c:199:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_ADDR_TRANSLATE_ADDR_MSB=0x164e4, bdf_addr_high=0xc0
/users/qianyich/RecoNIC/lib/reconic.c:200:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_MAP_CONTROL_ADDR=0x164f0, bdf_win_config=0xc2000000
/users/qianyich/RecoNIC/lib/reconic.c:198:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_ADDR_TRANSLATE_ADDR_LSB=0x16500, bdf_addr_low=0x0
/users/qianyich/RecoNIC/lib/reconic.c:199:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_ADDR_TRANSLATE_ADDR_MSB=0x16504, bdf_addr_high=0xe0
/users/qianyich/RecoNIC/lib/reconic.c:200:config_rn_dev_axib_bdf(): [BDF] AXIB_BDF_MAP_CONTROL_ADDR=0x16510, bdf_win_config=0xc2000000
Info: CREATE RDMA DEVICE
/users/qianyich/RecoNIC/lib/reconic.c:146:get_buffer_paddr(): Info: get_buffer_paddr - Page frame: 0x2f6b400
/users/qianyich/RecoNIC/lib/reconic.c:151:get_buffer_paddr(): Info: get_buffer_paddr - distance from page boundary: 0x0
/users/qianyich/RecoNIC/lib/reconic.c:155:get_buffer_paddr(): Info: get_buffer_paddr - Physical address of buffer: 0x2f6b400000
/users/qianyich/RecoNIC/lib/reconic.c:232:allocate_rdma_buffer(): Info: allocated host buffer vir addr = 0x7f93bf000000, physical addr = 2f6b400000, rn_dev->buffer_offset = 0x200000
/users/qianyich/RecoNIC/lib/reconic.c:233:allocate_rdma_buffer(): Info: allocate_rdma_buffer - successfully allocated rdma host buffer
/users/qianyich/RecoNIC/lib/reconic.c:146:get_buffer_paddr(): Info: get_buffer_paddr - Page frame: 0x2f6b600
/users/qianyich/RecoNIC/lib/reconic.c:151:get_buffer_paddr(): Info: get_buffer_paddr - distance from page boundary: 0x0
/users/qianyich/RecoNIC/lib/reconic.c:155:get_buffer_paddr(): Info: get_buffer_paddr - Physical address of buffer: 0x2f6b600000
/users/qianyich/RecoNIC/lib/reconic.c:232:allocate_rdma_buffer(): Info: allocated host buffer vir addr = 0x7f93bf200000, physical addr = 2f6b600000, rn_dev->buffer_offset = 0x1200000
/users/qianyich/RecoNIC/lib/reconic.c:233:allocate_rdma_buffer(): Info: allocate_rdma_buffer - successfully allocated rdma host buffer
/users/qianyich/RecoNIC/lib/reconic.c:146:get_buffer_paddr(): Info: get_buffer_paddr - Page frame: 0x2f6a600
/users/qianyich/RecoNIC/lib/reconic.c:151:get_buffer_paddr(): Info: get_buffer_paddr - distance from page boundary: 0x0
/users/qianyich/RecoNIC/lib/reconic.c:155:get_buffer_paddr(): Info: get_buffer_paddr - Physical address of buffer: 0x2f6a600000
/users/qianyich/RecoNIC/lib/reconic.c:232:allocate_rdma_buffer(): Info: allocated host buffer vir addr = 0x7f93c0200000, physical addr = 2f6a600000, rn_dev->buffer_offset = 0x1202000
/users/qianyich/RecoNIC/lib/reconic.c:233:allocate_rdma_buffer(): Info: allocate_rdma_buffer - successfully allocated rdma host buffer
/users/qianyich/RecoNIC/lib/reconic.c:146:get_buffer_paddr(): Info: get_buffer_paddr - Page frame: 0x2f6a602
/users/qianyich/RecoNIC/lib/reconic.c:151:get_buffer_paddr(): Info: get_buffer_paddr - distance from page boundary: 0x0
/users/qianyich/RecoNIC/lib/reconic.c:155:get_buffer_paddr(): Info: get_buffer_paddr - Physical address of buffer: 0x2f6a602000
/users/qianyich/RecoNIC/lib/reconic.c:232:allocate_rdma_buffer(): Info: allocated host buffer vir addr = 0x7f93c0202000, physical addr = 2f6a602000, rn_dev->buffer_offset = 0x1212000
/users/qianyich/RecoNIC/lib/reconic.c:233:allocate_rdma_buffer(): Info: allocate_rdma_buffer - successfully allocated rdma host buffer
/users/qianyich/RecoNIC/lib/reconic.c:146:get_buffer_paddr(): Info: get_buffer_paddr - Page frame: 0x2f6a612
/users/qianyich/RecoNIC/lib/reconic.c:151:get_buffer_paddr(): Info: get_buffer_paddr - distance from page boundary: 0x0
/users/qianyich/RecoNIC/lib/reconic.c:155:get_buffer_paddr(): Info: get_buffer_paddr - Physical address of buffer: 0x2f6a612000
/users/qianyich/RecoNIC/lib/reconic.c:232:allocate_rdma_buffer(): Info: allocated host buffer vir addr = 0x7f93c0212000, physical addr = 2f6a612000, rn_dev->buffer_offset = 0x1222000
/users/qianyich/RecoNIC/lib/reconic.c:233:allocate_rdma_buffer(): Info: allocate_rdma_buffer - successfully allocated rdma host buffer
Info: OPEN RDMA DEVICE
/users/qianyich/RecoNIC/lib/rdma_api.c:186:config_rdma_global_csr(): [Register] RN_RDMA_GCSR_DATBUFBA=0x600a0, value=0x6b600000
/users/qianyich/RecoNIC/lib/rdma_api.c:188:config_rdma_global_csr(): [Register] RN_RDMA_GCSR_DATBUFBAMSB=0x600a4, value=0x2f
/users/qianyich/RecoNIC/lib/rdma_api.c:190:config_rdma_global_csr(): [Register] RN_RDMA_GCSR_DATBUFSZ=0x600a8, value=0x10001000
/users/qianyich/RecoNIC/lib/rdma_api.c:193:config_rdma_global_csr(): [Register] RN_RDMA_GCSR_IPKTERRQBA=0x60088, value=0x6a600000
/users/qianyich/RecoNIC/lib/rdma_api.c:195:config_rdma_global_csr(): [Register] RN_RDMA_GCSR_IPKTERRQBAMSB=0x6008c, value=0x2f
/users/qianyich/RecoNIC/lib/rdma_api.c:197:config_rdma_global_csr(): [Register] RN_RDMA_GCSR_ERRBUFSZ=0x60090, value=0x2000
/users/qianyich/RecoNIC/lib/rdma_api.c:200:config_rdma_global_csr(): [Register] RN_RDMA_GCSR_ERRBUFBA=0x60060, value=0x6a602000
/users/qianyich/RecoNIC/lib/rdma_api.c:202:config_rdma_global_csr(): [Register] RN_RDMA_GCSR_ERRBUFBAMSB=0x60064, value=0x2f
/users/qianyich/RecoNIC/lib/rdma_api.c:204:config_rdma_global_csr(): [Register] RN_RDMA_GCSR_ERRBUFSZ=0x60068, value=0x1000100
/users/qianyich/RecoNIC/lib/rdma_api.c:207:config_rdma_global_csr(): [Register] RN_RDMA_GCSR_RESPERRPKTBA=0x600b0, value=0x6a612000
/users/qianyich/RecoNIC/lib/rdma_api.c:209:config_rdma_global_csr(): [Register] RN_RDMA_GCSR_RESPERRPKTBAMSB=0x600b4, value=0x2f
/users/qianyich/RecoNIC/lib/rdma_api.c:211:config_rdma_global_csr(): [Register] RN_RDMA_GCSR_RESPERRSZ=0x600b8, value=0x10000
/users/qianyich/RecoNIC/lib/rdma_api.c:213:config_rdma_global_csr(): [Register] RN_RDMA_GCSR_RESPERRSZMSB=0x600bc, value=0x0
/users/qianyich/RecoNIC/lib/rdma_api.c:217:config_rdma_global_csr(): [Register] RN_RDMA_GCSR_INTEN=0x60180, value=0xff
/users/qianyich/RecoNIC/lib/rdma_api.c:221:config_rdma_global_csr(): [Register] RN_RDMA_GCSR_MACXADDLSB=0x60010, value=0x35546002
/users/qianyich/RecoNIC/lib/rdma_api.c:223:config_rdma_global_csr(): [Register] RN_RDMA_GCSR_MACXADDMSB=0x60014, value=0xa
/users/qianyich/RecoNIC/lib/rdma_api.c:227:config_rdma_global_csr(): [Register] RN_RDMA_GCSR_IPV4XADD=0x60070, value=0xc0643301
/users/qianyich/RecoNIC/lib/rdma_api.c:230:config_rdma_global_csr(): [Register] RN_RDMA_GCSR_XRNICCONF=0x60000, value=0x56ce0821
/users/qianyich/RecoNIC/lib/rdma_api.c:233:config_rdma_global_csr(): [Register] RN_RDMA_GCSR_XRNICADCONF=0x60004, value=0xa0004
Info: RDMA global control status registers are configured.
Info: rdma_dev opened
Info: ALLOCATE PD
/users/qianyich/RecoNIC/lib/rdma_api.c:254:allocate_rdma_pd(): [Register] RN_RDMA_PDT_PDPDNUM=0x40000, pd_num=0, value=0x0
Info: OPEN DEVICE FILE
Info: ALLOCATE RDMA QP
Allocating qp->sq
/users/qianyich/RecoNIC/lib/rdma_api.c:437:allocate_rdma_qp(): sq_size = 32768, cq_size = 2048, rq_size 262144, buf_location = host_mem
/users/qianyich/RecoNIC/lib/reconic.c:146:get_buffer_paddr(): Info: get_buffer_paddr - Page frame: 0x2f6a622
/users/qianyich/RecoNIC/lib/reconic.c:151:get_buffer_paddr(): Info: get_buffer_paddr - distance from page boundary: 0x0
/users/qianyich/RecoNIC/lib/reconic.c:155:get_buffer_paddr(): Info: get_buffer_paddr - Physical address of buffer: 0x2f6a622000
/users/qianyich/RecoNIC/lib/reconic.c:232:allocate_rdma_buffer(): Info: allocated host buffer vir addr = 0x7f93c0222000, physical addr = 2f6a622000, rn_dev->buffer_offset = 0x122a000
/users/qianyich/RecoNIC/lib/reconic.c:233:allocate_rdma_buffer(): Info: allocate_rdma_buffer - successfully allocated rdma host buffer
Allocating qp->cq
/users/qianyich/RecoNIC/lib/reconic.c:146:get_buffer_paddr(): Info: get_buffer_paddr - Page frame: 0x2f6a62a
/users/qianyich/RecoNIC/lib/reconic.c:151:get_buffer_paddr(): Info: get_buffer_paddr - distance from page boundary: 0x0
/users/qianyich/RecoNIC/lib/reconic.c:155:get_buffer_paddr(): Info: get_buffer_paddr - Physical address of buffer: 0x2f6a62a000
/users/qianyich/RecoNIC/lib/reconic.c:232:allocate_rdma_buffer(): Info: allocated host buffer vir addr = 0x7f93c022a000, physical addr = 2f6a62a000, rn_dev->buffer_offset = 0x122a800
/users/qianyich/RecoNIC/lib/reconic.c:233:allocate_rdma_buffer(): Info: allocate_rdma_buffer - successfully allocated rdma host buffer
Allocating qp->rq
/users/qianyich/RecoNIC/lib/reconic.c:146:get_buffer_paddr(): Info: get_buffer_paddr - Page frame: 0x2f6a62b
/users/qianyich/RecoNIC/lib/reconic.c:151:get_buffer_paddr(): Info: get_buffer_paddr - distance from page boundary: 0x0
/users/qianyich/RecoNIC/lib/reconic.c:155:get_buffer_paddr(): Info: get_buffer_paddr - Physical address of buffer: 0x2f6a62b000
/users/qianyich/RecoNIC/lib/reconic.c:232:allocate_rdma_buffer(): Info: allocated host buffer vir addr = 0x7f93c022b000, physical addr = 2f6a62b000, rn_dev->buffer_offset = 0x126b000
/users/qianyich/RecoNIC/lib/reconic.c:233:allocate_rdma_buffer(): Info: allocate_rdma_buffer - successfully allocated rdma host buffer
Info: queue pair setting is done! Configuring RDMA per-queu CSR registers
/users/qianyich/RecoNIC/lib/rdma_api.c:487:allocate_rdma_qp(): DEBUG: rdma_dev->rn_dev->axil_ctl = 0x7f93df1fa000, rdma_dev->axil_ctl = 0x7f93df1fa000
/users/qianyich/RecoNIC/lib/rdma_api.c:502:allocate_rdma_qp(): [Register] RN_RDMA_QCSR_IPDESADDR1i=0x60360, qpid=2, value=0xc0643401
/users/qianyich/RecoNIC/lib/rdma_api.c:509:allocate_rdma_qp(): [Register] RN_RDMA_QCSR_MACDESADDLSBi=0x60350, qpid=2, value=0x35f781e1
/users/qianyich/RecoNIC/lib/rdma_api.c:516:allocate_rdma_qp(): [Register] RN_RDMA_QCSR_MACDESADDMSBi=0x60354, qpid=2, value=0xa
/users/qianyich/RecoNIC/lib/rdma_api.c:521:allocate_rdma_qp(): DEBUG: win_size_high = 0xff, win_size_low = 0xffffffff
/users/qianyich/RecoNIC/lib/rdma_api.c:539:allocate_rdma_qp(): [Register] RN_RDMA_QCSR_SQBAi=0x60310, qpid=2, value=0x6a622000
/users/qianyich/RecoNIC/lib/rdma_api.c:546:allocate_rdma_qp(): [Register] RN_RDMA_QCSR_SQBAMSBi=0x603c8, qpid=2, value=0x2f
/users/qianyich/RecoNIC/lib/rdma_api.c:550:allocate_rdma_qp(): DEBUG: qp->sq->dma_addr = 0x2f6a622000, sq_addr_msb = 0x2f, sq_addr_lsb = 0x6a622000
/users/qianyich/RecoNIC/lib/rdma_api.c:568:allocate_rdma_qp(): [Register] RN_RDMA_QCSR_CQBAi=0x60318, qpid=2, value=0x6a62a000
/users/qianyich/RecoNIC/lib/rdma_api.c:575:allocate_rdma_qp(): [Register] RN_RDMA_QCSR_CQBAMSBi=0x603d0, qpid=2, value=0x2f
/users/qianyich/RecoNIC/lib/rdma_api.c:579:allocate_rdma_qp(): DEBUG: qp->cq->dma_addr = 0x2f6a62a000, cq_addr_msb = 0x2f, cq_addr_lsb = 0x6a62a000
/users/qianyich/RecoNIC/lib/rdma_api.c:597:allocate_rdma_qp(): [Register] RN_RDMA_QCSR_RQBAi=0x60308, qpid=2, value=0x6a62b000
/users/qianyich/RecoNIC/lib/rdma_api.c:604:allocate_rdma_qp(): [Register] RN_RDMA_QCSR_RQBAMSBi=0x603c0, qpid=2, value=0x2f
/users/qianyich/RecoNIC/lib/rdma_api.c:608:allocate_rdma_qp(): DEBUG: qp->rq->dma_addr = 0x2f6a62b000, rq_addr_msb = 0x2f, rq_addr_lsb = 0x6a62b000
/users/qianyich/RecoNIC/lib/rdma_api.c:617:allocate_rdma_qp(): [Register] RN_RDMA_QCSR_CQDBADDi=0x60328, qpid=2, value=0x6b400000
/users/qianyich/RecoNIC/lib/rdma_api.c:624:allocate_rdma_qp(): [Register] RN_RDMA_QCSR_CQDBADDMSBi=0x6032c, qpid=2, value=0x2f
/users/qianyich/RecoNIC/lib/rdma_api.c:625:allocate_rdma_qp(): DEBUG: cq_cidb_addr = 0x2f6b400000
/users/qianyich/RecoNIC/lib/rdma_api.c:634:allocate_rdma_qp(): [Register] RN_RDMA_QCSR_RQWPTRDBADDi=0x60320, qpid=2, value=0x6b400020
/users/qianyich/RecoNIC/lib/rdma_api.c:641:allocate_rdma_qp(): [Register] RN_RDMA_QCSR_RQWPTRDBADDMSBi=0x60324, qpid=2, value=0x2f
/users/qianyich/RecoNIC/lib/rdma_api.c:642:allocate_rdma_qp(): DEBUG: rq_cidb_addr = 0x2f6b400020
/users/qianyich/RecoNIC/lib/rdma_api.c:651:allocate_rdma_qp(): [Register] RN_RDMA_QCSR_DESTQPCONFi=0x60348, qpid=2, value=0x2
/users/qianyich/RecoNIC/lib/rdma_api.c:660:allocate_rdma_qp(): [Register] RN_RDMA_QCSR_QDEPTHi=0x6033c, qpid=2, value=0x400040
/users/qianyich/RecoNIC/lib/rdma_api.c:707:allocate_rdma_qp(): [Register] RN_RDMA_QCSR_QPCONFi=0x60300, qpid=2, value=0x200043d
/users/qianyich/RecoNIC/lib/rdma_api.c:721:allocate_rdma_qp(): [Register] RN_RDMA_QCSR_QPADVCONFi=0x60304, qpid=2, value=0x12344000
/users/qianyich/RecoNIC/lib/rdma_api.c:730:allocate_rdma_qp(): [Register] RN_RDMA_QCSR_PDi=0x603b0, qpid=2, value=0x0
Info: allocate_rdma_qp - Successfully allocated a rdma qp
Info: CONFIGURE PSN
[Register] RN_RDMA_QCSR_LSTRQREQi=0x60344, qpid=2, value=0xa000abc
[Register] RN_RDMA_QCSR_SQPSNi=0x60340, qpid=2, value=0xabd
payload_size = 128, payload_size>>2 = 32
Info: Client is connecting to a remote server
Info: Client is connected to a remote server
Info: client received remote offset of A = 0xa350000000000000
/users/qianyich/RecoNIC/lib/reconic.c:256:allocate_rdma_buffer(): Info: allocated device buffer physical addr = a350000000000000, rn_dev->dev_buffer_offset = 0x80
/users/qianyich/RecoNIC/lib/reconic.c:258:allocate_rdma_buffer(): Info: allocate_rdma_buffer - successfully allocated rdma device buffer
Info: creating an RDMA read WQE for getting data
/users/qianyich/RecoNIC/lib/rdma_api.c:769:create_a_wqe(): Info: WQE mem_buffer = 0xa350000000000000, masked_mem_buffer = 0xa350000000000000
/users/qianyich/RecoNIC/lib/rdma_api.c:796:create_a_wqe(): [WQE] wrid=0x0
/users/qianyich/RecoNIC/lib/rdma_api.c:797:create_a_wqe(): [WQE] laddr_low=0x0
/users/qianyich/RecoNIC/lib/rdma_api.c:798:create_a_wqe(): [WQE] laddr_high=0xa3500000
/users/qianyich/RecoNIC/lib/rdma_api.c:799:create_a_wqe(): [WQE] length=0x80
/users/qianyich/RecoNIC/lib/rdma_api.c:800:create_a_wqe(): [WQE] opcode=0x4
/users/qianyich/RecoNIC/lib/rdma_api.c:801:create_a_wqe(): [WQE] remote_offset_low=0x0
/users/qianyich/RecoNIC/lib/rdma_api.c:802:create_a_wqe(): [WQE] remote_offset_high=0xa3500000
/users/qianyich/RecoNIC/lib/rdma_api.c:803:create_a_wqe(): [WQE] r_key=0x8
/users/qianyich/RecoNIC/lib/rdma_api.c:804:create_a_wqe(): [WQE] send_small_payload0=0x0
/users/qianyich/RecoNIC/lib/rdma_api.c:805:create_a_wqe(): [WQE] send_small_payload1=0x0
/users/qianyich/RecoNIC/lib/rdma_api.c:806:create_a_wqe(): [WQE] send_small_payload2=0x0
/users/qianyich/RecoNIC/lib/rdma_api.c:807:create_a_wqe(): [WQE] send_small_payload3=0x0
/users/qianyich/RecoNIC/lib/rdma_api.c:808:create_a_wqe(): [WQE] immdt_data=0x0
/users/qianyich/RecoNIC/lib/rdma_api.c:875:rdma_post_send(): DEBUG: Reading hardware SQPIi (0x60338) = 0x0
/users/qianyich/RecoNIC/lib/rdma_api.c:876:rdma_post_send(): DEBUG: original qp->sq_pidb = 0x0
/users/qianyich/RecoNIC/lib/rdma_api.c:882:rdma_post_send(): [Register] RN_RDMA_QCSR_SQPIi=0x60338, qpid=2, value=0x1
/users/qianyich/RecoNIC/lib/rdma_api.c:883:rdma_post_send(): DEBUG: Update hardware sq db idx from software = 1
/users/qianyich/RecoNIC/lib/rdma_api.c:884:rdma_post_send(): DEBUG: Reading hardware SQPIi (0x60338) = 0x1
/users/qianyich/RecoNIC/lib/rdma_api.c:844:poll_cq_cidb(): [Register] RN_RDMA_QCSR_CQHEADi=0x60330, qpid=2, value=0x0
/users/qianyich/RecoNIC/lib/rdma_api.c:846:poll_cq_cidb(): DEBUG: before polling: sq_cidb = 0; Polling CQ CIDB = 0
/users/qianyich/RecoNIC/lib/rdma_api.c:857:poll_cq_cidb(): DEBUG: after polling: sq_cidb = 0; Polling CQ CIDB = 1
Successfully sent an RDMA read operation
Info: Dump register values for debug purpose
Info: [RN_RDMA_GCSR_ERRBUFWPTR      = 0x6006c] = 0x0
Info: [RN_RDMA_GCSR_IPKTERRQWPTR    = 0x60094] = 0x0
Info: [RN_RDMA_GCSR_INSRRPKTCNT     = 0x60100] = 0x20004
Info: [RN_RDMA_GCSR_INAMPKTCNT      = 0x60104] = 0x1
Info: [RN_RDMA_GCSR_OUTIOPKTCNT     = 0x60108] = 0x40000
Info: [RN_RDMA_GCSR_OUTAMPKTCNT     = 0x6010c] = 0x1
Info: [RN_RDMA_GCSR_LSTINPKT        = 0x60110] = 0xabd0210
Info: [RN_RDMA_GCSR_LSTOUTPKT       = 0x60114] = 0x157a204
Info: [RN_RDMA_GCSR_ININVDUPCNT     = 0x60118] = 0x0
Info: [RN_RDMA_GCSR_INNCKPKTSTS     = 0x6011c] = 0x0
Info: [RN_RDMA_GCSR_OUTRNRPKTSTS    = 0x60120] = 0x0
Info: [RN_RDMA_GCSR_WQEPROCSTS      = 0x60124] = 0x12122000
Info: [RN_RDMA_GCSR_QPMSTS          = 0x6012c] = 0x40002
Info: [RN_RDMA_GCSR_INALLDRPPKTCNT  = 0x60130] = 0xe0000
Info: [RN_RDMA_GCSR_INNAKPKTCNT     = 0x60134] = 0x0
Info: [RN_RDMA_GCSR_OUTNAKPKTCNT    = 0x60138] = 0x0
Info: [RN_RDMA_GCSR_RESPHNDSTS      = 0x6013c] = 0x10f02
Info: [RN_RDMA_GCSR_RETRYCNTSTS     = 0x60140] = 0x0
Info: [RN_RDMA_GCSR_INCNPPKTCNT     = 0x60174] = 0x0
Info: [RN_RDMA_GCSR_OUTCNPPKTCNT    = 0x60178] = 0x0
Info: [RN_RDMA_GCSR_OUTRDRSPPKTCNT  = 0x6017c] = 0x6
Info: [RN_RDMA_GCSR_INTSTS          = 0x60184] = 0x10
Info: [RN_RDMA_GCSR_RQINTSTS1       = 0x60190] = 0x0
Info: [RN_RDMA_GCSR_RQINTSTS2       = 0x60194] = 0x0
Info: [RN_RDMA_GCSR_RQINTSTS3       = 0x60198] = 0x0
Info: [RN_RDMA_GCSR_RQINTSTS4       = 0x6019c] = 0x0
Info: [RN_RDMA_GCSR_RQINTSTS5       = 0x601a0] = 0x0
Info: [RN_RDMA_GCSR_RQINTSTS6       = 0x601a4] = 0x0
Info: [RN_RDMA_GCSR_RQINTSTS7       = 0x601a8] = 0x0
Info: [RN_RDMA_GCSR_RQINTSTS8       = 0x601ac] = 0x0
Info: [RN_RDMA_GCSR_CQINTSTS1       = 0x601b0] = 0x4
Info: [RN_RDMA_GCSR_CQINTSTS2       = 0x601b4] = 0x0
Info: [RN_RDMA_GCSR_CQINTSTS3       = 0x601b8] = 0x0
Info: [RN_RDMA_GCSR_CQINTSTS4       = 0x601bc] = 0x0
Info: [RN_RDMA_GCSR_CQINTSTS5       = 0x601c0] = 0x0
Info: [RN_RDMA_GCSR_CQINTSTS6       = 0x601c4] = 0x0
Info: [RN_RDMA_GCSR_CQINTSTS7       = 0x601c8] = 0x0
Info: [RN_RDMA_GCSR_CQINTSTS8       = 0x601cc] = 0x0
Info: [RN_RDMA_QCSR_CQHEADi         = 0x60330] = 0x1
Info: [RN_RDMA_QCSR_STATSSNi        = 0x60380] = 0x4
Info: [RN_RDMA_QCSR_STATMSNi        = 0x60384] = 0x0
Info: [RN_RDMA_QCSR_STATQPi         = 0x60388] = 0x1f0600
Info: [RN_RDMA_QCSR_STATCURSQPTRi   = 0x6038c] = 0x1
Info: [RN_RDMA_QCSR_STATRESPSNi     = 0x60390] = 0xabd
Info: [RN_RDMA_QCSR_STATRQBUFCAi    = 0x60394] = 0x6a62b000
Info: [RN_RDMA_QCSR_STATWQEi        = 0x60398] = 0x0
Info: [RN_RDMA_QCSR_STATRQPIDBi     = 0x6039c] = 0x0
Info: [RN_RDMA_QCSR_STATRQBUFCAMSBi = 0x603d8] = 0x2f
Info: [RN_RDMA_QCSR_SQPIi           = 0x60338] = 0x1

Info: All data has been received!
Info: buffer physical address is 0xa350000000000000
Info: Time spent 8.531000 usec, size = 128 bytes, Bandwidth = 0.120033 gigabits/sec
Info: The value of rc is 128
Info: CHECK RECEIVED DATA
Error: received data mismatched: recv[0]=541065216, sw_golden[0]=0
/users/qianyich/RecoNIC/lib/rdma_api.c:1088:destroy_rdma_qp(): [DEBUG] Destroying dev: 0x7f93df1fa000, RN_RDMA_QCSR_CQHEADi=0x60330, qpid=2, value=0x0
/users/qianyich/RecoNIC/lib/rdma_api.c:1093:destroy_rdma_qp(): [DEBUG] Destroying dev: 0x7f93df1fa000, RN_RDMA_QCSR_CQHEADi=0x60330, qpid=2, value=0x0
/users/qianyich/RecoNIC/lib/rdma_api.c:1101:destroy_rdma_qp(): [DEBUG] Destroying dev: 0x7f93df1fa000, RN_RDMA_QCSR_CQHEADi=0x60330, qpid=2, value=0x0

@zhguanw-amd I think, at this point, it is just some bugs in the test programs. RecoNIC is a bit fragile, and any small mistakes in the code could trap the device in an erroneous state, and the pain is that it can never be recovered unless we reprogram the board. BTW, I think the hardware design is ok on U280. We can merge that into the repo if you want.

Commenting out the if block in onic_main.c did work. Just let you know if you want to change it in the main branch.

@qianyich QP fatal recovery is a bug in the rdma IP, which is fixed in 4.0 version. I'll push this newer version when I have time.
The above QDMA issue is related to QDMA MM and ST channels mapping. You can revert back to the onic-driver in commit "9e4f0b74bc69744d6d807115e9a23705ba967dbb". But in this commit, there will be around 2-3% ping packet loss due to pid assigned to netdev exceeding 64 occasionally. The latter pushes are used to fix this isse, but seems introducing other qdma problems.

@zhguanw-amd Should I just wait for the new release?
I found that QPN, PSN, and rkey are hard coded in the tests. Does RecoNIC provide APIs that generate QPN, rkey, PSN, etc? RNICs from other vendors usually have their own algorithms to generate QPN, etc. Otherwise, it could be insecure, although it is still insecure with some algorithms.

@qianyich For the public release with new RDMA IP, it might be around June or July this year, as we need to upgrade Vivado version to support the new IP. And we also need to change current QDMA due to Vivado upgrade.
Regarding QPN, PSN and rkey, what we provide in the tests is just a showcase to demonstrate how to use RecoNIC and its RDMA via user-space APIs. Designers or users can change it according to their requirements. For example, security concerns you have. I'll leave this to developers if using this libreconic.
More standard usage would be to go through RDMA-core library, which abstracts those variables from users. We have a version at the moment. But for public release, it would take longer time.
It seems most of the issues have been addressed. I'm going to close this thread. Feel free to open another threads if you have more questions.


libtins: 4.0 -> 4.2 / compactor: 0.11.1 -> 0.12.2

Motivation for this change
Version updates
Fix compactor builds (currently failing on Hydra)
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
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 nix-review --run "nix-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)
[x] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nix-review pr 62090 on NixOS

2 package were build:

compactor
libtins


did it support data validation?

Yes, based on openpyxl support. The TableColumns accepts them trough the argument "data_validation". See the ChoiceColumn for an example of usage.


ADR: Block Data Propagation

Summary
A lot was discussed and said about block propagation (during consensus and in other cases) already. We should capture the decision on how to move forward with the implementation in an ADR.
Expectation / Details
The main purpose of this ADR is to focus on how to get the MVP out of the door (#381). It's OK if the initial design takes some shortcuts to get there faster if this does not introduce (substantial) technical debt.
Additionally, it can and should try to capture as much as possible from the different discussed approaches and tradeoffs. Similarly, it could touch upon future optimizations for iterations right after the MVP (nice-to-have).
If helpful, explorative implementation in parallel to the ADR is encouraged. At this stage, ideally a tracer-bullet and not a prototype. Where necessary a quickly written spike to verify the feasibility of the proposed solution can also be a good idea.
Some topics that could be part of this adr:

"pull vs push" based (https://docs.google.com/document/d/1mzfU2Ojlt1A5ucb1j_J5TfbIKcblF-9c2QnBRIZg8dk)
tendermint's p2p package in the context of block gossiping and reactors
libp2p's pubsusb
granularity of the gossiped data (shares, rows)?
(how) does this impact other components, particularly other p2p components, e.g. DAS?
relation to adr 001 (see below)

Difference to ADR 001
ADR 001 was written under the assumption that validators will also do DAS. Hence, every node-type could have used the ipld API RetrieveBlockData. Now, that we pivoted to removing that node-type (https://github.com/lazyledger/lazyledger-specs/pull/177#pullrequestreview-675719406), block propagation can and should be revisted. Particularly, during consensus, where it remains important that validators receive the block in a timely manner.
References and Context

a relatively vague and slightly confusing high-level issue about how the implementation might look like exists: #85
related discussion: https://github.com/lazyledger/lazyledger-core/discussions/384 (most discussions about this happened in slack / discord though)
draft PR: https://github.com/lazyledger/lazyledger-core/pull/293
adr001: https://github.com/lazyledger/lazyledger-core/blob/master/docs/lazy-adr/adr-001-block-propagation.md

@liamsi, regarding the granularity of the gossiped data. Some time ago you mentioned that gossiping BlockParts in Tendermint wasn't the best idea. The thing I wonder about is full-block data gossiping vs rows. I think the BlockParts thing is related here, so can you pls share your insights on that.

Some time ago you mentioned that gossiping BlockParts in Tendermint wasn't the best idea.

Yeah, gossiping block parts, at least in its current form, is not the best idea because we chunk the block differently already (into erasure coded shares). So IMO, we should stick to one approach.

The thing I wonder about is full-block data gossiping vs rows.

My intuition here is that gossiping rows is the best granularity: on the receiving side, you could check if the row you got matches a CID in the DAHeader (otherwise someone is giving you garbage data, e.g. to DoS your node). Remember that blocks could become potentially very large and we don't want to wait for the whole block until making the decision if the block matches the commitment in the header (or DAHeader) or not.
An alternative to gossiping rows could be gossiping shares. This would be more similar to the current BlockParts. But then, we would need to give the inclusion proof with each share to prevent the above's scenario that someone feeds garbage blocks into the network and this would only be detected after downloading all garbage. This would have the major downside that a lot of duplicate data needs to be gossiped (all those inner proof nodes).

Actually, another idea is to only send half the rows: namely those parts that represent the original data. So the smallest piece or "part" that would be gossiped could be [original part of row] (and maybe a single [proof node] for the other half). From this the receiving part could already compute the other half (this is currently not supported by rsmt2d but we could change that and it plays into your thinking here btw: https://github.com/lazyledger/rsmt2d/issues/60).

Yeah, gossiping block parts, at least in its current form, is not the best idea because we chunk the block differently already (into erasure coded shares).

Ok, but maybe I got your original concern wrongly. I thought the block parts are not a good idea in terms of tendermimt; for our case, it's obviously not a way to go for the reason you mentioned.

I thought the block parts are not a good idea in terms of tendermimt

There is nothing wrong with blockparts in tendermint. The only questionable thing is that the PartSetHeader is part of BlockID in the header and BlockID is used everywhere. So basically an implementation detail on how to get the block data to other nodes spills everywhere. There are several issues on how to get rid of PartSetHeader in the header; see for instance https://github.com/tendermint/spec/issues/78, and https://github.com/tendermint/spec/issues/277

Closing as this is no longer relevant now. IMO we should merge the ADR that Hlib wrote (after this is briefly addressed).


Improve apply performance

Avoid registering more than one action for componentSelection.all and resolutionStrategy.eachDependency and replace with a HashMap lookup against the module identitifer instead
Use Gradle's DefaultModuleIdentifier/DefaultModuleVersionIdentifier - avoids additional parsing on some paths as many dependency related methods take Object and will pass-through already parsed representations

🎉


Deleting Status page services in wrong order

The deletion is done by hostname.hostName. If you have an StatusPage service that has hostname it will be deleted as it is mean to be. But if you have that plus several NRQL services and try to delete one of the NRQL ones, the deletion won't be correct, because in the handler you find the index by hostName and NRQL components don't have hostName. It must be performed by id.

PR #167 fixes this issue


Conversational Program Repair Bots

"We imagine conversational systems for patch explanation: developers would be able to ask questions about the patch behavior, and the program repair bot would answer to those questions. Such a system can be data-driven, based on the analysis of the millions of similar conversations that have happened in open-source repositories."

Explainable Software Bot Contributions: Case Study of Automated Bug Fixes

Resilient Chatbots - Repair Strategy Preferences for Conversational Breakdowns.
URL: https://dblp.org/rec/html/conf/chi/AshktorabJLW19

The Rasa framework, by @RasaHQ, presented at BotSE by @amn41 could be of great help
https://github.com/RasaHQ/rasa/

Genie - a generator of natural language semantic parsers for virtual assistant commands.
https://dblp.org/rec/html/conf/pldi/CampagnaXMSL19

Food for thought:
What Makes a Good Conversation?
http://www.abigailsee.com/2019/08/13/what-makes-a-good-conversation.html

Neural Modules (NeMo): A toolkit for conversational AI
https://github.com/NVIDIA/NeMo

Convo: What does conversational programming need? An exploration of machine learning interface design.
http://arxiv.org/abs/2003.01318

APIBot: question answering bot for API documentation
https://ink.library.smu.edu.sg/cgi/viewcontent.cgi?article=4927&context=sis_research

Facebook Uses 1.5 Billion Reddit Posts To Create Chatbot
https://www.bbc.com/news/technology-52532930
we'll do the same with github and PR conversations

Automatic Classification of Review Comments in Pull-based Development Model.
https://whystar.github.io/res/paper/seke2017.pdf

Conversational Bot for Newcomers Onboarding to Open Source Projects
http://botse.org/preprints/BotSE20_paper_5.pdf

Designing a Pair Programming Conversational Agent
https://www.proquest.com/openview/9dddfa15ee915a7ddaf1868123053e20/1?cbl=18750&diss=y&parentSessionId=qp7w1M%2B9FZKKjhWtqMofTSGq%2BknKVNkrs8ObB%2BkRU3w%3D&pq-origsite=gscholar&accountid=7414

Chatbot4QR: Interactive Query Refinement for Technical Question Retrieval IEEE TSE

Conversational DevBots for Secure Programming: An Empirical Study on SKF Chatbot


Write docs

Since this Issue is heavily oversized and not fully qualified, i will close this one.
Documentation is done inside the code itself.
The docsgenerator will later on create the markdown documentations.


Fix canvas not filtering click event after drag

Fix #4458
The issue come from the fact that we compute targets in a different way while in canvas or vector DOM, but we were now checking for drag only in the DOM scenario.
I've tried to refactor a bit to get the check only once, but I think this is not doable given that we are computing the targets in two totally distinct ways.
Note to @IvanSanchez I've added a happen.click on the test to simulate the click event after down/up, I'm open to a better suggestion :)
This PR also fixes preclick not being fired by canvas layers. It's in a separate commit and I think it should stay separate and not be rebased.

greate work, i tried this fix and it works like a charm

Damn, squashed accidentally — sorry! The commit has a link to PR and a summary though.
@perliedman this may be a better approach — let's follow up if necessary.


express-pouchdb goes way too often

@calvinmetcalf could you elaborate on this issue?

we should definitely be able to set sync interval, even be able to turn syncing off and just act as a passthrough.


Fix parsing issue #27

Would be great if this can be merged and a new release made ASAP since it's breaking our main use case at work.


SAML is insecure by design

https://twitter.com/joonas_fi/status/1339205267637100546
https://twitter.com/pquerna/status/1349234347266564096

https://mobile.twitter.com/jupenur/status/1379138550558523398

Related: #79

Used in very important places in Finland, like bank logins and federal authentication services


Create a captive portal

When you connect your phone to the access point (at the first time), would be great to be navigated to the configuration portal.
It is possible and theoretically should not be hard.
The solution is described here:
https://stackoverflow.com/questions/54583818/esp-auto-login-accept-message-by-os-with-redirect-to-page-like-public-wifi-port

Done with version 1.05


Segmentation fault on Mac

My Travis build on Mac is failing consistently, apparently due to FFTW. Could you please share some thoughts on what might be happening and how I can fix it? https://travis-ci.org/juliohm/ImageQuilting.jl/jobs/346038516#L595-L614

I don't think this is related to FFTW but I could be wrong. The warnings you're seeing from FFTW are expected on 0.6 since there's no cache file for the package, it just uses the Base bindings. Something you could do to test locally would be to remove FFTW from your REQUIRE file and rerun the tests on 0.6. If they still segfault, try running it with LLDB (or GDB, if you prefer).

Thank you @ararslan , it seems like it is coming from Hwloc.jl? I opened an issue there instead. I don't know if something changed about Hwloc on Mac, but I am just calling a single function num_physical_cores().


failed, reason: certificate is not yet valid

Environment
No response
Reproduction
No response
Describe the bug
While running nuxt app in production I get next-auth error stating;
callbackUrl=<website_url> failed, reason: certificate is not yet valid
How can I solve the issue? It only occurs on server(VPS)
Here is my package.json
{   "name": "nuxt-app",   "private": true,   "type": "module",   "scripts": {     "build": "nuxt build",     "dev": "nuxt dev",     "generate": "nuxt generate",     "preview": "nuxt preview",     "postinstall": "nuxt prepare"   },   "devDependencies": {     "@nuxt/devtools": "latest",     "@pinia-plugin-persistedstate/nuxt": "^1.1.2",     "@sidebase/nuxt-auth": "0.5.0",     "nuxt": "^3.7.4",     "vue": "^3.3.4",     "vue-router": "^4.2.5"   },   "dependencies": {     "@pinia/nuxt": "^0.4.11",     "next-auth": "^4.22.5",     "nuxt-snackbar": "^1.0.3",     "pinia": "^2.1.6",     "pinia-plugin-persistedstate": "^3.2.0"   } }
Additional context
No response
Logs
No response

Hi @kennedyngigi4, from just the error message, I assume this may be related to SSL certificates. Could you please provide more context for when and how this happens?

Full error message
Nuxt Config
Any files relating to NuxtAuth
Deployment information (where + how)
Maybe a reproduction?


Test and create community principles

What
Create and test community principles that will be adopted by the communities the service manual works with.
Why
Tasks

[ ] Create community principles
[ ] User test community principles

Please delete this ticket.


There should be a mechanism to log out of mission control

Have a similar mechanism in team management too

If you want this feature to be implemented, give it a thumbs up reaction, so that we can determine which features are important to you.
👍

Since we don't have any user's info to show in Mission Control, let's add a simple logout icon in the top bar itself rather than showing a profile avatar? @YourTechBud. In team management, we can have a different logout mechanism which is similar to the one in billing console UI.
On clicking this logout icon in Mission Control, we can simply clear localStorage and redirect the user to the loginURL  returned by the getLoginURL function.

Done. Coming in v0.19.3.


Improve path max

Hi,
this PR is just a small improvement on how PATH_MAX is calculated.
(Sometimes 260 is not enough.)
I've also added the main-c to CMakeLists in the test directory.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: lbudai sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Thanks so much -- I fixed this inth elatest dev branch using slightly simplified code.

I think in most of the cases PATH_MAX is defined which means that the buffer for realpath can be allocated on the stack, so don't need to dynamically allocate a buffer then strdup the content of the buffer then free the buffer.
Pathconf... well, it is a POSIX.1-2001. conform function, so it's up to you.


Improve acceptance test suite build quality (decrease flakiness)

The current acceptance test suite has grown since the project started. It is now comprised of 30 xenorchestra_vm resource tests, which often cause the go test command to timeout (running TIMEOUT=XXXm make testacc never succeeds on its own). This is starting to become a significant time sink on development velocity. In addition, the process listed below is time consuming and requires that I correctly identify what tests failed or were skipped:

Run test suite via make testacc
Identify which tests failed and which were skipped (as in go test timed out before that test was run)
Run additional test commands only running the failed tests TEST='Test1|Test2|Test3|....' make testacc
Repeat 2-3 until the test suite passes

There have been past efforts to improve the test suite quality:

#84
#149
#148

While these have improved the test suite, it does not help with managing the test suite over time as its performance changes (test suite becomes slower, certain tests become problematic, identifying bad tests).
The goal of this issue is to allow the test suite to pass by running a single bash command. This will prevent the frequent loop identified above where commands are issued until all acceptance tests have passed.
One possible idea is to explore alternative ways of running the test suite (shell script, more proper test runner). It seems that gotestsum test runner is worth exploring. It has builtin support for re-running failed tests and can also identify what tests are slow.

Until this is fixed here is my solution:
$ comm -2 -3  <(git grep TestAcc | cut -d ':' -f2 | awk '{print $2}' | grep '(t' | grep -Po '.*(?=..$)' | sort) <(grep 'PASS:' ouptut.txt | awk '{print $3}' | sort ) | wc -l

Repeat with each successive test run.

I've evaluated gotestsum. Unfortunately it doesn't provide the functionality I need. It does allow re-running failed tests, but we need terraform's test sweeping to run before each additional retry (to purge VMs and other failed resources).
From reading it's source code and rakyll/go-test-trace, I believe writing a custom test runner is a good option. Essentially what it will do is keep track of all tests, run go test ... -sweep=true -json and parse the streamed output. Once the test timeout is reached it will remove the successful tests from the test list and run go test ... -sweep=true -json again with a smaller subset of tests. Separately I'd like to better understand these test failures, but I'd like to attempt this test runner first since my past attempts at understanding the tests's performance hasn't been successful.
I'm work in progress branch that I believe should be close to an initial prototype.

I've evaluated gotestsum. Unfortunately it doesn't provide the functionality I need. It does allow re-running failed tests, but we need terraform's test sweeping to run before each additional retry (to purge VMs and other failed resources).

I took another look at gotestsum as I was debugging my custom test runner and my initial assessment isn't quite correct. It should work with terraform's test sweeping (re-running go test after each set of failures). However when it encounters a test panic (exactly the situation I'd like to re-run in), it simply gives up.
My branch mentioned above has a github.com/ddelnano/terraform-provider-xenorchestra/testing/parallel test suite that passes with -timeout=32s, but fails with a -timeout=22s to better acceptance test whatever solution I use. Here is the behavior of gotestsum against those tests.
ddelnano@ddelnano-desktop:~/go/src/github.com/ddelnano/terraform-provider-xenorchestra$ ~/code/gotestsum/gotestsum --rerun-fails --packages="./..." -- -count=1 -timeout=22s -run="TestParallel" -v
∅  .
∅  cmd/testing (3ms)
∅  xoa/internal (11ms)
∅  xoa (12ms)
✖  cmd/testing/parallel (22.015s)

=== Failed
=== FAIL: cmd/testing/parallel TestParallelHangging (unknown)

DONE 3 tests, 1 failure in 22.558s
ERROR rerun aborted because previous run had a suspected panic and some test may not have run
ddelnano@ddelnano-desktop:~/go/src/github.com/ddelnano/terraform-provider-xenorchestra$ ~/code/gotestsum/gotestsum --rerun-fails --packages="./..." -- -count=1 -timeout=32s -run="TestParallel" -v
∅  .
∅  cmd/testing (8ms)
∅  xoa/internal (12ms)
∅  xoa (13ms)
✓  cmd/testing/parallel (30.022s)

DONE 3 tests in 30.561s

So it seems gotestsum may be able to be extended to not error in this situation, but I need to better understand what is more feasible.

I've also created a post on the Hashicorp discuss forums. I'm hoping to receive more guidance from other provider developers / Hashicorp on other things I haven't considered.

While gotestsum does not handle go test timeouts that result in panics, I've determined that I can extend it easily to support the behavior I need (https://github.com/gotestyourself/gotestsum/commit/8c70ff05e83bc93e5e042151a4d25343f1dfe4f8). I will attempt to upstream this behavior, but for now I believe that gotestsum is the correct approach to easily run the test suite.
I have to modify how the terraform test setup code works, so the solution isn't finished yet. However, I'm confident that it will be workable to solve this problem at this point. My previous work to write my own test runner ran into issues and I think it's better to build on top of an existing project than piece together a minimal one off test runner.
As an extension of this issue, I'd like to setup continuous integration so PRs are able to be tested automatically. Once I have this issue resolved, I will be looking into the CI job further.

I have confirmed that the changes in #217 result in a build that succeeds even when a subset of tests hit the timeout and panic. This significantly reduces the manual work to run the test suite and will drastically improve development and release time.
gotestsum output for acceptance test suite
$ TF_ACC=1 ~/code/gotestsum/gotestsum --rerun-fails=4 --rerun-fails-max-failures=1000 --packages='./...' -- ./... -v -count=1 -timeout=25m -sweep=true

[ ... ]

goroutine 47250 [select]:
google.golang.org/grpc/internal/transport.(*recvBufferReader).read(0xc00198cb90, {0xc001162250, 0x5, 0x5})
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/internal/transport/transport.go:177 +0x90
google.golang.org/grpc/internal/transport.(*recvBufferReader).Read(0xc00198cb90, {0xc001162250?, 0xc00271e978?, 0xc002727730?})
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/internal/transport/transport.go:171 +0x178
google.golang.org/grpc/internal/transport.(*transportReader).Read(0xc000afbce0, {0xc001162250?, 0xc0027277a8?, 0xa45067?})
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/internal/transport/transport.go:482 +0x32
io.ReadAtLeast({0x10807e0, 0xc000afbce0}, {0xc001162250, 0x5, 0x5}, 0x5)
        /usr/lib/go/src/io/io.go:332 +0x9a
io.ReadFull(...)
        /usr/lib/go/src/io/io.go:351
google.golang.org/grpc/internal/transport.(*Stream).Read(0xc0024de900, {0xc001162250, 0x5, 0x5})
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/internal/transport/transport.go:466 +0xa5
google.golang.org/grpc.(*parser).recvMsg(0xc001162240, 0x400000)
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/rpc_util.go:503 +0x47
google.golang.org/grpc.recvAndDecompress(0xc000afb620?, 0xc0024de900, {0x0, 0x0}, 0x400000, 0x0, {0x0, 0x0})
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/rpc_util.go:634 +0x66
google.golang.org/grpc.recv(0x8?, {0x7f544d3aab80, 0x1674798}, 0x203000?, {0x0?, 0x0?}, {0xe70440, 0xc00198cbe0}, 0xc002727a30?, 0x0, ...)
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/rpc_util.go:702 +0x6e
google.golang.org/grpc.(*serverStream).RecvMsg(0xc00240c600, {0xe70440?, 0xc00198cbe0})
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/stream.go:1496 +0x178
github.com/hashicorp/go-plugin/internal/plugin.(*gRPCBrokerStartStreamServer).Recv(0xc003a89a20)
        /home/ddelnano/go/pkg/mod/github.com/hashicorp/go-plugin@v1.4.0/internal/plugin/grpc_broker.pb.go:167 +0x4c
github.com/hashicorp/go-plugin.(*gRPCBrokerServer).StartStream(0xc000e57ad0, {0x108b220, 0xc003a89a20})
        /home/ddelnano/go/pkg/mod/github.com/hashicorp/go-plugin@v1.4.0/grpc_broker.go:84 +0x152
github.com/hashicorp/go-plugin/internal/plugin._GRPCBroker_StartStream_Handler({0xde9d60?, 0xc000e57ad0}, {0x10897f0?, 0xc00240c600})
        /home/ddelnano/go/pkg/mod/github.com/hashicorp/go-plugin@v1.4.0/internal/plugin/grpc_broker.pb.go:148 +0x9f
google.golang.org/grpc.(*Server).processStreamingRPC(0xc003a32000, {0x108b880, 0xc002016480}, 0xc0024de900, 0xc000e57b60, 0x162a7c0, 0x0)
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/server.go:1441 +0xd4a
google.golang.org/grpc.(*Server).handleStream(0xc003a32000, {0x108b880, 0xc002016480}, 0xc0024de900, 0x0)
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/server.go:1521 +0x9ea
google.golang.org/grpc.(*Server).serveStreams.func1.2()
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/server.go:859 +0x98
created by google.golang.org/grpc.(*Server).serveStreams.func1
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/server.go:857 +0x28a

goroutine 47251 [select]:
github.com/hashicorp/go-plugin.(*gRPCBrokerServer).StartStream.func1()
        /home/ddelnano/go/pkg/mod/github.com/hashicorp/go-plugin@v1.4.0/grpc_broker.go:70 +0x105
created by github.com/hashicorp/go-plugin.(*gRPCBrokerServer).StartStream
        /home/ddelnano/go/pkg/mod/github.com/hashicorp/go-plugin@v1.4.0/grpc_broker.go:68 +0x131

goroutine 47264 [select]:
github.com/hashicorp/terraform-plugin-go/tfprotov5/server.mergeStop({0x1087608?, 0xc0012e7b00?}, 0xc0035f63e0, 0xc0038674a0)
        /home/ddelnano/go/pkg/mod/github.com/hashicorp/terraform-plugin-go@v0.2.1/tfprotov5/server/server.go:111 +0x74
created by github.com/hashicorp/terraform-plugin-go/tfprotov5/server.(*server).stoppableContext
        /home/ddelnano/go/pkg/mod/github.com/hashicorp/terraform-plugin-go@v0.2.1/tfprotov5/server/server.go:129 +0x158

goroutine 47258 [select]:
google.golang.org/grpc/internal/transport.(*controlBuffer).get(0xc0012d9040, 0x1)
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/internal/transport/controlbuf.go:395 +0x115
google.golang.org/grpc/internal/transport.(*loopyWriter).run(0xc001859aa0)
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/internal/transport/controlbuf.go:515 +0x85
google.golang.org/grpc/internal/transport.newHTTP2Server.func2()
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/internal/transport/http2_server.go:291 +0xce
created by google.golang.org/grpc/internal/transport.newHTTP2Server
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/internal/transport/http2_server.go:288 +0x14d3

goroutine 47259 [select]:
google.golang.org/grpc/internal/transport.(*http2Server).keepalive(0xc0044ba900)
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/internal/transport/http2_server.go:979 +0x233
created by google.golang.org/grpc/internal/transport.newHTTP2Server
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/internal/transport/http2_server.go:299 +0x1518

goroutine 47260 [IO wait]:
internal/poll.runtime_pollWait(0x7f542e6edb50, 0x72)
        /usr/lib/go/src/runtime/netpoll.go:305 +0x89
internal/poll.(*pollDesc).wait(0xc0011e5280?, 0xc0044c8000?, 0x0)
        /usr/lib/go/src/internal/poll/fd_poll_runtime.go:84 +0x32
internal/poll.(*pollDesc).waitRead(...)
        /usr/lib/go/src/internal/poll/fd_poll_runtime.go:89
internal/poll.(*FD).Read(0xc0011e5280, {0xc0044c8000, 0x8000, 0x8000})
        /usr/lib/go/src/internal/poll/fd_unix.go:167 +0x25a
net.(*netFD).Read(0xc0011e5280, {0xc0044c8000?, 0x0?, 0xc002ed64e0?})
        /usr/lib/go/src/net/fd_posix.go:55 +0x29
net.(*conn).Read(0xc0001259f8, {0xc0044c8000?, 0x0?, 0xc002728cd0?})
        /usr/lib/go/src/net/net.go:183 +0x45
bufio.(*Reader).Read(0xc001859a40, {0xc0000f2818, 0x9, 0x0?})
        /usr/lib/go/src/bufio/bufio.go:237 +0x1bb
io.ReadAtLeast({0x107e200, 0xc001859a40}, {0xc0000f2818, 0x9, 0x9}, 0x9)
        /usr/lib/go/src/io/io.go:332 +0x9a
io.ReadFull(...)
        /usr/lib/go/src/io/io.go:351
golang.org/x/net/http2.readFrameHeader({0xc0000f2818?, 0x9?, 0xc00310d260?}, {0x107e200?, 0xc001859a40?})
        /home/ddelnano/go/pkg/mod/golang.org/x/net@v0.0.0-20200707034311-ab3426394381/http2/frame.go:237 +0x6e
golang.org/x/net/http2.(*Framer).ReadFrame(0xc0000f27e0)
        /home/ddelnano/go/pkg/mod/golang.org/x/net@v0.0.0-20200707034311-ab3426394381/http2/frame.go:492 +0x95
google.golang.org/grpc/internal/transport.(*http2Server).HandleStreams(0xc0044ba900, 0x6430376330362d63?, 0x2c22393730653064?)
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/internal/transport/http2_server.go:459 +0x177
google.golang.org/grpc.(*Server).serveStreams(0xc003a32000, {0x108b880?, 0xc0044ba900})
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/server.go:843 +0x142
google.golang.org/grpc.(*Server).handleRawConn.func1()
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/server.go:802 +0x34
created by google.golang.org/grpc.(*Server).handleRawConn
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/server.go:801 +0x3fd

goroutine 47263 [select]:
github.com/sourcegraph/jsonrpc2.Waiter.Wait({0x0?}, {0x1087640, 0xc00003c170}, {0xd3d0c0, 0xc000644060})
        /home/ddelnano/go/pkg/mod/github.com/sourcegraph/jsonrpc2@v0.0.0-20210201082850-366fbb520750/jsonrpc2.go:461 +0x99
github.com/sourcegraph/jsonrpc2.(*Conn).Call(0x8?, {0x1087640, 0xc00003c170}, {0xed22b0?, 0x0?}, {0xdad060?, 0xc002ebf170?}, {0xd3d0c0, 0xc000644060}, {0x0, ...})
        /home/ddelnano/go/pkg/mod/github.com/sourcegraph/jsonrpc2@v0.0.0-20210201082850-366fbb520750/jsonrpc2.go:423 +0xac
github.com/ddelnano/terraform-provider-xenorchestra/client.NewClient({{0xc0000460c8, 0x16}, {0xc00003c159, 0x5}, {0xc0000401bd, 0x8}, 0x0})
        /home/ddelnano/go/src/github.com/ddelnano/terraform-provider-xenorchestra/client/client.go:178 +0x36e
github.com/ddelnano/terraform-provider-xenorchestra/xoa.xoaConfigure(0xebc91c?)
        /home/ddelnano/go/src/github.com/ddelnano/terraform-provider-xenorchestra/xoa/provider.go:72 +0x1aa
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Provider).Configure(0xc0005e20f0, {0x10876b0, 0xc001b3c570}, 0xc0035f65c0?)
        /home/ddelnano/go/pkg/mod/github.com/hashicorp/terraform-plugin-sdk/v2@v2.4.3/helper/schema/provider.go:279 +0x12f
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).ConfigureProvider(0xc0033f5098, {0x1087608, 0xc0012e7b00}, 0xc001163218)
        /home/ddelnano/go/pkg/mod/github.com/hashicorp/terraform-plugin-sdk/v2@v2.4.3/helper/schema/grpc_provider.go:523 +0x27b
github.com/hashicorp/terraform-plugin-go/tfprotov5/server.(*server).Configure(0xc00498fbc0, {0x10876b0?, 0xc001b3c150?}, 0xc0012e7ac0)
        /home/ddelnano/go/pkg/mod/github.com/hashicorp/terraform-plugin-go@v0.2.1/tfprotov5/server/server.go:182 +0x147
github.com/hashicorp/terraform-plugin-go/tfprotov5/internal/tfplugin5._Provider_Configure_Handler({0xe7fca0?, 0xc00498fbc0}, {0x10876b0, 0xc001b3c150}, 0xc00403c420, 0x0)
        /home/ddelnano/go/pkg/mod/github.com/hashicorp/terraform-plugin-go@v0.2.1/tfprotov5/internal/tfplugin5/tfplugin5_grpc.pb.go:326 +0x170
google.golang.org/grpc.(*Server).processUnaryRPC(0xc003a32000, {0x108b880, 0xc0044ba900}, 0xc0024dee00, 0xc000e57e60, 0x1634518, 0x0)
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/server.go:1194 +0xcab
google.golang.org/grpc.(*Server).handleStream(0xc003a32000, {0x108b880, 0xc0044ba900}, 0xc0024dee00, 0x0)
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/server.go:1517 +0xa2f
google.golang.org/grpc.(*Server).serveStreams.func1.2()
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/server.go:859 +0x98
created by google.golang.org/grpc.(*Server).serveStreams.func1
        /home/ddelnano/go/pkg/mod/google.golang.org/grpc@v1.32.0/server.go:857 +0x28a

goroutine 47265 [select]:
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.mergeStop({0x1087608?, 0xc0012e7cc0?}, 0xc0035f65b0, 0xc003caf8c0)
        /home/ddelnano/go/pkg/mod/github.com/hashicorp/terraform-plugin-sdk/v2@v2.4.3/helper/schema/grpc_provider.go:44 +0x74
created by github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).StopContext
        /home/ddelnano/go/pkg/mod/github.com/hashicorp/terraform-plugin-sdk/v2@v2.4.3/helper/schema/grpc_provider.go:60 +0x158

=== FAIL: xoa TestAccXONetworkDataSource_read (re-run 1) (3.07s)
    data_source_xenorchestra_network_test.go:43: Step 1/1 error: Error running pre-apply refresh: exit status 1

        Error: Your query returned more than one result: [{Id:cb292945-e8d4-361b-b0b4-0729f98aeb8e NameLabel:terraform-acc-network-1 Bridge:xapi109 PoolId:355ee47d-ff4c-4924-3db2-fd86ae629676} {Id:661a1a2b-368a-9390-6e0b-62a5291cdbd2 NameLabel:terraform-acc-network-1 Bridge:xapi115 PoolId:355ee47d-ff4c-4924-3db2-fd86ae629676} {Id:0432d2a7-f268-6999-eb43-c6a2345b2133 NameLabel:terraform-acc-network-1 Bridge:xapi118 PoolId:355ee47d-ff4c-4924-3db2-fd86ae629676} {Id:a59e89ed-65c2-346b-c309-54a02f13eb6d NameLabel:terraform-acc-network-1 Bridge:xapi112 PoolId:355ee47d-ff4c-4924-3db2-fd86ae629676}]. Use `pool_id` or other fields to filter the result down to a single network

=== FAIL: xoa TestAccXenorchestraVm_createWithMutipleDisks (re-run 1) (51.34s)
    resource_xenorchestra_vm_test.go:945: Step 1/1 error: After applying this test step, the plan was not empty.
        stdout:

        An execution plan has been generated and is shown below.
        Resource actions are indicated with the following symbols:
          ~ update in-place

        Terraform will perform the following actions:

          # xenorchestra_vm.bar will be updated in-place
          ~ resource "xenorchestra_vm" "bar" {
                auto_poweron      = false
                cloud_config      = "template"
                core_os           = false
                cpu_cap           = 0
                cpu_weight        = 0
                cpus              = 1
                exp_nested_hvm    = false
                hvm_boot_firmware = "bios"
                id                = "52f2f9a5-174c-aec2-1fdf-17ca835bbb01"
                ipv4_addresses    = []
                ipv6_addresses    = []
                memory_max        =<PHONE_NUMBER>
                name_description  = "description"
                name_label        = "terraform-acc - TestAccXenorchestraVm_createWithMutipleDisks"
                power_state       = "Running"
                start_delay       = 0
                template          = "9b0fd2ac-c89a-93b4-5103-8506391395cd"
                vga               = "std"
                videoram          = 8
                wait_for_ip       = false

              ~ disk {
                    attached   = true
                    name_label = "disk 1"
                    position   = "0"
                  ~ size       =<PHONE_NUMBER> -><PHONE_NUMBER>8
                    sr_id      = "86a9757d-9c05-9fe0-e79a-8243cb1f37f3"
                    vbd_id     = "41c4cead-bce1-7eb9-f0a8-7f6aafbfed47"
                    vdi_id     = "295dc4eb-96d0-4c45-8657-77e387796d9c"
                }
                disk {
                    attached   = true
                    name_label = "disk 2"
                    position   = "1"
                    size       =<PHONE_NUMBER>8
                    sr_id      = "86a9757d-9c05-9fe0-e79a-8243cb1f37f3"
                    vbd_id     = "c07b1553-c1a6-5c1f-39b5-4487c6d2125b"
                    vdi_id     = "0a8cd9a9-7c2b-4aee-884c-1bf891474122"
                }

                network {
                    attached       = true
                    device         = "0"
                    ipv4_addresses = []
                    ipv6_addresses = []
                    mac_address    = "e6:08:98:9b:45:6e"
                    network_id     = "6c4e1cdc-9fe0-0603-e53d-4790d1fce8dd"
                }
            }

        Plan: 0 to add, 1 to change, 0 to destroy.

DONE 3 runs, 96 tests, 1 skipped, 10 failures in 2798.600s

# Verify the build succeeded
ddelnano@ddelnano-desktop:~/go/src/github.com/ddelnano/terraform-provider-xenorchestra$ echo $?
0

This is no longer an issue as there is build infrastructure within the Vates lab now.


Blog not showing chart on rendering

Although the code is now referred to https://github.com/nhs-r-community/nhs-r-community/commit/37687c922a5f922601b51638b988fa59dd6e2131 this isn't showing in the blog when rendered - possibly related to a freeze in the gh-action

Resolved by commenting out freeze https://github.com/nhs-r-community/nhs-r-community/blob/bdda0467dec3563cda31588896adc3efa6a30c06/.github/workflows/publish.yaml#L49 when trying to get sf package working in docker.


Update sv.po

Update Swedish translation

Thanks for the translation work!
It looks like the Swedish translations were also updated yesterday on https://translations.launchpad.net/pinta -  is this the same set of changes?

It was me also updating the launchpad version, but checking the github pot file, almost all the new launchpad strings was gone again. PoEdit removed them, so no... this PR is not the same as launchpad file.
It's your decision, which is more resent.  ;)

OK thanks! I think the launchpad translations page is still on the .pot file for the gtk2 branch, due to the recent 1.7.1 release. I've been meaning to get that switched over to match the master branch, so that probably accounts for the discrepancy you noticed?

OK, I think I've gotten things set up properly on  Launchpad now, and the master and gtk2 branch translations are both available to translate.
I'll merge this and sync it back to Launchpad - for future changes you don't need to make a PR since the Launchpad translation updates will be pulled in periodically
Thanks for your contribution!


Make unchecked division kernel available

Is your feature request related to a problem or challenge?
With #6792, now divisions check dividing by zero.
This is an API change and we are (and some other users may be) looking for an old behavior.
Describe the solution you'd like
we would like to propose to implement DivideUnchecked operation that behaves like the old Division operator (return null for dividing by zero)
Describe alternatives you've considered
No response
Additional context
No response

Closing based on https://github.com/apache/arrow-datafusion/pull/6970#issuecomment-1659109904


add As raw to parsered body

Description
Added an as raw helper function to parsed body.
Motivation and Context
This means instead of:
if case let .raw(data) = requestBody {}
You can do:
if let data = requestBody.asRaw {}
Which is more readable and now matched the other types (JSON, URLEncoded, text)
How Has This Been Tested?
Test for bodyparser has been changed to use this helper function and is passing
Checklist:

[x] If applicable, I have updated the documentation accordingly.
[x] If applicable, I have added tests to cover my changes.

Codecov Report

Merging #1258 into master will decrease coverage by 0.05%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master    #1258      +/-   ##
==========================================
- Coverage   89.07%   89.02%   -0.06%
==========================================
  Files          38       38
  Lines        2280     2286       +6
==========================================
+ Hits         2031     2035       +4
- Misses        249      251       +2

Flag
Coverage Δ

#Kitura
89.02% <66.66%> (-0.06%)
:arrow_down:

Impacted Files
Coverage Δ

Sources/Kitura/bodyParser/ParsedBody.swift
86.66% <66.66%> (-5%)
:arrow_down:

Continue to review full report at Codecov.

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

The test change from case let .raw(data) to asRaw uses this tests this helper function alongside the asJSON, asText etc functions and should cover this change.


Eliminate style and grammar errors in resources.yml

Describe your changes
Eliminated grammatical and style errors in resources.yml
Related issue number/link
Fixes #138
Thanks for contributing! 🥳🚀🌳

Thanks for the PR!


iOS Error : Undefined symbols for architecture arm64:   "OBJC_CLASS$_GMSServices", referenced from:  objc-class-ref in AppDelegate.o

Is this a bug report?
Yes
Have you read the Installation Instructions?
Yes
Environment
"react": "16.6.0-alpha.8af6728",
"react-native": "0.57.3",
"react-native-maps": "^0.22.1",

Target Platform:
iOS - 12.0 Simulator/iPhone XR
Apple map works fine, But I want to use google maps. And that gives me error.
Steps to Reproduce
I just add 'react-native-maps' in the project, setup CocoaPods and add enable google map from AppDelegate.m but this step gives me error like below.
Undefined symbols for architecture arm64:
"OBJC_CLASS$_GMSServices", referenced from:
objc-class-ref in AppDelegate.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Expected Behavior
It should run, and display google map on iPhone.

Very old issue, closing. Please re-open if you still have it.

i have the same issue. any solution?

i have the same issue? any solution @vivekshah-zymr @rborn. please help

i got it solved by adding $(inherited) in
BuildSettings->Linking->Other Linker Flags.

this needs to be reopened! I am stuck . on it like from 2 days nothing on google helped

@rborn did anybody had a solution?

can some one tell me the solution if it worked?
i was trying with xcode11 too, still i am facing this.

still facing this issue in m1

Adding these in Other Linker Flags fixes this issue:
-l"c++" -framework GoogleMaps -framework GoogleMapsBase -framework GoogleMapsCore


slovak translation

Thanks. Since you closed this pull request, do you actually want me to merge this translation? Or did you close it on purpose?

Sorry, this is my first ever pull request, i would be pleased if you merge my translation.

No worries, merging now. Thanks for your work!

Oh come on, I had this semi-done! Ah well.


v0.3.15 error win32 x86

:warning:Please attach %TEMP%\vscode-java-installer\log.txt and %TEMP%\vscode-java-installer\AdoptOpenJDK-MSI.log for more details.
version: 0.3.15
env:
JAVA_HOME: undefined
PATH:
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\WINDOWS\System32\WindowsPowerShell\v1.0\
C:\WINDOWS\System32\OpenSSH\
E:\WinSCP\
C:\Users\Shivam negi\AppData\Local\Microsoft\WindowsApps
C:\Program Files\Nmap
C:\Users\Shivam negi\AppData\Local\Programs\Microsoft VS Code\bin
JDKs:

log:
[2:00:09 PM] AdoptOpenJDK-11-x86
[2:00:11 PM] TypeError [ERR_INVALID_ARG_TYPE]: The "data" argument must be one of type string, TypedArray, or DataView. Received type undefined
[2:00:11 PM] Retry downloading ... [1]
[2:00:13 PM] TypeError [ERR_INVALID_ARG_TYPE]: The "data" argument must be one of type string, TypedArray, or DataView. Received type undefined
[2:00:13 PM] Retry downloading ... [2]
[2:00:15 PM] TypeError [ERR_INVALID_ARG_TYPE]: The "data" argument must be one of type string, TypedArray, or DataView. Received type undefined
[2:00:15 PM] fallback to Adopt API v3
[2:01:37 PM] Download JDK ... [Completed]
[2:01:38 PM] Install JDK
[2:01:38 PM] Installing AdoptOpenJDK-11-x86...
[2:01:55 PM] Error occurred
[2:01:55 PM] Error: Command failed with exit code 1620: C:\WINDOWS\System32\msiexec.exe /i "C:\Users\SHIVAM~1\AppData\Local\Temp\vscode-java-installer\binaries\jdk\11\x86\AdoptOpenJDK-11.msi" MSIINSTALLPERUSER=1 ADDLOCAL=FeatureJavaHome,FeatureEnvironment,FeatureJarFileRunWith /passive /l*v "C:\Users\SHIVAM~1\AppData\Local\Temp\vscode-java-installer\AdoptOpenJDK-MSI.log"
This installation package could not be opened.  Contact the application vendor to verify that this is a valid Windows Installer package.

See #186


Warps not saved

[00:27:57] [Server thread/INFO]: Loading SimpleWarp v2.1.1
...
version
[10:49:31] [Server thread/INFO]: This server is running PocketMine-MP 1.6dev 「Unleashed」 implementing API version 2.0.0 for Minecraft: PE v<IP_ADDRESS> alpha (protocol version 81)
addwarp dai1 268 120 72 DiagonAlley
[00:07:31] [Server thread/INFO]: You have created a warp called dai1 (X: 268, Y: 120, Z: 72, LEVEL: DiagonAlley)
listwarps
[00:07:41] [Server thread/INFO]: Warp list:
[00:07:41] [Server thread/INFO]:  * dai1 (X: 268, Y: 120, Z: 72, LEVEL: DiagonAlley)
Just in case
save-on
[00:08:07] [Server thread/INFO]: [CONSOLE: Turned on world auto-saving]
save-all
[00:08:12] [Server thread/INFO]: [CONSOLE: Saving...]
[00:08:12] [Server thread/INFO]: [CONSOLE: Saved the world]
stop
....
./start.sh
....
listwarps
[00:28:00] [Server thread/INFO]: No warps found.
And the plugins/SimpleWarp/warps.yml is "empty":
cat /home/minecraftpe/plugins/SimpleWarp/warps.yml
--- []
...

I figured out a work-around.
In retrospect I'm guessing since I'm running a dev PocketMine it's not cleaning up correctly at the end and doesn't call SimpleWarp to tell it to exit/save cleanly.
I was assuming that when I created a warp it would automatically be written out to the warp.yaml, but when I took a peek at config.yml I found the default storage-mode was set to 0, which means to write them on exit (which wasn't happening correctly).
I changed it to 1, restarted, warps started getting saved.
Recommendation:
Change the default in config.yml to 1. I can't think of any condition where someone would want 0, but I can see why someone would want 1 or 2. While 2 is a "safer" default between the two, I think 1 would be more commonly used.

Thanks for the docu

Maybe instead of hooking server-exit, 0 should hook save-world. Then the overhead is related to saving the world (expected), and the admin can save the warps on-demand instead of having to shut the server down.

@richardpickett That is a good idea. I will create an issue for that.

Following up on this, I have done two things

Created a warning system for users that are running servers with mode 0 after a "crash".
Switched default to mode 1.

If you want to save warps in mode 0, use the reload command.


About the baseline TiSASRec

When computing the user_min_interval, you use the interval_matrix = np.abs(time_seqs[:, None] - time_seqs[None, :]). As  the diagnal line of the matrix is  always  all-zero, min_interval = np.min(interval + (interval <= 0) * 0xFFFF) will be 0xFFFF for all users. By the way, I  correct the computation of  user_min_interval, but the performance of TiSASRec doesn't get any improvement. This seems to be not important.

I'm afraid I do not get the point. The diagonal elements are expected to be all-zero. To avoid np.min yields zero or negative values, we add a large number (0xFFFF) to these positions so that the min operation gets the minimal positive value in the original interval_matrix.


Lateral PID: move steer feedforward to CarInterface

Description This is useful for cars with strange steer commands that aren't proportional to angle * speed ** 2.
I want to implement this in the best way, and I'm still figuring out Python's tricks (this is cargo cult coding), so suggest any improvements and we'll iterate.
On top of this change, I'll add GM steer feedforward and lateral tuning.
Verification Process replay is unchanged.

I've done some testing by making
steer_feedforward = angle_steers_des_no_offset + params.averageOffsetDegrees

and setting P and I to zero. Then I tuned the kf to ensure that the wheel had no centering anymore(reducing kf if it was unstable and increasing if the wheel was centering).
I think this is a nice way to tune the kf term, but it also confirmed in my case that the values need to be quite a bit different depending on speed(which makes sense if we consider openpilot torque output as the simulatet driver torque, which the EPS is boosting by different amounts depending on the speed).
Haven't checked for nonlinearity in angle a lot, but if it's just the speed, wouldn't breakpoints like for P and I be a nicer solution?

@grekiki That's a smart idea to attempt tuning kf, very clean if we had the right function of (speed, angle) -> (steer) to begin with.
I also think that feedforward is best with (desired_curvature + params.angleOffsetDegrees - params.angleOffsetAverageDegrees), as the constant offset doesn't need counter torque (angle sensor not zeroed) but the instant vehicle model error does. Working on proving that out.
Non-linearity: for Volt steer command it's not just speed but a sigmoid of angle, so speed breakpoints won't work.
  # Volt determined by iteratively plotting and minimizing error for f(angle, speed) = steer.
  def get_steer_feedforward(self, desired_angle, v_ego):
    if self.CS.car_fingerprint in [CAR.VOLT]:
      desired_angle *= 0.02904609
      sigmoid = desired_angle / (1 + fabs(desired_angle))
      return 0.10006696 * sigmoid * (v_ego + 3.12485927) # 6.99 ~= 7 mph minimum steer speed

@qadmus For the first formula, looking at this simulation for example (https://www.youtube.com/watch?v=cJyIYjwakKo) I'd say it's quite reasonable to assume that the front tyres are being "pushed" down by the weight of the engine thereby generating lateral loads to keep the car straight, which should generate centering force. (@pd0wm any opinion on that?) (thinking a bit more, I am not confident this is true. Slip seems complicated...)
For the sigmoid, seems interesting. From just physics, I'd say that the centering torque should be about proportional to the $sin(steering_angle)*v^2$ where steering_angle=steering_wheel_angle/steering_ratio(combine a=v^2/r with http://www.davdata.nl/math/turning_radius.html), though it doesn't seem like that would approximate your curve too well(with about 15 steering ratio you don't get to the "interesting part" of the sin quite yet).
Are there plots something you can make from any rlogs?

@grekiki the plots are almost universal from any rlogs, but there are a few hardcoded values like GM's max steer command. See my branch tuning-scripts for work in progress. @sshane created all the principal work, I just riffed on it.
That sigmoid will hopefully come after this refactor, I tried fitting all the sigmoids with all the degrees of freedom for variables, arctan is close but 1/(1+|x|) is best.

Renamed LatControlPID.get_steer_feedforward()
@pd0wm , an alternative implementation is to do the best with the original LateralPID output, then try to re-map the steer command in CarController. But, that would interfere with clipping / saturation behavior.
I like how each car could get their own feedforward estimate here.

Yeah like that too!
If you're looking for another small project you could make all lateral control classes inherit from the same base class. After this change the PID controller has a different API for the constructor than the others, which could be confusing.

That sounds quite simmilar to https://github.com/commaai/openpilot/pull/21967

I can rebase it if you want the PR!


USE clause

https://neo4j.com/docs/cypher-manual/current/clauses/use/

Close as it is already implemented


fix crashes on UIImage.imageToGrayscale() and imageToBlackAndWhite()

fix crashes on UIImage.imageToGrayscale() and imageToBlackAndWhite()

Thanks to this fix, but please remove .DS_Store file, before I can merge it 👍

Thanks :+1:


Add ability to run shell commands

A simple change that would be awesome would be the ability to run shell commands. An example use case would be for files to be pushed remotely on any save.

Unfortunately, that's not so simple; there are platform inconsistencies to worry about (e.g. which shell to use (if we need pipe support), setting environment variables). However, you should be able to use this plugin with another one that handles execution of commands. For example:

Run Sublime's existing build system
ShellCommand plugin

Hook would look like: https://github.com/markbirbeck/sublime-text-shell-command/tree/v0.16.0#run-a-specific-command

Shell Exec plugin

Hook would look like: https://github.com/gbaptista/sublime-3-shell-exec/tree/0.0.10#git


Allow for configuration of indexing strategy.

Autodoc currently only supports indexing a file using the most affordable models available in a projects autodoc.config.json. Ideally, we should allow for different types of indexing strategies. At very least, there should be a option to use the "best available" models, which would tell Autodoc to always choose the most powerful models that have been configured.
This is an evolving issue. Please reach out on Discord if you're interested in contributing.
Related #8.

It's too bad I don't know how to integrate TS with Python, otherwise I could make some suggestions using gpt-index/llama-index. There's another project called Cognosis AI that is the only other GPT tooling project I've seen.


Search Product with single character issue

What I'm trying to achieve
I am trying to implement search product
Write your query or mutation here
query {
products(filter: { search: "c" }, first: 20) {
edges {
node {
id
name
}
}
}
}
Steps to reproduce the problem

Search with a single character

What I expected to happen
I want the result of all products having 'c' character in its name but it is returning empty
Screenshots

System information
Operating system:
Browser:

Please provide information about Saleor version you use, as well as if there are any errors in the console


[ERROR] NoMethodError, undefined method `stop' for #<Thread:0x2b93fe06b360 run>

Daemon is logging this error:
[ERROR] NoMethodError, undefined method `stop' for #<Thread:0x2b93fe06b360 run>

when I submit several notifications at once.
Here's an example
[2011-11-25 20:26:28] [ERROR] NoMethodError, undefined method `stop' for #<Thread:0x2b93fe06b360 run>
[2011-11-25 20:26:29] Notification 63 delivered to c40...
[2011-11-25 20:26:29] Notification 61 delivered to d46...
[2011-11-25 20:26:29] Notification 62 delivered to 1a7...
[2011-11-25 20:26:29] [ERROR] NoMethodError, undefined method `stop' for #<Thread:0x2b93fe06b360 run>
[2011-11-25 20:26:29] Notification 65 delivered to 732...
[2011-11-25 20:26:29] Notification 64 delivered to 30a...
[2011-11-25 20:26:29] Notification 66 delivered to a4a...
[2011-11-25 20:26:30] Notification 64 delivered to 30a...
[2011-11-25 20:26:30] Notification 66 delivered to a4a...
[2011-11-25 20:26:30] Notification 65 delivered to 732...

Please, note that notifications 61, 62 and 63 are sent once, but 64, 65 and 66 are sent twice. The associated devices are receiving two notifications as well.

This should fix the issue. I'm not quite ready to do another release as there are some other changes in master I'd like to test some before I do. If you are able to run rapns from master a try that'd be great.

Thank you for the fast response.
I ran rapns from master and, unfortunately, the problem persists. I notice that there is another "stop" situation that could be causing the error.
On deliver_handler_pool.rb
def object_removed_from_pool(object)
  object.stop
end

Could it be causing the error?

I don't believe so. That stop call is on an instance of DeliveryHandler, which simply sets an instance variable. How did you use rapns from master? I was almost certain that commit would have fixed it.

I put
gem 'rapns', :git => 'https://github.com/ileitch/rapns.git', :branch => 'master'

on my Gemfile. Isn't that correct?

I tested a little further.
After I restarted, the [ERROR] did stop appearing. Unfortunately, the duplicate error still happens.
Here's the log
[2011-11-28 18:17:51] [Connection 0] Connected to gateway.sandbox.push.apple.com:2195
[2011-11-28 18:17:51] [Connection 1] Connected to gateway.sandbox.push.apple.com:2195
[2011-11-28 18:17:51] [Connection 2] Connected to gateway.sandbox.push.apple.com:2195
[2011-11-28 18:17:51] Ready
[2011-11-28 18:18:15] Notification 129 delivered to d46...
[2011-11-28 18:18:16] Notification 131 delivered to c40...
[2011-11-28 18:18:16] Notification 130 delivered to 1a7...
[2011-11-28 18:18:17] Notification 132 delivered to 30a...
[2011-11-28 18:18:17] Notification 133 delivered to 732...
[2011-11-28 18:18:17] Notification 134 delivered to a4a...
[2011-11-28 18:18:17] Notification 133 delivered to 732...
[2011-11-28 18:18:17] Notification 134 delivered to a4a...

Notice that notifications 133 and 134 were sent twice. I thought is had something to do with the 'stop' error but it seems to be something different. Should I open another issue?

Ah, I see the what the cause of the duplicates is. I'll try get to it in the next few days.

Great! I'll keep the master branch. Let me know when you fix the issue so I can test it for you.

Bump on this -- what's the source of the duplicates and how concerned should I be? I have rapns in production and duplicated push notifications are a large concern for me.

ileitch, now that you explained, everything makes sense.
When I send 1~3 notifications, no problem, but when I send more, the 4th and following notifications are sent twice.
In my case, is very common to send multiple notifications at a time because it is an alert I send to multiple users. It'd be very nice if you find a solution - or at least suggest some workaround I could use until then.

This issue should be closed, I've opened a new duplicate message specific Issue #20


bump sync plugin version

@gabemontero fyi
@tdawson can you package the 0.15 sync plugin and respin the jenkins rhel images? (no need to do the slave images, just v1 and v2)

@tdawson @bparees while we are at it, we need updates to openshift-login and openshift-pipeline as well.  v1.0.31 of openshift-pipeline and v0.8 of openshift-login.  The RHEL images on brew pulp are currently at 1.0.28 and 0.6.
Same caveats about not needing to do the slave images, just v1 and v2.

[test]

[test]

@bparees @tdawson I just had to cut a new version of openshift-pipeline (v1.0.32) for https://bugzilla.redhat.com/show_bug.cgi?id=1392780
do we want to handle bumping to that with this pull or a separate pull?
If with this pull, I'll update this PR when v1.0.32 is available for download from jenkinsci (should be later today)

@gabemontero looks like it's available now, i'll update this PR to pick it up.

Cool - thx @bparees

rpms built, puddles built
jenkins-plugin-openshift-login-0.8-1.el7
jenkins-plugin-openshift-pipeline-1.0.32-1.el7
jenkins-plugin-openshift-sync-0.0.15-1.el7
Should I wait for this pull request before creating the images?

@tdawson nope, shouldn't matter.  you can create the rhel images.

thx @tdawson

Images created, with this pull request in.
openshift3/jenkins-1-rhel7:1.651.2-29
openshift3/jenkins-2-rhel7:2.7-14


old content and commented-out code makes noise

In some files (for example, dataization.yaml and new.yaml), there are some lines of code that are commented out for some reason. We don't understand the reason and I'm sure nobody will, in, say a few years. Please, remove all lines that are commented out or turn them into proper TODO markers (preferably understood by PDD bot).
Also, there are some files that may be removed (like yegor.yaml). They are in the repository for historical reasons, but that's what Git history is for. No need to keep them in the repo, they only make it harder to understand the code base.

@deemp @fizruk please, pay attention to this

Thanks for pointing this out!


issue in deep_eq

some data element are not in correct format while comparing, in the screenshot, while compare transactions, in the data got from block the min_to_receive['amount'] should be int but actually it is string, and the result is that when you submit an order with returnID=True but  you cannot got the orderid

Oha .. those backend issues with int vs. string drive me crazy ..
any recommendations on how to fix this?


Extensions list link seems to be down

Describe the bug
Can't reach the tiptap-extensions list doc page
Steps to Reproduce / Codesandbox Example
Steps to reproduce the behavior:

Go to
Click on extensions list

The Built-In extensions have been moved to the Api Reference
https://tiptap.scrumpy.io/docs/api/extensions.html


Fix #915: Allow user to specify CRAN mirror via .Rprofile

Provide a way to not set any CRAN mirror via R Tools | Options at all, using whatever is set by R itself (e.g. via .Rprofile or other startup code) instead.

Changed to never allow @CRAN@, but otherwise respect settings if users chooses to.

:+1:


ReactiveLoadBalancer hangs console app

I have a console application that is using com.playtika.reactivefeign:feign-reactor-cloud2:2.0.2. This is using ReactiveLoadBalancer. On my Spring Boot console app, this prevents the console app from shutting down. Something is keeping the process alive. If I don't use the load balancer and hardcode the url to localhost:8080, the app shuts down fine.
This is opposed to com.playtika.reactivefeign:feign-reactor-cloud:2.0.2 which uses the Netflix loadbalancer and has the dreaded Illegal State Exception : Shutdown in Progress due to ShutdownEnabledTimer.

com.playtika.reactivefeign:feign-reactor-cloud is not part of Spring Cloud so I am not sure what we will be able to do about that.  Can you reproduce the issue without using that project?

com.playtika.reactivefeign:feign-reactor-cloud is not part of Spring Cloud so I am not sure what we will be able to do about that. Can you reproduce the issue without using that project?

Yes, I understand. I'm using ReactiveLoadBalancer.Factory for the load balancer however. Assuming there is a threadpool, no? If the threadpool is not shutdown, it will keep a process alive. It doesn't hang with DynamicServerListLoadBalancer. That one has the shutdown hook exception though. Should I open this over at Playtika instead?

If you can recreate the hanging without feign reactivate keep it here. Otherwise open it there.

If you can recreate the hanging without feign reactivate keep it here. Otherwise open it there.

Bypassing the load balancer and using an absolute address exits cleanly. Only using ReactiveLoadBalancer hangs. I ran in debug mode and viewed the threads:

bunch of Deamon threads for reactor-http-nio
1 for DiscoveryClient-CacheRefreshExecutor
1 for DiscoveryClient-HeartBeatExecutor
1 regular thread for DestroyJavaVM
1 threadpool still running named pool-1-thread-1

pool-1-thread-1, is that you guys? It is my understanding that if you don't shutdown the threadpool, the app can't exit cleanly, no?
When I terminated the threadpool, the app closed.

I had a similar issue with a Spring Boot (2.3.0.RELEASE) application using spring-cloud-starter-openfeign (Hoxton.SR5): Shutdown via actuator POST /actuator/shutdown left a dangling non-daemon thread pool-1-thread-2. I traced that down to originate in the com.stoyanr:evictor library that is used in the Spring Cloud Load Balancer cache implementation.
Specifically the DelayedTaskEvictionScheduler used in the DefaultLoadBalancerCache creates a default ScheduledThreadPoolExecutor (using non-daemon threads) that only gets shutdown when EvictionScheduler::shutdown is called which seems to be missing in DefaultLoadBalancerCache (according to the JavaDocs the evictors client code is responsible to call the shutdown() method).
I guess the DefaultLoadBalancerCache should therefore either shut down the eviction scheduler properly or supply a custom ScheduledExecutorService using a ThreadFactory that creates daemon threads.

I should add: my workaround was to disable the load balancer cache. Shutting down the application then worked fine :)

Thanks for the update. Should be relatively straight forward to clean up

@SledgeHammer01 @lohner Will work on a solution with daemon threads. If any of you is able to provide a sample that reproduces the issue for tests, that will be very helpful, as I was not able to reproduce the issue locally.

@SledgeHammer01 @lohner Will work on a solution with daemon threads. If any of you is able to provide a sample that reproduces the issue for tests, that will be very helpful, as I was not able to reproduce the issue locally.

@OlgaMaciaszek Here you can see a quick example: https://github.com/philippn/demo-gh-728

@OlgaMaciaszek Here you can see a quick example: https://github.com/philippn/demo-gh-728

I also just created an example app: https://github.com/lohner/spring-cloud-commons-issue728
Just launch via "gradle bootRun" and from a second terminal try "curl localhost:8888/" followed by "curl -X POST localhost:8888/actuator/shutdown". This will result in a dangling pool-1-thread-1 non-daemon thread.
Thanks!

I also just created an example app: https://github.com/lohner/spring-cloud-commons-issue728
Just launch via "gradle bootRun" and from a second terminal try "curl localhost:8888/" followed by "curl -X POST localhost:8888/actuator/shutdown". This will result in a dangling pool-1-thread-1 non-daemon thread.
Thanks!

@philippn @lohner Thanks a lot, will look today.

@philippn @lohner Thanks a lot, will look today.


Update everything

WIP, don't merge.

[x] update ember/cli
[x] run codemods
[x] update integration tests
[ ] fix linting errors
[ ] convert component unit tests to integration
[ ] update deps
[ ] release

Hi @knownasilya :)
I'm currently using this addon (works great, thanks for maintaining it). I Just tried updating to Ember 3.8 and apparently Ember 3.8 removed the "Ember.Map" that's used in the init function of the uploader service
init() {
    set(this, 'queues', Ember.Map.create()); // This line
    set(this, 'all', Ember.A());
  },

Making this addon incompatible with Ember 3.8 I guess (It works in 3.7). I've seen that this pull request is fixing (also) exactly this situation, but the Pull Request is open for a while. Is there something I can do to help you out?
Best regards

@corrspt would love if you could tackle any of the todo items above that are open. Feel free to just submit a PR against this PR.

@knownasilya Got it, I'll do my best! Thanks for the quick reply :)

Hey @knownasilya I started working on this yesterday and one the items here is to convert unit test in integration tests.
I ran into the issue that unit tests have access to internal stuff of Ember Plupload, not really sure how to tackle that (example of getting the upload queue: https://github.com/knownasilya/ember-plupload/blob/master/tests/unit/components/pl-uploader-test.js#L166-L176).
Should some of those tests be deleted? Maintained as unit tests? How would I go about converting them? I've seen in the PR an example of converting a test (which was really useful). Maybe I just need to get more acquainted on how things work, but would appreciate a little help :)
Thanks :)

I think we can do both. In some places it makes sense to move a unit test to integration because it happens to use internal state but can actually be tested in another way. I'm not against keeping some of the tests as unit where it makes sense. Also we could probably do followup prs later.

Hi @knownasilya
Very sorry for the long delay in replying. I couldn't migrate the tests after some work and I missed my "upgrade time" and I haven't done anything in the last few months regarding this. I hope to get another upgrade time soon and take a stab at this.
I did spend sometime looking at the unit tests, but several of them I really didn't know how to migrate as they seemed to test some internal stuff (on the other hand they were failing, and I also didn't know how to make them pass).

@corrspt no problem. I might have a look this weekend.