feat(factory): emit SequencerOracleUpdated on contract creation

https://linear.app/autonomysoftware/issue/BAC-26/analyse-untracked-state-variables-in-smart-contracts
sequencerOracle state variable has an update event but it wasn't emitted on contract creation.

After the call with @TomasCImach it was decided to close this PR


Remove an used dnx command

Based on issue #50, I notice that install-sqlservercache command is never used

/cc @kichalla

:shipit:


chore: update SHA for RingTheory.Subring.Basic

<EMAIL_ADDRESS>
This fix was already synced in #1832

bors r+


Add contract address + filtering to PredictPrediction

To calculate accuracy for an asset, we would need to get all PredictPrediction events by contract address, and then calculate the average for each slot with the values inside predictPredictions[].slot.predictions[].
We are planning to calculate the accuracy of each slot by looking at payout, and using a stake-weighted average.
{
        "id": "0x1456c74c421d46af30ef3c8a4f142d2f713ae325-1692100800-0xe02a421dfc549336d47efee85699bd0a3da7d6ff",
        "slot": {
          "slot": "1692100800",
          "predictions": [
            {
              "user": {
                "id": "0xe02a421dfc549336d47efee85699bd0a3da7d6ff"
              },
              "stake": "0.75",
              "payout": null
            }
          ],
          "predictContract": {
            "id": "0x1456c74c421d46af30ef3c8a4f142d2f713ae325",
            }
          }
        },
      },

Tried like/in clauses, but i think we'll need to implement something

Berkay and Roberto discussed this yesterday. It's not needed because you can get the stake for up and stake for down. Therefore we can close this issue.


Deploy Checklist: New Expensify 2023-08-30

Release Version: 1.3.59-4
Compare Changes: https://github.com/Expensify/App/compare/production...staging
This release contains changes from the following pull requests:

[ ] https://github.com/Expensify/App/pull/20747
[x] https://github.com/Expensify/App/pull/21664
[x] https://github.com/Expensify/App/pull/23807
[ ] https://github.com/Expensify/App/pull/24098
[x] https://github.com/Expensify/App/pull/24111
[x] https://github.com/Expensify/App/pull/24173
[x] https://github.com/Expensify/App/pull/24369
[x] https://github.com/Expensify/App/pull/24405
[x] https://github.com/Expensify/App/pull/24411
[x] https://github.com/Expensify/App/pull/24414
[x] https://github.com/Expensify/App/pull/24440
[x] https://github.com/Expensify/App/pull/24479
[x] https://github.com/Expensify/App/pull/24493
[x] https://github.com/Expensify/App/pull/24541
[x] https://github.com/Expensify/App/pull/24542
[ ] https://github.com/Expensify/App/pull/24616
[x] https://github.com/Expensify/App/pull/25159
[x] https://github.com/Expensify/App/pull/25401
[x] https://github.com/Expensify/App/pull/25429
[x] https://github.com/Expensify/App/pull/25458
[x] https://github.com/Expensify/App/pull/25519
[x] https://github.com/Expensify/App/pull/25520
[x] https://github.com/Expensify/App/pull/25521
[x] https://github.com/Expensify/App/pull/25529
[x] https://github.com/Expensify/App/pull/25565
[x] https://github.com/Expensify/App/pull/25569
[x] https://github.com/Expensify/App/pull/25579
[x] https://github.com/Expensify/App/pull/25590
[x] https://github.com/Expensify/App/pull/25605
[x] https://github.com/Expensify/App/pull/25618
[x] https://github.com/Expensify/App/pull/25624
[x] https://github.com/Expensify/App/pull/25629
[x] https://github.com/Expensify/App/pull/25652
[x] https://github.com/Expensify/App/pull/25654
[x] https://github.com/Expensify/App/pull/25656
[x] https://github.com/Expensify/App/pull/25659
[x] https://github.com/Expensify/App/pull/25660
[x] https://github.com/Expensify/App/pull/25672
[x] https://github.com/Expensify/App/pull/25675
[x] https://github.com/Expensify/App/pull/25700
[x] https://github.com/Expensify/App/pull/25708
[x] https://github.com/Expensify/App/pull/25721
[x] https://github.com/Expensify/App/pull/25731
[x] https://github.com/Expensify/App/pull/25742
[x] https://github.com/Expensify/App/pull/25743
[x] https://github.com/Expensify/App/pull/25745
[x] https://github.com/Expensify/App/pull/25747
[x] https://github.com/Expensify/App/pull/25749
[x] https://github.com/Expensify/App/pull/25750
[x] https://github.com/Expensify/App/pull/25751
[x] https://github.com/Expensify/App/pull/25753
[x] https://github.com/Expensify/App/pull/25755
[x] https://github.com/Expensify/App/pull/25757
[x] https://github.com/Expensify/App/pull/25758
[x] https://github.com/Expensify/App/pull/25762
[x] https://github.com/Expensify/App/pull/25764
[x] https://github.com/Expensify/App/pull/25766
[x] https://github.com/Expensify/App/pull/25782
[x] https://github.com/Expensify/App/pull/25808
[ ] https://github.com/Expensify/App/pull/25815
[x] https://github.com/Expensify/App/pull/25816
[x] https://github.com/Expensify/App/pull/25825
[x] https://github.com/Expensify/App/pull/25826
[x] https://github.com/Expensify/App/pull/25828
[x] https://github.com/Expensify/App/pull/25831
[x] https://github.com/Expensify/App/pull/25832
[x] https://github.com/Expensify/App/pull/25840
[x] https://github.com/Expensify/App/pull/25842
[x] https://github.com/Expensify/App/pull/25844
[x] https://github.com/Expensify/App/pull/25847
[x] https://github.com/Expensify/App/pull/25848
[x] https://github.com/Expensify/App/pull/25849
[x] https://github.com/Expensify/App/pull/25858
[x] https://github.com/Expensify/App/pull/25861
[x] https://github.com/Expensify/App/pull/25862
[x] https://github.com/Expensify/App/pull/25866
[x] https://github.com/Expensify/App/pull/25873
[x] https://github.com/Expensify/App/pull/25876
[x] https://github.com/Expensify/App/pull/25882
[x] https://github.com/Expensify/App/pull/25900
[x] https://github.com/Expensify/App/pull/25907
[x] https://github.com/Expensify/App/pull/25911
[x] https://github.com/Expensify/App/pull/25912
[x] https://github.com/Expensify/App/pull/25914
[x] https://github.com/Expensify/App/pull/25915
[x] https://github.com/Expensify/App/pull/25916
[x] https://github.com/Expensify/App/pull/25917
[x] https://github.com/Expensify/App/pull/25918
[x] https://github.com/Expensify/App/pull/25919
[x] https://github.com/Expensify/App/pull/25921
[x] https://github.com/Expensify/App/pull/25923
[x] https://github.com/Expensify/App/pull/25924
[x] https://github.com/Expensify/App/pull/25943
[x] https://github.com/Expensify/App/pull/25944
[ ] https://github.com/Expensify/App/pull/25954
[x] https://github.com/Expensify/App/pull/25955
[x] https://github.com/Expensify/App/pull/25957
[x] https://github.com/Expensify/App/pull/25958
[x] https://github.com/Expensify/App/pull/25959
[x] https://github.com/Expensify/App/pull/25963
[ ] https://github.com/Expensify/App/pull/25969
[x] https://github.com/Expensify/App/pull/25974
[x] https://github.com/Expensify/App/pull/25981
[x] https://github.com/Expensify/App/pull/25984
[x] https://github.com/Expensify/App/pull/25986
[x] https://github.com/Expensify/App/pull/26023
[x] https://github.com/Expensify/App/pull/26035
[x] https://github.com/Expensify/App/pull/26042
[x] https://github.com/Expensify/App/pull/26045
[x] https://github.com/Expensify/App/pull/26055
[x] https://github.com/Expensify/App/pull/26056
[x] https://github.com/Expensify/App/pull/26057
[x] https://github.com/Expensify/App/pull/26081
[x] https://github.com/Expensify/App/pull/26095
[x] https://github.com/Expensify/App/pull/26100
[ ] https://github.com/Expensify/App/pull/26105
[x] https://github.com/Expensify/App/pull/26122
[x] https://github.com/Expensify/App/pull/26124
[x] https://github.com/Expensify/App/pull/26145
[ ] https://github.com/Expensify/App/pull/26153
[x] https://github.com/Expensify/App/pull/26163
[x] https://github.com/Expensify/App/pull/26168
[ ] https://github.com/Expensify/App/pull/26182
[x] https://github.com/Expensify/App/pull/26199
[x] https://github.com/Expensify/App/pull/26267
[ ] https://github.com/Expensify/App/pull/26293
[x] https://github.com/Expensify/App/pull/26296
[x] https://github.com/Expensify/App/pull/26305

Internal QA:

[ ] https://github.com/Expensify/App/pull/26292 - @youssef-lr
[x] https://github.com/Expensify/App/pull/25827 - @Beamanator
[ ] https://github.com/Expensify/App/pull/24639 - @youssef-lr
[ ] https://github.com/Expensify/App/pull/23063 -

Deploy Blockers:

[ ] https://github.com/Expensify/App/issues/26319
[ ] https://github.com/Expensify/App/issues/26322
[ ] https://github.com/Expensify/App/issues/26324

Deployer verifications:

[ ] I checked the App Timing Dashboard and verified this release does not cause a noticeable performance regression.
[ ] I checked Firebase Crashlytics and verified that this release does not introduce any new crashes. More detailed instructions on this verification can be found here.
[ ] I checked GitHub Status and verified there is no reported incident with Actions.

cc @Expensify/applauseleads

:rocket: All staging deploys are complete, @Expensify/applauseleads please begin QA on version https://github.com/Expensify/App/releases/tag/1.3.59-0 :rocket:

@luacmartins We will start regression in the morning
Checking off below as they were previously deployed and already in PROD.
https://github.com/Expensify/App/pull/23807
https://github.com/Expensify/App/pull/24111
https://github.com/Expensify/App/pull/24173
https://github.com/Expensify/App/pull/24405
https://github.com/Expensify/App/pull/24414
https://github.com/Expensify/App/pull/24479
https://github.com/Expensify/App/pull/24493
https://github.com/Expensify/App/pull/24541
https://github.com/Expensify/App/pull/24542
https://github.com/Expensify/App/pull/25401
https://github.com/Expensify/App/pull/25429
https://github.com/Expensify/App/pull/25458
https://github.com/Expensify/App/pull/25519
https://github.com/Expensify/App/pull/25521
https://github.com/Expensify/App/pull/25529
https://github.com/Expensify/App/pull/25565
https://github.com/Expensify/App/pull/25579
https://github.com/Expensify/App/pull/25590
https://github.com/Expensify/App/pull/25605
https://github.com/Expensify/App/pull/25618
https://github.com/Expensify/App/pull/25624
https://github.com/Expensify/App/pull/25652
https://github.com/Expensify/App/pull/25654
https://github.com/Expensify/App/pull/25659
https://github.com/Expensify/App/pull/25660
https://github.com/Expensify/App/pull/25672
https://github.com/Expensify/App/pull/25675
https://github.com/Expensify/App/pull/25700
https://github.com/Expensify/App/pull/25708
https://github.com/Expensify/App/pull/25742
https://github.com/Expensify/App/pull/25743
https://github.com/Expensify/App/pull/25757
https://github.com/Expensify/App/pull/25758
https://github.com/Expensify/App/pull/25762
https://github.com/Expensify/App/pull/25782
https://github.com/Expensify/App/pull/25816
https://github.com/Expensify/App/pull/25847
https://github.com/Expensify/App/pull/25866
https://github.com/Expensify/App/pull/25873
https://github.com/Expensify/App/pull/25876
https://github.com/Expensify/App/pull/25882
https://github.com/Expensify/App/pull/25900
https://github.com/Expensify/App/pull/25907
https://github.com/Expensify/App/pull/25911
https://github.com/Expensify/App/pull/25912
https://github.com/Expensify/App/pull/25914
https://github.com/Expensify/App/pull/25921
https://github.com/Expensify/App/pull/25924
https://github.com/Expensify/App/pull/25955
https://github.com/Expensify/App/pull/25957
https://github.com/Expensify/App/pull/25958
https://github.com/Expensify/App/pull/25959
https://github.com/Expensify/App/pull/25981
https://github.com/Expensify/App/pull/25986
https://github.com/Expensify/App/pull/26042
https://github.com/Expensify/App/pull/26045
https://github.com/Expensify/App/pull/26055
https://github.com/Expensify/App/pull/26057

Checking off internal QA ro https://github.com/Expensify/App/pull/25827

Checking of this deploy blocker which is not a bug https://github.com/Expensify/App/issues/26287#issuecomment-1699230160

Blocker https://github.com/Expensify/App/pull/26157 was fixed here and is currently being CP'd. Once complete I'll check it off

The post-CP build just completed and version 1.3.59-1 is ready to test on all platforms (Android was fixed 🎉 )

Checking off https://github.com/Expensify/App/issues/26273. Demoted to NAB

Checking off https://github.com/Expensify/App/issues/26282. Demoted to NAB

Checking off https://github.com/Expensify/App/issues/26286. Demoted to NAB

Checking off https://github.com/Expensify/App/issues/26288. We merged/CPed a fix.

Checking off https://github.com/Expensify/App/issues/26289. We merged/CPed a fix.

Checking off https://github.com/Expensify/App/issues/26311. Not an issue.

Checking off https://github.com/Expensify/App/pull/26292. We tested on staging and it's a pass.

@luacmartins We are finishing up regression
Current summary
https://github.com/Expensify/App/pull/20747 - pending validation on all platforms
https://github.com/Expensify/App/pull/23063 is failing https://github.com/Expensify/App/issues/26291
https://github.com/Expensify/App/pull/24616 - pending validation on all platforms
https://github.com/Expensify/App/pull/25815 - pending validation on all platforms
https://github.com/Expensify/App/pull/25954 - PROD QA , ok to check off?
https://github.com/Expensify/App/pull/25969 is failing https://github.com/Expensify/App/issues/26313, repro in PROD.
Also we are not able to validate PR on Native apps. Ok to check off?
https://github.com/Expensify/App/pull/26182 is failing https://github.com/Expensify/App/issues/26289
https://github.com/Expensify/App/pull/26105#issuecomment-1698484976 do we need to QA?
https://github.com/Expensify/App/pull/26293 - pending validation on all platforms

Checking off https://github.com/Expensify/App/issues/26314. Repro in prod.

Checking off https://github.com/Expensify/App/issues/26319. Demoted to NAB.

@mvtglobally thanks for the update! I checked off the applicable PRs. I also asked for internal validation of https://github.com/Expensify/App/pull/26182

Checking off https://github.com/Expensify/App/issues/26322. We merged/CPed a fix.

 Demoted to NAB since I can repro in prod.

Checklist is clear. Kicking off the deploy.

:shipit:


Send storage capacity as "openebs.io/capacity" from openebs provisioner

Is this a BUG REPORT
BUG REPORT

What happened:
Currently openebs provisioner is sending capacity as a volumeprovisioner.mapi.openebs.io/storage-size
What you expected to happen:
Send storage capacity as "openebs.io/capacity" from openebs provisioner

m-apiserver is made backward compatible to handle the old and new format for taking the capacity parameter. This needs to be updated though before the older labels are deprecated in the upcoming releases.

As part of 0.7 refactoring to use CAS based provisioning, capacity is sent using the types structured shared between -- maya-apiserver and provisioner.


Feature request: Escape key should not exit zen mode, Ctrl+W should not exit VSCode

While I'm editting in Zen mode I may open a search dialog, and then after finding something I may make a selection and hit Ctrl+D a bunch of times to select throughout the document and finally I will make my edits. To return to a single cursor state with the find window closed I usually hit escape 5 or 6 times in sequence. In regular mode this is not an issue, in Zen mode this drops me out of zen mode entirely. Can we get an option to disable the "escape zen mode" keyboard shortcut? I feel leaving Zen mode should be a more deliberate action.
In addition while I'm editting in VSCode in Zen mode, I may have multiple files open in the same tab. Eventually I get to a point where I feel comfortable closing out all of those files and starting from a clean slate. In this case I'll rapidly hit Ctrl+W and watch the files disappear, however unexpectedly when I hit Ctrl+W with no tabs open VSCode shutsdown entirely. I don't know of any other program that does this, except for maybe chrome where no tabs = no program. I feel this should be rectified entirely (not just hidden behind an option).
VSCode is awesome, thanks so much for building and maintaining it.

Slack closes with Ctrl+W

You can change shortcuts by yourself

Thanks @King66. Yes, you can customize the keybindings for these actions.
@klick-barakgall  Let me know if this does not solve the problem

I feel dumb. This is awesome. I should have known that these were separate actions in the keybindings. I learn something new about VSCode everyday and it's always pleasant. Thanks again!


Sea of Thieves doesn't work

So steamless won't extract SoT and won't tell me why. Any solutions or ways to try and fix this?
Let me know if I should just close this; I thought I might put one here because steamless is unactive

Steamless removes SteamStub DRM. Sea of theives uses its own in-house DRM alongside Microsofts DRM for Online Games.

Steamless also doesn't extract games it only removes the SteamStub DRM nothing more.

That makes sense given it's Xbox, probably should've put two and two together. Do you have any place I could find the key or any method to?

Luckily, I own SoT.
The AES Key should be: 0x37A0BC3DC2E01D9EB4923CA266A5701F56A4802347F07927FC3FC25C93B31B50.
If the key doesn't work, you might want to try another Guide or AES Key Extractor. @GHFear iirc has an updated executable that will and should work better.

Is it AES dumpster?

Luckily, I own SoT. The AES Key should be: 0x37A0BC3DC2E01D9EB4923CA266A5701F56A4802347F07927FC3FC25C93B31B50.
If the key doesn't work, you might want to try another Guide or AES Key Extractor. @GHFear iirc has an updated executable that will and should work better.

Try running my AESDumpster tool and see if you get that key. If not, DM me on Discord.

Is it AES dumpster?

yes

No keys to be found or a problem occurred.
I also don't have Discord (personal reasons)

Can't cause of the following

Can't cause of the following

aah yeah. I will dm Cracko.

thanks ;)


fix/dont use router in uniswaplp

Before submitting this PR, please make sure:

[X] Your code builds clean without any errors or warnings
[X] You are using approved title ("feat/", "fix/", "docs/", "refactor/")

A description of the changes proposed in the pull request:

May fix https://github.com/hummingbot/gateway/issues/152

Tips for QA testing:

Please run Gateway from source and test adding liquidity

Test performed:
Cloned and install: fix PR gw branch + Client - latest development branch
Created/started uniswapLP startegy using uniswap arbitrum successfully and WETH-USDC.E pair
bot returned error One of the tokens in this position isn't recognized
However Reviewed liquidity added successfully ✅
Created/started uniswapLP startegy using uniswap arbitrum successfully and WETH-ARB pair
bot returned error One of the tokens in this position isn't recognized
However Reviewed liquidity added successfully ✅
logs_gateway_app.log
logs_conf_uniswap_v3_lp_1.log
logs_unilp2.log
gw153.zip
2023-07-12 05:26:13,712 - 218157 - GatewayEVMAMMLP - INFO - Created ADD liquidity order add-WETH-USDC.E-1689139570209342 txHash: 0x3e7c326316df003591835b6ef0a9e39fb29efbcb51f064ce198bca9775a25d86 on arbitrum_one. Estimated Gas Cost: 0.000015069000000000  (gas limit: 3000000, gas price: 0.1000000000000000055511151231257827021181583404541015625)
2023-07-12 05:26:13,713 - 218157 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.0, "order_id": "add-WETH-USDC.E-1689139570209342", "exchange_order_id": "0x3e7c326316df003591835b6ef0a9e39fb29efbcb51f064ce198bca9775a25d86", "order_action": "LPType.ADD", "trading_pair": "WETH-USDC.E", "fee_tier": "LOW", "lower_price": "1790.288903791500000", "upper_price": "1978.740367348500000", "amount": "0.005000", "creation_timestamp":<PHONE_NUMBER>.0, "token_id": 0, "event_name": "RangePositionUpdateEvent", "event_source": "uniswapLP_ethereum_arbitrum_one"}
2023-07-12 05:26:14,265 - 218157 - GatewayEVMAMMLP - INFO - Liquidity added for position with ID 719713.
2023-07-12 05:26:14,275 - 218157 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.0, "order_id": "add-WETH-USDC.E-1689139570209342", "exchange_order_id": "0x3e7c326316df003591835b6ef0a9e39fb29efbcb51f064ce198bca9775a25d86", "trading_pair": "WETH-USDC.E", "lower_price": "1790.288903791500000", "upper_price": "1978.740367348500000", "amount": "0", "fee_tier": "LOW", "creation_timestamp":<PHONE_NUMBER>.0, "trade_fee": {"percent": "0", "percent_token": null, "flat_fees": [{"token": "ETH", "amount": "0.0001003772000000000055720539294"}]}, "token_id": 719713, "event_name": "RangePositionLiquidityAddedEvent", "event_source": "uniswapLP_ethereum_arbitrum_one"}
2023-07-12 05:26:15,214 - 218157 - GatewayEVMAMMLP - ERROR - Error on POST https://localhost:15888/amm/liquidity/position Error: {'message': 'Unknown error.', 'httpErrorCode': 503, 'errorCode': 1099, 'stack': "Error: One of the tokens in this position isn't recognized.\n    at UniswapLP.<anonymous> (/home/nikita/gwfixlp/dist/src/connectors/uniswap/uniswap.lp.js:76:23)\n    at Generator.next (<anonymous>)\n    at fulfilled (/home/nikita/gwfixlp/dist/src/connectors/uniswap/uniswap.lp.js:28:58)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)"}
Traceback (most recent call last):
  File "/home/nikita/development/hummingbot/connector/gateway/amm_lp/gateway_evm_amm_lp.py", line 1097, in _status_polling_loop
    await safe_gather(
  File "/home/nikita/development/hummingbot/core/utils/async_utils.py", line 22, in safe_gather
    return await asyncio.gather(*args, **kwargs)
  File "/home/nikita/development/hummingbot/connector/gateway/amm_lp/gateway_evm_amm_lp.py", line 970, in update_nft
    raise nft_update_result
  File "/home/nikita/development/hummingbot/core/gateway/gateway_http_client.py", line 798, in amm_lp_position
    return await self.api_request("post", "amm/liquidity/position", request_payload)
  File "/home/nikita/development/hummingbot/core/gateway/gateway_http_client.py", line 218, in api_request
    raise e
  File "/home/nikita/development/hummingbot/core/gateway/gateway_http_client.py", line 206, in api_request
    raise ValueError(f"Error on {method.upper()} {url} Error: {parsed_response}")
ValueError: Error on POST https://localhost:15888/amm/liquidity/position Error: {'message': 'Unknown error.', 'httpErrorCode': 503, 'errorCode': 1099, 'stack': "Error: One of the tokens in this position isn't recognized.\n    at UniswapLP.<anonymous> (/home/nikita/gwfixlp/dist/src/connectors/uniswap/uniswap.lp.js:76:23)\n    at Generator.next (<anonymous>)\n    at fulfilled (/home/nikita/gwfixlp/dist/src/connectors/uniswap/uniswap.lp.js:28:58)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)"}
2023-07-12 05:26:16,207 - 218157 - GatewayEVMAMMLP - ERROR - Error on POST https://localhost:15888/amm/liquidity/position Error: {'message': 'Unknown error.', 'httpErrorCode': 503, 'errorCode': 1099, 'stack': "Error: One of the tokens in this position isn't recognized.\n    at UniswapLP.<anonymous> (/home/nikita/gwfixlp/dist/src/connectors/uniswap/uniswap.lp.js:76:23)\n    at Generator.next (<anonymous>)\n    at fulfilled (/home/nikita/gwfixlp/dist/src/connectors/uniswap/uniswap.lp.js:28:58)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)"}
Traceback (most recent call last):
  File "/home/nikita/development/hummingbot/connector/gateway/amm_lp/gateway_evm_amm_lp.py", line 1097, in _status_polling_loop
    await safe_gather(
  File "/home/nikita/development/hummingbot/core/utils/async_utils.py", line 22, in safe_gather
    return await asyncio.gather(*args, **kwargs)
  File "/home/nikita/development/hummingbot/connector/gateway/amm_lp/gateway_evm_amm_lp.py", line 970, in update_nft
    raise nft_update_result
  File "/home/nikita/development/hummingbot/core/gateway/gateway_http_client.py", line 798, in amm_lp_position
    return await self.api_request("post", "amm/liquidity/position", request_payload)
  File "/home/nikita/development/hummingbot/core/gateway/gateway_http_client.py", line 218, in api_request
    raise e
  File "/home/nikita/development/hummingbot/core/gateway/gateway_http_client.py", line 206, in api_request
    raise ValueError(f"Error on {method.upper()} {url} Error: {parsed_response}")
ValueError: Error on POST https://localhost:15888/amm/liquidity/position Error: {'message': 'Unknown error.', 'httpErrorCode': 503, 'errorCode': 1099, 'stack': "Error: One of the tokens in this position isn't recognized.\n    at UniswapLP.<anonymous> (/home/nikita/gwfixlp/dist/src/connectors/uniswap/uniswap.lp.js:76:23)\n    at Generator.next (<anonymous>)\n    at fulfilled (/home/nikita/gwfixlp/dist/src/connectors/uniswap/uniswap.lp.js:28:58)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)"}
2023-07-12 05:26:17,191 - 218157 - GatewayEVMAMMLP - ERROR - Error on POST https://localhost:15888/amm/liquidity/position Error: {'message': 'Unknown error.', 'httpErrorCode': 503, 'errorCode': 1099, 'stack': "Error: One of the tokens in this position isn't recognized.\n    at UniswapLP.<anonymous> (/home/nikita/gwfixlp/dist/src/connectors/uniswap/uniswap.lp.js:76:23)\n    at Generator.next (<anonymous>)\n    at fulfilled (/home/nikita/gwfixlp/dist/src/connectors/uniswap/uniswap.lp.js:28:58)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)"}
Traceback (most recent call last):
  File "/home/nikita/development/hummingbot/connector/gateway/amm_lp/gateway_evm_amm_lp.py", line 1097, in _status_polling_loop
    await safe_gather(
  File "/home/nikita/development/hummingbot/core/utils/async_utils.py", line 22, in safe_gather
    return await asyncio.gather(*args, **kwargs)
  File "/home/nikita/development/hummingbot/connector/gateway/amm_lp/gateway_evm_amm_lp.py", line 970, in update_nft
    raise nft_update_result
  File "/home/nikita/development/hummingbot/core/gateway/gateway_http_client.py", line 798, in amm_lp_position
    return await self.api_request("post", "amm/liquidity/position", request_payload)
  File "/home/nikita/development/hummingbot/core/gateway/gateway_http_client.py", line 218, in api_request
    raise e
  File "/home/nikita/development/hummingbot/core/gateway/gateway_http_client.py", line 206, in api_request
    raise ValueError(f"Error on {method.upper()} {url} Error: {parsed_response}")
ValueError: Error on POST https://localhost:15888/amm/liquidity/position Error: {'message': 'Unknown error.', 'httpErrorCode': 503, 'errorCode': 1099, 'stack': "Error: One of the tokens in this position isn't recognized.\n    at UniswapLP.<anonymous> (/home/nikita/gwfixlp/dist/src/connectors/uniswap/uniswap.lp.js:76:23)\n    at Generator.next (<anonymous>)\n    at fulfilled (/home/nikita/gwfixlp/dist/src/connectors/uniswap/uniswap.lp.js:28:58)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)"}

Wow thats good! will this fix also remove liquidity?

Bot Client do not have this feature currently @emusol

Bot Client do not have feature to remove liquidity from UniswapLP currently @emusol

gateway had this functionality, I have custom script utilizing it successfully before the issue with uniswaplp started

@emusol Could you please share the script for further testing?

Tried to remove with curl command:
remove liquidity
curl -s -X POST -k --key $GATEWAY_KEY --cert $GATEWAY_CERT -H "Content-Type: application/json" -d "$(envsubst < ./requests/eth_uniswap_position.json)" https://localhost:15888/amm/liquidity/remove | jq

Got same issue: One of the tokens in this position isn't recognized

Created issue for removing liquidity as it also exist for the latest development branch
https://github.com/hummingbot/gateway/issues/154


Check performance and potential optimisations of products/targets queries

Related to the new Package page query in #2531.

We can't actually merge the two Joined4 queries that collect the products and targets from their respective tables - or at least not in a way that would help. If we make it a Joined5 we'd blow up the result set to N x M just to save a query.
For example, Soto has 348 products and 349 targets and therefore the Joined5 has 121,452 rows. Of course, Soto is the extreme but it's also just simpler in terms of implementation. We're not gaining anything here.


[Rust] Cargo test failed

Thank you for reporting the problem!
Please make sure what you are reporting is a bug with reproducible steps.
Describe the bug
A clear and concise description of what the bug is.

Expected behavior
A clear and concise description of what you expected to happen.
To Reproduce
Steps to reproduce the behavior.
Please try to provide a reproducible script.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):
Please specify the versions of Fury, OS, and others such as JDK/Python/Gcc/Clang/Go/NodeJS if they are used.

@caicancai  The cause of this bug is that I removed the native skip when checking the language flag. I added it back and the cargo test ran successfully. However, the cause of the error that broke the CI pipeline still needs to be investigated."


Windmill issues

Hi,
I've been playing around with BWM in creative today and found some issues with the windmills.

If I place a column of 7+ axles (say, 8-10), tapping one of the upper axle blocks with a vertical mill usually results in the "too few vertical axles" error. However if I tap one of the lower ones, it will recognise and place the mill. However...

When the vertical mill is placed, it looks like a regular mill and it doesn't turn.

When a regular mill (with horizontal gearbox) nearby, ONE blade of the vertical mill rotates in sync with the regular mill! There are no particles coming from the gearbox and if closer than about 12 blocks, the rotation stops.

Additional axles can be placed on or perpendicular to a regular mill's main axle and additional mills can be placed on those axles. The resulting contraption is awe-inspiring, if slightly unwieldy :-)

While I'm writing this, it started raining and the gearbox disintegrated. I'm assuming this is intended. What's probably not intended is that the mills are still suspended in mid-air.

This image attempts to illustrate what's happening: http://i.imgur.com/Ij2KOan.png
Cheers!
BWM 0.13.1-1.10.2-hotfix3
Forge 2122
MC 1.10.2

4 and 5 are intended, I'm pretty sure. It's been that way in BTW iirc.
The other ones seem like quality beeto code =P

I'm not sure that 4 is intended. This is what I'm talking about: http://i.imgur.com/RAvVFSm.png
Physics, as much as some suspension of disbelief is required in Minecraft, don't work that way!
As to 5, I can believe the gearbox disintegrating is intended but I would've thought the attached mills should fall to the ground when it does.

Found what's going wrong with the vertical windmill placement, at least. Everything else will probably need to be looked at.


Bad URL for User stories and Basic API test cases link in kyc-match-API-Readiness-Checklist.md  and in kyc-fill-in-API-Readiness-Checklist.md

Problem description
Bad URL for User stories and Basic API test cases link in kyc-match-API-Readiness-Checklist.md  and in kyc-fill-in-API-Readiness-Checklist.md
https://github.com/camaraproject/KnowYourCustomer/blob/r1.3/documentation/API_documentation/documentation/API_documentation/KnowYourCustomer_User_Story.md
https://github.com/camaraproject/KnowYourCustomer/blob/r1.3/documentation/API_documentation/code/Test_definitions/kyc-match.feature
Expected behavior
remove documentation/API_documentation/ from the URL because twice

If we do a small release r1.4 fixing the test plan for v0.2.1 we can include this issue there and solve it. wdyt?


能否提供python版本呢？

Hello, I am also wondering if it is possible to provide the python version of SECTOR? Thank you.


v0.2.2 doesn't detect any devices; can't use 0.3

I can't use version 0.3 because my keyplus mini boards have version 0.2.2, and I don't have an avr programmer to update it. The keyplus app doesn't detect any devices. No error messages are shown.

For some reason, the 0.3 programmer works with my board running 0.2.2, is this supposed to happen?

You can update your 0.2.2 board to 0.3 from the firmware update section of keyplus flasher. The 0.3 flasher should work fine with 0.2 boards. Keyplus must have not released the USB device properly last time you closed it leading to your last error. Restarting your computer should fix it.

Can I update it if I don't have an AVR programmer?

Yes, just go to the firmware update tab, select your hex, and press program.

When I try to, I get this error:

Nothing is printed in the terminal.

Try press program again and it should work.  I think the device just took longer too enter its bootloader than expected.
If you are running from source, it will be a good idea to checkout the specific git commit for the version you are using. You can use git checkout v0.3.0, to checkout a specific version.
Like was mentioned before you should be able to use v0.3.0 to update the firmware hex.  Note on the rev3 controllers, I was meaning to bump the firmware version to v0.3.0 before I sent them out, but I forgot.  So they say they are v0.2.2 but should actually be v0.3.0. I'll make sure to add a note about this somewhere.

That worked, I forgot to close the issue.


feat(clerk-js): Route transitions

Description
https://github.com/clerk/javascript/assets/73396808/8a391aeb-0b34-41ec-bccf-2cf42d97b958

Checklist

[ ] npm test runs as expected.
[ ] npm run build runs as expected.
[ ] (If applicable) JSDoc comments have been added or updated for any package exports
[ ] (If applicable) Documentation has been updated

Type of change

[ ] 🐛 Bug fix
[ ] 🌟 New feature
[ ] 🔨 Breaking change
[ ] 📖 Refactoring / dependency upgrade / documentation
[ ] other:

Hey @octoper, your preview is currently deploying and should be available shortly.

Status
Preview
Updated (UTC)

:cook: Deploying...
Inspect
Feb 26, 2024 07:05 PM

!preview

This looks really promising. Closing this one as it could turn out to be a different project! Thank you @desiprisg!


⚠ Bofrost.de has degraded performance

In a9f0063, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1679 ms

Resolved: Bofrost.de performance has improved in 573a95d.


KeyFrame Pose Update

Hi, @Zzh2000:
Thank you for a great job. I find that after BA, the keyframe's pose will be updated accordingly, while it doesn't update the pose in self.estimate_c2w_list.  Will it lead to an inferior result compared to the situation if we also update the pose in self.estimate_c2w_list? Since I notice the eval_ate.py uses the self.estimate_c2w_list for evaluation.

Hi!
Yeah, I also think if the non-keyframe pose is also updated after BA, the tracking results can be even better.


Tests for ReduceDatasetOp

This PR adds the tests for ReduceDatasetOp.
cc:@jsimsa

Internal run of the test segfaults with:
[ RUN      ] ReduceDatasetOpTest/ParameterizedReduceDatasetOpTest.Compute/2
*** SIGSEGV, see go/general-protection-fault received by PID 5524 (TID 5597); stack trace: ***
PC: @     0x7f3c0abd0f23  (unknown)  tensorflow::TensorShapeRep::DebugString()
    @     0x7f3c04a77393       1680  FailureSignalHandler()
    @     0x7f3c042b49a0    3252080  (unknown)
    @     0x5644f6326559        896  std::__g::_Function_handler<>::_M_invoke()
    @     0x7f3c0ab15e7b        144  tensorflow::data::BackgroundWorker::WorkerLoop()
    @     0x7f3c0572c401        208  Thread::ThreadBody()
    @     0x7f3c042ac4e8        176  start_thread
    @     0x7f3c040e722d  (unknown)  clone

@jsimsa Thanks for the log details! The error happens here. It is caused by that the size of output_shapes_ is smaller than the size of state. This commit(https://github.com/tensorflow/tensorflow/pull/28793/commits/a9ea9782d6db3623ceffac178f49bc67d45528de) is submitted to correct the output_shapes in the test case, and also adds the size check for output_shapes_, output_dtypes, and state. Could you please have a look at the changes?


Error: Function converted via 'toJS'

Hi when update flutter to  Flutter  3.27.0 , i have multiple error with  Error: Function converted via 'toJS'.
for example
media_stream_track_impl.dart:13:68: Error: Function converted via 'toJS' contains invalid types in its function signature: '*dynamic* Function(*dynamic*)'.

https://github.com/flutter-webrtc/dart-webrtc/pull/54/commits/f27d27c7af41ceeebe31b295af4fb38e7b4d793e fixes this for me.
so for the time being i use:
dependency_overrides:
  dart_webrtc:
    git:
      url: https://github.com/flutter-webrtc/dart-webrtc.git
      ref: f27d27c7af41ceeebe31b295af4fb38e7b4d793e

here is PR https://github.com/flutter-webrtc/dart-webrtc/pull/54 for this error

+1 on this

i'm getting this
../../../.pub-cache/hosted/pub.dev/dart_webrtc-1.4.9/lib/src/rtc_data_channel_impl.dart:34:11: Error: Function converted via 'toJS' contains invalid types in its function signature: 'Future Function(MessageEvent)'.
Use one of these valid types instead: JS types from 'dart:js_interop', ExternalDartReference, void, bool, num, double, int, String, extension types that erase to one of these types, '@staticInterop' types, 'dart:html' types when compiling to JS, or a type parameter that is a subtype of a valid non-primitive type.
}.toJS,


Add option "set brightness from built-in display"

Before opening the issue, have you...?

[X] Searched for existing issues

Is your feature request related to a problem? Please describe
When I connect an external monitor to my MacBook, the brightness can be very different. It is very uncomfortable.
Describe the solution you'd like
Add option "set brightness from built-in display".
With this option, the brightness value must be copied from the built-in display after connecting.
Also, you can add "offset brightness" - is the constant that increases/decreases the built-in display brightness value.
Describe alternatives you've considered
no
Anything else?
No response

You can enable "Attempt to read display" in "Upon startup or wake". If your display is set to the right brightness upon startup. Syncing from the built-in display would need a way to properly correlate/map the varying external and internal display brightnesses, that's why MonitorControl syncs only the changes, not the absolute values.

@waydabber I have enabled this setting. But that's different. I want to synchronize brightness value from built-display after connecting to MacBook.
For example:
I worked during the day and the brightness of the monitor was 100%. Then I disconnect the MacBook from the monitor and have worked without it. At night I have connected the MacBook to the monitor and the brightness on the monitor was at 100%.
There is already a very cool "sync change brightness" option, but "sync when connected" is very needed.

Yes, I understand. A feature like this could be implemented however it will not work that well due to the brightness differences (a brightness of 50% means something totally different in term of nits for the internal display and various external displays).

@waydabber I have MacBook Pro M1 16 and Philips 288E2A. When I have enabled "combine software and hardware dimming", displays look ~ same on different brightness values. With "auto sync brightness from built-in display" it's very comfortable. But issues on startup "killing my eyes".

100/100

50/50

25/25

25/100

I think that differences in brightness/nits can be ~ corrected with "startup delta value".

In "sync brightness with built-in display" you are not thinking about differences in brightness/nits - just changing value with calculated delta value. I suggest just adding "startup delta value" (as an option) and after startup sync brightness value from the built-in display with this delta value.

Yes, we can work something out, but might need a thoughtful approach to improve syncing experience and allow for absolute syncing in general. I added it as a feature request.

thanks. sounds great.

"Absolute" syncing would be great! I've never been in a situation where I wanted different a brightness on each display.
Currently my MacBook and Dell displays have pretty much identical brightness as long as each OSD shows the same number of chiclets (thanks to the combined hardware & software dimming). But they get out of sync throughout the day, for example after waking from sleep.

@patrickrushton - absolute syncing is rather difficult especially if you want to match different display brightnesses. Some sort of calibration process should be involved and also a decision must be made what to do with the excess low/high range of some display. Absolute syncing would also reduce the brightness range to the most limited device.


WIP adding traffic-destination

** DO NOT MERGE **
Just adding this PR for observability of this work, I am currently defining traffic-destination which is based round Istio's DestinationRule and Consul's Service Resolver.

Hmm, what problem are you trying to solve? The Istio one looks like a bunch of LB config and the Consul one appears to fill a similar role to k8s services and endpoints?

Hi @grampelberg @nicholasjackson - how do you feel about an issue for further discussion, instead of this PR? This PR doesn't look like we're actively working on it or are going to merge it soon.


Galm/consumer filters

In consumer Activity explorer:

Added Tagging filtering mechanism
Added static filtering via sidebar
https://www.loom.com/share/7331527c5d4242d9aa53bef18e42e6b9

great code!
fixed a minor bug in ActivityFilter & will merge soon!
@galmoyal88


[solution] uk/easy-unshift

Challenge [easy-unshift]
Checklist

[ ] Make sure that you are opening the PR with a single solution (one solution per PR)
[ ] The solution must have at least several references for the readers to dive in depth

error:
internally linking to ./easy-push.md, which does not exist (line 110)
easy push should be merged first


SNIP13: index ERC20 event fields

Events in Starknet consist of two felt arrays, keys and data, the former is analogous to topics on Ethereum. Similarly to Ethereum, Starknet’s json-rpc allows you to filter over event keys via the starknet_getEvents method.
In this SNIP we suggest updating StarkGate's ERC20s (including ETH, STRK, USDC and others) to index more fields the Transfer and Approval events in order to allow filtration over the sender or receiver.

Should be changed "to index more fields in the..."

making ERC20 Transfer and Approval events index these fields should be part of SNIP-2 instead of creating a new snip targeted at StarkGate tokens no?
in fact, this PR fixes this in the ERC20 standard (among other things) https://github.com/starknet-io/SNIPs/pull/83

Need to further investigate this change on fees and disk usage of full nodes.

@ArielElp it's ok to have it discussed in a separate snip explicitly but you should align the actual change of adding the missing events to StarkGate ERC20 tokens with this PR https://github.com/starknet-io/SNIPs/pull/83
Effectively all snip-2 (erc-20) compatible token contracts should emit these events


Investigate Merging Makefiles for SGX demo and test

The duplicate enclave build commands in sgx/demo/Makefile and sgx/test/Makefile are annoying to keep up to date.
This issue recommends potentially merging them to avoid the issues with maintaining duplicated build specifications.

Closed with #158


add ushie.dev

!!! hi afn

if possible merge this before others (if there are any PRs made by the time you get to this) so I can be next to afn

I was not able to find any usage of Lanyard on your site, remember this list is only if you use Lanyard in some capacity.

I was not able to find any usage of Lanyard on your site, remember this list is only if you use Lanyard in some capacity.
If there is something I'm missing, I'll leave this open so you can fix or let me know if I need to close.

The hero image and the name in the hero title are both via Lanyard, there is also an RPC but I temporarily disabled that for now till I fix mobile responsiveness

oh actually, I just checked the github and I just realised I didn't push those lanyard stuff yet 💀 I guess I kept them as local changes for like over a month, should I mention you when I push it?

@dustinrouillard should be up now


Update aws-core, http-client-spi, ... to 2.16.49

Updates

software.amazon.awssdk:aws-core
software.amazon.awssdk:http-client-spi
software.amazon.awssdk:netty-nio-client

from 2.16.48 to 2.16.49.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "software.amazon.awssdk" } ]

labels: library-update, semver-patch

Superseded by #341.


Add per-lang to react-scripts webpack builds.

Approach
Use dynamic imports from each locales/index.js to import the json file for the current locale (as well as english as a backup) and add those strings to i18next via zion-locale's addTranslations function.
This replaces our dependency on alienfast's loader. We may want to reach out to them with this implementation as they are interested in something like this: https://github.com/alienfast/i18next-loader/issues/6

So is this the only change needed to get per-lang? Or are there other changes/PRs that would accompany this?

So is this the only change needed to get per-lang? Or are there other changes/PRs that would accompany this?

I think we need some kind of a README or a big comment/doc explaining how this works, but not sure where to put it

I think we need some kind of a README or a big comment/doc explaining how this works, but not sure where to put it

@redbugz I agree, I'm happy to work on that README wherever we decide to put it. I'm currently working on adding the debounced addTranslations in zion-locale.

@redbugz I agree, I'm happy to work on that README wherever we decide to put it. I'm currently working on adding the debounced addTranslations in zion-locale.

@redbugz here's the other PR: https://github.com/fs-webdev/zion/pull/2365

@redbugz here's the other PR: https://github.com/fs-webdev/zion/pull/2365

I added a placeholder README, let's start there and see where we end up.

I added a placeholder README, let's start there and see where we end up.

This is not longer building locally for me, now failing with:
Module parse failed: Unexpected token i in JSON at position 1 while parsing near '
import i18n from 'i1...'
File was processed with these loaders:
 *<EMAIL_ADDRESS>You may need an additional loader to handle the result of these loaders.
SyntaxError: Unexpected token i in JSON at position 1 while parsing near '
import i18n from 'i1...'
    at JSON.parse (<anonymous>)

This is not longer building locally for me, now failing with:
Module parse failed: Unexpected token i in JSON at position 1 while parsing near '
import i18n from 'i1...'
File was processed with these loaders:
 *<EMAIL_ADDRESS>You may need an additional loader to handle the result of these loaders.
SyntaxError: Unexpected token i in JSON at position 1 while parsing near '
import i18n from 'i1...'
    at JSON.parse (<anonymous>)

Here is an error that I get, it's not fatal, caused by a dependency that doesn't have all the translations loaded yet, but it hightlights that errors are hard to track down as we currently don't get context of where the error occurred:
failed to load translation - ru" + "translation"

I had to dive into the source code and log out the file paths to know which dependency/path was causing this error, it would be nice if it was in the error message

Here is an error that I get, it's not fatal, caused by a dependency that doesn't have all the translations loaded yet, but it hightlights that errors are hard to track down as we currently don't get context of where the error occurred:
failed to load translation - ru" + "translation"

I had to dive into the source code and log out the file paths to know which dependency/path was causing this error, it would be nice if it was in the error message

Yeah, I wasn't sure how much we wanted to know about the missing files. I'm fine with logging something else or not logging anything.

Yeah, I wasn't sure how much we wanted to know about the missing files. I'm fine with logging something else or not logging anything.

I'm seeing this issue. Not sure why yet. Everything is translated expect the tree subnav component.

I'm seeing this issue. Not sure why yet. Everything is translated expect the tree subnav component.

Oh, it's a rerender issue. When I click on Recents, it rerenders and gets the right language.

Oh, it's a rerender issue. When I click on Recents, it rerenders and gets the right language.

closing in favor of the "real-deal" PR that exists.


Uncaught exception from renderers

Prior to 4.19.0, exceptions thrown by plugins that hooked any of the bootstrap rendering events (e.g. beforeStartup, requireEnsure, etc.) were caught and the error message was added to compilation.errors.  This occurred because compilation.createChunkAssets() has a try/catch block that catches and processes exceptions thrown by the renderers.
Starting with 4.19.0, the bootstrap rendering code is now also called via compilation.createHash().  Any exceptions thrown by the rendering code from this call are not caught and the exceptions propagates up to node and the application is terminated.
This pr adds exception handling code to compilation.createHash() that is similar to what compilation.createChunkAssets() does so that  exceptions thrown by bootstrap rendering code will be handled in a similar way.

What kind of change does this PR introduce?
Improves exception handling

bugfix
Did you add tests for your changes?
yes

Does this PR introduce a breaking change?
no

What needs to be documented once your changes are merged?
no documentation needed

Thanks


Update documentation

This adds several pages to the documentation and cleans up some of the content. Installation, Usage, and Contributing pages are added. An Examples section has also been added along with a page that discusses the ImageMagick file example. Sphinx dependencies are added to the conda environment file.

@tskluzac I added some commands in the contributing document regarding building/viewing the documentation. Let me know if any more minor changes are needed; otherwise, this is good to merge.


plan to support cassandra 2.1 and on

I haven't seen any updates on cassandra driver compatibility page since May last year. Which astyanax version supports cassandra 2.1, 2.2 and 3.0+ versions?

Hi, the latest astyanax version only support 2.0.12. Seems the community have no plan to update it because there are no substantial code changes for months. I have asked this question in Cassandra mail list, two guys suggest to stay in 2.0 or migrate to Datastax Java Driver. FYI.


Reworked team page look and building process

Hello!
Pull request overview

Create web/_templates/team.html: A HTML format which is filled with data from a new file called web/team/team.json.
Created some css to go along with this new team page.
Updated web/conf.py to automatically generate the Team page upon Sphinx build.
Moved web/images folder to web/_static/images.

Note:
This PR is not ready for merging. It's a draft that requires work. Currently, it's filled with a bogus team which needs to be filled out.
Sample screenshot
Note that the data for this team is bogus, and that I zoomed the page out further than normal for a larger screenshot. I've provided this screenshot to give an overview of the page as it stands after building while checked out at this PR.

My name in the top left links to a personal website, while clicking on my photo or on my github username links you to my GitHub page. The same goes for all member cards.
Details
Our documentation/website builder Sphinx works with .rst files. However, such files do not provide the freedom which I'd like to have with the team page. My goal was simple: make the process of adding or updating the list of team members as simple as possible, while making the team page visually fit with the rest of the documentation. Another goal was to provide options for team members to show whatever information they want.
This required html files, which can be imported in ReST like:
.. raw:: html
   :file: team/current_team.html

I used this to embed HTML files within the website on the Team page. This looks very natural to the end user, as you can see in the screenshot.
That all said, it's crucial that updating the team page is not a pain.
That's why I've opted for a Mustache file. Such a file is an HTML template, that uses "tags" similarly to Jinja (if you're familiar with that) to generate full-blown HTML pages.
It allowed me to easily create a format file (team.mustache) which is filled with some data (team.json) to generate HTML pages which are used by Sphinx.
Edited:
I've now opted for Jinja2 instead, as I used that for creating the HOWTO pages as well. The new web/_templates/team.html is a HTML file with Jinja2 tags to generate HTML pages using team.json data.
Now, to further aid the process of automating the website build process, I've created a function in web/conf.py which generates these files before Sphinx places them in the final website.
In short, all we need to do is fill out team.json, and then re-generate the website with sphinx -E ./web ./build like always. Easy.
The team.json format
The sample team.json that I've uploaded with this PR looks very similar to this:
{
    "current": [
        {
            "full_name": "Tom Aarsen",
            "github_username": "tomaarsen",
            "personal_website_url": "https://www.tomaarsen.com",
            "photo_path": "_static/images/tomaarsen.png",
            "location": "Nijmegen, Netherlands",
            "role": "Core Maintainer. Issue triaging, bug fixing, documentation, website.",
            "active_range": "Since 2020"
        },
        {
            "full_name": "Arbitrary Human",
            "github_username": "this-user-hopefully-does-not-exist",
            "personal_website_url": "https://www.google.com",
            "location": "Within the Milky Way, hypothetically",
            "role": "Introducing bugs",
            "active_range": "For far too long"
        }
    ],
    "former": [
        {
            "full_name": "Someone else",
            "github_username": "presumably-this-user-doesnt-exist-either",
            "location": "Earth",
            "role": "Absolutely nothing",
            "active_range": "Who knows?"
        }
    ]
}

The top-most two keys are current and former, and each of these become a separate file: current_team.html and former_team.html. Both of these files are included in the team page on the website, under their own section. Each of these keys contains lists of members. Each member in these lists can have the following options:

full_name - mandatory. Speaks for itself.
github_username - mandatory. Also used for creating a link to the github page.
personal_website_url - optional. If set, then the team member's name becomes a link to this page.
photo_path - optional. Final path to a square image rendered beside the team member. If set, then the photo can also be clicked for a link to the team member's GitHub page.
location - optional. Speaks for itself.
role - optional. Speaks for itself.
active_range - optional. Speaks for itself. Later on we can discuss a format for these ranges, e.g. 2014-2018 and 2020-.

Each of the optional keys can just be left out (e.g. photo_path for the bottom 2, and personal_website_url or active_range for the bottom one), and the template will react accordingly.
Potential for changes
I want to make something clear - everything you see here can be easily modified. If you don't really like some of the wording, or the design, then feel free to let me know. I'd love for this to become a page that team members are proud to refer to. It's very easy to add an optional extra header for a team member too, for those who are interested. E.g. "Research interest" or something. Anything goes.
Some ideas

The photo can also link to the team member's personal website, if they supply one, rather then their GitHub page.
The photo can perhaps also be taken directly from the team member's GitHub page. That way, everyone might have a picture without having to go through the hastle of uploading one. That said, it removes some freedom and choice.

What now?
I'm looking for feedback on the look of everything, and would like to extend the team.json file with information of other team members. I will need help with this.
To do:
(This is mostly for me to keep track of things)

tree.gif is packaged twice, once under _images and once under _static/images.
There's also a _static/img, perhaps use that one, instead fo _static/image.

Tom Aarsen

I've started using Jinja2 instead of Mustache for this. I'll update my main post accordingly.

looks awesome! 🔥

I know it's not ready for merging yet, but just approving since it looks great! In response to a few of your questions:

photo_path pointing a user's repo does feel nice and easy! even at the loss of a bit of freedom.

i wonder how hard this will be, i think if you had some way to get a user's ID from their username, you could point to this link https://avatars.githubusercontent.com/u/3710083 (swapping out the ID number at the end)

Regarding the optional vs required fields, how will users know which is required?

i actually don't know what to do here, potentially nesting a required list and an optional list. but that feels verbose

@dannysepler
Regarding 1: I did some more research into the matter, and it turns out that it's truly as simple as going to https://www.github.com/dannysepler.png! GitHub redirects it for you.
So, I'm using that now! All it took was 3 lines of changes in web/_templates/team.html.
And for 2: I'm not sure how to make this clear. Luckily, this team.json file will only need to be modified by team members, who will hopefully be able to find the documentation of this PR. Perhaps some of the explanation can be pasted into conf.py too (i.e. the file that is ran to actually generate the files)


chore: delete Lambda.rs

It's an unnecessary abstract and can be deleted. We can directly create expressions instead of going via lambda.

/bounty 10$

I'm taking this up. please assign me @tusharmath

/attempt #1112


clientv3/integration: close active connection to get ErrClientConnClosing

because clientv3.Close won't trigger it any more
clientv3.Close just closes watch client
instead of closing grpc connection
/cc @heyitsanthony @xiang90

@heyitsanthony PTAL. Thanks!

lgtm after adding the defer cli.Close(). Thanks!

@gyuho Will this fix https://github.com/coreos/etcd/issues/6630?

@xiang90 @heyitsanthony Fixed. PTAL.
Regarding https://github.com/coreos/etcd/pull/6768
This change would resolve that issue in that we now correctly close the gRPC connections.
I have been trying to reproduce that issue injecting some sleeps
// Close shuts down the client's etcd connections.
func (c *Client) Close() error {
	c.cancel()
	time.Sleep(2 * time.Second)
	c.Watcher.Close()
	return toErr(c.ctx, c.conn.Close())
}

but I think we can close it for now? I tried over 5k rounds but cannot reproduce...
Thanks!

lgtm. No strong opinion about #6630 and this; can close/reopen if it shows up again.


Write Performance on External Flash

Are there any limitations due to the write performance of the flash or due to the fact that the SPI bus speed is comparatively slow?

Max page program time is 10 ms in low power mode. If we need to write over a page border it would be 20 ms (worst case)
So even with 1000Hz we are only writing to the flash every 32 ms. I don't think we will be facing issues here

Checked with 100Hz and 200Hz frequency at 12Bit resolution. All Data (about 200000byte) looked fine, as timestamps were counting up and acceleration values showed realistic values.
I think we can close this issue :)


Issues with DinD

Hi Fabiano,
This is great work! I was curious on your experience with Docker-in-Docker in this project. I've read all over the internet that DinD will cause some issues with file corruption with incompatible nested file systems?
If I run BioPortainer locally and use DinD, do you imagine there is any issues?
Is there an alternative to perhaps using the docker socket to spawn sister containers instead of child containers with DinD?
Any insight and would be super appreciated!
Also, would be happy to carry conversation in email, but I couldn't find your email!
Ming

Sorry, I'm a little away writing my thesis.
About your question, projects like Galaxy use the DinD feature to run internal containers. Other projects also do, such as Portainer himself. We are using the concept of DinD in the lab and we have never had problems. We have a cluster based on Rancher and Kubernets where we do this.
About alternatives to sister containers, we have the concept of Docker Outside of Docker (DooD). For our proposal would not be interesting, because the system needed root attributes for file handling and management of Docker itself,


[keras/optimizers/legacy/adadelta.py] Standardise docstring usage of "Default to"

This is one of many PRs. Discussion + request to split into multiple PRs @ #17748

Hi @SamuelMarks, Please submit multiple typo fixes in a single PR as the CPU/GPU hours are wasted on CI.
Hence, we do not encourage one liner grammatical changes as it is an expensive process. Thank you for your contribution!


Remove unused methods.

Review by @sjrd

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/3456/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/4533/
Test FAILed.

Jenkins, retest this please

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/3460/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/4537/
Test PASSed.


Can you enable travis and codecov in the backend?

Finally am getting around to pickup the work here to start developing this plugin. @bmuschko can you log into travis and codecov and ensure we can build successfully on those services? Can you also copy over the same creds/env-vars from gradle-docker-plugin so that we can mimic the release process? Also might not be a bad idea to create a gradle-kubernetes-plugin repo on Bintray as well so that we can publish something to.
@orzeh if you want to start helping out in any way you can easily stand-up a kubernetes cluster on your local machine using docker containers. On mac this comes out of the box if you're using their edge releases. If not, or on another machine, there are loads of tutorials on how to use minikube or localkube which amounts to the same thing.

@cdancy done

@bmuschko Bintray as well?

@cdancy I believe the package will be created when you publish for the first time. Let me know if that should not work the way I think it works.

@bmuschko Ok I'll tackle that when I come to it then. I vaguely remember needing to import a project from github but maybe that's not the case.

Closing as ISSUE as now resolved.

@orzeh @bmuschko if you can spare a bit of time I've got the general project structure in place and would love if you can give things a look over and see if they make sense or if you have any general questions/comments/concerns.

@cdancy Thanks, I will try to look over it by the end of the week. How do you prefer to receive feedback?

@bmuschko open a new ISSUE or something else? Let me state a few design decisions here before folks go poking around as I've not fully documented my intentions or some of the features yet.
The plugin itself works in largely the same way as the gradle-docker-plugin. I simplified things a bit and factored out lots of code to traits (more on that below). We're using the fabric8.io kubernetes-client library for interacting with kubernetes. They provide a shaded version as well so I opted to use that if only to get around many of the issues we have with the gradle-docker-plugin. Furthermore I used the Jcl (java class loader) library to create a separate/isolated class-loader for the kubernetes-client classpath to further ensure that it won't clobber anything else put on the buildscript classpath.
One design goal that I was going with is to be able to "configure" each tasks properties/variables/etc instead of us having to code and expose these properties every time a user wants additional options. This is done through the ConfigAware trait, which gets applied to all tasks, and works something like this:
task someKubeTask (type: AwesomeKubernetesTask) {
    config {
        setPropertyOne('abcd')
        withSomeOtherProperty('efgh')
    }
}

The kubernetes-client instance has many ... domain?!? ... methods which return an Object of said domain, which can be further configured in some way, and then finally executed for a result. The config closure above gets applied on each domain object and then we execute the given command. Thought this was a good way of empowering the user to configure things however they want and getting us out of their way. Also seemed to be the only sane route less we want to expose a thousand properties that the client provides which could become a nightmare.
Another design idea is the ResponseAware trait which also gets applied to all tasks. As each execution in the kubernetes-client returns "something" I wanted a way for all tasks to return whatever that something is so that downstream tasks have a standard way of accessing and working with it in a gradle context. An example might look something like:
task getMyPods(type: ListPods) {
    // yes I brought along the reactive-stream methods as well as I find them to be very useful.
    onNext {
        logger.quiet "Found pod: ${it}"
    }
}

task downstreamTask(dependsOn: getMyPods) {
    doLast {
        def podsResponse = getMyPods.response()
        // do some additional work with podsResponse object
    }
}

As the response() could literally return anything, and thus potentially confusing the user, I was going to add an additional column to each tasks table which states not only what the response() object is but also what domain object the config {} closure further above is actually configuring and give direct links to the source.
Those are the few big ideas I'm going with everything else should be pretty self-explanatory. Travis-CI is already wired up and I've written a few basic functionalTests to get things working. The source itself contains loads of documentation and design-ideas itself that should further explain anything here I may have missed.
But yeah as far as feedback we could either do things here, in a follow-up ISSUE, or maybe setup a gitter chat? Anything works for me just wanted to get some input on the initial setup and if things make sense and if there was anything that could be done better or if I just completely missed on something :)


Issue when sending msg.payload to AWS IoT hub with strange padding chars

It causes AWS IoT To ElasticSearch rule engine to be failed.
{
  "messages": [
    {
      "messageNumber": 10,
      "payload": "{\"ID\":\"device1\",\"@timestamp\":1476173698563,\"humidity\":0.29481194056521276,\"temperature\":0.8402678019981551,\"value\":0.13363450403175348}|F",
      "qos": 0,
      "timestamp":<PHONE_NUMBER>735,
      "topic": "telemetry/sensors"
    },
    {
      "messageNumber": 11,
      "payload": "{\"ID\":\"device1\",\"@timestamp\":1476173700899,\"humidity\":0.5882954466170622,\"temperature\":0.9951452361800011,\"value\":0.5461481569598483}\u0000\u0000",
      "qos": 0,
      "timestamp":<PHONE_NUMBER>055,
      "topic": "telemetry/sensors"
    }
  ],
  "qos": 0,
  "topicFilter": "telemetry/sensors"
}

By removing qos and retain in options
mqttjs.publish(topic, payload,{},callback)

There is no added special payload anymore.


License auto-detection

Fix for #73: Detect the project license based on the licenses, organizationNam and startYear settings.
Note that licenses is of type Seq((String, URL)). The current implementation can only detect a license if licenses has only one entry. If there is exactly one entry the String has to contain a SPDX license identifier, which we than map to one of the licenses we support.
Users can still set the license directly by specifying the headerLicense setting. Is the headerLicense is set, it's value is given precedence.


Fix PlatformChannel leak by releasing it when necessary.

Fix PlatformChannel leak by releasing it when necessary.

:+1:


Proposal: IPNS pinning

At the moment, I don't think IPNS is supported by some pinning services, and I'm not sure if everyone is in sync on what the behavior would actual look like.
It'd be nice if we could standardize how IPNS should be handled by pinning services (including DNSLink functionality, how updates work).

FYSA there is a proposal and discussion around "IPNS Pinning Service" at https://github.com/ipfs/devgrants/pull/142.
My initial idea is to add IPNS support to this spec, instead of inventing something new – see my comment in https://github.com/ipfs/devgrants/pull/142#issuecomment-1131622631.
Sanity check + feedback on that issue would be appreciated.

@RangerMauve could you add a link to your project and or proposal? I would love to see the progress and roadmap

@mrodriguez3313  Yup, we're posting updates about it on this github issue: https://github.com/ipfs/devgrants/pull/129
The relevant bit is Milestone 5: https://github.com/RangerMauve/devgrants/blob/ef3ac96d6aab4d498b2ecd4cd9f7d99fb29ba2a1/open-grants/open-proposal-agregore-mobile.md#milestone-5-ipfs-pinning-service-ui--integration
At the moment we're planning on supporting both the regular IPFS pinning service API for IPFS URls, and also supporting the IPFS Cluster pinning API for IPNS.

Quick brain dump on our options "how to represent /ipns/{foo}" as a CIDv1.
We need to have rules around pinning (1) cryptographic IPNS names and (2) human-readable DNSLink names.

if foo is IPNS record key, then it is a CIDv1 with libp2p-key codec already

the main argument for not messing with existing CID is UX:  user pins the {foo} from the address as-is, without the need for any conversion

(open problem) find a way for pinning DNSLink names – need clarity for the future, even if we only decide to support (1).

Allowing DNSLink names  improves UX/devexp significantly, and allows website owners to pin a DNS name once on multiple services, and then have pinning services follow it (solves cases where IPNS records are not used, or when it is ok for IPNS keys to changeover time)
fwiw we have ipns-ns codec (0xe5) which was proposed by ENS team  but I agree with https://github.com/multiformats/multicodec/pull/136#pullrequestreview-257769901  – we should not be  mixing DNSLlink and IPNS records under a single umbrella, they should have distinct codecs, if possible
instead, my initial idea is to add dnslink codec to remove any ambiguity – would appreciate review/sanity check in https://github.com/multiformats/multicodec/pull/268

Thinking about point 1) and having gone through the pinning service spec. Since, with ipns records, there are two "types" of pinning. I feel like it would make sense to differentiate that in the spec. That being Record Tracking and Record Republishing
Record Tracking, that is allowing a service to track the record you have alive
Not much for the API spec would have to change here. The Pin object would hold the ipns key identifier instead of the CID and the rest would stay the same. Then the PinStatus object, would also hold the same format. The only thing I can see as possibly different would be the status results from the service. It could be queued, it could be resolving, or resolved. Tracking a record does not necesitate transferring/sharing keys at all. And you would use the endpoints for getting list of records you've pinned, posting records, and removing/stopping a record from being tracked by the service. My biggest question with this goes back to this github issue https://github.com/ipfs/go-ipfs/issues/1958#issuecomment-444201606. Does the service, as a central point, want to continue providing expired records or throw away those expired records? I have my opinion, but I'm interested to hear more people's thoughts on this?
Also (slightly unrelated), how would services know how to connect to the origins to download the record/data. Is there already a library or functionality in IPFS to support this? And on the flipside how would the service distribute the content to its delegates? I know these wouldn't be specified in the spec I was just wondering for my project.
Record Republishing, that is trustlessly allowing a third party to republish your record.
This is still a big dicussion, regardless I believe the general idea was/is, there being some extra key that is not a users private node key that permits republishing? And if that is the case, then nothing would have to change in the Spec in this regards either? Because then that key could go along in the Pin object in the CID? And of course a users API key or JWT access [link to that functionality](that I don't remember where I found). And if it has it's own codec then the third party service & ipfs can interpret it and allow republishing it with it?
Like @rangermauve was saying in the https://github.com/ipfs/devgrants/pull/142#issuecomment-1136437173 it would be nice to for a user to be able to specify how long they want their record to live before expiring. I just personally don't know if that would be specified in the spec? (I'm just not an architect genius, thoughts on where this would be best to have?) Maybe that could be as part of the meta field in Pin object the user submits?
Im sure you've thought of these things already @lidel @aschmahmann. Just wanted to bring them up here and see if you can offer an insight to the questions in this post or any follow up?

Cross posting from another thread on encoding DNSLink domains as CIDs:
Hmmm. Personally, the CIDs for DNS Name approach seems like it'll add a lot more burden for pinning service client implementations since they'd need to include CID libraries in whatever code they're writing (I'm a dependency minimalist 🤪).
Have you considered alternatives to CIDs like URLs? e.g. instead of passing a CID, clients could specify a ipfs://bafywhatever URL or ipns://ipfs.io/subpath URL. It'd add more work on the pinning service implementor side, but it might make the client side a lot more flexible. 🤷 (I'm also really into URLs)

@mrodriguez3313 the longer we talk about this, the more sense it makes to separate "dynamic/following/tracking" pinning from "static / one time" pinning. You have good insights!
I agree with @RangerMauve that forcing DNSLink into Pin.cid field is problematic and  if we could avoid that can of worms, we should.
Perhaps we should  frame this work around separating static pins (/ipfs/{cid}/)  from mutable ones (under /ipns/{name}/).
What if..

/pins  – (current state) static pinning, no following, no support  for /ipns/{name-or-key}  – we don't force any change on existing clients and services
/follows – (name tbd) NEW ENDPOINT (and name) to distinguish dynamic pinning that follows the provided content  path from static one

it would have Pin.path  instead of Pin.cid, allowing for any /ipns/ content path (IPNS and DNSLink)
periodically resolves  path and pins data and IPNS record behind it – inspired by https://github.com/ipfs/go-ipfs/issues/4435
it would have an optional Pin.expiration which would automatically unpin after a specified timestamp is hit
(tbd) it could have an optional Pin.privateKey  that allows delegated republishing and bumping IPNS record every 12-24h forever (default) or until Pin.expiration  hits (when both are provided)

A separate endpoint would:

make upgrade easier across the ecosystem

clients could add  ipfs pin remote add --follow to indicate pin is dynamic
pinning services could decide if they support "follows" or not
/follows endpoint makes it easy to test to tell which service supports dynamic pins vs static ones.

Does the service, as a central point, want to continue providing expired records or throw away those expired records? I have my opinion, but I'm interested to hear more people's thoughts on this?

If a user pinned an IPNS name, they expect the service to keep it alive (republish record, reprovide CIDs/data behind the record) until the pin is removed by the user.  To illustrate, you don't have private IPNS keys for, but want to keep last IPNS snapshot of Wikipedia, press articles,  historical scientific datasets alive.
Data (CIDs) is always reprovided.
I argue that when we talk pinning, the same should be applied to IPNS record itself, even if it is expired.
Sure, the record may be expired, and sure, DHT/pubsub IPNS clients may ignore puts for it, but the pinned data should be around for clients that are ok with an older, expired record as the ultimate fallback.

how would services know how to connect to the origins to download the record/data. Is there already a library or functionality in IPFS to support this?

Pinning service takes multiaddrs from Pin.origins and preconnects to them via the equivalent of  ipfs swarm connect  {multiaddr}.  See https://ipfs.github.io/pinning-services-api-spec/#section/Provider-hints
When no origins are provided, DHT is used for content routing.

Record Republishing, that is trustlessly allowing a third party to republish your record.

Right now, AFAIK, there is no trustless way for a third party to create a new, signed IPNS record with an update expiration date.
The only thing you can do in trustless fashion (without sharing private keys) is to republish old signed IPNS record.
(You are free to propose a scheme for trustless publishing where publisher is only able to re-sign an existing record to bump its TTL, and is unable to change the CID it points at, but it feels like a separate research/devgrant track.)

Regarding expiration I think we should encourage users to use a high value for the lifetime parameter in ipfs name publish so that we can avoid worrying about expiration for the time being (at least not as much). e.g. set it to a Year and tell users to try to be online on their original pinning device more frequenty than that. 😅 Not a perfect solution of course, but I think it could get us pretty far in terms of reliability. Might also be good to spell out the security implications of doing so.
Although I hate to admit it, I'm +1 to having an optional private key field in the new API. 🤷
Also, I'd like to point out that in the IPFS-cluster API they have two paths for adding IPFS/IPNS pins add /pins/ipfs/{path} and add /pins/ipns/{path}. This is in tandem with a add /pins/{cid} API

@lidel

My usual north star here is for people to be able to use pinning for keeping valuable datasets alive, even when the original publisher is gone

Yeah that is where my opinion lies as well.

periodically resolves path and pins data and IPNS record behind it – inspired by https://github.com/ipfs/go-ipfs/issues/4435

So if I understand correctly, this issue is for local development of pinning and by extension of what people want in a remote pinning service as well. But after reading it, I realized the command ipfs pin remote add --follow could be a little confusing.
I can think of two scenarios which can both be described as "following a record". The first is closer to what is being described in issue 4435. Which is that the users want to recieve updates on their own node from the original publisher (OP). Now this described in the issue is something that ideally they want baked into IPFS. Then they can circumvent any need for a third party service or scripting. But the command could also mean that help by a third party service is welcomed. So the service could push the updates from the OP to those that opted-in?
And the second scenario, would be to actually pin a record to the remote service (what we want to do). Do you think that this necessitates differentiating and adding to the IPNS spec? It's not necessarily pinning, but it would offer another work around for this feature request. But it would require adding the feature to go-ipfs either way, which would require a mjaor change. :/

Pinning service takes multiaddrs from Pin.origins and preconnects to them via the equivalent of ipfs swarm connect {multiaddr}. See https://ipfs.github.io/pinning-services-api-spec/#section/Provider-hints

Will do! Thank you.

Right now, AFAIK, there is no trustless way ... but it feels like a separate research/devgrant track.)

Yes I agree. Definitely requires a more dedicated and focused game plan.
@RangerMauve

Regarding expiration I think we should encourage users to use a high value for the lifetime parameter in ipfs name publish

Right right I know what you mean. Since people will imagine the pinning service to be like static ones or operate them like DBs. They may forget to about their records after 24-36hrs and not be online at that time and the record will expire. And since we want the default functionality to keep the expired record available. The security implications would be present and so we should lay those out for the user to educate them.

So to be a little more concrete and think publicly. It makes sense to have those added fields in the Pin object. So lets say that path, expiration, and privateKey fields get added on top of the current ones (name, origins, & meta). My only concern with leaving out the cid field is that it may be convenient for users, devs, dapps... to have. Firstly, this will give immediate access to the cid in a server response. So when records are listed via the GET /pins equivalent endpoint for records the user can quickly see the latest cid in the record along with the name of the file and the other details. Secondly, it tells the user the cid the service has. Then, a client could double check the answer by doing a resolve on their end.
Ultimately we want to have the latest version of the record returned to us. But it may go through updates and the client may want to quickly see how many changes has the service picked up on. Since "tracking/following" is a background process that would take some time to update. The returned PinStatus response may want to include how many times the service has updated the cid a record points to in its node. So I propose adding a version or count field to PinStatus.
Basically we want similar results like ipfs name resolve <name> from the service. So having the cid along with path will help understand results (and submissions) easier. In the future, if privateKey, cid, & path are provided in a POST then that could be infered as intending to a remote publish. So it could be good future proofing. Thoughts?

Yes I agree. Definitely requires a more dedicated and focused game plan.

Hello! I've been periodically tracking this proposal to see if it will fit my use case. After reading this comment and taking a closer look at the API in the Fierro repo indeed it seems that it does not.
What I had in mind is to write an IPNS record to an ENS name, a smart contract that is already used widely to resolve front-end UIs, but have the ability to take my node offline indefinitely. As long as I maintain pinning somewhere using what ever service I choose my node should, ideally, never have to come back online. It would also allow other clients to assist in keeping the IPNS record alive.

Does the service, as a central point, want to continue providing expired records or throw away those expired records?

I don't think I know enough about why records need to expire to develop this feature myself, nor am I proficient with go, but my understanding is that they expire just to clean out the DHT. Not too keen on trusting a pinning service to not abuse, or not get hacked, and have malicious content republished with a key I've endorsed as safe.
My question for this proposal is; will implementing trust-less IPNS pinning by keeping expired IPNS records alive on the network be out of scope of this proposal?
Maybe this could be a feature added after Fierro's implementation is merged because it would add an startFollowing(<IPNS_key> string)  interface. Once that's implemented I think it would just need to be extended to allow a node to opt into keeping the latest expired IPNS record alive. On the client node, an opt-in to accept expired IPNS records, or maybe an extra argument in the get() function allowing a user to specify which IPNS records to trust without modifying the node config.
Maybe there's more nuance there but it seems this is very doable once the pinning service api has a follow interface for IPNS IDs.
Thanks for reading and considering my input!


Migrate to newer go-git

Projects using go-licenses as build dependency now always get a security warning:
https://github.com/divVerent/aaaaxy/security/dependabot/7
It appears to be a real RCE that also is exploitable through its use by go-licenses.
This can be fixed only by this module upgrading from gopkg.in/src-d/go-git.v4 to github.com/go-git/go-git/v5.
Can you do that?

This actually seems to already be fixed by 9a41918e8c1e254f6472bdd8454b6030d445b255 - so all that's required is a new release of go-licenses.


Correct proxy config

This PR corrects the proxy config, as the api key and not the url should be uses a header

@jdiepeveen this is ready to merge

@bakito @jplimack
I'm no longer affiliated with TRIMM, so i do not have access to the account used for maintaining this repo. Will see if i can ping someone in there to finalize this.

@bakito @jplimack
Thank you for your interest in this plugin and I've released version 0.3.1 a couple of minutes ago. This version has been tested using Backstage version 1.27.5.
I will close this MR, as there are no changes left to be merged.


Misunderstanding "safetyState

Hi, can someone explain the data in the "safetyState" field and how to use it? I find that the basic explanations are not very detailed.
Kind regards.

So, for example, if an emergency stop button is pressed, the "eStop" field will change to "MANUAL". If a safety scanner has detected something in the protective field, the "eStop" field will change to "AUTOACK". If the AGV is in normal conditions, the "eStop" field will be set to "NONE".
The "fieldViolation" field is only applicable to the safety scanner.
Correct me if I'm wrong.


Accessibility & Tabbing

Hello,
I have the requirement to have a read-only grid, with custom filtering, etc. I have gotten most all of it to work rather well but noticed that tabbing through the grid seems impossible. Please keep in mind that in my situation mouse-clicking a table row redirects to a detail summary page (currently working). I only mention it because it can possibly affect how I approach implementing tabbing for this grid, since tabbing should not fire a click.
My team is trying to make our BackgridJS implementation compliant with the JAWS screen reader, for people with disabilities.
I noticed that when I tab from our search filter (above the grid), it immediately tabs down to the paginator control (below the grid). There is no tabbing through any table rows or table cells. (see screenshot).

Is there an easy way to make this grid tab compliant for screen reading? Is there a way to shift tab focus to the first cell? I notice in the Backgrid examples page...that if you click on a cell and start tabbing, it works okay. But you cannot tab from the DOM into the grid (it skips over the grid completely)? In my situation, there will be no mouse clicking at all, whatsoever. This is for people who are blind or disabled.

We were able to force keyboard access by extending the column as a UriCell and formatting appropriately.
The only remaining issue we face here is how to get the first/hidden column value rendered into the URL.
Here is our code:
{
    name: "Title",
    label: "Job Title",
    editable: false,
    className: 'occupationJobTitle',
    cell: Backgrid.UriCell.extend({
        className: 'occupationJobTitle',
            render: function () {
                this.$el.empty();
                var rawValue = this.model.get(this.column.get("name"));
                **var occupationID = this.model.get(other?.column.get("OccupationID")); //HELP?**
                var formattedValue = this.formatter.fromRaw(rawValue, this.model);
                this.$el.append($("<a>", {
                    href: '/OccupationInfo/OccupationSummary/' + occupationID,
                    title: this.title || formattedValue,
                    target: this.target
                }).text(formattedValue));
                this.delegateEvents();
                return this;
           }
        })
},

How can we obtain the balue of OccupationID? It is a hidden column, defined as so:
{
    name: "OccupationID",   // The key of the model attribute
    label: "ID",            // The name to display in the header
    editable: false,        // By default every cell in a column is editable, but *ID* shouldn't be
    renderable: false,
    cell: Backgrid.IntegerCell.extend({
        orderSeparator: ''
    })
}

Basically, how can column three reference column one during a render? Is there something easy?
Thank you...

Nevermind, I figured it out. It was this easy:
var occupationID = this.model.get("OccupationID");


AssessmentResults results.local-definitions missing items

Describe the bug
Seemingly, "inventory-items" and other keys are missing.
To Reproduce
Compare current AssessmentResults class LocalDefintions to https://pages.nist.gov/OSCAL/documentation/schema/assessment-results-layer/assessment-results/json-model-map/. See screenshot below.
Expected behavior
Was looking to use inventory-items. Have hacked it into my copy of AssessmentResults for now.
Screenshots

I confirm this is being dropped by fix_any.  I will look into it.

Fixed by #386.


logback dependency

There seems to be an implementation dependency on logback:
This creates a conflict for projects using slf4j with log4j2. I just excluded it but I don't think I should have to.
+--- com.fasterxml.jackson.jakarta.rs:jackson-jakarta-rs-json-provider:2.13.0-rc1
|    +--- com.fasterxml.jackson.jakarta.rs:jackson-jakarta-rs-base:2.13.0-rc1
|    |    +--- com.fasterxml.jackson.core:jackson-core:2.13.0-rc1 ()
|    |    +--- com.fasterxml.jackson.core:jackson-databind:2.13.0-rc1 ()
|    |    +--- ch.qos.logback:logback-classic:1.2.3
|    |    |    +--- ch.qos.logback:logback-core:1.2.3
|    |    |    --- org.slf4j:slf4j-api:1.7.25 -> 1.7.31
|    |    --- com.fasterxml.jackson:jackson-bom:2.13.0-rc1 ()
|    +--- com.fasterxml.jackson.module:jackson-module-jakarta-xmlbind-annotations:2.13.0-rc1
|    |    +--- com.fasterxml.jackson.core:jackson-annotations:2.13.0-rc1 ()
|    |    +--- com.fasterxml.jackson.core:jackson-core:2.13.0-rc1 ()
|    |    +--- com.fasterxml.jackson.core:jackson-databind:2.13.0-rc1 ()
|    |    +--- jakarta.xml.bind:jakarta.xml.bind-api:3.0.1
|    |    |    --- com.sun.activation:jakarta.activation:2.0.1
|    |    +--- jakarta.activation:jakarta.activation-api:1.2.1
|    |    --- com.fasterxml.jackson:jackson-bom:2.13.0-rc1 ()
|    +--- ch.qos.logback:logback-classic:1.2.3 ()
|    --- com.fasterxml.jackson:jackson-bom:2.13.0-rc1 (*)

D'oh.
Yes, this definitely needs to be test dependency, not compile. Thank you for reporting it!


Added example for watsonx flow

[ ] I have added tests that cover my changes.
[ ] If adding a new instrumentation or changing an existing one, I've added screenshots from some observability platform showing the change.
[ ] PR name follows conventional commits format: feat(instrumentation): ... or fix(instrumentation): ....
[ ] (If applicable) I have updated the documentation accordingly.

@gyliu513 lint is failing, can you take a look?