fork_database assertion failed

My witness stopped keeping up approximately 72 hours ago on testnet.  Due to #298 I do not have a full log, but it keeps spamming the following on the console:
3170975ms th_a       fork_database.cpp:57          push_block           ] Pushing block to fork database that failed to link.
3170978ms th_a       application.cpp:378           handle_block         ] Error when pushing block:
10 assert_exception: Assert Exception
second_branch_itr != _index.get<block_id>().end():
    {}
    th_a  fork_database.cpp:194 fetch_branch_from

    {"first":"0000e5b7915bd40faf619c8033500917be4a46f8","second":"0000e5a96341c967ec805a68124c6bed86e7429d"}
    th_a  fork_database.cpp:225 fetch_branch_from

    {"new_block":{"previous":"0000e67c9b3db252dddeb2d2ed3a11ec4541156f","timestamp":"2015-09-04T15:22:35","witness":"1.6.58","transaction_merkle_root":"560643c64b7d2e4c74363881ca52cdf8322652b3","extensions":[],"witness_signature":"204de1
8483f82577ac5edf89c6e6cafca318b3519483566ceba511da777b1bdc890eb554d57be51217dceb54b36c58fec8594fd05a897f808821b71b039ed479f5","transactions":[{"ref_block_num":58980,"ref_block_prefix":1947506295,"expiration":"2015-09-04T15:23:53","operat
ions":[[0,{"fee":{"amount":2000000,"asset_id":"1.3.0"},"from":"1.2.17263","to":"1.2.63354","amount":{"amount":100000,"asset_id":"1.3.0"},"extensions":[]}]],"extensions":[],"signatures":["206e82cb78d47f0b2144e96d24d8628bcd96c6e758fdb7eb5f
fe0a794761b06ad0732f6d12a3322dd48e2e00feadff1cfcd632061d655353611a47ae5384c93b48"],"operation_results":[[0,{}]]},{"ref_block_num":59002,"ref_block_prefix":1906513399,"expiration":"2015-09-04T15:22:45","operations":[[5,{"fee":{"amount":17
089,"asset_id":"1.3.0"},"registrar":"1.2.72728","referrer":"1.2.72728","referrer_percent":0,"name":"spam-0-i5xnur9ipwyojemi.spartako","owner":{"weight_threshold":1,"account_auths":[],"key_auths":[["GPH7obX9JBanjQJ3n6AcAQ2ob5YhuDWYnmqGaLc
bzzddx41hPnynN",1]],"address_auths":[]},"active":{"weight_threshold":1,"account_auths":[],"key_auths":[["GPH7QU7FhYKq9SCWEigtgxbMBCUhLEnWHq4r8PKewCAobQqQvcPJV",1]],"address_auths":[]},"options":{"memo_key":"GPH547nbgJnaJ9FFAtUx3bBokUV4Cd
bPd4gVbMWLuvihUtyVxeZDn","voting_account":"1.2.5","num_witness":0,"num_committee":0,"votes":[],"extensions":[]},"extensions":[]}]],"extensions":[],"signatures":["1f5131c3ee8bdfc75dc4f461243e6e48ec4450cb6aa09db731f1a3e200653460b36c2eb8925
65fa8e8f48c2f205823a1463a0e03ac8f983099d18e0600128e4c9b"],"operation_results":[[1,"1.2.95199"]]},{"ref_block_num":59002,"ref_block_prefix":1906513399,"expiration":"2015-09-04T15:22:45","operations":[[0,{"fee":{"amount":2089843,"asset_id"
:"1.3.0"},"from":"1.2.7015","to":"1.2.69491","amount":{"amount":1,"asset_id":"1.3.0"},"memo":{"from":"GPH5MdK4afYd8gAogtwYjuRWAHfSpsCYutfBvZ6y2AeZHLAtcYpY6","to":"GPH7gU4pHJ9rTUfVA6q6dEgCxgMGVLmq1YM3HRAKpj1VnTzJhrAn2","nonce":"9152755822
956654368","message":"dc88d4655bc8b44133e2c469c39846ba"},"extensions":[]}]],"extensions":[],"signatures":["2039f60de38827746d12464b79cd358c1b71b938d63c13831f68a5525a56f3e35b6e6bd6acfbec0fb61d0bbca6db06634fed4f010c32622831c2612e05b25198d9
"],"operation_results":[[0,{}]]},{"ref_block_num":58980,"ref_block_prefix":1947506295,"expiration":"2015-09-04T15:23:57","operations":[[0,{"fee":{"amount":2000000,"asset_id":"1.3.0"},"from":"1.2.17263","to":"1.2.63354","amount":{"amount"
:100000,"asset_id":"1.3.0"},"extensions":[]}]],"extensions":[],"signatures":["20614cbaf9cf923de37731389bd45d37d44ecd6916896bc26be0a7064396d280cb433114900ef6e12914df42c60b893331eeb2c5d43374359f8c6a532f1f422632"],"operation_results":[[0,{}
]]},{"ref_block_num":59002,"ref_block_prefix":1906513399,"expiration":"2015-09-04T15:22:45","operations":[[0,{"fee":{"amount":2089843,"asset_id":"1.3.0"},"from":"1.2.7015","to":"1.2.69491","amount":{"amount":1,"asset_id":"1.3.0"},"memo":
{"from":"GPH5MdK4afYd8gAogtwYjuRWAHfSpsCYutfBvZ6y2AeZHLAtcYpY6","to":"GPH7gU4pHJ9rTUfVA6q6dEgCxgMGVLmq1YM3HRAKpj1VnTzJhrAn2","nonce":"18304070265773539153","message":"56b74f10e37b8601a33572d4c47b7ef9"},"extensions":[]}]],"extensions":[],
"signatures":["1f0ed95f34f0b2bd76d82ec0239a8ae1e23fdd8ccd8ad8df76dadf24a28c4f60243919fc5be0e5e7986a3f38df63c118c809df43083b49abb8ab46d71e22878b8b"],"operation_results":[[0,{}]]},{"ref_block_num":59002,"ref_block_prefix":1906513399,"expir
ation":"2015-09-04T15:22:45","operations":[[0,{"fee":{"amount":2089843,"asset_id":"1.3.0"},"from":"1.2.7015","to":"1.2.69491","amount":{"amount":1,"asset_id":"1.3.0"},"memo":{"from":"GPH5MdK4afYd8gAogtwYjuRWAHfSpsCYutfBvZ6y2AeZHLAtcYpY6"
,"to":"GPH7gU4pHJ9rTUfVA6q6dEgCxgMGVLmq1YM3HRAKpj1VnTzJhrAn2","nonce":"3316090705884741618","message":"712f4efcc1d66c5ffdbe9e97e341cff8"},"extensions":[]}]],"extensions":[],"signatures":["205bebba42884c4647adf9873872e62edef289c3ab76a33b3
e5ce2017b2967720c35ef1223fb8b8cdede4d60ca1c4a5ba2df1e9a2b628fc28868f7beb16ffa971c"],"operation_results":[[0,{}]]},{"ref_block_num":58980,"ref_block_prefix":1947506295,"expiration":"2015-09-04T15:23:54","operations":[[0,{"fee":{"amount":2
000000,"asset_id":"1.3.0"},"from":"1.2.17263","to":"1.2.63354","amount":{"amount":100000,"asset_id":"1.3.0"},"extensions":[]}]],"extensions":[],"signatures":["1f7ded61cb961c412385532806c223b9f03e134a73123264d9ce584f751affd2143308c18e3bf1
5a69cf42c7a6012c7a2d17b4d7159deaaf5c81f4057b0bb59b00"],"operation_results":[[0,{}]]},{"ref_block_num":58980,"ref_block_prefix":1947506295,"expiration":"2015-09-04T15:23:55","operations":[[0,{"fee":{"amount":2000000,"asset_id":"1.3.0"},"f
rom":"1.2.17263","to":"1.2.63354","amount":{"amount":100000,"asset_id":"1.3.0"},"extensions":[]}]],"extensions":[],"signatures":["1f5e06abd38d78020eed077e4413c6fde7b8e33e305a338b51b3a816b2b8d771513c9e9b344407f7bbf0dcf00059909f0550f54d5be
0b671d454cabf37946771cf"],"operation_results":[[0,{}]]},{"ref_block_num":59000,"ref_block_prefix":2001541183,"expiration":"2015-09-04T15:22:52","operations":[[0,{"fee":{"amount":2000000,"asset_id":"1.3.0"},"from":"1.2.17263","to":"1.2.63
354","amount":{"amount":100000,"asset_id":"1.3.0"},"extensions":[]}]],"extensions":[],"signatures":["1f6913dd4a4964236af1335bba210a965ab0bf014bc2527ab164f0d1440c1f8a22240906a577a02a53a360eca0b4c7ce571626bbead4848b330f85c32b02da6ecd"],"op
eration_results":[[0,{}]]},{"ref_block_num":59002,"ref_block_prefix":1906513399,"expiration":"2015-09-04T15:22:45","operations":[[0,{"fee":{"amount":2089843,"asset_id":"1.3.0"},"from":"1.2.7015","to":"1.2.69491","amount":{"amount":1,"ass
et_id":"1.3.0"},"memo":{"from":"GPH5MdK4afYd8gAogtwYjuRWAHfSpsCYutfBvZ6y2AeZHLAtcYpY6","to":"GPH7gU4pHJ9rTUfVA6q6dEgCxgMGVLmq1YM3HRAKpj1VnTzJhrAn2","nonce":"13187981089080909634","message":"aab5fa0786f94d50a465a4e6831105cd"},"extensions"
:[]}]],"extensions":[],"signatures":["20317cec97273d04821c7eed4b4772469056f00d995522956f064ee461aa177648341ff8cb4d0227d4dc625212ee05619d7e3aed5996cf8f1cfa14b09dcc6ad1ad"],"operation_results":[[0,{}]]},{"ref_block_num":58980,"ref_block_pr
efix":1947506295,"expiration":"2015-09-04T15:24:02","operations":[[0,{"fee":{"amount":2000000,"asset_id":"1.3.0"},"from":"1.2.17263","to":"1.2.63354","amount":{"amount":100000,"asset_id":"1.3.0"},"extensions":[]}]],"extensions":[],"signa
tures":["1f35d579c46a19bc7a6214de18de60d7f639250c3195653946079830c91dd7ca7f0f41441e6ea29055d6ce6e9029ec0ec1b264e61a266f18cd4767b0e93df9e6fb"],"operation_results":[[0,{}]]},{"ref_block_num":58980,"ref_block_prefix":1947506295,"expiration"
:"2015-09-04T15:24:07","operations":[[0,{"fee":{"amount":2000000,"asset_id":"1.3.0"},"from":"1.2.17263","to":"1.2.63354","amount":{"amount":100000,"asset_id":"1.3.0"},"extensions":[]}]],"extensions":[],"signatures":["1f465cf86f9d9b4e1d65
8ed4d7700ebd8c87146f333720485d38535a061529f3990555362472c60936e12e65d3d9d3a713d8f8345b7151da5497e7b7ef7f5a6ad8"],"operation_results":[[0,{}]]},{"ref_block_num":59002,"ref_block_prefix":1906513399,"expiration":"2015-09-04T15:22:45","opera
tions":[[5,{"fee":{"amount":17089,"asset_id":"1.3.0"},"registrar":"1.2.72728","referrer":"1.2.72728","referrer_percent":0,"name":"spam-3-81qj36bn0ch7u8fr.spartako","owner":{"weight_threshold":1,"account_auths":[],"key_auths":[["GPH7obX9J
BanjQJ3n6AcAQ2ob5YhuDWYnmqGaLcbzzddx41hPnynN",1]],"address_auths":[]},"active":{"weight_threshold":1,"account_auths":[],"key_auths":[["GPH7QU7FhYKq9SCWEigtgxbMBCUhLEnWHq4r8PKewCAobQqQvcPJV",1]],"address_auths":[]},"options":{"memo_key":"
GPH547nbgJnaJ9FFAtUx3bBokUV4CdbPd4gVbMWLuvihUtyVxeZDn","voting_account":"1.2.5","num_witness":0,"num_committee":0,"votes":[],"extensions":[]},"extensions":[]}]],"extensions":[],"signatures":["2019a280d34bb50f1d7b2a107128b58ac1b866720c883
f77e6b0983a270a9228b16d9439acb2eb430bdb1a71d83ff9cc142e8c47fe24cbb570bc3d6c648befff76"],"operation_results":[[1,"1.2.95200"]]},{"ref_block_num":59002,"ref_block_prefix":1906513399,"expiration":"2015-09-04T15:22:45","operations":[[0,{"fee
":{"amount":2089843,"asset_id":"1.3.0"},"from":"1.2.7015","to":"1.2.69491","amount":{"amount":1,"asset_id":"1.3.0"},"memo":{"from":"GPH5MdK4afYd8gAogtwYjuRWAHfSpsCYutfBvZ6y2AeZHLAtcYpY6","to":"GPH7gU4pHJ9rTUfVA6q6dEgCxgMGVLmq1YM3HRAKpj1V
nTzJhrAn2","nonce":"17151148761166979233","message":"24e64245840426ea83043d648d2ece0c"},"extensions":[]}]],"extensions":[],"signatures":["1f37e56dcb9256537177147e0f570e1c3c94506da4951d33a0c5c546c80fa232fd15e3955f8d2b3d9b18824efbb19a8ecd8
09dda1b0a6f23cc98d89a6ef96c4778"],"operation_results":[[0,{}]]},{"ref_block_num":58980,"ref_block_prefix":1947506295,"expiration":"2015-09-04T15:24:03","operations":[[0,{"fee":{"amount":2000000,"asset_id":"1.3.0"},"from":"1.2.17263","to"
:"1.2.63354","amount":{"amount":100000,"asset_id":"1.3.0"},"extensions":[]}]],"extensions":[],"signatures":["1f7263a3c17b6727e1bd0b7e931e527d9ff587974dea267fde9492025ecb0b628b5049d6a532be5e43c4dc6204d4d141d639f3bd7898635638ad30b6ba40ec22
70"],"operation_results":[[0,{}]]},{"ref_block_num":59003,"ref_block_prefix":1399766633,"expiration":"2015-09-04T15:23:23","operations":[[0,{"fee":{"amount":2000000,"asset_id":"1.3.0"},"from":"1.2.17263","to":"1.2.63354","amount":{"amoun
t":100000,"asset_id":"1.3.0"},"extensions":[]}]],"extensions":[],"signatures":["1f674d8c4205e1f29391e3ff9a37617b7bb7f904e70af19d57eb68d025bbae8a4f126fcc8d8c99b072d1ca194aee640388d65989799aeda941a524d3496db913fb"],"operation_results":[[0,
{}]]},{"ref_block_num":58980,"ref_block_prefix":1947506295,"expiration":"2015-09-04T15:24:01","operations":[[0,{"fee":{"amount":2000000,"asset_id":"1.3.0"},"from":"1.2.17263","to":"1.2.63354","amount":{"amount":100000,"asset_id":"1.3.0"}
,"extensions":[]}]],"extensions":[],"signatures":["1f2975b15ae20ce41b8b42f6f880521b38ac1d41ff2fafe390e8f4ad1bab0a4be11128bd92c012bc22383f44a459677b7cf0a15e3700c2a7e29db106720a5b01e6"],"operation_results":[[0,{}]]},{"ref_block_num":58980,
"ref_block_prefix":1947506295,"expiration":"2015-09-04T15:24:04","operations":[[0,{"fee":{"amount":2000000,"asset_id":"1.3.0"},"from":"1.2.17263","to":"1.2.63354","amount":{"amount":100000,"asset_id":"1.3.0"},"extensions":[]}]],"extensio
ns":[],"signatures":["20487f49f778b120956af95e93f70668e101f00263a7faa8d9a7945778f706905c56df82899992a102bb5011fe320ebe9377115db702a61e392500b8676448f99b"],"operation_results":[[0,{}]]},{"ref_block_num":59002,"ref_block_prefix":1906513399
,"expiration":"2015-09-04T15:22:45","operations":[[0,{"fee":{"amount":2089843,"asset_id":"1.3.0"},"from":"1.2.7015","to":"1.2.69491","amount":{"amount":1,"asset_id":"1.3.0"},"memo":{"from":"GPH5MdK4afYd8gAogtwYjuRWAHfSpsCYutfBvZ6y2AeZHLA
tcYpY6","to":"GPH7gU4pHJ9rTUfVA6q6dEgCxgMGVLmq1YM3HRAKpj1VnTzJhrAn2","nonce":"6270452061439905553","message":"c6f3f6fc4d591a9b9e554dfc242a1bd0"},"extensions":[]}]],"extensions":[],"signatures":["1f10fab0ff0ce1d1985fbcdb0005b0799e209c2c7a
25f9e3b94c533499c107dc8a3f1af549d3bae74a6c0275e19ca369f981fbe00caf1c3cf8d89712063852970c"],"operation_results":[[0,{}]]},{"ref_block_num":59002,"ref_block_prefix":1906513399,"expiration":"2015-09-04T15:22:45","operations":[[5,{"fee":{"am
ount":17089,"asset_id":"1.3.0"},"registrar":"1.2.72728","referrer":"1.2.72728","referrer_percent":0,"name":"spam-2-81qj36bn0ch7u8fr.spartako","owner":{"weight_threshold":1,"account_auths":[],"key_auths":[["GPH7obX9JBanjQJ3n6AcAQ2ob5YhuDW
YnmqGaLcbzzddx41hPnynN",1]],"address_auths":[]},"active":{"weight_threshold":1,"account_auths":[],"key_auths":[["GPH7QU7FhYKq9SCWEigtgxbMBCUhLEnWHq4r8PKewCAobQqQvcPJV",1]],"address_auths":[]},"options":{"memo_key":"GPH547nbgJnaJ9FFAtUx3b
BokUV4CdbPd4gVbMWLuvihUtyVxeZDn","voting_account":"1.2.5","num_witness":0,"num_committee":0,"votes":[],"extensions":[]},"extensions":[]}]],"extensions":[],"signatures":["1f4a5afea5e8bfe5fdb8713e7f7a16928baa4f0e92edc2752c365bdcb9e6fcab7b1
79bd6a894f68eea56f7b69b9ca58ab196e2c2eba3abf388ba8ac1ca4751211a"],"operation_results":[[1,"1.2.95201"]]},{"ref_block_num":59002,"ref_block_prefix":1906513399,"expiration":"2015-09-04T15:22:45","operations":[[0,{"fee":{"amount":2089843,"a
sset_id":"1.3.0"},"from":"1.2.7015","to":"1.2.69491","amount":{"amount":1,"asset_id":"1.3.0"},"memo":{"from":"GPH5MdK4afYd8gAogtwYjuRWAHfSpsCYutfBvZ6y2AeZHLAtcYpY6","to":"GPH7gU4pHJ9rTUfVA6q6dEgCxgMGVLmq1YM3HRAKpj1VnTzJhrAn2","nonce":"18
015839889622198754","message":"0f4691adb44408b427a7ecd760fa37c8"},"extensions":[]}]],"extensions":[],"signatures":["1f3aa9bc4d0f3e066962a1a894184a9e2fc4f085aafee936e749230b820b05ea401465d1d47c091ad37e865fcfdcc89e7b34c7d8c65a14da07bfabc67
308f3c0e3"],"operation_results":[[0,{}]]},{"ref_block_num":59003,"ref_block_prefix":1399766633,"expiration":"2015-09-04T15:23:24","operations":[[0,{"fee":{"amount":2000000,"asset_id":"1.3.0"},"from":"1.2.17263","to":"1.2.63354","amount":
{"amount":100000,"asset_id":"1.3.0"},"extensions":[]}]],"extensions":[],"signatures":["201d1c3f091214b162a1ca5ebd6d6632bf2fe1227a4c0d33e480b95a79a37be46213dcb29c047d85588bb6a268804af2ac5a489fdfda8563abc71f5c1ae8d8b8b1"],"operation_result
s":[[0,{}]]},{"ref_block_num":59002,"ref_block_prefix":1906513399,"expiration":"2015-09-04T15:22:45","operations":[[5,{"fee":{"amount":17089,"asset_id":"1.3.0"},"registrar":"1.2.72728","referrer":"1.2.72728","referrer_percent":0,"name":"
spam-1-81qj36bn0ch7u8fr.spartako","owner":{"weight_threshold":1,"account_auths":[],"key_auths":[["GPH7obX9JBanjQJ3n6AcAQ2ob5YhuDWYnmqGaLcbzzddx41hPnynN",1]],"address_auths":[]},"active":{"weight_threshold":1,"account_auths":[],"key_auths
":[["GPH7QU7FhYKq9SCWEigtgxbMBCUhLEnWHq4r8PKewCAobQqQvcPJV",1]],"address_auths":[]},"options":{"memo_key":"GPH547nbgJnaJ9FFAtUx3bBokUV4CdbPd4gVbMWLuvihUtyVxeZDn","voting_account":"1.2.5","num_witness":0,"num_committee":0,"votes":[],"exte
nsions":[]},"extensions":[]}]],"extensions":[],"signatures":["2048c4530d9e75700a1da5e71ec475da6ad24b71e8dac4669f02835ea39709c86b4d47f23c6b8c57cb40dd1e2158f097cffc45f0348ab78244718155f3b2027357"],"operation_results":[[1,"1.2.95202"]]},{"r
ef_block_num":59003,"ref_block_prefix":1399766633,"expiration":"2015-09-04T15:22:50","operations":[[0,{"fee":{"amount":2089843,"asset_id":"1.3.0"},"from":"1.2.7015","to":"1.2.69491","amount":{"amount":1,"asset_id":"1.3.0"},"memo":{"from"
:"GPH5MdK4afYd8gAogtwYjuRWAHfSpsCYutfBvZ6y2AeZHLAtcYpY6","to":"GPH7gU4pHJ9rTUfVA6q6dEgCxgMGVLmq1YM3HRAKpj1VnTzJhrAn2","nonce":"9080698228922187301","message":"a66b69512b1980158603ee8be299f473"},"extensions":[]}]],"extensions":[],"signatu
res":["205229758c3bf0dde037287a69826128c37b6ae6d71694aa8d1e78f5b2e92411a64acb952e99a988626d40557e07323066549967c5c8e1e2a8f45b527bd34ceb2f"],"operation_results":[[0,{}]]},{"ref_block_num":59002,"ref_block_prefix":1906513399,"expiration":"
2015-09-04T15:22:45","operations":[[0,{"fee":{"amount":2089843,"asset_id":"1.3.0"},"from":"1.2.7015","to":"1.2.69491","amount":{"amount":1,"asset_id":"1.3.0"},"memo":{"from":"GPH5MdK4afYd8gAogtwYjuRWAHfSpsCYutfBvZ6y2AeZHLAtcYpY6","to":"G
PH7gU4pHJ9rTUfVA6q6dEgCxgMGVLmq1YM3HRAKpj1VnTzJhrAn2","nonce":"1802881231088084990","message":"cd33a21791a8a7a3f2bdd2fc63cf4aa2"},"extensions":[]}]],"extensions":[],"signatures":["2032b9fc15856aed8ae937ecbc62a92be06104fde3010808d0a8665ab
14b8f9c506569919fc89fcbbd25512fd80612c7c919b308e2227bc980fc1f74569861ff49"],"operation_results":[[0,{}]]}]}}
    th_a  db_block.cpp:176 _push_block

When I attempt to produce a block I get a similar message:
3303000ms th_a       witness.cpp:179               block_production_loo ] Not producing block because it isn't my turn
3303000ms th_a       witness.cpp:146               schedule_production_ ] now.time_since_epoch().count():<PHONE_NUMBER>996722 next_second: 2015-09-07T15:55:04
3304000ms th_a       witness.cpp:179               block_production_loo ] Not producing block because it isn't my turn
3304000ms th_a       witness.cpp:146               schedule_production_ ] now.time_since_epoch().count():<PHONE_NUMBER>996674 next_second: 2015-09-07T15:55:05
3305000ms th_a       fork_database.cpp:57          push_block           ] Pushing block to fork database that failed to link.
3305001ms th_a       db_block.cpp:292              _generate_block      ] Reason for block production failure: {"code":10,"name":"assert_exception","message":"Assert Exception","stack":[{"context":{"level":"error","file":"fork_database.cpp","line":194,"method":"fetch_branch_from","hostname":"","thread_name":"th_a","timestamp":"2015-09-07T15:55:05"},"format":"second_branch_itr != _index.get<block_id>().end(): ","data":{}},{"context":{"level":"warn","file":"fork_database.cpp","line":225,"method":"fetch_branch_from","hostname":"","thread_name":"th_a","timestamp":"2015-09-07T15:55:05"},"format":"","data":{"first":"0000e5b7915bd40faf619c8033500917be4a46f8","second":"0000e5a96341c967ec805a68124c6bed86e7429d"}},{"context":{"level":"warn","file":"db_block.cpp","line":176,"method":"_push_block","hostname":"","thread_name":"th_a","timestamp":"2015-09-07T15:55:05"},"format":"","data":{"new_block":{"previous":"0000e5a96341c967ec805a68124c6bed86e7429d","timestamp":"2015-09-07T15:55:05","witness":"1.6.1","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"205be9a6d1e50cbc59ab300dc71a1cf3558eb063f6f12c2d0b460cb6895640081669b8194ae46c301d6b26d6059394a256d36dabdfaab46ea66d3087c44be9c980","transactions":[]}}}]}
3305002ms th_a       witness.cpp:166               block_production_loo ] Got exception while generating block:
10 assert_exception: Assert Exception
second_branch_itr != _index.get<block_id>().end():
    {}
    th_a  fork_database.cpp:194 fetch_branch_from

    {"first":"0000e5b7915bd40faf619c8033500917be4a46f8","second":"0000e5a96341c967ec805a68124c6bed86e7429d"}
    th_a  fork_database.cpp:225 fetch_branch_from

    {"new_block":{"previous":"0000e5a96341c967ec805a68124c6bed86e7429d","timestamp":"2015-09-07T15:55:05","witness":"1.6.1","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"205be9a6d1e50cbc59ab300dc71a1cf3558eb063f6f12c2d0b460cb6895640081669b8194ae46c301d6b26d6059394a256d36dabdfaab46ea66d3087c44be9c980","transactions":[]}}
    th_a  db_block.cpp:176 _push_block

    {"witness_id":"1.6.1"}
    th_a  db_block.cpp:325 _generate_block

I think I know what's causing this.  Writing a unit test to confirm.

Duplicate of #264

I think what happened is the transaction expired in the cache.  The re-pushing of transactions in the cache in update_pending_block() is not guarded by its own try-catch, meaning the failure to apply any transaction in the local pool looks like a failure building the block to the outer code, which makes it unable to push any block that would cause the transaction to expire.
The code assumes that a transaction which makes it into the cache will always be valid, but this is not true because transactions can expire or become invalidated by chain state, for example if we have:

A: Alice receives 100 CORE
B: Alice spends 100 CORE
C: Alice spends 100 CORE

If you have A and B in your cache, it is fine -- but if you then receive a block containing A and C, the B in your cache will become invalid.  (This example demonstrates that even a blockchain without expiration would need to handle invalidation.)

See also #297

What was happening is two bugs relating to pending tx handling:

Pending tx's weren't being undone before switching forks
Re-applying the pending tx's after switching forks treated a failure of a pending tx as if the block was invalid

As a result, the node could get into a state where it would reject any block it received as invalid, due to invalid pending transactions in the node's cache.
The fix is to save and restore pending transactions around the call to _push_transaction.

I presume you me around the call to _push_block?


Support rebase/squash merges

Currently the action does not support rebase (and squash) merges.
Specifically, this action was build to deal with octopus merges. It does this by looking at the common ancestor of the head and base refs. But after a rebase the branch no longer points to the same head ref, which then ends up not being fetched by the action on checkout.
We should implement an alternative strategy to find all commits merged by the pull request.

An idea is to use List commits on a pull request, but the documentation is unclear about which commits will be listed. It might mean the original commits before the rebase or the commits after the rebase. Additionally, this requires dealing with pagination (max 100, default 30 per page) and has a maximum limit of requesting 250 commits.

It would be great if it reported back that this is not supported currently.

As far as I could find, it is currently not possible to know how the pull request was merged (merge commit, rebase or squash).
What I could do is add a check to see whether the commits are available to the action and if not comment on the pull request with something like:
Unable to backport this pull request automatically.
Please cherry-pick the commit(s) manually.
It seems that one or more of the commits are not available to the backport-action.
Note that rebase and squash merges are not supported at this time.
For more information see https://github.com/zeebe-io/backport-action/issues/46.

Does that help?

That's great!

@domenkozar I've merged a PR that performs this check and comments if 1 of the references cannot be found. Please let me know if you run into any problems with it.

Thank you :)

It doesn't seem to work: https://github.com/NixOS/nixpkgs/pull/143639#issuecomment-955071800


BPMSPL-156: Process dashboard refactor

The older process dashboard iframe (based on the external dashbuilder webapp) has been entirely replaced by an Uberfire native perspective built on top of the UF dashbuilder module. The new process dashboard feeds from two non-public (hidden to end users) data sets (see taskMonitoring & processMonitoring data set registration in DashbuilderBootstrap).
This new process dashboard also includes the following feature:
https://issues.jboss.org/browse/BPMSPL-17
... which allows the user to list the related instances shown in the dashboard as well as the ability to open a details screen for every process or task instance selected.

merged in master


Failed to build TensorRT plugin

Firstly, thank you for sharing your code.
To build your tensorrt plugin, I tried cmake .. -DTENSORRT_PREFIX_PATH='/PCDet/tools/tensorrt_utils/TensorRT-<IP_ADDRESS> && make'. However, I got the following errors and failed to build.
To solve this, I have tried two things:

pip install tensorrt=<IP_ADDRESS> as mentioned in the previous issue.
set(CUDA_ARCHITECTURES 75)

Could you provide any comments to help solve this problem?
Errors
/tensorrt_utils/tensorrt_scatter/include/common/atomics.cuh(167): error: more than one conversion
function from "__half" to a built-in type applies:
            function "__half::operator float() const"
/usr/local/cuda/bin/../targets/x86_64-linux/include/cuda_fp16.hpp(204): here
            function "__half::operator short() const"
/usr/local/cuda/bin/../targets/x86_64-linux/include/cuda_fp16.hpp(222): here
            function "__half::operator unsigned short() const"
/usr/local/cuda/bin/../targets/x86_64-linux/include/cuda_fp16.hpp(225): here
            function "__half::operator int() const"
/usr/local/cuda/bin/../targets/x86_64-linux/include/cuda_fp16.hpp(228): here
            function "__half::operator unsigned int() const"
/usr/local/cuda/bin/../targets/x86_64-linux/include/cuda_fp16.hpp(231): here
            function "__half::operator long long() const"
/usr/local/cuda/bin/../targets/x86_64-linux/include/cuda_fp16.hpp(234): here
            function "__half::operator unsigned long long() const"
/usr/local/cuda/bin/../targets/x86_64-linux/include/cuda_fp16.hpp(237): here
            function "__half::operator __nv_bool() const"
/usr/local/cuda/bin/../targets/x86_64-linux/include/cuda_fp16.hpp(241): here

/tensorrt_utils/tensorrt_scatter/include/common/atomics.cuh(167): error: no instance of overloaded
 function "atomicCAS" matches the argument list
            argument types are: (unsigned short *, unsigned short, <error-type>)

/tensorrt_utils/tensorrt_scatter/include/common/atomics.cuh(167): error: identifier "__ushort_as_b
float16" is undefined

/tensorrt_utils/tensorrt_scatter/include/common/atomics.cuh(167): error: identifier "__bfloat16_as
_ushort" is undefined

/tensorrt_utils/tensorrt_scatter/include/common/atomics.cuh(167): error: no instance of overloaded
 function "atomicCAS" matches the argument list
            argument types are: (unsigned short *, unsigned short, <error-type>)

/tensorrt_utils/tensorrt_scatter/include/common/utils.cuh(38): error: no operator "/=" matches these operands
            operand types are: half /= const half
          detected during:
            instantiation of "void div_kernel(scalar_t *, int32_t, const scalar_t *, __nv_bool) [with scalar_t=half]"

Environment

gpu: RTX2080
torch: '1.12.1+cu116'
cuda11.6
TensorRT: <IP_ADDRESS>

nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2022 NVIDIA Corporation
Built on Tue_Mar__8_18:18:20_PST_2022
Cuda compilation tools, release 11.6, V11.6.124
Build cuda_11.6.r11.6/compiler.31057947_0

It appears that fp16/bp16 and include.h are working properly on CUDA_ARCH 800. Therefore, we will close the issue.


Help text and target created time fixes

Unhealthy health check help text fixed.

Hey @pantsel I added a fix for targets displaying current time, and snyk is happy again for some reason.

Cheers man!


Fix: Vote option on proposal

show the alert as already voted if hasVoted
else show the button for casting vote in case of active sate proposal

https://github.com/omgnetwork/optimism/issues/424

Codecov Report

Merging #429 (2b43568) into develop (cecb468) will increase coverage by 9.95%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop     #429      +/-   ##
===========================================
+ Coverage    76.09%   86.05%   +9.95%
===========================================
  Files           81       49      -32
  Lines         3037     1936    -1101
  Branches       469      307     -162
===========================================
- Hits          2311     1666     -645
+ Misses         726      270     -456

Flag
Coverage Δ

batch-submitter
?

contracts
86.05% <ø> (ø)

core-utils
?

data-transport-layer
?

message-relayer
?

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

Impacted Files
Coverage Δ

...ackages/batch-submitter/src/utils/tx-submission.ts

packages/core-utils/src/common/index.ts

...itter/src/batch-submitter/state-batch-submitter.ts

.../l1-ingestion/handlers/sequencer-batch-appended.ts

packages/core-utils/src/l2context.ts

packages/core-utils/src/watcher.ts

...kages/data-transport-layer/src/utils/validation.ts

packages/message-relayer/hardhat.config.ts

...ckages/data-transport-layer/src/utils/constants.ts

...kages/batch-submitter/src/batch-submitter/index.ts

... and 22 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 cecb468...2b43568. Read the comment docs.


proptypes error

We should use ViewPropTypes.style instead of View.propTypes.style.
https://github.com/facebook/react-native/issues/16542

lol we cant use the component because of that!

Still not working
12 Sep 2018 to 18 Feb 2019

Still not working
12 Sep 2018 to 18 Feb 2019

Well, for now, if you want, you can fork this repo to yourself and resolve the problem using the pr #5 or simply use my fork that is already resolved.


NIFI-11556: Added ability to use a Process Group as a Stateless Flow

Summary
NIFI-00000
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[ ] Apache NiFi Jira issue created

Pull Request Tracking

[ ] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[ ] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[ ] Pull Request based on current revision of the main branch
[ ] Pull Request refers to a feature branch with one commit containing changes

Verification
Please indicate the verification steps performed prior to pull request creation.
Build

[ ] Build completed using mvn clean install -P contrib-check

[ ] JDK 11
[ ] JDK 17

Licensing

[ ] New dependencies are compatible with the Apache License 2.0 according to the License Policy
[ ] New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

[ ] Documentation formatting appears as expected in rendered files

Rebased to main in order to address conflicts and squashed commits in order to make that rebase easier. Thanks for the feedback @exceptionfactory

Force pushed to rebase against main, due to conflicts.

On root group created a process group and selected stateless engine.
In that stateless group created a GenerateFlowFile -> UpdateAttribute flow with a batch size of 500 and 1KB non unique text objects.  Realized I cannot start/stop individual components and instead must do so at the group level based on error responses.  Ideally we would prevent those buttons from being used at all as otherwise we're doing a user experience based on 'try and fail' which is often not fun.  Ideally we improve that now or in time.
When I started the group I realized I had the wrong scheduling period set as the default is 1min so a single flowfile went through.  I changed to '0 secs' and tried again.  Nothing happened and I noticed that scheduling period was returned to '1 min' suggesting my changes aren't taking effect.

OK pushed some changes @joewitt . Will now automatically show/hide the "Max  Concurrent Tasks" and "Stateless Flow Timeout" settings based on the chosen Execution Engine. Also addressed wording of the error messages.

Had a scenario I figured would cause problems.  Nope.  It works perfectly
Cannot change Execution Engine for StandardProcessGroup[identifier=888d6dd0-0189-1000-e88e-b0a720bf53e6,name=Stateless Group] while components are running. UpdateAttribute[id=888d916e-0189-1000-749a-0d0497e2b6e2] is currently running.
Running a typical GenerateFF->UpdateAttr flow in both standard and stateless.  Seeing performance being double the speed in standard vs stateless which I think surprises me.  Stateless has 5 concurrent threads whereas standard has 1 task for generate and update.  It seems like standard runs both generate and update at once whereas stateless runs one then the other and never more than one.  So that makes sense speed is double in standard case.
Other note: We should deprecate in 1.x line the ExecuteStateless processor.  This will be superior in every way to that.

The above info was with run duration set above zero.  With run duration at 0 on all things the behavior seems to possibly flip with standard being slower due to backlogs on connection hitting 10K slowing it down.

I had a flow running in a PG that is traditional and a PG that is stateless.  After restart the stateless PG did not automatically restart.

With provenance in Volatile mode now I see stateless flow running with all 5 threads.  I think my laptop will melt

Ok again it did not restart the stateless group.
So build a stateless flow in nifi.  Have it running.  Restart NiFi.  Then it all comes back up running.  Restart nifi again without doing anything else and the stateless flow will come up not running.  Traditional flows do run though.
Repeated that pattern twice. and it happened twice.

I see this in the logs once I tell nifi to restart.
2023-07-24 12:48:52,219 ERROR [Run Dataflow Stateless Group] o.a.n.s.flow.StandardStatelessFlow Failed to execute dataflow java.lang.RuntimeException: Dataflow canceled         at org.apache.nifi.stateless.engine.StandardExecutionProgress.enqueueTriggerResult(StandardExecutionProgress.java:178)         at org.apache.nifi.stateless.flow.StandardStatelessFlow.executeDataflow(StandardStatelessFlow.java:571)         at org.apache.nifi.stateless.flow.StandardStatelessFlow.lambda$trigger$5(StandardStatelessFlow.java:511)         at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)         at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)         at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)         at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)         at java.base/java.lang.Thread.run(Thread.java:833)

nifi appears stuck runnig the integration tests/system tests in nifi-system-tests with mvn clean install -Pintegration-tests
It isn't moving and stack dump shows
"main" #1 prio=5 os_prio=31 cpu=1795.56ms elapsed=2750.21s tid=0x000000011a008a00 nid=0x2203 in Object.wait()  [0x0000000170083000]    java.lang.Thread.State: WAITING (on object monitor)         at<EMAIL_ADDRESS>Method)         - waiting on <0x0000000700a00058> (a java.lang.Thread)         at java.lang.Thread.join(java.base@17.0.8/Thread.java:1304)         - locked <0x0000000700a00058> (a java.lang.Thread)         at java.lang.Thread.join(java.base@17.0.8/Thread.java:1372)         at org.apache.nifi.tests.system.AggregateNiFiInstance.start(AggregateNiFiInstance.java:49)         at org.apache.nifi.tests.system.NiFiInstanceCache$CachedNiFiInstance.start(NiFiInstanceCache.java:189)         at org.apache.nifi.tests.system.NiFiInstance.start(NiFiInstance.java:32)         at org.apache.nifi.tests.system.NiFiSystemIT.setup(NiFiSystemIT.java:121)         at<EMAIL_ADDRESS>Method)         at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@17.0.8/NativeMethodAccessorImpl.java:77)         at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@17.0.8/DelegatingMethodAccessorImpl.java:43)         at java.lang.reflect.Method.invoke(java.base@17.0.8/Method.java:568)         at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)         at org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)         at org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)         at org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)

Thanks @joewitt . I haven't been able to replicate an issue with the system test freezing, but based on the thread dump it looks like the nifi instance failed to startup. Perhaps due to a port conflict or something of that nature?
I did track down the issue with the Stateless Group not starting up when NiFi is restarted, though. I pushed a fix for that. Great catch!

I am just beginning to review this and it will take some time because it is a significant change. A couple comments off the bat.
Can you add "help" dialogs for the new properties for the configuration of a process group - specifically Execution Engine, Max Concurrent Tasks, Stateless Flow Timeout? See the Log File Suffix property for an example.
Can you add some information in the PR description to assist in evaluating this one? It is non-trivial to say the least and not having any description of what was added/modified, why, or what areas to focus on makes reviewing even more challenging.
Thanks!

The latest version has a clean shutdown with the Controller Service reference scenario described, thanks @markap14!
I pushed a correction for the unused import, otherwise this looks ready to go pending successful builds.

Thanks for taking a look @markobean. As you noted, there is a lot here, but it builds on the core capabilities of Stateless execution. If you are not familiar with Stateless operation, or the ExecuteStateless Processor, it would be worth reviewing the associated documentation for those features.
It is worth giving some consideration to how approachable this capability is for general users, so improving usability is worth doing. However, some of those items could be considered under a follow-on effort. One of the main concerns with this pull request is to ensure existing functionality works, and the new optional functionality operates within reasonable parameters.


Clicking and dragging meshes

Hi Marco,
I was wondering if there was a way to enable the panning of meshes (click and drag) withing a Plotter.
 Is there a way to make it so that this is what happens, without having to press 'a' and then also hold shift?
Ideally, I would like to have a button that acts as a switch between style 1 (default) to style 2 (left click and drag results in panning of meshes)

Hi @DanKrsi
yes - it's in interactor_modes submodule
check out the example in:
https://github.com/marcomusy/vedo/blob/master/examples/basic/interaction_modes1.py

Hi Marco,
Thanks for this, but I am looking to pan (translate) the individual meshes, not looking to pan the camera.
In the same way that you do when you press 'a', then hold shift + click drag.
Thanks

You can start with that interactor with eg:
show(meshes, axes=1, mode="TrackballActor")


Code simplification

Simplifies code in the unified library and the pointers utility to better match FFI convention of handling pointers, specifically arrays of structs.
Replace the potentially error-prone loader script in utils.rb with direct references to the limited set of files provided.

Will merge once testing is performed, as I presently am not somewhere that has the necessary drivers.


Add Open Trials press release to news page today

Need some help posting this ASAP today.
https://docs.google.com/document/d/1CMNewnWfyf2bOWRqDZHfmpfYRm9GLRnmGo0MWvYVgEc/edit
Also, cc: @saradbowman please add to social media stream after it is up.

This was done.


explain difference between handle_call and handle_info. Explain why y…

I explained the difference between handle_call and handle_info in the mailbox exercise. I also tackled the question of when to use which.

Love the addition.


ONNX IMPORTER: enable protobuf build via cmake if it's version > 3.0

Merged in order to unblock merge of DLDT MR.


Use current year and author from package as defaults

Interesting. I've been meaning to look into reading the license data off the package.json as well.

More than interesting? Worth a release? :tada:

Yeah, published as 1.0.0. Sorry for the delay.


Features/graphs and misc

Pull Request Test Coverage Report for Build 50

45 of 45 (100.0%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 48:
0.0%

Covered Lines:
640

Relevant Lines:
640

💛  - Coveralls


Add create-vite templates for Solid.js

Description
As a developer using vite I wish to have an option to easily getting started with projects using the React-alternative Solid.js
Suggested solution
We could add sub commands allowing users to create solid.js projects based on vite for both javascript and typescript
Alternative
No response
Additional context
I would happily take over this enhancement if it is approved.
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

This is a duplicate of #5572.
We are trying to keep create-vite as minimal as possible to avoid maintenance issues in core.
FYI there is already an template for solid: https://github.com/solidjs/templates


Open inpage host in a new browser tab

Not sure that will be trivial to implement, but this will be very useful because we'll use subscriber UI, that separated from base page, without rempl-server

Maybe something like:
const newOrExisitingWindow = window.open('', publisherName, '').focus();
injectSubscriberUI(newOrExisitingWindow);


[WIP]add the selector text used when selector does not match element (closes #2568)

@testcafe-build-bot retest

I've accidentally closed it and force pushed. Now cannot reopen it, so create the separate one


Question on spark-submit failing via the operator

What does this actually mean and how can I troubleshoot this?
For context, I am using the latest release of the operator, and I use a custom base image for spark (which is based on the bitnami spark image).
There is no /home/spark folder by default in that image.
Warning  SparkApplicationFailed  14m   spark-application-controller  SparkApplication brazil-pan-ecs failed: failed to run spark-submit: failed to run spark-submit: Ivy Default Cache set to: /home/spark/.ivy2/cache
The jars for the packages stored in: /home/spark/.ivy2/jars
org.apache.spark#spark-streaming-kafka-0-10_2.12 added as a dependency
org.apache.spark#spark-sql-kafka-0-10_2.12 added as a dependency
:: resolving dependencies :: org.apache.spark#spark-submit-parent-511288aa-ce7c-4a38-9c8e-4869b71c68fa;1.0
  confs: [default]
Exception in thread "main" java.io.FileNotFoundException: /home/spark/.ivy2/cache/resolved-org.apache.spark-spark-submit-parent-511288aa-ce7c-4a38-9c8e-4869b71c68fa-1.0.xml (No such file or directory)
           at java.base/java.io.FileOutputStream.open0(Native Method)
           at java.base/java.io.FileOutputStream.open(Unknown Source)
           at java.base/java.io.FileOutputStream.<init>(Unknown Source)
           at java.base/java.io.FileOutputStream.<init>(Unknown Source)
           at org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorWriter.write(XmlModuleDescriptorWriter.java:71)
           at org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorWriter.write(XmlModuleDescriptorWriter.java:63)
           at org.apache.ivy.core.module.descriptor.DefaultModuleDescriptor.toIvyFile(DefaultModuleDescriptor.java:553)
           at org.apache.ivy.core.cache.DefaultResolutionCacheManager.saveResolvedModuleDescriptor(DefaultResolutionCacheManager.java:184)
           at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:259)
           at org.apache.ivy.Ivy.resolve(Ivy.java:522)
           at org.apache.spark.deploy.SparkSubmitUtils$.resolveMavenCoordinates(SparkSubmit.scala:1580)
           at org.apache.spark.util.DependencyUtils$.resolveMavenDependencies(DependencyUtils.scala:185)
           at org.apache.spark.deploy.SparkSubmit.prepareSubmitEnvironment(SparkSubmit.scala:334)
           at org.apache.spark.deploy.SparkSubmit.org$apache$spark$deploy$SparkSubmit$$runMain(SparkSubmit.scala:964)
           at org.apache.spark.deploy.SparkSubmit.doRunMain$1(SparkSubmit.scala:194)
           at org.apache.spark.deploy.SparkSubmit.submit(SparkSubmit.scala:217)
           at org.apache.spark.deploy.SparkSubmit.doSubmit(SparkSubmit.scala:91)
           at org.apache.spark.deploy.SparkSubmit$$anon$2.doSubmit(SparkSubmit.scala:1120)
           at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:1129)
           at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala)
  Warning  SparkApplicationPendingRerun  44s (x2 over 50s)  spark-application-controller  SparkApplication brazil-pan-ecs is pending rerun

What's odd is if I manually do a docker run with:
spark-submit --name test-pan-ecs --packages org.apache.spark:spark-streaming-kafka-0-10_2.12:3.5.0,org.apache.spark:spark-sql-kafka-0-10_2.12:3.5.0 --conf spark.jars.ivy=/opt/bitnami/spark/.ivy2 /opt/bitnami/spark/universal_parser.py

the container starts up normally.

got the same error with spark-operator 2.0.1, it works with 2.0.0

@missedone thanks for the tip! I will test this out on my end.

How did you get around this? I have specified
  sparkConf:
    spark.jars.ivy: /opt/bitnami/spark/.ivy2
    spark.driver.extraJavaOptions: -Divy.cache.dir=/opt/bitnami/spark/.ivy2 -Divy.home=/opt/bitnami/spark/.ivy2

in my SparkApplication YAML file but you can see from the pod logs that the ivy default cache location goes to /tmp/.ivy/cache and completely ignores my configuration.
I have confirmed that spark.configuration is correctly mounted inside the pod from a configmap created by the operator and has the correct values in it. Do I actually have to modify ivysettings.xml in my base image?
:: loading settings :: url = jar:file:/opt/bitnami/spark/jars/ivy-2.5.1.jar!/org/apache/ivy/core/settings/ivysettings.xml
Ivy Default Cache set to: /tmp/.ivy/cache
The jars for the packages stored in: /tmp/.ivy/jars
org.apache.spark#spark-streaming-kafka-0-10_2.12 added as a dependency
org.apache.spark#spark-sql-kafka-0-10_2.12 added as a dependency
:: resolving dependencies :: org.apache.spark#spark-submit-parent-f1a326af-fa2f-47c6-b83c-cf6efcf5ad2d;1.0
        confs: [default]
        found org.apache.spark#spark-streaming-kafka-0-10_2.12;3.5.1 in central
        found org.apache.spark#spark-token-provider-kafka-0-10_2.12;3.5.1 in central
        found org.apache.kafka#kafka-clients;3.4.1 in central
        found org.lz4#lz4-java;1.8.0 in central
        found org.xerial.snappy#snappy-java;<IP_ADDRESS> in central
        found org.slf4j#slf4j-api;2.0.7 in central
        found org.apache.hadoop#hadoop-client-runtime;3.3.4 in central

I ended up modifying my Dockerfile to build my own image with --conf spark.jars.ivy=/tmp/.ivy

got the same error with spark-operator 2.0.1, while it works with 2.0.0.
and seems it not base image specific issue, as we changed from bitnami spark image to the official spark image, the same error.
we have to rollback to 2.0.0 to unblock the team.

Yup, I can confirm 2.0.0 works just fine in my testing. @missedone


Allow loading images from /public

Fixes #1
Might help with some of the problems in #41
I am in the process of adding this tool, and found it difficult to do because normally astro loads images from /public, and so all my existing images live there, including images that I reference from markdown files.  I hit errors during build like Input file is missing, without knowing why (because I didn't realize it was my images in markdown that were being automatically processed, and the error message does not say the filepath that failed).
So, this change allows markdown and components to specify images in /public (or other configured publicDir), without the need for explicitly adding /public to the start of the url.  I've tested it in my own app in dev and build, with a <Picture /> element loading from /src and from public, as well as markdown files pointing to public images as well as http images.
I'd like to add some better tests around the method, though, to be sure that it is handling the edge cases properly (I'm not sure it will deal with relative paths correctly, for instance).  What would you think about adding some vitest tests?  They are easy to set up, support esm natively, and run nice and quick.  Would you be open to a few basic tests, to see how it works? Tests were added in https://github.com/RafidMuhymin/astro-imagetools/pull/58, but are currently failing until https://github.com/RafidMuhymin/astro-imagetools/pull/64 is merged.  I've added some test cases here as well.  Ideally, we'll add some higher-level tests soon too, to be sure that it's all working end-to-end.
I also wonder if you might consider a breaking change to treat all absolute paths as being inside /public, and relative paths like ./src/foo.jpg as relative to the project root.  Or ideally relative to the file itself, but that might be a little trickier. Talked in discord, and @RafidMuhymin prefers that we try to find files relative to both locations, which is what I've done in this PR
lastly, it might be better to add a try/catch around the call to sharp with a warning there when files can't be found, rather than throwing a warning in the function I made.  I'll experiment with that approach as well. I've taken out the warning, and opened https://github.com/RafidMuhymin/astro-imagetools/issues/66 to track as a separate feature request.

Tests will fail until https://github.com/RafidMuhymin/astro-imagetools/pull/64 is merged and this is rebased on it.  Otherwise, I think it's ready to go.
I guess we need to write the astro config to a file because of SSR?  Am I correct in thinking that sometimes this code runs in node, and sometimes in the browser, which is why we can't just create a variable in memory and rely on closures to pass it around?

I also added an .npmignore file, to avoid publishing tests and test fixtures to npm, which would just bloat the install size.

@RafidMuhymin okay, this is ready for a review, thanks!

LGTM :+1: ! Thanks for contributing @IanVS !


ENH: sparse.linalg: An efficient implementation of GMRES method

Reference issue

Closes gh-15149 because my forked scipy repository is removed by mistake
What does this implement/fix?

The PR reimplemented restarted GMRES algorihm, the code in the PR is more efficient than the original version. The comments and performance is shown in gh-15149.
Additional information

Dear Andrew @lobpcg , Could you review it again? The references have been added according to your suggestions and the rest of the code remains unchanged. Thanks

Dear @zhaog6, I take this opportunity to share some results and discuss a few points.
I plan to add the weighted GMRES(m) to scipy, as this variant can lead to mesh independent convergence results for FEM/BEM simulations (see e.g. this article). The weighted version requires only a few changes to the code as compared to the classic Euclidean version.
What I did so far:

I was having difficulties with the Fortran core in scipy.sparse.linalg.gmres, and found out that the pyamg.krylov.gmres code was much easier to understand, and to modify. I implemented the weighted GMRES for mgs orthogonalization (I shall propose a PR soon to pyamg).
I came across your issue, and found it very interesting as it didn't use the Fortran core. I decided to wait for the commit to be done, in order to start implementing a weighted scipy.sparse.linalg.gmresk function.
Today, I wondered whether the classic pyamg.krylov.gmres (with both 'mgs' and 'householder' orthogonalizations) was more efficient that scipy.sparse.linalg.gmres, so I implemented a simple benchmark.
pyamg.krylov.gmres appeared to be twice as slow as scipy.sparse.linalg.gmres for my BEM simulations (performed with bempp-cl).
I decided to compare those results to your scipy.linalg.gmresk implementation. scipy.sparse.linalg.gmresk and scipy.linalg.gmres appear to have similar performances (see the exhaustive results above).

A few questions:

Which are the differences between pyamg.krylov.gmres('mgs') and scipy.sparse.linalg.gmresk? Did you use pyamg.krylov.gmres('mgs') as a reference?
Is your scipy.sparse.linalg.gmresk implementation supposed to replace the original scipy.sparse.linalg.gmres in scipy?

Paul

Example:
3D EM scattering problem by a unit sphere solved by BEM on a graded mesh. CFIE formulation in strong form with BC function space + FMM.
N = 711 dofs
k = 4 wavenumber
tol = 1e-5
maxiter = 1000
For restart = maxiter, convergence is reached in 20 iterations:
Execution time (in s.):

15.713715314865112 sc gmres
15.42734169960022 sc gmresk
30.51805353164673 pyamg gmres_householder
31.24692392349243 pyamg gmres_mgs

Final residuals are:
0.00019359173984727306 sc gmres
0.00019765435974601611 sc gmresk
0.0001935917398478821 pyamg gmres_householder
0.00019359173984632332 pyamg gmres_mgs
I tried other configurations, and obtained the similar relative performance. I hope this helps!
Paul

While performing the simulations, I detected two possible issues. I defined this callback:
class sc_gmres_counter(object):
    def __init__(self, disp=True):
        self._disp = disp
        self.niter = 0
        self.residual = []
    def __call__(self, rk=None):
        self.niter += 1
        self.residual.append(rk)
        if self._disp:
            print('iter %3i\trk = %s' % (self.niter, str(rk)))
            #print(rk.dtype)

With scipy.sparse.linalg.gmres:
ta = time.time()
sc_gmres_callback = sc_gmres_counter(disp = True)
sc_gmres_x, conv = sc_gmres(MFIE, b0, tol = tol, maxiter = maxiter, restart = restart, callback = sc_gmres_callback)
tsc_gmres = time.time() - ta
print(tsc_gmres, 'tsc_gmres')

I get:
iter   1	rk = 0.1837916301090236
iter   2	rk = 0.11138931939225478
iter   3	rk = 0.08211903375560312
iter   4	rk = 0.07004378432798104
iter   5	rk = 0.06380985251775857
iter   6	rk = 0.05715909562403769
iter   7	rk = 0.04642969181489359
iter   8	rk = 0.03214239224867582
iter   9	rk = 0.01107110975966527
iter  10	rk = 0.0029690925151010243
iter  11	rk = 0.0014425678231152971
iter  12	rk = 0.0010554942264707778
iter  13	rk = 0.0009143820403326146
iter  14	rk = 0.0006545110058378569
iter  15	rk = 0.0004261595451156276
iter  16	rk = 0.00013309019662648385
iter  17	rk = 6.889628500893324e-05
iter  18	rk = 4.214960307118879e-05
iter  19	rk = 1.6825761832743438e-05
iter  20	rk = 8.99929372085533e-06
15.713715314865112 tsc_gmres

With scipy.sparse.linalg.gmresk:
ta = time.time()
sc_gmresk_callback = sc_gmres_counter(disp = True)
sc_gmresk_x, conv = sc_gmresk(MFIE, b0, tol = tol, maxiter = maxiter, restart = restart, callback = sc_gmresk_callback)
tsc_gmresk = time.time() - ta
print(tsc_gmresk, 'tsc_gmresk')

I get:
iter   1	rk = (21.511881471209872+0j)
iter   2	rk = 3.9537038393927517
iter   3	rk = 2.396696066591928
iter   4	rk = 1.7695582180118858
iter   5	rk = 1.5127003077945789
iter   6	rk = 1.4133875853610975
iter   7	rk = 1.3805802960304863
iter   8	rk = 1.2685742747255486
iter   9	rk = 0.7814670758076535
iter  10	rk = 0.24208381988871075
iter  11	rk = 0.06396454310698772
iter  12	rk = 0.03104710829792781
iter  13	rk = 0.022771018219659676
iter  14	rk = 0.023974382488567897
iter  15	rk = 0.023093319894124793
iter  16	rk = 0.010817520444123376
iter  17	rk = 0.002906011109539687
iter  18	rk = 0.001493678744490108
iter  19	rk = 0.0009188626403153703
iter  20	rk = 0.00037376595656475045
iter  21	rk = (0.00019765435974601611+0j)
15.42734169960022 tsc_gmresk

Comments:

It sounds like the gmres callback is with relative residual rk/r0 while gmresk sounds to be giving me rk.
My simulations are in complex128. With gmresk, some residuals are float, as expected, but I get complex numbers at iterations 1 and 21.

Paul

Dear @pescap thanks for your attention!

I plan to add the weighted GMRES(m) to scipy, as this variant can lead to mesh independent convergence results for FEM/BEM simulations (see e.g. this article).

Yes, it is interesting and meaningful.

Which are the differences between pyamg.krylov.gmres('mgs') and scipy.sparse.linalg.gmresk?

I downloaded it and take a look. There are some differences. The algorithm steps of the algorithm are almost the same because we all refer to the textbook of Yousef Saad, but some optimizations have been made for data storage way based on Python and some mathematical operations. Therefore it will be expected to bring performance improvements.

Did you use pyamg.krylov.gmres('mgs') as a reference?

No. General steps of the algorithm are basically the same, but the implementation details and optimizations are different.

Is your scipy.sparse.linalg.gmresk implementation supposed to replace the original scipy.sparse.linalg.gmres in scipy?

Yes

Example:
3D EM scattering problem by a unit sphere solved by BEM on a graded mesh. CFIE formulation in strong form with BC function space + FMM.
N = 711 dofs
k = 4 wavenumber
tol = 1e-5
maxiter = 1000

Thanks. Increase the number of DOFs (mesh: 64x64/128x128/256x256/...), gmresk will be significantly faster than the original implementation gmres in SciPy, at least for the 2-D convection-diffusion equations (asymmetric) and Poisson equations (symmetric).

It sounds like the gmres callback is with relative residual rk/r0 while gmresk sounds to be giving me rk.

Yes, gmresk gives absolute resdiual rk, if you want to get relative residual, you only need to change it as follows
self.residual.append(rk / np.linalg.norm(b))

I plan to add the weighted GMRES(m) to scipy, as this variant can lead to mesh independent convergence results for FEM/BEM simulations (see e.g. this article).

Yes, it is interesting and meaningful.
I'll create an issue, and start working on its implementation as soon as gmresk is added to the library.

My simulations are in complex128. With gmresk, some residuals are float, as expected, but I get complex numbers at iterations 1 and 21 (i.e. first and last iteration).

I see, I'll fix the bug.

Yet, for compatibility issues, don't you think that gmres and gmresk should behave the exact same way, and be with the same default behavior?

In fact, I prefer callback of absolute residual norm because it can be compared with the results of many math library. If users want to get relative residual norm, which can be defined in callback function. If you think it is really inconvenient or affects compatibility, I can modify it.

Hi @zhaog6 I found this a little too late to take in. Apologies for that but now we have #18488 in case you want to add the extras on top of the existing solver.


Bug: JSONParser Nested Record Key Check

Background
Currently, the Rule Processor's JSONParser contains a bug when working with nested records where the schema_match check is improperly reset between iterations of each record.   This bug was identified as a result of parsing CloudTrail logs from S3.
   def _key_check(self, schema, json_records):
        """Verify the declared schema matches the json payload
        If keys do not match per the schema, records are removed from the
        passed in json_records list
        Args:
            json_records [list]: List of dictionaries representing JSON payloads
        Returns:
            [bool] True if any log in the list matches the schema, False if not
        """
        schema_keys = set(schema.keys())
        schema_match = False                                       # This must happen in the iteration below

        for index in reversed(range(len(json_records))):
            json_keys = set(json_records[index].keys())
            if json_keys == schema_keys:
                schema_match = True
                for key, key_type in schema.iteritems():
                    if key == 'streamalert:envelope_keys' and isinstance(json_records[index][key], dict):
                        continue
                    # Nested key check
                    if key_type and isinstance(key_type, dict):
                        schema_match = self._key_check(schema[key], [json_records[index][key]])
            else:
                LOGGER.debug('JSON Key mismatch: %s vs. %s', json_keys, schema_keys)

            if not schema_match:                                    # This bug causes the record to not be considered invalid by remaining in the json_records list
                del json_records[index]

#264 is in progress to fix this bug

Fixed in #264


Improve integration with @vite/plugin-legacy

Description
I know this issue has been posed before (#39), but I would like to open it again from a different angle because I HAVE a working solution, it is just quite hacky, and I would like to improve it. Also, there is one issue when using the plugin in older Edge browsers that should be easy to fix from your side.
Before going for the solution, let me motivate why I need the plugin in the first place. For me, it is not at all about IE11—that one is definitely dead. For me, it is about older phones. The current Vite baseline is dynamic import() + import.meta.url support. This leaves out about 5% of users (https://caniuse.com/?search=import.meta) and for instance everyone stuck on Safari 10.
And I do not think this has been the final time this baseline will be moved. For instance support for module workers (https://caniuse.com/?search=module worker) or import assertions could theoretically become part of the baseline in the future.
So here is my approach:
https://github.com/lukastaegert/vite-plugin-ssr-legacy
It works like this:

We add vite-plugin-ssr and the legacy plugin. We need disableAutoFullBuild: true because otherwise, the extra build triggered by @vite/plugin-legay will also trigger the ssr plugin which then will fail because there is no manifest.json (possible improvement: vite-plugin-ssr detects this extra build and ignores it, or does something else sensible).
First, we run vite build --ssr so that the server files are generated.
Then we run vite build. This also triggers a nested build from @vite/plugin-legacy that generates a -legacy.js file for every regular generated file. At bundleClose, a special plugin kicks in that

Runs the prerender function to generate the HTML files.
Uses globs to find all

generated HTML files
the generated entry-server-routing.[hash].js
the corresponding  entry-server-routing-legacy.[hash].js

Manually runs  the transformIndexHtml hook of the legacy plugin first on a simulated legacy chunk to set some internal state of the legacy plugin, and then again on a simulated "modern" chunk that will actually inject the legacy code. This is a really tricky step where I blindly copied quite a bit of logic from Vite to be able to parse the non-trivial response from that hook.

To test this solution actually works, I downloaded a VM from https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ and tested the production build. I am working against "MSEdge von Win10", which supports ES6 imports but no dynamic imports or import.meta.url.
With client routing, there is a bug that occurs when using
import { navigate } from "vite-plugin-ssr/client/router";

That triggers a history initialization with a history.replaceState(someObject, undefined, undefined). In old Edge if you pass an explicit undefined as the third parameter here, it actively changes the url to /undefined. The fix would be as simple as changing https://github.com/brillout/vite-plugin-ssr/blob/aabfde988d2e427a9af78f3d8765276455947fb2/vite-plugin-ssr/client/router/history.ts#L81-L83 to
function replaceHistoryState(state: HistoryState, url: string | null = null) {
  window.history.replaceState(state, '', url)
}

because null indeed works as expected even in old Edge.
Beyond that, here are things where I hope we can work to improve on vite-plugin-ssr:

support autoFullBuild for pre-rendering. It could be as easy as detecting and ignoring that special run triggered by the legacy plugin.
find a way to avoid manually running the transformIndexHtml hook. I am not sure this will be easily possible. The longer I think about it, the easiest way would probably be to do that as part of the plugin itself. The transforms are not terribly complicated. They could just be written as template strings where in the right place one would need to inject the name of the legacy chunk. Doing the transform yourself would also mean that it would not only work for pre-rendering, it could also work for true SSR. So it would mean when the plugin is detected, vite-plugin-ssr automatically adds the necessary HTML transformations while the plugin just handles generating the legacy SystemJS JavaScript.

<!DOCTYPE html>
<html lang="en">
  <head>
    <!-- injected if modern polyfills are enabled. Leave out if no such file exists -->
    <script type="module" crossorigin src="/assets/polyfills.29399a5e.js"></script>

    <!-- regular head content goes here... -->

    <!-- feature detection. This snippet is always identical -->
    <script type="module">try{import.meta.url;import("_").catch(()=>1);}catch(e){}window.__vite_is_modern_browser=true;</script>
    <script type="module">!function(){if(window.__vite_is_modern_browser)return;console.warn("vite: loading legacy build because dynamic import or import.meta.url is unsupported, syntax error above should be ignored");var e=document.getElementById("vite-legacy-polyfill"),n=document.createElement("script");n.src=e.src,n.onload=function(){System.import(document.getElementById('vite-legacy-entry').getAttribute('data-src'))},document.body.appendChild(n)}();</script>
  </head>
  <body>

    <!-- regular body content goes here... -->

    <!-- script loader. This snippet is always identical. -->
    <script nomodule>!function(){var e=document,t=e.createElement("script");if(!("noModule"in t)&&"onbeforeload"in t){var n=!1;e.addEventListener("beforeload",(function(e){if(e.target===t)n=!0;else if(!e.target.hasAttribute("nomodule")||!n)return;e.preventDefault()}),!0),t.type="module",t.src=".",e.head.appendChild(t),t.remove()}}();</script>

    <!-- legacy polyfill chunk. Leave out if no such file can be found. -->
    <script nomodule crossorigin id="vite-legacy-polyfill" src="/assets/polyfills-legacy.d29a7a52.js"></script>

    <!-- legacy entry. Here we need to inject the correct legacy chunk -->
    <script nomodule crossorigin id="vite-legacy-entry" data-src="/assets/entry-server-routing-legacy.6fabb6ae.js">System.import(document.getElementById('vite-legacy-entry').getAttribute('data-src'))</script>
  </body>
</html>

Wow, that was super quick, thank you so much.

I'm open to this as long as it doesn't decrease VPS maintainability all too much

I agree that this might be the biggest problem.

Removing the line, fixes the problem

Does 0.4.71-draft.18338 work for you? (Removing the assertion isn't sufficient.)

Hi, yes it works. Thanks :)

👍 Released as 0.4.72. FYI in case your company is up for it: https://github.com/sponsors/brillout.

@brillout
yeah，when using @vite/plugin-legacy，really need VPS insert modern+legacy code  into html, Is there a schedule?
That will be great

Is there a schedule?

You can already use VPS with @vite/plugin-legacy today, see https://github.com/brillout/vite-plugin-ssr/issues/477#issue-1411515555. Please respect https://brillout.github.io/rules/ – thanks!

Is there a schedule?

You can already use VPS with @vite/plugin-legacy today, see #477 (comment). Please respect https://brillout.github.io/rules/ – thanks!

sorry, Maybe I didn't express it clearly，
i used @vite/plugin-legacyand VPS, ssr mode(not prerender);
just wanna cover most of mobile phones.
when npm run prod, visit /index，
html will response like that:
<!DOCTYPE html>
    <html lang="en">
      <head>
        <link rel="stylesheet" type="text/css" href="/assets/_default.page.client.cc733d7d.css">
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <meta name="description" content="App using Vite + vite-plugin-ssr" />
        <title>Vite SSR app</title>
      </head>
      <body>
        <div id="app"> some doms </div>
        <script type="module" src="/assets/entry-server-routing.0e8173a5.js" defer></script>
        <link rel="modulepreload" href="/assets/src/pages/index/index.page.545e05bb.js" as="script" type="text/javascript">
        <link rel="modulepreload" href="/assets/chunk-101896b7.js" as="script" type="text/javascript">
        <link rel="modulepreload" href="/assets/chunk-ce4476bd.js" as="script" type="text/javascript">
        <link rel="modulepreload" href="/assets/renderer/_default.page.client.03a442f4.js" as="script" type="text/javascript">
        <link rel="modulepreload" href="/assets/chunk-3adbf793.js" as="script" type="text/javascript">
        <script id="vite-plugin-ssr_pageContext" type="application/json">{"pageContext":{"_pageId":"/src/pages/index/index","pageProps":"!undefined","urlPathname":"/"}}</script>
      </body>
    </html>

*-legacy assets and <script> nomodule   missed.
how can i get both modern assets and legacy assets in responsed html ?
just like this issue beginning:
<!DOCTYPE html>
<html lang="en">
  <head>
    <!-- injected if modern polyfills are enabled. Leave out if no such file exists -->
    <script type="module" crossorigin src="/assets/polyfills.29399a5e.js"></script>

    <!-- regular head content goes here... -->

    <!-- feature detection. This snippet is always identical -->
    <script type="module">try{import.meta.url;import("_").catch(()=>1);}catch(e){}window.__vite_is_modern_browser=true;</script>
    <script type="module">!function(){if(window.__vite_is_modern_browser)return;console.warn("vite: loading legacy build because dynamic import or import.meta.url is unsupported, syntax error above should be ignored");var e=document.getElementById("vite-legacy-polyfill"),n=document.createElement("script");n.src=e.src,n.onload=function(){System.import(document.getElementById('vite-legacy-entry').getAttribute('data-src'))},document.body.appendChild(n)}();</script>
  </head>
  <body>

    <!-- regular body content goes here... -->

    <!-- script loader. This snippet is always identical. -->
    <script nomodule>!function(){var e=document,t=e.createElement("script");if(!("noModule"in t)&&"onbeforeload"in t){var n=!1;e.addEventListener("beforeload",(function(e){if(e.target===t)n=!0;else if(!e.target.hasAttribute("nomodule")||!n)return;e.preventDefault()}),!0),t.type="module",t.src=".",e.head.appendChild(t),t.remove()}}();</script>

    <!-- legacy polyfill chunk. Leave out if no such file can be found. -->
    <script nomodule crossorigin id="vite-legacy-polyfill" src="/assets/polyfills-legacy.d29a7a52.js"></script>

    <!-- legacy entry. Here we need to inject the correct legacy chunk -->
    <script nomodule crossorigin id="vite-legacy-entry" data-src="/assets/entry-server-routing-legacy.6fabb6ae.js">System.import(document.getElementById('vite-legacy-entry').getAttribute('data-src'))</script>
  </body>
</html>

I'm not that familiar with @vite/plugin-legacy – this seems more like @vite/plugin-legacy question than a VPS question.

I'm not that familiar with @vite/plugin-legacy – this seems more like @vite/plugin-legacy question than a VPS question.

just confused，cuz after  build，dist contains  legacy  assets:

but when server rendering :
got _pageAssets like  this, no more  legacy assets, just modern assets:

curious how VPS got page's  assets in server side?
It should be determined at compile time？

well，in my opinion,
VPS generate the response HTML all in runtime，and without any hooks or Intermediate blocks，maybe too Limited or heavy for customization。
final HTML  = compiled assets(js、critical css/links) + dynamic tags/title/desc/...  + #app SSR components

content-hashed assets already  generated after compile and unchangeable(even，put these assets in  or ，some assets use module or nomodule，has been confirmed after compiled)

during the compilation process, there are  so many plug-ins that can affect the results generated

It is not possible to Implement the logic of all plug-ins，maybe just modified or combine those compiled html/blocks will much flexible, and doesn't decrease VPS maintainability~~~

I'm afraid I didn't understand your message. Feel free to create a reproduction with a clear description of what you want VS what is happening.


Suggestion about making the code more global for working with ZHA, too

Hi,
your appdaemon script doesn't work with ZHA, only the aqara integration.
But if you change:
    for entity_id in motion_sensors:
#     self.listen_event(self.motion_sensor_state_on, "xiaomi_aqara.motion", entity_id=entity_id)
      self.listen_state(self.motion_sensor_state_on, entity_id, new = "on")

# def motion_sensor_state_on(self, event, data, kwargs):
  def motion_sensor_state_on(self, entity, attribute, old, new, kwargs):
    """Set motion sensor state to on"""
    entity_id = entity

it should probably work globally.
I can say that this works with ZHA, could you please test it with the aqara integration. If it works, too, you could think about changing those three lines in your code...
Seb

@wernerhp could you pleas look into that as it might help others a lot with a little change...
Thx!

I've migrated away from the Aqara hub, so I can't test for regressions, but I've released a new version that supports ZHA.


Improve setting cache-control header

Adds explicit Cache-Control header functionality to StaticFileMiddleware

Can specify a DefaultCacheProfile to use for all requests
Alternatively, can use the CachProfileProvider to create a request-specific CacheProfile that overrides the default
If neither is specified, adds no headers
Borrows heavily from the ResponseCacheFilter in MVC project.

Address #122

Hi @andrewlock, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;

@JunTaoLuo

Assigning to @JunTaoLuo for investigation. We'll need to decide if we'd like to take this in.

Thanks for all the feedback! I'll work through it shortly.
I have to confess, the implementation of the ResponseCacheFilter was somewhat blindly copied from the MVC ResponseCacheFilter implementation on the basis that it was a best practice for the cache header behaviour, but I may have misunderstood some of its behaviour.

@JunTaoLuo I think the last 2 bits remaining are potentially renaming the enums and handling negative durations. Are there any more thoughts on how those points should be handled?
Renaming enums makes sense but does break even further from the MVC approach - though the whole implementation is maybe far enough from that now that it's not an issue.
I'm all for handling negative durations but I'm not sure of the best approach that will be accepted?
Thanks

Just wanted to follow up on this PR WRT the final couple of questions... Thanks

Hi @andrewlock, thanks for the PR. We decided to reject this PR - we had a meeting to review this, and we decided that this PR adds a lot of complexity to solve the issue specified in https://github.com/aspnet/StaticFiles/issues/122 (which is not that bad really.)  And accepting this PR would mean that we'll have to support this additional complexity for a very long time.

Ok @muratg, that's fair enough. I think I learnt from it anyway:) I assume you're going to close #122 then?

Thanks for the reminder! Yep, closed the bug too.

The ApplyCacheProfile(HttpContext, CacheProfile) method @andrewlock has written is not something trivial and not something I'd want to include in my projects.
For anyone else who doesn't want to have to copy pasta his code, I've included it in the Boilerplate.AspNetCore NuGet package. The GitHub repo is ASP-NET-MVC-Boilerplate/Framework.


updates theme.json to v2 for compatibility with filtering

Description of the Change
This updates the theme.json version to v2 for compatibility with the new theme.json filters. It also updates keys to match v2 schema.
How to test the Change
Confirm custom styles are applying to the theme.
Changelog Entry

Changed - Updates theme.json to v2

Checklist:

[ ] I agree to follow this project's Code of Conduct.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my change.
[ ] All new and existing tests pass.

@jacobdubail If you want to you can also change the base of this PR to the trunk branch. We will want to use the update for the entire scaffold :)

@jacobdubail
We want to have the filter for the theme.json updates in here -right? Or is that still up for discussion?

ohh... @jacobdubail I see how you are doing it now.. and that's actually pretty slick!!


[Feat]:   Improve Feature Page UI for Enhanced Visual Appeal

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
The current UI of the feature page could be enhanced to provide a more visually appealing and user-friendly experience. These changes aim to boost usability and create a cohesive design that aligns with the overall application's style.

Use Case
By improving the feature page UI, this enhancement will align it with the design and layout standards of other pages in the project. This consistency will make the navigation and user experience more seamless, creating a polished and cohesive interface across all sections.
Benefits
No response
Priority
High
Agreements

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSoC contributor
[X] I'm a Hacktoberfest contributor
[X] I want to work on this issue
[X] I'm willing to provide further clarification or assistance if needed.

Proceed!


Payment is shown as pending and received

What did I do?

Fund wallet with 100k sats
Pay JIT channel opening fees of 153 sats
Receive funds of 153 sats
Pay with faucet.

I can't reproduce this - are you sure you didn't accidentally exit out of invoice creation at some point?
Can you show the details for the pending & successful ones?

Screenshot of my state after performing steps listed

Ah, I just managed to reproduce this. I think there must be a race condition somewhere creating the invoice twice.

I suppose we'd expect to see two "Successfully created invoice" logs

Closing as we are reworking the receive screen in #1163 which will solve this ticket.


How to make doc prop reactive in vue

Thanks for the this package.
I am trying to implment it using vue. It is working as expected, but I am unable to make doc prop reactive. Here is my code:
<script setup>
import { EditorCacheProvide, SQLEditor } from '@tidbcloud/tisqleditor-vue';
import { curSqlGutter } from '@tidbcloud/codemirror-extension-cur-sql-gutter';
const code = ref(sqlCode.value ?? '');
</script>

<template>
 <EditorCacheProvide>
	<SQLEditor
		editor-id="test"
		:doc="code"
		class="block grow"
		:basic-setup-options="{
			autocompletion: true
		}"
		:extra-exts="[
			curSqlGutter()
		]"
	/>
</EditorCacheProvide>
</template>

I have also installed @codemirror/view and @codemirror/state.
When I update code, the content inside the editor is not updated.

@abdul-alhasany you need to use onDocChange from the events extension to get access to the SQL statement.
import {
  onDocChange,
  onSelectionChange
} from '@tidbcloud/codemirror-extension-events'

const docChangeHandler = (view, state, doc) => {
  console.log(doc);
}

const selectionChangeHandler = (view, state, ranges) => {
  console.log(ranges);
}
...
:extra-exts="[
			curSqlGutter(),
			onDocChange(docChangeHandler),
  onSelectionChange(selectionChangeHandler)
		]"

console will now log the query


zk plugin not showing up in IntelliJ 15.0.1

Installed plugin two different ways, accessing the plugin through IntelliJ and downloading ZK plugin then installing. It shows up as an active plugin but when I try to create a Maven project ZK does not show up.

It seems like the IntelliJ changes some plugin API, so the current version won't work with it.

Do you have any idea when you will release a fixed version?
From: Jumper Chen<EMAIL_ADDRESS>Sent: Sunday, November 29, 2015 11:18 PM
To: jumperchen/zkidea<EMAIL_ADDRESS>Cc: IndisRepair<EMAIL_ADDRESS>Subject: Re: [zkidea] zk plugin not showing up in IntelliJ 15.0.1 (#11)
It seems like the IntelliJ changes some plugin API, so the current version won't work with it.
—
Reply to this email directly or view it on GitHub https://github.com/jumperchen/zkidea/issues/11#issuecomment-160542633 .

when? not sure, it needs some time to study their source code to see what happened.

A week, a month, or …? Need to make a decision
Thanks for the reply
From: Jumper Chen<EMAIL_ADDRESS>Sent: Monday, November 30, 2015 8:27 PM
To: jumperchen/zkidea<EMAIL_ADDRESS>Cc: IndisRepair<EMAIL_ADDRESS>Subject: Re: [zkidea] zk plugin not showing up in IntelliJ 15.0.1 (#11)
when? not sure, it needs some time to study their source code to see what happened.
—
Reply to this email directly or view it on GitHub https://github.com/jumperchen/zkidea/issues/11#issuecomment-160850042 .

After re-verify again, ZK plugin can work with IntelliJ 15.0.1 version from this 0.1.6 version - https://plugins.jetbrains.com/plugin/7855


[Deployment] Remove the need for port 3000 when loading the app

Our goal is for users to access the offline computers SSID and from their browser just navigate to Terrastories (or possibly terrastories.io.

I assigned @Bootjack and @robbkidd but mainly cause I need help. Perhaps one or two of us could pair later tonight, Sept. 30th.

closing for now; moving details to issue google doc


Feature 1.2

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

419 of 477 (87.84%)  changed or added relevant lines in 18 files are covered.
40 unchanged lines in 11 files lost coverage.
Overall coverage decreased (-1.2%) to 94.571%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

include/rexsapi/JsonModelSerializer.hxx
3
4
75.0%

include/rexsapi/Mode.hxx
0
1
0.0%

include/rexsapi/ModelSaver.hxx
0
1
0.0%

include/rexsapi/RelationTypeChecker.hxx
11
12
91.67%

include/rexsapi/ModelBuilder.hxx
51
53
96.23%

include/rexsapi/ExternalSubcomponentsChecker.hxx
51
58
87.93%

include/rexsapi/JsonModelLoader.hxx
26
48
54.17%

include/rexsapi/ModelMerger.hxx
165
188
87.77%

Files with Coverage Reduction
New Missed Lines
%

include/rexsapi/Types.hxx
1
97.92%

include/rexsapi/RelationTypeChecker.hxx
1
94.17%

include/rexsapi/ModelSaver.hxx
1
85.0%

include/rexsapi/database/FileResourceLoader.hxx
1
93.1%

include/rexsapi/ModelLoader.hxx
1
96.39%

include/rexsapi/Base64.hxx
1
91.67%

include/rexsapi/ConversionHelper.hxx
2
92.31%

include/rexsapi/XSDSchemaValidator.hxx
3
95.9%

include/rexsapi/XMLModelLoader.hxx
4
90.53%

include/rexsapi/JsonModelLoader.hxx
6
82.24%

Totals

Change from base Build<PHONE_NUMBER>:
-1.2%

Covered Lines:
4024

Relevant Lines:
4255

💛  - Coveralls


Promote Frictionless Data Case Study

[x] Blog post on case studies
[x] General promotion

Closed by https://github.com/okfn/okfn.github.com/pull/477
Tweets scheduled


Develop Coordinated Vulnerability Disclosure recommendations for OSS projects

The group would like to develop a CVD guide for OSS projects. The guide should include the CVD process, how to work with security researchers in a CVD setting, and templates for security policies (issue #95).
A fork of Google's CVD for OSS guide has been added here to give a starting base. Please open issues, PRs, and edit away!

We've got that first version up and an feedback/incorporation mechanism going, so I think we can close this out!


feature: add state anno

What this PR does:
add state anno#438

Thanks for your contribution and welcome to the community !


Do not apply P3 penalty if peers are pruned from topic mesh

Motivation

Part of the effort to investigate why P3 is applied a lot to peers

Description

Do not apply P3 penalty if peers are pruned from topic mesh (double checked with rust-libp2p)

Codecov Report

Merging #212 (412b895) into master (8d62ee4) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #212   +/-   ##
=======================================
  Coverage   86.12%   86.13%
=======================================
  Files          19       19
  Lines        5450     5452    +2
  Branches      612      617    +5
=======================================
+ Hits         4694     4696    +2
  Misses        756      756

Impacted Files
Coverage Δ

ts/score/peer-score.ts
91.19% <100.00%> (+0.03%)
:arrow_up:

Continue to review full report at Codecov.

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

Right now P3 is applied heavily even after peers left mesh (there's only 1 mesh peer)


TypeKit Console Error

Not a big deal but the following error appears in the browser console for any We.Retail site page:

dje4ayd.js:48 Typekit: the domain [domain-name] isn't in the list of published domains for kit "dje4ayd".

Basically, our UNIT test server isn't in your TypeKit's (ID: dje4ayd) publish domain list. I went to create my own TypeKit for our test environments but the font being used (Proxima Nova) is a premium-only font, so I can't even technically replace your TypeKit ID with my own to get this to work properly.
Maybe I'm just being OCD about clean console output. If so, I apologize.

The TypeKit is configured with localhost in the list of published domains as the demo is expected to be run locally.


Add multi-select table filter for columns with many options

[ ] Add multiple selection widget with auto-completion.

ng-select
OR (material chips](https://material.angular.io/components/chips/overview).

[ ] Add option to Column type to control whether columns use checkboxes or this new UI widget.
[ ] Incorporate into tables

[ ] Simulators
[ ] Projects

:tada: This issue has been resolved in version 7.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Note not to use kubectl-apply for tigera-operator.yaml.

Quick impression of the change:

/sem-approve


gnomeExtensions.no-title-bar: 9 -> 11, unbreak

Motivation for this change
Second attempt at #88679, since upstream tagged a release. I've been running this on my system for a while, it all works.
Things done

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

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

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

@ofborg eval

@ofborg eval

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

1 package built:

gnomeExtensions.no-title-bar

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

1 package built:

gnomeExtensions.no-title-bar

Is there anything I can do to get this merged? Would like to see this in master before 21.05 and there's another release of this extension :sweat_smile:

I'm currently testing with this patch applied to unstable. Works just fine. I may end up keeping it :)


Listchaintxns

Background
Describe your issue here.
Odd entry in listchaintxns
    {
        "tx_hash": "c006221d97cea983951be48c0992767c5bff575bcaa9a776def6cf6b95784aad",
        "amount": "0",
        "num_confirmations": 0,
        "block_hash": "",
        "block_height": 0,
        "time_stamp": "1536965928",
        "total_fees": "0",
        "dest_addresses": [
        ]
    }

Your environment

version of lnd      "version": "0.5.0-beta commit=7fe095c54128b502e20b3482ef73f1b6ba737850"

which operating system (uname -a on *Nix) x86_64 GNU/Linux

version of btcd, bitcoind, or other backend, btcd

any other relevant environment details

Steps to reproduce
Tell us how to reproduce this issue. Please provide stacktraces and links to code in question.
No logs show that txid
Expected behaviour
Tell us what should happen
Actual behaviour
Tell us what happens instead

Can happen due to second layer HTLCs and the like. We add them to the wallet so it can rebroadcast them, but the wallet doesn't know the inputs and can't spend the outputs itself.


Build and publish docs for dav-server-opendalfs

dav-server-opendalfs is a released crate but we didn't build it's docs to opendal.apache.org.

Interested! 😃
If I understand this issue correctly, we are going to change main/integrations/dav-server/src/lib.rs to make it similar to main/core/src/lib.rs ?

This issue is about to use rustdoc to generate API docs like
https://github.com/apache/opendal/blob/2665e634d454b7ecedeb580ac353da1666072f5d/.github/workflows/docs.yml#L37-L72


Fixed the API request on fetching contributors

@Rakesh9100 hii i have fixed #996  , now api limited increseses to 5000 pr hr
please mark Gssoc24 level 3

[X ] My code follows the style guidelines of this project
[ X] I have performed a self-review of my own code
[ X] I have commented my code, particularly in hard-to-understand areas
[X ] I am an Open Source Contributor

Pls make the changes to this file Contributors script as this is the main logic file of contributors @pandeyji711

Pls make the changes to this file Contributors script as this is the main logic file of contributors @pandeyji711

ok

@Rakesh9100 I create New branch for this https://github.com/Rakesh9100/CalcDiverse/pull/1179
pleaase cheak


CLI tools should report error into stderr and have user friendly outputs

Description
For now if there is some error it is reported to stdout. This is wrong it should be reported to stderr.
Use case
Better for scripting and for errors handling
Interface Changes
Need to update next CLI commands:
oneacct
oneacl
onecluster
onedatastore
onedb
oneflow
oneflow-template
onegroup
onehost
oneimage
onemarket
onemarketapp
onesecgroup
oneshowback
onetemplate
oneuser
onevcenter
onevdc
onevm
onevmgroup
onevnet
onevrouter
onezone

Additional Context

Progress Status

[ ] Branch created
[ ] Code committed to development branch
[ ] Testing - QA
[ ] Documentation
[ ] Release notes - resolved issues, compatibility, known issues
[ ] Code committed to upstream release/hotfix branches
[ ] Documentation committed to upstream release/hotfix branches

PRs to merge in 5.10 and master:

code: https://github.com/OpenNebula/one/pull/4294
docs: https://github.com/OpenNebula/docs/pull/975


Highlights the resource Parameter

Because the resource parameter is only briefly mentioned in the README.md, it's
an immensely useful feature that's difficult to track down outside of the code base.
Until better messaging can be provided---the current "Error: No label add or removes
specified" could use some DX love---this example highlights the resource parameter
as a feature of this API.
Addresses Issue #808

[x] npm test succeeds
[x] Pull request has been squashed into 1 commit
[x] I did NOT manually make changes to anything in apis/
[x] Code coverage does not decrease (if any source code was changed)
[x] Appropriate JSDoc comments were updated in source code (if applicable)
[x] Approprate changes to readme/docs are included in PR

Codecov Report

Merging #809 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #809   +/-   ##
=======================================
  Coverage   74.57%   74.57%
=======================================
  Files           4        4
  Lines         236      236
  Branches       53       53
=======================================
  Hits          176      176
  Misses         43       43
  Partials       17       17

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 4b0b548...fab80cf. Read the comment docs.

I signed it!


Skip setting makeprg if makefile exists

Sometimes I want to use :make to use Makefile instead of a single plantuml command. So I made this to avoid setting makeprg if makefile exists in the current directory.
Thank you.

Hello @diginatu I don't like checking for a specific file name as other tools than make can be used in the makeprg.  How about having a setting that prevents the makeprg from being set instead?

@aklt  Thank you for your reply.
I see. I was thinking to make a setting at first. I'll close this and recreate a PR.


Fix GolangCI-Lint warnings

🔧 Changes

Fix GolangCI-Lint warnings

📚 References

🔬 Testing

📝 Checklist

[x] All new/changed/fixed functionality is covered by tests (or N/A)
[x] I have added documentation for all new/changed functionality (or N/A)

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

Project coverage is 95.37%. Comparing base (ec52c3e) to head (fdc6dee).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #412   +/-   ##
=======================================
  Coverage   95.37%   95.37%
=======================================
  Files          47       47
  Lines        7610     7610
=======================================
  Hits         7258     7258
  Misses        235      235
  Partials      117      117

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


🐛 BUG: Unable to wrangler pages publish to production env

What version of Wrangler are you using?
2.0.5
What operating system are you using?
Macos
Describe the Bug
It does not seem possible to run wrangler pages publish against the production environment.
wrangler pages publish --env production

returns
 [ERROR] Unknown argument: env

Looking at the dashboard, running wrangler pages publish --env production seems to deploy in the "preview" environment

Hi @Barre ,
The environment for a Pages deployment is determined by the branch used. By default this will pick up from your git workspace if you're in one, but you can also specify this manually with the wrangler pages publish ./dir --branch=foo argument. When the branch name matches that of your project's production branch, you'll create a production deployment.