#[non_exhaustive]pub struct OutputConfigBuilder { /* private fields */ }
Expand description
A builder for OutputConfig
.
Implementations§
Source§impl OutputConfigBuilder
impl OutputConfigBuilder
Sourcepub fn s3_output_location(self, input: impl Into<String>) -> Self
pub fn s3_output_location(self, input: impl Into<String>) -> Self
Identifies the S3 bucket where you want Amazon SageMaker AI to store the model artifacts. For example, s3://bucket-name/key-name-prefix
.
Sourcepub fn set_s3_output_location(self, input: Option<String>) -> Self
pub fn set_s3_output_location(self, input: Option<String>) -> Self
Identifies the S3 bucket where you want Amazon SageMaker AI to store the model artifacts. For example, s3://bucket-name/key-name-prefix
.
Sourcepub fn get_s3_output_location(&self) -> &Option<String>
pub fn get_s3_output_location(&self) -> &Option<String>
Identifies the S3 bucket where you want Amazon SageMaker AI to store the model artifacts. For example, s3://bucket-name/key-name-prefix
.
Sourcepub fn target_device(self, input: TargetDevice) -> Self
pub fn target_device(self, input: TargetDevice) -> Self
Identifies the target device or the machine learning instance that you want to run your model on after the compilation has completed. Alternatively, you can specify OS, architecture, and accelerator using TargetPlatform fields. It can be used instead of TargetPlatform
.
Currently ml_trn1
is available only in US East (N. Virginia) Region, and ml_inf2
is available only in US East (Ohio) Region.
Sourcepub fn set_target_device(self, input: Option<TargetDevice>) -> Self
pub fn set_target_device(self, input: Option<TargetDevice>) -> Self
Identifies the target device or the machine learning instance that you want to run your model on after the compilation has completed. Alternatively, you can specify OS, architecture, and accelerator using TargetPlatform fields. It can be used instead of TargetPlatform
.
Currently ml_trn1
is available only in US East (N. Virginia) Region, and ml_inf2
is available only in US East (Ohio) Region.
Sourcepub fn get_target_device(&self) -> &Option<TargetDevice>
pub fn get_target_device(&self) -> &Option<TargetDevice>
Identifies the target device or the machine learning instance that you want to run your model on after the compilation has completed. Alternatively, you can specify OS, architecture, and accelerator using TargetPlatform fields. It can be used instead of TargetPlatform
.
Currently ml_trn1
is available only in US East (N. Virginia) Region, and ml_inf2
is available only in US East (Ohio) Region.
Sourcepub fn target_platform(self, input: TargetPlatform) -> Self
pub fn target_platform(self, input: TargetPlatform) -> Self
Contains information about a target platform that you want your model to run on, such as OS, architecture, and accelerators. It is an alternative of TargetDevice
.
The following examples show how to configure the TargetPlatform
and CompilerOptions
JSON strings for popular target platforms:
-
Raspberry Pi 3 Model B+
"TargetPlatform": {"Os": "LINUX", "Arch": "ARM_EABIHF"},
"CompilerOptions": {'mattr': \['+neon'\]}
-
Jetson TX2
"TargetPlatform": {"Os": "LINUX", "Arch": "ARM64", "Accelerator": "NVIDIA"},
"CompilerOptions": {'gpu-code': 'sm_62', 'trt-ver': '6.0.1', 'cuda-ver': '10.0'}
-
EC2 m5.2xlarge instance OS
"TargetPlatform": {"Os": "LINUX", "Arch": "X86_64", "Accelerator": "NVIDIA"},
"CompilerOptions": {'mcpu': 'skylake-avx512'}
-
RK3399
"TargetPlatform": {"Os": "LINUX", "Arch": "ARM64", "Accelerator": "MALI"}
-
ARMv7 phone (CPU)
"TargetPlatform": {"Os": "ANDROID", "Arch": "ARM_EABI"},
"CompilerOptions": {'ANDROID_PLATFORM': 25, 'mattr': \['+neon'\]}
-
ARMv8 phone (CPU)
"TargetPlatform": {"Os": "ANDROID", "Arch": "ARM64"},
"CompilerOptions": {'ANDROID_PLATFORM': 29}
Sourcepub fn set_target_platform(self, input: Option<TargetPlatform>) -> Self
pub fn set_target_platform(self, input: Option<TargetPlatform>) -> Self
Contains information about a target platform that you want your model to run on, such as OS, architecture, and accelerators. It is an alternative of TargetDevice
.
The following examples show how to configure the TargetPlatform
and CompilerOptions
JSON strings for popular target platforms:
-
Raspberry Pi 3 Model B+
"TargetPlatform": {"Os": "LINUX", "Arch": "ARM_EABIHF"},
"CompilerOptions": {'mattr': \['+neon'\]}
-
Jetson TX2
"TargetPlatform": {"Os": "LINUX", "Arch": "ARM64", "Accelerator": "NVIDIA"},
"CompilerOptions": {'gpu-code': 'sm_62', 'trt-ver': '6.0.1', 'cuda-ver': '10.0'}
-
EC2 m5.2xlarge instance OS
"TargetPlatform": {"Os": "LINUX", "Arch": "X86_64", "Accelerator": "NVIDIA"},
"CompilerOptions": {'mcpu': 'skylake-avx512'}
-
RK3399
"TargetPlatform": {"Os": "LINUX", "Arch": "ARM64", "Accelerator": "MALI"}
-
ARMv7 phone (CPU)
"TargetPlatform": {"Os": "ANDROID", "Arch": "ARM_EABI"},
"CompilerOptions": {'ANDROID_PLATFORM': 25, 'mattr': \['+neon'\]}
-
ARMv8 phone (CPU)
"TargetPlatform": {"Os": "ANDROID", "Arch": "ARM64"},
"CompilerOptions": {'ANDROID_PLATFORM': 29}
Sourcepub fn get_target_platform(&self) -> &Option<TargetPlatform>
pub fn get_target_platform(&self) -> &Option<TargetPlatform>
Contains information about a target platform that you want your model to run on, such as OS, architecture, and accelerators. It is an alternative of TargetDevice
.
The following examples show how to configure the TargetPlatform
and CompilerOptions
JSON strings for popular target platforms:
-
Raspberry Pi 3 Model B+
"TargetPlatform": {"Os": "LINUX", "Arch": "ARM_EABIHF"},
"CompilerOptions": {'mattr': \['+neon'\]}
-
Jetson TX2
"TargetPlatform": {"Os": "LINUX", "Arch": "ARM64", "Accelerator": "NVIDIA"},
"CompilerOptions": {'gpu-code': 'sm_62', 'trt-ver': '6.0.1', 'cuda-ver': '10.0'}
-
EC2 m5.2xlarge instance OS
"TargetPlatform": {"Os": "LINUX", "Arch": "X86_64", "Accelerator": "NVIDIA"},
"CompilerOptions": {'mcpu': 'skylake-avx512'}
-
RK3399
"TargetPlatform": {"Os": "LINUX", "Arch": "ARM64", "Accelerator": "MALI"}
-
ARMv7 phone (CPU)
"TargetPlatform": {"Os": "ANDROID", "Arch": "ARM_EABI"},
"CompilerOptions": {'ANDROID_PLATFORM': 25, 'mattr': \['+neon'\]}
-
ARMv8 phone (CPU)
"TargetPlatform": {"Os": "ANDROID", "Arch": "ARM64"},
"CompilerOptions": {'ANDROID_PLATFORM': 29}
Sourcepub fn compiler_options(self, input: impl Into<String>) -> Self
pub fn compiler_options(self, input: impl Into<String>) -> Self
Specifies additional parameters for compiler options in JSON format. The compiler options are TargetPlatform
specific. It is required for NVIDIA accelerators and highly recommended for CPU compilations. For any other cases, it is optional to specify CompilerOptions.
-
DTYPE
: Specifies the data type for the input. When compiling forml_*
(except forml_inf
) instances using PyTorch framework, provide the data type (dtype) of the model's input."float32"
is used if"DTYPE"
is not specified. Options for data type are:-
float32: Use either
"float"
or"float32"
. -
int64: Use either
"int64"
or"long"
.
For example,
{"dtype" : "float32"}
. -
-
CPU
: Compilation for CPU supports the following compiler options.-
mcpu
: CPU micro-architecture. For example,{'mcpu': 'skylake-avx512'}
-
mattr
: CPU flags. For example,{'mattr': \['+neon', '+vfpv4'\]}
-
-
ARM
: Details of ARM CPU compilations.-
NEON
: NEON is an implementation of the Advanced SIMD extension used in ARMv7 processors.For example, add
{'mattr': \['+neon'\]}
to the compiler options if compiling for ARM 32-bit platform with the NEON support.
-
-
NVIDIA
: Compilation for NVIDIA GPU supports the following compiler options.-
gpu_code
: Specifies the targeted architecture. -
trt-ver
: Specifies the TensorRT versions in x.y.z. format. -
cuda-ver
: Specifies the CUDA version in x.y format.
For example,
{'gpu-code': 'sm_72', 'trt-ver': '6.0.1', 'cuda-ver': '10.1'}
-
-
ANDROID
: Compilation for the Android OS supports the following compiler options:-
ANDROID_PLATFORM
: Specifies the Android API levels. Available levels range from 21 to 29. For example,{'ANDROID_PLATFORM': 28}
. -
mattr
: Add{'mattr': \['+neon'\]}
to compiler options if compiling for ARM 32-bit platform with NEON support.
-
-
INFERENTIA
: Compilation for target ml_inf1 uses compiler options passed in as a JSON string. For example,"CompilerOptions": "\"--verbose 1 --num-neuroncores 2 -O2\""
.For information about supported compiler options, see Neuron Compiler CLI Reference Guide.
-
CoreML
: Compilation for the CoreML OutputConfigTargetDevice
supports the following compiler options:-
class_labels
: Specifies the classification labels file name inside input tar.gz file. For example,{"class_labels": "imagenet_labels_1000.txt"}
. Labels inside the txt file should be separated by newlines.
-
Sourcepub fn set_compiler_options(self, input: Option<String>) -> Self
pub fn set_compiler_options(self, input: Option<String>) -> Self
Specifies additional parameters for compiler options in JSON format. The compiler options are TargetPlatform
specific. It is required for NVIDIA accelerators and highly recommended for CPU compilations. For any other cases, it is optional to specify CompilerOptions.
-
DTYPE
: Specifies the data type for the input. When compiling forml_*
(except forml_inf
) instances using PyTorch framework, provide the data type (dtype) of the model's input."float32"
is used if"DTYPE"
is not specified. Options for data type are:-
float32: Use either
"float"
or"float32"
. -
int64: Use either
"int64"
or"long"
.
For example,
{"dtype" : "float32"}
. -
-
CPU
: Compilation for CPU supports the following compiler options.-
mcpu
: CPU micro-architecture. For example,{'mcpu': 'skylake-avx512'}
-
mattr
: CPU flags. For example,{'mattr': \['+neon', '+vfpv4'\]}
-
-
ARM
: Details of ARM CPU compilations.-
NEON
: NEON is an implementation of the Advanced SIMD extension used in ARMv7 processors.For example, add
{'mattr': \['+neon'\]}
to the compiler options if compiling for ARM 32-bit platform with the NEON support.
-
-
NVIDIA
: Compilation for NVIDIA GPU supports the following compiler options.-
gpu_code
: Specifies the targeted architecture. -
trt-ver
: Specifies the TensorRT versions in x.y.z. format. -
cuda-ver
: Specifies the CUDA version in x.y format.
For example,
{'gpu-code': 'sm_72', 'trt-ver': '6.0.1', 'cuda-ver': '10.1'}
-
-
ANDROID
: Compilation for the Android OS supports the following compiler options:-
ANDROID_PLATFORM
: Specifies the Android API levels. Available levels range from 21 to 29. For example,{'ANDROID_PLATFORM': 28}
. -
mattr
: Add{'mattr': \['+neon'\]}
to compiler options if compiling for ARM 32-bit platform with NEON support.
-
-
INFERENTIA
: Compilation for target ml_inf1 uses compiler options passed in as a JSON string. For example,"CompilerOptions": "\"--verbose 1 --num-neuroncores 2 -O2\""
.For information about supported compiler options, see Neuron Compiler CLI Reference Guide.
-
CoreML
: Compilation for the CoreML OutputConfigTargetDevice
supports the following compiler options:-
class_labels
: Specifies the classification labels file name inside input tar.gz file. For example,{"class_labels": "imagenet_labels_1000.txt"}
. Labels inside the txt file should be separated by newlines.
-
Sourcepub fn get_compiler_options(&self) -> &Option<String>
pub fn get_compiler_options(&self) -> &Option<String>
Specifies additional parameters for compiler options in JSON format. The compiler options are TargetPlatform
specific. It is required for NVIDIA accelerators and highly recommended for CPU compilations. For any other cases, it is optional to specify CompilerOptions.
-
DTYPE
: Specifies the data type for the input. When compiling forml_*
(except forml_inf
) instances using PyTorch framework, provide the data type (dtype) of the model's input."float32"
is used if"DTYPE"
is not specified. Options for data type are:-
float32: Use either
"float"
or"float32"
. -
int64: Use either
"int64"
or"long"
.
For example,
{"dtype" : "float32"}
. -
-
CPU
: Compilation for CPU supports the following compiler options.-
mcpu
: CPU micro-architecture. For example,{'mcpu': 'skylake-avx512'}
-
mattr
: CPU flags. For example,{'mattr': \['+neon', '+vfpv4'\]}
-
-
ARM
: Details of ARM CPU compilations.-
NEON
: NEON is an implementation of the Advanced SIMD extension used in ARMv7 processors.For example, add
{'mattr': \['+neon'\]}
to the compiler options if compiling for ARM 32-bit platform with the NEON support.
-
-
NVIDIA
: Compilation for NVIDIA GPU supports the following compiler options.-
gpu_code
: Specifies the targeted architecture. -
trt-ver
: Specifies the TensorRT versions in x.y.z. format. -
cuda-ver
: Specifies the CUDA version in x.y format.
For example,
{'gpu-code': 'sm_72', 'trt-ver': '6.0.1', 'cuda-ver': '10.1'}
-
-
ANDROID
: Compilation for the Android OS supports the following compiler options:-
ANDROID_PLATFORM
: Specifies the Android API levels. Available levels range from 21 to 29. For example,{'ANDROID_PLATFORM': 28}
. -
mattr
: Add{'mattr': \['+neon'\]}
to compiler options if compiling for ARM 32-bit platform with NEON support.
-
-
INFERENTIA
: Compilation for target ml_inf1 uses compiler options passed in as a JSON string. For example,"CompilerOptions": "\"--verbose 1 --num-neuroncores 2 -O2\""
.For information about supported compiler options, see Neuron Compiler CLI Reference Guide.
-
CoreML
: Compilation for the CoreML OutputConfigTargetDevice
supports the following compiler options:-
class_labels
: Specifies the classification labels file name inside input tar.gz file. For example,{"class_labels": "imagenet_labels_1000.txt"}
. Labels inside the txt file should be separated by newlines.
-
Sourcepub fn kms_key_id(self, input: impl Into<String>) -> Self
pub fn kms_key_id(self, input: impl Into<String>) -> Self
The Amazon Web Services Key Management Service key (Amazon Web Services KMS) that Amazon SageMaker AI uses to encrypt your output models with Amazon S3 server-side encryption after compilation job. If you don't provide a KMS key ID, Amazon SageMaker AI uses the default KMS key for Amazon S3 for your role's account. For more information, see KMS-Managed Encryption Keys in the Amazon Simple Storage Service Developer Guide.
The KmsKeyId can be any of the following formats:
-
Key ID:
1234abcd-12ab-34cd-56ef-1234567890ab
-
Key ARN:
arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab
-
Alias name:
alias/ExampleAlias
-
Alias name ARN:
arn:aws:kms:us-west-2:111122223333:alias/ExampleAlias
Sourcepub fn set_kms_key_id(self, input: Option<String>) -> Self
pub fn set_kms_key_id(self, input: Option<String>) -> Self
The Amazon Web Services Key Management Service key (Amazon Web Services KMS) that Amazon SageMaker AI uses to encrypt your output models with Amazon S3 server-side encryption after compilation job. If you don't provide a KMS key ID, Amazon SageMaker AI uses the default KMS key for Amazon S3 for your role's account. For more information, see KMS-Managed Encryption Keys in the Amazon Simple Storage Service Developer Guide.
The KmsKeyId can be any of the following formats:
-
Key ID:
1234abcd-12ab-34cd-56ef-1234567890ab
-
Key ARN:
arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab
-
Alias name:
alias/ExampleAlias
-
Alias name ARN:
arn:aws:kms:us-west-2:111122223333:alias/ExampleAlias
Sourcepub fn get_kms_key_id(&self) -> &Option<String>
pub fn get_kms_key_id(&self) -> &Option<String>
The Amazon Web Services Key Management Service key (Amazon Web Services KMS) that Amazon SageMaker AI uses to encrypt your output models with Amazon S3 server-side encryption after compilation job. If you don't provide a KMS key ID, Amazon SageMaker AI uses the default KMS key for Amazon S3 for your role's account. For more information, see KMS-Managed Encryption Keys in the Amazon Simple Storage Service Developer Guide.
The KmsKeyId can be any of the following formats:
-
Key ID:
1234abcd-12ab-34cd-56ef-1234567890ab
-
Key ARN:
arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab
-
Alias name:
alias/ExampleAlias
-
Alias name ARN:
arn:aws:kms:us-west-2:111122223333:alias/ExampleAlias
Sourcepub fn build(self) -> OutputConfig
pub fn build(self) -> OutputConfig
Consumes the builder and constructs a OutputConfig
.
Trait Implementations§
Source§impl Clone for OutputConfigBuilder
impl Clone for OutputConfigBuilder
Source§fn clone(&self) -> OutputConfigBuilder
fn clone(&self) -> OutputConfigBuilder
1.0.0 · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read moreSource§impl Debug for OutputConfigBuilder
impl Debug for OutputConfigBuilder
Source§impl Default for OutputConfigBuilder
impl Default for OutputConfigBuilder
Source§fn default() -> OutputConfigBuilder
fn default() -> OutputConfigBuilder
Source§impl PartialEq for OutputConfigBuilder
impl PartialEq for OutputConfigBuilder
impl StructuralPartialEq for OutputConfigBuilder
Auto Trait Implementations§
impl Freeze for OutputConfigBuilder
impl RefUnwindSafe for OutputConfigBuilder
impl Send for OutputConfigBuilder
impl Sync for OutputConfigBuilder
impl Unpin for OutputConfigBuilder
impl UnwindSafe for OutputConfigBuilder
Blanket Implementations§
Source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
Source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
Source§impl<T> CloneToUninit for Twhere
T: Clone,
impl<T> CloneToUninit for Twhere
T: Clone,
Source§impl<T> Instrument for T
impl<T> Instrument for T
Source§fn instrument(self, span: Span) -> Instrumented<Self>
fn instrument(self, span: Span) -> Instrumented<Self>
Source§fn in_current_span(self) -> Instrumented<Self>
fn in_current_span(self) -> Instrumented<Self>
Source§impl<T> IntoEither for T
impl<T> IntoEither for T
Source§fn into_either(self, into_left: bool) -> Either<Self, Self>
fn into_either(self, into_left: bool) -> Either<Self, Self>
self
into a Left
variant of Either<Self, Self>
if into_left
is true
.
Converts self
into a Right
variant of Either<Self, Self>
otherwise. Read moreSource§fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
self
into a Left
variant of Either<Self, Self>
if into_left(&self)
returns true
.
Converts self
into a Right
variant of Either<Self, Self>
otherwise. Read moreSource§impl<T> Paint for Twhere
T: ?Sized,
impl<T> Paint for Twhere
T: ?Sized,
Source§fn fg(&self, value: Color) -> Painted<&T>
fn fg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self
with the foreground set to
value
.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like red()
and
green()
, which have the same functionality but are
pithier.
§Example
Set foreground color to white using fg()
:
use yansi::{Paint, Color};
painted.fg(Color::White);
Set foreground color to white using white()
.
use yansi::Paint;
painted.white();
Source§fn bright_black(&self) -> Painted<&T>
fn bright_black(&self) -> Painted<&T>
Source§fn bright_red(&self) -> Painted<&T>
fn bright_red(&self) -> Painted<&T>
Source§fn bright_green(&self) -> Painted<&T>
fn bright_green(&self) -> Painted<&T>
Source§fn bright_yellow(&self) -> Painted<&T>
fn bright_yellow(&self) -> Painted<&T>
Source§fn bright_blue(&self) -> Painted<&T>
fn bright_blue(&self) -> Painted<&T>
Source§fn bright_magenta(&self) -> Painted<&T>
fn bright_magenta(&self) -> Painted<&T>
Source§fn bright_cyan(&self) -> Painted<&T>
fn bright_cyan(&self) -> Painted<&T>
Source§fn bright_white(&self) -> Painted<&T>
fn bright_white(&self) -> Painted<&T>
Source§fn bg(&self, value: Color) -> Painted<&T>
fn bg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self
with the background set to
value
.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like on_red()
and
on_green()
, which have the same functionality but
are pithier.
§Example
Set background color to red using fg()
:
use yansi::{Paint, Color};
painted.bg(Color::Red);
Set background color to red using on_red()
.
use yansi::Paint;
painted.on_red();
Source§fn on_primary(&self) -> Painted<&T>
fn on_primary(&self) -> Painted<&T>
Source§fn on_magenta(&self) -> Painted<&T>
fn on_magenta(&self) -> Painted<&T>
Source§fn on_bright_black(&self) -> Painted<&T>
fn on_bright_black(&self) -> Painted<&T>
Source§fn on_bright_red(&self) -> Painted<&T>
fn on_bright_red(&self) -> Painted<&T>
Source§fn on_bright_green(&self) -> Painted<&T>
fn on_bright_green(&self) -> Painted<&T>
Source§fn on_bright_yellow(&self) -> Painted<&T>
fn on_bright_yellow(&self) -> Painted<&T>
Source§fn on_bright_blue(&self) -> Painted<&T>
fn on_bright_blue(&self) -> Painted<&T>
Source§fn on_bright_magenta(&self) -> Painted<&T>
fn on_bright_magenta(&self) -> Painted<&T>
Source§fn on_bright_cyan(&self) -> Painted<&T>
fn on_bright_cyan(&self) -> Painted<&T>
Source§fn on_bright_white(&self) -> Painted<&T>
fn on_bright_white(&self) -> Painted<&T>
Source§fn attr(&self, value: Attribute) -> Painted<&T>
fn attr(&self, value: Attribute) -> Painted<&T>
Enables the styling Attribute
value
.
This method should be used rarely. Instead, prefer to use
attribute-specific builder methods like bold()
and
underline()
, which have the same functionality
but are pithier.
§Example
Make text bold using attr()
:
use yansi::{Paint, Attribute};
painted.attr(Attribute::Bold);
Make text bold using using bold()
.
use yansi::Paint;
painted.bold();
Source§fn rapid_blink(&self) -> Painted<&T>
fn rapid_blink(&self) -> Painted<&T>
Source§fn quirk(&self, value: Quirk) -> Painted<&T>
fn quirk(&self, value: Quirk) -> Painted<&T>
Enables the yansi
Quirk
value
.
This method should be used rarely. Instead, prefer to use quirk-specific
builder methods like mask()
and
wrap()
, which have the same functionality but are
pithier.
§Example
Enable wrapping using .quirk()
:
use yansi::{Paint, Quirk};
painted.quirk(Quirk::Wrap);
Enable wrapping using wrap()
.
use yansi::Paint;
painted.wrap();
Source§fn clear(&self) -> Painted<&T>
👎Deprecated since 1.0.1: renamed to resetting()
due to conflicts with Vec::clear()
.
The clear()
method will be removed in a future release.
fn clear(&self) -> Painted<&T>
resetting()
due to conflicts with Vec::clear()
.
The clear()
method will be removed in a future release.Source§fn whenever(&self, value: Condition) -> Painted<&T>
fn whenever(&self, value: Condition) -> Painted<&T>
Conditionally enable styling based on whether the Condition
value
applies. Replaces any previous condition.
See the crate level docs for more details.
§Example
Enable styling painted
only when both stdout
and stderr
are TTYs:
use yansi::{Paint, Condition};
painted.red().on_yellow().whenever(Condition::STDOUTERR_ARE_TTY);