truffle deploy contracts in integration_949_elixir_omg_pr

Issue Type
[ ] bug report
[ x] feature request

Current Behavior
Deploys old contract behaviour.
plasma-deployer_1  | - Fetching solc version list from solc-bin. Attempt #1
plasma-deployer_1  | - Downloading compiler. Attempt #1
plasma-deployer_1  | - Blocks: 0            Seconds: 0
plasma-deployer_1  | - Saving migration to chain.
plasma-deployer_1  | - Blocks: 0            Seconds: 0
plasma-deployer_1  | - Blocks: 0            Seconds: 0
plasma-deployer_1  | - Blocks: 0            Seconds: 0
plasma-deployer_1  | - Saving migration to chain.
plasma-deployer_1  | - Saving migration to chain.
plasma-deployer_1  | - Saving migration to chain.
plasma-deployer_1  | {"\nCompiling your contracts...\n===========================\n> Compiling ./contracts/BasicToken.sol\n> Compiling ./contracts/Bits.sol\n> Compiling ./contracts/ByteUtils.sol\n> Compiling ./contracts/ECRecovery.sol\n> Compiling ./contracts/ERC20.sol\n> Compiling ./contracts/ERC20Basic.sol\n> Compiling ./contracts/Eip712StructHash.sol\n> Compiling ./contracts/Math.sol\n> Compiling ./contracts/Merkle.sol\n> Compiling ./contracts/Migrations.sol\n> Compiling ./contracts/MintableToken.sol\n> Compiling ./contracts/Ownable.sol\n> Compiling ./contracts/PlasmaCore.sol\n> Compiling ./contracts/PlasmaCoreTest.sol\n> Compiling ./contracts/PriorityQueue.sol\n> Compiling ./contracts/PriorityQueueFactory.sol\n> Compiling ./contracts/PriorityQueueLib.sol\n> Compiling ./contracts/PriorityQueueWrapper.sol\n> Compiling ./contracts/RLP.sol\n> Compiling ./contracts/RLPTest.sol\n> Compiling ./contracts/RootChain.sol\n> Compiling ./contracts/SafeMath.sol\n> Compiling ./contracts/SignatureTest.sol\n> Compiling ./contracts/StandardToken.sol\n\n    > compilation warnings encountered:\n\n/opt/plasma_deployer/contracts/Ownable.sol:20:3: Warning: Defining constructors as functions with the same name as the contract is deprecated. Use \"constructor(...) { ... }\" instead.\n  function Ownable() {\n  ^ (Relevant source part starts here and spans across multiple lines).\n,/opt/plasma_deployer/contracts/RLPTest.sol:16:9: Warning: Use of the \"var\" keyword is deprecated.\n        var txList = RLP.toList(RLP.toRLPItem(tx_bytes));\n        ^--------^\n,/opt/plasma_deployer/contracts/RLPTest.sol:29:9: Warning: Use of the \"var\" keyword is deprecated.\n        var txList = RLP.toList(RLP.toRLPItem(tx_bytes));\n        ^--------^\n,/opt/plasma_deployer/contracts/BasicToken.sol:29:5: Warning: Invoking events without \"emit\" prefix is deprecated.\n    Transfer(msg.sender, _to, _value);\n    ^-------------------------------^\n,/opt/plasma_deployer/contracts/RLP.sol:596:17: Warning: The use of labels is deprecated. Please use \"if\", \"switch\", \"for\" or function calls instead.\n                tag_loop:\n                ^------^\n,/opt/plasma_deployer/contracts/RLP.sol:596:17: Warning: Jump instructions and labels are low-level EVM features that can lead to incorrect stack access. Because of that they are discouraged. Please consider using \"switch\", \"if\" or \"for\" statements instead.\n                tag_loop:\n                ^------^\n,/opt/plasma_deployer/contracts/RLP.sol:597:21: Warning: Jump instructions and labels are low-level EVM features that can lead to incorrect stack access. Because of that they are discouraged. Please consider using \"switch\", \"if\" or \"for\" statements instead.\n                    jumpi(end, eq(i, words))\n                    ^----------------------^\n,/opt/plasma_deployer/contracts/RLP.sol:603:21: Warning: Jump instructions and labels are low-level EVM features that can lead to incorrect stack access. Because of that they are discouraged. Please consider using \"switch\", \"if\" or \"for\" statements instead.\n                    jump(tag_loop)\n                    ^------------^\n,/opt/plasma_deployer/contracts/RLP.sol:604:17: Warning: The use of labels is deprecated. Please use \"if\", \"switch\", \"for\" or function calls instead.\n                end:\n                ^-^\n,/opt/plasma_deployer/contracts/RLP.sol:604:17: Warning: Jump instructions and labels are low-level EVM features that can lead to incorrect stack access. Because of that they are discouraged. Please consider using \"switch\", \"if\" or \"for\" statements instead.\n                end:\n                ^-^\n,/opt/plasma_deployer/contracts/Eip712StructHash.sol:24:41: Warning: Initial value for constant variable has to be compile-time constant. This will fail to compile with the next breaking version change.\n    bytes32 constant DOMAIN_SEPARATOR = keccak256(abi.encode(\n                                        ^ (Relevant source part starts here and spans across multiple lines).\n,/opt/plasma_deployer/contracts/StandardToken.sol:34:5: Warning: Invoking events without \"emit\" prefix is deprecated.\n    Transfer(_from, _to, _value);\n    ^---------------------" <> ...,
plasma-deployer_1  |  0}
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.071 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.074 [info]  Compiling your contracts...
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.074 [info]  ===========================
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.074 [info]  > Compiling ./contracts/BasicToken.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.074 [info]  > Compiling ./contracts/Bits.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.074 [info]  > Compiling ./contracts/ByteUtils.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.074 [info]  > Compiling ./contracts/ECRecovery.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.074 [info]  > Compiling ./contracts/ERC20.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.074 [info]  > Compiling ./contracts/ERC20Basic.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.074 [info]  > Compiling ./contracts/Eip712StructHash.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.074 [info]  > Compiling ./contracts/Math.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.075 [info]  > Compiling ./contracts/Merkle.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.075 [info]  > Compiling ./contracts/Migrations.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.075 [info]  > Compiling ./contracts/MintableToken.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.075 [info]  > Compiling ./contracts/Ownable.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.076 [info]  > Compiling ./contracts/PlasmaCore.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.076 [info]  > Compiling ./contracts/PlasmaCoreTest.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.077 [info]  > Compiling ./contracts/PriorityQueue.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.077 [info]  > Compiling ./contracts/PriorityQueueFactory.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.077 [info]  > Compiling ./contracts/PriorityQueueLib.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.077 [info]  > Compiling ./contracts/PriorityQueueWrapper.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.077 [info]  > Compiling ./contracts/RLP.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.077 [info]  > Compiling ./contracts/RLPTest.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.077 [info]  > Compiling ./contracts/RootChain.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.077 [info]  > Compiling ./contracts/SafeMath.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.077 [info]  > Compiling ./contracts/SignatureTest.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]  > Compiling ./contracts/StandardToken.sol
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]      > compilation warnings encountered:
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]  /opt/plasma_deployer/contracts/Ownable.sol:20:3: Warning: Defining constructors as functions with the same name as the contract is deprecated. Use "constructor(...) { ... }" instead.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]    function Ownable() {
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]    ^ (Relevant source part starts here and spans across multiple lines).
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]  ,/opt/plasma_deployer/contracts/RLPTest.sol:16:9: Warning: Use of the "var" keyword is deprecated.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]          var txList = RLP.toList(RLP.toRLPItem(tx_bytes));
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]          ^--------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]  ,/opt/plasma_deployer/contracts/RLPTest.sol:29:9: Warning: Use of the "var" keyword is deprecated.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]          var txList = RLP.toList(RLP.toRLPItem(tx_bytes));
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]          ^--------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]  ,/opt/plasma_deployer/contracts/BasicToken.sol:29:5: Warning: Invoking events without "emit" prefix is deprecated.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]      Transfer(msg.sender, _to, _value);
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]      ^-------------------------------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]  ,/opt/plasma_deployer/contracts/RLP.sol:596:17: Warning: The use of labels is deprecated. Please use "if", "switch", "for" or function calls instead.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]                  tag_loop:
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]                  ^------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]  ,/opt/plasma_deployer/contracts/RLP.sol:596:17: Warning: Jump instructions and labels are low-level EVM features that can lead to incorrect stack access. Because of that they are discouraged. Please consider using "switch", "if" or "for" statements instead.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]                  tag_loop:
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.083 [info]                  ^------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.084 [info]  ,/opt/plasma_deployer/contracts/RLP.sol:597:21: Warning: Jump instructions and labels are low-level EVM features that can lead to incorrect stack access. Because of that they are discouraged. Please consider using "switch", "if" or "for" statements instead.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.084 [info]                      jumpi(end, eq(i, words))
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.084 [info]                      ^----------------------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.084 [info]  ,/opt/plasma_deployer/contracts/RLP.sol:603:21: Warning: Jump instructions and labels are low-level EVM features that can lead to incorrect stack access. Because of that they are discouraged. Please consider using "switch", "if" or "for" statements instead.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.084 [info]                      jump(tag_loop)
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.084 [info]                      ^------------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.084 [info]  ,/opt/plasma_deployer/contracts/RLP.sol:604:17: Warning: The use of labels is deprecated. Please use "if", "switch", "for" or function calls instead.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.084 [info]                  end:
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.084 [info]                  ^-^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.084 [info]  ,/opt/plasma_deployer/contracts/RLP.sol:604:17: Warning: Jump instructions and labels are low-level EVM features that can lead to incorrect stack access. Because of that they are discouraged. Please consider using "switch", "if" or "for" statements instead.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.084 [info]                  end:
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.084 [info]                  ^-^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.084 [info]  ,/opt/plasma_deployer/contracts/Eip712StructHash.sol:24:41: Warning: Initial value for constant variable has to be compile-time constant. This will fail to compile with the next breaking version change.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.084 [info]      bytes32 constant DOMAIN_SEPARATOR = keccak256(abi.encode(
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.084 [info]                                          ^ (Relevant source part starts here and spans across multiple lines).
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.084 [info]  ,/opt/plasma_deployer/contracts/StandardToken.sol:34:5: Warning: Invoking events without "emit" prefix is deprecated.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.084 [info]      Transfer(_from, _to, _value);
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.084 [info]      ^--------------------------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.085 [info]  ,/opt/plasma_deployer/contracts/StandardToken.sol:50:5: Warning: Invoking events without "emit" prefix is deprecated.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.085 [info]      Approval(msg.sender, _spender, _value);
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.089 [info]      ^------------------------------------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.090 [info]  ,/opt/plasma_deployer/contracts/StandardToken.sol:72:5: Warning: Invoking events without "emit" prefix is deprecated.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.090 [info]      Approval(msg.sender, _spender, allowed[msg.sender][_spender]);
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.090 [info]      ^-----------------------------------------------------------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.090 [info]  ,/opt/plasma_deployer/contracts/StandardToken.sol:83:5: Warning: Invoking events without "emit" prefix is deprecated.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.090 [info]      Approval(msg.sender, _spender, allowed[msg.sender][_spender]);
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.090 [info]      ^-----------------------------------------------------------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.090 [info]  ,/opt/plasma_deployer/contracts/Ownable.sol:40:5: Warning: Invoking events without "emit" prefix is deprecated.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.090 [info]      OwnershipTransferred(owner, newOwner);
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.090 [info]      ^-----------------------------------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.090 [info]  ,/opt/plasma_deployer/contracts/MintableToken.sol:37:5: Warning: Invoking events without "emit" prefix is deprecated.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]      Mint(_to, _amount);
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]      ^----------------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]  ,/opt/plasma_deployer/contracts/MintableToken.sol:38:5: Warning: Invoking events without "emit" prefix is deprecated.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]      Transfer(address(0), _to, _amount);
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]      ^--------------------------------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]  ,/opt/plasma_deployer/contracts/MintableToken.sol:48:5: Warning: Invoking events without "emit" prefix is deprecated.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]      MintFinished();
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]      ^------------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]  ,/opt/plasma_deployer/contracts/RootChain.sol:877:39: Warning: This function only accepts a single "bytes" argument. Please use "abi.encodePacked(...)" or a similar function to encode the data.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]          return _computeStandardExitId(keccak256(feeExitNum), 0);
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]                                        ^-------------------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]  ,/opt/plasma_deployer/contracts/RootChain.sol:877:39: Warning: The provided argument of type uint256 is not implicitly convertible to expected type bytes memory.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]          return _computeStandardExitId(keccak256(feeExitNum), 0);
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]                                        ^-------------------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]  ,/opt/plasma_deployer/contracts/Ownable.sol:20:3: Warning: No visibility specified. Defaulting to "public".
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]    function Ownable() {
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]    ^ (Relevant source part starts here and spans across multiple lines).
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]  ,/opt/plasma_deployer/contracts/PriorityQueueLib.sol:32:5: Warning: No visibility specified. Defaulting to "public".
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]      function init(Queue storage self, address _owner)
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]      ^ (Relevant source part starts here and spans across multiple lines).
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]  ,/opt/plasma_deployer/contracts/PriorityQueueLib.sol:39:5: Warning: No visibility specified. Defaulting to "public".
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]      function insert(Queue storage self, uint256 k)
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]      ^ (Relevant source part starts here and spans across multiple lines).
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]  ,/opt/plasma_deployer/contracts/PriorityQueueLib.sol:46:5: Warning: No visibility specified. Defaulting to "public".
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]      function minChild(Queue storage self, uint256 i)
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]      ^ (Relevant source part starts here and spans across multiple lines).
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]  ,/opt/plasma_deployer/contracts/PriorityQueueLib.sol:69:5: Warning: No visibility specified. Defaulting to "public".
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]      function delMin(Queue storage self)
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]      ^ (Relevant source part starts here and spans across multiple lines).
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.091 [info]  ,/opt/plasma_deployer/contracts/PriorityQueueFactory.sol:10:5: Warning: No visibility specified. Defaulting to "public".
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.092 [info]      function deploy(address _forOwner)
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.092 [info]      ^ (Relevant source part starts here and spans across multiple lines).
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.092 [info]  ,/opt/plasma_deployer/contracts/RootChain.sol:1125:5: Warning: No visibility specified. Defaulting to "public".
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.092 [info]      function getInFlightExitPriority(bytes _tx, uint256 _txoPos)
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.093 [info]      ^ (Relevant source part starts here and spans across multiple lines).
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.093 [info]  ,/opt/plasma_deployer/contracts/RootChain.sol:1400:5: Warning: No visibility specified. Defaulting to "public".
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.093 [info]      function _initOperator()
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.093 [info]      ^ (Relevant source part starts here and spans across multiple lines).
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.093 [info]  ,/opt/plasma_deployer/contracts/PlasmaCore.sol:54:5: Warning: Function state mutability can be restricted to pure
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.093 [info]      function decode(bytes memory _tx)
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.093 [info]      ^ (Relevant source part starts here and spans across multiple lines).
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.093 [info]  ,/opt/plasma_deployer/contracts/PriorityQueueLib.sol:25:5: Warning: Function state mutability can be restricted to view
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.093 [info]      function isOwner(Queue storage self)
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.093 [info]      ^ (Relevant source part starts here and spans across multiple lines).
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.093 [info]  ,/opt/plasma_deployer/contracts/RLP.sol:597:21: Warning: Function declared as view, but this expression (potentially) modifies the state and thus requires non-payable (the default) or payable.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.093 [info]                      jumpi(end, eq(i, words))
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.093 [info]                      ^----------------------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.093 [info]  ,/opt/plasma_deployer/contracts/RLP.sol:603:21: Warning: Function declared as view, but this expression (potentially) modifies the state and thus requires non-payable (the default) or payable.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.094 [info]                      jump(tag_loop)
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.094 [info]                      ^------------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.094 [info]  ,/opt/plasma_deployer/contracts/RLPTest.sol:11:5: Warning: Function state mutability can be restricted to pure
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.094 [info]      function eight(bytes tx_bytes)
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.094 [info]      ^ (Relevant source part starts here and spans across multiple lines).
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.094 [info]  ,/opt/plasma_deployer/contracts/RLPTest.sol:24:5: Warning: Function state mutability can be restricted to pure
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.094 [info]      function eleven(bytes tx_bytes)
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.106 [info]      ^ (Relevant source part starts here and spans across multiple lines).
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.106 [info]  ,/opt/plasma_deployer/contracts/RootChain.sol:865:13: Warning: Function declared as view, but this expression (potentially) modifies the state and thus requires non-payable (the default) or payable.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.106 [info]          if (_isDeposit(_utxoPos.getBlknum())){
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.106 [info]              ^------------------------------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.106 [info]  ,/opt/plasma_deployer/contracts/RootChain.sol:1075:13: Warning: Function declared as view, but this expression (potentially) modifies the state and thus requires non-payable (the default) or payable.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.106 [info]          if (_isDeposit(blknum)) {
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.106 [info]              ^----------------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.106 [info]  ,/opt/plasma_deployer/contracts/RootChain.sol:1278:29: Warning: Function declared as view, but this expression (potentially) modifies the state and thus requires non-payable (the default) or payable.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.106 [info]          already_finalized = _cleanupDoubleSpendingStandardExits(inputUtxoPos, _inputTx);
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.106 [info]                              ^---------------------------------------------------------^
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.106 [info]  ,/opt/plasma_deployer/contracts/RootChain.sol:1359:5: Warning: Function state mutability can be restricted to view
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.106 [info]      function _shouldClearInFlightExit(InFlightExit storage _inFlightExit)
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.106 [info]      ^ (Relevant source part starts here and spans across multiple lines).
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.106 [info]  ,/opt/plasma_deployer/contracts/RootChain.sol:1390:5: Warning: Function state mutability can be restricted to pure
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.106 [info]      function _isDeposit(uint256 blknum)
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.106 [info]      ^ (Relevant source part starts here and spans across multiple lines).
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.107 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.107 [info]  > Artifacts written to /opt/plasma_deployer/build/contracts
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.109 [info]  > Compiled successfully using:
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.109 [info]     - solc: 0.4.25+commit.59dbf8f1.Emscripten.clang
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.109 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.109 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.109 [info]  Starting migrations...
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.110 [info]  ======================
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.110 [info]  > Network name:    'local'
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.110 [info]  > Network id:      1337
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.111 [info]  > Block gas limit: 0x7270e0
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.111 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.111 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.111 [info]  1_check_authority_address.js
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.111 [info]  ============================
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.116 [info]  Funding authority address 0x2b89590CDBe7117F457891E0C19845cF447fd78a
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.116 [info]  Successfully funded authority address.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]     -------------------------------------
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]     > Total cost:                   0 ETH
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]  2_initial_migration.js
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]  ======================
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]     Deploying 'Migrations'
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]     ----------------------
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]     > transaction hash:    0x1689ea5e4a78f686b8f9acc2555996afac901489478e362bcc6016b07e3e1261
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]     > Blocks: 0            Seconds: 0
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]     > contract address:    0x6F13Ad87e0e2dA9E40aBfd751d115400FF728771
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]     > block number:        1000
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]     > block timestamp:<PHONE_NUMBER>
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]     > account:             0xF7527026CEf1042f59301D151e9B87398b87d482
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]     > balance:<PHONE_NUMBER>37316195423570985008687907853269984665640564039154.598408773129639927
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]     > gas used:            193323
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]     > gas price:           20 gwei
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]     > value sent:          0 ETH
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]     > total cost:          0.00386646 ETH
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]     > Saving migration to chain.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]     > Saving artifacts
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]     -------------------------------------
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]     > Total cost:          0.00386646 ETH
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.118 [info]  3_deploy_contracts.js
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.119 [info]  =====================
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.119 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.119 [info]     Deploying 'PriorityQueueLib'
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.119 [info]     ----------------------------
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.119 [info]     > transaction hash:    0x4e696ed130bf3c4fb356b9a934969f30f413f48d1bf8cba6781b0df9ad131590
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.119 [info]     > Blocks: 0            Seconds: 0
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.119 [info]     > contract address:    0x7cF62bEeB565A9626c407661F4BF8476c43A9e68
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.119 [info]     > block number:        1004
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.119 [info]     > block timestamp:<PHONE_NUMBER>
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.119 [info]     > account:             0xF7527026CEf1042f59301D151e9B87398b87d482
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.119 [info]     > balance:<PHONE_NUMBER>37316195423570985008687907853269984665640564039154.598408773129639927
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.119 [info]     > gas used:            460069
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.119 [info]     > gas price:           20 gwei
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > value sent:          0 ETH
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > total cost:          0.00920138 ETH
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     Linking
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     -------
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     * Contract: PriorityQueueFactory <--> Library: PriorityQueueLib (at address: 0x7cF62bEeB565A9626c407661F4BF8476c43A9e68)
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     Deploying 'PriorityQueueFactory'
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     --------------------------------
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > transaction hash:    0x21f7d23b508f529efaaaa5052d5b43d796ebc92f6ea9d71365ea0898ca0310a9
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > Blocks: 0            Seconds: 0
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > contract address:    0xe7CD38fE96A4D1A72856199a62752C585EAdF566
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > block number:        1006
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > block timestamp:<PHONE_NUMBER>
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > account:             0xF7527026CEf1042f59301D151e9B87398b87d482
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > balance:<PHONE_NUMBER>37316195423570985008687907853269984665640564039154.598408773129639927
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > gas used:            379282
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > gas price:           20 gwei
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > value sent:          0 ETH
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > total cost:          0.00758564 ETH
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     Linking
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     -------
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     * Contract: RootChain <--> Library: PriorityQueueFactory (at address: 0xe7CD38fE96A4D1A72856199a62752C585EAdF566)
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     Deploying 'RootChain'
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     ---------------------
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > transaction hash:    0x8e1f8af15a141a801beb9e6feb6a9a7b1e501f88b4227fd1a093c507789d14e6
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > Blocks: 0            Seconds: 0
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > contract address:    0x4E6c34276C5F91593249D2a0598f994bA0B13D27
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > block number:        1008
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > block timestamp:<PHONE_NUMBER>
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > account:             0xF7527026CEf1042f59301D151e9B87398b87d482
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > balance:<PHONE_NUMBER>37316195423570985008687907853269984665640564039154.598408773129639927
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > gas used:            5810203
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > gas price:           20 gwei
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > value sent:          0 ETH
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]     > total cost:          0.11620406 ETH
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.120 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.121 [info]     > Saving migration to chain.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.121 [info]     > Saving artifacts
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.121 [info]     -------------------------------------
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.129 [info]     > Total cost:          0.13299108 ETH
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]  4_init_rootchain_contract.js
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]  ============================
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]     > Saving migration to chain.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]     -------------------------------------
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]     > Total cost:                   0 ETH
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]  5_output_results.js
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]  ===================
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]  {"contract_addr":"0x4e6c34276c5f91593249d2a0598f994ba0b13d27","txhash_contract":"0x8e1f8af15a141a801beb9e6feb6a9a7b1e501f88b4227fd1a093c507789d14e6","authority_addr":"0x2b89590cdbe7117f457891e0c19845cf447fd78a"}
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]     > Saving migration to chain.
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]     -------------------------------------
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]     > Total cost:                   0 ETH
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]  Summary
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]  =======
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]  > Total deployments:   4
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]  > Final cost:          0.13685754 ETH
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]
plasma-deployer_1  |
plasma-deployer_1  | 17:52:54.135 [info]

Expected Behavior
To be able to deploy ALD contracts to chain with truffle
Steps to Reproduce
git checkout integration_949_elixir_omg_pr
npx truffle migrate --network local --reset
Suggested Fix
/
Motivation for Change
Elixir OMG uses truffle for local cluster deploy.
System Specs
FROM erlang:21-alpine

MAINTAINER Ino Murko<EMAIL_ADDRESS>
# Create and set home directory
WORKDIR /opt/plasma_deployer

# Configure required environment
ENV MIX_ENV prod

# elixir expects utf8.

RUN git checkout integration_949_elixir_omg_pr
#RUN git checkout 67b90e5175cd1e4d503ad0160cb069565ef91136

COPY mix.* ./
COPY . .

RUN mix do local.hex --force, local.rebar --force
RUN mix deps.get
RUN MIX_ENV=prod mix escript.build

###node for truffle
RUN apk add --no-cache --repository http://dl-cdn.alpinelinux.org/alpine/v3.7/main/ nodejs=10.14.2-r0
RUN apk add --update npm
RUN apk add --update \
    python \
    python-dev \
    py-pip \
    build-base \
  && pip install virtualenv \
  && rm -rf /var/cache/apk/*

#last bits to get things going, npm install from contracts
RUN npm install
# curl for healthchecks
RUN apk add --no-cache curl

CMD [ "./plasma_deployer" ]

I will try to merge this into master today: https://github.com/omisego/plasma-contracts/pull/298
Then there would be migration script directly on master. I am not really into the idea of supporting a special branching.....and aside from migration script there is some python tests commits but I don't think it really matters to elixir integration.
If you think that specific branch is necessary we can rebase that to master afterward, or merge the python test PR ASAP.

Sounds great! I don’t have any special requests 😁

with #298 and #332 merged, I think everything is in master now.


UPDATE statement not honouring WHERE NOT EXISTS filter when used in conjunction with a filter on PK

CrateDB version
5.5.2 and nightly-5.6.0-2024-01-05-00-02
CrateDB setup information
-Cdiscovery.type=single-node
Problem description
Originally reported by jiren on https://community.cratedb.com/t/bug-with-update-statement-using-subselect/1684
The UPDATE statement below updates a row it should not. This is only reproducible in the presence of a PK.
Steps to Reproduce
CREATE TABLE f2 (id integer primary key, column1 text);

INSERT INTO f2 VALUES (2, '456'), (10, '123');

UPDATE f2
SET column1 = '123'
WHERE id = 2
AND NOT EXISTS (
    SELECT 1
    FROM f2
    WHERE column1 = '123'
);

(thanks @hammerhead )
Actual Result
Updates the row with ID 2
Expected Result
No rows updated.

Thanks for the report. This should be fixed with https://github.com/crate/crate/pull/15293


jfrog audit scan command fails while finding existing packages

Hello Team,
We are using jfrog audit scan using cli. It fails while running scan for a package which is a dependency of a dependency and is available in Artifactory. It seems it is not able to find that package. Could you please guide me on this.
Details:
16:53:38 [Info] Running SCA scan for yarn vulnerable dependencies in /azp/_work/1/s/CheckedOutSource directory...
16:53:38 [Info] Calculating Yarn dependencies...
16:53:39 [Warn] An error occurred while collecting dependencies info:
{"type":"warning","data":"Lockfile has incorrect entry for<EMAIL_ADDRESS>Ignoring it."}
{"type":"error","data":"Couldn't find package<EMAIL_ADDRESS>required by \"<EMAIL_ADDRESS>on the \"npm\" registry."}

16:53:39 [Warn] An error was thrown while collecting dependencies info: exit status 1
Command output:
{"type":"info","data":"Visit https://yarnpkg.com/en/docs/cli/list for documentation about this command."}

Package in our Artifactory:

Hey @jashan05 ,
Could you please share some additional details that will help us investigate the issue?

Which version of Yarn are you using?
Share debug level logs (You can do that by exporting ENV var JFROG_CLI_LOG_LEVEL=DEBUG)
Share the package.json file if you can, or any other details you can to help us reproduce this problem.


[Removal]: Prehistoric Pearl Oyster

Hotspot Name
Prehistoric Pearl Oyster
Hotspot b58 Address
112bJpc6pKCjmPHinsa2UeMqi1SaHdnnSgt7pWqBzixEyg2gwb8i
Discord Handle
Superdude#5042
Hotspot Manufacturer
Bobcat
Removal Reason
Have never done anything to warrant a deny
Modifications
No
Extra forwarders
No
Extra antennas
No
Additional Information
In my opinion I have never done anything to warrant a deny.
I have placed my hotspot in my house, in kitchen. Replaced antenna with lower dbi (3 from stock 4) and placed it outside. This cause im in a crowded area and 3dbi  seemed better. I have updated my antenna height and dbi (and payed for this both times trough helium app).

Original location (location that helium gave me on initial setup) on helium explorer was not 100% accurate, showed me about 100m from my actual location so i updated this to my actual location (within 5 mtrs accurate) (and payed for it again)
Only reason i can think of is that my cable is too long and taking away some dbi and thus transmitting lower then 3. But there is no way for me to know this and should not be reason to be denied.
PLease remove me from deny list, or tell me what i must to to be removed from deny list. Thank you

We have taken into account this removal request in the next iteration of the denylist. It may take some time before it's processed. This is an automated comment due to the volume of addition and removal requests. A future tool is in the works to provide more insight into the analysis approach made by the Helium team and community members that maintain this list.


Bump ember-lodash

This release includes a fix for nested dependencies with Node and
NPM3+ (see mike-north/ember-lodash#7).

ty sir!


In cluster of type STRICT_DNS, requests being routed to unhealthy hosts

Title: In cluster of type STRICT_DNS, requests being routed to unhealthy hosts
Description:
I have this envoy config, running docker image docker.io/envoyproxy/envoy-alpine:v1.14.1
admin:
  access_log_path: /dev/null
  address:
    socket_address: { address: <IP_ADDRESS>, port_value: 9901 }

static_resources:
  listeners:
  - name: default
    address:
      socket_address: { address: <IP_ADDRESS>, port_value: 8080 }
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: default
          # http1 or http2
          codec_type: AUTO
          access_log:
          - name: envoy.access_loggers.file
            filter:
              not_health_check_filter: {}
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
              path: /dev/stderr
          http_filters:
          - name: envoy.filters.http.router
          route_config:
            name: local_route
            virtual_hosts:
            - name: default
              domains: ["*"]
              retry_policy:
                retry_on: gateway-error,connect-failure,refused-stream
                num_retries: 100

              routes:
              - match:
                  prefix: /
                route:
                  cluster: default
                  timeout: 300s
                  idle_timeout: 300s
  clusters:
  - name: default
    type: STRICT_DNS
    respect_dns_ttl: true
    connect_timeout: 0.25s
    lb_policy: LEAST_REQUEST
    least_request_lb_config:
      choice_count: 10
    close_connections_on_host_health_failure: false
    health_checks:
      timeout: 0.25s
      interval: 1s
      no_traffic_interval: 1s
      unhealthy_threshold: 1
      healthy_threshold: 1
      reuse_connection: true
      http_health_check:
        path: /available
    load_assignment:
      cluster_name: default
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address: { address: upstream, port_value: 8080 }

The upstream DNS name resolves to 100 individual IPs running a simple HTTP service. This service is a simulation of a another system, but simpler: 95 of these are configured to always respond with 503 Service Unavailable, and 5 of these respond 200 OK.
(it's implemented as two Deployment resources in kubernetes sharing the same headless Service resource to create the DNS entry)
Via the admin interface, I can confirm the health/unhealthy host counts are as expected:
$ wget -O - http://<IP_ADDRESS>:9901/clusters | grep healthy | wc -l
5

$ wget -O - http://<IP_ADDRESS>:9901/clusters | grep failed_active_hc | wc -l
95

I was expecting an incoming request to be handled "fast" because envoy would be aware of the unhealthy hosts and choose one of the few healthy hosts.
However, what I am observing is the the request is "slow" (just as slow as when I disable health checking entirely) and in the logs of my "unhealthy" services, I can observe they are receiving (and refusing with 503) request attempts from envoy which is then presumably retrying per config until it finds a healthy host.
I'm wondering if my mental model of envoy is correct here. Should I expect it to skip over unhealthy hosts in this situation? Is there something about using STRICT_DNS vs. explicitly listing each endpoint?
Thank you.
Logs
The envoy logs are mostly uninteresting:
[2020-05-11T20:35:57.774Z] "GET /get/6/ping HTTP/1.1" 200 - 0 0 2859 2858 "-" "Go-http-client/1.1" "43eb01c2-50f4-41f4-9d91-139321e7e359" "<IP_ADDRESS>:8111" "<IP_ADDRESS>:8080"
[2020-05-11T20:36:01.841Z] "GET /get/7/ping HTTP/1.1" 200 - 0 0 598 597 "-" "Go-http-client/1.1" "d5a2f3b9-0026-46a6-a04d-1e39cd0963a0" "<IP_ADDRESS>:8111" "<IP_ADDRESS>:8080"
[2020-05-11T20:36:03.647Z] "GET /get/8/ping HTTP/1.1" 200 - 0 0 2713 2712 "-" "Go-http-client/1.1" "fcf65adf-3005-43c6-a3f5-de12d342628d" "<IP_ADDRESS>:8111" "<IP_ADDRESS>:8080"
[2020-05-11T20:36:07.566Z] "GET /get/9/ping HTTP/1.1" 200 - 0 0 1952 1952 "-" "Go-http-client/1.1" "8564aa08-4cd5-4403-bb05-84805284b685" "<IP_ADDRESS>:8111" "<IP_ADDRESS>:8080"
[2020-05-11T20:36:10.726Z] "GET /get/10/ping HTTP/1.1" 200 - 0 0 2083 2082 "-" "Go-http-client/1.1" "1ced62e4-c624-4055-a942-b654ff570aec" "<IP_ADDRESS>:8111" "<IP_ADDRESS>:8080"
[2020-05-11T20:36:14.014Z] "GET /get/11/ping HTTP/1.1" 200 - 0 0 300 300 "-" "Go-http-client/1.1" "b3237d33-4cd7-4983-ac32-e5c3b2d3157e" "<IP_ADDRESS>:8111" "<IP_ADDRESS>:8080"
[2020-05-11T20:36:15.521Z] "GET /get/12/ping HTTP/1.1" 200 - 0 0 1885 1884 "-" "Go-http-client/1.1" "6cb6c805-a4a2-4ab1-907a-d843c7642830" "<IP_ADDRESS>:8111" "<IP_ADDRESS>:8080"

@snowp would you be able to look at this? Thank you!

You're probably hitting panic mode: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/panic_threshold

@snowp That's it, thank you very much.
Adding
    common_lb_config:
      healthy_panic_threshold: { value: 0 }

to my cluster config makes envoy route to the 5 healthy hosts "fast" and skip the 95 unhealthy.
I suppose this is a slightly strange use case. For what it's worth, I'm experimenting with ways to load balance a service that can only process a single request concurrently.


Proposal: Please start using Semantic Versioning

I found that this project already supports Go modules. But sadly, the tags doesn't follow Semantic Versioning, which means that all tags of this project will be ignored by Go modules and replaced by pseudo-versions, go get acts weirdly when tags are not in that form. It would be great to have the tagged release be named in the format vX.X.X format so that go mod can read it.
	github.com/milosgajdos/tenus v0.0.0-20200730100109-997445a7a4dd

Else the mod file shows something like github.com/milosgajdos/tenus v0.0.0-20200730100109-997445a7a4dd which is not very readable and difficult to upgrade. It’s hard to verify which version is in use. This is not conducive to version control
So, I propose this project to follow Semantic Versioning in future versions. For example, v1.0.1, v2.0.0, v3.1.0-alpha, v3.1.0-beta.2etc.

@alrs  @YuviGold  Could you help me review this issue? Thx :p

Hi @KateGo520, I'm happy to do this. I guess maybe we can kick this off with v0.0.1 release. WDYT?

@milosgajdos  I think it's a good idea.

This should now be done.


New package: Libwebsockets v1.0.0

Registering package: Libwebsockets
Repository: https://github.com/bhftbootcamp/Libwebsockets.jl
Created by: @gryumov
Version: v1.0.0
Commit: 2a5a0b2549dc19b6c2ac2e4390b0f94c9292a32f
Reviewed by: @gryumov
Reference: https://github.com/bhftbootcamp/Libwebsockets.jl/commit/2a5a0b2549dc19b6c2ac2e4390b0f94c9292a32f#commitcomment-149152823
Description: Libwebsockets is a Julia wrapper for the libwebsockets library, providing verstile tooling for setting up WebSocket and HTTP clients and servers, managing SSL connections, and handling data efficiently in a variety of applications

[noblock] I’d recommend LibWebSockets

[noblock] I’d recommend LibWebSockets

Hi! Thanks for the suggestion, but I’d prefer to keep the name as it is. There’s some variation in how people split “libwebsockets” into words, so we’ll stick with a version that’s as close to the original name as possible.


lodash: signatures of the method _.floor changed

https://lodash.com/docs#floor
https://lodash.com/docs#_ (description of the chainable wrapper)

thanks mate!


doc: Update section about imperative containers

Nix commands inside the container have been broken since 18.03,
and no fix is yet in sight.  Lets remove from the documentation
that this is a usecase that we support, as it doesn't seem
likely that this will be fixed before 18.09 either.
See #40355
Motivation for this change
Things done

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

[ ] 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 nox --run "nox-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)
[x] Fits CONTRIBUTING.md.

cc @vcunat @samueldr  Perhaps we want to backport this to release-18.09

backport: b72abcf8615

@grahamc fixed it meanwhile.

https://github.com/NixOS/nixpkgs/compare/243e28bc96db...9622cd3b38dd
https://github.com/NixOS/nixpkgs/compare/4c3a0ae44566...4867086bc7e1


Feature: WidgetsBindingObserver to track application wide events

:loudspeaker: Type of change

[ ] Bugfix
[x] New feature
[ ] Enhancement
[ ] Refactoring

:scroll: Description
This PR introduces a WidgetsBindingObserver which can track some application wide changes (like for example lifecycle, accessibility features or display features) as breadcrumbs. It gets added by default.
Currently it only tracks the following events:

app lifecycle
display metrics
changes of light to dark mode and vice versa
text scale factor
memory pressure

There are more events which can be tracked, see next steps.
:bulb: Motivation and Context

It helps developer to better understand crash reports which result from the events mentioned above.

:green_heart: How did you test it?
I've written tests and made sure the example still works as expected.
:pencil: Checklist

[x] I reviewed submitted code
[x] I added tests to verify changes
[x] All tests passing
[x] No breaking changes

:crystal_ball: Next steps
There is still room for improvement and additional functionality. However I'm not sure how to proceed with those.
Therefore I would like to leave it up to you. I also left documentation and some thoughts on what to do.
I also would like some input on what to do with SentryWidgetsBindingObserver.didChangeMetrics. I currently see the option of tracking it as a breadcrumb or to push a new scope as it is a change to the device context.

Codecov Report

Merging #203 (49d6bfa) into main (cca35fd) will decrease coverage by 0.69%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #203      +/-   ##
==========================================
- Coverage   78.88%   78.19%   -0.70%
==========================================
  Files          48       44       -4
  Lines        1468     1371      -97
==========================================
- Hits         1158     1072      -86
+ Misses        310      299      -11

Impacted Files
Coverage Δ

flutter/lib/src/platform_checker.dart

flutter/lib/src/file_system_transport.dart

...lib/src/navigation/sentry_navigation_observer.dart

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 cca35fd...49d6bfa. Read the comment docs.

thanks @ueman once more :)
so my main concern here is, a few of those breadcrumbs are already tracked on the Native SDKs (which we get for free from sentry_flutter), so creating duplicated/noisy breadcrumbs is not something we'd like to do, however, if the Flutter API offers this to all the other platforms (macOS, Web, etc...) it'd make sense to turn it off on the Native SDKs and enable it here only.
I could guide you on how to deactivate the Native SDKs, but we'd need to be sure that the Flutter API offers the same feature on the other platforms, do you know if that works? for Web at least?

So here's what I would like to do:
As Android and iOS already collect some of this data, it would be nice to collect only new events. However because other platforms have no native integration (yet?) it would be nice to record all of them.
Therefore I propose a WidgetsBindingObserverConfiguration class in order to configure which events of WidgetsBindingObserver should be tracked.
Something like this:
class WidgetsBindingObserverConfig {
  WidgetsBindingObserverConfig({
    this.trackLifecycle,
    this.trackWindowMetrics,
    this.trackBrightness,
  });

  factory WidgetsBindingObserverConfig.android() {
    return WidgetsBindingObserverConfig(
      trackLifecycle: false,
      trackWindowMetrics: false,
      trackBrightness: false,
    );
  }

  factory WidgetsBindingObserverConfig.web() {
    return WidgetsBindingObserverConfig(
      trackLifecycle: true,
      trackWindowMetrics: true,
      trackBrightness: true,
    );
  }
   // default options for other platforms...

  final bool trackLifecycle;
  final bool trackWindowMetrics;
  final bool trackBrightness;
  // all the other events...
}

This way it could already be configured nicely by default. It would also give the user the option to track only Flutters lifecycle events in case the user disables SentryOptions.enableAutoNativeBreadcrumbs.
What do you think?

So here's what I would like to do:
As Android and iOS already collect some of this data, it would be nice to collect only new events. However because other platforms have no native integration (yet?) it would be nice to record all of them.
Therefore I propose a WidgetsBindingObserverConfiguration class in order to configure which events of WidgetsBindingObserver should be tracked.
Something like this:
class WidgetsBindingObserverConfig {
  WidgetsBindingObserverConfig({
    this.trackLifecycle,
    this.trackWindowMetrics,
    this.trackBrightness,
  });

  factory WidgetsBindingObserverConfig.android() {
    return WidgetsBindingObserverConfig(
      trackLifecycle: false,
      trackWindowMetrics: false,
      trackBrightness: false,
    );
  }

  factory WidgetsBindingObserverConfig.web() {
    return WidgetsBindingObserverConfig(
      trackLifecycle: true,
      trackWindowMetrics: true,
      trackBrightness: true,
    );
  }
   // default options for other platforms...

  final bool trackLifecycle;
  final bool trackWindowMetrics;
  final bool trackBrightness;
  // all the other events...
}

This way it could already be configured nicely by default. It would also give the user the option to track only Flutters lifecycle events in case the user disables SentryOptions.enableAutoNativeBreadcrumbs.
These options doesn't have to be user facing. For them it still could only be the option to enable or disable them and the SDK chooses which to enable per platform. I hope you get what I mean.
What do you think?

That sounds a good idea, although I'd not add those options as an extension method, as the Integration is created automatically by our SDK, also because the natural/standardized way of enabling things across SDKs is via SentryOptions.
I'm ok with fine grain options to turn things on and off, see on Android, we have pretty much the same.
https://github.com/getsentry/sentry-java/blob/main/sentry-android-core/src/main/java/io/sentry/android/core/SentryAndroidOptions.java#L22-L35
2 things I'd consider rather important, the breadcrumbs should follow the same type, category, action etc... as the UI renders it nicely based on those settings (See Android).
I'd document that if you enable options X, you might want to disable option Y to not get duplicated breadcrumbs.
how does that sound?

Yep, sounds good!

How am I supposed to add Flutter specific options to SentryOptions?
It doesn't really make sense for them to be on SentryOptions but I also can't subclass SentryOptions because SentryFlutter.init already receives an options instance from Sentry.init. So I can't initialize and pass my own subclass.
Should I just add a second options class? Like for example:
  await SentryFlutter.init(
    (options, flutterOptions) {
      options.dsn =<EMAIL_ADDRESS>      // configure SentryFlutter with flutterOptions
      // flutterOptions.exampleOption = true;
    },
    // Init your App.
    () => runApp(MyApp()),
  );

How am I supposed to add Flutter specific options to SentryOptions?
It doesn't really make sense for them to be on SentryOptions but I also can't subclass SentryOptions because SentryFlutter.init already receives an options instance from Sentry.init. So I can't initialize and pass my own subclass.
Should I just add a second options class? Like for example:
  await SentryFlutter.init(
    (options, flutterOptions) {
      options.dsn =<EMAIL_ADDRESS>      // configure SentryFlutter with flutterOptions
      // flutterOptions.exampleOption = true;
    },
    // Init your App.
    () => runApp(MyApp()),
  );

so on Android, we had this problem and we created a specific AndroidOptions and we inited via reflection which is suboptimal but solved it.
I believe that at some point even if we create a FlutterOptions we'll end up with custom options that only make sense to a specific platform (Android/iOS/macOS/Linux, etc...).
Not sure if it makes sense to go fine-grained here, I'd just add those options to the current class but documenting its usage for X platform, actually I've done this already for a few options but it's not great, I agree.
@bruno-garcia opinions?

Dart for Flutter does not support reflection, so that is no option.

No overloading makes it hard because we could simply add an overload to Sentry.init that takes SentryOptions so we can pass FlutterSentryOptions (which would derive from SentryOptions) to it.
Last we have is a apply method that will apply values from one instance to the other. Still go with the inheritance but in the callback of init apply the value from to the instance we got from Sentry.init. Would that work?

No overloading makes it hard because we could simply add an overload to Sentry.init that takes SentryOptions so we can pass FlutterSentryOptions (which would derive from SentryOptions) to it.
Last we have is a apply method that will apply values from one instance to the other. Still go with the inheritance but in the callback of init apply the values to the instance we got from Sentry.init. Would that work?

One could do
// option 1: Optional positional parameter
static Future<void> init(
    OptionsConfiguration optionsConfiguration, [
    AppRunner appRunner,
    List<Integration> initialIntegrations,
    SentryOptions sentryOptions,
  ]) async {
    if (optionsConfiguration == null) {
      throw ArgumentError('OptionsConfiguration is required.');
    }

    final options = sentryOptions ?? SentryOptions();
    await _initDefaultValues(options, appRunner, initialIntegrations);

    await optionsConfiguration(options);

    if (options == null) {
      throw ArgumentError('SentryOptions is required.');
    }

    await _init(options);
  }

or
  // option 2: Optional named parameter, would be breaking but Sentry v4 is still in alpha 🤷♂
  // The upside here is that one could document parameters a little bit better since they have a name.
  static Future<void> init(
    OptionsConfiguration optionsConfiguration, {
    AppRunner appRunner,
    List<Integration> initialIntegrations,
    SentryOptions sentryOptions,
  }) async {
    if (optionsConfiguration == null) {
      throw ArgumentError('OptionsConfiguration is required.');
    }

    final options = sentryOptions ?? SentryOptions();
    await _initDefaultValues(options, appRunner, initialIntegrations);

    await optionsConfiguration(options);

    if (options == null) {
      throw ArgumentError('SentryOptions is required.');
    }

    await _init(options);
  }

Both options are like method overloading.
I would prefer one of the above suggestions over an apply method. My reasoning is that this kind of manual mapping is kinda error prone. Additionally the SentryFlutterOptions aren't automatically passed to the Integration here https://github.com/getsentry/sentry-dart/blob/main/flutter/lib/src/sentry_flutter.dart#L41 .

hey @ueman a bit off-topic but if you'd like to join our discord chat: https://discord.gg/Ww9hbqr
there's a #flutter channel :)

hey @ueman be aware of #214
we might get a few git conflicts but might be easily fixable, we were needing to change a few things because of other features, so expect a similar solution of yours landing tomorrow :) thanks!

I've changed the code based on your feedback. Thanks for the throughout review!

@ueman so I upstream the Flutter configurations fix as I wanted to release asap.
Just pull the latest changes and ready to be merged :)


0.0.8 Release

0.0.8   Will be the first registered version of Olive, consisting of  a working pre-release version of  Olive.  This release will be a preview of what is to  come in 0.1.0, as well as an easy way to iron out any bugs that are expected with a project of this magnitude.
cell types

:code
:pkgrepl
:helprepl
shell
olive
todo
creator
module

All that is needing completion for this release is some Cells.jl reorginazation,  docs, some improvements to /doc, and syntax highlighting :)

Also, create could use completion.

Reimplementing new cells around new extracted design... There are only a few things left to do for this first release.

Add returner to directories
Add environment directory
Update ALL cell functions (reimplementing of cells)
Make dir add for root
finish Olive.create
module cells

gimme like one more day. :)

6 more issues until 0.0.8 :)

i lied, maybe 1 more day lol...

I'm tired of my mind, I always hate her
julia julia @JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/79866
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.0.8 -m "<description of version>" af34123f35cd5faf7ac45b85b197f51aa0d81fc7
git push origin v0.0.8

Also, note the warning: This looks like a new registration that registers version 0.0.8.
Ideally, you should register an initial release with 0.0.1, 0.1.0 or 1.0.0 version numbers
This can be safely ignored. However, if you want to fix this you can do so. Call register() again after making the fix. This will update the Pull request.

i lied, maybe 1 more day lol...

i lied, maybe like an hour


Make Maybe tail recursive

Maybe is built with Eval so it should be possible to make it tail recursive also.

completed on branch


Do not differ between CommonJS and ESM builds

What problem does this feature solve?
Parcel 2 breaks on Vue with HMR because it expects __VUE_HMR_RUNTIME__ to be defined in the global scope. This is only defined in the ESM build because Vue assumes all bundlers will use ESM. However, to save Babel compilation time in development, Parcel 2 uses the CommonJS version, defined by "main" in package.json, meaning the HMR runtime added by the Vue transformer breaks. This issue was found in parcel-bundler/parcel#5325.
What does the proposed API look like?
Code that functions differently with CommonJS and ESM is unusual and is arguably an antipattern. Creating a CJS version for bundlers and adding that to "main" or adding the HMR runtime to the existing CJS build would fix the issue.

This sounds more like a bug in Parcel: they should follow the same convention followed by webpack and include the module instead of main one when doing bundling. That way they can benefit from tree shaking. The CJS version is meant to be used on Node

Code that functions differently with CommonJS and ESM is unusual and is arguably an antipattern.

No, because both target different environments (Node vs Browser) so it makes sense to optimize them differently

Tree shaking doesn't work with HMR, hence ESM is useless when developing with HMR and transpiling ESM to CommonJS, which is ultimately used in the final build, only slows the build down.
You can't assume ESM is bundler and CJS is Node anymore; Node supports ESM loading. Instead, the "browser" field of package.json should being used to do that.
If you really want to force Parcel to unnecessarily transpile ESM in development, setting the "browser" field to the ESM version will fix the issue.

The modern way for different builds for esm/cjs/node is the exports field: https://webpack.js.org/guides/package-exports/#target-environment.

@posva Would adding the "browser" field to package.json be possible? It just needs to refer to the same thing as "module" and would fix Parcel 2 support.

If I recall correctly, using "browser" for the ESM breaks other things because it's not a browser module, it contains environment variables

As far as I know, only bundlers support the "browser" key, and since bundlers can replace the environment variables, it should work...

No, bundlers are not the only ones, some cdns use it too

One solution would be adding typeof process !== "undefined" when the env variables are checked.


cowboy_req:qs/match_qs cannot handle 2 or more key/value query string

for URL like
/path?id=135&lang=en
below dosen't work:
{id := ID, lang := Lang} = cowboy_req:match_qs([id, lang], Req)

I have a test for this that is passing. You'll have to provide more info.

sorry, it looks like a cURL problem. it's OK when using Safari browser.

when using cURL command line, the URL should be quoted, just like a string:
curl "http://localhost:8080/path?id=135&lang=en"
otherwise, without quoted, only the first query parameter are submit

Right, because & is a special character in the shell to run the command in the background. Closing!


TypeScript Project Properties for Unit Test Projects

I would like to request the feature to support Visual Studio Unit Test projects with this extension (ie. include the project tab TypeScript Build in unit test project properties).
Standard practice is to have 1 unit test project for every code project in Visual Studio and I want to include my type script tests written against my typescript in my web project in the unit test project. The problem is that the visual studio unit test project does not have a project page called "Typescript Build" where I can configure the project to watch and automatically compile the .ts files into .js files. This forces me to use a 3rd party tool like chutzpah to compile files manually so I can test them which is cumbersome and also slower than if VS does it on the fly.

See #1398

Thank you for the pointer Dan. What I am looking for is not a javascript/typescript unit test runner but the option to automatically compile typescript (.ts) files to javascript (.js) in a visual studio unit test without the use of another plugin. I figure the easiest way to add this support is to add the project settings for typescript to other projects. If I am unclear please see this link where I have included a screen shot in a question on the msdn forums

Ah, got it. I'm not an MSBuild expert. You're definitely not going to get the project properties page updated by doing that though. Can you set the action on your TypeScript files to build though (in the Properties window)?

@IgorWolbers from your msdn issue, looks like you did not add the targets file. what you need is:

prop files at the top
targets at the bottom
all typeScript files should be in TypeScriptCompile tags
configurations

e.g:
 <PropertyGroup>
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">14.0</VisualStudioVersion>
  </PropertyGroup>

  <ItemGroup>
    <TypeScriptCompile Include="app.ts" />
  </ItemGroup>
  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props')" />
  <PropertyGroup Condition="'$(Configuration)' == 'Debug'">
    <TypeScriptRemoveComments>false</TypeScriptRemoveComments>
    <TypeScriptSourceMap>true</TypeScriptSourceMap>
    <Prefer32Bit>false</Prefer32Bit>
  </PropertyGroup>
  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets')" />

Thank you! I am going to try it first thing tomorrow and will report back the results.

Works like a charm, thank you so much!

glad it helped.

HI @mhegazy or @IgorWolbers
I have the same problem. I have a main project with TS files in it and that compiles just fine.
I have a second project (in the same solution) that is my unit test project for my TS files. The TS files in this project do not get compiled. They do get compiled if I save them, but if I do a build clean - the JS and JS.map files don't get cleared out. If I remove them by hand, then they don't get regenerated when I build the project.
I am trying to understand the comment by @mhegazy and what file he is referring to. Is that the csproj file for the unit test project? If so, I found that I didn't have the import statements in my csproj for the unit test project but I did have them in the main project csproj file. I found that my unit test csproj already had the <TypescriptCompile....> lines for each file in my project. And there were no typescript flags in my debug property group section.
I added the imports and the debug flags but when I reload the project and select build for that project it still doesn't build the TS files into JS files.
I noticed that Typescript 2.0.0 is now a nuget package that can get installed into a project. I have been using 1.8 to this point. With 2.0.0, should I be installing the typescript package into my main project and into my unit test project?
Thanks for any help.
Greg

Ok I think I got it. My csproj had lots of stuff in it so I wasn't sure where to put the import lines. It seems the order is important. When I moved the second import line to the bottom of my csproj - right below the import line for c#, then it started to work. My guess, looking at the import statement is that the condition was false when it was evaluated at the beginning of the file because it hadn't hit the <TypescriptCompile...> lines yet.
BTW, even though this is a work around, I hope something has been done so that when creating a new project and new unit test project all of this is done automatically.
Thanks
Greg

@gregveres  - correct, the order is important. Why that is I am not sure. However in the most up to date versions of VS you can now include a tsconfig.json file and enable the "compileOnSave": true feature. This is the now recommended and supported way to ensure that typescript files are compiled in a VS project and also how they are compiled (based on the settings in that file).

Thanks @IgorWolbers
I did have a tsconfig.json and compileOnSave: true. That's how I have been running for months. This shouldn't and can't be the recommended and only supported way of getting JS files. It works fine for your local dev machne but when multiple people are working on a project, it would mean that every person would have to go touch all the TS files to get JS files rather than doing a build. Also, you can't have compileOnSave work on a hosted build server. I finally ran this down because I am now trying to get my TS unit tests running on Visual Studio Online and the problem I was running into was that the build didn't create the JS files so when Chutzpah ran, it couldn't find anything to run.
So these modifications to the csproj file need to get into VS studio automatically somehow or the system is just broken. I consider it a bug that the import line wasn't put in there given that the Typescriptcompile lines were put in the csproj file.

@gregveres  - ah hah, got it. Yes, I too struggled for a while to get that working but the good news is that typescript unit testing in VSTS does work.
Good luck!

@IgorWolbers - yup now that I have the build of TS -> JS files working my unit tests are working well on VSO. Do you use modules in TS? I am now trying to setup an MVC app that treats each MVC page as a single page app. I am trying to get TS setup with requireJS but I am having trouble figuring out the right import syntax to use and the right requireJS config settings. If you are using TS with requireJS in a similar fashion I would love to see what you are doing. greg.veres @ rogers . com if you are willing to continue the discussion.
Thanks
Greg


Change the input camera

Is it possible to change the input camera on mobile or other devices?

Hi @teawithfruit!
Sorry for the late reply.
It would be a great idea to be able to change the camera (front/back) on mobile or other devices, however this feature is not integrated into the plugin for now. I will work on the possibility of taking this change into account in the near future.
Thanks for your interest in the project and don't hesitate to star/watch to be notified about code modification.

Note: concret sample found at https://webrtc.github.io/samples/src/content/devices/input-output. Will be usefull for feature implementation.

@teawithfruit up

Hi @teawithfruit,
Sorry for the long wait, I will work on that today :wink:


After upgrade to 1.20.1, cannot connect. Error:  A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: HTTP Provider, error: 0 - )

Microsoft.Data.SqlClient.SqlException (0x80131904): A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: HTTP Provider, error: 0 - )
at Microsoft.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action1 wrapCloseInAction)    at Microsoft.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)    at Microsoft.Data.SqlClient.TdsParser.ConsumePreLoginHandshake(Boolean encrypt, Boolean trustServerCert, Boolean integratedSecurity, Boolean& marsCapable, Boolean& fedAuthRequired)    at Microsoft.Data.SqlClient.TdsParser.Connect(ServerInfo serverInfo, SqlInternalConnectionTds connHandler, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Boolean encrypt, Boolean trustServerCert, Boolean integratedSecurity, Boolean withFailover, SqlAuthenticationMethod authType)    at Microsoft.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, SecureString newSecurePassword, Boolean ignoreSniOpenTimeout, TimeoutTimer timeout, Boolean withFailover)    at Microsoft.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(ServerInfo serverInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString connectionOptions, SqlCredential credential, TimeoutTimer timeout)    at Microsoft.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(TimeoutTimer timeout, SqlConnectionString connectionOptions, SqlCredential credential, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance)    at Microsoft.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, SqlCredential credential, Object providerInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString userConnectionOptions, SessionData reconnectSessionData, Boolean applyTransientFaultHandling, String accessToken, DbConnectionPool pool)    at Microsoft.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions)    at Microsoft.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup, DbConnectionOptions userOptions)    at Microsoft.Data.ProviderBase.DbConnectionFactory.<>c__DisplayClass45_0.<TryGetConnection>b__1(Task1 _)
at System.Threading.Tasks.ContinuationResultTaskFromResultTask`2.InnerInvoke()
at System.Threading.Tasks.Task.<>c.<.cctor>b__274_0(Object obj)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location where exception was thrown ---
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.SqlTools.ServiceLayer.Connection.ReliableConnection.ReliableSqlConnection.<>c__DisplayClass30_0.<b__0>d.MoveNext() in D:\a\1\s\src\Microsoft.SqlTools.ManagedBatchParser\ReliableConnection\ReliableSqlConnection.cs:line 314
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.SqlTools.ServiceLayer.Connection.ConnectionService.TryOpenConnection(ConnectionInfo connectionInfo, ConnectParams connectionParams) in D:\a\1\s\src\Microsoft.SqlTools.ServiceLayer\Connection\ConnectionService.cs:line 549
ClientConnectionId:fcbf6f8f-2e85-4ae0-aeb8-11f4527f7e9b

Try the solutions mentioned in https://github.com/microsoft/azuredatastudio/issues/11367#issuecomment-659614111 and let us know if you still encounter issues.

Worked.
https://github.com/microsoft/azuredatastudio/issues/11367#issuecomment-659614111


docker build : install devDependencies so the build succeed

Declaring
ENV NODE_ENV=production before npm install will not install devDependencies and the build will fail with a TypeScript error, see issue #1593
Move the declaration before RUN npm run build:app so the build succeed.

Looks good. Thanks!


Fix /shows/last_updated not working

fix the show/last_updated route not working
also removed Q dependency from setup.js

This is no longer relevant.


Verify Plot Visualizations

Quickly run through each plot endpoint and make sure it doesn't blow up completely. Create bugs for each endpoint that doesn't work correctly or if you notice it has missing parameters, etc...

Integration tests (Issue #3 ) will prove that each plot endpoint works, so this issue is a duplicate.


Add scripts

Hello,
Thanks for your tool!
Is there any way to add scripts assignments to your tool ? (https://endpoint.microsoft.com/#view/Microsoft_Intune_DeviceSettings/DevicesMenu/~/scripts)
Thanks.

Hi,
yes it is possible and that is actually work in progress at the moment. This applies to Powershell scripts and Proactive Remediation scripts.
Next bigger release should have scripts included in the UI.

will there be a web version of this??


Inquiry Regarding Dataset Architecture and Organization

I hope this message finds you well. I would like to express my gratitude for the significant contributions you have made to the project. Your work has been truly inspiring and has provided me with valuable insights into the tasks I am aiming to accomplish.
Unfortunately, due to various reasons, I have encountered challenges in accessing the dataset hosted on dfdc.ai. Instead, I have been able to locate the dfdc dataset within the Kaggle project. I am reaching out to kindly inquire if you could provide some insights into the specific architecture of the dataset and the roles played by each of its components.
Additionally, I have a specific question regarding the contents of the DFDC folder. Are the data stored in this folder a combination of video frames with both FAKE and REAL attributes? Or do all REAL video frames exclusively reside in the ORIGINAL folder, while the remaining FAKE video frames are distributed across folders such as DFDC, FACE++, and others?
I understand that your time is valuable, and I genuinely appreciate your consideration in addressing my inquiries amidst your busy schedule.
Thank you for your time and assistance.

I followed the solution you suggested in #18, but encountered this problem, but I did not change the program

I followed the solution you suggested in #18, but encountered this problem, but I did not change the program


wip: docker image to run website linters

docker build -t gcr.io/istio-io/website-builder .
gcloud docker -- push gcr.io/istio-io/website-builder

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: ayj
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: linsun
Assign the PR to them by writing /assign @linsun in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Wow. You make it seem so simple!

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: ayj, geeknoid
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [geeknoid]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

New changes are detected. LGTM label has been removed.

/lgtm

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: ayj, geeknoid
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [geeknoid]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


terminal.wordWrap & terminal.wordWrapColumn [feature-request] [settings]

Please, add more terminal settings!

No plans to add these, you may be able to drive this by configuring your shell however on macOS/Linux.

wgat about windows & bash term?

@xaota please consult the shell documentation. You can certainly tweak wrapping settings in bash, which is one of the reasons adding this to vscode is out of the question imo.


Move JDK shims to munit.internal

Will fix #437.

You can run scalafixAll and scalafmtAll inside the sbt shell to fix the Scalafix error

Thanks for the feedback and pointers. I'm still tracking down various linking issues for JS then I'll iterate on your feedback 👍

Uh-oh, maybe I should wait on this until you decide what you want to do? 😅  Removing I/O completely would be excellent for browsers and friends.

You can try to implement this alternative approach if you're interested. The steps would be

Add new textContents field to munit.Location, with a fallback constructor that defaults to textContents = "" https://github.com/scalameta/munit/blob/e331ee3666838edb6318653c7d903a6e193e4be2/munit/shared/src/main/scala/munit/Location.scala#L14
Update the Scala 2 macro to inline the contents here https://github.com/scalameta/munit/blob/e331ee3666838edb6318653c7d903a6e193e4be2/munit/shared/src/main/scala/munit/internal/MacroCompatScala2.scala#L15
Update the Scala 3 macro to inline the contents here https://github.com/scalameta/munit/blob/e331ee3666838edb6318653c7d903a6e193e4be2/munit/shared/src/main/scala-3/munit/internal/MacroCompat.scala#L20
Update Lines.scala to use Location.textContents instead of file I/O

I'm sorry for guiding you in the other direction, this idea didn't come up until after you opened the draft PR.

The CI seems green so we can also merge this PR as is and I can look into the alternative later.

Apologies, getting a bit out-of-scope for me. As it stands this PR does the hard part of #437 by tracking down all the JDK stuff and condenses it. All that's left is bike-shedding names according to unwritten convention which it seems you are the expert on 😉

Apologies, I regret my remark as it came across poorly I think 😕 I have ton of respect for projects and developers that keep things organized, extremely important for projects like this at the top of the dependency food chain. It's just hard for me to know exactly how you want things without a couple more iterations and it seems the future of this PR is dubious depending on some very good changes that might be forthcoming. So I'm happy to let this sit and if it's still relevant by the time 1.0 is solidifying then we can make it all perfect :)

@olafurpg we've been butting heads with this problem again in https://github.com/http4s/http4s/pull/5758.
Would you be open to accepting the changes in this PR into 0.7.x series (after it's polished up)? I know it's technically a breaking change, but in fact anyone who experiences that breaking change likely had bugs/linking issues that were masked precisely because of these shims.
Thanks!

Oh, one more idea: if you really want to avoid a breaking change, we apply the changes here, and also move these shims into a new artifact. So anyone that experiences issues because of the change, can just add a new dependency to get the shims back (or alternatively, the shims can be included by default and downstreams where it causes a problem can remove it explicitly).

@olafurpg I've now renamed/re-organized everything as you suggested. Thanks for your patience on this one! :)


Automated cherry pick of #3573: Update latest version to v0.9.1

Cherry pick of #3573 on website.
#3573: Update latest version to v0.9.1
For details on the cherry pick process, see the cherry pick requests page.
NONE

This is the part of the releasing v0.9.1
/assign @mimowo

/lgtm
/approve


fix compile warning, which will be compile error in upcoming swift 6

fix #1122
Checklist - While not every PR needs it, new features should consider this list:

[x] Does this have tests?
[ ] Does this have documentation?
[ ] Does this break the public API (Requires major version bump)?
[ ] Is this a new feature (Requires minor version bump)?

@wongzigii

Thanks


IOS Sample App Request

I saw in the issues section that many developers are requesting this due to the errors they are facing like ld: framework not found FirebaseFirestore. Can you please provide a simple sample that we can load on ios and follow to set for our project?

Pulling this out from our discussion in #288. Here are basic setup instructions that worked for us:
Swift Package Manager Setup

Create new Kotlin Multiplatform App from Android Studio (AS version is 2021.2.1, Chipmunk, KMM plugin version is 0.3.2(212-1.6.10-release-974-IJ)-216)
Select Regular Framework for the setting iOS Framework Distribution
Add classpath("com.google.gms:google-services:4.3.10") to the dependencies section of buildscript under MyApplication/build.gradle.kts
Add apply(plugin = "com.google.gms.google-services") and implementation(platform("com.google.firebase:firebase-bom:30.0.1")) to appAndroid/build.gradle.kts
Add dependencies { implementation("dev.gitlive:firebase-firestore:1.6.1") } to commonMain in shared/build.gradle.kts
Set isStatic = true in your shared/build.gradle.kts
Link your google-services files to both androidApp and iosApp as you would usually, following the Firebase docs
Open File -> Add Packages on Xcode and add https://github.com/firebase/firebase-ios-sdk
Select FirebaseFirestore from the available SDKs, add it to your project and wait until Xcode finishes initialising
Make sure to call the relevant dev.gitlive.Firebase.initialize() methods for iOS and Android where appropriate in your project before making any calls
Both Android and iOS should build successfully now and you should be able to use the SDKs in commonMain

I saw in the issues section that many developers are requesting this due to the errors they are facing like ld: framework not found FirebaseFirestore. Can you please provide a simple sample that we can load on ios and follow to set for our project?

https://github.com/leoull/KMM-FirebaseAuth

Hi, I finish to publish an article about this https://medium.com/@carlosgub/how-to-implement-firebase-firestore-in-kotlin-multiplatform-mobile-with-compose-multiplatform-32b66cdba9f7


Update MoveCamera.cs

This should be merged. This is just good code practice.

This should be merged. This is just good code practice.

This should be merged. This is just good code practice.


feat: add bot.load_extensions

Summary
This PR adds a new function in ext.commands.bot that loads all extensions found in a folder.
Checklist

[ ] If code changes were made then they have been tested.

[ ] I have updated the documentation to reflect the changes.

[ ] This PR fixes an issue.
[x] This PR adds something new (e.g. new method or parameters).
[ ] This PR is a breaking change (e.g. methods or parameters removed/renamed)
[ ] This PR is not a code change (e.g. documentation, README, ...)

I am not sure if this is necessary

I am not sure if this is necessary

That is a good point, but the reason I wanted to open this PR is if you have many bots, you'll have to copy-paste the same code over and over again to load extensions and honestly I think it's better if it's in the library itself.

That is a good point, but the reason I wanted to open this PR is if you have many bots, you'll have to copy-paste the same code over and over again to load extensions and honestly I think it's better if it's in the library itself.

My point is, that might not be usable for you if you have a different folder structure cause this kinda requires a given folder structure which might be "normal" to use but still might not be your personal taste.
I guess that lies in epic's hands.

I feel it would maybe be better to load all extensions provided, rather then finding them itself. Where the input would be a list of paths to load in current format.

Can I offer an alternative solution for find_load_extensions that is working for me?
https://gist.github.com/DenverCoder1/49cc433c7bf5c9a70ff12ff01e4da6ed
This supports both of these file structures:
.
├── main.py
└── cogs
    ├── cog1.py
    └── cog2.py

.
├── main.py
└── cogs
    ├── cog1
    │   └── __init__.py
    └── cog2
        ├── __init__.py
        └── extras.py

And can be run with bot.find_load_extensions("cogs") where "cogs" is the parent module (not path).

What's the reason to return the list of successfully loaded extensions. Seems unnecessary as that is what you give as input and the function raises an exception if any extension fails.

That is a good point for load_extensions, yes, however for find_load_extensions, it serves a different purpose. It serves the purpose of telling you the names of the extensions found & loaded in the provided cog folder. I should definitely supply the parent folder path along with the extension name.

Can I offer an alternative solution for find_load_extensions that is working for me?
https://gist.github.com/DenverCoder1/49cc433c7bf5c9a70ff12ff01e4da6ed
This supports both of these file structures:

.

├── main.py

└── cogs

    ├── cog1.py

    └── cog2.py

.

├── main.py

└── cogs

    ├── cog1

    │   └── __init__.py

    └── cog2

        ├── __init__.py

        └── extras.py

And can be run with bot.find_load_extensions("cogs") where "cogs" is the parent module (not path).

I don't like this solution. It doesn't use glob syntax and it hardcodes in a prefix, which was something you didn't want according to Discord. If you just want me to warn people that find_load_extensions only works via a relative path, then I will.

A useful optional argument in find_load_extensions can be a list called something like ignore, so if I have multiple cogs in cogs/ - with a utils.py file which isn't a cog, I can simply pass in ignore=["utils.py"]

It doesn't use glob syntax and it hardcodes in a prefix, which was something you didn't want according to Discord. If you just want me to warn people that find_load_extensions only works via a relative path, then I will.

Not sure what you mean by hardcoding a prefix. This basically works similar to load_extension, but takes the parent module instead of the submodule, and loads all submodules in the specified parent module.
I like koala's idea of being able to exclude specific modules. In my opinion, it should take the extension names eg:
bot.find_load_extensions("my.cog.module", exclude=["utils"])

Also, maybe there is a better name for this function? I don't know what the best name would be, but I'm thinking it would make more sense if it were called something like load_extensions_from_module or load_submodule_extensions. Something in that sense.

After some thinking, I think I might rename find_load_extensions to load_extensions_from_module. It sounds a little more descriptive and less wordy.

Can I offer an alternative solution for find_load_extensions that is working for me?
https://gist.github.com/DenverCoder1/49cc433c7bf5c9a70ff12ff01e4da6ed
This supports both of these file structures:
.
├── main.py
└── cogs
    ├── cog1.py
    └── cog2.py

.
├── main.py
└── cogs
    ├── cog1
    │   └── __init__.py
    └── cog2
        ├── __init__.py
        └── extras.py

And can be run with bot.find_load_extensions("cogs") where "cogs" is the parent module (not path).

Sorry about rejecting this approach earlier, it's clear to me now that it might be better than my current implementation

Also, since that alternative implementation suggested removing the returned list of the names of the extensions that loaded successfully (in both load_extensions and load_extensions_from_module), I just want to justify why I didn't make that change:
When the developer is loading extensions via load_extensions_from_module for example, they cannot predict which modules loaded successfully and where they are from. Because of this, it would be advantageous to tell the developer which extensions loaded successfully. Why? Well maybe they want to inform the user about the extensions that were able to load. It'll save developers some time trying to figure out which extensions loaded successfully.

I'm not sure how package(s) are meant to be used.

It's supposed to be the source package for a relative import, and the plural is for if each extension has a different source package for relative import.

For the docstrings, maybe an example usage could be helpful to make it more likely people will understand how to use it (eg. a Usage :: section)?
Also, it should probably have versionadded

For the docstrings, maybe an example usage could be helpful to make it more likely people will understand how to use it (eg. a Usage :: section)?
Also, it should probably have versionadded

Resolved in f654c77

Sphinx isnt very compliant


[FEATURE REQUEST] Add favicon option

Same as some relay implementations allow, I suggest adding an option to store and select a favicon on config and offer this to the clients that request it
Example:
https://github.com/scsibug/nostr-rs-relay/blob/master/config.toml#L19-L21
Example of a favicon.ico hosted on a relay:
https://relay.minibolt.info/favicon.ico
Result on clients, for example, Amethyst:

Done.
{
  favicon: "path/to/favicon.ico"
  ...
}

In config.js


Update xlsx parser to properly handle percentages

Overview
See https://github.com/frictionlessdata/tabulator-py/issues/330

Please preserve this line to notify @roll (lead of this repository)

@roll Added tests and fixed on py2