Dustin4444

/**
 * Take screenshot when step fails.
 * Works only with Selenium2Driver.
 * 
 * @AfterStep
 */
public function takeScreenshotAfterFailedStep($event)
{
    if (4 === $event->getResult()) {
        $driver = $this->getSession()->getDriver();

Dustin4444

{

    function cleanup_t_bool(value) -> cleaned {
        cleaned := iszero(iszero(value))
    }

    function abi_encode_t_bool_to_t_bool_fromStack(value, pos) {
        mstore(pos, cleanup_t_bool(value))
    }

Dustin4444

{
  "contracts/vendor/utils/StorageSlot.sol": {
    "__sources__": {
      "contracts/vendor/utils/StorageSlot.sol": {
        "content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts v4.4.1 (utils/StorageSlot.sol)\n\npragma solidity ^0.8.0;\n\n/**\n * @dev Library for reading and writing primitive types to specific storage slots.\n *\n * Storage slots are often used to avoid storage conflict when dealing with upgradeable contracts.\n * This library helps with reading and writing to such slots without the need for inline assembly.\n *\n * The functions in this library return Slot structs that contain a `value` member that can be used to read or write.\n *\n * Example usage to set ERC1967 implementation slot:\n * ```\n * contract ERC1967 {\n *     bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;\n *\n *     function _getImplementation() internal view returns (address) {\n *         return StorageSlot.getAddressSlot(_IMPLEMENTATIO

Dustin4444

[core]
	repositoryformatversion = 0
	filemode = false
	bare = false
	logallrefupdates = true
	symlinks = false
	ignorecase = true

Dustin4444

'use strict';

import { expect } from "chai";
import { ethers } from "hardhat";

describe("Storage", function () {
  let storageContract;
  let owner;

  before(async () => {

Dustin4444

import "github.com/ethereum/dapp-bin/library/math.sol"; // source unit name: dapp-bin/library/math.sol

Dustin4444

26/04/30 21:35:32 WARN HangingThreadDetector: Potential Hung Thread Detected:
Thread ID: 1910
Thread name: SparkConnectExecuteThread_opId=6e78d900-bffd-4cb8-903b-554eb03722e7
Time Spent Hanging: 29399994 ms
Stuck at Frame: java.base@17.0.16/jdk.internal.misc.Unsafe.park(Native Method)
Latest Stack Trace:
java.base@17.0.16/jdk.internal.misc.Unsafe.park(Native Method)
	at java.base@17.0.16/java.util.concurrent.locks.LockSupport.park(LockSupport.java:211)
	at java.base@17.0.16/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:715)
	at java.base@17.0.16/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1047)

Dustin4444

{
  "contracts/1_Storage.sol": {
    "__sources__": {
      "contracts/1_Storage.sol": {
        "content": "// SPDX-License-Identifier: GPL-3.0\n\npragma solidity >=0.8.2 <0.9.0;\n\n/**\n * @title Storage\n * @dev Store & retrieve value in a variable\n * @custom:dev-run-script ./scripts/deploy_with_ethers.ts\n */\ncontract Storage {\n    uint256 number;\n\n    /**\n     * @dev Store value in variable\n     * @param num value to store\n     */\n    function store(uint256 num) public {\n        number = num;\n    }\n\n    /**\n     * @dev Return value\n     * @return value of 'number'\n     */\n    function retrieve() public view returns (uint256) {\n        return number;\n    }\n}\n",
        "file": "contracts/1_Storage.sol"
      }
    }
  },
  ".deps/remix-tests/remix_accounts.sol": {

Dustin4444

// SPDX-License-Identifier: GPL-3.0

pragma solidity >=0.7.0 <0.9.0;

import "hardhat/console.sol";

/**
 * @title Owner
 * @dev Set & change owner
 */

Dustin4444

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.