Ashutosh Varma
Ashutosh Varma
Fixes #6533 As titled, add support for prefer_literal option in intrinsic decorator. PS: I am not so sure about the test I made, any suggestions would help.
## Summary While trying to compile from latest master branch kept getting `ERROR TS2304: Cannot find name 'null'.` --- **Steps to reproduce** - ``` git clone https://github.com/nearprotocol/assemblyscript-json cd assemblyscript-json yarn...
I have a very large benchmark suite in which many benches are parametised and sometimes there is a large error for a particular set of parameters. Is there any way...
We should remove: * block-reward-hybrid pallet * dapps-staking pallet * dapp-staking migration pallet * dapps staking v2 precompiles
- The `cumulus_client_service::start_collator()` has been deprecated and the new `start_relay_chain_tasks()` is recommended to use over it. - All the root imports of `cumulus_client_consensus_aura` like `AuraConsensus` & `BuildAuraConsensusParams` are now deprecated...
After the introduction of https://github.com/paritytech/substrate/pull/13958 during the v1.1.0 uplift, now the PoV is taken into account by `transcation-payment` pallet for adjusting fee and tx priority. Currently we use max pov...
Now that Moonbeam's [`precompile-utils` is included in frontier](https://github.com/paritytech/frontier/pull/1150) and we can remove the vendor code (`precompiles-utils`) after the next uplift. _Originally posted by @ashutoshvarma in https://github.com/AstarNetwork/Astar/pull/996#pullrequestreview-1654390513_
**Description** In the [release notes for v5.17.0](https://github.com/AstarNetwork/Astar/releases/tag/v5.17.0) (produced by CI) the `authorizeUpgrade` hash for [`shibuya-107.wasm`](https://github.com/AstarNetwork/Astar/releases/download/v5.17.0/shibuya-107.wasm) is `0x8548843a78eabe88f80fb5333c3b74d06562296827230ce1529f1eac05786b01` which is different from actual hash (produced by polkadotjs app) which is `0xfaa5b3d7c9b7f6cb85e92b9dacbea59eca7350b5301fb5e1b04d8a5d95163bf6`.
`Config.load_file()` removes the xpdfrc settings from pyxpdf_data. As pyxpdf_data introduce new encodings with the help of automatic generated xpdfrc and loading another xpdfrc will discard them. It can be solved...
As of now xpdf errors/warnings/logs are sent to stdout and only way to partially control it is with `Config.error_quiet`. Also pyxpdf in most cases cannot detect errors in xpdf sources...