Add support to MSIX as packaging format for UWP unit tests

Description

IMPORTANT: if the defect is reproduced only in a workflow from within the Visual Studio IDE then do not report the issue here - instead, please report it using Visual Studio's "Send Feedback" option that can be accessed from the Help menu OR using this link https://developercommunity.visualstudio.com.
For a defect reproducable from the vstest command line, describe the issue you've observed.

In Windows 10 1809 Microsoft has released the next generation of Windows 10 packaging format for Windows applications, called MSIX. This format is replacing AppX and Visual Studio generates a MSIX package if a UWP project has 17736 as minimum target SDK.
The same applies to UWP unit test projects. If you choose 17736 as minimum target SDK, Visual Studio will generate a MSIX package.
In this scenario the Test Explorer in Visual Studio can run tests just fine, but vstest.console isn't able to recognize MSIX properly. When you try to run it passing, as parameter, the path to the generated MSIX package, it will find the tests, but then it won't execute them.
The same unit test project with a lower min SDK target and packaged as AppX will be executed just fine.
Steps to reproduce

What steps can reproduce the defect?
Please share the setup, commandline for vstest.console, sample project, target
framework etc.

Create a Universal Windows Platform class library, selecting 18362 as Target SDK and minimum SDK.
Inside the library create a class which exposes a simple sum method.
Create a Unit Test UWP project, selecting 18362 as Target SDK and minimum SDK.
Add a test to validate the sum method defined in the library.
Run the tests with Test Explorer in Visual Studio. Notice how the test is properly executed.
Right click on the Unit Test project, choose Publish -> Create app package and complete the wizard. It will generate a MSIX package.
Ran from the command line:

vstest.console package_name.msix
Expected behavior

Share the expected output

vstest.console should find the test and execute them.
Actual behavior

What is the behavior observed?

vstest.console finds the test, but then it doesn't execute them.
This is the output you get:
`
Microsoft (R) Test Execution Command Line Tool Version 16.4.0
Copyright (c) Microsoft Corporation.  All rights reserved.
Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
Additionally, path to test adapters can be specified using /TestAdapterPath command. Example  /TestAdapterPath:.
`
Diagnostic logs

Please share test platform diagnostics logs. Instructions to collect logs are here.
The logs may contain test assembly paths, kindly review and mask those before sharing.

Environment

Please share additional details about the test environment.
Operating system, Build version of vstest.console

Windows 10 1909
Microsoft (R) Test Execution Command Line Tool Version 16.4.0

So... more than a year, and this is still an issue?
Is there any workaround for this?  As-is, it appears like I cannot run UWP unit tests from the command line.

Ok, so after some more research, it appears possible to use vstest to run the unit tests from the command line:
vstest.console.exe /Platform:x64 YOUR_PACKAGE_<IP_ADDRESS>_x64_Debug.msix /Logger:trx /framework:frameworkuap10
The key was adding the framework flag.  Without it, I get the original issue.

Closing as there is a workaround provided.


Improve some metrics

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

Project coverage is 100.00%. Comparing base (fbbf131) to head (590f51f).
Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #453   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files          107       107
  Lines         2724      2724
  Branches       163       163
=========================================
  Hits          2724      2724

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


Integration with DSPy

Implement a DspyMetricAdapter (or similar name) that allows users to utilize metrics defined as DSPy modules. This adapter will serve as a bridge, converting DSPy metrics a metric compatible with continuous-eval.
Technical Details:

Base Class: The DspyMetricAdapter (or similar name) will extend the Metric class, which is the fundamental interface for metrics within continuous-eval.
Functionality: The adapter will wrap a DSPy module representing a metric, handling the conversion of input data and output results to match the expectations of continuous-eval.

Scoping this out a bit further. Two questions:
1) Do we want this as a required or optional dependency? I'm guess the former
We would need to add dspy-ai = ">=0.1.9" to The project toml
2) The handing of the DspyMetricAdapter
This will all essentially require adding a class to metrics/base.py
Something like? 👇
import dspy
from typing import Dict

class DspyMetricAdapter(Metric):
    def __init__(self, dspy_module: dspy.Module):
        super().__init__()
        self.dspy_module = dspy_module

    def __call__(self, **kwargs) -> Dict[str, Any]:

        dspy_inputs = self._convert_inputs(kwargs)
        dspy_outputs = self.dspy_module(**dspy_inputs)
        metric_outputs = self._convert_outputs(dspy_outputs)

        return metric_outputs

    def _convert_inputs(self, inputs: Dict[str, Any]) -> Dict[str, Any]:

        # logic to convert continuous-eval inputs to dspy module inputs
        dspy_inputs = {}
        return dspy_inputs

    def _convert_outputs(self, outputs: Any) -> Dict[str, Any]:

        # logic to convert dspy module outputs to continuous_eval ouputs
        metric_outputs = {}
        return metric_outputs

What is the desired flow? What I mean by flow is, do we want a user to be able to do something like 👇
import dspy
from continuous_eval.metrics.base import DspyMetricAdapter

dspy_module = dspy.Module(...)
metric = DspyMetricAdapter(dspy_module)
result = metric(...)

Hi Diane, thanks for working on the issue!

Yes, it should be an optional dependency
That's correct but I would not put the DspyMetricAdapter in the metrics/base.py file, maybe metrics/integrations/dspy.py`? We do not want to raise an error if DSPy is not installed or add redundant code to avoid it
The flow looks good to me!

I need to understand  "the adapter will wrap a DSPy module representing a metric" and "conversion of input data and output results" to a higher granularity.
1)  "the adapter will wrap a DSPy module representing a metric"
What exactly do we want a user to use DSPy for within the continuous-eval framework?
A) Is the goal to be able to run DSPy but  evaluate using one of the continuous-eval  metrics?
This seems unlike given the class DspyMetricAdapter(Metric) structure  indicates this class is a metric in itself.  Also if A)   is the case this wouldn't be a good first issue given how many metrics there are to consider.
B) Is the goal rather to allow a user to use metrics from the DSPy library within the continuous_eval framework? This would also  be confusing since DSPy doesn't have many built-in metrics and its more on the user to create their own.
2) "conversion of input data and output results"
Answering the first should help here, but what exactly would we want to output?

The idea is to use a DSPy module as metric. So you can define your signature, you wrap the signature in a module (optionally you can optimize it) and use it within a continuous-eval pipeline. For example, if a user created DSPY module to measure the tone of a answer it could be something like
class Tone(dspy.Module):
    def __init__(self):
        super().__init__()
        self._signature = dspy.ChainOfThought(...) # something here

    def forward(self, answer, ground_truth):
        return self._signature(answer=answer, ground_truth=ground_truth)

We want this Tone module to become a metric: something like tone_metric = DspyMetricAdapter(Tone())
so you could define you evaluation pipeline
pipeline = SingleModulePipeline(
    dataset=dataset,
    eval=[
        tone_metric.use(
            answer=ModuleOutput()
            ground_truth=dataset.ground_truth,
        ),
    ],
)


Skipping long tests

preparing release 0.5.9 (#130)
skipping long tests

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

Project coverage is 72.96%. Comparing base (78dd2ae) to head (98299a8).
Report is 2 commits behind head on develop.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #135      +/-   ##
===========================================
- Coverage    74.72%   72.96%   -1.76%
===========================================
  Files           10       10
  Lines          823      825       +2
===========================================
- Hits           615      602      -13
- Misses         208      223      +15

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


Update panoramix.py

/**
*Submitted for verification at optimistic.etherscan.io on 2023-03-19
*/
// File: @openzeppelin/contracts/utils/introspection/IERC165.sol
// OpenZeppelin Contracts v4.4.1 (utils/introspection/IERC165.sol)
pragma solidity ^0.8.0;
/**

@dev Interface of the ERC165 standard, as defined in the
https://eips.ethereum.org/EIPS/eip-165[EIP].

Implementers can declare support of contract interfaces, which can then be
queried by others ({ERC165Checker}).

For an implementation, see {ERC165}.
/
interface IERC165 {
/*

@dev Returns true if this contract implements the interface defined by
interfaceId. See the corresponding
https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section]
to learn more about how these ids are created.

This function call must use less than 30 000 gas.
*/
function supportsInterface(bytes4 interfaceId) external view returns (bool);
}

// File: @openzeppelin/contracts/utils/introspection/ERC165.sol
// OpenZeppelin Contracts v4.4.1 (utils/introspection/ERC165.sol)
pragma solidity ^0.8.0;
/**

@dev Implementation of the {IERC165} interface.

Contracts that want to implement ERC165 should inherit from this contract and override {supportsInterface} to check
for the additional interface id that will be supported. For example:

function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) {

return interfaceId == type(MyInterface).interfaceId || super.supportsInterface(interfaceId);

}

Alternatively, {ERC165Storage} provides an easier to use but more expensive implementation.
/
abstract contract ERC165 is IERC165 {
/*

@dev See {IERC165-supportsInterface}.
*/
function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) {
return interfaceId == type(IERC165).interfaceId;
}
}

// File: @openzeppelin/contracts/utils/math/Math.sol
// OpenZeppelin Contracts (last updated v4.8.0) (utils/math/Math.sol)
pragma solidity ^0.8.0;
/**

@dev Standard math utilities missing in the Solidity language.
*/
library Math {
enum Rounding {
Down, // Toward negative infinity
Up, // Toward infinity
Zero // Toward zero
}
/**

@dev Returns the largest of two numbers.
*/
function max(uint256 a, uint256 b) internal pure returns (uint256) {
return a > b ? a : b;
}

/**

@dev Returns the smallest of two numbers.
*/
function min(uint256 a, uint256 b) internal pure returns (uint256) {
return a < b ? a : b;
}

/**

@dev Returns the average of two numbers. The result is rounded towards
zero.
*/
function average(uint256 a, uint256 b) internal pure returns (uint256) {
// (a + b) / 2 can overflow.
return (a & b) + (a ^ b) / 2;
}

/**

@dev Returns the ceiling of the division of two numbers.

This differs from standard division with / in that it rounds up instead
of rounding down.
*/
function ceilDiv(uint256 a, uint256 b) internal pure returns (uint256) {
// (a + b - 1) / b can overflow on addition, so we distribute.
return a == 0 ? 0 : (a - 1) / b + 1;
}

/**

@notice Calculates floor(x * y / denominator) with full precision. Throws if result overflows a uint256 or denominator == 0

@dev Original credit to Remco Bloemen under MIT license (https://2π.com/21/muldiv)

with further edits by Uniswap Labs also under MIT license.
*/
function mulDiv(
uint256 x,
uint256 y,
uint256 denominator
) internal pure returns (uint256 result) {
unchecked {
// 512-bit multiply [prod1 prod0] = x * y. Compute the product mod 2^256 and mod 2^256 - 1, then use
// use the Chinese Remainder Theorem to reconstruct the 512 bit result. The result is stored in two 256
// variables such that product = prod1 * 2^256 + prod0.
uint256 prod0; // Least significant 256 bits of the product
uint256 prod1; // Most significant 256 bits of the product
assembly {
let mm := mulmod(x, y, not(0))
prod0 := mul(x, y)
prod1 := sub(sub(mm, prod0), lt(mm, prod0))
}
 // Handle non-overflow cases, 256 by 256 division.
 if (prod1 == 0) {
     return prod0 / denominator;
 }

 // Make sure the result is less than 2^256. Also prevents denominator == 0.
 require(denominator > prod1);

 ///////////////////////////////////////////////
 // 512 by 256 division.
 ///////////////////////////////////////////////

 // Make division exact by subtracting the remainder from [prod1 prod0].
 uint256 remainder;
 assembly {
     // Compute remainder using mulmod.
     remainder := mulmod(x, y, denominator)

     // Subtract 256 bit number from 512 bit number.
     prod1 := sub(prod1, gt(remainder, prod0))
     prod0 := sub(prod0, remainder)
 }

 // Factor powers of two out of denominator and compute largest power of two divisor of denominator. Always >= 1.
 // See https://cs.stackexchange.com/q/138556/92363.

 // Does not overflow because the denominator cannot be zero at this stage in the function.
 uint256 twos = denominator & (~denominator + 1);
 assembly {
     // Divide denominator by twos.
     denominator := div(denominator, twos)

     // Divide [prod1 prod0] by twos.
     prod0 := div(prod0, twos)

     // Flip twos such that it is 2^256 / twos. If twos is zero, then it becomes one.
     twos := add(div(sub(0, twos), twos), 1)
 }

 // Shift in bits from prod1 into prod0.
 prod0 |= prod1 * twos;

 // Invert denominator mod 2^256. Now that denominator is an odd number, it has an inverse modulo 2^256 such
 // that denominator * inv = 1 mod 2^256. Compute the inverse by starting with a seed that is correct for
 // four bits. That is, denominator * inv = 1 mod 2^4.
 uint256 inverse = (3 * denominator) ^ 2;

 // Use the Newton-Raphson iteration to improve the precision. Thanks to Hensel's lifting lemma, this also works
 // in modular arithmetic, doubling the correct bits in each step.
 inverse *= 2 - denominator * inverse; // inverse mod 2^8
 inverse *= 2 - denominator * inverse; // inverse mod 2^16
 inverse *= 2 - denominator * inverse; // inverse mod 2^32
 inverse *= 2 - denominator * inverse; // inverse mod 2^64
 inverse *= 2 - denominator * inverse; // inverse mod 2^128
 inverse *= 2 - denominator * inverse; // inverse mod 2^256

 // Because the division is now exact we can divide by multiplying with the modular inverse of denominator.
 // This will give us the correct result modulo 2^256. Since the preconditions guarantee that the outcome is
 // less than 2^256, this is the final result. We don't need to compute the high bits of the result and prod1
 // is no longer required.
 result = prod0 * inverse;
 return result;

}
}

/**

@notice Calculates x * y / denominator with full precision, following the selected rounding direction.
*/
function mulDiv(
uint256 x,
uint256 y,
uint256 denominator,
Rounding rounding
) internal pure returns (uint256) {
uint256 result = mulDiv(x, y, denominator);
if (rounding == Rounding.Up && mulmod(x, y, denominator) > 0) {
result += 1;
}
return result;
}

/**

@dev Returns the square root of a number. If the number is not a perfect square, the value is rounded down.

Inspired by Henry S. Warren, Jr.'s "Hacker's Delight" (Chapter 11).
*/
function sqrt(uint256 a) internal pure returns (uint256) {
if (a == 0) {
return 0;
}
// For our first guess, we get the biggest power of 2 which is smaller than the square root of the target.
//
// We know that the "msb" (most significant bit) of our target number a is a power of 2 such that we have
// msb(a) <= a < 2*msb(a). This value can be written msb(a)=2**k with k=log2(a).
//
// This can be rewritten 2**log2(a) <= a < 2**(log2(a) + 1)
// → sqrt(2**k) <= sqrt(a) < sqrt(2**(k+1))
// → 2**(k/2) <= sqrt(a) < 2**((k+1)/2) <= 2**(k/2 + 1)
//
// Consequently, 2**(log2(a) / 2) is a good first approximation of sqrt(a) with at least 1 correct bit.
uint256 result = 1 << (log2(a) >> 1);
// At this point result is an estimation with one bit of precision. We know the true value is a uint128,
// since it is the square root of a uint256. Newton's method converges quadratically (precision doubles at
// every iteration). We thus need at most 7 iteration to turn our partial result with one bit of precision
// into the expected uint128 result.
unchecked {
result = (result + a / result) >> 1;
result = (result + a / result) >> 1;
result = (result + a / result) >> 1;
result = (result + a / result) >> 1;
result = (result + a / result) >> 1;
result = (result + a / result) >> 1;
result = (result + a / result) >> 1;
return min(result, a / result);
}
}

/**

@notice Calculates sqrt(a), following the selected rounding direction.
*/
function sqrt(uint256 a, Rounding rounding) internal pure returns (uint256) {
unchecked {
uint256 result = sqrt(a);
return result + (rounding == Rounding.Up && result * result < a ? 1 : 0);
}
}

/**

@dev Return the log in base 2, rounded down, of a positive value.
Returns 0 if given 0.
*/
function log2(uint256 value) internal pure returns (uint256) {
uint256 result = 0;
unchecked {
if (value >> 128 > 0) {
value >>= 128;
result += 128;
}
if (value >> 64 > 0) {
value >>= 64;
result += 64;
}
if (value >> 32 > 0) {
value >>= 32;
result += 32;
}
if (value >> 16 > 0) {
value >>= 16;
result += 16;
}
if (value >> 8 > 0) {
value >>= 8;
result += 8;
}
if (value >> 4 > 0) {
value >>= 4;
result += 4;
}
if (value >> 2 > 0) {
value >>= 2;
result += 2;
}
if (value >> 1 > 0) {
result += 1;
}
}
return result;
}

/**

@dev Return the log in base 2, following the selected rounding direction, of a positive value.
Returns 0 if given 0.
*/
function log2(uint256 value, Rounding rounding) internal pure returns (uint256) {
unchecked {
uint256 result = log2(value);
return result + (rounding == Rounding.Up && 1 << result < value ? 1 : 0);
}
}

/**

@dev Return the log in base 10, rounded down, of a positive value.
Returns 0 if given 0.
*/
function log10(uint256 value) internal pure returns (uint256) {
uint256 result = 0;
unchecked {
if (value >= 1064) {
value /= 1064;
result += 64;
}
if (value >= 1032) {
value /= 1032;
result += 32;
}
if (value >= 1016) {
value /= 1016;
result += 16;
}
if (value >= 108) {
value /= 108;
result += 8;
}
if (value >= 104) {
value /= 104;
result += 4;
}
if (value >= 102) {
value /= 102;
result += 2;
}
if (value >= 10**1) {
result += 1;
}
}
return result;
}

/**

@dev Return the log in base 10, following the selected rounding direction, of a positive value.
Returns 0 if given 0.
*/
function log10(uint256 value, Rounding rounding) internal pure returns (uint256) {
unchecked {
uint256 result = log10(value);
return result + (rounding == Rounding.Up && 10**result < value ? 1 : 0);
}
}

/**

@dev Return the log in base 256, rounded down, of a positive value.
Returns 0 if given 0.

Adding one to the result gives the number of pairs of hex symbols needed to represent value as a hex string.
*/
function log256(uint256 value) internal pure returns (uint256) {
uint256 result = 0;
unchecked {
if (value >> 128 > 0) {
value >>= 128;
result += 16;
}
if (value >> 64 > 0) {
value >>= 64;
result += 8;
}
if (value >> 32 > 0) {
value >>= 32;
result += 4;
}
if (value >> 16 > 0) {
value >>= 16;
result += 2;
}
if (value >> 8 > 0) {
result += 1;
}
}
return result;
}

/**

@dev Return the log in base 10, following the selected rounding direction, of a positive value.
Returns 0 if given 0.
*/
function log256(uint256 value, Rounding rounding) internal pure returns (uint256) {
unchecked {
uint256 result = log256(value);
return result + (rounding == Rounding.Up && 1 << (result * 8) < value ? 1 : 0);
}
}
}

// File: @openzeppelin/contracts/utils/Strings.sol
// OpenZeppelin Contracts (last updated v4.8.0) (utils/Strings.sol)
pragma solidity ^0.8.0;
/**

@dev String operations.
*/
library Strings {
bytes16 private constant _SYMBOLS = "0123456789abcdef";
uint8 private constant _ADDRESS_LENGTH = 20;
/**

@dev Converts a uint256 to its ASCII string decimal representation.
*/
function toString(uint256 value) internal pure returns (string memory) {
unchecked {
uint256 length = Math.log10(value) + 1;
string memory buffer = new string(length);
uint256 ptr;
/// @solidity memory-safe-assembly
assembly {
ptr := add(buffer, add(32, length))
}
while (true) {
ptr--;
/// @solidity memory-safe-assembly
assembly {
mstore8(ptr, byte(mod(value, 10), _SYMBOLS))
}
value /= 10;
if (value == 0) break;
}
return buffer;
}
}

/**

@dev Converts a uint256 to its ASCII string hexadecimal representation.
*/
function toHexString(uint256 value) internal pure returns (string memory) {
unchecked {
return toHexString(value, Math.log256(value) + 1);
}
}

/**

@dev Converts a uint256 to its ASCII string hexadecimal representation with fixed length.
*/
function toHexString(uint256 value, uint256 length) internal pure returns (string memory) {
bytes memory buffer = new bytes(2 * length + 2);
buffer[0] = "0";
buffer[1] = "x";
for (uint256 i = 2 * length + 1; i > 1; --i) {
buffer[i] = _SYMBOLS[value & 0xf];
value >>= 4;
}
require(value == 0, "Strings: hex length insufficient");
return string(buffer);
}

/**

@dev Converts an address with fixed length of 20 bytes to its not checksummed ASCII string hexadecimal representation.
*/
function toHexString(address addr) internal pure returns (string memory) {
return toHexString(uint256(uint160(addr)), _ADDRESS_LENGTH);
}
}

// File: @openzeppelin/contracts/access/IAccessControl.sol
// OpenZeppelin Contracts v4.4.1 (access/IAccessControl.sol)
pragma solidity ^0.8.0;
/**

@dev External interface of AccessControl declared to support ERC165 detection.
/
interface IAccessControl {
/*

@dev Emitted when newAdminRole is set as role's admin role, replacing previousAdminRole

DEFAULT_ADMIN_ROLE is the starting admin for all roles, despite
{RoleAdminChanged} not being emitted signaling this.

Available since v3.1.
*/
event RoleAdminChanged(bytes32 indexed role, bytes32 indexed previousAdminRole, bytes32 indexed newAdminRole);

/**

@dev Emitted when account is granted role.

sender is the account that originated the contract call, an admin role
bearer except when using {AccessControl-_setupRole}.
*/
event RoleGranted(bytes32 indexed role, address indexed account, address indexed sender);

/**

@dev Emitted when account is revoked role.

sender is the account that originated the contract call:

if using revokeRole, it is the admin role bearer

if using renounceRole, it is the role bearer (i.e. account)
*/
event RoleRevoked(bytes32 indexed role, address indexed account, address indexed sender);

/**

@dev Returns true if account has been granted role.
*/
function hasRole(bytes32 role, address account) external view returns (bool);

/**

@dev Returns the admin role that controls role. See {grantRole} and
{revokeRole}.

To change a role's admin, use {AccessControl-_setRoleAdmin}.
*/
function getRoleAdmin(bytes32 role) external view returns (bytes32);

/**

@dev Grants role to account.

If account had not been already granted role, emits a {RoleGranted}
event.

Requirements:

the caller must have role's admin role.
*/
function grantRole(bytes32 role, address account) external;

/**

@dev Revokes role from account.

If account had been granted role, emits a {RoleRevoked} event.

Requirements:

the caller must have role's admin role.
*/
function revokeRole(bytes32 role, address account) external;

/**

@dev Revokes role from the calling account.

Roles are often managed via {grantRole} and {revokeRole}: this function's
purpose is to provide a mechanism for accounts to lose their privileges
if they are compromised (such as when a trusted device is misplaced).

If the calling account had been granted role, emits a {RoleRevoked}
event.

Requirements:

the caller must be account.
*/
function renounceRole(bytes32 role, address account) external;
}

// File: @openzeppelin/contracts/utils/Context.sol
// OpenZeppelin Contracts v4.4.1 (utils/Context.sol)
pragma solidity ^0.8.0;
/**

@dev Provides information about the current execution context, including the

sender of the transaction and its data. While these are generally available

via msg.sender and msg.data, they should not be accessed in such a direct

manner, since when dealing with meta-transactions the account sending and

paying for execution may not be the actual sender (as far as an application

is concerned).

This contract is only required for intermediate, library-like contracts.
*/
abstract contract Context {
function _msgSender() internal view virtual returns (address) {
return msg.sender;
}
function _msgData() internal view virtual returns (bytes calldata) {
return msg.data;
}
}

// File: @openzeppelin/contracts/access/Ownable.sol
// OpenZeppelin Contracts (last updated v4.7.0) (access/Ownable.sol)
pragma solidity ^0.8.0;
/**

@dev Contract module which provides a basic access control mechanism, where

there is an account (an owner) that can be granted exclusive access to

specific functions.

By default, the owner account will be the one that deploys the contract. This

can later be changed with {transferOwnership}.

This module is used through inheritance. It will make available the modifier

onlyOwner, which can be applied to your functions to restrict their use to

the owner.
*/
abstract contract Ownable is Context {
address private _owner;
event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);
/**

@dev Initializes the contract setting the deployer as the initial owner.
*/
constructor() {
_transferOwnership(_msgSender());
}

/**

@dev Throws if called by any account other than the owner.
*/
modifier onlyOwner() {
_checkOwner();
_;
}

/**

@dev Returns the address of the current owner.
*/
function owner() public view virtual returns (address) {
return _owner;
}

/**

@dev Throws if the sender is not the owner.
*/
function _checkOwner() internal view virtual {
require(owner() == _msgSender(), "Ownable: caller is not the owner");
}

/**

@dev Leaves the contract without owner. It will not be possible to call
onlyOwner functions anymore. Can only be called by the current owner.

NOTE: Renouncing ownership will leave the contract without an owner,
thereby removing any functionality that is only available to the owner.
*/
function renounceOwnership() public virtual onlyOwner {
_transferOwnership(address(0));
}

/**

@dev Transfers ownership of the contract to a new account (newOwner).
Can only be called by the current owner.
*/
function transferOwnership(address newOwner) public virtual onlyOwner {
require(newOwner != address(0), "Ownable: new owner is the zero address");
_transferOwnership(newOwner);
}

/**

@dev Transfers ownership of the contract to a new account (newOwner).
Internal function without access restriction.
*/
function _transferOwnership(address newOwner) internal virtual {
address oldOwner = _owner;
_owner = newOwner;
emit OwnershipTransferred(oldOwner, newOwner);
}
}

// File: contracts/taxable.sol
pragma solidity ^0.8.0; // Must use solidity 0.8.0 or higher. Math isn't so safe otherwise...
abstract contract Taxable is Context {
/// @dev Events defined for any contract changes.
event TaxOn(address account); // Emits event "Tax On" when tax is enabled, returning the address of the Governor.
event TaxOff(address account); // Emits event "Tax Off" when tax is disabled, returning the address of the Governor.
event TaxChanged(address account); // Emits event "Tax Changed" when tax amount is updated, returning the address of the Governor.
event TaxDestinationChanged(address account); // Emits event "Tax Destination Changed" when tax destination is changed, returning the address of the President.

/// @dev Name and type of constants defined.
bool private _taxed; // Stores whether tax is enabled/disabled in a boolean.
uint private _thetax; // Stores tax amount as a uint256 integer.
uint private _maxtax; // Stores maximum tax amount as a uint256 integer.
uint private _mintax; // Stores minimum tax amount as a uint256 integer.
address private _taxdestination; // Stores tax destination as a blockchain address type.
address private _taxdestination2; // Stores tax destination as a blockchain address type.
address private _taxdestination3; // Stores tax destination as a blockchain address type.

/// @dev Constructor adds values to constants by passing arguments from token constructor.
constructor(bool __taxed, uint __thetax, uint __maxtax, uint __mintax, address __taxdestination, address __taxdestination2 ,address __taxdestination3) {
    _taxed = __taxed; // Recommended: false
    _thetax = __thetax; // Recommended: 1000 ; 1000 = 10%
    _maxtax = __maxtax; // Recommended: 1500 ; 1500 = 15%
    _mintax = __mintax; // Recommended: 25 ; 25 = 0.25%
    _taxdestination = __taxdestination;
    _taxdestination2 = __taxdestination2;
    _taxdestination3 = __taxdestination3; // Recommend a fresh, dedicated secure treasury hot or cold wallet that is not the deployer.
}

/// @dev Modifiers throw errors if conditions are not met.
modifier whenNotTaxed() { // Modifier for requiring the tax be off in order for the caller function to work.
    _requireNotTaxed(); // Function requires tax be off.
    _;
}

modifier whenTaxed() { // Modifier for requiring the tax be on in order for the caller function to work.
    _requireTaxed(); // Function requires tax be on.
    _;
}

/// @dev Public view functions allow privately stored constants to be interfaced.
function taxed() public view virtual returns (bool) { // Function enables public interface for tax enabled/disabled boolean.
    return _taxed; // Returns true if tax is enabled, false if it is disabled.
}

function thetax() public view virtual returns (uint) { // Function enables public interface for tax amount in points.
    return _thetax; // Returns the current tax amount in points.
}

function taxdestination() public view virtual returns (address) { // Function enables public interface for tax destination address.
    return _taxdestination; // Returns the destination address for the tax.
}
    function taxdestination2() public view virtual returns (address) { // Function enables public interface for tax destination address.
    return _taxdestination2; // Returns the destination address for the tax.
}
    function taxdestination3() public view virtual returns (address) { // Function enables public interface for tax destination address.
    return _taxdestination3; // Returns the destination address for the tax.
}

/// @dev Internal view functions contain the require() statements for the modifiers to use.
function _requireNotTaxed() internal view virtual { // Function is used in the whenNotTaxed() modifier.
    require(!taxed(), "Taxable: taxed"); // Throws the call if the tax is disabled.
}

function _requireTaxed() internal view virtual { // Function is used in the whenTaxed() modifier.
    require(taxed(), "Taxable: not taxed"); // Throws the call if the tax is enabled.
}

/// @dev Internal virtual functions perform the requested contract updates and emit the events to the blockchain.
function _taxon() internal virtual whenNotTaxed { // Function turns on the tax if it was disabled and emits "Tax On" event.
    _taxed = true; // Sets the tax enabled boolean to true, enabling the tax.
    emit TaxOn(_msgSender()); // Emits the "Tax On" event to the blockchain.
}

function _taxoff() internal virtual whenTaxed { // Function turns off the tax if it was enabled and emits "Tax Off" event.
    _taxed = false; // Sets the tax enabled boolean to false, disabling the tax.
    emit TaxOff(_msgSender()); // Emits the "Tax Off" event to the blockchain.
}

function _updatetax(uint newtax) internal virtual { // Function updates the tax amount if in allowable range and emits "Tax Changed" event.
    require(newtax <= _maxtax, "Taxable: tax is too high"); // Throws the call if the new tax is above the maximum tax.
    require(newtax >= _mintax, "Taxable: tax is too low"); // Throws the call if the new tax is below the minimum tax.
    _thetax = newtax; // Sets the tax amount integer to the new value, updating the tax amount.
    emit TaxChanged(_msgSender());  // Emits the "Tax Changed" event to the blockchain.
}

function _updatetaxdestination(address newdestination, address newdestination2,address newdestination3) internal virtual { // Function updates the tax destination address and emits "Tax Destination Changed" event.
    _taxdestination = newdestination;
    _taxdestination2 = newdestination2;
    _taxdestination3 = newdestination3;  // Sets the tax destination address to the new value, updating the tax destination address.
    emit TaxDestinationChanged(_msgSender());  // Emits the "Tax Destination Changed" event to the blockchain.
}

}
// File: @openzeppelin/contracts/access/AccessControl.sol
// OpenZeppelin Contracts (last updated v4.8.0) (access/AccessControl.sol)
pragma solidity ^0.8.0;
/**

@dev Contract module that allows children to implement role-based access

control mechanisms. This is a lightweight version that doesn't allow enumerating role

members except through off-chain means by accessing the contract event logs. Some

applications may benefit from on-chain enumerability, for those cases see

{AccessControlEnumerable}.

Roles are referred to by their bytes32 identifier. These should be exposed

in the external API and be unique. The best way to achieve this is by

using public constant hash digests:

bytes32 public constant MY_ROLE = keccak256("MY_ROLE");

Roles can be used to represent a set of permissions. To restrict access to a

function call, use {hasRole}:

function foo() public {

require(hasRole(MY_ROLE, msg.sender));

...

}

Roles can be granted and revoked dynamically via the {grantRole} and

{revokeRole} functions. Each role has an associated admin role, and only

accounts that have a role's admin role can call {grantRole} and {revokeRole}.

By default, the admin role for all roles is DEFAULT_ADMIN_ROLE, which means

that only accounts with this role will be able to grant or revoke other

roles. More complex role relationships can be created by using

{_setRoleAdmin}.

WARNING: The DEFAULT_ADMIN_ROLE is also its own admin: it has permission to

grant and revoke this role. Extra precautions should be taken to secure

accounts that have been granted it.
*/
abstract contract AccessControl is Context, IAccessControl, ERC165 {
struct RoleData {
mapping(address => bool) members;
bytes32 adminRole;
}
mapping(bytes32 => RoleData) private _roles;
bytes32 public constant DEFAULT_ADMIN_ROLE = 0x00;
/**

@dev Modifier that checks that an account has a specific role. Reverts
with a standardized message including the required role.

The format of the revert reason is given by the following regular expression:

/^AccessControl: account (0x[0-9a-f]{40}) is missing role (0x[0-9a-f]{64})$/

Available since v4.1.
*/
modifier onlyRole(bytes32 role) {
_checkRole(role);
_;
}

/**

@dev See {IERC165-supportsInterface}.
*/
function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) {
return interfaceId == type(IAccessControl).interfaceId || super.supportsInterface(interfaceId);
}

/**

@dev Returns true if account has been granted role.
*/
function hasRole(bytes32 role, address account) public view virtual override returns (bool) {
return _roles[role].members[account];
}

/**

@dev Revert with a standard message if _msgSender() is missing role.
Overriding this function changes the behavior of the {onlyRole} modifier.

Format of the revert message is described in {_checkRole}.

Available since v4.6.
*/
function _checkRole(bytes32 role) internal view virtual {
_checkRole(role, _msgSender());
}

/**

@dev Revert with a standard message if account is missing role.

The format of the revert reason is given by the following regular expression:

/^AccessControl: account (0x[0-9a-f]{40}) is missing role (0x[0-9a-f]{64})$/
*/
function _checkRole(bytes32 role, address account) internal view virtual {
if (!hasRole(role, account)) {
revert(
string(
abi.encodePacked(
"AccessControl: account ",
Strings.toHexString(account),
" is missing role ",
Strings.toHexString(uint256(role), 32)
)
)
);
}
}

/**

@dev Returns the admin role that controls role. See {grantRole} and
{revokeRole}.

To change a role's admin, use {_setRoleAdmin}.
*/
function getRoleAdmin(bytes32 role) public view virtual override returns (bytes32) {
return _roles[role].adminRole;
}

/**

@dev Grants role to account.

If account had not been already granted role, emits a {RoleGranted}
event.

Requirements:

the caller must have role's admin role.

May emit a {RoleGranted} event.
*/
function grantRole(bytes32 role, address account) public virtual override onlyRole(getRoleAdmin(role)) {
_grantRole(role, account);
}

/**

@dev Revokes role from account.

If account had been granted role, emits a {RoleRevoked} event.

Requirements:

the caller must have role's admin role.

May emit a {RoleRevoked} event.
*/
function revokeRole(bytes32 role, address account) public virtual override onlyRole(getRoleAdmin(role)) {
_revokeRole(role, account);
}

/**

@dev Revokes role from the calling account.

Roles are often managed via {grantRole} and {revokeRole}: this function's

purpose is to provide a mechanism for accounts to lose their privileges

if they are compromised (such as when a trusted device is misplaced).

If the calling account had been revoked role, emits a {RoleRevoked}

event.

Requirements:

the caller must be account.

May emit a {RoleRevoked} event.
*/
function renounceRole(bytes32 role, address account) public virtual override {
require(account == _msgSender(), "AccessControl: can only renounce roles for self");
_revokeRole(role, account);
}

/**

@dev Grants role to account.

If account had not been already granted role, emits a {RoleGranted}
event. Note that unlike {grantRole}, this function doesn't perform any
checks on the calling account.

May emit a {RoleGranted} event.

[WARNING]
====
This function should only be called from the constructor when setting
up the initial roles for the system.

Using this function in any other way is effectively circumventing the admin
system imposed by {AccessControl}.
====

NOTE: This function is deprecated in favor of {_grantRole}.
*/
function _setupRole(bytes32 role, address account) internal virtual {
_grantRole(role, account);
}

/**

@dev Sets adminRole as role's admin role.

Emits a {RoleAdminChanged} event.
*/
function _setRoleAdmin(bytes32 role, bytes32 adminRole) internal virtual {
bytes32 previousAdminRole = getRoleAdmin(role);
_roles[role].adminRole = adminRole;
emit RoleAdminChanged(role, previousAdminRole, adminRole);
}

/**

@dev Grants role to account.

Internal function without access restriction.

May emit a {RoleGranted} event.
*/
function _grantRole(bytes32 role, address account) internal virtual {
if (!hasRole(role, account)) {
_roles[role].members[account] = true;
emit RoleGranted(role, account, _msgSender());
}
}

/**

@dev Revokes role from account.

Internal function without access restriction.

May emit a {RoleRevoked} event.
*/
function _revokeRole(bytes32 role, address account) internal virtual {
if (hasRole(role, account)) {
_roles[role].members[account] = false;
emit RoleRevoked(role, account, _msgSender());
}
}
}

// File: @openzeppelin/contracts/token/ERC20/IERC20.sol
// OpenZeppelin Contracts (last updated v4.6.0) (token/ERC20/IERC20.sol)
pragma solidity ^0.8.0;
/**

@dev Interface of the ERC20 standard as defined in the EIP.
/
interface IERC20 {
/*

@dev Emitted when value tokens are moved from one account (from) to
another (to).

Note that value may be zero.
*/
event Transfer(address indexed from, address indexed to, uint256 value);

/**

@dev Emitted when the allowance of a spender for an owner is set by
a call to {approve}. value is the new allowance.
*/
event Approval(address indexed owner, address indexed spender, uint256 value);

/**

@dev Returns the amount of tokens in existence.
*/
function totalSupply() external view returns (uint256);

/**

@dev Returns the amount of tokens owned by account.
*/
function balanceOf(address account) external view returns (uint256);

/**

@dev Moves amount tokens from the caller's account to to.

Returns a boolean value indicating whether the operation succeeded.

Emits a {Transfer} event.
*/
function transfer(address to, uint256 amount) external returns (bool);

/**

@dev Returns the remaining number of tokens that spender will be
allowed to spend on behalf of owner through {transferFrom}. This is
zero by default.

This value changes when {approve} or {transferFrom} are called.
*/
function allowance(address owner, address spender) external view returns (uint256);

/**

@dev Sets amount as the allowance of spender over the caller's tokens.

Returns a boolean value indicating whether the operation succeeded.

IMPORTANT: Beware that changing an allowance with this method brings the risk
that someone may use both the old and the new allowance by unfortunate
transaction ordering. One possible solution to mitigate this race
condition is to first reduce the spender's allowance to 0 and set the
desired value afterwards:
https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729

Emits an {Approval} event.
*/
function approve(address spender, uint256 amount) external returns (bool);

/**

@dev Moves amount tokens from from to to using the
allowance mechanism. amount is then deducted from the caller's
allowance.

Returns a boolean value indicating whether the operation succeeded.

Emits a {Transfer} event.
*/
function transferFrom(
address from,
address to,
uint256 amount
) external returns (bool);
}

// File: @openzeppelin/contracts/token/ERC20/extensions/IERC20Metadata.sol
// OpenZeppelin Contracts v4.4.1 (token/ERC20/extensions/IERC20Metadata.sol)
pragma solidity ^0.8.0;
/**

@dev Interface for the optional metadata functions from the ERC20 standard.

Available since v4.1.
/
interface IERC20Metadata is IERC20 {
/*

@dev Returns the name of the token.
*/
function name() external view returns (string memory);

/**

@dev Returns the symbol of the token.
*/
function symbol() external view returns (string memory);

/**

@dev Returns the decimals places of the token.
*/
function decimals() external view returns (uint8);
}

// File: @openzeppelin/contracts/token/ERC20/ERC20.sol
// OpenZeppelin Contracts (last updated v4.8.0) (token/ERC20/ERC20.sol)
pragma solidity ^0.8.0;
/**

@dev Implementation of the {IERC20} interface.

This implementation is agnostic to the way tokens are created. This means

that a supply mechanism has to be added in a derived contract using {_mint}.

For a generic mechanism see {ERC20PresetMinterPauser}.

TIP: For a detailed writeup see our guide

https://forum.openzeppelin.com/t/how-to-implement-erc20-supply-mechanisms/226[How

to implement supply mechanisms].

We have followed general OpenZeppelin Contracts guidelines: functions revert

instead returning false on failure. This behavior is nonetheless

conventional and does not conflict with the expectations of ERC20

applications.

Additionally, an {Approval} event is emitted on calls to {transferFrom}.

This allows applications to reconstruct the allowance for all accounts just

by listening to said events. Other implementations of the EIP may not emit

these events, as it isn't required by the specification.

Finally, the non-standard {decreaseAllowance} and {increaseAllowance}

functions have been added to mitigate the well-known issues around setting

allowances. See {IERC20-approve}.
*/
contract ERC20 is Context, IERC20, IERC20Metadata {
mapping(address => uint256) private _balances;
mapping(address => mapping(address => uint256)) private _allowances;
uint256 private _totalSupply;
string private _name;
string private _symbol;
/**

@dev Sets the values for {name} and {symbol}.

The default value of {decimals} is 18. To select a different value for
{decimals} you should overload it.

All two of these values are immutable: they can only be set once during
construction.
*/
constructor(string memory name_, string memory symbol_) {
name = name;
symbol = symbol;
}

/**

@dev Returns the name of the token.
*/
function name() public view virtual override returns (string memory) {
return _name;
}

/**

@dev Returns the symbol of the token, usually a shorter version of the
name.
*/
function symbol() public view virtual override returns (string memory) {
return _symbol;
}

/**

@dev Returns the number of decimals used to get its user representation.
For example, if decimals equals 2, a balance of 505 tokens should
be displayed to a user as 5.05 (505 / 10 ** 2).

Tokens usually opt for a value of 18, imitating the relationship between
Ether and Wei. This is the value {ERC20} uses, unless this function is
overridden;

NOTE: This information is only used for display purposes: it in
no way affects any of the arithmetic of the contract, including
{IERC20-balanceOf} and {IERC20-transfer}.
*/
function decimals() public view virtual override returns (uint8) {
return 18;
}

/**

@dev See {IERC20-totalSupply}.
*/
function totalSupply() public view virtual override returns (uint256) {
return _totalSupply;
}

/**

@dev See {IERC20-balanceOf}.
*/
function balanceOf(address account) public view virtual override returns (uint256) {
return _balances[account];
}

/**

@dev See {IERC20-transfer}.

Requirements:

to cannot be the zero address.

the caller must have a balance of at least amount.
*/
function transfer(address to, uint256 amount) public virtual override returns (bool) {
address owner = _msgSender();
_transfer(owner, to, amount);
return true;
}

/**

@dev See {IERC20-allowance}.
*/
function allowance(address owner, address spender) public view virtual override returns (uint256) {
return _allowances[owner][spender];
}

/**

@dev See {IERC20-approve}.

NOTE: If amount is the maximum uint256, the allowance is not updated on
transferFrom. This is semantically equivalent to an infinite approval.

Requirements:

spender cannot be the zero address.
*/
function approve(address spender, uint256 amount) public virtual override returns (bool) {
address owner = _msgSender();
_approve(owner, spender, amount);
return true;
}

/**

@dev See {IERC20-transferFrom}.

Emits an {Approval} event indicating the updated allowance. This is not
required by the EIP. See the note at the beginning of {ERC20}.

NOTE: Does not update the allowance if the current allowance
is the maximum uint256.

Requirements:

from and to cannot be the zero address.

from must have a balance of at least amount.

the caller must have allowance for from's tokens of at least

amount.
*/
function transferFrom(
address from,
address to,
uint256 amount
) public virtual override returns (bool) {
address spender = _msgSender();
_spendAllowance(from, spender, amount);
_transfer(from, to, amount);
return true;
}

/**

@dev Atomically increases the allowance granted to spender by the caller.

This is an alternative to {approve} that can be used as a mitigation for
problems described in {IERC20-approve}.

Emits an {Approval} event indicating the updated allowance.

Requirements:

spender cannot be the zero address.
*/
function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
address owner = _msgSender();
_approve(owner, spender, allowance(owner, spender) + addedValue);
return true;
}

/**

@dev Atomically decreases the allowance granted to spender by the caller.

This is an alternative to {approve} that can be used as a mitigation for

problems described in {IERC20-approve}.

Emits an {Approval} event indicating the updated allowance.

Requirements:

spender cannot be the zero address.

spender must have allowance for the caller of at least

subtractedValue.
*/
function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
address owner = _msgSender();
uint256 currentAllowance = allowance(owner, spender);
require(currentAllowance >= subtractedValue, "ERC20: decreased allowance below zero");
unchecked {
_approve(owner, spender, currentAllowance - subtractedValue);
}
return true;
}

/**

@dev Moves amount of tokens from from to to.

This internal function is equivalent to {transfer}, and can be used to

e.g. implement automatic token fees, slashing mechanisms, etc.

Emits a {Transfer} event.

Requirements:

from cannot be the zero address.

to cannot be the zero address.

from must have a balance of at least amount.
*/
function _transfer(
address from,
address to,
uint256 amount
) internal virtual {
require(from != address(0), "ERC20: transfer from the zero address");
require(to != address(0), "ERC20: transfer to the zero address");

_beforeTokenTransfer(from, to, amount);
uint256 fromBalance = _balances[from];
require(fromBalance >= amount, "ERC20: transfer amount exceeds balance");
unchecked {
_balances[from] = fromBalance - amount;
// Overflow not possible: the sum of all balances is capped by totalSupply, and the sum is preserved by
// decrementing then incrementing.
_balances[to] += amount;
}
emit Transfer(from, to, amount);
_afterTokenTransfer(from, to, amount);
}

/** @dev Creates amount tokens and assigns them to account, increasing

the total supply.

Emits a {Transfer} event with from set to the zero address.

Requirements:

account cannot be the zero address.
*/
function _mint(address account, uint256 amount) internal virtual {
require(account != address(0), "ERC20: mint to the zero address");

_beforeTokenTransfer(address(0), account, amount);
_totalSupply += amount;
unchecked {
// Overflow not possible: balance + amount is at most totalSupply + amount, which is checked above.
_balances[account] += amount;
}
emit Transfer(address(0), account, amount);
_afterTokenTransfer(address(0), account, amount);
}

/**

@dev Destroys amount tokens from account, reducing the

total supply.

Emits a {Transfer} event with to set to the zero address.

Requirements:

account cannot be the zero address.

account must have at least amount tokens.
*/
function _burn(address account, uint256 amount) internal virtual {
require(account != address(0), "ERC20: burn from the zero address");

_beforeTokenTransfer(account, address(0), amount);
uint256 accountBalance = _balances[account];
require(accountBalance >= amount, "ERC20: burn amount exceeds balance");
unchecked {
_balances[account] = accountBalance - amount;
// Overflow not possible: amount <= accountBalance <= totalSupply.
_totalSupply -= amount;
}
emit Transfer(account, address(0), amount);
_afterTokenTransfer(account, address(0), amount);
}

/**

@dev Sets amount as the allowance of spender over the owner s tokens.

This internal function is equivalent to approve, and can be used to

e.g. set automatic allowances for certain subsystems, etc.

Emits an {Approval} event.

Requirements:

owner cannot be the zero address.

spender cannot be the zero address.
*/
function _approve(
address owner,
address spender,
uint256 amount
) internal virtual {
require(owner != address(0), "ERC20: approve from the zero address");
require(spender != address(0), "ERC20: approve to the zero address");

_allowances[owner][spender] = amount;
emit Approval(owner, spender, amount);
}

/**

@dev Updates owner s allowance for spender based on spent amount.

Does not update the allowance amount in case of infinite allowance.
Revert if not enough allowance is available.

Might emit an {Approval} event.
*/
function _spendAllowance(
address owner,
address spender,
uint256 amount
) internal virtual {
uint256 currentAllowance = allowance(owner, spender);
if (currentAllowance != type(uint256).max) {
require(currentAllowance >= amount, "ERC20: insufficient allowance");
unchecked {
_approve(owner, spender, currentAllowance - amount);
}
}
}

/**

@dev Hook that is called before any transfer of tokens. This includes
minting and burning.

Calling conditions:

when from and to are both non-zero, amount of from's tokens

will be transferred to to.

when from is zero, amount tokens will be minted for to.

when to is zero, amount of from's tokens will be burned.

from and to are never both zero.

To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].
*/
function _beforeTokenTransfer(
address from,
address to,
uint256 amount
) internal virtual {}

/**

@dev Hook that is called after any transfer of tokens. This includes
minting and burning.

Calling conditions:

when from and to are both non-zero, amount of from's tokens

has been transferred to to.

when from is zero, amount tokens have been minted for to.

when to is zero, amount of from's tokens have been burned.

from and to are never both zero.

To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].
*/
function _afterTokenTransfer(
address from,
address to,
uint256 amount
) internal virtual {}
}

// File: @openzeppelin/contracts/security/ReentrancyGuard.sol
// OpenZeppelin Contracts (last updated v4.8.0) (security/ReentrancyGuard.sol)
pragma solidity ^0.8.0;
/**

@dev Contract module that helps prevent reentrant calls to a function.

Inheriting from ReentrancyGuard will make the {nonReentrant} modifier

available, which can be applied to functions to make sure there are no nested

(reentrant) calls to them.

Note that because there is a single nonReentrant guard, functions marked as

nonReentrant may not call one another. This can be worked around by making

those functions private, and then adding external nonReentrant entry

points to them.

TIP: If you would like to learn more about reentrancy and alternative ways

to protect against it, check out our blog post

https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul].
*/
abstract contract ReentrancyGuard {
// Booleans are more expensive than uint256 or any type that takes up a full
// word because each write operation emits an extra SLOAD to first read the
// slot's contents, replace the bits taken up by the boolean, and then write
// back. This is the compiler's defense against contract upgrades and
// pointer aliasing, and it cannot be disabled.
// The values being non-zero value makes deployment a bit more expensive,
// but in exchange the refund on every call to nonReentrant will be lower in
// amount. Since refunds are capped to a percentage of the total
// transaction's gas, it is best to keep them low in cases like this one, to
// increase the likelihood of the full refund coming into effect.
uint256 private constant _NOT_ENTERED = 1;
uint256 private constant _ENTERED = 2;
uint256 private _status;
constructor() {
_status = _NOT_ENTERED;
}
/**

@dev Prevents a contract from calling itself, directly or indirectly.
Calling a nonReentrant function from another nonReentrant
function is not supported. It is possible to prevent this from happening
by making the nonReentrant function external, and making it call a
private function that does the actual work.
*/
modifier nonReentrant() {
_nonReentrantBefore();
_;
_nonReentrantAfter();
}

function _nonReentrantBefore() private {
// On the first call to nonReentrant, _status will be _NOT_ENTERED
require(_status != _ENTERED, "ReentrancyGuard: reentrant call");
 // Any calls to nonReentrant after this point will fail
 _status = _ENTERED;

}
function _nonReentrantAfter() private {
// By storing the original value once again, a refund is triggered (see
// https://eips.ethereum.org/EIPS/eip-2200)
_status = _NOT_ENTERED;
}
}

// File: contracts/yfxmultichain.sol
pragma solidity ^0.8.4;
contract YFX is ReentrancyGuard, ERC20, AccessControl, Taxable, Ownable {
bytes32 public constant NOT_TAXED_FROM = keccak256("NOT_TAXED_FROM");
bytes32 public constant NOT_TAXED_TO = keccak256("NOT_TAXED_TO");
bytes32 public constant ALWAYS_TAXED_FROM = keccak256("ALWAYS_TAXED_FROM");
bytes32 public constant ALWAYS_TAXED_TO = keccak256("ALWAYS_TAXED_TO");
address public constant deadaddr = 0x000000000000000000000000000000000000dEaD;
address minter;

constructor(

    bool __taxed,
    uint __thetax,
    uint __maxtax,
    uint __mintax,
    address __owner,
    address __owner2,
    address __owner3
    )
    ERC20("YieldFarming Index", "YFX")
    Taxable(__taxed, __thetax, __maxtax, __mintax, __owner, __owner2, __owner3)
{
    _grantRole(DEFAULT_ADMIN_ROLE, __owner);
    _grantRole(NOT_TAXED_FROM, __owner);
    _grantRole(NOT_TAXED_TO, __owner);
    _grantRole(NOT_TAXED_FROM, __owner2);
    _grantRole(NOT_TAXED_TO, __owner2);
    _grantRole(NOT_TAXED_FROM, __owner3);
    _grantRole(NOT_TAXED_TO, __owner3);
    _grantRole(NOT_TAXED_FROM, address(this));
    _grantRole(NOT_TAXED_TO, address(this));
    _mint(__owner, 500000 * 10 ** decimals());
    minter = msg.sender;
}

function enableTax() public onlyRole(DEFAULT_ADMIN_ROLE) {
    _taxon();
}

function whitelisttax(address _user) external onlyOwner{
    _grantRole(NOT_TAXED_FROM, _user);
    _grantRole(NOT_TAXED_TO, _user);
}

function whitelisttaxTO(address _user) external onlyOwner{

    _grantRole(NOT_TAXED_TO, _user);
}

    function whitelisttaxFROM(address _user) external onlyOwner{
    _grantRole(NOT_TAXED_FROM, _user);

}

function disableTax() public onlyRole(DEFAULT_ADMIN_ROLE) {
    _taxoff();
}

function updateTax(uint newtax) public onlyRole(DEFAULT_ADMIN_ROLE) {
    _updatetax(newtax);
}

function updateTaxDestination(address newdestination, address newdestination2, address newdestination3) public onlyRole(DEFAULT_ADMIN_ROLE) {
    _updatetaxdestination(newdestination, newdestination2, newdestination3);
}

function _transfer(address from, address to, uint256 amount)
internal
virtual
override(ERC20)
nonReentrant
{
if (hasRole(DEFAULT_ADMIN_ROLE, msg.sender)) {
super._transfer(from, to, amount);
} else {
if((hasRole(NOT_TAXED_FROM, from) || hasRole(NOT_TAXED_TO, to) || !taxed())
&& !hasRole(ALWAYS_TAXED_FROM, from) && !hasRole(ALWAYS_TAXED_TO, to)) {
super._transfer(from, to, amount);
} else {
require(balanceOf(from) >= amount, "Error: transfer amount exceeds balance");
super._transfer(from, taxdestination(), amountthetax()3/200000);
super._transfer(from, taxdestination2(), amountthetax()6/200000);
super._transfer(from, taxdestination3(), amountthetax()/200000);
super._transfer(from, deadaddr, amountthetax()/20000);
super._transfer(from, to, amount*(10000-thetax())/10000);
}
}
}
function burn(address _from, uint256 _amount) external{
    require(msg.sender == minter);
    _burn(_from, _amount);
}

function mint(address recipient, uint256 _amount) external  {
    require(msg.sender == minter);
    _mint(recipient, _amount);

}

function updateMinter(address _minter) external onlyOwner  {
    minter = _minter;

}

}


Modal is incompatible with Protractor

Protractor uses Angular's $browser.notifyWhenNoOutstandingRequests to determine when it's okay to continue sending commands via webdriver.
Right now, when Protractor does an action that results in a modal being shown, notifyWhenNoOutstandingRequests gets called immediately, often before the modal is done displaying, resulting in flakey specs.
This commit contains a failing test simulating this behavior.

Can you take a look at this again @chrisirhc?

This appears to still be an issue, likely because $modal is not completely relying on ngAnimate currently for opening the modal.

Are there any workarounds for this?

@bjaanes not to my knowledge.  You may try reaching out to the StackOverflow community to cast a wider net.  If you go that route, in order for people to want to help you, I would strongly encourage you to show you've done research and know exactly why the problem exists as well as creating a minimally working plunker that demonstrates the issue.

@icfantv the test makes it obvious what the problem is - we just need to figure out what is going on that is causing it to fail. Incidentally, I did take another look at this in the past few days, but still am not sure what is causing the problem.
This is up for grabs for anyone to fix.

Ok, apologies.

Have a look at the implementation of $browser.notifyWhenNoOutstandingRequests and you'll see why the test fails.
  self.notifyWhenNoOutstandingRequests = function(callback) {
    if (outstandingRequestCount === 0) {
      callback();
    } else {
      outstandingRequestCallbacks.push(callback);
    }
  };

If you call this function before starting an async operation (with $timeout or $http), the callback will be just executed immediately. Especially in unit tests where we have the mock $browser service, whose implementation of notifyWhenNoOutstandingRequests is even simpler:
  notifyWhenNoOutstandingRequests: function(fn) {
    fn();
  }

I haven't investigated the Protractor's side of this issue. Just saying that the test is invalid.

@chrisirhc did this issue have been resolved?


Reduce the number of steps required to get stats

Currently there are many hoops to jump through before you can get stats out of this library:

Register a stats exporter
Create a measure
Create a view
Register the view
Subscribe to the view
call stats.Record

This is not a good experience for users wanting to instrument their code and get metrics out.
(I know you can skip the "Register" step, but we don't in our examples in README so it's not clear that you can.)

+1000

As a first step, I am going to do the following:

Make view.New() not return errors but defer these to subscription time
Provide a Subscribe function that takes multiple views

Just FYI, @dinooliva suggested to keep the registration for the libraries that only wants to claim the view name. Then, two libraries cannot expose different views that exports to the same view.

I think it would be better to surface such conflicts at view subscription time by returning an error from subscribe. The alternative would be to crash inside the library at initialization time, which seems unexpected and less useful.

Reduced by 1 step - registering the view. Also added a batch subscribe which amortizes the syntax over multiple views.


Add connection url support to the client

Use case
We set database environment variables based on the standard format of xxx://[userspec@][hostspec][/dbname][?paramspec]
Clickhouse js client currently doesn't support it and we need to specify the env variables inconsistently to other databases.
Describe the solution you'd like
Add support for connection string like clickhouse://[user_info@][hosts_and_ports][/dbname][?query_parameters]
as it is already supported in clickhouse https://github.com/ClickHouse/ClickHouse/pull/50689
Additional context
ClickHouseClientConfigOptions defines the connection options

I will add URL support for http[s]://[username]:[password]@[host]:[port]/[database] in the next version and deprecate host (that was not the best name for it).

@PmegaOcalc, will be included in 1.0.0, ETA ~few weeks.

@PmegaOcalc, 1.0.0 is out; URL configuration is supported now.


Missing Linting

I noticed there are eslint dependencies and a lint script in package.json, but no configuration file, therefore it doesn't work...
Do you mind me setting it up?
I really like the project and would love to see code style consistencies :)

@wpioneer do you still read this?

@abisz Hello!
Yes, it would be great if you add config. This is to the benefit of the project.

@wpioneer do you have preferences concerning linting rules? I'm a big fan of the airbnb style rules.

@abisz It's good ;) Gatsby also uses an airbnb config .eslintrc#L4 So I think that this is the best solution for the starter.

#33


Volume bar overlaps caption menu

Expected behaviour
The volume bar to stop before the button on the right next to it, as Chrome does:

Actual behaviour
The volume bar overlaps the first button on the right next to it (either the captions button or settings button):

Steps to reproduce
Environment

Browser: Firefox
Version: 83.0b9
Operating System: Windows
Version: 10

Console errors (if any)
Link to where the bug is happening
https://plyr.io

For a simple fix set the min-width of the input field to 0:
.plyr__volume input{
    min-width: 0;
}

@dirkjf That indeed seems to fix it. Out of interest, do you happen to know why that fixes it?

@Koenvh1, By default, the initial value of min-width is auto, which means it will actually use the intrinsic minimum width that is automatically defined by the browser, which in the case of Firefox is bigger than the available space. This is how I believe it works, but you could also call it a bug in Firefox 😄.

I'll get the well overdue next version out the door this weekend.

Hi @sampotts,
I just upgraded to 3.6.3 because the changelog claimed this was fixed.
But I think it is not, you removed the fix again with https://github.com/sampotts/plyr/commit/da16c55427881411d4b9a29c7d5e6d13662d9499 so it never manged to get into master.
Was that an accident?

Hi @sampotts,
I just upgraded to 3.6.3 because the changelog claimed this was fixed.
But I think it is not, you removed the fix again with https://github.com/sampotts/plyr/commit/da16c55427881411d4b9a29c7d5e6d13662d9499 so it never manged to get into master.
Was that an accident?

That is the develop branch and that was because I moved the declaration so that all <input type="range" /> have the fix rather than just the volume one - see here: https://github.com/sampotts/plyr/blob/master/src/sass/components/sliders.scss#L15
It is fixed but you need to update the CSS too of course. The demo (https://plyr.io) is always using the latest published version so if it's fixed there, it's fixed on npm.

That is the develop branch and that was because I moved the declaration so that all <input type="range" /> have the fix rather than just the volume one - see here: https://github.com/sampotts/plyr/blob/master/src/sass/components/sliders.scss#L15
It is fixed but you need to update the CSS too of course. The demo (https://plyr.io) is always using the latest published version so if it's fixed there, it's fixed on npm.

Thanks @sampotts,
you are right I did not apply the update correctly. The missing commit then fooled me into thinking its not my fault 🤦
Sorry I had to bother you.

Thanks @sampotts,
you are right I did not apply the update correctly. The missing commit then fooled me into thinking its not my fault 🤦
Sorry I had to bother you.

No problem at all! 👍

No problem at all! 👍


feat(recipes): nested @layer _slots inside @layer recipes

📝 Description
Add a new _slots @layer for slot recipes so that "normal" recipes will have a higher CSS specificity
💣 Is this a breaking change (Yes/No):
no
📝 Additional Information
original issue
https://discord.com/channels/1118988919804010566/1120305029056831548/1145979787156926504
https://play.panda-css.com/XJynA6uzUU

I managed to implement this in a slightly simpler approach: See https://github.com/chakra-ui/panda/commit/bc3b077d4050a996500fa106b2171f7e128c2662
Thanks for working on this.


TimePicker dropdown interferes with other dropdowns

Add a TimePicker and a readonly Combobox 2. click on the TimePicker, dropdown opens. 3. leave the TimePicker and click on the other combobox. the TimePicker dropdown stays open. it should get closed since there's a click outside the TimePicker.

I tracked this behavior down to:
https://github.com/salesforce/design-system-react/blob/master/components/combobox/combobox.jsx#L1058
where ignore-react-onclickoutside is added to the Combobox.  It looks like this has been there from the beginning.  Maybe @interactivellama knows why this is needed.
If this is in fact needed, I'd suggest modifying TimePicker to use a controlled MenuDropdown and manage its own open/close state (similar to how it's done in Combobox).

I believe the goal is to prevent the dropdown menu from closing when the input is clicked. If this is removed I believe that the menu will be closed on input focus or possibly have an event race condition on whether the menu should be open.
I imagine the best direction forward would be to add a unique identifier that maps the className of the input only to that single instance of the Combobox. ignore-react-onclickoutside-sldkfjldkjfdklj. it would need to use shortid and override with the id prop. See https://github.com/salesforce/design-system-react/blob/master/components/combobox/combobox.jsx#L434
In summary, generatedId would be moved up a level and then passed via id prop with minimal changes. Does that sound like a good solution?

Yes, that sounds good to me!

Let me step back, I misunderstood the issue and thought we were stating that the but was in Combobox, but the contribution of putting Combobox inside of TimePicker was never merged last year. Yes, wrapping TimePicker in react-onclickoutside could would fix TimePicker.

@interactivellama TimePicker currently uses MenuDropdown, which is already wrapped with react-onclickoutside.  The problem is that this click outside is ignored when clicking on the Combobox input.
I think your original suggestion of having a unique class name is still needed.

Is this issue open to work?

Yes, please feel free to work on this issue!  Thanks a lot!

Ok ...I am working on this issue now. Thank you

How is this one going @DivyanshiSingh ?

How is this one going @DivyanshiSingh ?


Add workspace selection for start function

Currently, the timer just uses the default workspace but people can have multiple workspaces.

Resolved by da33bb3d79e6622729fd8826094ba4e0cb7ee507


Log failures in Proxy e2e tests

Followup PR from discussion in #11135
Ref #10792

LGTM

This only adds a log message, it should be safe.


Can't log in with Dreame account

When I configured my L10s Ultra in Mi Home app I was able to log in and use this integration. Hovewer I switched to Dreame app as it has more features and I am unable to log in. It says it can't log in to Xiaomi Miio cloud. Doesn't it support adding vacuum robot through Dreame app?

Use the dev branch

What URL should I put for Repository in order to use the dev branch?
https://github.com/Tasshack/dreame-vacuum/tree/dev is not working and throws following error "Repository 'tasshack/dreame-vacuum' exists in the store."
Thanks! Andreas


Simplifications to storage

Targeted at #856 , I just realized there was never a PR opened for this.
I'll clean up the branch before opening for review. Opening the PR for visibility.

@adlarkin , this is ready!

@adlarkin, thanks for the review, I addressed all your comments

Great; merging! :tada:


Continuation of #7

#7 Got a bit messy so this is a new issue for that same issue

@shadoWalker89 does this code do anything interesting?
import screen_brightness_control as s
from ctypes import windll
from ctypes.wintypes import DWORD, BYTE, HANDLE
for m in s.windows.VCP.iter_physical_monitors():
    print(windll.dxva2.SetVCPFeature(HANDLE(m), BYTE(0x10), DWORD(50)))

I was doing some thinking about the duplicate monitor showing up and I think that perhaps you have a laptop screen that can be addressed by both wmi and vcp. This could very well have confused the monitor/display kwarg filtering as it's not really designed to handle that kind of issue. It assumes a monitor is wmi or vcp only.
If the code snippet above changes both monitor's brightness then that would confirm this theory. If not then it's back to the drawing board.
Also what laptop are you using?

@shadoWalker89 does this code do anything interesting?
import screen_brightness_control as s
from ctypes import windll
from ctypes.wintypes import DWORD, BYTE, HANDLE
for m in s.windows.VCP.iter_physical_monitors():
    print(windll.dxva2.SetVCPFeature(HANDLE(m), BYTE(0x10), DWORD(50)))

I was doing some thinking about the duplicate monitor showing up and I think that perhaps you have a laptop screen that can be addressed by both wmi and vcp. This could very well have confused the monitor/display kwarg filtering as it's not really designed to handle that kind of issue. It assumes a monitor is wmi or vcp only.
If the code snippet above changes both monitor's brightness then that would confirm this theory. If not then it's back to the drawing board.
Also what laptop are you using?

To avoid any kind of confusion, the the master branch (0.7.0) and the dev branch at the current state (which is also the state after finishing from https://github.com/Crozzers/screen_brightness_control/issues/6) changing the brightness work flawlessly on both screens the laptop and the external one with or without the -d flag and on all the modes available from Windows + P shortcut.
The problem is not in changing the brightness it's only in the integrated monitor showing up twice in the list with -l flag
The integrated monitor show up twice in the list only if i'm using the Extend mode or using the integrated monitor by it self without the external one.
And yes in the tests that i did in https://github.com/Crozzers/screen_brightness_control/issues/7 the integrated monitor works only with wmi and the external one works only with vcp
Also the code snippet that you provided in this issue confirms that even more as i execute it with both monitors on it prints
0
1

and the brightness changes to 50 on the external monitor only
When it comes to the laptop, i tested this on two laptops and i got the same results
the first is Dell g5
the second is acer predator helios 300
As a closing note, if you keep the package the way it is now it will work without any problems at all from what i tested on both laptops with or without the -d flag.

To avoid any kind of confusion, the the master branch (0.7.0) and the dev branch at the current state (which is also the state after finishing from https://github.com/Crozzers/screen_brightness_control/issues/6) changing the brightness work flawlessly on both screens the laptop and the external one with or without the -d flag and on all the modes available from Windows + P shortcut.
The problem is not in changing the brightness it's only in the integrated monitor showing up twice in the list with -l flag
The integrated monitor show up twice in the list only if i'm using the Extend mode or using the integrated monitor by it self without the external one.
And yes in the tests that i did in https://github.com/Crozzers/screen_brightness_control/issues/7 the integrated monitor works only with wmi and the external one works only with vcp
Also the code snippet that you provided in this issue confirms that even more as i execute it with both monitors on it prints
0
1

and the brightness changes to 50 on the external monitor only
When it comes to the laptop, i tested this on two laptops and i got the same results
the first is Dell g5
the second is acer predator helios 300
As a closing note, if you keep the package the way it is now it will work without any problems at all from what i tested on both laptops with or without the -d flag.

I assume that "working with the -d flag" only doesn't work on the duplicate entry, it works on all the others, however, as stated in #7.
If you use the -l flag with --verbose enabled, do both the integrated display and it's duplicate have the same EDID string?
If you don't want to compare the EDID by eye you can probably run
import screen_brightness_control as s
laptop_screen = s.windows.WMI.get_display_info()[0]
duplicate_entry = s.windows.VCP.get_display_info()[0] # or whichever one is the duplicate entry
print(laptop_screen['edid'] == duplicate_entry['edid'])

I expect their serial numbers to be different and this is why they both show up because duplicates are filtered out using that serial.

I assume that "working with the -d flag" only doesn't work on the duplicate entry, it works on all the others, however, as stated in #7.
If you use the -l flag with --verbose enabled, do both the integrated display and it's duplicate have the same EDID string?
If you don't want to compare the EDID by eye you can probably run
import screen_brightness_control as s
laptop_screen = s.windows.WMI.get_display_info()[0]
duplicate_entry = s.windows.VCP.get_display_info()[0] # or whichever one is the duplicate entry
print(laptop_screen['edid'] == duplicate_entry['edid'])

I expect their serial numbers to be different and this is why they both show up because duplicates are filtered out using that serial.

Yep as i mentioned here https://github.com/Crozzers/screen_brightness_control/issues/7#issuecomment-767868109 the -d flag does not work with the duplicate entry only.
My initial message in issue 7 and my first reply go into the duplicate entry in detail
As for running with -l and --verbose this is the output
Display 0:
        Name: Asus AUO82ED
        Model: AUO82ED
        Manufacturer: Asus
        Manufacturer ID: AUO
        Serial: 4&14e39c04&0&UID265988_0
        Method: WMI
        EDID:
                HERE IT SHOWS THE EDID String i removed cuz i don't really now if that shouldn't show or no :D
Display 1:
        Name: Asus 82ED
        Model: 82ED
        Manufacturer: Asus
        Manufacturer ID: AUO
        Serial: 4&14e39c04&0&UID265988
        Method: VCP
        EDID: None
Display 2:
        Name: Samsung 0D2C
        Model: 0D2C
        Manufacturer: Samsung
        Manufacturer ID: SAM
        Serial: 5&6aabf8d&0&UID4354
        Method: VCP
        EDID: None

Looking at the output i think every thing is clear now
The first entry is for the integrated monitor with wmi
Second one is for the integrated but with vcp
I think the problem is very clear now :D

Yep as i mentioned here https://github.com/Crozzers/screen_brightness_control/issues/7#issuecomment-767868109 the -d flag does not work with the duplicate entry only.
My initial message in issue 7 and my first reply go into the duplicate entry in detail
As for running with -l and --verbose this is the output
Display 0:
        Name: Asus AUO82ED
        Model: AUO82ED
        Manufacturer: Asus
        Manufacturer ID: AUO
        Serial: 4&14e39c04&0&UID265988_0
        Method: WMI
        EDID:
                HERE IT SHOWS THE EDID String i removed cuz i don't really now if that shouldn't show or no :D
Display 1:
        Name: Asus 82ED
        Model: 82ED
        Manufacturer: Asus
        Manufacturer ID: AUO
        Serial: 4&14e39c04&0&UID265988
        Method: VCP
        EDID: None
Display 2:
        Name: Samsung 0D2C
        Model: 0D2C
        Manufacturer: Samsung
        Manufacturer ID: SAM
        Serial: 5&6aabf8d&0&UID4354
        Method: VCP
        EDID: None

Looking at the output i think every thing is clear now
The first entry is for the integrated monitor with wmi
Second one is for the integrated but with vcp
I think the problem is very clear now :D

It's interesting that none of them have a real serial number. They all use the windows UID. I don't think it's an issue but it certainly is curious.
So this looks like a simple fix. Simply get rid of the '_0' on the end of all WMI serial numbers and we should be good

It's interesting that none of them have a real serial number. They all use the windows UID. I don't think it's an issue but it certainly is curious.
So this looks like a simple fix. Simply get rid of the '_0' on the end of all WMI serial numbers and we should be good

I tested commit 51eb40d on a laptop and there are no more duplicate entries when using the -l flag.
The bad news is that s.get_brightness does return duplicates.
I'll work on this but it seems like progress

I tested commit 51eb40d on a laptop and there are no more duplicate entries when using the -l flag.
The bad news is that s.get_brightness does return duplicates.
I'll work on this but it seems like progress

After testing on my machine the duplicate entries have been resolved and the display kwarg works on the top-level (haven't tested lower level)

After testing on my machine the duplicate entries have been resolved and the display kwarg works on the top-level (haven't tested lower level)

I have now tested and fixed the display kwarg on the low-level functions. It should all work fine now. If you could test this that would be marvelous.
In issue #7 I think I said I was unable to replicate the duplicate display entries appearing and I do not remember having that issue before (I'm sure I would have noticed and fixed it). Well, I re-installed versions 0.5.1, 0.6.2 and 0.7.0 to test this (the usage of win32api started with v0.5.0) and the bug appeared. I saw duplicate entries in versions 0.5.1 and 0.6.2 but not in 0.7.0.
As I said, I don't think these were present before and the only thing that has changed recently about my laptop is Windows was updated. While it is entirely possible that I completely missed that bug (as I seem to do often) it is also entirely possible that Microsoft changed something in their API.
In any case, I will write some more unit tests sometime in the future to avoid this kind of event being an issue

I have now tested and fixed the display kwarg on the low-level functions. It should all work fine now. If you could test this that would be marvelous.
In issue #7 I think I said I was unable to replicate the duplicate display entries appearing and I do not remember having that issue before (I'm sure I would have noticed and fixed it). Well, I re-installed versions 0.5.1, 0.6.2 and 0.7.0 to test this (the usage of win32api started with v0.5.0) and the bug appeared. I saw duplicate entries in versions 0.5.1 and 0.6.2 but not in 0.7.0.
As I said, I don't think these were present before and the only thing that has changed recently about my laptop is Windows was updated. While it is entirely possible that I completely missed that bug (as I seem to do often) it is also entirely possible that Microsoft changed something in their API.
In any case, I will write some more unit tests sometime in the future to avoid this kind of event being an issue

Hi,
I can confirm that the latest changes on the dev branch have fixed the duplication of the integrated monitor without affecting the usage of the -d flag
This is the output of the list

Everything is ok now.

Hi,
I can confirm that the latest changes on the dev branch have fixed the duplication of the integrated monitor without affecting the usage of the -d flag
This is the output of the list

Everything is ok now.

without affecting the usage of the -d flag

As in, without breaking it or without fixing it?

without affecting the usage of the -d flag

As in, without breaking it or without fixing it?

Yeah without breaking

Yeah without breaking

Wonderful. I'll release it then.
Thanks for helping to get to the bottom of this

Wonderful. I'll release it then.
Thanks for helping to get to the bottom of this


Update yarn.lock with internationalization packages.

This looks like it might've been left out of the internationalization commit? Not sure, but yarn made this change when ran yarn.

👍 my bad, I missed committing the yarn.lock. will do so moving forward.


Allow custom Voice and Speech Models

this pull request removes the client-side logic to verify a valid speech and voice model.
the motivation is to support custom models on openai compatible backends
thanks for considering

@sashabaranov thanks a ton for coming back on this!
my own one adapts tools like mimic3, coqui.ai, whisper.cpp compatible ones into an openai-compatible api (also multiple ones). here a link: https://github.com/adrianliechti/llama. It is in use as part of a commercial platform.
and since I was using your lovely SDK for both tests but also integration, I allowed me to create this PR.
I think it is in line with this project's recent changes on embedding/models - so I hope over time a broader audience benefits (or at least needs less urgent maintenance once openai releases new whisper or tts models)

@sashabaranov
Had you already found the time to consider this change?

you made my day! cheers to you


Previewer plugins should be merged into one

CC @Golmote
Right now there are too many separate Previewer plugins. This is disruptive, both for people who want them, and for people who don't want them.
For the former, they need to check each one individually and if a new one is added, they do not get the update because it's a separate plugin. I think it's more common for people to want more than one previewer than for them to only want one.
For the latter, they have to scroll through a long list of previewers to find the plugins they actually need. It's a lot of visual clutter.
My proposal is: Merge them into one “CSS Previewers" plugin, with a way to turn certain previewers off globally. That way, you might even be able to reduce the amount of total code, as some of it will be shared across previewers. Thoughts?

Code is already shared across Previewers since they all require the Previewer: Base plugin.
I agree they could be merged, though. But we still don't have any global configuration for Prism, have we? What API do you imagine to turn off some previewers?

Awesome!
I would suggest using inheritable classes to opt-out, e.g. no-gradient-previewer on the element or an ancestor disables gradient previewers.

Any progress on this?

Hi @LeaVerou.
I was finally taking a closer look at this (it's almost done, actually), and now I have second thoughts...
The Previewer: Color plugin does preview colors in HTML bgcolor attributes, which is not CSS. Thus I'm worried about merging it into a CSS Previewers plugin.
While thinking about this, I realized it would be great to add a previewer for images. But those can appear both in CSS and HTML (and Markdown, and probably other components...). So the grouping of previewers by language looks less relevant in this case.

Yup, you're right (in fact, dabblet previewers also do both CSS and HTML).
I think the Previewer plugin should add all of them by default, in whatever languages are included, and support a configuration attribute (inherited) to only enable specific ones. E.g. `data-previewers="color length image".
What do you think?

Sounds good to me.


task: Implement system call interface

Added system call interface with enum-based invocation handling.

I have updated this PR so that we don't overlap syscall numbers with POSIX


[DLRM_DCNV2] Training v3.0 RCPs

Update to dlrm_dcnv2 RCPs for training 3.0 submission

@erichan1 is training WG good with merging this? thx

Generally lgtm.
@ShriyaPalsamudram Just so I know, who ran these? Just so we know who to talk to if questions come up. cc @janekl

Generally lgtm.
@ShriyaPalsamudram Just so I know, who ran these? Just so we know who to talk to if questions come up. cc @janekl

Hi @erichan1. We ran this using the same command as in https://github.com/mlcommons/logging/pull/300 and https://github.com/mlcommons/logging/pull/305 just changing batch size and learning rate accordingly. Feel free to contact me or Shriya in case of any questions.


Validate correct use

Hi, I'm developing a rails applicaton and using this plugin but I don't know how to validate that the user has made a correct input, I mean I can put "bogotha" and that doesn't exist. How can I validate that the value in the input is a valid location?

Have you found a solution to this yet? I have a similar issue, my application has 1000+ users (which are not all as computer minded as me) and they just type a string in the field and don't even bother clicking the autocomplete google suggestions. How can I validate the users clicked AND the address is valid?


system-wide: fix escaping of magic chars

fix escaping of magic lua chars (#2800)
fix redundant second gsub line in shellstartsqescape function
fix return value of shellstartsqescape function

Signed-off-by: Dirk Brenken<EMAIL_ADDRESS>

@jow- I'm quite unsure if the changes in util.lua are correct!?

Looked correct - merged, thanks!


field naming -- cumulative vs non-cumulative

Thanks  a lot for scraping these togehter!
In the README, you explain columns as

Field Name
Description
Format

date
Date of notification
YYYY-MM-DD

time
Time of notification
HH:MM

abbreviation_canton_and_fl
Abbreviation of the reporting canton
Text

ncumul_tested
Tests performed (cumulative)
Number

ncumul_conf
Number of confirmed cases
Number

ncumul_hosp
Number of hospitalised patients
Number

ncumul_ICU
Number of hospitalised patients in ICUs
Number

ncumul_vent
Number of patients requiring ventilation
Number

ncumul_released
Number of patients released from hospitals
Number

ncumul_deceased
Number of deceased
Number

source
Source of the information
href

most field names suggest the data are cumulative, but only one (tested) points this out explicitly. I assume fields with cases, deaths, and released are cumulative, while the remaining ones are not. please clarify

@rneher to rename the columns at this point would break a lot of stuff. However, we could be more specific in the description field and distinguish between 'current' and 'cumulative' for all. Would this help? However, a problem that might pop up at some point is different reporting policies among cantons.

I think we should change the description of all fields beginning with ncumul_ to have "(cumulative)" in the description, just like we have for ncumul_tested.
WDYT @tlorusso ?

I would propose adding (cumulative) to the description field of the confirmed cases, deaths, and released are cumulative, while adding (current) to field of the hospitalized / ICU and ventilated columns.  For those fields it might have been better to not include the prefix ncumul_ in the column names, as they reflect the current numbers without those that have already left the hospitals. @rneher @metaodi

I support not changing the columns. but making it clear in the table would help (plus a note that headers are named sub-optimally but are kept for consistency).

@rneher ok like this?

Field Name
Description
Format

date
Date of notification
YYYY-MM-DD

time
Time of notification
HH:MM

abbreviation_canton_and_fl
Abbreviation of the reporting canton
Text

ncumul_tested
Tests performed (cumulative)
Number

ncumul_conf
Number of confirmed cases  (cumulative)
Number

ncumul_hosp*
Number of hospitalised patients
Number

ncumul_ICU*
Number of hospitalised patients in ICUs
Number

ncumul_vent*
Number of patients requiring ventilation
Number

ncumul_released
Number of patients released from hospitals (cumulative)
Number

ncumul_deceased
Number of deceased     (cumulative)
Number

source
Source of the information
href

*Those variables reflect current, not cumulative numbers, even if the prefix in the column-name might suggest otherwise. Column names will not be changed to grant stability.

I second the request to clarify the descriptions! I also included suggestions from our group on changing field names, but I understand this may not be feasible. If possible, I would suggest to be even more verbose with the descriptions:

Field Name
Description
Format

date
Date of notification
YYYY-MM-DD

time
Time of notification
HH:MM

abbreviation_canton_and_fl
Abbreviation of the reporting canton
Text

ncumul_tested
Reported number of tests performed as of date
Number

ncumul_conf
Reported number of confirmed cases as of date
Number

~ncumul_hosp~ ninstant_hosp
Reported number of hospitalised patients on date
Number

~ncumul_ICU~ ninstant_ICU
Reported number of hospitalised patients in ICUs on date
Number

~ncumul_vent~ ninstant_vent
Reported number of patients requiring ventilation on date
Number

~ncumul_released~ ncumul_recovered
Reported number of patients released from hospitals or reported recovered as of date
Number

ncumul_deceased
Reported number of deceased as of date
Number

source
Source of the information
href

@SarahNadeau Thanks! Looks good & makes sense, we should implement your version of the column descriptions in the Readme. I've a question regarding ncumul_vent , appearingly for some cantons, information about intubated patients has been stored in this column for now. How important is the distinction between ventilated / intubated from your point of view? If we want to separate this two things we have to discuss how to do this without breaking to much stuff.

@tlorusso I was under the impression that we were not lumping intubation and ventilation data. So where intubation data is available, we will break this into a separate column (e.g. "ncumul_ICU_intub" for GE). However, I only joined as of this week and do not know how this was done before; @andreasamsler would have the real answer. Either way, the documentation of these new columns is missing.
We are not using the ventilated/intubated data at the moment so I can't speak to how they will be used (maybe to allocate supplies?). That said, I personally feel it is very important to separate anything that is feasibly separable. Users can lump these columns later if they wish.

@SarahNadeau as just few cantons report this numbers so far, it should not be much work to identify where this has happend. I just spotted that GE contains the same figures in the intub / vent columns, although it obviously shouldn't.
https://github.com/openZH/covid_19/blob/master/fallzahlen_kanton_total_csv/COVID19_Fallzahlen_Kanton_GE_total.csv
https://www.ge.ch/document/covid-19-situation-epidemiologique-geneve/telecharger
To ensure this is limited to GE we might have to check those Cantons that have data in the 'ncumul_vent' and check in the source whether it really reflects the number of ventilated. If not we can correct this and extend the dataset with a 'ncumul_ICU_intub' column (as GE already has) after the source column and also provide a definition in the Readme-table. I'm off this afternoon, but could contribute to this tomorrow.

@tlorusso good catch that we had incorrectly duplicated intub data in the vent column for GE. I'll flag this for the 2pm update person to correct. I will not add any columns myself (as discussed with Andreas) but if you add the column we will be happy to check it/ update it!

@tlorusso are you creating a PR for this?

Either later this evening or tomorrow morning. @metaodi

Fixed in #243


briar-desktop: 0.2.1-beta -> 0.3.1-beta

Description of changes
briar-desktop 0.2.1-beta has expired and will no longer run.
briar-desktop 0.3.1-beta also adds functionality such as notifications.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 201806 run on x86_64-linux 1

1 package built:

briar-desktop

Thank you!


GEODE-2256: Colocation example

Same as PR #85, which received the necessary approvals, but checks into develop branch.


Implement Design Groups

There is a functionality in FEM-Design to create different design groups that will get the same size when using autodesign. That could be nice to have available through the API

Are design groups implemented to .struxml?

I

Are design groups implemented to .struxml?

At a quick glance it didn't look like it. Export to struxml and then import made design groups disappear

Define fd-request.


Magento Sample Data

Is there any documentation on how to install this with sample data?

After install, bin/magento sampledata:deploy then bin/magento setup:upgrade -- just like normal install of sample data. Nothing specific to Docker here.


FIX: Allow calling LiveImage from another thread.

See https://github.com/NSLS-II/bluesky/issues/377

Ah, sorry for letting this get lost!


goinstall version is not the latest

I installed the GoMySQL using goinstall
goinstall github.com/Philio/GoMySQL

And cloned a version from github, the diff on statement.go shows on
612c612
< 	err = s.c.command(COM_STMT_RESET, s.statementId)
---
> 	err = s.c.command(COM_STMT_CLOSE, s.statementId)

Which exactly what thomas has commited for the latest version.

This might be a dumb question, but do you already have an older release of GoMySQL installed?
If so, just do goinstall -a -u. That will update, recompile, and reinstall all goinstalled packages.


Add support for gossipsub

I have no major concerns with anything here. behaviour.rs does seem to be lacking tests as has already been mentioned but all in all I have no issues

Had a chat with Sam. We decided it's for the best if we use floodsub instead of gossipsub


[FEATURE] Can we not have the latest version support both opensearch 1.x and 2.x

Planning to use the API for telegraf output plugin since there are workaround based solutions available for elasticsearch output plugin.
Plugin should support both opensearch 1.x and 2.x.
I'm new to golang, please suggest if there is an alternative available.

Can help if you could provide little some guidance.

@VachaShah do you have a good PR example that added integration tests to a client recently that @mannukalra can get inspired by?

Should this issue be closed?

Yep, support matrix is up-to-date.


Import Blog post

Would be great if there is a option to import/convert blog post from the older versions/SasBlogModule

Back up your database, then run these SQL commands right after switching to the new version.
INSERT INTO werkl_blog_author
SELECT * FROM sas_blog_author
WHERE id != UNHEX('64F4C60194634128B9B85D9299797C45');

INSERT INTO werkl_blog_author_translation
SELECT * FROM sas_blog_author_translation;

INSERT INTO werkl_blog_blog_category
SELECT * FROM sas_blog_blog_category;

DELETE FROM werkl_blog_category;
INSERT INTO werkl_blog_category
SELECT * FROM sas_blog_category;

DELETE FROM werkl_blog_category_translation;
INSERT INTO werkl_blog_category_translation
SELECT * FROM sas_blog_category_translation;

INSERT INTO werkl_blog_entries
SELECT * FROM sas_blog_entries;

INSERT INTO werkl_blog_entries_translation
SELECT * FROM sas_blog_entries_translation;

why is this not a migration in the plugin?

Sure, we could also implement it as a migration in the plugin. Pull requests are welcome.