profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/jorijnsmit/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Jorijn Jacko Smit jorijnsmit Business Intelligence & Data Science

jorijnsmit/onlineChecker 4

A systemd service that constantly pings a device on your network and reports to Domoticz whether it is online or not.

jorijnsmit/marktplaats-rssgen 3

Parses a search URL into its corresponding RSS URL.

jorijnsmit/poloniex_wrapper 2

Poloniex API wrapper in PHP

jorijnsmit/aivd-kerstpuzzel-2019 0

Genetic algorithm exploration of the AIVD Christmas puzzle 2019 (assignment 8).

jorijnsmit/aml-densenet-varying-learning-rates 0

Re-training the deep neural network DenseNet using various learning rate strategies. Entry for the Food Recognition Challenge for the Master's course Applied Machine Learning.

jorijnsmit/ape-safe 0

gnosis safe tx builder

jorijnsmit/badger-utils 0

Library that keeps shared code for badger project

jorijnsmit/binance-official-api-docs 0

Official Documentation for the Binance APIs and Streams

jorijnsmit/bitstamp-python-client 0

Python package to communicate with bitstamp.net

issue commenteth-brownie/brownie

Add params to brownie run

yes, can confirm this works! thank you kindly for your work @WyseNynja!

just note that args are always parsed as strings, so they might require some casting.

drLis

comment created time in 6 days

PR opened SHAKOTN/badger-utils

unlimiting eth-brownie version

is there a reason you constrained it to <1.16.4? trying to upgrade to https://github.com/eth-brownie/brownie/releases/tag/v1.17.0

+1 -1

0 comment

1 changed file

pr created time in 7 days

push eventjorijnsmit/badger-utils

Jorijn Jacko Smit

commit sha 448527720d2477422b2e61b1e621dfe5a9819cdb

unlimiting eth-brownie version is there a reason you constrained it to `<1.16.4`? trying to upgrade to https://github.com/eth-brownie/brownie/releases/tag/v1.17.0

view details

push time in 7 days

fork jorijnsmit/badger-utils

Library that keeps shared code for badger project

fork in 7 days

issue commenteth-brownie/brownie

Add params to brownie run

looks to be included in https://github.com/eth-brownie/brownie/releases/tag/v1.17.0 👀

drLis

comment created time in 7 days

push eventjorijnsmit/ape-safe

Jorijn Jacko Smit

commit sha 64068537578eea92662dab155bd115bcf0815e48

bumping brownie and gnosis to latest versions

view details

push time in 7 days

fork jorijnsmit/ape-safe

gnosis safe tx builder

fork in 7 days

PR opened banteg/ape-safe

bumping brownie and gnosis to latest versions
+2 -2

0 comment

1 changed file

pr created time in 7 days

push eventgosuto-ai/ape-safe

jorijnsmit

commit sha 573eee1d911a6459dc82fa3c5b16f2d1f5b873d6

bumping brownie and gnosis to latest versions

view details

push time in 7 days

push eventgosuto-ai/ape-safe

jorijnsmit

commit sha 716994ef6e6521fc04fea3352cb6dea2a1d57274

bumping brownie and gnosis to latest versions

view details

push time in 7 days

issue commentpandas-dev/pandas

[0.24.1] New nullable integer fillna with non-int doesn't coerce to object

i brought it up here: https://github.com/pandas-dev/pandas/issues/25288#issuecomment-592917095

i still think it makes more sense to be able to just use .fillna() without explicitly casting first. as i stated earlier in this thread, this is default behaviour for .fillna() on other dtypes, and it also is a logical step when for example adding a float to an Int64.

what you are suggesting from a user perspective, is that now sometimes i can .fillna() directly, and sometimes i will have to cast + fill. as a user i would feel more for consistent behaviour of .fillna().

jelther

comment created time in 7 days

issue commentpandas-dev/pandas

[0.24.1] New nullable integer fillna with non-int doesn't coerce to object

are you then also saying there is no room for a flag (eg coerce=True) to make it more consistent with other dtypes if needed?

jelther

comment created time in 8 days

startedBadger-Finance/badger-system

started time in 8 days

issue commentbanteg/ape-safe

Error when estimating gas

my understanding is that this issue is related to using gnosis safes <v.1.3.0. the implementation of https://github.com/gnosis/safe-contracts/issues/274 in v.1.3.0 makes setting safe_tx_gas obsolete, and makes the estimate_gas function work as expected.

for those still on <v1.3.0, @Uxio0's pr #15 is a workaround that removes dependency of web3's estimate_gas, and grabs it from self.preview().gas_used instead (with some additional margin calcs).

jo-tud

comment created time in 10 days

issue commentduneanalytics/abstractions

weth9 balances not included in view_token_balances_*

https://discord.com/channels/757637422384283659/757641002138730588/894531540158136331 https://discord.com/channels/757637422384283659/757641002138730588/894671310607749231

jorijnsmit

comment created time in 15 days

issue openedduneanalytics/abstractions

weth9 balances not included in view_token_balances_*

probably because weth9 tokens also withdraw and deposit, instead of only transfer.

fix could consist of using a table similar to the one below, to replace the weth9 entries in erc20."ERC20_evt_Transfer":

SELECT
    contract_address,
    dst,
    evt_block_number,
    evt_block_time,
    evt_index,
    evt_tx_hash,
    src,
    wad
FROM zeroex."WETH9_evt_Transfer"

UNION ALL

SELECT
    contract_address,
    dst,
    evt_block_number,
    evt_block_time,
    evt_index,
    evt_tx_hash,
    NULL AS src,
    wad
FROM zeroex."WETH9_evt_Deposit"

UNION ALL

SELECT
    contract_address,
    NULL AS dst,
    evt_block_number,
    evt_block_time,
    evt_index,
    evt_tx_hash,
    src,
    wad
FROM zeroex."WETH9_evt_Withdrawal"

created time in 15 days

pull request commentduneanalytics/abstractions

remove filter which excludes tokens already present in prices.usd

if coingecko feeds would be filled in retroactively, it would solve the issue in a way.

however, let's say you want to compare coingecko feed prices and dex prices. you would still need tokens that have a coingecko feed to also be included in dex.(view_)token_prices.

jorijnsmit

comment created time in 20 days

issue commentSHAKOTN/badger-utils

requirements contains pinned versions that are incompatible with current env

✔ Installation Succeeded

jorijnsmit

comment created time in 20 days

issue closedSHAKOTN/badger-utils

requirements contains pinned versions that are incompatible with current env

trying to install into our badger-ape repo, but getting

There are incompatible versions in the resolved dependencies:
  attrs==20.3.0 (from badger-utils==0.0.9->-r /var/folders/q0/wj9dn5_91y37j42gk1kls8_r0000gn/T/pipenvuh8hbawurequirements/pipenv-6meo6px5-constraints.txt (line 8))
  attrs==21.2.0 (from eth-brownie==1.16.4->-r /var/folders/q0/wj9dn5_91y37j42gk1kls8_r0000gn/T/pipenvuh8hbawurequirements/pipenv-6meo6px5-constraints.txt (line 5))

is it possible to unpin (some of) the requirements, eg using attrs>=20.3.0 or even attrs instead?

if we want to add badger-utils to our prod branch, the less (pinned) requirements the better. i have no experience publishing to pypi, but i think you just did a freeze? are all those reqs really needed, and are they needed at exactly that version?

maybe you could only include the core dependencies in requirements.txt, and let the sub dependencies follow from those?

here is our requirements-core.txt for badger-ape:

ape-safe==0.2.2
pandas
pycoingecko
rich
tabulate

all other sub dependencies follow from those five reqs.

some background: https://towardsdatascience.com/why-you-should-consider-adding-requirements-core-txt-to-your-next-python-project-2c36c1381b12

closed time in 20 days

jorijnsmit

issue commentSHAKOTN/badger-utils

requirements contains pinned versions that are incompatible with current env

i never said badger-api; im talking about badger-ape. i realise now it might not be visible for you. it is a fork of badger-system we use to run multisig scripts (built around https://github.com/banteg/ape-safe).

jorijnsmit

comment created time in 20 days

pull request commentduneanalytics/abstractions

remove filter which excludes tokens already present in prices.usd

being a table instead of a materialised view makes sense i think. price feeds in this table are a core element of a lot queries currently i believe, and the more inclusive and faster it is the better.

having said that, im not sure if i am the person to write it; i currently dont really have the time to figure out the updater function. is this not something you guys could pick up with the core team @masquot @0xBoxer?

jorijnsmit

comment created time in 20 days

startedSHAKOTN/badger-utils

started time in 21 days

issue openedSHAKOTN/badger-utils

requirements contains pinned versions that are incompatible with current env

trying to install into our badger-ape repo, but getting

There are incompatible versions in the resolved dependencies:
  attrs==20.3.0 (from badger-utils==0.0.9->-r /var/folders/q0/wj9dn5_91y37j42gk1kls8_r0000gn/T/pipenvuh8hbawurequirements/pipenv-6meo6px5-constraints.txt (line 8))
  attrs==21.2.0 (from eth-brownie==1.16.4->-r /var/folders/q0/wj9dn5_91y37j42gk1kls8_r0000gn/T/pipenvuh8hbawurequirements/pipenv-6meo6px5-constraints.txt (line 5))

is it possible to unpin (some of) the requirements, eg using attrs>=20.3.0 or even attrs instead?

if we want to add badger-utils to our prod branch, the less (pinned) requirements the better. i have no experience publishing to pypi, but i think you just did a freeze? are all those reqs really needed, and are they needed at exactly that version?

maybe you could only include the core dependencies in requirements.txt, and let the sub dependencies follow from those?

here is our requirements-core.txt for badger-ape:

ape-safe==0.2.2
pandas
pycoingecko
rich
tabulate

all other sub dependencies follow from those five reqs. some background: https://towardsdatascience.com/why-you-should-consider-adding-requirements-core-txt-to-your-next-python-project-2c36c1381b12

created time in 21 days

issue commentbanteg/ape-safe

Error when estimating gas

really want to get to the bottom of this, i think passing good gas values to the final tx is important.

i create a new env, with nothing else but ape-safe==0.2.2 installed. i then run one single tx from a safe to a wallet.

this seems to fail in the same way @jo-tud reports in the beginning of this issue:

  File "./scripts/example.py", line 12, in main
    safe.estimate_gas(safe_tx)
  File "ape_safe.py", line 161, in estimate_gas
    return self.estimate_tx_gas(safe_tx.to, safe_tx.value, safe_tx.data, safe_tx.operation)
  File "gnosis/safe/safe.py", line 577, in estimate_tx_gas
    return self.estimate_tx_gas_with_web3(to, value, data) + ADDITIONAL_GAS + WEB3_ESTIMATION_OFFSET
  File "gnosis/safe/safe.py", line 514, in estimate_tx_gas_with_web3
    raise CannotEstimateGas(f'Cannot estimate gas with `eth_estimateGas`: {exc}') from exc
CannotEstimateGas: Cannot estimate gas with `eth_estimateGas`: execution reverted: VM Exception while processing transaction: revert

someone suggested to use the --noVMErrorsOnRPCResponse flag for ganache. this helps a little bit, in that we get some more output (before failing in the same way):

Safe=0xFEB4acf3df3cDEA7399794D0869ef76A6EfAff52 Problem estimating gas, returned value without gas limit set is 0x for tx={[...]}

now if i run the script again, but this time with amount anything else but the full balance of the safe, it works! somehow doing

amount = usdc.balanceOf(safe.address)
usdc.transfer(wallet_addr, amount)

breaks .estimate_gas, but transferring amount / 2 or 0 give a successful output for .estimate_gas.

however, its output

recommended gas limit: 96060
estimate gas: 59614

differs a lot from the recommended gas limit. also, in all the of erroneous cases above, .preview was always able to output a (seemingly) proper recommended gas limit.

and tbh, all i care for is that that recommended gas limit ends up in safe_tx.safe_tx_gas and in safe_tx.base_gas before posting.

so hereby a feature/fix request: let there be a function which grabs recommended gas and sets safe_tx.safe_tx_gas and safe_tx.base_gas accordingly.

jo-tud

comment created time in a month

create barnchgosuto-ai/ape-safe

branch : update-gnosis-3.3.3

created branch time in a month

push eventgosuto-ai/ape-safe

banteg

commit sha 5f3b98c695f2df026a8f3abd533f6fb623625b68

feat: support lowercase addresses

view details

push time in a month

issue commenteth-brownie/brownie

Contract.from_explorer("0x561B94454b65614aE3db0897B74303f4aCf7cc75") fails

can confirm same behaviour on v1.16.2

WyseNynja

comment created time in a month

pull request commentDevOps4DeFi/scout

Arbitrum for scout

yea im a contrib so i see all activities here, that's how i found that double strategy mention in addresses. but i think you are already ahead of that pr.

Tritium-VLK

comment created time in a month

issue closedDevOps4DeFi/scout

get_token_prices should be able to handle tokens which cannot be found on coingecko

https://github.com/DevOps4DeFi/scout/blob/85209eed613c62c583fe7e53e6b15ec937739a63/docker/scout/scripts/main.py#L61

closed time in a month

jorijnsmit