h& s<      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ Safe-Inferred"%&1;=?   Safe-Inferred"%&1;=?launchdarkly-server-sdk(The status of the client initialization.launchdarkly-server-sdk;The client has not yet finished connecting to LaunchDarkly.launchdarkly-server-sdk?The client attempted to connect to LaunchDarkly and was denied.launchdarkly-server-sdk5The client has successfuly connected to LaunchDarkly.launchdarkly-server-sdkThe client is being terminated  Safe-Inferred"%&1;=?o  Safe-Inferred"%&1;=?  Safe-Inferred"#%&1;=?launchdarkly-server-sdkDefines the possible values of the errorKind property of EvaluationReason.launchdarkly-server-sdkIndicates that there was an internal inconsistency in the flag data, e.g. a rule specified a nonexistent variation.launchdarkly-server-sdkIndicates that the caller provided a flag key that did not match any known flag.launchdarkly-server-sdkIndicates that the result value was not of the requested type, e.g. you called boolVariationDetail but the value was an integer.launchdarkly-server-sdkIndicates that the caller tried to evaluate a flag before the client had successfully initialized.launchdarkly-server-sdkIndicates that some error was returned by the external feature store.launchdarkly-server-sdkDefines the possible values of the Kind property of EvaluationReason.launchdarkly-server-sdkIndicates that the flag was off and therefore returned its configured off value. launchdarkly-server-sdkindicates that the user key was specifically targeted for this flag.%launchdarkly-server-sdk;The index of the rule that was matched (0 being the first).&launchdarkly-server-sdk3The unique identifier of the rule that was matched.'launchdarkly-server-sdkWhether the evaluation was part of an experiment. Is true if the evaluation resulted in an experiment rollout *and* served one of the variations in the experiment. Otherwise false.(launchdarkly-server-sdk-The flag key of the prerequisite that failed.)launchdarkly-server-sdkDescribes the type of error.*launchdarkly-server-sdkCombines the result of a flag evaluation with an explanation of how it was calculated.,launchdarkly-server-sdkThe result of the flag evaluation. This will be either one of the flag's variations or the default value passed by the application.-launchdarkly-server-sdkThe index of the returned value within the flag's list of variations, e.g. 0 for the first variation - or Nothing if the default value was returned..launchdarkly-server-sdkDescribes the main factor that influenced the flag evaluation value.)('&%$#"! *-,.+  Safe-Inferred"%&1;=?  Safe-Inferred"%&1;=?c Safe-Inferred"%&1;=?+/launchdarkly-server-sdk1A builder for feature flag rules to be used with 5.In the LaunchDarkly model, a flag can have any number of rules, and a rule can have any number of clauses. A clause is an individual test such as "name is 'X'". A rule matches a user if all of the rule's clauses match the user.To start defining a rule, use one of the matching functions such as ; or <. This defines the first clause for the rule. Optionally, you may add more clauses with the rule builder functions such as = and >. Finally, call 4 to finish defining the rule.0launchdarkly-server-sdkSpecifies the fallthrough variation. The fallthrough is the value that is returned if targeting is on and the user was not matched by a more specific target or rule.If the flag was previously configured with other variations and the variation specified is a boolean, this also changes it to a boolean flag.1launchdarkly-server-sdkSpecifies the off variation for a flag. This is the variation that is returned whenever targeting is off.If the flag was previously configured with other variations and the variation specified is a boolean, this also changes it to a boolean flag.2launchdarkly-server-sdkSets the flag to always return the specified variation for all users.The variation is specified, Targeting is switched on, and any existing targets or rules are removed. The fallthrough variation is set to the specified value. The off variation is left unchanged.If the flag was previously configured with other variations and the variation specified is a boolean, this also changes it to a boolean flag.3launchdarkly-server-sdkSets the flag to return the specified variation for a specific user key when targeting is on.=This has no effect when targeting is turned off for the flag.If the flag was previously configured with other variations and the variation specified is a boolean, this also changes it to a boolean flag.4launchdarkly-server-sdkFinishes defining the rule, specifying the result as either a boolean or a variation index.If the flag was previously configured with other variations and the variation specified is a boolean, this also changes it to a boolean flag.5launchdarkly-server-sdk:A builder for feature flag configurations to be used with )LaunchDarkly.Server.Integrations.TestData.see  and 7launchdarkly-server-sdkA shortcut for setting the flag to use the standard boolean configuration.3This is the default for all new flags created with &. The flag will have two variations, True and False" (in that order); it will return False whenever targeting is off, and True> when targeting is on if no other settings specify otherwise.8launchdarkly-server-sdk-Sets targeting to be on or off for this flag.The effect of this depends on the rest of the flag configuration, just as it does on the real LaunchDarkly dashboard. In the default configuration that you get from calling + with a new flag key, the flag will return False" whenever targeting is off, and True when targeting is on.launchdarkly-server-sdkRemoves any existing rules from the flag. This undoes the effect of methods like ; or <launchdarkly-server-sdkRemoves any existing user targets from the flag. This undoes the effect of methods like 39launchdarkly-server-sdkSets the flag to always return the specified variation value for all users.-The value may be of any type that implements . This method changes the flag to have only a single variation, which is this value, and to return the same variation regardless of whether targeting is on or off. Any existing targets or rules are removed.:launchdarkly-server-sdk4Changes the allowable variation values for the flag.1The value may be of any JSON type, as defined by . For instance, a boolean flag normally has [toJSON True, toJSON False]; a string-valued flag might have [toJSON "red", toJSON "green"]; etc.;launchdarkly-server-sdklaunchdarkly-server-sdk8Adds another clause, using the "is not one of" operator..For example, this creates a rule that returns True5 if the name is "Patsy" and the country is not "gb": testData & flag "flag" & ifMatch "name" [toJSON "Patsy"] & andNotMatch "country" [toJSON "gb"] & thenReturn True 0launchdarkly-server-sdkTrue or False or the desired fallthrough variation index: 0 for the first, 1 for the second, etc.1launchdarkly-server-sdkTrue or False or the desired fallthrough variation index: 0 for the first, 1 for the second, etc.2launchdarkly-server-sdkTrue or False or the desired fallthrough variation index: 0 for the first, 1 for the second, etc.3launchdarkly-server-sdka user key to targetlaunchdarkly-server-sdkTrue or False or the desired fallthrough variation index: 0 for the first, 1 for the second, etc.4launchdarkly-server-sdkTrue or False or the desired fallthrough variation index: 0 for the first, 1 for the second, etc.8launchdarkly-server-sdkisOn True if targeting should be on:launchdarkly-server-sdkthe desired variations;launchdarkly-server-sdk-attribute the user attribute to match againstlaunchdarkly-server-sdkvalues to compare tolaunchdarkly-server-sdkcall 4, to finish the rule, or add more tests with = or > <launchdarkly-server-sdk-attribute the user attribute to match againstlaunchdarkly-server-sdkvalues to compare tolaunchdarkly-server-sdkcall 4, to finish the rule, or add more tests with = or > =launchdarkly-server-sdk#the user attribute to match againstlaunchdarkly-server-sdkvalues to compare to>launchdarkly-server-sdk#the user attribute to match againstlaunchdarkly-server-sdkvalues to compare to/4320156789:;<=> Safe-Inferred"%&1;=?1l ?launchdarkly-server-sdk-An abstract representation of a store object.Alaunchdarkly-server-sdkA serialized item. If the item is deleted or does not exist this should be .Blaunchdarkly-server-sdkThe version of a given item. If the item does not exist this should be zero.Claunchdarkly-server-sdkThe interface implemented by external stores for use by the SDK.Elaunchdarkly-server-sdk=A map of all features in a given namespace including deleted.Flaunchdarkly-server-sdk)Return the value of a key in a namespace.Glaunchdarkly-server-sdkUpsert a given feature. Versions should be compared before upsert. The result should indicate if the feature was replaced or not.Hlaunchdarkly-server-sdkChecks if the external store has been initialized, which may have been done by another instance of the SDK.Ilaunchdarkly-server-sdkA map of namespaces, and items in namespaces. The entire store state should be replaced with these values.Jlaunchdarkly-server-sdk0Represents a namespace such as flags or segmentsKlaunchdarkly-server-sdk'Represents the key for a given feature.Llaunchdarkly-server-sdkThe result type for every C function. Instead of throwing an exception, any store related error should return :. Exceptions unrelated to the store should not be caught.4?@ABCDEFGHIJKL Safe-Inferred"%&1;=?2?@ABCDEFGHIJKLLKJCDEFGHI?@AB Safe-Inferred"%&1;=?2 Safe-Inferred"%&1;=?9;Olaunchdarkly-server-sdk/Creates a new instance of the test data source.Plaunchdarkly-server-sdkCreates or copies a 5( for building a test flag configuration.2If this flag key has already been defined in this M instance, then the builder starts with the same configuration that was last provided for this flag.Otherwise, it starts with a new default configuration in which the flag has True and False variations, is True1 for all users when targeting is turned on and False otherwise, and currently has targeting turned on. You can change any of those properties, and provide more complex behavior, using the 5 methods.Once you have set the desired configuration, pass the builder to Q.see QQlaunchdarkly-server-sdkMNOPQMOPQN57801293:;<6/=>4 Safe-Inferred"%&1;=?F5Rlaunchdarkly-server-sdk Creates a DataSourceFactory which uses the configured the file data sources. This allows you to use local files as a source of feature flag state, instead of using an actual LaunchDarkly connection.1To use the file dataSource you can add it to the  using  let config = configSetDataSourceFactory (FileData.dataSourceFactory [".testDataflags.json"]) $ makeConfig "sdk-key" client <- makeClient config This will cause the client not to connect to LaunchDarkly to get feature flags. The client may still make network connections to send analytics events, unless you have disabled this with  to False. IMPORTANT: Do not set  to True; doing so would not just put the SDK "offline" with regard to LaunchDarkly, but will completely turn off all flag data sources to the SDK including the file data source.Flag data files can be either JSON or YAML. They contain an object with three possible properties: flagsFeature flag definitions. flagValues3Simplified feature flags that contain only a value.segmentsUser segment definitions.The format of the data in flags and segments is defined by the LaunchDarkly application and is subject to change. Rather than trying to construct these objects yourself, it is simpler to request existing flags directly from the LaunchDarkly server in JSON format, and use this output as the starting point for your file. In Linux you would do this: (curl -H "Authorization: {your sdk key}"  +https://app.launchdarkly.com/sdk/latest-all The output will look something like this (but with many more properties): { "flags": { "flag-key-1": { "key": "flag-key-1", "on": true, "variations": [ "a", "b" ] }, "flag-key-2": { "key": "flag-key-2", "on": true, "variations": [ "c", "d" ] } }, "segments": { "segment-key-1": { "key": "segment-key-1", "includes": [ "user-key-1" ] } } } Data in this format allows the SDK to exactly duplicate all the kinds of flag behavior supported by LaunchDarkly. However, in many cases you will not need this complexity, but will just want to set specific flag keys to specific values. For that, you can use a much simpler format: { "flagValues": { "my-string-flag-key": "value-1", "my-boolean-flag-key": true, "my-integer-flag-key": 3 } }  Or, in YAML: flagValues: my-string-flag-key: "value-1" my-boolean-flag-key: true $It is also possible to specify both flags and  flagValues, if you want some flags to have simple values and others to have complex behavior. However, it is an error to use the same flag key or segment key more than once, either in a single file or across multiple files.If the data source encounters any error in any file(malformed content, a missing file) it will not load flags from that file. If the data source encounters a duplicate key it will ignore that duplicate entry.RR Safe-Inferred"%&1;=?I`launchdarkly-server-sdk