"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.8.0) (utils/Address.sol)\n\npragma solidity ^0.8.1;\n\n/**\n * @dev Collection of functions related to the address type\n */\nlibrary Address {\n    /**\n     * @dev Returns true if `account` is a contract.\n     *\n     * [IMPORTANT]\n     * ====\n     * It is unsafe to assume that an address for which this function returns\n     * false is an externally-owned account (EOA) and not a contract.\n     *\n     * Among others, `isContract` will return false for the following\n     * types of addresses:\n     *\n     *  - an externally-owned account\n     *  - a contract in construction\n     *  - an address where a contract will be created\n     *  - an address where a contract lived, but was destroyed\n     * ====\n     *\n     * [IMPORTANT]\n     * ====\n     * You shouldn't rely on `isContract` to protect against flash loan attacks!\n     *\n     * Preventing calls from contracts is highly discouraged. It breaks composability, breaks support for smart wallets\n     * like Gnosis Safe, and does not provide security since it can be circumvented by calling from a contract\n     * constructor.\n     * ====\n     */\n    function isContract(address account) internal view returns (bool) {\n        // This method relies on extcodesize/address.code.length, which returns 0\n        // for contracts in construction, since the code is only stored at the end\n        // of the constructor execution.\n\n        return account.code.length > 0;\n    }\n\n    /**\n     * @dev Replacement for Solidity's `transfer`: sends `amount` wei to\n     * `recipient`, forwarding all available gas and reverting on errors.\n     *\n     * https://eips.ethereum.org/EIPS/eip-1884[EIP1884] increases the gas cost\n     * of certain opcodes, possibly making contracts go over the 2300 gas limit\n     * imposed by `transfer`, making them unable to receive funds via\n     * `transfer`. {sendValue} removes this limitation.\n     *\n     * https://consensys.net/diligence/blog/2019/09/stop-using-soliditys-transfer-now/[Learn more].\n     *\n     * IMPORTANT: because control is transferred to `recipient`, care must be\n     * taken to not create reentrancy vulnerabilities. Consider using\n     * {ReentrancyGuard} or the\n     * https://solidity.readthedocs.io/en/v0.5.11/security-considerations.html#use-the-checks-effects-interactions-pattern[checks-effects-interactions pattern].\n     */\n    function sendValue(address payable recipient, uint256 amount) internal {\n        require(\n            address(this).balance >= amount,\n            \"Address: insufficient balance\"\n        );\n\n        (bool success, ) = recipient.call{value: amount}(\"\");\n        require(\n            success,\n            \"Address: unable to send value, recipient may have reverted\"\n        );\n    }\n\n    /**\n     * @dev Performs a Solidity function call using a low level `call`. A\n     * plain `call` is an unsafe replacement for a function call: use this\n     * function instead.\n     *\n     * If `target` reverts with a revert reason, it is bubbled up by this\n     * function (like regular Solidity function calls).\n     *\n     * Returns the raw returned data. To convert to the expected return value,\n     * use https://solidity.readthedocs.io/en/latest/units-and-global-variables.html?highlight=abi.decode#abi-encoding-and-decoding-functions[`abi.decode`].\n     *\n     * Requirements:\n     *\n     * - `target` must be a contract.\n     * - calling `target` with `data` must not revert.\n     *\n     * _Available since v3.1._\n     */\n    function functionCall(address target, bytes memory data)\n        internal\n        returns (bytes memory)\n    {\n        return\n            functionCallWithValue(\n                target,\n                data,\n                0,\n                \"Address: low-level call failed\"\n            );\n    }\n\n    /**\n     * @dev Same as {xref-Address-functionCall-address-bytes-}[`functionCall`], but with\n     * `errorMessage` as a fallback revert reason when `target` reverts.\n     *\n     * _Available since v3.1._\n     */\n    function functionCall(\n        address target,\n        bytes memory data,\n        string memory errorMessage\n    ) internal returns (bytes memory) {\n        return functionCallWithValue(target, data, 0, errorMessage);\n    }\n\n    /**\n     * @dev Same as {xref-Address-functionCall-address-bytes-}[`functionCall`],\n     * but also transferring `value` wei to `target`.\n     *\n     * Requirements:\n     *\n     * - the calling contract must have an ETH balance of at least `value`.\n     * - the called Solidity function must be `payable`.\n     *\n     * _Available since v3.1._\n     */\n    function functionCallWithValue(\n        address target,\n        bytes memory data,\n        uint256 value\n    ) internal returns (bytes memory) {\n        return\n            functionCallWithValue(\n                target,\n                data,\n                value,\n                \"Address: low-level call with value failed\"\n            );\n    }\n\n    /**\n     * @dev Same as {xref-Address-functionCallWithValue-address-bytes-uint256-}[`functionCallWithValue`], but\n     * with `errorMessage` as a fallback revert reason when `target` reverts.\n     *\n     * _Available since v3.1._\n     */\n    function functionCallWithValue(\n        address target,\n        bytes memory data,\n        uint256 value,\n        string memory errorMessage\n    ) internal returns (bytes memory) {\n        require(\n            address(this).balance >= value,\n            \"Address: insufficient balance for call\"\n        );\n        (bool success, bytes memory returndata) = target.call{value: value}(\n            data\n        );\n        return\n            verifyCallResultFromTarget(\n                target,\n                success,\n                returndata,\n                errorMessage\n            );\n    }\n\n    /**\n     * @dev Same as {xref-Address-functionCall-address-bytes-}[`functionCall`],\n     * but performing a static call.\n     *\n     * _Available since v3.3._\n     */\n    function functionStaticCall(address target, bytes memory data)\n        internal\n        view\n        returns (bytes memory)\n    {\n        return\n            functionStaticCall(\n                target,\n                data,\n                \"Address: low-level static call failed\"\n            );\n    }\n\n    /**\n     * @dev Same as {xref-Address-functionCall-address-bytes-string-}[`functionCall`],\n     * but performing a static call.\n     *\n     * _Available since v3.3._\n     */\n    function functionStaticCall(\n        address target,\n        bytes memory data,\n        string memory errorMessage\n    ) internal view returns (bytes memory) {\n        (bool success, bytes memory returndata) = target.staticcall(data);\n        return\n            verifyCallResultFromTarget(\n                target,\n                success,\n                returndata,\n                errorMessage\n            );\n    }\n\n    /**\n     * @dev Same as {xref-Address-functionCall-address-bytes-}[`functionCall`],\n     * but performing a delegate call.\n     *\n     * _Available since v3.4._\n     */\n    function functionDelegateCall(address target, bytes memory data)\n        internal\n        returns (bytes memory)\n    {\n        return\n            functionDelegateCall(\n                target,\n                data,\n                \"Address: low-level delegate call failed\"\n            );\n    }\n\n    /**\n     * @dev Same as {xref-Address-functionCall-address-bytes-string-}[`functionCall`],\n     * but performing a delegate call.\n     *\n     * _Available since v3.4._\n     */\n    function functionDelegateCall(\n        address target,\n        bytes memory data,\n        string memory errorMessage\n    ) internal returns (bytes memory) {\n        (bool success, bytes memory returndata) = target.delegatecall(data);\n        return\n            verifyCallResultFromTarget(\n                target,\n                success,\n                returndata,\n                errorMessage\n            );\n    }\n\n    /**\n     * @dev Tool to verify that a low level call to smart-contract was successful, and revert (either by bubbling\n     * the revert reason or using the provided one) in case of unsuccessful call or if target was not a contract.\n     *\n     * _Available since v4.8._\n     */\n    function verifyCallResultFromTarget(\n        address target,\n        bool success,\n        bytes memory returndata,\n        string memory errorMessage\n    ) internal view returns (bytes memory) {\n        if (success) {\n            if (returndata.length == 0) {\n                // only check isContract if the call was successful and the return data is empty\n                // otherwise we already know that it was a contract\n                require(isContract(target), \"Address: call to non-contract\");\n            }\n            return returndata;\n        } else {\n            _revert(returndata, errorMessage);\n        }\n    }\n\n    /**\n     * @dev Tool to verify that a low level call was successful, and revert if it wasn't, either by bubbling the\n     * revert reason or using the provided one.\n     *\n     * _Available since v4.3._\n     */\n    function verifyCallResult(\n        bool success,\n        bytes memory returndata,\n        string memory errorMessage\n    ) internal pure returns (bytes memory) {\n        if (success) {\n            return returndata;\n        } else {\n            _revert(returndata, errorMessage);\n        }\n    }\n\n    function _revert(bytes memory returndata, string memory errorMessage)\n        private\n        pure\n    {\n        // Look for revert reason and bubble it up if present\n        if (returndata.length > 0) {\n            // The easiest way to bubble the revert reason is using memory via assembly\n            /// @solidity memory-safe-assembly\n            assembly {\n                let returndata_size := mload(returndata)\n                revert(add(32, returndata), returndata_size)\n            }\n        } else {\n            revert(errorMessage);\n        }\n    }\n}\n"
    },
<EMAIL_ADDRESS>{
      "content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.9.0) (access/Ownable.sol)\n\npragma solidity ^0.8.0;\n\nimport \"../utils/Context.sol\";\n\n/**\n * @dev Contract module which provides a basic access control mechanism, where\n * there is an account (an owner) that can be granted exclusive access to\n * specific functions.\n *\n * By default, the owner account will be the one that deploys the contract. This\n * can later be changed with {transferOwnership}.\n *\n * This module is used through inheritance. It will make available the modifier\n * `onlyOwner`, which can be applied to your functions to restrict their use to\n * the owner.\n */\nabstract contract Ownable is Context {\n    address private _owner;\n\n    event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);\n\n    /**\n     * @dev Initializes the contract setting the deployer as the initial owner.\n     */\n    constructor() {\n        _transferOwnership(_msgSender());\n    }\n\n    /**\n     * @dev Throws if called by any account other than the owner.\n     */\n    modifier onlyOwner() {\n        _checkOwner();\n        _;\n    }\n\n    /**\n     * @dev Returns the address of the current owner.\n     */\n    function owner() public view virtual returns (address) {\n        return _owner;\n    }\n\n    /**\n     * @dev Throws if the sender is not the owner.\n     */\n    function _checkOwner() internal view virtual {\n        require(owner() == _msgSender(), \"Ownable: caller is not the owner\");\n    }\n\n    /**\n     * @dev Leaves the contract without owner. It will not be possible to call\n     * `onlyOwner` functions. Can only be called by the current owner.\n     *\n     * NOTE: Renouncing ownership will leave the contract without an owner,\n     * thereby disabling any functionality that is only available to the owner.\n     */\n    function renounceOwnership() public virtual onlyOwner {\n        _transferOwnership(address(0));\n    }\n\n    /**\n     * @dev Transfers ownership of the contract to a new account (`newOwner`).\n     * Can only be called by the current owner.\n     */\n    function transferOwnership(address newOwner) public virtual onlyOwner {\n        require(newOwner != address(0), \"Ownable: new owner is the zero address\");\n        _transferOwnership(newOwner);\n    }\n\n    /**\n     * @dev Transfers ownership of the contract to a new account (`newOwner`).\n     * Internal function without access restriction.\n     */\n    function _transferOwnership(address newOwner) internal virtual {\n        address oldOwner = _owner;\n        _owner = newOwner;\n        emit OwnershipTransferred(oldOwner, newOwner);\n    }\n}\n"
    },
<EMAIL_ADDRESS>{
      "content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.9.0) (token/ERC20/IERC20.sol)\n\npragma solidity ^0.8.0;\n\n/**\n * @dev Interface of the ERC20 standard as defined in the EIP.\n */\ninterface IERC20 {\n    /**\n     * @dev Emitted when `value` tokens are moved from one account (`from`) to\n     * another (`to`).\n     *\n     * Note that `value` may be zero.\n     */\n    event Transfer(address indexed from, address indexed to, uint256 value);\n\n    /**\n     * @dev Emitted when the allowance of a `spender` for an `owner` is set by\n     * a call to {approve}. `value` is the new allowance.\n     */\n    event Approval(address indexed owner, address indexed spender, uint256 value);\n\n    /**\n     * @dev Returns the amount of tokens in existence.\n     */\n    function totalSupply() external view returns (uint256);\n\n    /**\n     * @dev Returns the amount of tokens owned by `account`.\n     */\n    function balanceOf(address account) external view returns (uint256);\n\n    /**\n     * @dev Moves `amount` tokens from the caller's account to `to`.\n     *\n     * Returns a boolean value indicating whether the operation succeeded.\n     *\n     * Emits a {Transfer} event.\n     */\n    function transfer(address to, uint256 amount) external returns (bool);\n\n    /**\n     * @dev Returns the remaining number of tokens that `spender` will be\n     * allowed to spend on behalf of `owner` through {transferFrom}. This is\n     * zero by default.\n     *\n     * This value changes when {approve} or {transferFrom} are called.\n     */\n    function allowance(address owner, address spender) external view returns (uint256);\n\n    /**\n     * @dev Sets `amount` as the allowance of `spender` over the caller's tokens.\n     *\n     * Returns a boolean value indicating whether the operation succeeded.\n     *\n     * IMPORTANT: Beware that changing an allowance with this method brings the risk\n     * that someone may use both the old and the new allowance by unfortunate\n     * transaction ordering. One possible solution to mitigate this race\n     * condition is to first reduce the spender's allowance to 0 and set the\n     * desired value afterwards:\n     * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729\n     *\n     * Emits an {Approval} event.\n     */\n    function approve(address spender, uint256 amount) external returns (bool);\n\n    /**\n     * @dev Moves `amount` tokens from `from` to `to` using the\n     * allowance mechanism. `amount` is then deducted from the caller's\n     * allowance.\n     *\n     * Returns a boolean value indicating whether the operation succeeded.\n     *\n     * Emits a {Transfer} event.\n     */\n    function transferFrom(address from, address to, uint256 amount) external returns (bool);\n}\n"
    },
<EMAIL_ADDRESS>{
      "content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts v4.4.1 (utils/Context.sol)\n\npragma solidity ^0.8.0;\n\n/**\n * @dev Provides information about the current execution context, including the\n * sender of the transaction and its data. While these are generally available\n * via msg.sender and msg.data, they should not be accessed in such a direct\n * manner, since when dealing with meta-transactions the account sending and\n * paying for execution may not be the actual sender (as far as an application\n * is concerned).\n *\n * This contract is only required for intermediate, library-like contracts.\n */\nabstract contract Context {\n    function _msgSender() internal view virtual returns (address) {\n        return msg.sender;\n    }\n\n    function _msgData() internal view virtual returns (bytes calldata) {\n        return msg.data;\n    }\n}\n"
    },
    "contracts/ApprovalPaymaster.sol": {
      "content": "// SPDX-License-Identifier: MIT\npragma solidity ^0.8.0;\n\nimport {IPaymaster, ExecutionResult, PAYMASTER_VALIDATION_SUCCESS_MAGIC} from \"@matterlabs/zksync-contracts/l2/system-contracts/interfaces/IPaymaster.sol\";\nimport {IPaymasterFlow} from \"@matterlabs/zksync-contracts/l2/system-contracts/interfaces/IPaymasterFlow.sol\";\nimport {TransactionHelper, Transaction} from \"@matterlabs/zksync-contracts/l2/system-contracts/libraries/TransactionHelper.sol\";\n\nimport \"@matterlabs/zksync-contracts/l2/system-contracts/Constants.sol\";\n\nimport \"@openzeppelin/contracts/token/ERC20/IERC20.sol\";\nimport \"@openzeppelin/contracts/access/Ownable.sol\";\n\n/// @author Matter Labs\n/// @notice This smart contract pays the gas fees for accounts with balance of a specific ERC20 token. It makes use of the approval-based flow paymaster.\ncontract ApprovalPaymaster is IPaymaster, Ownable {\n    uint256 constant PRICE_FOR_PAYING_FEES = 1;\n\n    address public allowedToken;\n\n    modifier onlyBootloader() {\n        require(\n            msg.sender == BOOTLOADER_FORMAL_ADDRESS,\n            \"Only bootloader can call this method\"\n        );\n        // Continue execution if called from the bootloader.\n        _;\n    }\n\n    constructor(address _erc20) {\n        allowedToken = _erc20;\n    }\n\n    function validateAndPayForPaymasterTransaction(\n        bytes32,\n        bytes32,\n        Transaction calldata _transaction\n    )\n        external\n        payable\n        onlyBootloader\n        returns (bytes4 magic, bytes memory context)\n    {\n        // By default we consider the transaction as accepted.\n        magic = PAYMASTER_VALIDATION_SUCCESS_MAGIC;\n        require(\n            _transaction.paymasterInput.length >= 4,\n            \"The standard paymaster input must be at least 4 bytes long\"\n        );\n\n        bytes4 paymasterInputSelector = bytes4(\n            _transaction.paymasterInput[0:4]\n        );\n        // Approval based flow\n        if (paymasterInputSelector == IPaymasterFlow.approvalBased.selector) {\n            // While the transaction data consists of address, uint256 and bytes data,\n            // the data is not needed for this paymaster\n            (address token, uint256 amount, bytes memory data) = abi.decode(\n                _transaction.paymasterInput[4:],\n                (address, uint256, bytes)\n            );\n\n            // Verify if token is the correct one\n            require(token == allowedToken, \"Invalid token\");\n\n            // We verify that the user has provided enough allowance\n            address userAddress = address(uint160(_transaction.from));\n\n            address thisAddress = address(this);\n\n            uint256 providedAllowance = IERC20(token).allowance(\n                userAddress,\n                thisAddress\n            );\n            require(\n                providedAllowance >= PRICE_FOR_PAYING_FEES,\n                \"Min allowance too low\"\n            );\n\n            // Note, that while the minimal amount of ETH needed is tx.gasPrice * tx.gasLimit,\n            // neither paymaster nor account are allowed to access this context variable.\n            uint256 requiredETH = _transaction.gasLimit *\n                _transaction.maxFeePerGas;\n\n            try\n                IERC20(token).transferFrom(userAddress, thisAddress, amount)\n            {} catch (bytes memory revertReason) {\n                // If the revert reason is empty or represented by just a function selector,\n                // we replace the error with a more user-friendly message\n                if (revertReason.length <= 4) {\n                    revert(\"Failed to transferFrom from users' account\");\n                } else {\n                    assembly {\n                        revert(add(0x20, revertReason), mload(revertReason))\n                    }\n                }\n            }\n\n            // The bootloader never returns any data, so it can safely be ignored here.\n            (bool success, ) = payable(BOOTLOADER_FORMAL_ADDRESS).call{\n                value: requiredETH\n            }(\"\");\n            require(\n                success,\n                \"Failed to transfer tx fee to the bootloader. Paymaster balance might not be enough.\"\n            );\n        } else {\n            revert(\"Unsupported paymaster flow\");\n        }\n    }\n\n    function postTransaction(\n        bytes calldata _context,\n        Transaction calldata _transaction,\n        bytes32,\n        bytes32,\n        ExecutionResult _txResult,\n        uint256 _maxRefundedGas\n    ) external payable override onlyBootloader {}\n\n    function withdraw(address _to) external onlyOwner {\n        (bool success, ) = payable(_to).call{value: address(this).balance}(\"\");\n        require(success, \"Failed to withdraw funds from paymaster.\");\n    }\n\n    receive() external payable {}\n}\n"
    },
    "contracts/GeneralPaymaster.sol": {
      "content": "// SPDX-License-Identifier: MIT\npragma solidity ^0.8.0;\n\nimport {IPaymaster, ExecutionResult, PAYMASTER_VALIDATION_SUCCESS_MAGIC} from \"@matterlabs/zksync-contracts/l2/system-contracts/interfaces/IPaymaster.sol\";\nimport {IPaymasterFlow} from \"@matterlabs/zksync-contracts/l2/system-contracts/interfaces/IPaymasterFlow.sol\";\nimport {TransactionHelper, Transaction} from \"@matterlabs/zksync-contracts/l2/system-contracts/libraries/TransactionHelper.sol\";\n\nimport \"@matterlabs/zksync-contracts/l2/system-contracts/Constants.sol\";\n\nimport \"@openzeppelin/contracts/access/Ownable.sol\";\n\n/// @author Matter Labs\n/// @notice This contract does not include any validations other than using the paymaster general flow.\ncontract GeneralPaymaster is IPaymaster, Ownable {\n    modifier onlyBootloader() {\n        require(\n            msg.sender == BOOTLOADER_FORMAL_ADDRESS,\n            \"Only bootloader can call this method\"\n        );\n        // Continue execution if called from the bootloader.\n        _;\n    }\n\n    function validateAndPayForPaymasterTransaction(\n        bytes32,\n        bytes32,\n        Transaction calldata _transaction\n    )\n        external\n        payable\n        onlyBootloader\n        returns (bytes4 magic, bytes memory context)\n    {\n        // By default we consider the transaction as accepted.\n        magic = PAYMASTER_VALIDATION_SUCCESS_MAGIC;\n        require(\n            _transaction.paymasterInput.length >= 4,\n            \"The standard paymaster input must be at least 4 bytes long\"\n        );\n\n        bytes4 paymasterInputSelector = bytes4(\n            _transaction.paymasterInput[0:4]\n        );\n        if (paymasterInputSelector == IPaymasterFlow.general.selector) {\n            // Note, that while the minimal amount of ETH needed is tx.gasPrice * tx.gasLimit,\n            // neither paymaster nor account are allowed to access this context variable.\n            uint256 requiredETH = _transaction.gasLimit *\n                _transaction.maxFeePerGas;\n\n            // The bootloader never returns any data, so it can safely be ignored here.\n            (bool success, ) = payable(BOOTLOADER_FORMAL_ADDRESS).call{\n                value: requiredETH\n            }(\"\");\n            require(\n                success,\n                \"Failed to transfer tx fee to the Bootloader. Paymaster balance might not be enough.\"\n            );\n        } else {\n            revert(\"Unsupported paymaster flow in paymasterParams.\");\n        }\n    }\n\n    function postTransaction(\n        bytes calldata _context,\n        Transaction calldata _transaction,\n        bytes32,\n        bytes32,\n        ExecutionResult _txResult,\n        uint256 _maxRefundedGas\n    ) external payable override onlyBootloader {}\n\n    function withdraw(address payable _to) external onlyOwner {\n        uint256 balance = address(this).balance;\n        (bool success, ) = _to.call{value: balance}(\"\");\n        require(success, \"Failed to withdraw funds from paymaster.\");\n    }\n\n    receive() external payable {}\n}\n"
    },
    "contracts/Greeter.sol": {
      "content": "//SPDX-License-Identifier: Unlicense\npragma solidity ^0.8.0;\n\ncontract Greeter {\n    string private greeting;\n\n    constructor(string memory _greeting) {\n        greeting = _greeting;\n    }\n\n    function greet() public view returns (string memory) {\n        return greeting;\n    }\n\n    function setGreeting(string memory _greeting) public {\n        greeting = _greeting;\n    }\n}\n"
    }
  },
  "settings": {
    "viaIR": true,
    "optimizer": {
      "enabled": true,
      "mode": "3"
    },
    "outputSelection": {
      "*": {
        "": [
          "ast"
        ],
        "*": [
          "evm.legacyAssembly",
          "abi",
          "metadata",
          "devdoc",
          "userdoc",
          "storageLayout",
          "evm.methodIdentifiers"
        ]
      }
    },
    "libraries": {}
  }
}

@qiaoxrcn I've checked your input.
Apparently, solc has produced compile-time errors.
That's why you don't see any output apart from AST.

@qiaoxrcn I've checked your input. Apparently, solc has produced compile-time errors. That's why you don't see any output apart from AST.
You've reached the EVM stack limit of 16 slots, so by no means you can get an EVMLA representation for that.

Thanks!
CompilerError: Stack too deep. Try compiling with `--via-ir` (cli) or the equivalent `viaIR: true` (standard JSON) while enabling the optimizer. Otherwise, try removing local variables.
   --> @matterlabs/zksync-contracts/l2/system-contracts/BootloaderUtilities.sol:104:34:
    |
104 |             uint256 listLength = encodedNonce.length +
    |                                  ^^^^^^^^^^^^

Error HH600: Compilation failed

For more info go to https://hardhat.org/HH600 or run Hardhat with --show-stack-traces

generated by zksolc:
evm":{
"legacyAssembly":{
  ".auxdata":null,".code":[
  {"name":"PUSH","value":"80"},
  {"name":"PUSH","value":"40"}
...

generated by solc:
{".code":
[
{"begin":62,"end":378,"name":"PUSH","source":0,"value":"80"},
...

Why missing fileds begin,end,source?

Just to save space as we have never used them. Is it crucial?

Just to save space as we have never used them. Is it crucial?

Ha, they are important to solidity-now. May I request to put these fields back?

Just to save space as we have never used them. Is it crucial?

Ha, they are important to solidity-now. May I request to put these fields back?

Sure.
But you can use solc to get this output for now, correct?

Just to save space as we have never used them. Is it crucial?

Ha, they are important to solidity-now. May I request to put these fields back?

Sure. But you can use solc to get this output for now, correct?

Yes,  output generated by zksolc v1.3.15 contains evm.legacyAssembly now.
Additionally, there is another issue unrelated to this pull request. The contract you just mentioned, which reached the EVM stack limit of 16 slots, comes from official system contracts.
@matterlabs/zksync-contracts/l2/system-contracts/BootloaderUtilities.sol:104:34 .
Should we fix this contract?

Just to save space as we have never used them. Is it crucial?

Ha, they are important to solidity-now. May I request to put these fields back?

Sure. But you can use solc to get this output for now, correct?

Yes,  output generated by zksolc v1.3.15 contains evm.legacyAssembly now.
Additionally, there is another issue unrelated to this pull request. The contract you just mentioned, which reached the EVM stack limit of 16 slots, comes from official system contracts.
@matterlabs/zksync-contracts/l2/system-contracts/BootloaderUtilities.sol:104:34 .
Should we fix this contract?

No, system contracts are only supposed to be compiled by zksolc via Yul. Not any other way.

Just to save space as we have never used them. Is it crucial?

Ha, they are important to solidity-now. May I request to put these fields back?

Sure. But you can use solc to get this output for now, correct?

Yes,  output generated by zksolc v1.3.15 contains evm.legacyAssembly now.
Additionally, there is another issue unrelated to this pull request. The contract you just mentioned, which reached the EVM stack limit of 16 slots, comes from official system contracts.
@matterlabs/zksync-contracts/l2/system-contracts/BootloaderUtilities.sol:104:34 .
Should we fix this contract?

No, system contracts are only supposed to be compiled by zksolc via Yul. Not any other way.

Got it. Thanks a lot !

@qiaoxrcn the fields have been added in the latest release (v1.3.16).

@qiaoxrcn the fields have been added in the latest release (v1.3.16).

Thanks! It works now.


[Bug]: MySQL sync issues

Is there an existing issue for this?

[ ] I have searched the existing issues

Have you tried to reproduce this without OP?

[X] I have tested without OP

Current Behavior
Start MySQL save mode In BungeeCord Server.
Data can be lost in many cases.
After repeated testing up to hundreds of times.

If player connects to the server when the server is shut down, his data will be completely lost.
When the server is whitelisted, players trying to log in to the server will cause complete data loss.
If periodic saving is turned on, the same problem will occur.
If periodic saving is turned on, when players move across servers that synchronize data, have small chance data will be completely lost.

Expected Behavior
Hope to add a way to save to solve the problem.
Or add a regular data retrospective function, which can easily help players recover lost data.
Steps To Reproduce
Start MySQL save mode In BungeeCord Server.
Data can be lost in many cases.
After repeated testing up to hundreds of times.

If player connects to the server when the server is shut down, his data will be completely lost.
Simple test method: lobby server -> test server
When the server is whitelisted, players trying to log in to the server will cause complete data loss.
Simple test method: lobby server -> test server
If periodic saving is turned on, the same problem will occur.
If periodic saving is turned on, when players move across servers that synchronize data, have small chance data will be completely lost.
Simple test method: test1 server (use proskillapi server) -> test2 server (use proskillapi server)

Environment
- Server Software: PaperSpigot 1.16.5
- ProSkillAPI Version: <IP_ADDRESS>-1330
- ProMCCore Version: <IP_ADDRESS>-1150257
- Plugins: Essentials, Itemizer, Vault, TabList, Core, PlaceholderAPI, CMILib, GroupManager, ProMCCore, Multiverse-Core, LibsDisguises, InventorySaver, BetterGUI, Vulcan, Residence, MythicMobs, Citizens, ProSkillAPI, ProtocolLib

latest.log
latest.log

# paste log here...

Anything else?
If the delayed loading of data is not enabled, If player try to restart the server without completely restarting the server. When logging in, it will cause the plugin to load the data abnormally, and then cause the server to crash without responding.

I'm a bit confused here. Are you installing ProSkillAPI on the Bungee instance? The SQL implementation does need work, but if you're installing on Bungee and trying to sync without an online server to join, I'm not sure that this would actually function as you intend.

I'm a bit confused here. Are you installing ProSkillAPI on the Bungee instance? The SQL implementation does need work, but if you're installing on Bungee and trying to sync without an online server to join, I'm not sure that this would actually function as you intend.

I installed proskillapi on the subserver under Bungee.
And enable MySQL to store player data.
problems described above all occur when proskillapi is installed on the sub-server to synchronize data.
Synchronized data is often lost accidentally.

Detailed descriptions of certain parts.

When the server is closed, there will be a period of time to execute the shutdown. During that time, the player can still try to connect to the server. If the player tries to connect, it will cause data loss.

After the server has been running for a long time.
Then execute the normal shutdown command, and after restarting the server, sometimes it is found that some player's data is accidentally lost.
It's unclear why.

@ReverseAllen Sorry this has been so long. I'm not convinced the code I just pushed will fix this. More particularly, it may fix the server-closing issue. Probably not the random data loss on shutdown. Feel free to give the new build a try though and let me know.

When the server is whitelisted, players trying to log in to the server will cause complete data loss.
This problem still exists.
@Travja

Ah! @ReverseAllen huge! That's a solid way to reproduce this! Thank you!

Ah! @ReverseAllen huge! That's a solid way to reproduce this! Thank you!

A clearer way to test and reproduce.
Should be whitelist enable server.
Players who are not included in the whitelist will be blocked from entering.
Then if the player tries to connect and log in, all data will be lost.

D9es it matter what whitelist it is? Defaukt minecraft one or plugin based

Whitelist for Minecraft itself.
How to reproduce:

player is't in whitelist
The player connects to the server that starts the whitelist.
data loser

Supplement: This method is when the server restarts
When the plug-in is unloading or loading, the problem is triggered by the player performing related operations.

Currently using the latest development version
The problem of user data loss continues to occur.
After shutting down the server normally and restarting it, it is always found that some user data is inexplicably lost.
There are also attempts to let the players log out of the server first, then shut down the server and restart it, but data loss still occurs.

So someone always gets their data wiped when the server restarts? Are they getting kicked back to a hub server (and does the hub have SkillAPI installed)? or just disconnected? If it's not their entire player data, what all is lost?

close server error.
what is this problem?
[11:57:02 ERROR]: Error occurred while disabling ProSkillAPI v1.1.8-R0.10-SNAPSHOT (Is it up to date?)
java.lang.NullPointerException: Cannot invoke "com.sucy.skill.api.player.PlayerAccounts.getPlayer()" because "data" is null
at com.sucy.skill.data.io.IOManager.save(IOManager.java:356) ~[?:?]
at com.sucy.skill.data.io.SQLIO.saveSingle(SQLIO.java:133) ~[?:?]
at com.sucy.skill.data.io.SQLIO.saveAll(SQLIO.java:116) ~[?:?]
at com.sucy.skill.SkillAPI.onDisable(SkillAPI.java:593) ~[?:?]
at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:265) ~[patched_1.16.5.jar:git-Paper-794]
at org.bukkit.plugin.java.JavaPluginLoader.disablePlugin(JavaPluginLoader.java:405) ~[patched_1.16.5.jar:git-Paper-794]
at org.bukkit.plugin.SimplePluginManager.disablePlugin(SimplePluginManager.java:533) ~[patched_1.16.5.jar:git-Paper-794]
at org.bukkit.plugin.SimplePluginManager.disablePlugins(SimplePluginManager.java:519) ~[patched_1.16.5.jar:git-Paper-794]
at org.bukkit.plugin.SimplePluginManager.disablePlugins(SimplePluginManager.java:512) ~[patched_1.16.5.jar:git-Paper-794]
at org.bukkit.craftbukkit.v1_16_R3.CraftServer.disablePlugins(CraftServer.java:452) ~[patched_1.16.5.jar:git-Paper-794]
at net.minecraft.server.v1_16_R3.MinecraftServer.stop(MinecraftServer.java:906) ~[patched_1.16.5.jar:git-Paper-794]
at net.minecraft.server.v1_16_R3.DedicatedServer.stop(DedicatedServer.java:763) ~[patched_1.16.5.jar:git-Paper-794]
at net.minecraft.server.v1_16_R3.MinecraftServer.w(MinecraftServer.java:1182) ~[patched_1.16.5.jar:git-Paper-794]
at net.minecraft.server.v1_16_R3.MinecraftServer.lambda$a$0(MinecraftServer.java:291) ~[patched_1.16.5.jar:git-Paper-794]
at java.lang.Thread.run(Thread.java:831) [?:?]

In the case of using MySQL storage mode.
The autosave problem still causes player data to be lost unexpectedly.
When a player transfers across servers on a sub-server with proskillapi installed, there is a chance that the data will be completely lost.
Maybe the problem is that the auto-save process is also in progress when the player crosses servers, causing some kind of read conflict.
The easiest way to restore is to set the auto-save time to a very low value, and then repeatedly perform cross-server transfers between the two servers to reproduce the problem.

I've just found where the problem is:

The data was saved, but the InventoryCloseEvent fired.
The data was loaded again.
The data will be kept in this server, and anything will be rollbacked if the data is saved.

Some tests:

Oh interesting. I'll have to do some digging and verifying that so I can see what I can do. Thanks for your sharp eye!

Wait so what are you saying needs to be changed then?

Add an early-return statement for checking isn't ALLOWED.

Oh I see, you were showing modified code, not the code at present. If you want to just create a PR, that would be a great help!

Sorry I have about zero experience with GitHub.
Please do that 4 me, thanks a lot.

Hello @Travja, I just lead you to the wrong way to fix the "whitelist" error,
sorry about that.
It seems like login result will always be ALLOWED in AsyncPreLoginEvent
So, the modified correct code should be:


mountSignUp not loading the locales

Preliminary Checks

[X] I have reviewed the documentation: https://clerk.com/docs
[X] I have searched for existing issues: https://github.com/clerk/javascript/issues
[X] I have not already reached out to Clerk support via email or Discord (if you have, no need to open an issue here)
[X] This issue is not a question, general help request, or anything other than a bug report directly related to Clerk. Please ask questions in our Discord community: https://clerk.com/discord.

Reproduction / Replay Link
https://codeshare.io/oQ9yXp
Publishable key
pk_test_bWludC1oYW1zdGVyLTIyLmNsZXJrLmFjY291bnRzLmRldiQ
Description
Steps to reproduce:

Try to render the signup component with localization

Expected behavior:
it should load the text in Spanish instead of English even if we are using a local object given by clerk team
    import { esES } from "@clerk/localizations";
    await clerk?.load({ localization: esES });
    clerk?.mountSignUp(containerRef.current, {
      afterSignUpUrl: window.origin + "/handshake",
      signInUrl: window.origin + "/login",
      redirectUrl: window.origin + "/handshake",
    });

Actual behavior:
it is always loading the text in English
Environment
System:
    OS: Windows 10 10.0.22621
    CPU: (16) x64 AMD Ryzen 7 5700U with Radeon Graphics
    Memory: 6.85 GB / 15.39 GB
  Binaries:
    Node: 18.13.0 - C:\Program Files\nodejs\node.EXE
    npm: 9.8.1 - ~\work\clibot\web-saas-ui\node_modules\.bin\npm.CMD
  Browsers:
    Edge: Chromium (120.0.2210.91)
    Internet Explorer: 11.0.22621.1
  npmPackages:
    @chakra-ui/icons: ^2.0.18 => 2.1.0
    @chakra-ui/react: ^2.5.5 => 2.8.0
    @clerk/clerk-react: ^4.26.3 => 4.26.3
    @clerk/localizations: ^1.26.13 => 1.26.13
    @clerk/themes: ^1.7.9 => 1.7.9
    @emotion/react: ^11.10.6 => 11.11.1
    @emotion/styled: ^11.10.6 => 11.11.0
    @faker-js/faker: ^8.0.2 => 8.0.2
    @fseehawer/react-circular-slider: ^2.6.1 => 2.6.1
    @react-oauth/google: ^0.11.0 => 0.11.0
    @release-it/conventional-changelog: ^7.0.2 => 7.0.2
    @rematch/core: ^2.2.0 => 2.2.0
    @rematch/immer: ^2.1.3 => 2.1.3
    @rematch/loading: ^2.1.2 => 2.1.2
    @rematch/persist: ^2.1.2 => 2.1.2
    @rematch/select: ^3.1.2 => 3.1.2
    @rematch/updated: ^2.1.2 => 2.1.2
    @segment/analytics-next: ^1.58.0 => 1.58.0
    @sentry/react: ^7.85.0 => 7.85.0
    @stripe/react-stripe-js: ^2.4.0 => 2.4.0
    @tanstack/query-sync-storage-persister: ^4.15.1 => 4.32.0
    @tanstack/react-query-persist-client: ^4.16.1 => 4.32.0
    @tanstack/react-table: ^8.8.5 => 8.9.3
    @tanstack/react-virtual: ^3.0.0-beta.54 => 3.0.0-beta.54
    @testing-library/react: ^13.4.0 => 13.4.0
    @types/jest: ^29.5.2 => 29.5.3
    @types/mocha: ^10.0.1 => 10.0.1
    @types/node: ^18.11.9 => 18.16.19
    @types/react: ^18.0.24 => 18.2.15
    @types/react-color: ^3.0.6 => 3.0.6
    @types/react-copy-to-clipboard: ^5.0.4 => 5.0.4
    @types/react-dom: ^18.0.8 => 18.2.7
    @types/react-highlight: ^0.12.5 => 0.12.5
    @types/segment-analytics: ^0.0.35 => 0.0.35
    @typescript-eslint/eslint-plugin: ^5.42.1 => 5.62.0
    @typescript-eslint/parser: ^5.42.1 => 5.62.0
    @vitejs/plugin-react: ^2.2.0 => 2.2.0
    @vitest/coverage-c8: ^0.25.1 => 0.25.8
    axios: ^1.1.3 => 1.4.0
    chakra-dayzed-datepicker: ^0.2.10 => 0.2.10
    chart.js: ^4.3.0 => 4.3.0
    chartjs-adapter-date-fns: ^3.0.0 => 3.0.0
    cypress: ^12.17.0 => 12.17.2
    cypress-iframe: ^1.0.1 => 1.0.1
    date-fns: ^2.30.0 => 2.30.0
    dayzed: ^3.2.3 => 3.2.3
    eslint: ^8.27.0 => 8.45.0
    eslint-config-airbnb: ^19.0.4 => 19.0.4
    eslint-config-node: ^4.1.0 => 4.1.0
    eslint-config-prettier: ^8.5.0 => 8.8.0
    eslint-config-react-app: ^7.0.1 => 7.0.1
    eslint-plugin-cypress: ^2.14.0 => 2.14.0
    eslint-plugin-import: ^2.26.0 => 2.27.5
    eslint-plugin-jsx-a11y: ^6.6.1 => 6.7.1
    eslint-plugin-node: ^11.1.0 => 11.1.0
    eslint-plugin-prettier: ^4.2.1 => 4.2.1
    eslint-plugin-react: ^7.31.10 => 7.33.0
    eslint-plugin-react-hooks: ^4.3.0 => 4.6.0
    eslint-plugin-simple-import-sort: ^8.0.0 => 8.0.0
    firebase: ^10.0.0 => 10.3.0
    formik: ^2.2.9 => 2.4.2
    framer-motion: ^10.11.6 => 10.13.0
    husky: ^8.0.3 => 8.0.3
    immer: ^9.0.21 => 9.0.21
    jsdom: ^20.0.2 => 20.0.3
    json-2-csv: ^5.0.1 => 5.0.1
    moment: ^2.29.4 => 2.29.4
    monsterbot-sdk: github:Baliza-IT-Consultancy/Caleida-Core-SDK => 1.1.4
    npm: ^9.6.5 => 9.8.1
    path: ^0.12.7 => 0.12.7
    prettier: ^2.7.1 => 2.8.8
    rc-upload: ^4.3.4 => 4.3.4
    react: ^18.2.0 => 18.2.0
    react-chartjs-2: ^5.2.0 => 5.2.0
    react-circular-progressbar: 2.1.0 => 2.1.0
    react-color: ^2.19.3 => 2.19.3
    react-copy-to-clipboard: ^5.1.0 => 5.1.0
    react-date-range: ^1.4.0 => 1.4.0
    react-dom: ^18.2.0 => 18.2.0
    react-google-recaptcha-v3: ^1.10.1 => 1.10.1
    react-highlight: ^0.15.0 => 0.15.0
    react-highlight-within-textarea: ^3.1.1 => 3.2.1
    react-i18next: ^12.3.1 => 12.3.1
    react-icons: ^4.8.0 => 4.10.1
    react-joyride: ^2.7.0 => 2.7.0
    react-markdown: ^8.0.7 => 8.0.7
    react-phone-input-2: ^2.15.1 => 2.15.1
    react-query: ^3.39.2 => 3.39.3
    react-redux: ^8.0.5 => 8.1.1
    react-router-dom: ^6.4.3 => 6.14.2
    react-select: ^5.7.2 => 5.7.4
    react-tag-input-component: ^2.0.2 => 2.0.2
    react-tagsinput: ^3.20.3 => 3.20.3
    reactour: ^1.19.2 => 1.19.2
    redux-persist: ^6.0.0 => 6.0.0
    remark-breaks: ^3.0.3 => 3.0.3
    timeago-react: ^3.0.6 => 3.0.6
    typescript: ^4.6.4 => 4.9.5
    vite: ^3.2.3 => 3.2.7
    vite-plugin-eslint: ^1.8.1 => 1.8.1
    vite-tsconfig-paths: ^3.5.2 => 3.6.0
    vitest: ^0.25.1 => 0.25.8

Hi!
Sorry to hear you're running into an issue. To help us best begin debugging the underlying cause, it is incredibly helpful if you're able to create a minimal reproduction. This is a simplified example of the issue that makes it clear and obvious what the issue is and how we can begin to debug it.
If you're up for it, we'd very much appreciate if you could provide a minimal reproduction and we'll be able to take another look.
Thanks for using Clerk!

hey @LekoArts ,this the main implementation it's  a react-vite project
import { chakra, Flex, Link, Stack, Text } from "@chakra-ui/react";
import {   esES } from "@clerk/localizations";
import { sdk } from "@configs/index";
import { colors } from "@constants/colors";
import { useEffect, useRef } from "react";

function SignupPage() {
  const _c = sdk?.clerk; // just the clerk instance
  const containerRef = useRef<HTMLDivElement>(null);
  // const lang = navigator.language || (navigator as any)?.userLanguage;
  const mountSignup = async () => {
    if (containerRef.current == null) return;
    await _c?.load({ localization: esES });
    _c?.mountSignUp(containerRef.current, {
      afterSignUpUrl: window.origin + "/handshake",
      signInUrl: window.origin + "/login",
      redirectUrl: window.origin + "/handshake",
    });
    return;
  };

  useEffect(() => {
    mountSignup();
    return () => {
      containerRef?.current && _c?.unmountSignIn(containerRef?.current);
    };
  }, [ ]);

  return (
    <Stack bg={colors.bg_5} minH={"100vh"} align={"center"} justify={"center"}>

    </Stack>
  );
}

export default SignupPage;

In an effort to keep our GitHub issues clean and focused, we close any issues that are awaiting a reproduction after 8 days on inactivity, and it has been 7 days. This issue will be closed tomorrow unless a reproduction is produced. If it takes longer than this to get a reproduction, that's ok, just drop a comment and we will re-open the issue then.
Thanks for being a part of the Clerk community! 🙏

Hey 👋 Please post your full minimal reproduction (a GitHub repository) as often such errors can't be replicated from just a single code snippet. Thanks!

Hey 👋 Please post your full minimal reproduction (a GitHub repository) as often such errors can't be replicated from just a single code snippet. Thanks!

sure I will try to make a small vite app for the same

@souvik666 What's preventing you from using the <ClerkProvider/> ?

Is it possible to give us access to your repo or create a similar one and share that with us.
I've been doing this, in one of my personal apps for a while and I'm certain that it works.
<ClerkProvider localization={enGR}>
 {...}
</ClerkProvider>

Is it possible to give us access to your repo or create a similar one and share that with us.
I've been doing this, in one of my personal apps for a while and I'm certain that it works.
<ClerkProvider localization={enGR}>
 {...}
</ClerkProvider>

I have tried it it might be a issue that i’M using the js sdk in react after changing the whole to react package it’s working fine

One more thing
If you wish to load clerk from clerk-js and then also use the provider you can pass the clerk instance to ClerkProvider via the Clerk={} prop. But i don't think it does not worth the trouble :)

One more thing
If you wish to load clerk from clerk-js and then also use the provider you can pass the clerk instance to ClerkProvider via the Clerk={} prop. But i don't think it does not worth the trouble :)

Have done the same way with locals prop no luck anyway now it’s working fine


Feature/52 docker integration

Regarding issue #57, this PR has tests integrated to test public and admin DRS functionalities, mainly for the docker integration step for the GitHub actions.

Codecov Report

Merging #58 (84a99ac) into develop (809682b) will decrease coverage by 0.16%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             develop      #58      +/-   ##
=============================================
- Coverage      95.99%   95.83%   -0.17%
+ Complexity       256      255       -1
=============================================
  Files             32       32
  Lines            624      624
  Branches          38       38
=============================================
- Hits             599      598       -1
  Misses            19       19
- Partials           6        7       +1

Impacted Files
Coverage Δ

.../org/ga4gh/starterkit/drs/controller/DrsAdmin.java
95.65% <ø> (ø)

...arterkit/drs/utils/hibernate/DrsHibernateUtil.java
82.92% <0.00%> (-2.44%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 809682b...84a99ac. Read the comment docs.


build: unable to parse COPY --chown flag in Dockerfile

Nice project, loving the idea of a containerd based docker alternative. While trying it out I ran into some issues, one being some of the flags on COPY cause errors trying to build images:
  30 | >>> COPY --chown=
--------------------
error: failed to solve: dockerfile parse error on line 30: COPY requires at least two arguments, but only one was provided. Destination could not be determined.

I have a dockerfiles with 2 stage build, in images with only --from= it seems to work, but --chown and --from together don't (didn't try --chown= alone) but image builds fine with docker.
Dockerfile reference doc: https://docs.docker.com/engine/reference/builder/#copy
Version info:
nerdctl version
Client:
 Version:	v0.12.1
 Git commit:	6f0c8b7bc63270404c9f5810a899e6bae7546608
Server:
 containerd:
  Version:	v1.5.7
  GitCommit:	8686ededfc90076914c5238eb96c883ea093a8ba

Please report to https://github.com/moby/buildkit/issues with the version info of buildkitd


Should we use C++ for kernel implementation?

Certainly we can. But do we really need it? What are the implications?
More to read here: http://wiki.osdev.org/C++

The way I see it this choice mostly depends on the desired project scale.
What exactly are the advantages of C++ over plain C, that make sense at kernel level?
The nice advantages of C++:

Classes over structures, inheritance, virtual functions, interfaces, polymorphism.
This one requires no runtime support, so we'd get this for free. This may hopefully lead to some (nice?) OOP, provided we spend enough effort carefully designing interfaces. Polymorphism might be useful as well, especially in places where we would like to separate implementation from interface, so eg. hardware drivers
Most of such features can be simulated in C (function pointers in structures, conversion procedures), so this advantage is mostly the same as the following one.
More elegant language-level syntax.
I guess this one is clear: C++ has con/destructors, automatic virtual calls, type conversions, operator overloading and a lot of goodies which are not really anything that was not achievable in C, but make the code so much nicer to read.
STL (at least data structures).
Requires porting, which means extra effort before we would start actual work, but provides probably all data structures we might ever need.
Note that writing basic data structures in C is not that much effort as it may seem like, and the complex ones (if needed) can be borrowed from existing implementations.

The not-so-nice advantages:

Memory management.
new/delete require runtime support, which may boil down to malloc/free, so not really an advantage over C. Requires careful use before paging and memory management is ready.
Exception support.
Exceptions require runtime support, and therefore are not usable ootb. Furthermore, I have a hunch that the use of exceptions mixed with context switching and interrupts may create a lot of confusion, and end up being a hassle instead of an advantage. However, it's easy to force the compiler to completely disable exceptions.
RTTI (typeid, dynamic_cast)
Requires runtime support. Can be easily disabled. In most cases, use of RTTI is avoidable, e.g. by implementing type info within classes that require it, and then restricting casts to static_ and reinterpret_.
Global constructors.
I'm not sure whether these are that much helpful, but the osdev wiki assumes they are. These obviously require runtime support and manual initialisation.

Possible disadvantages:

Sticking to one particular C++ ABI.
It may be not important, it's not like we have a ton of toolchains to choose from, anyway.

I believe we need to consider whether these advantages are really worth the effort of setting them up. Using C++ seems like a longer-term investment, it requires a lot of work to prepare, but may result in more elegant source, which will be desired if we aim to develop a serious kernel.
If what we do is just an experiment, and do not expect to develop a large system, I'd vote for sticking to plain C, because it's simpler, has less setup overhead, and is probably less confusing (especially for debugging).

I think you are missing the point here. It is quite clear that the only sane way to enable C++ in kernel is to rely on the language implementation (i.e. the compiler and the appropriate libraries), so the real question is what it would take to be able to link libstdc++ against the kernel. Well, it depends on C standard library and some additional target-specific functions, in case of Linux target that would be posix and some gnu extensions. Standard C library will be needed anyway and most of the remaining functions can be stubbed and their implementation deferred, indefinitely in some cases. In general I wouldn't expect much difficulties in porting the runtime C++ support, the most complicated probably will be configuring GCC target but that can be cheated by using an existing one.
As for C vs. C++ I won't list the differences here, anyone claiming to know both should know them, besides the most important ones were already mentioned (well, apart from templates and all the magic related to them, lambdas and non-container parts of the standard library). Unfortunately, standard C++ containers are non-intrusive what makes std::list, std::map and std::set useless in many cases. There is boost.intrusive, though.
Undoubtedly, apart from the language constructs and idioms (RAII!) that make it harder to introduce bugs iand speed up the development another big reason for using C++ is the fact that in some kernel subsystems (namely vfs and device management) using OOP at least to some extent is the most natural choice and because of that kernels like Linux or FreeBSD ended up with object-oriented C which, frankly, isn't very pretty.
However, there is a problem of code size. The board has only a tiny amount of flash and adding runtime support for C++ wouldn't exactly go well with the policy of using as little memory as possible. Exceptions are probably the biggest issue apart from requiring several stack unwinding procedures there is also dwarf information needed to perform the unwinding itself. I am not sure what the numbers here are (especially on MIPS) but it is definitely worth checking before deciding to use C++. On the other hand, I guess that before the flash size starts to become a problem the board will be already obsoleted by a newer model with more space for the kernel code.
There is also a compiler flag to disable exceptions, but I believe that it is an extremely bad idea to use it. The language, especially the standard library, weren't designed to be used without exceptions (e.g. without exceptions constructors cannot fail). For instance consider the following code:
void function(const std::vector<int>& vector) {
    auto copy(vector);
    // ...
}

What happens if the copy fails?

MIPS ABI are listed in here. The toolchain uses o32 MIPS ABI and contains libstdc++. Hence it'd be nice to test if c++ compiler is fully functional.

Let's finish this topic by saying that C++ enables a programmer to construct asbtractions too easily and as such doesn't encourage minimal designs. Many people in unix community view C++ as a bloated language with too many things to worry about. Even if we chose C++ over C it'd be a very strict subset without STL obviously. I won't argue right now... we've already gone too far to change our mind easily.
In your free time please muse on http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918 and corresponding chapter from "The Art of Unix Programming" http://www.catb.org/esr/writings/taoup/html/ch14s04.html#cc_language


Add YOLOv9 to supported models

Describe the feature

Add support for object detector YOLOv9 for modern and robust YOLO support

Motivation
A clear and concise description of the motivation of the feature.

For those who want easy to use real time capable detector that is efficient and quick
For those willing to sacrifice accuracy for immense increases in inference speed

Related resources
If there is an official code release or third-party implementations, please also provide the information here, which would be very helpful.

Official repo: https://github.com/WongKinYiu/yolov9
MIT reimplementation repo: https://github.com/WongKinYiu/YOLO

Additional context
Add any other context or screenshots about the feature request here.
If you would like to implement the feature and create a PR, please leave a comment here and that would be much appreciated.

Closed due to MMYOLO repo


feat: Support authentication via Shared Access Signatures (SAS) for Azure artifacts (Fixes #10297)

Fixes #10297
Motivation
Currently, argo-workflows support Azure blob storage artifacts by authentication only via Access Keys. Azure, however, also supports auth via Shared Access Signatures (SAS).
This PR adds support for authentication via SAS.
Modifications

To avoid spec changes, we re-use spec.name.inputs.name.azure.accountKeySecret to hold either an access key or SAS token. A new isSASAccountKey method checks whether the provided secret contains an access key or a SAS token. Since SAS tokens are nothing but URL query parameters, a simple regex can identify a SAS token. Once identified, we use the SAS token to initialize a NewClientWithNoCredential client instead of the NewClientWithSharedKeyCredential which will continue to be used for regular access keys.
Verification

Tests have been added to workflow/artifacts/azure/azure_test.go to check both the isSASAccountKey as well as the correct functioning of NewClientWithNoCredential via azurite.

Sorry I am not sure why the code-owners were not added as reviewers to this PR.
So mentioning the reviewers personally here, could any one of you please review this PR? Thanks!
(@agilgur5, @sarabala1979, @terrytangyuan)

Hi @agilgur5, could you please be able to review this PR or add relevant reviewers who could help with reviewing?
Thank you so much!


GenericWebhook cannot be triggered with default Admin Key

ENV: https://functions-staging.azure.com
Runtime version: ~1
Repro steps:

Create or open a function app.
Create a GenericWebHook function.
Go to the Develop tab of the function just created, wait for page to load. Verify code parameter of function URL is default Admin Key.
Use the function URL to trigger function via fiddler/postman, verify it got 400 error with below message
"Message": "The 'code' query parameter provided in the HTTP request did not match the expected value."

this is expected. The function default key takes precedence over admin default key.


Support for  matryoshka embeddings

Related Issue
#476

Checklist

[x] I have read the CONTRIBUTING guidelines.
[x] I have added tests to cover my changes.
[x] I have updated the documentation (docs folder) accordingly.

Additional Notes
WIP to add matryoshka embeddings.
Is there a CLAP model which supports matryoshka embedding for testing?
Is there a TinyCLIP model which supoprts matryoshka embedding for testing?
Currently missing:
[  ] Integration into client
[  ] Implementation for dummy model

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 68.00000% with 8 lines in your changes missing coverage. Please review.

Project coverage is 73.64%. Comparing base (be48378) to head (1de6c52).

Files with missing lines
Patch %
Lines

libs/infinity_emb/infinity_emb/engine.py
62.50%
3 Missing :warning:

libs/infinity_emb/infinity_emb/sync_engine.py
50.00%
3 Missing :warning:

...finity_emb/infinity_emb/inference/batch_handler.py
71.42%
2 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

:exclamation:  There is a different number of reports uploaded between BASE (be48378) and HEAD (1de6c52). Click for more details.
HEAD has 3 uploads less than BASE

Flag
BASE (be48378)
HEAD (1de6c52)

4
1

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #490      +/-   ##
==========================================
- Coverage   79.53%   73.64%   -5.89%
==========================================
  Files          41       41
  Lines        3430     3438       +8
==========================================
- Hits         2728     2532     -196
- Misses        702      906     +204

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

LGTM, if you change the OpenAPI spec for the validation of input.

@wirthual
Potentially this. could be a end-to-end test!
from openai import OpenAI

client = OpenAI(
    base_url="http://<IP_ADDRESS>:7997",
    api_key="sk",
)

result = client.embeddings.create(
    input=["input","input2"],
    model="nomic-ai/nomic-embed-text-v1.5",
    dimensions=64
)

assert len(result.data[0].embedding) == 64

@wirthual Potentially this. could be a end-to-end test under open
from openai import OpenAI

client = OpenAI(
    base_url="http://<IP_ADDRESS>:7997",
    api_key="sk",
)

result = client.embeddings.create(
    input=["input","input2"],
    model="nomic-ai/nomic-embed-text-v1.5",
    dimensions=64
)

assert len(result.data[0].embedding) == 64

Sounds good. Is there an exmaple on how to start a fastapi server within a pytest method without using AsyncOpenAI client?

Just add one here:
https://github.com/michaelfeil/infinity/blob/be483785f23c3e2a738c85028cbac3a390ec2bab/libs/infinity_emb/tests/end_to_end/test_openapi_client_compat.py#L115C9-L115C21
Also with the other tests - mostly we don't use pytest.mark.parametrize here to that it does not need to restart the server every time.

Like this?


Cosmos DB - Authorization policy

This PR enhances the pipeline by adding the AuthorizationPolicy and migrates the preexisting CosmosDB pipeline operations to the new policy.
AuthorizationPolicy
The AuthorizationPolicy cannot be in Core since every service uses a different authorization mechanism. So this PR proposes to have a specific policy in each module (they can potentially be shared in case of duplication). This PR covers Cosmos DB only. While CosmosDB does not support (yet) the bearer token authentication, it's possibile to authenticate specific users with shared key.
The AuthorizationPolicy will handle the authentication by injecting the required headers to the request passing through the pipeline. Since the resulting authorization token can depend on the preexisting headers the AuthorizationPolicy must be executed right before the TransportPolicy. Also, since the token depends on the current timestamp (to mitigate reply attacks), AuthorizationPolicy must be run at every retry.
Cosmos context
In CosmosDB, the authorization token depends on the resource type. This information must be somehow passed through the pipeline because the AuthorizationPolicy needs it.
The information of which resource to authenticate must be passed by the operation builder prior starting the pipeline. For example, the create_database operation, knowing that it has to work on ResourceType::Databases, must be able to pass ResourceType::Databases to the AuthorizationPolicy. The pipeline has a Context struct that must be instantiated by the SDK user (ie the code that calls create_database). The Context will then traverse the pipeline. As such is a good candidate for the resource type information.
For this reason, this PR proposes an additional type, called PipelineContext that wraps the user-supplied Context and adds the module-dependent field. This is achieved by exposing a generic (constrained to be Send + Sync).
An alternative approach (shown here: https://github.com/MindFlavor/azure-sdk-for-rust/tree/cosmos/auth_policy%2Fdev) is to use Rust's runtime polymorphism in the form of std::any::Any. Basically Context will have a Box<dyn Any> field that can accept anything. It would be responsibility of the operation builder (ie the create_database function) to store the relevant information in the Box<dyn Any> instance. The AuthorizationPolicy will then downcast_ref() the Any instance and get the expected type.
While this approach is easy to do, it lacks any kind of type safety and relies upon conventions (which is very unidiomatic in Rust). Also, it's runtime enforced only (another thing unidiomatic in Rust).
The approach proposed in this PR, instead, is type safe and clearly self-explanatory.
Notable changes

Created the PipelineContext<BAG> discussed above (composition of Context and custom field of type BAG).
Changed Policy trait to be generic on the BAG above. This allows policies that accept generic PipelineContext<BAG>.
Changed the pipeline to be generic on the BAG above.
Fixed the preexisting policies to accept the BAG generic (called R for brevity, this is something we might want to correct to avoid confusion).
Implemented Policy<CosmosContext> for AuthorizationPolicy.
Changed pipeline code in CosmosDB to support the AuthorizationPolicy (and to send the proper PipelineContext<CosmosContext> down the pipeline.
Removed useless cosmos_client::prepare_request2.
Created a new function in cosmos_client called prepare_request_pipeline. This function will no longer perform authentication since it will delegated to the pipeline policy AuthorizationPolicy.
Moved all the authorization code from CosmosClient to AuthorizationPolicy (preexisting non-pipeline code has been rerouted pending removal).
Removed uninmplemented from add_as_header2 that caused E2E tests to fail (fix #324).
Implemented add_as_header2 for all the required types.

Thank you @rylev for taking the time to review this! I'll try to address your suggestions and push another commit.

@MindFlavor looks good. Shall we merge?

Yes, let's keep the ball rolling! 👍


Pipeline wizard

Fix: #310

Codecov Report

Merging #338 into master will decrease coverage by 1.46%.
The diff coverage is 22.82%.

@@            Coverage Diff             @@
##           master     #338      +/-   ##
==========================================
- Coverage   73.87%   72.41%   -1.47%
==========================================
  Files          46       47       +1
  Lines        3415     3495      +80
  Branches      635      641       +6
==========================================
+ Hits         2523     2531       +8
- Misses        892      964      +72

Impacted Files
Coverage Δ

src/tkn.ts
65.12% <0.00%> (-0.29%)
:arrow_down:

src/pipeline/wizard.ts
14.08% <14.08%> (ø)

src/tekton/pipeline.ts
63.15% <46.66%> (-5.03%)
:arrow_down:

src/extension.ts
90.34% <100.00%> (+0.06%)
:arrow_up:

src/util/MultiStepInput.ts
10.16% <0.00%> (-2.95%)
:arrow_down:

src/tekton/pipelinecontent.ts
91.81% <0.00%> (-1.64%)
:arrow_down:

src/pipeline/preview.ts
9.82% <0.00%> (-0.80%)
:arrow_down:

src/tekton/tektonitem.ts
84.72% <0.00%> (-0.21%)
:arrow_down:

src/tools.ts
91.39% <0.00%> (-0.10%)
:arrow_down:

... and 2 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f8413a9...3712de9. Read the comment docs.

Workspace UI @siamaksade and @evidolob

Parameters, Git and Image Resource UI

@sudhirverma I got:

@sudhirverma I have empty wizard for this pipeline

@sudhirverma I have empty wizard for this pipeline

if YAML doesn't have params, git or image resources, and workspace I will directly start the pipeline. without showing the wizard.

@siamaksade and @evidolob
param, git and Image Resource Gif

Workspace Gif

@sudhirverma When wizard starts pipeline, it is open pipeline run diagram for previous pipelinerun:

@sudhirverma When wizard starts pipeline, it is open pipeline run diagram for previous pipelinerun:

okay, I will check this out.

@evidolob done the changes


Installation Error conflict with composer-plugin-api versions

I get this when trying to install this to my composer.json file.
I'm using the johnpbloch installation configurations alongside this and this is what the "config" section looks like.
"config": {         "allow-plugins": {             "johnpbloch/wordpress-core-installer": true,             "composer/installers": true         }     },

Problem 1
- Root composer.json requires advanced-custom-fields/advanced-custom-fields-pro * -> satisfiable by advanced-custom-fields/advanced-custom-fields-pro[6.0.5].
- advanced-custom-fields/advanced-custom-fields-pro 6.0.5 requires composer/installers ^1.0 -> found composer/installers[v1.0.0, ..., v1.12.0] but the package is fixed to v2.2.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
Not sure how to rectify this to get ACF pro to work as instructed.

I have the same problem


logger_no_op.sql has mismatch of spec and body definitions for some procedures

From @rimblas on September 13, 2013 18:49
In v2.1.2 the spec declaration for log_permanent,log_warning,log_information and log doesn't match the body.
For example in the spec:
procedure log_permanent(
p_text    in varchar2,
p_scope   in varchar2 default null,
p_extra   in clob default null,
p_params  in tab_param default logger.gc_empty_tab_param);
The body is missing p_params:
procedure log_permanent(p_text    in varchar2,
p_scope   in varchar2 default null,
p_extra   in clob default null)
Copied from original issue: tmuth/Logger---A-PL-SQL-Logging-Utility#44

Fixed as part of #57


refactor: create ModelCache

Codecov Report

Merging #39 into master will increase coverage by 6.9%.
The diff coverage is 57.62%.

@@            Coverage Diff            @@
##           master      #39     +/-   ##
=========================================
+ Coverage   44.09%   50.99%   +6.9%
=========================================
  Files          13       14      +1
  Lines         440      451     +11
  Branches       82       83      +1
=========================================
+ Hits          194      230     +36
+ Misses        228      203     -25
  Partials       18       18

Impacted Files
Coverage Δ

src/common/parser/index.ts
80.95% <ø> (ø)
:arrow_up:

src/language/definitionProvider.ts
0% <0%> (ø)
:arrow_up:

.../language/completionItemProvider/completionItem.ts
0% <0%> (ø)

src/language/hoverProvider.ts
0% <0%> (ø)
:arrow_up:

src/common/cache/modelCache.ts
100% <100%> (ø)

src/common/cache/index.ts
14.81% <11.76%> (+14.81%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update aeefb7d...524f02b. Read the comment docs.


Improving README

README

moving Environment Variables section to table
adding COMPOSER_MEMORY_LIMIT on documentation (https://github.com/kool-dev/docker-php/commit/bb4fcc396216fb1587598068c3ad3b0fd1ace1b0)

@wesleyhf
We just introduced a few more env variables on nginx images: https://github.com/kool-dev/docker-php/pull/9


examples / parameterized script failing (transaction submit error ShelleyTxValidationError ShelleyBasedEraBabbage ...)

Attempting to run the parameterized_script example in a browser context, I am getting an error (see formatted below). I've tried to understand the underlying reasons for this, but I am lacking some fundamental understanding of plutus scripts, so it's quite hard.
From what I've been able to google, there was another similar report, https://github.com/Emurgo/cardano-serialization-lib/issues/536, which surfaced a bug that was patched in https://github.com/Emurgo/cardano-serialization-lib/pull/539/. Again, I am probably misunderstanding something here, so sorry if this is a user error. I will try to reduce the example and see if I can pinpoint the issue.
transaction submit error ShelleyTxValidationError ShelleyBasedEraBabbage (
    ApplyTxError [
        UtxowFailure (
            FromAlonzoUtxowFail (
                MissingRedeemers [(
                    Minting (
                        PolicyID {
                            policyID = ScriptHash "55d96504a2652bf541a6cb1af89ae3aff0e8c54628f0cf5b62c725b6"
                        }
                    ),
                    ScriptHash "55d96504a2652bf541a6cb1af89ae3aff0e8c54628f0cf5b62c725b6"
                )]
            )
        ),
        UtxowFailure (
            FromAlonzoUtxowFail (
                PPViewHashesDontMatch SNothing (
                    SJust (
                        SafeHash "6a8a837564a3454ea0d595d458bff105abb4b737008eebf4332447e422c0189b"
                    )
                )
            )
        ),
        UtxowFailure (
            UtxoFailure (
                FromAlonzoUtxoFail (
                    UtxosFailure (
                        CollectErrors [
                            NoRedeemer (
                                Minting (
                                    PolicyID {
                                        policyID = ScriptHash "55d96504a2652bf541a6cb1af89ae3aff0e8c54628f0cf5b62c725b6"
                                    }
                                )
                            )
                        ]
                    )
                )
            )
        )
    ]
)

Here is the code in question: https://github.com/GGAlanSmithee/use-cardano/compare/feature/port-lucid-example-parameterized-script?expand=1#diff-ab63a702a131e06ad57d9c4ecc5a340edda33c10a3a0de1be9a757b98510a827R1

Here is another issue that keeps popping up as I search: https://github.com/input-output-hk/cardano-node/issues/3389, which is about script input ordering. Probably not the case here though.

@GGAlanSmithee Talk to Cardano Support on the Live support page so that your issue can be looked into.

Ups I think there is a little bug in my example. I forgot to add the redeemer to .mintAssets. It needs to be:
.mintAssets({ [unit]: 1n }, Data.empty())

@alessandrokonrad
Thanks for your reply! I've verified that it works in the linked repository.


Use URI class for FirmwareLocation

URI handling is self-implemented, rather than relying on the built-in URI class in Java. Relying on built-in classes allows the software to benefit from future platform improvements and security check, whereas the self-implemented solution will not.
File: https://github.com/OSGP/Protocol-Adapter-OSLP/blob/development/osgp-adapter-protocol-oslp/src/main/java/com/alliander/osgp/adapter/protocol/oslp/device/FirmwareLocation.java

The firmware location is a filesytem location at this moment. Pretty soon we will change this to a separate server. This server will contain all firmware versions. When this change is implemented we will concider using a Java built-in solution, since we will be using a real URI instead on a filesystem location. Thank you for your suggestion.


HelidonContainerInitializer#addPackages is not picking the beans

Environment Details

Helidon Version: 4.0.0-SNAPSHOT
Helidon MP
JDK version: Java(TM) SE Runtime Environment (build 20.0.1+9-29)
OS: Linux

Problem Description
Many CDI TCKs are failing because of this.
In the next test, the method packages() doesn't work:
public class ReproducerTest {

    @Test
    public void packages() {
        try (SeContainer container = SeContainerInitializer
                .newInstance()
                .addPackages(true, Car.class)
                .initialize();) {
            Car car = container.select(Car.class).get();
            assertNotNull(car);
        }
    }

    @Test
    public void bean() {
        try (SeContainer container = SeContainerInitializer
                .newInstance()
                .addBeanClasses(Car.class)
                .initialize();) {
            Car car = container.select(Car.class).get();
            assertNotNull(car);
        }
    }
}

Steps to reproduce
git clone https://github.com/jbescos/Questions.git
cd Questions/helidon-addPackages
mvn clean install

Output:
[ERROR] Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.124 s <<< FAILURE! -- in com.example.issue.ReproducerTest
[ERROR] com.example.issue.ReproducerTest.packages -- Time elapsed: 0.155 s <<< ERROR!
org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001334: Unsatisfied dependencies for type Car with qualifiers
	at org.jboss.weld.bean.builtin.InstanceImpl.checkBeanResolved(InstanceImpl.java:251)
	at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:113)
	at com.example.issue.ReproducerTest.packages(ReproducerTest.java:19)

I am debugging this and there is one difference. For addPackages it searches for annotations in the beans (the test Car.class is not annotated) in case the beans.xml is annotated. So that test is fixed annotating the Car.class or adding all in the beans.xml.
However in some TCK tests it is failing. I am investigating it further.

It seems it is not an issue


1.3.6 — Editing tables in raw/visual mode faulty

If adding a table in raw mode and switching to visual mode, an editing is not possible: the editor shows a new 2 x 2 table without the existing structure of cells and rows, which are preserved in the background.

You probably use a different markdown-variant for tables, the visual editor only provides one style.

I think both modes should be compatible. Where is the difference (markdown variant) in the following code?
| Projekt | Status |
|---|---|
| Aufgaben | |
| Wissen | |
| Notizen | |


fix(LoadingBar): remove loadingbar component #1738

Contributes to #1738
The component is now part of Carbon. Check that files are no longer needed and remove them.
What did you change?
Removed LoadingBar component and its files.
How did you test and verify your work?
Storybook

@lee-chase fixed test failure issues


remove child.type checks

This completes the plotly_editor_traits refactoring, and plays nice with HMR. The SidebarSection thing breaks the API a tiny bit but really this is not the place to be adding classes, it should be done in the calling code.

Are you ok with doing it in CSS? Or do you want another editor_trait?

yes ok for the css, didn't see the updated convo thread

thanks @aulneau @nicolaskruchten !


compute pressure force error?

Hi, thanks for your greak work, it really inspires me a lot . However, i'm wondering whether it is correct to compute two pressure force while computing pressure acceleration between two fluid particles.

In "Versatile Rigid-Fluid Coupling for Incompressible SPH", it only use one pressure force.
In "Versatile Rigid-Fluid Coupling for Incompressible SPH":

I'm wondering if you take interaction force into consideration. But i think that it should not be correct?
Looking forward to your reply!

Thanks for your interest on this project. The equation you refer to is a direct discretization of the pressure gradient. In real implementation, a symmetric formula is usually preferred for discretizing spatial differential operator (i.e., pressure gradient here), which can conserve linear and angular momentum and helps for robust simulation.

Hi @Bryan-Wong919, thanks for your interest on this project. The equation you refer to is a direct discretization of the pressure gradient. In real implementation, a symmetric formula is usually preferred for discretizing spatial differential operator (i.e., pressure gradient here), which can conserve linear and angular momentum and helps for robust simulation.

Thanks for your quick reply! I think i have figure it out. But i'm troubled by another question: Is the pressure of the rigid body particle on the fluid particle considered here？Is it not taken into account here or do I not fully understand the code and theory? I'm a beginner in fluid simulation, forgive me if I asked questions which may be very simple.


us-wi-la_crosse

{
    "coverage": {
        "country": "us",
        "state": "wi",
        "county": "La Crosse"
    },
    "website": "http://www.co.la-crosse.wi.us:81/ParcelAddressDimensionLabels/ParcelLabels/1/query",
    "license": "",
    "year": "",
    "skip": true
}

Link is dead. Checked website for new link and just see search engines.

Tracked at: https://github.com/openaddresses/openaddresses/blob/master/sources/us/wi/la_crosse.json


Test update_with_whole_file_closes_file is flaky on Windows

This is from a recent CI run:
2024-06-08T20:44:59.222019Z ERROR nativelink_store::filesystem_store: Failed to delete file, file_path: "C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\/12005528146084892232/temp_path/0123456789abcdef000000000000000000010000000000001c00000000000000-10", err: Error { code: Internal, messages: ["background task failed: JoinError::Cancelled(Id(1342))", "Failed to remove file \"C:\\\\Users\\\\RUNNER~1\\\\AppData\\\\Local\\\\Temp\\\\/12005528146084892232/temp_path/0123456789abcdef000000000000000000010000000000001c00000000000000-10\""] }
    at nativelink-store\src\filesystem_store.rs:121
    in nativelink_store::filesystem_store::filesystem_delete_file

test update_file_future_drops_before_rename ... ok
test update_with_whole_file_closes_file ... FAILED
test update_with_whole_file_slow_path_when_low_file_descriptors ... ok
test valid_results_after_shutdown_test ... ok

failures:

---- update_with_whole_file_closes_file stdout ----
thread 'update_with_whole_file_closes_file' panicked at nativelink-store\tests\filesystem_store_test.rs:1364:9:
assertion failed: `(left == right)`: Expected 1 permit to be available

Diff < left / right > :
<0
>1

Appeared again in https://github.com/TraceMachina/nativelink/actions/runs/9587554110/job/26437832708


feat: add array fields move method

Fix #624

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 88.95%. Comparing base (0e5b923) to head (1458fda).
Report is 3 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #647      +/-   ##
==========================================
+ Coverage   88.86%   88.95%   +0.09%
==========================================
  Files          32       32
  Lines         844      851       +7
  Branches      189      189
==========================================
+ Hits          750      757       +7
  Misses         87       87
  Partials        7        7

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Set MSBuildAllProjects property

This sets the MSBuildAllProjects property that is used in MSBuild < 16 to ensure new builds are properly triggered when targets files change.
Connects to #3

Release in alpha 7.


Destructuring issue

    const {
        web: {
            port,
            koaKeys,
            koaSessionConfig,
        },
    } = require('./config')

will be formatted to
    const {
        web: {
            port,
        koaKeys,
        koaSessionConfig,
        },
    } = require('./config')

Thanks for reporting. I will work on it after upgrading to eslint v4.

It's now like this:
const {
  web: {
    port,
    koaKeys,
    koaSessionConfig,
  },
} = require('./config')


Transition landing page header refresh

What
New transition landing page header design to be deploy Friday 16th by 5pm. Both English and Welsh pages are updated.
Welsh content
Trello: https://trello.com/c/WM8yQVMT/519-updated-landing-page-campaign-refresh-and-phase-4-testing
Before

After

Adds in new header styling, countdown flip component and new background image
:warning: This application is Continuously Deployed: :warning:

Merged changes are automatically deployed to staging and production.

Make sure you follow the guidance for deployments before you merge.

Check your branch is being deployed in the Release app, after merging.

@hannako - I've removed the clock code - when you merge your stuff - you will need to pass this into the view

Is there any particular reason why the Welsh version does not have the same red highlight on the header as the English translation?
En: has highlight

Cy: no highlight

Is there any particular reason why the Welsh version does not have the same red highlight on the header as the English translation?
En: has highlight

Cy: no highlight

Yes - I left it on purpose because the translation file didn't specify which bits to highlight. Wasn't sure if I should risk a google translate! Am just investigating what the opinion is on that...

Is there any particular reason why the Welsh version does not have the same red highlight on the header as the English translation?
En: has highlight

Cy: no highlight

Yes - I left it on purpose because the translation file didn't specify which bits to highlight. Wasn't sure if I should risk a google translate! Am just investigating what the opinion is on that...

@hannako ahhh fair enough yeah I totally get that then. Wish we had Welsh speakers around to help us out with stuff like this 😬
I would have thought that Bydd rheolau newydd would be highlighted.
Based on the almighty Google:
"Bydd rheolau newydd" = "There will be new rules"
"Bydd rheolau newydd i fusnesau" = "There will be new rules for businesses"
But I understand not wanting to risk it if we don't know for sure. It's just a detail I noticed.

I have two other Welsh related visual issues. Both are to do with text wrapping in an unsightly way on smaller adaptions.

Not sure these are priority right now considering the very tight timeline we're dealing with here. But they should be recorded and dealt with.

@danacotoran Thanks Dana! Will make a card.

The calculation for today_in_london specifies the time zone as UTC. Does that mean for the hour between 00:00 and 01:00 each morning while we are still in BST, our calculation will be out by 1? During that hour, UTC will still be the previous day.
The COVID services team bumped into the UTC / BST problem during their recent work and ended up coercing the time zone to BST using an instance variable.
I'm not sure whether or not anything else in Collections relies on the time zone being UTC, but might it be a good idea for the teams to have a chat and consider setting the time zone in config/application like we do in  Whitehall? That would allow us to rely on Time.zone.now to do the right thing.
.cc @Rosa-Fox @leenagupte

The calculation for today_in_london specifies the time zone as UTC. Does that mean for the hour between 00:00 and 01:00 each morning while we are still in BST, our calculation will be out by 1? During that hour, UTC will still be the previous day.
The COVID services team bumped into the UTC / BST problem during their recent work and ended up coercing the time zone to BST using an instance variable.
I'm not sure whether or not anything else in Collections relies on the time zone being UTC, but might it be a good idea for the teams to have a chat and consider setting the time zone in config/application like we do in Whitehall? That would allow us to rely on Time.zone.now to do the right thing.
.cc @Rosa-Fox @leenagupte

I tried setting the time zone in config/application on Friday night, but it broken some (unrelated to the postcode checker) atom feed and document presenter tests that I didn't have time to fix, hence the instance variable.

Thanks @bevanloon. I'll address this in a fresh PR now. 👍

@bevanloon https://github.com/alphagov/collections/pull/1997


⚠ Redacted has degraded performance

In 5c816b7, Redacted ($RED) experienced degraded performance:

HTTP code: 200
Response time: 2812 ms

Resolved: Redacted performance has improved in 29c277e.


Update major versions of dependencies

Hello,
Actually I would like to increase a dependency version of url and dotenv  crate only, as I have duplicates versions in my Cargo.lock. But I have collect also which other dependency could be increased:
diesel/diesel/Cargo.toml
[dependencies]
url = "2.1.0"
quickcheck = "0.9.0"
uuid = "0.8.1"
[dev-dependencies]
dotenv = "0.15.0"
quickcheck = "0.9.0"

diesel/diesel_cli/Cargo.toml
[dependencies]
dotenv = "0.15.0"
toml = "0.5.3"
barrel = "0.6.2"
libsqlite3-sys = "0.16.0"
url = "2.1.0"
[dev-dependencies]
difference = "2.0.0"
regex = "1.3.1"
url = "2.1.0"

diesel/diesel_migrations/Cargo.toml
[dependencies]
dotenv = "0.15.0"

diesel/diesel_derives/Cargo.toml
[dev-dependencies]
dotenv = "0.15.0"

diesel/diesel_tests/Cargo.toml
[build-dependencies]
dotenv = "0.15.0"
[dependencies]
dotenv = "0.15.0"

Forward thank you!

Would be great to get PR's updating the dependencies.

I can care about this.

If this hasn't been resolved, I'd like to start on this tonight.

It seems that dotenv is actually breaking right now, making it impossible to run cargo install diesel_cli:
error[E0659]: `error_chain` is ambiguous (derive helper attribute vs any other name)
  --> /home/worleyg/.cargo/registry/src/github.com-1ecc6299db9ec823/dotenv-0.10.1/src/lib.rs:35:7
   |
35 |     #[error_chain(foreign)]
   |       ^^^^^^^^^^^ ambiguous name

This upgrade should likely be performed soon. I am just getting started with diesel, so I don't know if I can verify it works appropriately after performing the upgrade, but I can open a PR with the version updates today. I will try and get it working right now since I need to install it now.

Sounds good.

Actually, I will leave it be. I downloaded the repository locally and got it to build due to the file at https://github.com/diesel-rs/diesel/blob/master/rust-toolchain. It forced the installation of an appropriate Rust version. This is good enough for me currently.

@vadixidav This is probably caused by https://github.com/rust-lang/rust/issues/66508. Which rustc version do you use?

@weiznich I was a few days behind, but I updated to latest nightly and was still receiving the issue:
worleyg@computer:~/code/psqlcom$ rustc --version
rustc 1.41.0-nightly (5c5b8afd8 2019-11-16)
worleyg@computer:~/code/psqlcom$ cargo install diesel_cli
Updating crates.io index
Installing diesel_cli v1.4.0
Compiling libc v0.2.66
Compiling proc-macro2 v1.0.6
Compiling unicode-xid v0.2.0
Compiling syn v1.0.11
Compiling cfg-if v0.1.10
Compiling pkg-config v0.3.17
Compiling autocfg v0.1.7
Compiling getrandom v0.1.13
Compiling cc v1.0.48
Compiling bitflags v1.2.1
Compiling memchr v2.2.1
Compiling smallvec v1.0.0
Compiling matches v0.1.8
Compiling pq-sys v0.4.6
Compiling byteorder v1.3.2
Compiling ppv-lite86 v0.2.6
Compiling unicode-xid v0.0.4
Compiling quote v0.3.15
Compiling percent-encoding v1.0.1
Compiling rustc-demangle v0.1.16
Compiling lazy_static v1.4.0
Compiling ucd-util v0.1.5
Compiling serde v1.0.104
Compiling regex v0.2.11
Compiling unicode-width v0.1.7
Compiling utf8-ranges v1.0.4
Compiling vec_map v0.8.1
Compiling ansi_term v0.11.0
Compiling remove_dir_all v0.5.2
Compiling strsim v0.8.0
Compiling unicode-bidi v0.3.4
Compiling unicode-normalization v0.1.11
Compiling synom v0.11.3
Compiling num-traits v0.2.10
Compiling num-integer v0.1.41
Compiling c2-chacha v0.2.3
Compiling thread_local v0.3.6
Compiling regex-syntax v0.5.6
Compiling textwrap v0.11.0
Compiling mysqlclient-sys v0.2.4
Compiling libsqlite3-sys v0.16.0
Compiling syn v0.11.11
Compiling idna v0.1.5
Compiling quote v1.0.2
Compiling time v0.1.42
Compiling atty v0.2.13
Compiling aho-corasick v0.6.10
Compiling rand_core v0.5.1
Compiling url v1.7.2
Compiling clap v2.33.0
Compiling backtrace-sys v0.1.32
Compiling rand_chacha v0.2.1
Compiling rand v0.7.2
Compiling chrono v0.4.10
Compiling tempfile v3.1.0
Compiling backtrace v0.3.40
Compiling error-chain v0.10.0
Compiling derive-error-chain v0.10.1
Compiling diesel_derives v1.4.1
Compiling serde_derive v1.0.104
Compiling dotenv v0.10.1
error[E0659]: error_chain is ambiguous (derive helper attribute vs any other name)
--> /home/worleyg/.cargo/registry/src/github.com-1ecc6299db9ec823/dotenv-0.10.1/src/lib.rs:27:7
|
27 |     #[error_chain(custom)]
|       ^^^^^^^^^^^ ambiguous name
|
note: error_chain could refer to the derive helper attribute defined here
--> /home/worleyg/.cargo/registry/src/github.com-1ecc6299db9ec823/dotenv-0.10.1/src/lib.rs:22:17
|
22 | #[derive(Debug, error_chain)]
|                 ^^^^^^^^^^^
note: error_chain could also refer to the derive macro imported here
--> /home/worleyg/.cargo/registry/src/github.com-1ecc6299db9ec823/dotenv-0.10.1/src/lib.rs:10:1
|
10 | #[macro_use]
| ^^^^^^^^^^^^

@weiznich Actually, it looks like in the above I messed up and was using the wrong version. I set my default toolchain to current nightly in rustup.

So this was caused by a old nightly affected by that bug? If it happens at a newer nightly, please open a bugreport at the rustc repo linking the issue mentioned above.

This issue is really showing me how much I don't understand about Cargo.toml

I think I will close this issue to make some clean up.
As it already 4 month passed and issue is partial solved..
If you think that issue is still actual - better make new one with fresh dependency request.
Forward thank you!


Add missing classname argument in download-streamine-artifacts.py

While trying to run download-streamine-artifacts.py, it throws below error.
Unrecognized option: --artifactRepositories
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
It appears that the classname is missing in the java command that the script is trying to execute

@HeartSaVioR , I am not sure how the script is supposed to work, but looks like the classname argument is missing. Let me know if this is valid and I will create a github issue to associate with the PR.

@arunmahadevan Very weird... I ran script couple of times before raising pull request... I might be worked with copy of script... I guess we can file an issue and proceed. Thanks for the fix.


No indicator that photo is being processed after cropping

What

When you add a photo, you get to the cropping screen. After adjusting the area, when I click on the validation button, it seems that nothing happens.
In fact, something is happening but on my phone this is very slow and I have no indication that processing is in progress.

Expected behavior

We should display a spinner to indicate action was taken into account and that processing is happening.

Why

The user might be disoriented, click several time on the validation button and think the app is broken.

Can I work on this? Kinda new to open source but feels like i can handle this

Sure @AshAman999, if you need any help, just ask

@AshAman999 before starting working, can you outline your plan here ?
In my opinion, we should avoid notifying the user during the upload, but rather once it's finished "Upload successful". If it fails, it should retry on its own later, once network is available.
As a user "Ongoing upload" is not useful. The UI should update immediately, and I should receive an unobtrusive hint of success afterwise.

@teolemon  I was simply going to do the approach as @M123-dev  suggested, showing a loading spinner while the cropping is in process
Something like this
https://user-images.githubusercontent.com/57723319/159107708-aab09062-a811-4328-8fbf-50ef179cdbd7.mp4
Should I go ahead with something like this?
but as @teolemon  suggested, if we have to do something like background uploading, I will have to study the codebase a bit more (kinda new here).
Please confirm which approach should I go for?

@AshAman999 the way you showed in the video looks good for now. For me the issue is exactly about this. Offline upload is certainly great but we have more important tasks currently.


Revisiting Monitor Error Alerts

Doc level monitors create error alerts on each run where there is an error.
This would lead us to filling up the index with error alerts if there are frequently scheduled monitors which are erroring in each run (such as an incorrect index name or an index being deleted etc.)
This is noisy behaviour.
We can check if there is an unacknowledged ERROR state alert and only send out notifications and not create a new alert. If notification is too noisy we can choose to update the last updated time of alert

Will add more details for each type of monitor's error Alert logic.

When there already exists ERROR state alert and end time is null-

again monitor errors - upsert current alert error message (if message is different else just update lastNotificationTime)
if monitor's next execution is successful -> set an end time on the current error alert

We should roll over alerts with non-null end time into history index for doc level monitor alerts
@petardz


haskellPackages: cleaning up obsolete overrides (16/x)

Motivation for this change
Remove obsolete overrides on the following haskellPackages:
universum: -dontCheck
MissingH: -dontCheck, -doJailbreak
html-entities: -doJailbreak
restless-git: -doJailbreak
blaze-markup: -doJailbreak
Part of https://github.com/NixOS/nixpkgs/issues/86500
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build haskellPackages.universum
@GrahamcOfBorg build haskellPackages.MissingH
@GrahamcOfBorg build haskellPackages.html-entities
@GrahamcOfBorg build haskellPackages.restless-git
@GrahamcOfBorg build haskellPackages.blaze-markup

Great, thanks for cleaning up these as well


💚 Popoyoko-ui build in another branch

when there is a modification on the main branch, we should make sure that it builds the library and pushes it to another branch.
is this right ? @LouiFi

already done my bad xd