Conversion of verified IBM 720 raw dump to IMG fails

I dumped a disk that had some read errors during dumping, but after retries all sectors were dumped successfully according to the logs during the dumping process:
> gw read --tracks=c=0-81 --retries 5 --seek-retries 4 --format ibm.720 --revs 5 --raw raw/MBASH4_00.0.raw

Reading c=0-81:h=0-1 revs=5
Format ibm.720
T0.0: IBM MFM (9/9 sectors) from Raw Flux (215994 flux in 1000.40ms)
T0.1: IBM MFM (9/9 sectors) from Raw Flux (215845 flux in 999.81ms)
T1.0: IBM MFM (9/9 sectors) from Raw Flux (189925 flux in 999.77ms)
T1.1: IBM MFM (9/9 sectors) from Raw Flux (190034 flux in 999.56ms)
T2.0: IBM MFM (9/9 sectors) from Raw Flux (190090 flux in 999.67ms)
T2.1: IBM MFM (9/9 sectors) from Raw Flux (190484 flux in 999.51ms)
T3.0: IBM MFM (9/9 sectors) from Raw Flux (190406 flux in 999.65ms)
T3.1: IBM MFM (9/9 sectors) from Raw Flux (190426 flux in 999.51ms)
T4.0: IBM MFM (9/9 sectors) from Raw Flux (190440 flux in 999.65ms)
T4.1: IBM MFM (9/9 sectors) from Raw Flux (190155 flux in 999.50ms)
T5.0: IBM MFM (9/9 sectors) from Raw Flux (189485 flux in 999.58ms)
T5.1: IBM MFM (9/9 sectors) from Raw Flux (189974 flux in 999.47ms)
T6.0: IBM MFM (9/9 sectors) from Raw Flux (189906 flux in 999.56ms)
T6.1: IBM MFM (9/9 sectors) from Raw Flux (189854 flux in 999.48ms)
T7.0: IBM MFM (9/9 sectors) from Raw Flux (189764 flux in 999.57ms)
T7.1: IBM MFM (9/9 sectors) from Raw Flux (190554 flux in 999.45ms)
T8.0: IBM MFM (9/9 sectors) from Raw Flux (189946 flux in 999.56ms)
T8.1: IBM MFM (9/9 sectors) from Raw Flux (190874 flux in 999.46ms)
T9.0: IBM MFM (9/9 sectors) from Raw Flux (190246 flux in 999.55ms)
T9.1: IBM MFM (9/9 sectors) from Raw Flux (190234 flux in 999.45ms)
T10.0: IBM MFM (9/9 sectors) from Raw Flux (189917 flux in 999.50ms)
T10.1: IBM MFM (9/9 sectors) from Raw Flux (190415 flux in 999.45ms)
T11.0: IBM MFM (9/9 sectors) from Raw Flux (190234 flux in 999.49ms)
T11.1: IBM MFM (9/9 sectors) from Raw Flux (190175 flux in 999.43ms)
T12.0: IBM MFM (9/9 sectors) from Raw Flux (189655 flux in 999.48ms)
T12.1: IBM MFM (9/9 sectors) from Raw Flux (189725 flux in 999.45ms)
T13.0: IBM MFM (9/9 sectors) from Raw Flux (189933 flux in 999.49ms)
T13.1: IBM MFM (9/9 sectors) from Raw Flux (189974 flux in 999.44ms)
T14.0: IBM MFM (9/9 sectors) from Raw Flux (189506 flux in 999.50ms)
T14.1: IBM MFM (9/9 sectors) from Raw Flux (189841 flux in 999.42ms)
T15.0: IBM MFM (9/9 sectors) from Raw Flux (190190 flux in 999.47ms)
T15.1: IBM MFM (9/9 sectors) from Raw Flux (190423 flux in 999.45ms)
T16.0: IBM MFM (9/9 sectors) from Raw Flux (189797 flux in 999.48ms)
T16.1: IBM MFM (9/9 sectors) from Raw Flux (189864 flux in 999.44ms)
T17.0: IBM MFM (9/9 sectors) from Raw Flux (189464 flux in 999.51ms)
T17.1: IBM MFM (9/9 sectors) from Raw Flux (189582 flux in 999.45ms)
T18.0: IBM MFM (9/9 sectors) from Raw Flux (189384 flux in 999.53ms)
T18.1: IBM MFM (9/9 sectors) from Raw Flux (190515 flux in 999.44ms)
T19.0: IBM MFM (9/9 sectors) from Raw Flux (189944 flux in 999.49ms)
T19.1: IBM MFM (9/9 sectors) from Raw Flux (191335 flux in 999.45ms)
T20.0: IBM MFM (9/9 sectors) from Raw Flux (190386 flux in 999.49ms)
T20.1: IBM MFM (9/9 sectors) from Raw Flux (189869 flux in 999.44ms)
T21.0: IBM MFM (9/9 sectors) from Raw Flux (189765 flux in 999.50ms)
T21.1: IBM MFM (9/9 sectors) from Raw Flux (189824 flux in 999.42ms)
T22.0: IBM MFM (9/9 sectors) from Raw Flux (190023 flux in 999.47ms)
T22.1: IBM MFM (9/9 sectors) from Raw Flux (190083 flux in 999.42ms)
T23.0: IBM MFM (9/9 sectors) from Raw Flux (189686 flux in 999.45ms)
T23.1: IBM MFM (9/9 sectors) from Raw Flux (190284 flux in 999.42ms)
T24.0: IBM MFM (9/9 sectors) from Raw Flux (190664 flux in 999.43ms)
T24.1: IBM MFM (9/9 sectors) from Raw Flux (191193 flux in 999.43ms)
T25.0: IBM MFM (9/9 sectors) from Raw Flux (191393 flux in 999.46ms)
T25.1: IBM MFM (9/9 sectors) from Raw Flux (190387 flux in 999.43ms)
T26.0: IBM MFM (9/9 sectors) from Raw Flux (189495 flux in 999.46ms)
T26.1: IBM MFM (9/9 sectors) from Raw Flux (189956 flux in 999.42ms)
T27.0: IBM MFM (9/9 sectors) from Raw Flux (191176 flux in 999.46ms)
T27.1: IBM MFM (9/9 sectors) from Raw Flux (190894 flux in 999.43ms)
T28.0: IBM MFM (9/9 sectors) from Raw Flux (190527 flux in 999.45ms)
T28.1: IBM MFM (9/9 sectors) from Raw Flux (189829 flux in 999.41ms)
T29.0: IBM MFM (9/9 sectors) from Raw Flux (189785 flux in 999.49ms)
T29.1: IBM MFM (9/9 sectors) from Raw Flux (190456 flux in 999.45ms)
T30.0: IBM MFM (9/9 sectors) from Raw Flux (190303 flux in 999.42ms)
T30.1: IBM MFM (9/9 sectors) from Raw Flux (190654 flux in 999.40ms)
T31.0: IBM MFM (9/9 sectors) from Raw Flux (190605 flux in 999.42ms)
T31.1: IBM MFM (9/9 sectors) from Raw Flux (190820 flux in 999.42ms)
T32.0: IBM MFM (9/9 sectors) from Raw Flux (190421 flux in 999.43ms)
T32.1: IBM MFM (9/9 sectors) from Raw Flux (189503 flux in 999.43ms)
T33.0: IBM MFM (9/9 sectors) from Raw Flux (189795 flux in 999.48ms)
T33.1: IBM MFM (9/9 sectors) from Raw Flux (189398 flux in 999.45ms)
T34.0: IBM MFM (9/9 sectors) from Raw Flux (189953 flux in 999.43ms)
T34.1: IBM MFM (9/9 sectors) from Raw Flux (189705 flux in 999.43ms)
T35.0: IBM MFM (9/9 sectors) from Raw Flux (189926 flux in 999.46ms)
T35.1: IBM MFM (9/9 sectors) from Raw Flux (190315 flux in 999.44ms)
T36.0: IBM MFM (9/9 sectors) from Raw Flux (190406 flux in 999.48ms)
T36.1: IBM MFM (9/9 sectors) from Raw Flux (190285 flux in 999.45ms)
T37.0: IBM MFM (9/9 sectors) from Raw Flux (189656 flux in 999.51ms)
T37.1: IBM MFM (9/9 sectors) from Raw Flux (189764 flux in 999.45ms)
T38.0: IBM MFM (9/9 sectors) from Raw Flux (189689 flux in 999.48ms)
T38.1: IBM MFM (9/9 sectors) from Raw Flux (190266 flux in 999.46ms)
T39.0: IBM MFM (9/9 sectors) from Raw Flux (190191 flux in 999.49ms)
T39.1: IBM MFM (9/9 sectors) from Raw Flux (189295 flux in 999.46ms)
T40.0: IBM MFM (9/9 sectors) from Raw Flux (191383 flux in 999.51ms)
T40.1: IBM MFM (9/9 sectors) from Raw Flux (190140 flux in 999.49ms)
T41.0: IBM MFM (9/9 sectors) from Raw Flux (190115 flux in 999.50ms)
T41.1: IBM MFM (9/9 sectors) from Raw Flux (189795 flux in 999.45ms)
T42.0: IBM MFM (9/9 sectors) from Raw Flux (189785 flux in 999.51ms)
T42.1: IBM MFM (9/9 sectors) from Raw Flux (190715 flux in 999.47ms)
T43.0: IBM MFM (9/9 sectors) from Raw Flux (189935 flux in 999.50ms)
T43.1: IBM MFM (9/9 sectors) from Raw Flux (190403 flux in 999.47ms)
T44.0: IBM MFM (9/9 sectors) from Raw Flux (190146 flux in 999.51ms)
T44.1: IBM MFM (9/9 sectors) from Raw Flux (189846 flux in 999.48ms)
T45.0: IBM MFM (9/9 sectors) from Raw Flux (190044 flux in 999.51ms)
T45.1: IBM MFM (9/9 sectors) from Raw Flux (190026 flux in 999.46ms)
T46.0: IBM MFM (9/9 sectors) from Raw Flux (190480 flux in 999.49ms)
T46.1: IBM MFM (9/9 sectors) from Raw Flux (190293 flux in 999.46ms)
T47.0: IBM MFM (9/9 sectors) from Raw Flux (189823 flux in 999.48ms)
T47.1: IBM MFM (9/9 sectors) from Raw Flux (190284 flux in 999.41ms)
T48.0: IBM MFM (9/9 sectors) from Raw Flux (189886 flux in 999.50ms)
T48.1: IBM MFM (9/9 sectors) from Raw Flux (190046 flux in 999.43ms)
T49.0: IBM MFM (9/9 sectors) from Raw Flux (189848 flux in 999.47ms)
T49.1: IBM MFM (9/9 sectors) from Raw Flux (189960 flux in 999.44ms)
T50.0: IBM MFM (9/9 sectors) from Raw Flux (190368 flux in 999.46ms)
T50.1: IBM MFM (9/9 sectors) from Raw Flux (189525 flux in 999.46ms)
T51.0: IBM MFM (9/9 sectors) from Raw Flux (190067 flux in 999.49ms)
T51.1: IBM MFM (9/9 sectors) from Raw Flux (190494 flux in 999.44ms)
T52.0: IBM MFM (9/9 sectors) from Raw Flux (189932 flux in 999.52ms)
T52.1: IBM MFM (9/9 sectors) from Raw Flux (189326 flux in 999.43ms)
T53.0: IBM MFM (9/9 sectors) from Raw Flux (188719 flux in 999.50ms)
T53.1: IBM MFM (9/9 sectors) from Raw Flux (189425 flux in 999.45ms)
T54.0: IBM MFM (9/9 sectors) from Raw Flux (190014 flux in 999.48ms)
T54.1: IBM MFM (9/9 sectors) from Raw Flux (189315 flux in 999.43ms)
T55.0: IBM MFM (9/9 sectors) from Raw Flux (190338 flux in 999.47ms)
T55.1: IBM MFM (9/9 sectors) from Raw Flux (190054 flux in 999.43ms)
T56.0: IBM MFM (9/9 sectors) from Raw Flux (189352 flux in 999.46ms)
T56.1: IBM MFM (9/9 sectors) from Raw Flux (189706 flux in 999.43ms)
T57.0: IBM MFM (9/9 sectors) from Raw Flux (190221 flux in 999.49ms)
T57.1: IBM MFM (9/9 sectors) from Raw Flux (190177 flux in 999.45ms)
T58.0: IBM MFM (9/9 sectors) from Raw Flux (190092 flux in 999.47ms)
T58.1: IBM MFM (9/9 sectors) from Raw Flux (189428 flux in 999.42ms)
T59.0: IBM MFM (9/9 sectors) from Raw Flux (190062 flux in 999.47ms)
T59.1: IBM MFM (9/9 sectors) from Raw Flux (189644 flux in 999.45ms)
T60.0: IBM MFM (9/9 sectors) from Raw Flux (189671 flux in 999.49ms)
T60.1: IBM MFM (9/9 sectors) from Raw Flux (190549 flux in 999.47ms)
T61.0: IBM MFM (9/9 sectors) from Raw Flux (189995 flux in 999.48ms)
T61.1: IBM MFM (9/9 sectors) from Raw Flux (189253 flux in 999.45ms)
T62.0: IBM MFM (9/9 sectors) from Raw Flux (192463 flux in 999.48ms)
T62.1: IBM MFM (9/9 sectors) from Raw Flux (189291 flux in 999.44ms)
T63.0: IBM MFM (9/9 sectors) from Raw Flux (190375 flux in 999.39ms)
T63.1: IBM MFM (9/9 sectors) from Raw Flux (190884 flux in 999.45ms)
T64.0: IBM MFM (9/9 sectors) from Raw Flux (190107 flux in 999.33ms)
T64.1: IBM MFM (9/9 sectors) from Raw Flux (189896 flux in 999.43ms)
T65.0: IBM MFM (9/9 sectors) from Raw Flux (190497 flux in 999.33ms)
T65.1: IBM MFM (9/9 sectors) from Raw Flux (190477 flux in 999.44ms)
T66.0: IBM MFM (9/9 sectors) from Raw Flux (189106 flux in 999.44ms)
T66.1: IBM MFM (9/9 sectors) from Raw Flux (190686 flux in 999.43ms)
Unknown mark f9
T67.0: IBM MFM (9/9 sectors) from Raw Flux (190714 flux in 999.49ms)
T67.1: IBM MFM (9/9 sectors) from Raw Flux (189535 flux in 999.46ms)
Unknown mark f9
T68.0: IBM MFM (8/9 sectors) from Raw Flux (190226 flux in 999.46ms)
Unknown mark f9
T68.0: IBM MFM (9/9 sectors) from Raw Flux (380450 flux in 1998.90ms) (Retry #1.1)
T68.1: IBM MFM (9/9 sectors) from Raw Flux (190121 flux in 999.42ms)
T69.0: IBM MFM (7/9 sectors) from Raw Flux (191396 flux in 999.45ms)
T69.0: IBM MFM (8/9 sectors) from Raw Flux (382792 flux in 1998.91ms) (Retry #1.1)
T69.0: IBM MFM (8/9 sectors) from Raw Flux (574185 flux in 2998.34ms) (Retry #1.2)
T69.0: IBM MFM (8/9 sectors) from Raw Flux (765580 flux in 3997.74ms) (Retry #1.3)
T69.0: IBM MFM (8/9 sectors) from Raw Flux (956976 flux in 4997.15ms) (Retry #1.4)
T69.0: IBM MFM (9/9 sectors) from Raw Flux (1148369 flux in 5996.54ms) (Retry #1.5)
T69.1: IBM MFM (9/9 sectors) from Raw Flux (189845 flux in 999.42ms)
Unknown mark f9
Unknown mark f9
T70.0: IBM MFM (8/9 sectors) from Raw Flux (189130 flux in 999.40ms)
T70.0: IBM MFM (8/9 sectors) from Raw Flux (378388 flux in 1998.86ms) (Retry #1.1)
T70.0: IBM MFM (8/9 sectors) from Raw Flux (567644 flux in 2998.30ms) (Retry #1.2)
T70.0: IBM MFM (9/9 sectors) from Raw Flux (756899 flux in 3997.74ms) (Retry #1.3)
T70.1: IBM MFM (9/9 sectors) from Raw Flux (189764 flux in 999.43ms)
Unknown mark f9
Unknown mark f9
Unknown mark f9
Unknown mark fa
Unknown mark f9
Unknown mark f9
T71.0: IBM MFM (5/9 sectors) from Raw Flux (189404 flux in 999.37ms)
Unknown mark f9
T71.0: IBM MFM (7/9 sectors) from Raw Flux (378848 flux in 1998.80ms) (Retry #1.1)
Unknown mark f9
Unknown mark fa
Unknown mark fa
Unknown mark f9
Unknown mark f9
Unknown mark fa
T71.0: IBM MFM (9/9 sectors) from Raw Flux (568293 flux in 2998.22ms) (Retry #1.2)
T71.1: IBM MFM (9/9 sectors) from Raw Flux (190814 flux in 999.39ms)
Unknown mark a9
Unknown mark f9
Unknown mark f9
T72.0: IBM MFM (1/9 sectors) from Raw Flux (190549 flux in 999.37ms)
Unknown mark f9
T72.0: IBM MFM (2/9 sectors) from Raw Flux (381298 flux in 1998.73ms) (Retry #1.1)
Unknown mark f9
Unknown mark f9
Unknown mark f9
T72.0: IBM MFM (5/9 sectors) from Raw Flux (572054 flux in 2998.06ms) (Retry #1.2)
Unknown mark f9
T72.0: IBM MFM (5/9 sectors) from Raw Flux (762810 flux in 3997.42ms) (Retry #1.3)
Unknown mark e9
Unknown mark e0
T72.0: IBM MFM (5/9 sectors) from Raw Flux (953562 flux in 4996.75ms) (Retry #1.4)
Unknown mark f9
Unknown mark f9
T72.0: IBM MFM (5/9 sectors) from Raw Flux (1144313 flux in 5996.11ms) (Retry #1.5)
T72.0: IBM MFM (9/9 sectors) from Raw Flux (1335068 flux in 6995.48ms) (Retry #2.1)
T72.1: IBM MFM (9/9 sectors) from Raw Flux (190026 flux in 999.43ms)
T73.0: IBM MFM (9/9 sectors) from Raw Flux (189805 flux in 999.38ms)
T73.1: IBM MFM (9/9 sectors) from Raw Flux (190284 flux in 999.41ms)
T74.0: IBM MFM (9/9 sectors) from Raw Flux (189665 flux in 999.42ms)
T74.1: IBM MFM (9/9 sectors) from Raw Flux (190256 flux in 999.43ms)
T75.0: IBM MFM (9/9 sectors) from Raw Flux (189627 flux in 999.46ms)
T75.1: IBM MFM (9/9 sectors) from Raw Flux (189492 flux in 999.40ms)
T76.0: IBM MFM (9/9 sectors) from Raw Flux (189543 flux in 999.38ms)
T76.1: IBM MFM (9/9 sectors) from Raw Flux (190161 flux in 999.43ms)
Unknown mark f9
Unknown mark fa
Unknown mark fa
Unknown mark fa
Unknown mark fa
T77.0: IBM MFM (5/9 sectors) from Raw Flux (189685 flux in 999.38ms)
Unknown mark fa
Unknown mark fa
Unknown mark f9
T77.0: IBM MFM (9/9 sectors) from Raw Flux (379371 flux in 1998.79ms) (Retry #1.1)
T77.1: IBM MFM (9/9 sectors) from Raw Flux (190503 flux in 999.44ms)
Unknown mark e9
Unknown mark fa
Unknown mark fa
Unknown mark e9
Unknown mark fa
Unknown mark 76
Unknown mark f9
Unknown mark e9
Unknown mark eb
T78.0: IBM MFM (0/9 sectors) from Raw Flux (190681 flux in 999.34ms)
Unknown mark f9
Unknown mark e8
Unknown mark f9
Unknown mark f9
Unknown mark e9
Unknown mark f9
Unknown mark f9
Unknown mark f9
T78.0: IBM MFM (1/9 sectors) from Raw Flux (381536 flux in 1998.76ms) (Retry #1.1)
Unknown mark f9
Unknown mark e9
Unknown mark fa
Unknown mark e9
Unknown mark f9
Unknown mark e9
Unknown mark f9
T78.0: IBM MFM (3/9 sectors) from Raw Flux (572400 flux in 2998.17ms) (Retry #1.2)
Unknown mark fa
Unknown mark f9
Unknown mark fa
Unknown mark f9
Unknown mark f9
Unknown mark f9
T78.0: IBM MFM (5/9 sectors) from Raw Flux (763264 flux in 3997.55ms) (Retry #1.3)
Unknown mark fa
Unknown mark fa
Unknown mark f9
T78.0: IBM MFM (6/9 sectors) from Raw Flux (954129 flux in 4996.95ms) (Retry #1.4)
Unknown mark f9
Unknown mark fa
Unknown mark e4
Unknown mark f9
Unknown mark f9
T78.0: IBM MFM (7/9 sectors) from Raw Flux (1144993 flux in 5996.29ms) (Retry #1.5)
T78.0: IBM MFM (9/9 sectors) from Raw Flux (1335858 flux in 6995.66ms) (Retry #2.1)
T78.1: IBM MFM (9/9 sectors) from Raw Flux (200396 flux in 999.34ms)
T79.0: IBM MFM (9/9 sectors) from Raw Flux (235988 flux in 999.40ms)
T79.1: IBM MFM (9/9 sectors) from Raw Flux (235935 flux in 999.42ms)
T80.0: WARNING: Out of range for for format 'ibm.720': No format conversion applied
T80.1: WARNING: Out of range for for format 'ibm.720': No format conversion applied
T81.0: WARNING: Out of range for for format 'ibm.720': No format conversion applied
T81.1: WARNING: Out of range for for format 'ibm.720': No format conversion applied
Cyl-> 0         1         2         3         4         5         6         7         8
H. S:<PHONE_NUMBER>012345678901234567890123456789012345678901234567890123456789012345678901
0. 0: ................................................................................
0. 1: ................................................................................
0. 2: ................................................................................
0. 3: ................................................................................
0. 4: ................................................................................
0. 5: ................................................................................
0. 6: ................................................................................
0. 7: ................................................................................
0. 8: ................................................................................
1. 0: ................................................................................
1. 1: ................................................................................
1. 2: ................................................................................
1. 3: ................................................................................
1. 4: ................................................................................
1. 5: ................................................................................
1. 6: ................................................................................
1. 7: ................................................................................
1. 8: ................................................................................
Found 1440 sectors of 1440 (100%)

Now I tried converting this very same image to IMG as follows and get that 1 sector has an error:
> gw convert --format=ibm.720 raw/MBASH4_00.0.raw MBASH4.img

Converting c=0-79:h=0-1 -> c=0-79:h=0-1
Format ibm.720
T0.0: IBM MFM (9/9 sectors) from Raw Flux (215995 flux in 1000.41ms)
T0.1: IBM MFM (9/9 sectors) from Raw Flux (215846 flux in 999.82ms)
T1.0: IBM MFM (9/9 sectors) from Raw Flux (189926 flux in 999.78ms)
T1.1: IBM MFM (9/9 sectors) from Raw Flux (190035 flux in 999.58ms)
T2.0: IBM MFM (9/9 sectors) from Raw Flux (190091 flux in 999.68ms)
T2.1: IBM MFM (9/9 sectors) from Raw Flux (190485 flux in 999.52ms)
T3.0: IBM MFM (9/9 sectors) from Raw Flux (190407 flux in 999.66ms)
T3.1: IBM MFM (9/9 sectors) from Raw Flux (190427 flux in 999.52ms)
T4.0: IBM MFM (9/9 sectors) from Raw Flux (190441 flux in 999.66ms)
T4.1: IBM MFM (9/9 sectors) from Raw Flux (190156 flux in 999.51ms)
T5.0: IBM MFM (9/9 sectors) from Raw Flux (189486 flux in 999.59ms)
T5.1: IBM MFM (9/9 sectors) from Raw Flux (189975 flux in 999.48ms)
T6.0: IBM MFM (9/9 sectors) from Raw Flux (189907 flux in 999.57ms)
T6.1: IBM MFM (9/9 sectors) from Raw Flux (189855 flux in 999.49ms)
T7.0: IBM MFM (9/9 sectors) from Raw Flux (189765 flux in 999.58ms)
T7.1: IBM MFM (9/9 sectors) from Raw Flux (190555 flux in 999.46ms)
T8.0: IBM MFM (9/9 sectors) from Raw Flux (189947 flux in 999.57ms)
T8.1: IBM MFM (9/9 sectors) from Raw Flux (190875 flux in 999.47ms)
T9.0: IBM MFM (9/9 sectors) from Raw Flux (190247 flux in 999.56ms)
T9.1: IBM MFM (9/9 sectors) from Raw Flux (190235 flux in 999.46ms)
T10.0: IBM MFM (9/9 sectors) from Raw Flux (189918 flux in 999.51ms)
T10.1: IBM MFM (9/9 sectors) from Raw Flux (190416 flux in 999.46ms)
T11.0: IBM MFM (9/9 sectors) from Raw Flux (190235 flux in 999.50ms)
T11.1: IBM MFM (9/9 sectors) from Raw Flux (190176 flux in 999.44ms)
T12.0: IBM MFM (9/9 sectors) from Raw Flux (189656 flux in 999.49ms)
T12.1: IBM MFM (9/9 sectors) from Raw Flux (189726 flux in 999.47ms)
T13.0: IBM MFM (9/9 sectors) from Raw Flux (189934 flux in 999.50ms)
T13.1: IBM MFM (9/9 sectors) from Raw Flux (189975 flux in 999.45ms)
T14.0: IBM MFM (9/9 sectors) from Raw Flux (189507 flux in 999.52ms)
T14.1: IBM MFM (9/9 sectors) from Raw Flux (189842 flux in 999.43ms)
T15.0: IBM MFM (9/9 sectors) from Raw Flux (190191 flux in 999.48ms)
T15.1: IBM MFM (9/9 sectors) from Raw Flux (190424 flux in 999.46ms)
T16.0: IBM MFM (9/9 sectors) from Raw Flux (189798 flux in 999.49ms)
T16.1: IBM MFM (9/9 sectors) from Raw Flux (189865 flux in 999.45ms)
T17.0: IBM MFM (9/9 sectors) from Raw Flux (189465 flux in 999.52ms)
T17.1: IBM MFM (9/9 sectors) from Raw Flux (189583 flux in 999.46ms)
T18.0: IBM MFM (9/9 sectors) from Raw Flux (189385 flux in 999.54ms)
T18.1: IBM MFM (9/9 sectors) from Raw Flux (190516 flux in 999.45ms)
T19.0: IBM MFM (9/9 sectors) from Raw Flux (189945 flux in 999.51ms)
T19.1: IBM MFM (9/9 sectors) from Raw Flux (191336 flux in 999.46ms)
T20.0: IBM MFM (9/9 sectors) from Raw Flux (190387 flux in 999.50ms)
T20.1: IBM MFM (9/9 sectors) from Raw Flux (189870 flux in 999.45ms)
T21.0: IBM MFM (9/9 sectors) from Raw Flux (189766 flux in 999.51ms)
T21.1: IBM MFM (9/9 sectors) from Raw Flux (189825 flux in 999.44ms)
T22.0: IBM MFM (9/9 sectors) from Raw Flux (190024 flux in 999.48ms)
T22.1: IBM MFM (9/9 sectors) from Raw Flux (190084 flux in 999.44ms)
T23.0: IBM MFM (9/9 sectors) from Raw Flux (189687 flux in 999.46ms)
T23.1: IBM MFM (9/9 sectors) from Raw Flux (190285 flux in 999.43ms)
T24.0: IBM MFM (9/9 sectors) from Raw Flux (190665 flux in 999.44ms)
T24.1: IBM MFM (9/9 sectors) from Raw Flux (191194 flux in 999.44ms)
T25.0: IBM MFM (9/9 sectors) from Raw Flux (191394 flux in 999.47ms)
T25.1: IBM MFM (9/9 sectors) from Raw Flux (190388 flux in 999.44ms)
T26.0: IBM MFM (9/9 sectors) from Raw Flux (189496 flux in 999.47ms)
T26.1: IBM MFM (9/9 sectors) from Raw Flux (189957 flux in 999.43ms)
T27.0: IBM MFM (9/9 sectors) from Raw Flux (191177 flux in 999.47ms)
T27.1: IBM MFM (9/9 sectors) from Raw Flux (190895 flux in 999.44ms)
T28.0: IBM MFM (9/9 sectors) from Raw Flux (190528 flux in 999.46ms)
T28.1: IBM MFM (9/9 sectors) from Raw Flux (189830 flux in 999.42ms)
T29.0: IBM MFM (9/9 sectors) from Raw Flux (189786 flux in 999.51ms)
T29.1: IBM MFM (9/9 sectors) from Raw Flux (190457 flux in 999.47ms)
T30.0: IBM MFM (9/9 sectors) from Raw Flux (190304 flux in 999.43ms)
T30.1: IBM MFM (9/9 sectors) from Raw Flux (190655 flux in 999.41ms)
T31.0: IBM MFM (9/9 sectors) from Raw Flux (190606 flux in 999.43ms)
T31.1: IBM MFM (9/9 sectors) from Raw Flux (190821 flux in 999.43ms)
T32.0: IBM MFM (9/9 sectors) from Raw Flux (190422 flux in 999.44ms)
T32.1: IBM MFM (9/9 sectors) from Raw Flux (189504 flux in 999.44ms)
T33.0: IBM MFM (9/9 sectors) from Raw Flux (189796 flux in 999.49ms)
T33.1: IBM MFM (9/9 sectors) from Raw Flux (189399 flux in 999.46ms)
T34.0: IBM MFM (9/9 sectors) from Raw Flux (189954 flux in 999.44ms)
T34.1: IBM MFM (9/9 sectors) from Raw Flux (189706 flux in 999.45ms)
T35.0: IBM MFM (9/9 sectors) from Raw Flux (189927 flux in 999.47ms)
T35.1: IBM MFM (9/9 sectors) from Raw Flux (190316 flux in 999.45ms)
T36.0: IBM MFM (9/9 sectors) from Raw Flux (190407 flux in 999.49ms)
T36.1: IBM MFM (9/9 sectors) from Raw Flux (190286 flux in 999.46ms)
T37.0: IBM MFM (9/9 sectors) from Raw Flux (189657 flux in 999.52ms)
T37.1: IBM MFM (9/9 sectors) from Raw Flux (189765 flux in 999.46ms)
T38.0: IBM MFM (9/9 sectors) from Raw Flux (189690 flux in 999.49ms)
T38.1: IBM MFM (9/9 sectors) from Raw Flux (190267 flux in 999.47ms)
T39.0: IBM MFM (9/9 sectors) from Raw Flux (190192 flux in 999.51ms)
T39.1: IBM MFM (9/9 sectors) from Raw Flux (189296 flux in 999.47ms)
T40.0: IBM MFM (9/9 sectors) from Raw Flux (191384 flux in 999.52ms)
T40.1: IBM MFM (9/9 sectors) from Raw Flux (190141 flux in 999.51ms)
T41.0: IBM MFM (9/9 sectors) from Raw Flux (190116 flux in 999.51ms)
T41.1: IBM MFM (9/9 sectors) from Raw Flux (189796 flux in 999.46ms)
T42.0: IBM MFM (9/9 sectors) from Raw Flux (189786 flux in 999.52ms)
T42.1: IBM MFM (9/9 sectors) from Raw Flux (190716 flux in 999.48ms)
T43.0: IBM MFM (9/9 sectors) from Raw Flux (189936 flux in 999.51ms)
T43.1: IBM MFM (9/9 sectors) from Raw Flux (190404 flux in 999.48ms)
T44.0: IBM MFM (9/9 sectors) from Raw Flux (190147 flux in 999.52ms)
T44.1: IBM MFM (9/9 sectors) from Raw Flux (189847 flux in 999.49ms)
T45.0: IBM MFM (9/9 sectors) from Raw Flux (190045 flux in 999.52ms)
T45.1: IBM MFM (9/9 sectors) from Raw Flux (190027 flux in 999.48ms)
T46.0: IBM MFM (9/9 sectors) from Raw Flux (190481 flux in 999.51ms)
T46.1: IBM MFM (9/9 sectors) from Raw Flux (190294 flux in 999.47ms)
T47.0: IBM MFM (9/9 sectors) from Raw Flux (189824 flux in 999.49ms)
T47.1: IBM MFM (9/9 sectors) from Raw Flux (190285 flux in 999.43ms)
T48.0: IBM MFM (9/9 sectors) from Raw Flux (189887 flux in 999.51ms)
T48.1: IBM MFM (9/9 sectors) from Raw Flux (190047 flux in 999.45ms)
T49.0: IBM MFM (9/9 sectors) from Raw Flux (189849 flux in 999.49ms)
T49.1: IBM MFM (9/9 sectors) from Raw Flux (189961 flux in 999.45ms)
T50.0: IBM MFM (9/9 sectors) from Raw Flux (190369 flux in 999.47ms)
T50.1: IBM MFM (9/9 sectors) from Raw Flux (189526 flux in 999.47ms)
T51.0: IBM MFM (9/9 sectors) from Raw Flux (190068 flux in 999.50ms)
T51.1: IBM MFM (9/9 sectors) from Raw Flux (190495 flux in 999.45ms)
T52.0: IBM MFM (9/9 sectors) from Raw Flux (189933 flux in 999.53ms)
T52.1: IBM MFM (9/9 sectors) from Raw Flux (189327 flux in 999.44ms)
T53.0: IBM MFM (9/9 sectors) from Raw Flux (188720 flux in 999.51ms)
T53.1: IBM MFM (9/9 sectors) from Raw Flux (189426 flux in 999.46ms)
T54.0: IBM MFM (9/9 sectors) from Raw Flux (190015 flux in 999.49ms)
T54.1: IBM MFM (9/9 sectors) from Raw Flux (189316 flux in 999.44ms)
T55.0: IBM MFM (9/9 sectors) from Raw Flux (190339 flux in 999.48ms)
T55.1: IBM MFM (9/9 sectors) from Raw Flux (190055 flux in 999.44ms)
T56.0: IBM MFM (9/9 sectors) from Raw Flux (189353 flux in 999.48ms)
T56.1: IBM MFM (9/9 sectors) from Raw Flux (189707 flux in 999.44ms)
T57.0: IBM MFM (9/9 sectors) from Raw Flux (190222 flux in 999.50ms)
T57.1: IBM MFM (9/9 sectors) from Raw Flux (190178 flux in 999.46ms)
T58.0: IBM MFM (9/9 sectors) from Raw Flux (190093 flux in 999.48ms)
T58.1: IBM MFM (9/9 sectors) from Raw Flux (189429 flux in 999.43ms)
T59.0: IBM MFM (9/9 sectors) from Raw Flux (190063 flux in 999.48ms)
T59.1: IBM MFM (9/9 sectors) from Raw Flux (189645 flux in 999.47ms)
T60.0: IBM MFM (9/9 sectors) from Raw Flux (189672 flux in 999.50ms)
T60.1: IBM MFM (9/9 sectors) from Raw Flux (190550 flux in 999.48ms)
T61.0: IBM MFM (9/9 sectors) from Raw Flux (189996 flux in 999.49ms)
T61.1: IBM MFM (9/9 sectors) from Raw Flux (189254 flux in 999.46ms)
T62.0: IBM MFM (9/9 sectors) from Raw Flux (192464 flux in 999.50ms)
T62.1: IBM MFM (9/9 sectors) from Raw Flux (189292 flux in 999.45ms)
T63.0: IBM MFM (9/9 sectors) from Raw Flux (190376 flux in 999.40ms)
T63.1: IBM MFM (9/9 sectors) from Raw Flux (190885 flux in 999.46ms)
T64.0: IBM MFM (9/9 sectors) from Raw Flux (190108 flux in 999.34ms)
T64.1: IBM MFM (9/9 sectors) from Raw Flux (189897 flux in 999.44ms)
T65.0: IBM MFM (9/9 sectors) from Raw Flux (190498 flux in 999.34ms)
T65.1: IBM MFM (9/9 sectors) from Raw Flux (190478 flux in 999.45ms)
T66.0: IBM MFM (9/9 sectors) from Raw Flux (189107 flux in 999.46ms)
T66.1: IBM MFM (9/9 sectors) from Raw Flux (190687 flux in 999.44ms)
Unknown mark f9
T67.0: IBM MFM (9/9 sectors) from Raw Flux (190715 flux in 999.51ms)
T67.1: IBM MFM (9/9 sectors) from Raw Flux (189536 flux in 999.47ms)
Unknown mark f9
Unknown mark f9
T68.0: IBM MFM (9/9 sectors) from Raw Flux (380451 flux in 1998.91ms)
T68.1: IBM MFM (9/9 sectors) from Raw Flux (190122 flux in 999.43ms)
T69.0: IBM MFM (8/9 sectors) from Raw Flux (1148370 flux in 5996.55ms)
T69.1: IBM MFM (9/9 sectors) from Raw Flux (189846 flux in 999.44ms)
Unknown mark f9
Unknown mark f9
T70.0: IBM MFM (9/9 sectors) from Raw Flux (756900 flux in 3997.75ms)
T70.1: IBM MFM (9/9 sectors) from Raw Flux (189765 flux in 999.44ms)
Unknown mark f9
Unknown mark f9
Unknown mark f9
Unknown mark f9
Unknown mark fa
Unknown mark f9
Unknown mark f9
Unknown mark f9
Unknown mark f9
Unknown mark f9
Unknown mark fa
Unknown mark fa
Unknown mark f9
Unknown mark f9
Unknown mark fa
T71.0: IBM MFM (9/9 sectors) from Raw Flux (568294 flux in 2998.23ms)
T71.1: IBM MFM (9/9 sectors) from Raw Flux (190815 flux in 999.41ms)
Unknown mark f9
Unknown mark f9
Unknown mark f9
Unknown mark f9
Unknown mark f9
Unknown mark f9
Unknown mark e9
Unknown mark e0
Unknown mark f9
T72.0: IBM MFM (9/9 sectors) from Raw Flux (1335069 flux in 6995.49ms)
T72.1: IBM MFM (9/9 sectors) from Raw Flux (190027 flux in 999.44ms)
T73.0: IBM MFM (9/9 sectors) from Raw Flux (189806 flux in 999.39ms)
T73.1: IBM MFM (9/9 sectors) from Raw Flux (190285 flux in 999.43ms)
T74.0: IBM MFM (9/9 sectors) from Raw Flux (189666 flux in 999.43ms)
T74.1: IBM MFM (9/9 sectors) from Raw Flux (190257 flux in 999.45ms)
T75.0: IBM MFM (9/9 sectors) from Raw Flux (189628 flux in 999.47ms)
T75.1: IBM MFM (9/9 sectors) from Raw Flux (189493 flux in 999.41ms)
Unknown mark fa
T76.0: IBM MFM (9/9 sectors) from Raw Flux (189544 flux in 999.39ms)
T76.1: IBM MFM (9/9 sectors) from Raw Flux (190162 flux in 999.44ms)
Unknown mark f9
Unknown mark fa
Unknown mark fa
Unknown mark fa
Unknown mark fa
Unknown mark fa
Unknown mark fa
T77.0: IBM MFM (9/9 sectors) from Raw Flux (379372 flux in 1998.80ms)
T77.1: IBM MFM (9/9 sectors) from Raw Flux (190504 flux in 999.45ms)
Unknown mark e9
Unknown mark fa
Unknown mark fa
Unknown mark e9
Unknown mark f9
Unknown mark e8
Unknown mark f9
Unknown mark e9
Unknown mark f9
Unknown mark e9
Unknown mark fa
Unknown mark e9
Unknown mark fa
Unknown mark fa
Unknown mark f9
Unknown mark fa
Unknown mark f9
Unknown mark f9
Unknown mark fa
Unknown mark fa
Unknown mark f9
Unknown mark fa
Unknown mark f2
T78.0: IBM MFM (9/9 sectors) from Raw Flux (1335859 flux in 6995.67ms)
T78.1: IBM MFM (9/9 sectors) from Raw Flux (200397 flux in 999.35ms)
T79.0: IBM MFM (9/9 sectors) from Raw Flux (235989 flux in 999.42ms)
T79.1: IBM MFM (9/9 sectors) from Raw Flux (235936 flux in 999.43ms)
Cyl-> 0         1         2         3         4         5         6         7
H. S:<PHONE_NUMBER>0123456789012345678901234567890123456789012345678901234567890123456789
0. 0: ................................................................................
0. 1: ................................................................................
0. 2: ................................................................................
0. 3: ................................................................................
0. 4: ................................................................................
0. 5: .....................................................................X..........
0. 6: ................................................................................
0. 7: ................................................................................
0. 8: ................................................................................
1. 0: ................................................................................
1. 1: ................................................................................
1. 2: ................................................................................
1. 3: ................................................................................
1. 4: ................................................................................
1. 5: ................................................................................
1. 6: ................................................................................
1. 7: ................................................................................
1. 8: ................................................................................
Found 1439 sectors of 1440 (99%)

I think my drive might need cleaning but I still expected it to get me a perfect dump since no errors occurred during the dumping.
Here is the raw dump:
MBASH4_RAW.zip

Wow, that is one marginal dump. It's amazing that all the sectors decode at all! Since this occurs on later tracks, I wonder if the density-selection is incorrect? Is this from a 5.25inch drive? Then you may need to specify --densel=L to gw read. If from a 3.5-inch drive it is possible that the physical density-select switch isn't working properly.
Anyway, back to why this doesn't decode corrcetly on subsequent gw convert. It is because the flux doesn't get converted to bitcells in exactly the same way.

On read, the subsequent read retries get passed through the PLL (clock recovery) individually, with PLL parameters reset on each retry
On convert, all the read retries are concatenated together and passed through PLL in one pass.

Anyway, as it happens the data is recoverable, you just need to play with the PLL parameters a bit. So there's something you probably didn't know about. By default, clock recovery tries two different PLL setups.

An aggressive PLL (period=5:phase=650)
A conservative PLL (period=1:phase=10)

You don't really need to know too much about what those parameters mean, but in almost all cases it is the conservative PLL that is saving your bacon when you have a marginal, noisy dump. So it makes sense to try alternative parameters close by to that default conservative setup. In this specific case, this works for me:
gw convert MBASH4_00.0.raw a.img --format=ibm.720 --pll=period=1:phase=15

So, all is not lost :)

Thank you! I had no idea it worked like that, but the command you provided works like a charm.
It is a 3.5 inch drive and the drive has worked properly reading other disks. I think this disk possibly had some dirt or something on it that accumulated on the read head which caused the later sector reads to get very noisy. Have had similar things happen before. I'll have to clean the heads and also try redumping it with another drive since this dump ended up a bit too noisy for my liking.


Typo

Github is saying the outputs changed, which I don't think is true!
This is the intended change:

Thanks @rowanc1. I'm seeing the diff and apparently there were some changes in some outputs:
$ nbdiff main notebooks/02-inversion-dc-resistivity-2d.ipynb
nbdiff notebooks/02-inversion-dc-resistivity-2d.ipynb (main) notebooks/02-inversion-dc-resistivity-2d.ipynb
--- notebooks/02-inversion-dc-resistivity-2d.ipynb (main)  (no timestamp)
+++ notebooks/02-inversion-dc-resistivity-2d.ipynb  2024-01-24 10:24:38.979579
## inserted before /cells/14/outputs/0:
+  output:
+    output_type: display_data
+    data:
+      image/png: iVBORw0K...<snip base64, md5=3f49c2b36d6902cb...>
+      text/plain: <Figure size 1000x200 with 1 Axes>

## deleted /cells/14/outputs/0:
-  output:
-    output_type: display_data
-    data:
-      image/png: iVBORw0K...<snip base64, md5=02239952714a4edc...>
-      text/plain: <Figure size 1000x200 with 1 Axes>

## inserted before /cells/16/outputs/0:
+  output:
+    output_type: display_data
+    data:
+      image/png: iVBORw0K...<snip base64, md5=46158db9d96045c2...>
+      text/plain: <Figure size 800x275 with 2 Axes>
+  output:
+    output_type: display_data
+    data:
+      image/png: iVBORw0K...<snip base64, md5=0a0c33139884e6bf...>
+      text/plain: <Figure size 800x275 with 2 Axes>

## deleted /cells/16/outputs/0-1:
-  output:
-    output_type: display_data
-    data:
-      image/png: iVBORw0K...<snip base64, md5=b10ab42c762a1991...>
-      text/plain: <Figure size 800x275 with 2 Axes>
-  output:
-    output_type: display_data
-    data:
-      image/png: iVBORw0K...<snip base64, md5=8768cedfac902767...>
-      text/plain: <Figure size 800x275 with 2 Axes>

## inserted before /cells/20/outputs/1:
+  output:
+    output_type: display_data
+    data:
+      image/png: iVBORw0K...<snip base64, md5=873af9cc8b297fdb...>
+      text/plain: <Figure size 700x500 with 1 Axes>

## deleted /cells/20/outputs/1:
-  output:
-    output_type: display_data
-    data:
-      image/png: iVBORw0K...<snip base64, md5=1e92e1784715d300...>
-      text/plain: <Figure size 700x500 with 1 Axes>

## modified /cells/21/source:
@@ -7,7 +7,7 @@ Here, we define the mesh used for the inversion. Not only will this define the n
 1. Because there are no currents in the air, we do not need to pad upwards. I.e. the top of the mesh corresponds to the top of the topography.
 2. We require at least 2-3 cells between each current electrode; with more accurate results being obtained when the minimum cell size is smaller. For a 2.5D problem geometry, we can discretize much finer.
 3. To be safe, the padding thickness should be at least 2-3 times the largest electrode spacing.
-4. The increase in cell size at increasing distancee from the current electrodes should not happen too abruptly. At each cell size, you should have a layer at least 4 cells thick before increasing the cell size.
+4. The increase in cell size at increasing distance from the current electrodes should not happen too abruptly. At each cell size, you should have a layer at least 4 cells thick before increasing the cell size.
 5. Finer discretization is required when topography is significant.

## inserted before /cells/61/outputs/0:
+  output:
+    output_type: display_data
+    data:
+      image/png: iVBORw0K...<snip base64, md5=eca66cbb5369f2b2...>
+      text/plain: <Figure size 1500x600 with 4 Axes>

## deleted /cells/61/outputs/0:
-  output:
-    output_type: display_data
-    data:
-      image/png: iVBORw0K...<snip base64, md5=b609a4e4c5bb17bc...>
-      text/plain: <Figure size 1500x600 with 4 Axes>

## inserted before /cells/65/outputs/0:
+  output:
+    output_type: display_data
+    data:
+      image/png: iVBORw0K...<snip base64, md5=b6e584ed8dbbbc6c...>
+      text/plain: <Figure size 700x900 with 6 Axes>

## deleted /cells/65/outputs/0:
-  output:
-    output_type: display_data
-    data:
-      image/png: iVBORw0K...<snip base64, md5=f4b5245f363e9f37...>
-      text/plain: <Figure size 700x900 with 6 Axes>

## inserted before /cells/67/outputs/0:
+  output:
+    output_type: display_data
+    data:
+      image/png: iVBORw0K...<snip base64, md5=3b5f547817488375...>
+      text/plain: <Figure size 800x275 with 2 Axes>
+  output:
+    output_type: display_data
+    data:
+      image/png: iVBORw0K...<snip base64, md5=bcc858437d4b8c52...>
+      text/plain: <Figure size 800x275 with 2 Axes>

## deleted /cells/67/outputs/0-1:
-  output:
-    output_type: display_data
-    data:
-      image/png: iVBORw0K...<snip base64, md5=1f84ce1701bdd8f6...>
-      text/plain: <Figure size 800x275 with 2 Axes>
-  output:
-    output_type: display_data
-    data:
-      image/png: iVBORw0K...<snip base64, md5=423b6287dcebf5a5...>
-      text/plain: <Figure size 800x275 with 2 Axes>

## inserted before /cells/71/outputs/0:
+  output:
+    output_type: display_data
+    data:
+      image/png: iVBORw0K...<snip base64, md5=03601356146385b0...>
+      text/plain: <Figure size 900x600 with 4 Axes>

## deleted /cells/71/outputs/0:
-  output:
-    output_type: display_data
-    data:
-      image/png: iVBORw0K...<snip base64, md5=7cf5133408f82d49...>
-      text/plain: <Figure size 900x600 with 4 Axes>

I've pushed changes to revert those modifications to the outputs

Now I'm merging this 🚀
Thanks for opening this PR!


Loading button

Description

Add a loading state to buttons since Inertia supports processing in useForm
Possible Implementation

Create a new atom component for button, add the prop: loading
Display https://mui.com/components/progress/ instead of regular text when processing is true
There is an implementation on it in Profile.tsx right now
Out of scope

Requirements / Restrictions

Hey team! Please add your planning poker estimate with ZenHub @AnnieTran13 @luigibesani @pascwhale


Information need about the actors persisted state on actors

Hi,
There is no information about the persisted actor state on the service fabric cluster local disk.
For example, we don't know how the ActorStateStore file size behaves when the actor,  or its state is deleted.
Regards,
Alexandre

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

ID: 7d674e09-226b-149f-07f1-f094bad3ef9c
Version Independent ID: e66f989b-f067-a96a-1643-140579caa575
Content: Delete Azure Service Fabric actors
Content Source: articles/service-fabric/service-fabric-reliable-actors-delete-actors.md
Service: service-fabric
GitHub Login: @amanbha
Microsoft Alias: amanbha

@sobral-a thanks for following up our forum discussion with this doc feedback :)
@amanbha can you please take a look and consider adding this information to the document? You can see this forum post for more information if needed: https://social.msdn.microsoft.com/Forums/azure/en-US/ba070715-62f4-483d-a053-fb7dde7a83ae/service-fabric-actors-what-is-the-correct-way-to-delete-the-persisted-actor-state-on-cluster-hard?forum=AzureServiceFabric

When a DeleteActorAsync call is made, all its state and metadata is deleted. So if you query Actor again you will  not get any information about the actor.
The file on the disk (for windows) is the local ese (https://msdn.microsoft.com/en-us/library/gg269259(v=exchg.10).aspx) database file, rows of data for the actor which is deleted are removed form it. How the database file contracts in size is different from actor state and deletion, the database has its logic of reclaiming free space in the file.  How the actor state is stored is an implementation detail as itcan change the implementation to change some other storage technology. On linux it currently uses different stack to sore information on disk.
The contract of the DeleteActorAsync api is that after an actor is deleted all its state is deleted, and if you make call for that actor again you will not see any state. How its persisted to disk is internal implementation detail and is platform dependent and can change in future.

Thank you for taking the time to share your product and documentation feedback with us. Your input is valued because it helps us create the right documentation for our customers. Due to the volume of issues in our queue, we are closing open issues older than 90 days. We hope to continue hearing from you. Thank you.


'Selenium.Support 3.141.0' is not compatible with '********constraint: Selenium.Support (>= 4.0.0-alpha05)'

Installing a nuget package that is Selenium 4 (alpha)- based  was not compatible with Appium 4.3.1
Framework: .NET Framework 4.7.2
Appium version: 4.3.1
MS Test Unit
Getting error:

This will be because thus library doesn't support selenium v4-x. The nuget package specifies that. Also we don't integrate alpha or beta dependencies


ci: release to Github also the compiled package, and a script to download it and publish to NPM

Make Release Please to also compile the package (using Svelte Package) when publishing to Github.
Add a script that download this generated version and upload to NPM
Update the README for instructions how to publish the new version to NPM

@orefalo , the last two commits, a13328dc1ac215547688f872eebd5171cce2acec and e76fc9906d101a5981f6b0df1589268f02253535 was accidentally pushed onto this branch instead of master, so just ignore them and review&merge the whole PR, so they could arrive to master eventually.

Happy new year @Tal500, success with your personal project.
The PR Looks good.

Happy new year @Tal500, success with your personal project. The PR Looks good.

Thanks! To you as well


Satellite v2: Updated documents

Updated documents based on changes from PR: https://github.com/censoredplanet/satellitev2/pull/60

@eltsai Has this been updated after the latest changes?

@ramakrishnansr This doc is up to date, can you please merge this?


Uncaught SyntaxError: Unexpected token ]

[Enter steps to reproduce below:]

i just click on the big red flashing button

Atom Version: 1.7.4 & 1.7.2 & 1.8.0 beta 4
System: Debian GNU/Linux
Thrown From: atom-lupa package, v0.5.46
Stack Trace
Uncaught SyntaxError: Unexpected token ]
At /home/pma/.atom/packages/atom-lupa/node_modules/react/lib/ReactErrorUtils.js:52

SyntaxError: Unexpected token ]
    at Object.parse (native)
    at Object.analysis.indexProject (/home/pma/.atom/packages/atom-lupa/node_modules/lupa/src/analysis.js:93:27)
    at /home/pma/.atom/packages/atom-lupa/lib/lupaMiddleware.js:54:30
    at /home/pma/.atom/packages/atom-lupa/lib/middleware/domMiddleware.js:22:9
    at Object.dispatch (/home/pma/.atom/packages/atom-lupa/node_modules/redux-thunk/lib/index.js:14:16)
    at _react2.default.createElement._react2.default.createElement.onClick (/home/pma/.atom/packages/atom-lupa/lib/components/Lupa.js:253:34)
    at Object.invokeGuardedCallback (/home/pma/.atom/packages/atom-lupa/node_modules/react/lib/ReactErrorUtils.js:26:12)
    at executeDispatch (/home/pma/.atom/packages/atom-lupa/node_modules/react/lib/EventPluginUtils.js:87:21)
    at Object.executeDispatchesInOrder (/home/pma/.atom/packages/atom-lupa/node_modules/react/lib/EventPluginUtils.js:110:5)
    at executeDispatchesAndRelease (/home/pma/.atom/packages/atom-lupa/node_modules/react/lib/EventPluginHub.js:42:22)
    at executeDispatchesAndReleaseTopLevel (/home/pma/.atom/packages/atom-lupa/node_modules/react/lib/EventPluginHub.js:53:10)
    at Array.forEach (native)
    at forEachAccumulated (/home/pma/.atom/packages/atom-lupa/node_modules/react/lib/forEachAccumulated.js:24:9)
    at Object.EventPluginHub.processEventQueue (/home/pma/.atom/packages/atom-lupa/node_modules/react/lib/EventPluginHub.js:215:7)
    at runEventQueueInBatch (/home/pma/.atom/packages/atom-lupa/node_modules/react/lib/ReactEventEmitterMixin.js:18:18)
    at Object.ReactEventEmitterMixin.handleTopLevel [as _handleTopLevel] (/home/pma/.atom/packages/atom-lupa/node_modules/react/lib/ReactEventEmitterMixin.js:29:5)
    at handleTopLevelImpl (/home/pma/.atom/packages/atom-lupa/node_modules/react/lib/ReactEventListener.js:73:24)
    at ReactDefaultBatchingStrategyTransaction.Mixin.perform (/home/pma/.atom/packages/atom-lupa/node_modules/react/lib/Transaction.js:136:20)
    at Object.ReactDefaultBatchingStrategy.batchedUpdates (/home/pma/.atom/packages/atom-lupa/node_modules/react/lib/ReactDefaultBatchingStrategy.js:63:19)
    at Object.batchedUpdates (/home/pma/.atom/packages/atom-lupa/node_modules/react/lib/ReactUpdates.js:98:20)
    at ReactEventListener.dispatchEvent (/home/pma/.atom/packages/atom-lupa/node_modules/react/lib/ReactEventListener.js:150:20)

Commands
     -0:16.3.0 pane:show-next-item (atom-text-editor.editor.is-focused)
     -0:13.6.0 pane:show-previous-item (div.panels-item)
  2x -0:11.3.0 pane:show-next-item (atom-text-editor.editor.is-focused)
 13x -0:09.3.0 atom-lupa:toggle (atom-text-editor.editor.is-focused)

Config
{
  "core": {
    "allowPendingPaneItems": false,
    "autoHideMenuBar": true,
    "disabledPackages": [
      "wrap-guide",
      "welcome",
      "language-c",
      "language-clojure",
      "language-coffee-script",
      "language-csharp",
      "language-gfm",
      "language-git",
      "language-go",
      "language-make",
      "language-objective-c",
      "language-perl",
      "language-python",
      "language-ruby",
      "language-ruby-on-rails",
      "language-todo",
      "language-toml",
      "language-yaml",
      "open-on-github",
      "metrics",
      "package-generator",
      "animated-cursor",
      "seti-icons",
      "quick-highlight",
      "live-archive",
      "fortune-background-tips",
      "background-tips",
      "activate-power-mode",
      "atom-beautify",
      "autocomplete-paths",
      "composer",
      "atom-ctags",
      "symbols-tree-view",
      "hyperclick-php"
    ],
    "ignoredNames": [
      ".git",
      ".hg",
      ".svn",
      ".DS_Store",
      "._*",
      "Thumbs.db",
      ".live-archive"
    ],
    "openEmptyEditorOnStart": false,
    "packagesWithKeymapsDisabled": [
      "multirow-tabs",
      "php-integrator-symbol-viewer",
      "atom-lupa"
    ],
    "projectHome": "/mnt"
  },
  "atom-lupa": {
    "styleguide": true
  }
}

Installed Packages
# User
atom-lupa, v0.5.46
autoclose-html, v0.23.0
autocomplete-html-entities, v0.1.0
caniuse, v0.9.0
custom-title, v1.0.1
disable-keybindings, v0.6.0
fast-eslint, v2.11.0
file-icons, v1.7.13
file-watcher, v0.4.0
foldername-tabs, v0.1.11
highlight-selected, v0.11.2
hyperclick, v0.0.36
indent-guide-improved, v1.4.8
javascript-snippets, v1.2.1
jquery-snippets, v11.0.0
js-hyperclick, v1.4.2
language-diff, v0.4.0
last-cursor-position, v0.9.0
line-diff-details, v1.3.5
linter, v1.11.4
linter-php, v1.2.0
minimap, v4.24.3
minimap-codeglance, v0.4.5
minimap-find-and-replace, v4.5.1
minimap-git-diff, v4.3.1
minimap-highlight-selected, v4.4.0
minimap-selection, v4.4.0
mixed-indent-warning, v0.3.0
open-recent, v5.0.0
php-integrator-annotations, v0.4.1
php-integrator-autocomplete-plus, v0.8.1
php-integrator-base, v0.9.3
php-integrator-navigation, v0.7.1
php-integrator-symbol-viewer, v0.6.1
pigments, v0.28.4
project-view, v0.5.0
svn, v0.0.11

# Dev
No dev packages

Do you have lupaProject.json file?
how does it look? is it correct JSON?

yep it's there.
i just copied your json.
when remove the trailing comma, the error doesn't show anymore. looks like that was the issue indeed.
can you please provide a few details on how to use that json config file ? can i configure multiple file patterns ? what are autolabels for ?
a few more things :

so, what does the big red button really do ? (suggestion: a tooltip might help)
please provide a keybind to toggle the side panel. i tend to open a lot of things simultaneously, and i toggle things a lot (treeview,minimap,symbols)
(the 'atom-lupa:toggle' only activates it)
(oh and by the way, the default ctrl-. doesn't work, i had to rebind it)

thanks for the quick answer and for an otherwise very useful and very promising package :)

Thanks! It means that there is error in my docs (trailing coma is okay in JavaScript but not in JSON).

autolabels was feature which I temporarily removed. I'll restore it later when I'll improve it.
This worked this way that you could set some "regexp detectors" in your files. And if it detected some regexps it showed in form of labels: angular, numbers.
can i configure multiple file
Try this:
"filePattern": "{spec/*,lib/**/*}"
it catches spec/* and lib/**/*
syntax is from glob:
https://github.com/isaacs/node-glob
But I will probably change it to make it more intuitive.
Maybe in future there will be something like that:
{
    "patterns": {
       "ignored": ["node_modules"],
       "project": ["src/**/*"],
       "tests": ["spec"],
    }

What do you think about proposition above? Is is more clear than one file pattern like now?
so, what does the big red button really do ? (suggestion: a tooltip might help)
It's easter egg and cultural reference to the book The Hitchhiker's Guide to the Galaxy which I was reading when I changed it to this form :) But now I restored Index project text.
please provide a keybind to toggle the side panel. i tend to open a lot of things simultaneously, and i toggle things a lot (treeview,minimap,symbols)
But you mean show/hide? Okay. I'll add some shortcut for showing/hiding. And I 'll fix activate button (now it's bound to cmd+., but this is mac keyboard only)

I've added real toggle command (which shows and hides sidepanel). I've renamed previously toggle command as more appropriate focus. (If you want to discuss it, discuss it here: https://github.com/hex13/atom-lupa/issues/20  )
I have to work on keybindings, though.

Okay. Check this now. Default keybindings should work (now Linux and Windows have Ctrl+. and Ctrl+Alt+L, and OSX has Cmd+. and Cmd+Alt+L

looking good so far (but i'm currently mostly doing php related stuff, so i'll get into it more thoroughly later)
you might want to rething the ctrl+. keybind, since it's atom's default shortcut for the key binding resolver


[Switch Plate] Cannot manufacture due to "small bridges"

Hi Sir , Please kindly note that the space between with these slots need 4mm at least as below arrow ,which will break off easily in the production , so that we will cancel it and then you will modify it and then to replace the correct one ,thanks
-- JLCPCB

Original post by r/jammer-hammer

I am considering increasing the edge thickness for the next version; but this would mean that the previous PCB / Plate files will be incompatible with this new version. (It will be possible to assemble but the edges won't match)
It might be a good idea to release a v1.1 with the new features and old edge, to maintain backward compatibility, and after that release v2.0 with the new features and new edge.

I have decided to not increase the outer edge. If JLC doesn't want to print it you can try another printing service like allpcb or pcbway or you can laser cut it from a metal sheet using the DXF file.


bump dashboards-reports version to 1.3

Description
[Describe what this change achieves]
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] New functionality includes testing.

[ ] All tests pass, including unit test, integration test and doctest

[ ] New functionality has been documented.

[ ] New functionality has javadoc added
[ ] New functionality has user manual doc added

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #265 (0a3bfe2) into main (4a93401) will increase coverage by 11.81%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##               main     #265       +/-   ##
=============================================
+ Coverage     65.29%   77.11%   +11.81%
=============================================
  Files            94       30       -64
  Lines          3922     1866     -2056
  Branches        608      374      -234
=============================================
- Hits           2561     1439     -1122
+ Misses         1220      424      -796
+ Partials        141        3      -138

Flag
Coverage Δ

dashboards-reports
77.11% <ø> (ø)

reports-scheduler
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...search/reportsscheduler/settings/PluginSettings.kt

...uler/model/ReportDefinitionDetailsSearchResults.kt

...rch/reportsscheduler/index/ReportInstancesIndex.kt

...tsscheduler/model/InContextReportCreateResponse.kt

...rtsscheduler/model/OnDemandReportCreateResponse.kt

...reportsscheduler/model/GetReportInstanceRequest.kt

...tsscheduler/model/DeleteReportDefinitionRequest.kt

...ortsscheduler/action/OnDemandReportCreateAction.kt

...heduler/model/UpdateReportInstanceStatusRequest.kt

...earch/reportsscheduler/metrics/RollingCounter.java

... and 54 more

Continue to review full report at Codecov.

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


File price not showing up properly in search results

Bug
The file price isn't showing up properly in the search results.

To Reproduce
Steps to reproduce the behavior:

Open app
Search for "music"

Expected behavior
The file price shouldn't overflow.
Screenshots

System Configuration

LBRY Daemon version:
LBRY App version:
LBRY Installation ID: 5rtRpW1S82tCGZZaTvkVrY4L52xZVpsPv8QAVTKRz63TDFzD7y1BVBycrF85GLSANW
Operating system: Windows 10

Additional context
Add any other context about the problem here.

Thanks for filing!


Fix bug where we didn't let + lists break paragraphs

We were also able to simplify the paragraph interruption checks into one function.
Fixes https://github.com/raphlinus/pulldown-cmark/issues/567.

Thanks for the quick fix! Once this PR is merged, could you issue a patch release so we could fix it in rustdoc?

Thanks for the quick review! You're absolutely right that adding + to interrupt_paragraph_by_list would've done it, but while investigating I noticed that that needn't be a separate function anymore, since it doesn't use any context from self.
@ehuss Will do a quick release after this is merged!


[4.0.0-beta.15] content resize method missing

Bug Report
Ionic:
ionic (Ionic CLI) : 4.0.6
System:
NodeJS : v8.11.3
npm    : 6.4.1
OS     : Windows 10
Describe the Bug
the resize method for ion-content is missing. i need to call this method to resize the searchbar
see https://github.com/ionic-team/ionic/issues/7706

Thanks for the issue! In Ionic 4, the ion-content layout is based on flex. This means the size of the content will automatically adjust without the need to call resize().  I'm not able to see any issues with this and removing the toolbar. Could you please provide a way for us to reproduce if you're seeing issues with this? Thanks!

hi, sure.
the problem appears only on big screens, on mobile width all looks fine
<ion-header no-border>
  <ion-toolbar class="transparent-toolbar">
    <ion-buttons slot="end">
      <ion-button *ngIf="!showSearchBar" icon-only (click)="presentSearch()">
        <ion-icon class="md-icon" name="search"></ion-icon>
      </ion-button>
    </ion-buttons>
    <ion-title *ngIf="!showSearchBar">{{title}}</ion-title>
    <ion-searchbar showCancelButton *ngIf="showSearchBar" placeholder="Suchen" (ionClear)="onSearchCancel($event)" [(ngModel)]="searchstring" (search)="search()"></ion-searchbar>
  </ion-toolbar>
</ion-header>

<ion-content fullscreen>
</ion-content>

presentSearch() {
      this.showSearchBar = true;
}
onSearchCancel() {
      this.showSearchBar = false;
      this.searchstring = '';
}
search() {

}

thanks

I think resize is not needed anymore in v4, duplicate https://github.com/ionic-team/ionic/issues/14875

@bossjon because I used to use it in v3 but don't use it anymore in v4, even in pages where I use scrollToBottom with dynamic content aka in my chat

I tried to reproduce the problem using the code above but I am not seeing any issues with content where it would need to be resized. If anyone could please provide code that I can use to reproduce this or confirm it is no longer an issue that would be great. Thank you!!
Codepen: https://codepen.io/brandyscarney/pen/GeoazQ?editors=1010


is it possible to make it so that when you click on the button to start voting, it starts immediately

is it possible to make it so that when you click on the button to start voting, it starts immediately. When I lie down on the bed and press the “start voting” button, a command with the start of voting is written to the chat, is it possible to skip it like that and after pressing the button, the voting starts immediately? Maybe you need to fix a line in the code, or something else?

Yes, this is something I have wanted to do for a while. There are two options: suggest command and run command. The former is currently set but I think we agree it should be the latter. I will make this change for the next release.

when will the next release come out?

There is no ETA. Updates will come when they are ready. I do have some API changes to make for commands so it may be soon.

I'm just launching my server soon (on the 23rd), I wanted not to let the guys down and play right away with convenience)

This should be fixed with 47461b3 and will be included in the next release.


Reviewing log data

laravel-activitylog records the id of the user making the change and the id of the user that has changed the record.  The model does not associate this with the user... ie there is no relationship in the model.
Is this the perfect excuse for using one of the new Laravel 5.5 resources?

laravel-activitylog records the id of the user making the change and the id of the user that has changed the record. The model does not associate this with the user... ie there is no relationship in the model.

I'm thinking this should work. Can you PR a failing test?


workspace creation fails after adding git provider

Describe the bug
after adding git providers , the workspace creation starts to fail and give error git clone failed
Expected behavior
Project(workspace) creation should not fails and also don't give verbose output
Screenshots

@bryans-go Thanks for the issue, please keep the "Version" and "Steps to reproduce" parts in the description when submitting these. I just tried out adding a git provider and create-ing on the latest version (v0.38.0) and it seemed to work fine.
Did you follow the breaking change handling steps? You can see them here - If you haven't, in short, you should do daytona gp rm --all and readd the git providers you want to use.

This Issue has been automatically marked as "stale" because it has not had recent activity (for 14 days). It will be closed if no further activity occurs. Thanks for the feedback.

Due to the lack of activity in the last 7 days since it was marked as "stale", we are closing this Issue. Do not hesitate to reopen it later if necessary.


Always receiving REFUSED_STREAM when sending PUSH_PROMISE

Example:
-> HEADERS(1)
- END_STREAM
+ END_HEADERS
:method: POST
:scheme: https
:authority: localhost:8443
:path: /
content-type: application/json
content-length: 58
Stream: RemainingSendFlowControlWindowIsEnough(58): 65535 > 58 = true
-> DATA(1)
+ END_STREAM
{58 bytes}
<- PUSH_PROMISE(1)
+ END_HEADERS
Promised Stream Id: 2
:authority: localhost:8443
:path: /
-> RST_STREAM(2)
Error code: REFUSED_STREAM
<- HEADERS(2)
- END_STREAM
+ END_HEADERS
:status: 400
<- DATA(2)
+ END_STREAM
{73 bytes}
Any thoughts on what's going on here?

Did you set the :method and :scheme headers in the push promise?

i set method originally, but not scheme.
will try in the morning. Do you have a ref to the part of the spec that details what needs to be set in the promise?

im using this to test an http2 implementation because In too lazy to write a client while Im writing the server.

The push promise should contain the same headers that would normally be present in a request.


Mempool initialization speed

Node takes forever to initialize with non-empty mempool (max size is 300mb. With just 2 mb it takes 10-15 minutes to launch)

@noescape00 were you on stratis or bitcoin network? Just tried with bitcoin testnet and it seemed reasonably fast (a few seconds) with this size of mempool:
MempoolSize: 1216 DynamicSize: 1187 kb OrphanSize: 100

I got those problems running on stratis testnet. I had bunch of big txes (1 input, 500 outputs), some of them were ancestor txes.
Txs type might affect the speed of AcceptTxToMempool execution big time.
Basically what we are looking for is the setup where we have the heaviest type of tx that is withing the standard tx policy. Fill 5-10% of mempool (15-30mb) and check loading speed.
I think target reasonable value for loading should be up to 5 minutes.

Ok sounds good. I'll see if I can write a quick test to reproduce then see if I can find where the bottleneck is.

Initial test - Running on Stratis Regtest POW
2000tx with 500 outputs each
=======Mempool=======
MempoolSize: 2000 DynamicSize: 68637 kb OrphanSize: 0

Took about ~3 minutes to load and get added to mempool
These are simple tx's, no ancestors outputs to all new wallets

So next will try some more complex tx's as it looks like it's not IO but more likely something to do with the tx makeup.

Looks like they are loading quite fast for you.
I wonder if something changed in the mempool that allowed them to be processed faster or it's just different tx type.
If you won't encounter issues with the ancestor txes then it's probably not an issue anymore and was optimized at some point.

Tried ancestor transactions as well and still only was a couple of minutes to load with a large tx set. I have an SSD drive so maybe that's masking it a bit, or maybe I just haven't come up with the tx set that is a problem.
I think what I will do next is add some trace logging around mempool as there is hardly any present right now so makes it tough to troubleshoot problems like these if someone runs into something.

Thanks for detailed feedback and good investigation.
Looks like it's not an issue anymore and was fixed at some point since the issue was first discovered 4-6 months ago.
Feel free to close the issue.

Closed with https://github.com/stratisproject/StratisBitcoinFullNode/pull/1915


Patching to enable building swift-apis on current nightly Swift

Currently this builds in Debug on the latest nightly toolchain on Linux. macOS is untested.
All unit tests pass except one, which is not crucial (only a floating point difference of 1e-6).
Building on Release is blocked by https://github.com/apple/swift/pull/38745#issuecomment-947890567

Seeing as this PR is stale, I'm going to comment about something the people involved with this PR ought to know about. I know this might not be the most appropriate way to reach out, but please bear with me.
I'm working on turning DL4S into a successor to Swift for TensorFlow. I'm rebuilding it from the ground up for GPU acceleration through Metal. I will also heavily modify its current API, adding fragments of S4TF (using @differentiable for custom layers and Tensor<Float> for tensors), Keras (a SwiftUI-like DSL for declaring models), and new activation functions. @ProfFan would you be willing to redirect your interest in resurrecting S4TF onto our effort at DL4S? I could invite you to our organization.
I just realized that I have an opportunity to bring DL4S to Windows with ArrayFire, which would make it closer to replacing S4TF. If it succeeds, it could be a major milestone in support for Swift on Windows. @compnerd I thought you might want to know about this. Please tell me what you think or if you know of anybody who might want to help.

Seeing as this PR is stale, I'm going to comment about something the people involved with this PR ought to know about. I know this might not be the most appropriate way to reach out, but please bear with me.

I think that this is rather an inappropriate forum for this.

I'm working on turning DL4S into a successor to Swift for TensorFlow. I'm rebuilding it from the ground up for GPU acceleration through Metal. I will also heavily modify its current API, adding fragments of S4TF (using @differentiable for custom layers, Tensor<Float> for tensors, including the Sequential function builder API) and new activation functions. @ProfFan would you be willing to redirect your interest in resurrecting S4TF onto our effort at DL4S? I could invite you to our organization.
I just realized that I have an opportunity to bring DL4S to Windows with ArrayFire, which would make it closer to replacing S4TF. If it succeeds, it could be a major milestone in support for Swift on Windows. @compnerd I thought you might want to know about this. Please tell me what you think or if you could suggest anybody who might want to help us.

The project doesn't seem particularly enticing to me - the "rebuilding from the ground up for GPU acceleration through Metal" is a big component of that.  If you were designing it for optimization for DCOM+ (DirectX is effective accessed through COM), that might be different.  GPU environments are quite fragmented and designing around a particular one is a choice that I do not particularly agree with.
This also seems very much as other platforms are an afterthought.  The overall structure of S4TF is far better from a design standpoint - it generically solves the problem in software and has abstractions over a compilation pipeline to separate the concern of optimization and device/runtime independence.
Additionally, I don't think that you realize the complexity of using ArrayFire.  That codebase has a core in C++ - which means that it is a non-starter.  Until the underlying ABI issues are resolved, C++ interop cannot be reliably used.

@compnerd this discussion has been moved into another forum.
Referencing: https://github.com/dl4s-team/dl4s-evolution/issues/8#issuecomment-981155814

I don't particularly consider this PR as stale btw, there are still items to be resolved and investigated before it can be merged.

The S4TF team archived this project in February and said they were no longer accepting pull requests to it. Merging this PR would seem to be in violation of Google’s policy. Furthermore, this PR is based on a branch called “resurrection", implying that it is an effort to un-archive S4TF.
When I made that comment, I had only skimmed through the edits and got the wrong impression that @ProfFan was trying to bring S4TF out of archive mode. I thought that because of his intention, you were never going to accept the PR. I apologize for this misunderstanding.

If Swift for TensorFlow is open for changes again, I will gladly help you out with this pull request. I have plenty of time, which is something all of you seem to greatly lack. I assume that’s why this PR has been inactive for 3 weeks. Could you outline what must be done before this pull request is approved?
@rxwei @BradLarson @compnerd I have more to say on this topic and refactored it into an issue to prevent cluttering this PR. Could you please take a look at that?

What bugs specifically are blocking this swift-apis PR? I’m trying to build this repo on Linux by redoing the build system, and I need to know exactly where autodiff will cause me trouble.

What bugs specifically are blocking this swift-apis PR? I’m trying to build this repo on Linux by redoing the build system, and I need to know exactly where autodiff will cause me trouble.

@ProfFan @compnerd @rxwei @dan-zheng @BradLarson someone please help me. Please bear with my rushed tone and run-on sentences; I have no way to continue working on S4TF because of this problem. I have tried building S4TF, but all of the solutions are failing. Bazel fails because it tries to dowload an arm64 version of Bazel 3.7.2 (only x86_64 exists). I have Bazelisk installed on my system and can't find out how to get it off. I suspect that if I could uninstall Bazelisk, I could force Bazel to download as something that works.
Then, I tried just using CMake instead of SwiftPM. According to a comment in @ProfFan's PR, I could then use SwiftPM to re-build the non-X10 stuff afterward. I'm trying to rip out X10 and build a new backend in its place, so I won't modify X10 after building. The Swift development snapshot seemed to have something wrong. I checked and made the terminal use the development snapshot (swift --version showed 5.6-dev) by putting export TOOLCHAINS=... in the .zshrc file. When it built in the terminal, it emitted errors that there was "no such module _Differentiation" and the froze indefinitely without an explanation. I checked the activity monitor, and no code compilation process was taking up anywhere close to 100% of my CPU. It seemed to stop at completely random points in the build process. Also, the Swift REPL crashed because libArgumentParser.dylib wasn't found somewhere.

At this point, I'm thinking of modifying S4TF to alternatively build on a release toolchain, using my Differentiation package. I can't do that yet because I have no way to reproduce the original build process. I also can't download the pre-built X10 binary and run it from Rosetta because I'm building from a personal fork with this PR's commits merged into it. @ProfFan modified something in the X10 directory(ies), and the existing binaries don't have these changes. If you have an Apple silicon Mac, could you send me the arm64 binaries you built in a package structured similarly to the pre-built x64 macOS X10 binaries?

@philipturner - Regarding blocking compiler crashers, one was recently fixed, but two still remain (the 12/23/2021 nightly shapshot is the first toolchain to include the linked fix). The two remaining crashers are both due to failing assertions around debug symbols, one that triggers around mutating functions and control flow, and the other due to an optimization pass behaving oddly during release builds. The former can be worked around by moving control flow out of any mutating function that triggers the assertion failure (BatchNorm was one place we hit that here), and the latter can be avoided by disabling the generation of debug symbols when building for release. Both can be prevented if you build a non-assertion-enabled toolchain.
Fixing these has been slow going, because I've had a hard time creating a concrete reproducer for the first (I do have SIL dumps, which points to a possible cause, but I need a failing test to verify a fix), and the latter only occurs under very specific optimization conditions. I do know the exact commit and lines that introduced the latter failure, but not the root cause.
By "release toolchain", do you mean the ones integrated with Xcode, or the swift.org release toolchains? In either case, the 5.5 branch does not have some necessary autodiff fixes in it that have been put in place over the last year (the branching for that was a while ago), and I know that there was another compiler crasher that directly blocked tensorflow/swift-apis from building which has been fixed in main and is present in the nightly toolchain builds. I don't think switching to a release toolchain (Xcode or swift.org) will help you much in trying to build the project.
If you're getting errors of "no such module _Differentiation", that sounds like the build process is still trying to use the default Swift Xcode toolchain and not one from Swift.org, so you could try to manually place the path to the correct toolchain in your PATH ahead of the Xcode toolchain in order to force the use of the right toolchain.
Regarding building TensorFlow, getting Bazel set up can be a bit of a pain, and building TensorFlow from source can take as long as building the entire Swift toolchain. If you're trying to build this on an M1, I'm not sure that all even works with the version of TensorFlow you'd need to build to connect to the old Swift for TensorFlow interfaces (2.4.0 if I'm reading things right). I think you'll have to build that on X86_64. You may also need to match up the exact version of Bazel that had been used to build TensorFlow (somewhere between 3.7.2 and 3.99.0, but it sounds like you've got the correct 3.7.2).

@BradLarson I'm continuing this conversation in the "requesting assistance" issue to prevent cluttering this PR.

start with x86 rather than jump to m1!

I have a few hours tomorrow morning where I can access my Intel Mac mini. Hopefully, I can bridge from the Swift dev toolchain to release within that timeframe, then proceed on Colab (also x86) for the rest of the day.
Sent from my iPhone

On Jan 3, 2022, at 10:33 PM, brett koonce @.***> wrote:

start with x86 rather than jump to m1!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.

@philipturner wrt to https://github.com/tensorflow/swift-apis/issues/1185#issuecomment-1004776357 + going off of what brad was saying, you should make sure you have the same cmake version as well!

@ProfFan (or @compnerd or @BradLarson if you reproduced his steps in October) could you let me know which Swift nightly snapshot was used while building this fix? I'm having trouble reproducing your results on Linux. I attached the Colab notebook where I'm facing issues right now. It's untidy, but hopefully you can use it to reproduce my conditions (please run on Google Colab and read the comments).
CompilingSwift2.ipynb.zip
If you'd rather not run it, I downloaded CMake 3.22.1, Bazel 3.1.0, and took the CMake route to compiling with a pre-compiled Ubuntu x64 binary. I pulled source code from ProfFan's fan/resurrection fork. I got CMake to start compiling the x10 library at runtime, but it was so slow that I expected it to take hours (a bad idea, especially in Colab).
I'm facing problems with it freezing after logging the command below. I faced a similar silent freezing error when attempting to build S4TF on my Mac mini (with a different cause), and I later found that the program had actually stopped and would log the error if was run slightly different. I can't figure out how to reveal that error in the Colab environment though.
[18/30] Linking Swift static library lib/libTensorTests.a

On the Swift releases website, it doesn't show snapshots earlier than November. Yet, these patches were made in October. I just need the date of the snapshot used, and the snapshot from then might still be downloadable. This is all to narrow down the cause of the error and reproduce the exact same environment that @ProfFan somehow successfully built S4TF in.

@ProfFan there was a compiler failure while compiling swift-apis using SwiftPM on the 2021-11-12 nightly and using a pre-compiled Ubuntu x10 binary:
Building for debugging...
/content/swift-apis/Sources/TensorFlow/Core/DataTypes.swift:89:61: error: cannot find type 'ElementaryFunctions' in scope
  TensorFlowScalar & BinaryFloatingPoint & Differentiable & ElementaryFunctions

The full stack trace and conditions for how to reproduce are in this Colab notebook:
CompilingSwift2 (1).ipynb.zip

I got S4TF to build successfully once in a Colab environment, although I used a pre-compiled x10.

@ProfFan there was a build failure on the 2021-12-23 snapshot that didn't occur on the 2021-11-12 snapshot. I have yet to test 2022-01-06, but this should be worth investigating to add commits to your PR. The crash log is in one of the later cells of this notebook:
CompilingSwift2 (3).ipynb.zip

If I'm reading these notebook results correctly, it looks like the 12/23/2021 nightly snapshot toolchain got a lot farther in building than the 11/12/2021 one. I vaguely remember being able to use the 2021-07-07 nightly (downloadable from here for X86 Ubuntu 18.04) to build this branch before, but I could be wrong about that. That was a good, stable snapshot for autodiff for a while.
Looking at the failure on the 12/23/2021 toolchain, it appears that the RequirementMachine is unable to solve out the TangentVector for RecurrentLayer (type defined at swift-apis/Sources/TensorFlow/Layers/Recurrent.swift, lines 370 - 469). If that could be minimized, it'd be great to report upstream for Richard and / or Slava to look at. If this persists with the just-released 1/6/2022 toolchain, let me know and I can minimize and report that.
As a workaround, you might be able to define a custom TangentVector for RecurrentLayer that explicitly states what the compiler is currently generating for that TangentVector and that might help the solver here.

2021/11/12 actually completed the build. I had some problems but resolved them. I didn’t try it on 2021-07-07.

@BradLarson could you give more precise details on how to implement the workaround? I anticipate that my lack of experience with differentiation will unnecessarily waste time if I tackle to problem alone. Plus, it takes 2 minutes to reach the build failure, unlike Xcode where you can cache build products (I might fix that by moving to my Mac mini if this gets serious enough).

@BradLarson could you give super precise details on how to implement the workaround?

I haven't verified that this will compile, but you'll want to add something like the following before line 376 in Recurrent.swift:
public struct TangentVector: Differentiable, AdditiveArithmetic {
  public typealias TangentVector = RecurrentLayer.TangentVector
  public var cell: Cell.TangentVector

  public init(cell: Cell.TangentVector) {
    self.cell = cell
  }
}

mutating func move(by offset: TangentVector) {
  self.cell.move(by: offset.cell)
}

That should provide what you need to satisfy a manual TangentVector for the RecurrentLayer type. Again, not entirely sure that'll compile, but something close to that is what you'd need.

Thanks! That’s what I was asking for! And any progress/insights on the bug with VJP pow derivative? (I assigned to you on JIRA)
Sent from my iPhone

On Jan 7, 2022, at 9:18 PM, Brad Larson @.***> wrote:

@BradLarson could you give super precise details on how to implement the workaround?
I haven't verified that this will compile, but you'll want to add something like the following before line 376 in Recurrent.swift:
public struct TangentVector: Differentiable, AdditiveArithmetic {
public typealias TangentVector = RecurrentLayer.TangentVector
public var cell: Cell.TangentVector
public init(cell: Cell.TangentVector) {
self.cell = cell
}
}
mutating func move(by offset: TangentVector) {
self.cell.move(by: offset.cell)
}
That should provide what you need to satisfy a manual TangentVector for the RecurrentLayer type. Again, not entirely sure that'll compile, but something close to that is what you'd need.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.

@BradLarson the crash still occurs (2022-01-06), even with your workaround. It says this in the crash log:
5.	While generating protocol witness thunk SIL function "@AD__$s10TensorFlow14RecurrentLayerVyxGAA0D0A2aEP14callAsFunctiony6OutputQz5InputQzFTW_jvp_SS".
 for 'callAsFunction(_:)' (at /content/swift-apis/Sources/TensorFlow/Layers/Recurrent.swift:464:10)

Colab notebook:
CompilingSwift2 (5).ipynb.zip
I noticed that it says jvp at the end of the mangled name, which shouldn't exist anymore. @rxwei made requests on JIRA for someone to remove JVP protocol witnesses:

https://bugs.swift.org/browse/SR-15577

@ProfFan I can't get my comment on your code above to load when I'm not logged in to my personal account. It says "Pending" in a label just like many code snippets say "Outdated". Can you see the comment?
The comment was to this: https://github.com/tensorflow/swift-apis/pull/1184#discussion_r734912234

@ProfFan did you get a notification for the PR I left on your fork? GitHub might do something weird with notifications if it isn't on the main repository.

@ProfFan do any of your current projects depend on S4TF? If so, wouldn't your work be impacted by the new crash that appeared in 2021-12-23?

No I am not doing any S4TF in my current work

@ProfFan how to do you prefer to be contacted for discussions not relevant to this PR?

I have no bandwidth for this now. Maybe I will have time after 2 months.


Copy certificates into a folder

Hi,
This might be a basic question, but I couldn't find the answer online..
What I would like, is after creating the IIS-project and the SSL-certificate, I would like to copy the .crt and the .key into a relative folder.
So, when running the ps-script, I would like to create an SSL-folder in my project with the .crt and the .key.
Is this doable?

I think you are looking to create a .pfx file. I assume you want to export the certificate into a file and then apply it to another machine? If my assumption is correct then sure creating a pfx shouldn't be too complicated.

Haven't had a response so I am closing this issue. Thanks for using the script!


Freeze & Thaw the JSON

So it's all well and good that we can template JSON, but what about when that JSON includes functions? If we had the following config for example
var config = {
	baseUrl: 'http://foo',
	items: [
		{
			url: '%baseUrl%/users',
			build: function () { }
		},
		{
			url: '%baseUrl%/dogs',
			build: function () { }
		}
	]
}

And we try to resolve it with itself, we lose those anonymous functions because we're calling JSON.stringify.
I was wondering whether we should support Freezing/Thawing the JSON by default, and merging the results... For example...
var freeze = original
// resolve the original JSON
var thaw = merge(original, freeze);

return thaw

Thoughts?

Only if that merge doesn't mutate the original, but yeah, willing to say that losing the functions is a bug

what @subsidel said

Except that JSON cannot include functions, what you are talking about is templating javascript.
http://www.json.org/

Actually, that's a good point

Sure, I'm on about templating JavaScript. I have a use case for it which is why I'm raising this as an enhancement.
JavaScript == JSON == config

I am mostly arguing about semantics, which is that you shouldn't be calling this JSON because it isn't.
I think there are 2 different questions:
1: What do you want this library to do? In this case adding this functionality may make sense
2: Should I use javascript to configure my app? IMO probably not. I personally don't agree that Javascript == JSON == config but thats your decision.


README: Align Provider manifest to docs

Description of your changes
The image suggested in the README lacks a host where to fetch it.
According to
https://marketplace.upbound.io/providers/crossplane-contrib/provider-openstack/v0.2.0, the package image is under xpkg.upbound.io.
Fixes #49
I have:

[ ] Read and followed Crossplane's contribution process.
[ ] Run make reviewable test to ensure this PR is ready for review.

How has this code been tested
Locally, following the README.

WRT the DCO sign-off: https://github.com/crossplane-contrib/provider-openstack/issues/51


Finding Reporter id always equal to 1 when finding created in API

Slack us first!
I did and was told to report a bug on slack
Be informative
I am using: v. 2.10.0 ( release mode )
I am creating products, engagements and findings through the API.
Bug description
When creating a finding I would like the reporter to correspond to the id of the pentester in defectdojo so I tried in 2 ways:
First while using the API with admin APIKEY I created a finding and sent  a reporter field with the id of the pentester (3). The reporter id for the finding ends up being 1 (admin) anyhow.
Second  while using the API with the pentester APIKEY I created a finding. The reporter id for the finding is 1 when the pentester id is 3.
Steps to reproduce
One can use the  /api/v2/oa3/swagger-ui/#/findings/findings_create to reproduce
One need a product and an engagement to create the finding
Expected behavior
I would like the "reporter" field value to be taken into account.
Deployment method (select with an X)

[ ] Docker Compose

Environment information

DefectDojo version v. 2.10.0 ( release mode )

Merged for release 2.12


Log formatter: add BATS summary line

BATS emits a summary line (number of tests passed/failed)...
but only on a tty or when run with --pretty! In our CI
context, with TAP output, it gives no end summary.
Fix that. Keep track of 'ok', 'not ok', and 'skipped',
and display the counts at the end.
Also: add a regression test. You don't need to review
or even read it: it's stark, and I'm not even enabling
it for CI because it almost certainly won't run due to
missing Perl library modules. It's just something I
need on my end.
Signed-off-by: Ed Santiago<EMAIL_ADDRESS>

@baude with no CI running I can't offer you an example of what it looks like, sorry. It'll be something like:
Summary:  2 Passed, 1 Failed, 1 Skipped. Total tests: 4

LGTM

/approve
/lgtm


Atomic store updates

Changes to entity data in Store should be done atomically. If the graph node panics or is shut down while processing a block, the entity data in the database should not be left in an inconsistent state. Similarly, while a block is being processed, queries should not see partially update entity data.
An architecture change was proposed for #292 that should resolve this issue as well.

Linked to #390.


Latest focus trap changes causes the modal response to be lost

The recent change to how the focus trap is set up (PR #549) is causing issues when you expect the close action to return a value.
Specifically this change in the modal component on lines 103-105:
https://github.com/simplabs/ember-promise-modals/pull/549/files#diff-f1bdcfc6adc126290ecb2862332b13bf329fcd5a397b3ab6210de2911dc65d54L93-R105
Not passing in null here as it did before changes the behaviour in such a way that the focus trap's onDeactivate function calls closeModal again (without return value this time) and resolves the modal before the original @close action call has a chance to resolve with the return value that was passed in.
So currently, this happens:

A link in your modal calls @close
Internally the modal then calls closeModal(result) with the result passed to @close
This then runs focusTrap.deactivate() which immediately runs the onDeactivate function
closeModal() is called again, but without the passed in result this time.
The modal resolves with the undefined result before closeModal(result) from step 2 has a chance to resolve with its data.

Reverting lines 103-105 linked above makes it work properly again, though that probably breaks something else that the PR fixed?
Another workaround might be to set onDeactivate to null through the open() call or globally on the modals service, but that feels like it shouldn't be necessary.

Thanks for reporting this. For some reason we were missing a test that verifies this.
Resolved by #596


Incorrect error handling in the AuthenticationClient.WebServerAsync

To reproduce:
tokenRequestEndpointUrl = "https://login.salesforce.com/services/oauth2/authorizeee"; // typo in the url
await auth.WebServerAsync(consumerKey, consumerSecret, callbackUrl, authCode, tokenRequestEndpointUrl);

Inside WebServerAsync method the HTTP request returns html error page and therefore can't be deserialized into AuthErrorResponse type in the following code:
    public async Task WebServerAsync(string clientId, string clientSecret, string redirectUri, string code, string tokenRequestEndpointUrl)
    {
            ...
            AuthErrorResponse errorResponse = JsonConvert.DeserializeObject<AuthErrorResponse>(response);
            ...
    }

Okay. Finally got around to this one too. =)
https://github.com/developerforce/Force.com-Toolkit-for-NET/pull/205
/cc @dcarroll

Merged.


MP Formulas Test Automation v1.0

Context
Create one script that complete the following actions for MP Formulas: Create, Edit, Evaluate, Revert to Offical Record

Test Complete


Replace package satori/go.uuid

This issue has been opened automaticaly because we think you are using satori/uuid in your code. Unfortunately, satori/uuid has a critical defect where it doesn't generate random UUIDV4s satori/go.uuid#73 and should be replaced as the maintainer has been unresponsive for 5 months with the bug still open. Alternative packages you should consider: https://github.com/google/uuid https://github.com/pborman/uuid

Thanks for the heads up! I'll take a look at the alternatives.


hello,I have a question;

when I run follow readme , but my terminal always told me that I have not update my local map, my goal and so on. How can I solve this problem?  thank you !

Hello, please show me rqt_graph when warning appears.

Hello, please show me rqt_graph when warning appears.

hello!
terminal displays:
[ WARN] [1621909565.623581573]: Local goal has not been updated
[ WARN] [1621909565.623596566]: Odom has not been updated
[ WARN] [1621909565.623602937]: Local map has not been updated
[ WARN] [1621909566.623915967]: Local goal has not been updated
[ WARN] [1621909566.623961883]: Odom has not been updated
[ WARN] [1621909566.624012520]: Local map has not been updated
[ WARN] [1621909567.624217945]: Local goal has not been updated
[ WARN] [1621909567.624317311]: Odom has not been updated
[ WARN] [1621909567.624416536]: Local map has not been updated
[ WARN] [1621909568.673904253]: Local goal has not been updated
[ WARN] [1621909568.673958281]: Odom has not been updated
...

Thank you !
I think some topics published by your node is not subscribed in /local_planner/dwa_planner node.
Please check topic name between published and subscribed is match.
You can use rqt_graph to see if the topic is connected correctly.


Remove version: Jackett.Jackett version 0.21.631

404 - release deleted
Microsoft Reviewers: Open in CodeFlow

URL: https://github.com/Jackett/Jackett/releases/download/v0.21.631/Jackett.Installer.Windows.exe
Response Error: The remote server returned an error: (404) Not Found.
(Automated message - build 918)


Missing Option: Restore Solution Explorer project hierarchy state on solution load

This sounds useless to provide as an option. What does it do and why would anyone not want to load a solution properly when they open it?

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

ID: 28461613-82d6-e8f7-7f12-da24a594775d
Version Independent ID: d7758211-e43d-9fca-4ca2-52be17a7cd63
Content: Projects and Solutions, Options dialog box - Visual Studio
Content Source: docs/ide/reference/projects-and-solutions-options-dialog-box.md
Product: visual-studio-windows
Technology: vs-ide-general
GitHub Login: @gewarren
Microsoft Alias: gewarren

Referring to this new option:


Compilation terminated.
CMake Error at nheqminer_cuda_tromp_generated_equi_miner.cu.o.cmake:264 (message):
Error generating file
/home/rbminer/nheqminer/Linux_cmake/nheqminer_cuda_tromp/CMakeFiles/nheqminer_cuda_tromp.dir///cuda_tromp/./nheqminer_cuda_tromp_generated_equi_miner.cu.o
make[2]: *** [CMakeFiles/nheqminer_cuda_tromp.dir///cuda_tromp/./nheqminer_cuda_tromp_generated_equi_miner.cu.o] Error 1
make[1]: *** [CMakeFiles/nheqminer_cuda_tromp.dir/all] Error 2
make: *** [all] Error 2

Running into the same thing

Adding -std=c++11 to CMakeList.txt allowed me to compile it
On line 24:
set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};--disable-warnings;--ptxas-options=-v;-use_fast_math;-lineinfo;-std=c++11)

Adding -std=c++1 worked for me. Thanks !

Issue related to older version.
Closing...

very cool

list(APPEND CUDA_NVCC_FLAGS "std=c++11") added to CMakeLists.txt     solved my same error...


Update dependencies

Continuation of #247
#265, update to Solid 1.8.0 and make everything work with latest SolidStart (v0.4.0 Beta 2) with SSR.
Should be ~ 4 hours.

I'm good with you proceeding on this update!

It's ok for me too.


customize bottom menu position

i want the bottom menu on the top of the viewcontroller how can i do that?

@starsPanda Do you mean the Library/Photo/Video menu being displayed at the top?
There is no way to do that through the library as is but you can fork it and replace YPBottomPagerView.swift by
final class YPBottomPagerView: UIView {

    var header = YPPagerMenu()
    var scrollView = UIScrollView()

    convenience init() {
        self.init(frame: .zero)
        backgroundColor = UIColor(red: 239/255, green: 238/255, blue: 237/255, alpha: 1)

        sv(
            scrollView,
            header
        )

        layout(
            0,
            |header| ~ 44,
            0,
            |scrollView|,
            0
        )

        header.heightConstraint?.constant = YPConfig.hidesBottomBar ? 0 : 44

        clipsToBounds = false
        setupScrollView()
    }

    private func setupScrollView() {
        scrollView.clipsToBounds = false
        scrollView.isPagingEnabled = true
        scrollView.showsHorizontalScrollIndicator = false
        scrollView.scrollsToTop = false
        scrollView.bounces = false
    }
}

Closing this for lack of activity, Fee free to reopen if needed :)


Stylesheet and script not loaded because of MIME-type

Bug report

What is the current behavior?
When I deployed the local code to the line, the online environment crashed directly.
"Refused to apply style from 'xxxx' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.".
My local wepback version is 4.31.0， on the line is 4.35.0.
The local is running normally, but the line is broken.
If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?
I hope to fix this problem as soon as possible

Other relevant information:
webpack version:
Node.js version:
Operating System:
Additional tools:

I also have this problem. How did you solve it?


Install issue on mac

As the extension appears hardcoded to python (mine is python3) on mac I created a venv with aider-chat and flask in. I can move to that dir and aider runs fine from the terminal.
In the extension I have pointed it to the bin folder in that venv which has python in but the extension reports from the following uncaught error: aider-chat service exited with code 2 and signal null

In the aider composer output at vscode you can find the start comamnd. And you can use it in your terminal to have a try.
Since I don't have mac so I may not debug this locally.


Organizations create_account() should create an IAM role in the new "account"

Hello! Long time, first time. Thanks for the library -- it's hugely useful. I have a (hopefully) small enhancement request.
In AWS Organizations, calling the organizations:CreateAccount API results in an IAM role named OrganizationAccountAccessRole being created in the new account. The name of the role can be customized using the RoleName parameter (boto3 Organizations.Client.create_account() docs).
I would like to propose mirroring that behavior in moto. I could probably sort out how to implement this, but first I wanted to open an issue to see if it's philosophically in line with moto; I don't know if there's any precedent for cross-service interaction like this.
Here are a couple of tests that illustrate the desired behavior:
import os

import boto3
from moto import mock_aws

@mock_aws
def test_create_account_creates_role():
    orgs_client = boto3.client('organizations', region_name='us-west-2')
    _ = orgs_client.create_organization()
    account = orgs_client.create_account(
        AccountName='test_account',
<EMAIL_ADDRESS>    )
    account_id = account['CreateAccountStatus']['AccountId']

    os.environ['MOTO_ACCOUNT_ID'] = account_id
    iam_client = boto3.client('iam')
    org_role = iam_client.get_role(RoleName='OrganizationAccountAccessRole')
    assert org_role

@mock_aws
def test_create_account_creates_custom_role():
    orgs_client = boto3.client('organizations', region_name='us-west-2')
    _ = orgs_client.create_organization()
    account = orgs_client.create_account(
        AccountName='test_account',
<EMAIL_ADDRESS>        RoleName='CustomOrganizationRole',
    )
    account_id = account['CreateAccountStatus']['AccountId']

    os.environ['MOTO_ACCOUNT_ID'] = account_id
    iam_client = boto3.client('iam')
    org_role = iam_client.get_role(RoleName='CustomOrganizationRole')
    assert org_role

Both tests result in an exception on the get_role() calls: botocore.errorfactory.NoSuchEntityException: An error occurred (NoSuchEntity) when calling the GetRole operation: Role CustomOrganizationRole not found

Hi @patricksanders! That is definitely possible - we have cross-service interactions like this in quite a few places already. I've submitted a PR with the required changes. :+1:

Awesome! Thank you, @bblommers. Lightning fast turnaround ⚡