profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/christopheradams/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.

christopheradams/elixir_style_guide 3751

A community driven style guide for Elixir

christopheradams/christopheradams.io 4

Articles and Photos

christopheradams/dotfiles 2

Configuration files for Emacs, Git, Irssi, tmux, Vim, xmonad, etc.

christopheradams/absinthe 0

The GraphQL toolkit for Elixir

christopheradams/allthecolorintheworld.com 0

All the Color in the World

christopheradams/arkb 0

Arweave Deploy that saves you some data costs.

christopheradams/awesome-elixir 0

A curated list of amazingly awesome Elixir and Erlang libraries, resources and shiny things. Updates:

christopheradams/bangkok-biennial-platform 0

The platform for bangkok biennial 2020

startedchristopheradams/elixir_style_guide

started time in 6 hours

PR opened ArweaveTeam/SmartWeave

chore: add validity return to `readContractState`

Hey 👋🏻 noticed that you couldn't check the validity of contract interactions from inside a contract.

P.S. Sorry for the massive diff, formatters 😄

+27 -21

0 comment

4 changed files

pr created time in 6 hours

issue closedOpenZeppelin/openzeppelin-contracts-upgradeable

error : The requested contract was not found. Make sure the source code is available for compilation

Firstly , I have already deployed *.sol in bsc testnet ,but I redeployed a second time ,and it appeared this error:

The requested contract was not found. Make sure the source code is available for compilation. I didn't change the code in the process

closed time in a day

Tom1054

issue openedOpenZeppelin/openzeppelin-contracts-upgradeable

error : The requested contract was not found. Make sure the source code is available for compilation

Firstly , I have already deployed *.sol in bsc testnet ,but I redeployed a second time ,and it appeared this error

created time in a day

push eventOpenZeppelin/openzeppelin-contracts-upgradeable

github-actions

commit sha 88ee64b9e2ec74b69021d6fc2186bd8916ae562d

Transpile bce31dee

view details

push time in a day

push eventOpenZeppelin/openzeppelin-contracts-upgradeable

renovate[bot]

commit sha 78103f31376bd16add5270ec531721802b25bf75

Update lockfile (#2717) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

Hadrien Croubois

commit sha 0a05f6fa458b39ccf58c30d0632e435b0ee2aba9

Add a recover(bytes32,bytes32,bytes32) that follows EIP2098 (#2713)

view details

Francisco Giordano

commit sha 17958adacafc6e9dd385a3ffb83f4882a3298906

Uninstall unused mocha dependency

view details

Hadrien Croubois

commit sha fd111df16daa7a15c336e8f82608d089f773377a

Remove unecessary code from Context (#2718)

view details

Hadrien Croubois

commit sha 6f50f6e1ef97b1387235f7054c1397fca5b623a4

Remove repeated code from ERC1967Upgrade (#2720)

view details

Hadrien Croubois

commit sha 788d338c9b53d57f7229f79815573dcb91ecede1

Improve naming of internal variables (#2721)

view details

Hadrien Croubois

commit sha f710bafae89c8ac1bad5d3595ed2d37c10c0d766

Fix typos (#2723)

view details

Hadrien Croubois

commit sha 00128bd26061986d10172573ceec914a4f3b4d3c

Fix function ordering in ERC1967Upgrades (#2722)

view details

Hadrien Croubois

commit sha 27e09007ccac62594232a6a0eeb8ad836e7b54d1

Reorder state changes and event emission for consistency (#2719) Co-authored-by: Francisco Giordano <frangio.1@gmail.com>

view details

Hadrien Croubois

commit sha 4d0f8c1da8654a478f046ea7cf83d2166e1025af

Check inheritance tree consistency (#2727) Co-authored-by: Francisco Giordano <frangio.1@gmail.com>

view details

Hadrien Croubois

commit sha 8a775cd8d428595804bb1cc77a5e77f9c39f8c6d

Emit DelegateVotesChanged events after Transfer (#2733)

view details

Hadrien Croubois

commit sha 6842518b1b71fac9a21c7d94ec521992cff266b5

Wrapper extension for ERC20 token (#2633) Co-authored-by: Francisco Giordano <frangio.1@gmail.com>

view details

Francisco Giordano

commit sha bce31dee32859adcbcada7daac57900015abd5b9

Merge upstream openzeppelin-contracts into upstream-patched

view details

push time in a day

push eventArweaveTeam/SmartWeave

Cedrik

commit sha ac9cc2a9db10682636affddd1c1a97bb46c80f0c

🆙 evolve

view details

push time in a day

push eventArweaveTeam/SmartWeave

Cedrik

commit sha 23017dfdfde4fded32a4abd400e3c953f7cbe9fb

evolve

view details

push time in a day

startedchristopheradams/elixir_style_guide

started time in a day

issue commentArweaveTeam/SmartWeave

Add feature to call "interactRead" from other contract

As, the SmartWeave.contracts.readContractState method needs to load and replay all the transactions, allowing interactRead should not affect the performance.

ppedziwiatr

comment created time in 2 days

issue openedArweaveTeam/SmartWeave

Add feature to call "interactRead" from other contract

Currently SWC offers only one way of calling other contract - ie. reading its current state: SmartWeave.contracts.readContractState(contractId: string): Promise<any>

This is somewhat limiting, as it prevents from calling any logic from external contract.

As "interactRead" does not change state (ie. it only returns "result", not new "state"), it doesn't seem to introduce any security risks.

Having such feature would allow to split business logic between different contract (eg. vesting or staking contract and PST contract).

Current workaround forces to firstly call state update on the callee contract (and wait for a transaction to be mined) - only then the "caller" contract can read updated state from "callee" contract and perform its logic.

created time in 2 days

issue commentArweaveTeam/SmartWeave

Running untrusted Javascript in SmartWeave contracts

I'll add here that anything utilizing the foreign call protocol (which will hopefully be all SmartWeave token contracts in the future) would be at risk of this without a sandbox environment because users would be able to introduce any code into the execution path of the other contracts.

Technically users could whitelist the contracts that other contracts can read from, however, this naturally puts a large limitation on who can interact with what.

joshbenaron

comment created time in 2 days

issue commentArweaveTeam/SmartWeave

"interactRead" does not set block timestamp properly

I believe this has been fixed in version 0.4.33 https://github.com/ArweaveTeam/SmartWeave/commit/c154bbeb5b31ddbbdb13c18e5142b159e9be1581 (though I still believe should be taken from current block data, and not simply as Date.now().

ppedziwiatr

comment created time in 2 days

issue closedArweaveTeam/SmartWeave

"interactRead" does not set block timestamp properly

I've noticed that block timestamp is not properly set for "interactRead" operation - ie. SmartWeave.block.timestamp inside contract's handle function returns null for such operations (it works properly for "interactWrite" though). I'm not sure why timestamp is set to null in https://github.com/ArweaveTeam/SmartWeave/blob/788a974e66494ef2ab8f876024e72bf363d4c4a4/src/contract-interact.ts#L223

Btw. - "timestamp" property does not seem to be documented in https://github.com/ArweaveTeam/SmartWeave/blob/master/CONTRACT-GUIDE.md#smartweave-global-api

Thanks.

closed time in 2 days

ppedziwiatr

issue openedArweaveTeam/SmartWeave

Running untrusted SmartWeave contracts

Hey, I think we're going to need a way to run any JavaScript safely. This is going to be needed for certain things that are coming into the ecosystem such as AMM's. If we are to run random PST contracts in the browser we need to sandbox the code so it's 100% harmless. I wanted this to be the start of the discussion on the topic. I have a few ideas so far. Sandboxing can be done in two ways:

  1. WASM/WASI inherently sandboxes execution. This won't be easy to do though as V8 (NodeJS JavaScript engine) doesn't support compiling to WASM
  2. Running SmartWeave contracts in its own JS interpreter which can box up the code execution. See an example here: https://github.com/jterrace/js.js

Let me know your thoughts on this.

created time in 2 days

startedchristopheradams/elixir_style_guide

started time in 3 days

PR closed OpenZeppelin/openzeppelin-contracts-upgradeable

Removed unused variable raising warnings

<!-- Thank you for your interest in contributing to OpenZeppelin! -->

<!-- Consider opening an issue for discussion prior to submitting a PR. --> <!-- New features will be merged faster if they were first discussed and designed with the team. -->

Fixes #???? <!-- Fill in with issue number -->

<!-- Describe the changes introduced in this pull request. --> <!-- Include any context necessary for understanding the PR's purpose. -->

PR Checklist

<!-- Before merging the pull request all of the following must be complete. --> <!-- Feel free to submit a PR or Draft PR even if some items are pending. --> <!-- Some of the items may not apply. -->

  • [x] Tests
  • [x] Documentation
  • [x] Changelog entry
+1 -3

2 comments

1 changed file

Madeindreams

pr closed time in 4 days

pull request commentOpenZeppelin/openzeppelin-contracts-upgradeable

Removed unused variable raising warnings

Hello @Madeindreams. The contracts in this repository are not hand-written. They are automatically transpiled from the @openzeppelin/contracts package. This "unused variable" issue is a (small) side effect from the transpiler.

A commit that changes that, such as yours, will be automatically overwritten next time the transpilling workflow is executed. This should be solved at a higher level, directly in the transpiler ... which really is not that easy to do.

Madeindreams

comment created time in 4 days

startedchristopheradams/elixir_style_guide

started time in 4 days

pull request commentOpenZeppelin/openzeppelin-contracts-upgradeable

Removed unused variable raising warnings

I have tested and recompiled with solidity 0.8.0 using Hardhat Compiled Without warning as expected.

Madeindreams

comment created time in 4 days

PR opened OpenZeppelin/openzeppelin-contracts-upgradeable

Removed unused variable raising warnings

<!-- Thank you for your interest in contributing to OpenZeppelin! -->

<!-- Consider opening an issue for discussion prior to submitting a PR. --> <!-- New features will be merged faster if they were first discussed and designed with the team. -->

Fixes #???? <!-- Fill in with issue number -->

<!-- Describe the changes introduced in this pull request. --> <!-- Include any context necessary for understanding the PR's purpose. -->

PR Checklist

<!-- Before merging the pull request all of the following must be complete. --> <!-- Feel free to submit a PR or Draft PR even if some items are pending. --> <!-- Some of the items may not apply. -->

  • [ ] Tests
  • [ ] Documentation
  • [ ] Changelog entry
+1 -3

0 comment

1 changed file

pr created time in 4 days

startedchristopheradams/elixir_style_guide

started time in 5 days

startedchristopheradams/elixir_style_guide

started time in 5 days

startedchristopheradams/elixir_style_guide

started time in 5 days

issue closedOpenZeppelin/openzeppelin-contracts-upgradeable

Wrong content on release v3.4.0-solc-0.7

💻 Environment

<!-- Tell us what version of OpenZeppelin Contracts you're using, and how you're using it: Truffle, Remix, etc. -->

Now I am using 3.4.1-solc-0.7-2 with Hardhat.

📝 Details

I was trying to upgrade the library with solc 0.7 support and v3.4.0-solc-0.7 is the latest solc 0.7 version, but the npm install from npmjs.com content is wrong as it's using ERC20 instead of ERC20Upgradable and my compile failed. Then I realised there's 3.4.1-solc-0.7-2 on npmjs.com but not on GitHub release. Now I am using the 0.7-2 version and has no problem.

Therefore I suggest adding the 3.4.1-solc-0.7-2 tag on Github and ask people to use 3.4.1-solc-0.7-2 instead of 3.4.0-solc-0.7

🔢 Code to reproduce bug

npm install @openzeppelin/contracts-upgradeable@3.4.0-solc-0.7

closed time in 5 days

leckylao

issue commentOpenZeppelin/openzeppelin-contracts-upgradeable

Wrong content on release v3.4.0-solc-0.7

Hello @leckylao, and thank you for raising that issue.

We did encounter an issue when publishing 3.4.1-solc-0.7 on npm, which required us to have this -2 fix. We are aware that this might cause issues, like the one you have been facing, and we are sorry for that.

We will take measures shortly to improve the situation.

leckylao

comment created time in 5 days

startedchristopheradams/elixir_style_guide

started time in 6 days

issue openedOpenZeppelin/openzeppelin-contracts-upgradeable

Wrong content on release v3.4.0-solc-0.7

💻 Environment

<!-- Tell us what version of OpenZeppelin Contracts you're using, and how you're using it: Truffle, Remix, etc. -->

Now I am using 3.4.1-solc-0.7-2 with Hardhat.

📝 Details

I was trying to upgrade the library with solc 0.7 support and v3.4.0-solc-0.7 is the latest solc 0.7 version, but the npm install from npmjs.com content is wrong as it's using ERC20 instead of ERC20Upgradable and my compile failed. Then I realised there's 3.4.1-solc-0.7-2 on npmjs.com but not on GitHub release. Now I am using the 0.7-2 version and has no problem.

Therefore I suggest adding the 3.4.1-solc-0.7-2 tag on Github and ask people to use 3.4.1-solc-0.7-2 instead of 3.4.0-solc-0.7

🔢 Code to reproduce bug

npm install @openzeppelin/contracts-upgradeable@3.4.0-solc-0.7

created time in 6 days

push eventArweaveTeam/SmartWeave

Cedrik

commit sha 4cac26257c62e7cd6f53a98c6eb415eacd9db0d2

fix conflict

view details

Cedrik

commit sha 90af59826917a1ef452b3b98ab8bf4b547c1e7f5

0.4.33

view details

Cedrik

commit sha 030b88fbfdce32c2b37773a44a94c01ccf585d16

Merge branch 'master' of https://github.com/ArweaveTeam/SmartWeave

view details

push time in 6 days