Need straightforward way to honor the caller's preference-variable values / inherited common parameters in functions defined in script modules

This is a longstanding issue that @dlwyatt explained in detail in this 2014 blog post, and he has even published module PreferenceVariables with advanced function Get-CallerPreference to ease the pain, via a hard-coded list of preference variable names.
In short: A script module's functions do not see the preference-variable values set in the caller's context (except if that context happens to be the global one), which means that the caller's preferences are not honored.
Update: Since implicitly setting preference variables is PowerShell's method for propagating (inheriting) common parameters such as -WhatIf, such parameters are ultimately not honored in calls to script-module functions when passed via an advanced function - see #3106, #6556, and #6342. In short: the common-parameter inheritance mechanism is fundamentally broken for advanced functions across module scopes, which also affects standard modules such as NetSecurity and Microsoft.PowerShell.Archive .

From a user's perspective this is (a) surprising and (b), once understood, inconvenient.
Additionally, given that compiled cmdlets do not have the same problem, it is not easy to tell in advance which cmdlets / advanced functions are affected. In a similar vein, compiled cmdlets proxied via implicitly remoting modules also do not honor the caller's preferences.

From a developer's perspective, it is (a) not easy to keep the problem in mind, and (b) addressing the problem requires a workaround that is currently quite cumbersome, exacerbated by currently not having a programmatic way identify all preference variables in order to copy their values to the callee's namespace - see #4394.

A simple demonstration of the problem:
# Define an in-memory module with a single function Foo() that provokes
# a non-terminating error.
$null = New-Module {
  function Foo {
    [CmdletBinding()] param()
    # Provoke a non-terminating error.
    Get-Item /Nosuch
  }
}

# Set $ErrorActionPreference in the *script* context:
# Request that errors be silenced.
# (Note: Only if you defined this in the *global* context would the module see it.)
$ErrorActionPreference = 'SilentlyContinue'

# Because the module in which Foo() is defined doesn't see this script's
# variables, it cannot honor the $ErrorActionPreference setting, and
# the error message still prints.
Foo

Desired behavior
No output.
Current behavior
Get-Item : Cannot find path '/Nosuch' because it does not exist.
...

Environment data
PowerShell Core v6.0.0-beta.5 on macOS 10.12.6
PowerShell Core v6.0.0-beta.5 on Ubuntu 16.04.3 LTS
PowerShell Core v6.0.0-beta.5 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
Windows PowerShell v5.1.15063.483 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)

Module has its own context. It may be preferable to set the preference variable value for the module
Set-Variable -Module moduleName

Yes, modules have their own scope, which is generally a good thing.
However, this special case calls for a concise, PS-supported way to copy all the preference-variable values from the caller's scope.
(The current workaround of using $PSCmdlet.SessionState.PSVariable  based on a hard-coded list of preference variable names is neither future-proof nor reasonable.)
Consider the user's perspective:
If $ErrorActionPreference = 'Ignore'; Get-Item /NoSuch works,
$ErrorActionPreference = 'Ignore'; Get-MyItem /NoSuch not working, just because the Get-MyItem command happens to be defined as an advanced function in a script module, is highly obscure and confusing.

Main module's function is to isolate code that expose public API and hide implementation. We can get unpredictable behavior if we just copy any variables (and maybe indirectly functions) to a module context.
Also internally there are difference of global and local preference variables.
Preference variables is not protected and can be used other ways:
Remove-Variable ErrorActionPreference
$ErrorActionPreference =@()

We may have problems if these variables are simply copied in a module context.
What scenarios do we need to? It seems it is only debug. If so we could resolve this otherwise,  for example, by loading a module in debug mode. If we want to manage the preference variables in a module, we must do this in a predictable way.
Import-Module testModule -SetErrorActionPreference Stop

Also we have an Issue with request to share modules between runspaces. If we want implement this we can not simply copy any variables - no single parent context exists.

Preference variables is not protected and can be used other ways:

Indeed, but that is (a) incidental to the issue at hand and  (b) should in itself be considered a bug: see  #3483

We can get unpredictable behavior if we just copy any variables (and maybe indirectly functions) to a module context.

We're not talking about any variables. We're talking about the well-defined set of preference variables - even though, as stated, there's currently no programmatic way to enumerate them.

What scenarios do we need to? It seems it is only debug.

Please read the blog post that the original post links to.
Then consider my Get-Item vs. Get-MyItem example.

This is very much a production issue, unrelated to debugging:
Currently, if you create a script module, that module's functions will by default ignore a caller's preferences variables (unless you're calling from the global scope), which to me is self-evidently problematic:
For instance, if a caller sets $ErrorActionPreference to Stop, they have a reasonable expectation that cmdlets / advanced functions invoked subsequently honor that setting - without having to know whether a given command happens to be defined in a script module that doesn't see that setting.

Honoring the callers preference might cause serious problems by introducing exceptions (e.g. $errorActionPreference = 'Stop' in places where none were expected.
Some examples - Dispose might not get called and resources leak, or the system may be left in an inconsistent state because some side effects do not execute.
If the goal is to silence a noisy function - one can work with the function author to provide a better experience or else explicitly pass -ErrorActionPrefernce SilentlyContinue.

I think the focus is too much on the implementation here and not on the problem:  a user shouldn't have to know or care how a particular PowerShell command is implemented.  Whether it's a cmdlet, function, cdxml, imported from a remote session, whatever:  they should have a consistent experience with regard to common parameters and preference variables.  If I put $VerbosePreference = 'Continue' in my script, I should expect to see all the verbose output that I asked for.  If I say $ErrorActionPreference = 'Stop', then anything that bubbles up through the Error stream to my code should cause a terminating error.

Honoring the callers preference might cause serious problems by introducing exceptions (e.g. $errorActionPreference = 'Stop' in places where none were expected.

I don't see this as a problem, since that's exactly what happens if the caller specifies -ErrorAction Stop today.  (Common parameters cause the equivalent preference variables to be set in the advanced function's scope.)

@dlwyatt: Amen to that. I was in the middle of composing the following:
The point is that if compiled cmdlets respect preference variables set in the caller's scope, it's reasonable to expect advanced functions to respect them too - the user shouldn't have to worry about module scopes or how a given command happens to be implemented.
With respect to $ErrorActionPreference = 'Stop': It sounds like using Stop (whether via the pref. variable or the common parameter) is inherently problematic, which is a separate conversation (and I personally wasn't aware that it's problematic - probably worth documenting).
Let's take a more innocuous example: setting $VerbosePreference = 'Continue' in an effort to make all cmdlet invocations in the current script produce verbose output:
The following example defines Get-Foo1 as a compiled cmdlet, and functionally equivalent Get-Foo2 as an advanced function in a module:
Get-Foo1 respects the verbose preference, Get-Foo2 does not.
# Define compiled cmdlet Get-Foo1 (via an in-memory assembly and module).
Add-Type -TypeDefinition @'
    using System;
    using System.Management.Automation;
    [Cmdlet("Get", "Foo1")]
    public class GetFoo1 : PSCmdlet {

        protected override void EndProcessing() {
            WriteVerbose("foo1");
        }
    }
'@ -PassThru | % Assembly | Import-Module

# Define analogous advanced function Get-Foo2 via an in-memory module.
$null = New-Module {
    Function Get-Foo2 {
        [cmdletbinding()]
        param()

        End {
            Write-Verbose("foo2");
        }
    }
}

$VerbosePreference = 'Continue'

# Compiled cmdlet respects $VerbosePreference.
Get-Foo1
# Verbose: foo1

# Advanced function in script module does NOT, because it doesn't see the caller's
# $VerbosePreference variable.
Get-Foo2
# (no output)

Expecting the user to even anticipate a distinction here and to then know which commands are affected based on how they happen to be implemented strikes me as highly obscure.
A scenario in which the behavior is even more obscure is with implicit remoting modules that proxy compiled cmdlets that execute remotely. In that case, the remotely executing cmdlets, even though they normally respect the caller's preference, do not. (On a related note: even -ErrorAction Stop does not work in that scenario, because the parameter is applied remotely, and terminating errors that occur remotely are by design converted to non-terminating ones.)

I don't know what the right solution is, but if we can agree that there is a problem, we can tackle it.

Keep in mind one big difference between binary cmdlets and functions - binary cmdlets are rarely implemented in terms of PowerShell functions or other cmdlets.
The error or verbose output is likely carefully crafted for a binary cmdlet, whereas it's a bit more random for functions.
Also note that the equivalence of -ErrorAction Stop and setting the preference variable could be thought of as an implementation detail and is considered a bug by some people for some of the reasons mentioned above.
It's worth pointing out that extra verbosity is not always desirable - and this proposal could turn some useful verbose output into noisy useless output.

Keep in mind one big difference between binary cmdlets and functions - binary cmdlets are rarely implemented in terms of PowerShell functions or other cmdlets.

Users needing to be aware of how a given command happens to be implemented is an unreasonable expectation.
Aside from that, I don't understand your comment.

The error or verbose output is likely carefully crafted for a binary cmdlet, whereas it's a bit more random for functions.

PowerShell has evolved toward making the PowerShell language a first-class citizen with respect to creating cmdlets (advanced functions).
Someone skilled enough to create advanced functions as part of a module should be assumed to exercise the same care as someone creating a compiled cmdlet.

It's worth pointing out that extra verbosity is not always desirable - and this proposal could turn some useful verbose output into noisy useless output.

If I, as a user, set $VerbosePreference = 'Continue' scope-wide, I expect all commands invoked subsequently to honor that settings; if I didn't want that, I would use -Verbose on a per-command basis.
Note that backward compatibility is a separate discussion - opting in to copying the caller's preference variables is a viable option in that context, perhaps via a new [System.Management.Automation.CmdletBindingAttribute] property such as [CmdletBinding(UseCallerPreferences)].

the equivalence of -ErrorAction Stop and setting the preference variable

Again I don't fully understand your comment; at the risk of going off on a tangent:
They are not equivalent: -ErrorAction Stop only affects non-terminating errors (escalates them to script-terminating errors); $ErrorActionPreference = 'Stop' affects both non-terminating and statement-terminating errors - see Our Error Handling, Ourselves - time to fully understand and properly document PowerShell's error handling.

Users needing to be aware

I think you're emphasizing my point. Users of a command aren't aware of the implementation and do have the expectation of reasonable output.
Command authors are a different story - they need to be aware of the implications of preference variables and parameters like -Verbose in a way that differs from the user.
In some cases, the command author and user are the same, and I do wonder if that's where some of this feedback is coming from - because the command author sometimes wants more help debugging during development.

Users of a command aren't aware of the implementation and do have the expectation of reasonable output.

No argument there. And let's not forget predictable behavior, which brings us to the next point:

I do wonder if that's where some of this feedback is coming from

I can't speak for @dlwyatt, but to me this is all about the user perspective:

I set a preference variable to modify the behavior scope-wide.
I expect commands called from that scope to honor them, just as the standard cmdlets do.

If I can't predict which of the commands I'll invoke will actually honor the preferences, I might as well do without preferences altogether and only use common parameters.
We've covered $VerbosePreference, but let's consider $WhatIfPreference and $ConfirmPreference:
If I set these with the expectations that all commands invoked from the same scope will honor them, I may be in for nasty surprises.
Similarly, to return to $ErrorActionPreference: An approach I've personally used it to set $ErrorActionPreference = 'Stop' at the start of a script as fallback and then handle errors that I anticipate on a per-command basis. That way, unanticipated errors cause the script to abort, as a fail-safe - or so I'd hoped.

Also note that the equivalence of -ErrorAction Stop and setting the preference variable could be thought of as an implementation detail and is considered a bug by some people for some of the reasons mentioned above.

I think I now understand what you're saying, and I hope I'm not wasting my breath based on a misinterpretation:
It sounds like you're conceiving of preference variables as being limited to the current scope only, without affecting its descendant scopes or the potentially completely separate scopes of commands invoked.

By itself, this conception runs counter to how variables work in PowerShell, at least with respect to descendant scopes.
To be consistent with how PS variables work, you'd have to define a variable as $private: in order to limit it to the current scope only.

Certainly, given that core cmdlets currently  do honor the preference variables, changing that behavior - selectively, for preference variables only - would be a serious breaking change and would require a focused effort to reframe the purpose of preference variables.

Leaving the syntax and backward compatibilities issues aside, I can see how some preference variables can be helpful as limited to the current scope:

$DebugPreference and $VerbosePreference only applied to Write-Debug and Write-Verbose commands issued directly  in the current scope could help with debugging only a given script, without being distracted by debug/verbose commands from commands invoked from the current scope.

Again: In the realm of PowerShell variables, that would call for something like $private:VerbosePreference = 'Continue'.  On a side note: that doesn't actually work - descendant scopes still see the value.

However, other preference variables would be rendered meaningless as current-scope-only variables:

What does setting $ErrorActionPreference mean, if it doesn't apply to commands invoked from the current scope? If we believe the current documentation, stating that $ErrorActionPreference applies to non-terminating errors, that would leave no errors to apply the preference to, given that only commands can report non-terminating errors, whereas any other errors (runtime errors such as 1 / 0 or [int]::Parse('foo')) are [statement]-terminating errors, to which the preference allegedly doesn't apply (it does in practice).

I found that specifying $global: addresses this for progress bar issues.
$global:ProgressPreference = 'silentlycontinue'  at the top of a script suppresses the performance killing progress indicator when downloading things.

It seems to me that when considering code inside a script module there are two distinct kinds of code to which preference variables (eg. $ErrorActionPreference, etc) and common parameters (eg. -ErrorAction, etc) might apply:

business logic implemented within the module

The cause of errors arising from such code are bugs (ie. "boneheaded" errors per Eric Lippert's taxonomy).  Accordingly, such code should be run with $ErrorActionPreference='Stop'.
Deciding the conditions for and quantity of verbose messages output from the business logic requires the good judgment of the module author.  This probably involves careful consideration of what should happen when the module is called with the different values of $VerbosePreference and -Verbose at the call site of module entry points.
$DebugPreference, $WarningPreference, and $InformationPreference for such code should probably be the PowerShell defaults regardless of what the caller's values of those variable are.

calls made to outside the module

Such code is subject to all sorts of untidy unpredictable external realities that cause errors (Eric Lippert calls these "exogenous").  The user of the module should be the party deciding what to do when such an error arises.  Accordingly,
the value of common parameters and preference variables for such calls should be the same as they were at the call site of the entry point to the module.

The above points aren't hard and fast, but I think they're a reasonable starting point for most modules involving a mix of business logic and calls made to outside the module.  PowerShell, of course, does not behave this way by default.  To implement a module that is consistent with the above points requires two things to happen as follows:

Capture preference variables and common parameters at the call site of the entry point to the module.
Apply those preference variables and common parameters to the calls made to outside the module.

I suspect that these tasks can be handled reasonably well by a utility module.  I wrote an annotated proof-of-concept of such a module.  The entry points to a user module that uses the utility module would look, for example, like this:
function Get-MyItem {
    param(
        [Parameter(Position=1)] $Path
    )
    HonorCallerPrefs {
        Get-MyItemImpl $Path
    }
}

function New-MyItem {
    param(
        [Parameter(Position=1)] $Path,
        [switch]                $WhatIf,
        [switch]                $Confirm
    )
    HonorCallerPrefs {
        New-MyItemImpl $Path
    }
}

The corresponding sites that call out of the user module would look like this:
InvokeWithCallerPrefs {
    Get-Item $path @CallerCommonArgs
}

InvokeWithCallerPrefs {
    New-Item $path @CallerCommonArgs
}

HonorCallerPrefs{} and InvokeWithCallerPrefs{} are implemented by the utility module and capture and apply the preference variables and common parameters, respectively.  The concept should work even if the call stack between HonorCallerPrefs{} and InvokeWithCallerPrefs{} is deep and complicated, as long as they are in the same module.

This issue seems stalled, but it's such an important one, and with the upcoming PowerShell 7.0 milestone it would be really, really great if people put their heads together and come up with a model that makes sense for the caller, has the right default behavior, and that gives the developer the flexibility they need to override the default behavior if necessary.

Agreed. If we can come to a conclusion on this it would be great to get a more consistent model in place.

We could move forward if we created examples of the desired behavior in the form of Perter tests.

The expectation from my POV is that caller preferences that do not affect the script or module execution paths are replicated out to every script or module that gets involved, as a default, without having to opt-in (other than [CmdletBinding()] ofc).
This would be things like Verbose, Debug, Information, and Progress, but not something like ErrorActionPreference, PSEmailServer, or ModuleAutoLoadingPreference.

I just read through this discussion again, taking some more time this time around to catch all of the details, and I think it's worth summing up some key points, as follows:

To an end user who is not a command author, a function, advanced function, filter, cmdlet, and alias, and even a script discoverable via $env:Path that is invoked by name, are all just commands.
End users should never have to care what type of command they invoke, and any scripts they write should function the same regardless of the type of command they invoke.
If a command author decides to convert a cmdlet into an advanced function, or vice versa, as long as that author can perform a perfect conversion of the functionality within the command, they should be able to do so without having to worry about existing scripts that directly or indirectly call that command behaving differently just because they changed the way that command was implemented.

With this issue as it exists today, only the first item in that list is true, and that is a problem that leads to non-intuitive behavior at best and bugs that cannot be easily worked around without duplicating a lot of code at worst.
When it comes to preference variables, I strongly feel that all preferences that can be influenced by common parameters (Error, Warning, Information, Verbose, Debug, Progress, Confirm, and WhatIf) need to be carried through the entire invocation of a command, end to end, regardless of what other commands are invoked internally as part of that process. That means a few things:

End users get a declarative syntax for every command they invoke. If they invoke with -Verbose, they should get all verbose messages that the command author intended them to get. Ditto with -Debug, but for debug messages. And if they use any of the -*Action common parameters, that action needs to apply to everything done internally in that command and in any commands invoked internally within that command according to how the author intentionally wrote the command.

Command authors need features that allow them to control the volume of output sent to various streams, as well as features that allow them to silence or ignore certain messages or errors. They have this already. The behavior of -Debug has very recently changed such that users are no longer prompted when messages are sent to the debug stream, so now command authors have two levels of output for troubleshooting-type messages. This gives command authors more flexibility over the volume of output to specific message streams (they no longer just have the verbose stream to realistically work with). Similarly they have common parameters and preference variables to control other message streams and error handling in the commands that they invoke.

Part of the discussion here suggests that it may be detrimental to carry through these preferences -- that users may receive too much verbose output, for example. What is/is not too much output from a command, regardless of which stream it is sent to, is a decision that must be made by the command author, intentionally, not incidentally. Command authors can turn verbose/debug output off for other commands that they invoke, if they feel that information is not helpful/relevant to the caller. They can also silence or ignore errors, warnings, or information messages in commands that they invoke, regardless of how their command is being invoked. The decision on what to allow to pass through or not needs to be a conscious one, not accidental, made by the command author. It should never have been something that a caller should concern themselves with by having to pay attention to the nuances associated with type of command they are invoking and the way that command was loaded.
It is also worth pointing out how we got here, and some relevant changes, because that information may lead to a solution to this problem. We've had common parameters and preference variables in PowerShell since v1 was released in 2006. When PowerShell v2 came out in 2009, the PowerShell Team added modules (along with the scoping they have today that contributes to this problem because of how all variables, including preference variables, are only accessible in nested scopes), as well as the addition of the largely underused $PSDefaultParameterValues feature, which allows users to assign default values to be used for parameters on commands that are invoked. While the globally visible $PSDefaultParameterValues variable was initially accessible from modules (which caused problems because $PSDefaultParameterValues is meant to be a user convenience for commands users invoke ad hoc or in scripts, but its use was also impacting commands used within module internals), in PowerShell v5, modules received their own $PSDefaultParameterValues so that module commands could run as they were designed without this user convenience getting in the way.
What's most interesting about $PSDefaultParameterValues with respect to this issue is that the values it contains impact the parameters (not variables) used in the invocation of all commands in its scope and any child scope. What if $*Preference variables continued to function as they do today (current scope plus child scopes unless they are redefined), but when a command is invoked using common parameters to control the various streams and how errors should be handled would not only assign the locally-scoped $*Preference variable, but would also result in assignment of corresponding default parameter values in a locally-scoped $PSDefaultParameterValues hashtable, such that any command invoked within that command would automatically be invoked with the same common parameter values.
For example, consider this script:
# First, create two modules, where a command in one module invokes a command in the other
nmo -name test1 {
    function Test-1 {
        [cmdletBinding()]
        param()
        Test-2
    }
} | ipmo
nmo -name test2 {
    function Test-2 {
        [cmdletBinding()]
        param()
        Write-Verbose 'Verbose output'
    }
} | ipmo

# The next command shows verbose output, as expected
Test-2 -Verbose

# Output: VERBOSE: Verbose output

# This command does not show verbose output, because of the design flaw identified in this GitHub issue
Test-1 -Verbose

# Output: none

# Now let's redefine the test1 module, with some extra logic to assign a locally-scoped PSDefaultParameterValues hashtable based on the Verbose common parameter
nmo -name test1 {
    function Test-1 {
        [cmdletBinding()]
        param()
        $PSDefaultParameterValues = @{'*:Verbose' = ($VerbosePreference -eq 'Continue')} # The magic
        Test-2
    }
} | ipmo

# Now this works, because of PSDefaultParameterValues impact on common parameters
Test-1 -Verbose

# Output: VERBOSE: Verbose output

As you can see, if we maintain the current scope visibility on preference variables, but apply a locally-scoped PSDefaultParameterValues collection based on common parameters, then we get commands whose internal behavior is end-to-end as a default, resolving this issue. Command/script authors who are assigning preference variables that are not globally scoped in hopes that they will get this behavior will be provided with a solution that allows them to get this more desirable functionality, and rules can be created for PowerShell Script Analyzer to catch these variable assignments and recommend how users should work with a locally scoped PSDefaultParameterValues collection instead.
Simple, right? :smile:

Thinking about the last paragraph in my previous comment a little more, I'm inclined to push for the following to address this (and yes, I'll log this as a separate issue):
Any ShouldProcess command that works with PowerShell entities in the current scope (e.g. any of the following commands invoked without -Scope: Clear-Variable, New-Variable, Set-Variable, Remove-Variable, Import-Alias, New-Alias, Set-Alias, along with any of their corresponding New-Item, Set-Item, or Remove-Item commands) should run without checking $PSCmdlet.ShouldProcess. i.e. If -Scope is not used, or if -Scope is 0, just do it regardless of WhatIf or Confirm preferences. Local scope operations for these commands should be considered safe, because they have no bearing on any parent scopes whatsoever, and are therefore non-destructive. This model should be followed for any command that supports ShouldProcess for both actions that may be destructive as well as actions that are non-destructive -- just because ShouldProcess is supported in the command, doesn't mean it should be the gatekeeper to all actions taken by that command.
This creates an exception, but one worth having because some commands should only cause WhatIf or Confirm to change how they run some of the time. For example, there are cases where you want to create a set of variables with dynamic names in a loop without ShouldProcess preferences getting in the way of invocation, and while you can do this using APIs, it should be possible to do this using cmdlets since that's what they are for. End users shouldn't have to learn by trial and error which one they should be using -- the cmdlets should just do the right thing.
If that gets accepted, then the last paragraph in my previous post in this discussion becomes a non-issue.

FYI, I opened a set of RFCs to address error handling issues in PowerShell, this one included. If you're keen and you don't want to wait for the RFCs to reach the draft stage, you can find the PR with those RFCs here.

@nacitar You can leave a feedback in RFC https://github.com/PowerShell/PowerShell-RFC/pull/221

For anyone who has tripped on this issue and is following this discussion, please do share your feedback in https://github.com/PowerShell/PowerShell-RFC/pull/221. That PR, the way it is currently written, talks about adopting optional features in PowerShell (described in another RFC: https://github.com/PowerShell/PowerShell-RFC/pull/220).
There is some pushback on the optional feature idea because it requires time/resources to properly manage, and it may be too risky to be worth it to the PowerShell Team (see discussion in optional features RFC), in which case you need to ask yourself: is the current problem with how execution preferences do not propagate beyond module or script scope worth fixing even if it may result in breaking changes?
Breaking changes may occur because you would be changing how execution preferences influence existing code without specifically testing that code to make sure that it still works as intended.
From my perspective, I think it is worth it, because the current behavior is the root cause of many issues that show up in different modules. If folks agree, and if the optional feature idea is officially rejected, I can at least set up an experimental feature (these are different from optional features) to allow folks to try it out with their modules and make sure things still work the way they intended with execution preferences properly propagating beyond module or script scope.

I assume this behavior is the root of the issue where ShouldProcess doesn't do verbose output even if VerbosePreference is set? Or should this be a separate issue?
function Test-Whatif {
    [CmdletBinding(SupportsShouldProcess)]
    param (
        $String = 'Thing to do'
    )
    $target = 'Thing to Target'
    $VerbosePreference ='continue'
    if ($PSCmdlet.ShouldProcess($target,$string)){
        "Did $string to $target"
    }
}

Couldn't say off the top of my head, but given that you're setting $VerbosePreference immediately before it, I would be inclined to say that it's likely a separate issue, something to do with how WhatIf only see verbose set by the switch and not an in-session variable.

Sorry if this has already been mentioned, but this thread is quite long so I mostly just skimmed it.
I believe there isn't a single "right answer" here:
For $ErrorActionPreference, I personally use
Set-StrictMode -Version Latest
$ErrorActionPreference = "Stop"

as a header in every module I write, because I want to fail hard when an unhandled error occurs, and my code is written with this in mind. So just blindly copying the variable from caller scope is imo not a good approach, because scripts that do not declare the variable themselves will work differently in different sessions.
For output level preference variables ($VerbosePreference, $InformationPreference,...), I think the current situation where the output is controlled in each scope separately (so the effective output is the minimum of all set preference variables in all scopes the output passes through) is quite nice and I'd like to keep it both as a module writer and a user.

@MatejKafka: There are two separate aspects, which are independent of one another:

Designing your module so that it reports the appropriate type of error, based on the official guidelines, summarized here (by me). The same applies to using the other output streams, such as the one for verbose output.

Respecting the caller's preference variables so as to modify the module's default behavior on demand. For that, there's no justification for distinguishing between (a) functions (and scripts) outside a module scope, (b) functions inside a module, and (c) cmdlets.

(a) and (c) properly respect the caller's preferences, whereas (b) doesn't. This distinction doesn't make sense, and no user should ever have to think about the implementation details of a given command, i.e. whether they happen to be implemented as (a), (b), or (c).

@mklement0 I agree that the behavior being inconsistent is an issue, but it seems we partially disagree in which direction they should be unified.
Ad 1) - I'm more of a programmer than sysadmin - the concept of a non-terminating error seems like something terrifying to me - an error occurred, meaning that something bad happened and I did not correctly anticipate it and handle it, and the program is in an undefined state. Continuing ahead instead of panicking is imo irresponsible, as I cannot safely reason about the behavior of my own program. Non-terminating error should imo either be a terminating error, or a warning, not a weird mix of both.
I also edited my previous comment, as I found out that my assumption in the last paragraph aren't correct.

the concept of a non-terminating error seems like something terrifying to me

It shouldn't do. There's a difference between errors and exceptions.  Whether an error is "exceptional" depends on the context.  If you've correctly functionally decomposed your code into a series of small pipeline functions each function by itself can't determine if an error is an exception, because it can't own that policy because it doesn't know why it's being called.  Errors from that function should bubble through the pipeline to the creator of the pipeline who can, in that context, determine whether the error is exceptional in that context/pipeline.

As a general rule, non-terminating errors tend to be something that comes from an individual object input in the pipeline. If one bad piece of data is received, you don't necessarily want to cancel processing the next 10,000 bits of input. On the other hand, if the error comes from bad / unusable input as the result of a fixed (non-pipeline) parameter input, you can deduce that processing all 10,000 bits of input will yield with the same result (say, for example, the cmldet requires authentication, and the authentication provider you're using indicates that the credentials specified are invalid) -- then you can throw a terminating error to avoid wasting time trying the known-bad credentials 10,000 times.

I would prefer we do not use this Issue to discuss/debate PowerShell's error handling models. There are existing Issues you can pile onto, or start a new one.

Having just fallen foul of this one myself, a good-enough syntax (for me), as an occasional AF-author would simply be...
Get-Variable -Preference | Set-Variable -Scope Local

...where -Preference was a new switch added to Get-Variable which limited the output of that command to the known preference variables and supplied the correctly-resolved value for whatever the current scope intended, apropos of any magic that might apply to that preference variable.
I think the intent of such a call would be clear and idiomatic, and—given -Preference doesn't exist yet—shouldn't break any backward compatibility, but I've of course only spent a minimal amount of time looking into it, so I am sure there are all manner of cases that I am not considering.  I don't think it requires alteration to Set-Variable, since both -Name and -Value accept the pipeline input that Get-Variable outputs, and -Scope does not.
I suppose it might be open to global scope abuse (but, surely so is $global:*Preference, so I'm not going to lose sleep over it).

I hit this problem writing my first module. I'm going to revert back to sourcing scripts directly (. .\foo.ps1), and not use advanced-function modules going forward.
9+ years for a problem of this impact seems like a long time. Are advanced-function modules considered second-class citizens in PowerShell? Are developers writing binary modules instead? Or is there just very little developer involvement at the module level in general?

@mc-ganduron most likely the issue is complexity of implementation vs. relatively easy workarounds (passing the preference thru to child functions).
I would say abandoning advanced functions for just this is a little dramatic don't you think?

I would say abandoning advanced functions for just this is a little dramatic don't you think?

Not at all. First, I have a prior solution available with no workarounds required (sourcing scripts directly). Second, it's reasonable to take first impressions into account. My first experience with advanced-function modules led me to a 9+ year-old bug. I'm not willing to march ahead into other old bugs when I have options available, within PowerShell and without.

I'm not willing to march ahead into other old bugs when I have options available

@mc-ganduron  - All software has bugs. Lots of them are old. This one bothered me as well until the day I was troubleshooting a problem with my module and I only wanted to have verbose output from my module and did not want all of the verbose output noise from all of the other modules and functions my module called. This current way does not seem as convenient or consistent at first, but it does represent an "opt-in" style choice that is more useful than opting out for many troubleshooting scenarios.

Actually I noticed that for errors $PSCmdlet.ThrowTerminatingError() works exactly like compiled cmdlet and honor the caller's preference:
$null = New-Module {
    $ErrorActionPreference = 'Stop'
    function Foo {
        [CmdletBinding()] param()
        trap { $PSCmdlet.ThrowTerminatingError($_) }
        Get-Item /Nosuch
    }
}

$ErrorActionPreference = 'SilentlyContinue'
Foo

I think that it's the most reliable way to handle errors from modules.
I wish the default behavior was like the example above without needing to re-throw the errors. And maybe a way to do the same thing for streams other then errors.

I do wish the syntax for $PSCmdlet.WriteError and ThrowTerminating error was more terse, it looks like black magic when it really should be the way to do it, something like throwUser keyword.

I have been scratching my head for months why I didn't get my Debug, Verbose and Information messages in my output when calling Functions in Modules. It's funny when they advise us to move from Write-Host to Write-Information and then make InformationPreference SilentlyContinue the default.
By accident I found this thread and I now prefix DebugPreference, VerbosePreference and InformationPreference with $Global and suddenly I get everything I've been missing, all the feedback I had programmed into my functions but could only see when running from my local system.
So this is absolutely still a thing on PowerShell 7, Mr. Bot.

This is so ugly.  I want my debug messages and have no problem getting them.  Somehow a module gets the preference.  I try as I might to disable the module messages, but to no avail.  I don't know if it's the module code trying to get the preference via some tricky means because of this issue or something else.  Really, perhaps leave this as version 1 of messaging and create a completely new implementation.  And make the new implementation easy to use.  A transcript option would be nice if we don't want to liter code with write-debug when we want to see everything.  A message level instead many preferences.  Multiple targets.  Bite the bullet and think of something both easy and useful.  Don't make it so we are stuck with backward compatible horrors.

I don't remember how many ways I tried to suppress module debug messages without suppressing mine.  (I'm debugging my code, not the modules.)  Here is another attempt that seems to work.  (I'm holding my breath.)
In the function I define a private set of preference variables if they are different from the desired module preferences.  The function will use the private set.  A global set of preferences are defined - after the private set is defined - with the desired module preferences.  Before exiting the function, the global values are returned to their original values.  I'm experienced with PowerShell, but I in no way consider myself an expert.  This seems fragile and clunky.  Constructive criticism very welcome.  (If you don't think I know what I'm doing, that probably makes two of us.)
function Set-StandardDatabaseMail {
    [CmdletBinding(SupportsShouldProcess, ConfirmImpact = "Low")]
    param (
        [parameter(Mandatory, ValueFromPipeline)]
        [string[]]$SqlInstance,
        [PSCredential]$SqlCredential,
        [switch]$Force
    )

    begin {

        $fnName = $PSCmdlet.MyInvocation.MyCommand.Name

        Write-Debug ('[{0}] BEGIN enter' -f $fnName)

        if (-not $PSBoundParameters.ContainsKey('Debug')) {
            $DebugPreference = $PSCmdlet.SessionState.PSVariable.GetValue('DebugPreference')
        }
        Write-Debug ('[{0}] $DebugPreference={1}' -f $fnName, $DebugPreference)

        if (-not $PSBoundParameters.ContainsKey('Verbose')) {
            $VerbosePreference = $PSCmdlet.SessionState.PSVariable.GetValue('VerbosePreference')
        }
        Write-Debug ('[{0}] $VerbosePreference={1}' -f $fnName, $VerbosePreference)

        if (-not $PSBoundParameters.ContainsKey('InformationAction')) {
            $InformationPreference = $PSCmdlet.SessionState.PSVariable.GetValue('InformationPreference')
        }
        Write-Debug ('[{0}] $InformationPreference={1}' -f $fnName, $InformationPreference)

        if ($Force -and -not $Confirm){ # Force disables confirm unless the user explicitly requested it
            $ConfirmPreference = 'None'
            Write-Debug ('[{0}] $ConfirmPreference={1} (Force)' -f $fnName, $ConfirmPreference)
        } else {
            if (-not $PSBoundParameters.ContainsKey('Confirm')) {
                $ConfirmPreference = $PSCmdlet.SessionState.PSVariable.GetValue('ConfirmPreference')
            }
            Write-Debug ('[{0}] $ConfirmPreference={1}' -f $fnName, $ConfirmPreference)
        }

        if (-not $PSBoundParameters.ContainsKey('WhatIf')) {
            $WhatIfPreference = $PSCmdlet.SessionState.PSVariable.GetValue('WhatIfPreference')
        }
        Write-Debug ('[{0}] $WhatIfPreference={1}' -f $fnName, $WhatIfPreference)

        $moduleDebugPreference = 'SilentlyContinue' # for the DBATools module
        Write-Debug ('[{0}] $moduleDebugPreference={1}' -f $fnName, $moduleDebugPreference)

        $moduleVerbosePreference = 'SilentlyContinue' # for the DBATools module
        Write-Debug ('[{0}] $moduleVerbosePreference={1}' -f $fnName, $moduleVerbosePreference)

        # hack custom module preferences

        if ($moduleDebugPreference -ne $DebugPreference) {
            $private:DebugPreference = $DebugPreference
            $global:DebugPreference = $moduleDebugPreference
            Write-Debug ('[{0}] $DebugPreference={1}' -f $fnName, $DebugPreference)
            Write-Debug ('[{0}] $private:DebugPreference={1}' -f $fnName, $private:DebugPreference)
            Write-Debug ('[{0}] $global:DebugPreference={1}' -f $fnName, $global:DebugPreference)
        }

        if ($moduleVerbosePreference -ne $DebugPreference) {
            $private:VerbosePreference = $VerbosePreference
            $global:VerbosePreference = $moduleVerbosePreference
            Write-Debug ('[{0}] $VerbosePreference={1}' -f $fnName, $VerbosePreference)
            Write-Debug ('[{0}] $private:VerbosePreference={1}' -f $fnName, $private:VerbosePreference)
            Write-Debug ('[{0}] $global:VerbosePreference={1}' -f $fnName, $global:VerbosePreference)
        }

    }

    process {

        Write-Debug ('[{0}] PROCESS enter' -f $fnName)

        # The DBA team uses the same settings, account, and profile for email alerts
        # related to database maintenance on each instance.  Those values that depend upon
        # instance name will follow the same pattern.

        $accountName = 'MailAccountName'
        $description = 'Mail account for SMTP e-mail.'
        $emailDomain = 'ouremaildomain.gov'
        $mailServer = 'oursmptserverfqdn'
        $useDefaultCredentials = $true # use the service account to access the mail server

        Write-Debug ('[{0}] $accountName={1}' -f $fnName, $accountName)
        Write-Debug ('[{0}] $description={1}' -f $fnName, $description)
        Write-Debug ('[{0}] $emailDomain={1}' -f $fnName, $emailDomain)
        Write-Debug ('[{0}] $mailServer={1}' -f $fnName, $mailServer)
        Write-Debug ('[{0}] $useDefaultCredentials={1}' -f $fnName, $useDefaultCredentials)

        foreach ($instance in $SqlInstance) {

            # We need to create a compatible display name and email address from the server name
            # that does not have a backslash.  If a FQDN is provided, the domain part is removed.

            $computerName = $instance.split('\',2)[0].split('.',2)[0].ToUpper()
            $instanceName = $instance.split('\', 2)[1].ToUpper()

            Write-Debug ('[{0}] $computerName={1}' -f $fnName, $computerName)
            Write-Debug ('[{0}] $instanceName={1}' -f $fnName, $instanceName)

            if ($instanceName) {
                $instanceShort = $computerName + '\' + $instanceName
            } else {
                $instanceShort = $computerName
            }

            Write-Debug ('[{0}] $instanceShort={1}' -f $fnName, $instanceShort)

            $accountSplat = @{
                'Account' = $accountName
                'DisplayName' = $instanceShort
                'Description' = $description
                'EmailAddress' = $instanceShort.replace('\', '_').ToLower() + '@' + $emailDomain
                'ReplyToAddress' = 'do_not_reply@' + $emailDomain
                'MailServer' = $mailServer
            }

            Write-Debug ('[{0}] $accountSplat.EmailAddress={1}' -f $fnName, $accountSplat.EmailAddress)
            Write-Debug ('[{0}] $accountSplat.ReplyToAddress={1}' -f $fnName, $accountSplat.ReplyToAddress)

            try {
                $account = Get-DbaDbMailAccount -SqlInstance $instance -Account $accountSplat.Account -EnableException
            }
            catch {
                Write-Warning ('[{0}] {1} : Failed to access db mail account {2}' -f $fnName, $instanceShort, $accountName)
                Continue
            }

            # Create the account if it does not exist; otherwise, check if it needs updated.

            if (-not $account) {
                if( $PSCmdlet.ShouldProcess($instance, "Creating new db mail account called $accountName") ) {

                    try {
                        $account = New-DbaDbMailAccount -SqlInstance $sqlInstance @accountSplat -WhatIf:$WhatIfPreference -Confirm:$false
                        }
                    catch {
                        Write-Warning ('[{0}] {1} : Failed to create db mail account {2}' -f $fnName, $instanceShort, $accountName)
                        Continue
                    }

                    $account.DisplayName = $accountSplat.DisplayName
                    $account.Description = $accountSplat.Description
                    $account.EmailAddress = $accountSplat.EmailAddress
                    $account.ReplyToAddress = $accountSplat.ReplyToAddress
                    $account.MailServers[0].Name = $accountSplat.MailServer
                    $account.MailServers[0].UseDefaultCredentials = $useDefaultCredentials
                    $account.Alter() # saves all changes to sql instance
                    Write-Information ('[{0}] {1}-{2} : Account Created' -f $fnName, $instanceShort, $accountName)
                }

            } else {

                $accountDirty = $false

                if ($account.DisplayName -ne $accountSplat.DisplayName) {
                    $oldDisplayName = $account.DisplayName
                    $account.DisplayName = $accountSplat.DisplayName
                    $accountDirty = $true
                    Write-Verbose ('[{0}] {1}-{2}-DisplayName : {3} -> {4}' -f $fnName, $instanceShort, $accountName, $oldDisplayName, $account.DisplayName)
                }

                if ($account.Description -ne $accountSplat.Description) {
                    $oldDescription = $account.Description
                    $account.Description = $accountSplat.Description
                    $accountDirty = $true
                    Write-Verbose ('[{0}] {1}-{2}-Description : {3} -> {4}' -f $fnName, $instanceShort, $accountName, $oldDescription, $account.Description)
                }

                if ($account.EmailAddress -ne $accountSplat.EmailAddress) {
                    $oldEmailAddress = $account.EmailAddress
                    $account.EmailAddress = $accountSplat.EmailAddress
                    $accountDirty = $true
                    Write-Verbose ('[{0}] {1}-{2}-EmailAddress : {3} -> {4}' -f $fnName, $instanceShort, $accountName, $oldEmailAddress, $account.EmailAddress)
                }

                if ($account.ReplyToAddress -ne $accountSplat.ReplyToAddress) {
                    $oldReplyToAddress = $account.ReplyToAddress
                    $account.ReplyToAddress = $accountSplat.ReplyToAddress
                    $accountDirty = $true
                    Write-Verbose ('[{0}] {1}-{2}-ReplyToAddress : {3} -> {4}' -f $fnName, $instanceShort, $accountName, $oldReplyToAddress, $account.ReplyToAddress)
                }

                if ($account.MailServers[0].Name -ne $accountSplat.MailServer) {
                    $oldMailServer = $account.MailServers[0].Name
                    $account.MailServers[0].Name = $accountSplat.MailServer
                    $accountDirty = $true
                    Write-Verbose ('[{0}] {1}-{2}-MailServer : {3} -> {4}' -f $fnName, $instanceShort, $accountName, $oldMailServer, $account.MailServers[0].Name)
                }

                if ($account.MailServers[0].UseDefaultCredentials -ne $useDefaultCredentials) {
                    $oldUseDefaultCredentials = $account.MailServers[0].UseDefaultCredentials
                    $account.MailServers[0].UseDefaultCredentials = $useDefaultCredentials
                    $accountDirty = $true
                    Write-Verbose ('[{0}] {1}-{2}-UseDefaultCredentials : {3} -> {4}' -f $fnName, $instanceShort, $accountName, $oldUseDefaultCredentials, $account.MailServers[0].UseDefaultCredentials)
                }

                if ($accountDirty -and $PSCmdlet.ShouldProcess($instance, "Saving changes to db mail account $accountName")) {
                    $account.Alter() # save all changes to sql instance
                    Write-Information ('[{0}] {1}-{2} : Account Updated' -f $fnName, $instanceShort, $accountName)
                }

            }

        }
    }

    end {

        # un-hack custom module preferences

        if ($global:DebugPreference -ne $private:DebugPreference) {
            $global:DebugPreference = $private:DebugPreference
            Write-Debug ('[{0}] $global:DebugPreference={1}' -f $fnName, $global:DebugPreference)
        }

        if ($global:VerbosePreference -ne $private:DebugPreference) {
            $global:VerbosePreference = $private:VerbosePreference
            Write-Debug ('[{0}] $global:VerbosePreference={1}' -f $fnName, $global:VerbosePreference)
        }

        Write-Debug ('[{0}] END' -f $fnName)
    }

}

$DebugPreference = 'Continue'
$VerbosePreference = 'Continue'
Set-StandardDatabaseMail -SqlInstance XXX -WhatIf -InformationAction Continue

DEBUG: [Set-StandardDatabaseMail] BEGIN enter
DEBUG: [Set-StandardDatabaseMail] $DebugPreference=Continue
DEBUG: [Set-StandardDatabaseMail] $VerbosePreference=Continue
DEBUG: [Set-StandardDatabaseMail] $InformationPreference=Continue
DEBUG: [Set-StandardDatabaseMail] $ConfirmPreference=High
DEBUG: [Set-StandardDatabaseMail] $WhatIfPreference=True
DEBUG: [Set-StandardDatabaseMail] $moduleDebugPreference=SilentlyContinue
DEBUG: [Set-StandardDatabaseMail] $moduleVerbosePreference=SilentlyContinue
DEBUG: [Set-StandardDatabaseMail] $DebugPreference=Continue
DEBUG: [Set-StandardDatabaseMail] $private:DebugPreference=Continue
DEBUG: [Set-StandardDatabaseMail] $global:DebugPreference=SilentlyContinue
DEBUG: [Set-StandardDatabaseMail] $VerbosePreference=Continue
DEBUG: [Set-StandardDatabaseMail] $private:VerbosePreference=Continue
DEBUG: [Set-StandardDatabaseMail] $global:VerbosePreference=SilentlyContinue
DEBUG: [Set-StandardDatabaseMail] PROCESS enter
DEBUG: [Set-StandardDatabaseMail] $accountName=xxx
DEBUG: [Set-StandardDatabaseMail] $description=Mail account for SMTP e-mail.
DEBUG: [Set-StandardDatabaseMail] $emailDomain=xxx
DEBUG: [Set-StandardDatabaseMail] $mailServer=xxx
DEBUG: [Set-StandardDatabaseMail] $useDefaultCredentials=True
DEBUG: [Set-StandardDatabaseMail] $computerName=xxx
DEBUG: [Set-StandardDatabaseMail] $instanceName=xxx
DEBUG: [Set-StandardDatabaseMail] $instanceShort=xxx
DEBUG: [Set-StandardDatabaseMail] $accountSplat.EmailAddress=xxx
DEBUG: [Set-StandardDatabaseMail] $accountSplat.ReplyToAddress=xxx
VERBOSE: [Set-StandardDatabaseMail] SQLTEST16\DEV-Conference-EmailAddress : xxx -> yyy
VERBOSE: [Set-StandardDatabaseMail] SQLTEST16\DEV-Conference-ReplyToAddress : xxx -> yyy
What if: Performing the operation "Saving changes to db mail account xxx" on target "xxx".
DEBUG: [Set-StandardDatabaseMail] $global:DebugPreference=Continue
DEBUG: [Set-StandardDatabaseMail] $global:VerbosePreference=Continue
DEBUG: [Set-StandardDatabaseMail] END

Note: The function is incomplete.  My desire is to run the function and magically check or set the complete database mail configuration on 50-100 SQL instances to conform to standards.
In my opinion, if it's very hard to find a good template or pattern for solving a problem, the tool likely has an issue.  This is the case for T-SQL and stored procedures.  Perhaps PowerShell is not as bad, but I'm not so sure in this case.
Also, common problems such as displaying values for debug could have a common template.  I'm not fond of trying to create a format for messages.  Wish there was an expertly defined format that provided natively.

Please reopen this.  Looks like the bot closed it.  (Sweeping it under the carpet?)

After that lengthy example, I have to wonder if all I needed to do was like below.  In this case Set-StandardDatabaseMail would not have the "hack" code to set the private and global preference values.  I don't know if it would handle Debug or Verbose switches as desired.  I wish I knew the right way to handle this.  If there is no fix, then perhaps a detailed document that explains how we should handle this?
$private:DebugPreference = 'Continue'
$private:VerbosePreference = 'Continue'
$global:DebugPreference = 'SilentlyContinue'
$global:VerbosePreference = 'SilentlyContinue'

Set-StandardDatabaseMail -SqlInstance XXX -WhatIf -InformationAction Continue

If I was using several modules and want to control them individually, this could become very cumbersome.  Should preference variables be private by default scoped by fn and module?

There might be an easy workaround if a related VSCode "bug/feature" is fixed/added.
https://github.com/PowerShell/vscode-powershell/issues/4327
VSCode dot sources scripts when run in the development environment using F5, so there is no separate script scope. However, when running from the command line, it is possible to not dot source. PowerShell ISE also dot sources scripts, so VSCode is consistent - for good or bad. There does not seem to be a direct way to test not dot-sourcing via VSCode and F5. (Is VSCode is forcing dot sourcing as a best practice by not allowing otherwise?)
If dot sourcing can be avoided, the global scope can be reserved for modules while script scope can be used for user script. Then the module preference "firewall" can be useful - even if still wonky. (Introducing a bad practice to compensate for issues controlling module preferences?)
Another consideration - must scripts work by design for both dot sourced or not dot sourced use?  Perhaps there should be a script level "requires" to force the correct loading of the script?  Or perhaps some variables can be forced into a script scope even if the script is dot sourced?
Anyway, here is a test script.  It demonstrates that running code in VSCode/ISE produces different results from the same code run without dot sourcing.
$hostDescription = (Get-Host).ForEach({'{0} - {1}' -f $_.Name, $_.Version})

Write-Host "Host : $hostDescription"

$commandOrigin = $MyInvocation.CommandOrigin

Write-Host ( 'Command Origin : {0} ({1})' -f $commandOrigin, $(if ($commandOrigin -eq 'internal') {'dot sourced?'} else {'not dot sourced?'}) )

$cmd = $PSCommandPath # blank if F8
if ( -not $cmd -and $script:psEditor ) { $cmd = $script:psEditor.GetEditorContext().CurrentFile.Path } # F8 friendly
if ( -not $cmd -and $script:psISE ) { $cmd = $script:psISE.CurrentFile.FullPath } # F8 friendly if stuck with PS ISE because of a .Net Core clash

Write-Host "Command : $cmd"

$scriptName = $MyInvocation.MyCommand.Name # name of the running command or script

Write-Host "Script Name : $scriptName"

$DebugPreference = 'Continue'
$global:DebugPreference = 'SilentlyContinue' # last update wins if global is local

Write-Host ('[{0}] $global:DebugPreference={1}' -f $scriptName, $global:DebugPreference)
Write-Host ('[{0}] $script:DebugPreference={1}' -f $scriptName, $script:DebugPreference)
Write-Host ('[{0}] $local:DebugPreference={1}' -f $scriptName, $local:DebugPreference)
Write-Host ('[{0}] $DebugPreference={1}' -f $scriptName, $DebugPreference)

function Test-ScriptScope {
    $fnName = $MyInvocation.MyCommand.Name # name of the running command or script
    Write-Host ('[{0}] $global:DebugPreference={1}' -f $fnName, $global:DebugPreference)
    Write-Host ('[{0}] $script:DebugPreference={1}' -f $fnName, $script:DebugPreference)
    Write-Host ('[{0}] $local:DebugPreference={1}' -f $fnName, $local:DebugPreference)
    Write-Host ('[{0}] $DebugPreference={1}' -f $fnName, $DebugPreference)
}

Test-ScriptScope

The first two results show that both VSCode and Windows PowerShell ISE dot source by default when run.  Note: the script file is open and run via F5.
Host : Visual Studio Code Host - 2023.8.0
Command Origin : Internal (dot sourced?)
Command : C:\Users\xxx\Documents\GitHub\sql-server-maintenance\Test-ScriptScope.ps1
Script Name : Test-ScriptScope.ps1
[Test-ScriptScope.ps1] $global:DebugPreference=SilentlyContinue
[Test-ScriptScope.ps1] $script:DebugPreference=SilentlyContinue
[Test-ScriptScope.ps1] $local:DebugPreference=SilentlyContinue
[Test-ScriptScope.ps1] $DebugPreference=SilentlyContinue
[Test-ScriptScope] $global:DebugPreference=SilentlyContinue
[Test-ScriptScope] $script:DebugPreference=SilentlyContinue
[Test-ScriptScope] $local:DebugPreference=
[Test-ScriptScope] $DebugPreference=SilentlyContinue

Host : Windows PowerShell ISE Host - 5.1.19041.3803
Command Origin : Internal (dot sourced?)
Command : C:\Users\xxx\Documents\GitHub\sql-server-maintenance\Test-ScriptScope.ps1
Script Name : Test-ScriptScope.ps1
[Test-ScriptScope.ps1] $global:DebugPreference=SilentlyContinue
[Test-ScriptScope.ps1] $script:DebugPreference=SilentlyContinue
[Test-ScriptScope.ps1] $local:DebugPreference=SilentlyContinue
[Test-ScriptScope.ps1] $DebugPreference=SilentlyContinue
[Test-ScriptScope] $global:DebugPreference=SilentlyContinue
[Test-ScriptScope] $script:DebugPreference=SilentlyContinue
[Test-ScriptScope] $local:DebugPreference=
[Test-ScriptScope] $DebugPreference=SilentlyContinue

It the script file is run without dot sourcing via command line, the results are different.
Host : Visual Studio Code Host - 2023.8.0
Command Origin : Runspace (not dot sourced?)
Command : C:\Users\xxx\Documents\GitHub\sql-server-maintenance\Test-ScriptScope.ps1
Script Name : Test-ScriptScope.ps1
[Test-ScriptScope.ps1] $global:DebugPreference=SilentlyContinue
[Test-ScriptScope.ps1] $script:DebugPreference=Continue
[Test-ScriptScope.ps1] $local:DebugPreference=Continue
[Test-ScriptScope.ps1] $DebugPreference=Continue
[Test-ScriptScope] $global:DebugPreference=SilentlyContinue
[Test-ScriptScope] $script:DebugPreference=Continue
[Test-ScriptScope] $local:DebugPreference=
[Test-ScriptScope] $DebugPreference=Continue

Host : Windows PowerShell ISE Host - 5.1.19041.3803
Command Origin : Runspace (not dot sourced)
Command : C:\Users\xxx\Documents\GitHub\sql-server-maintenance\Test-ScriptScope.ps1
Script Name : Test-ScriptScope.ps1
[Test-ScriptScope.ps1] $global:DebugPreference=SilentlyContinue
[Test-ScriptScope.ps1] $script:DebugPreference=Continue
[Test-ScriptScope.ps1] $local:DebugPreference=Continue
[Test-ScriptScope.ps1] $DebugPreference=Continue
[Test-ScriptScope] $global:DebugPreference=SilentlyContinue
[Test-ScriptScope] $script:DebugPreference=Continue
[Test-ScriptScope] $local:DebugPreference=
[Test-ScriptScope] $DebugPreference=Continue

Host : ConsoleHost - 5.1.19041.3803
Command Origin : Runspace (not dot sourced?)
Command : C:\Users\xxx\Documents\GitHub\sql-server-maintenance\Test-ScriptScope.ps1
Script Name : Test-ScriptScope.ps1
[Test-ScriptScope.ps1] $global:DebugPreference=SilentlyContinue
[Test-ScriptScope.ps1] $script:DebugPreference=Continue
[Test-ScriptScope.ps1] $local:DebugPreference=Continue
[Test-ScriptScope.ps1] $DebugPreference=Continue
[Test-ScriptScope] $global:DebugPreference=SilentlyContinue
[Test-ScriptScope] $script:DebugPreference=Continue
[Test-ScriptScope] $local:DebugPreference=
[Test-ScriptScope] $DebugPreference=Continue

Host : ConsoleHost - 7.4.0
Command Origin : Runspace (not dot sourced?)
Command : C:\Users\xxx\Documents\GitHub\sql-server-maintenance\Test-ScriptScope.ps1
Script Name : Test-ScriptScope.ps1
[Test-ScriptScope.ps1] $global:DebugPreference=SilentlyContinue
[Test-ScriptScope.ps1] $script:DebugPreference=Continue
[Test-ScriptScope.ps1] $local:DebugPreference=Continue
[Test-ScriptScope.ps1] $DebugPreference=Continue
[Test-ScriptScope] $global:DebugPreference=SilentlyContinue
[Test-ScriptScope] $script:DebugPreference=Continue
[Test-ScriptScope] $local:DebugPreference=
[Test-ScriptScope] $DebugPreference=Continue
So, it appears I need to not dot source my first file and then dot source the rest from that file.  I suppose this is a VSCode nightmare to support natively.  Perhaps two four options in VSCode - always dot source (current), never dot source (user must do it), dot source into a specific file (user sets once), or dot source into a single imaginary file (VSCode uses a hidden file script scope and dots to it).  Head can start to hurt thinking about the complexity.

Here's a trick to create a new scope if the file was dot sourced.  It's not the script scope, but might be okay for a simple call.
& {
$DebugPreference = 'Break'
Test-ScriptScope
}

Host : Visual Studio Code Host - 2023.8.0
Command Origin : Internal (dot sourced?)
Command : C:\Users\rstone\Documents\GitHub\sql-server-maintenance\Test-ScriptScope.ps1
Script Name : Test-ScriptScope.ps1
[Test-ScriptScope.ps1] $global:DebugPreference=SilentlyContinue
[Test-ScriptScope.ps1] $script:DebugPreference=SilentlyContinue
[Test-ScriptScope.ps1] $local:DebugPreference=SilentlyContinue
[Test-ScriptScope.ps1] $DebugPreference=SilentlyContinue
Testing Test-ScriptScop
[Test-ScriptScope] $global:DebugPreference=SilentlyContinue
[Test-ScriptScope] $script:DebugPreference=SilentlyContinue
[Test-ScriptScope] $local:DebugPreference=
[Test-ScriptScope] $DebugPreference=SilentlyContinue
Testing &{} with Test-ScriptScop
[Test-ScriptScope] $global:DebugPreference=SilentlyContinue
[Test-ScriptScope] $script:DebugPreference=SilentlyContinue
[Test-ScriptScope] $local:DebugPreference=
[Test-ScriptScope] $DebugPreference=Break

So many years and no change - we are still struggling with this.  mklement0 was pretty spot on from the beginning, and it is hard to grasp the perspectives that has been put onto this, attempting to justify inconsistent behavior with user vs developer perspectives. We're not developing to match everyones expectation, but to produce consistent outcomes and predictable behavior.
Imho - whether you are looking at this from a user perspective, or developer perspective, either one wants consistent behavior, independent of the source of the function thei're invoking. By having a requirement for detailed knowledge of the call stack from start to end, to be able to predict the outcome of preferences, does exactly complicate it for users and developers alike, and especially -WhatIf is a problematic preference variable/common parameter, since it can incur devastating consequences, which ultimately can't be predicted in the current state of affairs, if implemented in an advanced module function.
Keep in mind that in module development, we often call other functions in the module, to deal with specific tasks a greater function needs to accomplish, but at the same time the user/another developer may have the option to call those functions directly.
Users and developers alike would expect e.g. -WhatIf to perform as intended, regardless of how deep the function call is in the call stack. It could be catastrophic if we forgot to import preference variables from the callers scope, and even if we do remember it, the inheritance may have been severed by a module function somewhere else in the call stack that didn't do it - which btw. is completely out of our control, and not fixable by an opt-in change. This leaves the WhatIf parameter risky, and thereby imo useless in a module advanced function, as you cannot guarantee its propagation from parent scopes.
Propagating preference variables to descendent scopes should always have been the way, but the proposed option of adding a CmdletBindingAttribute for opting in to this, is however a truly elegant solution, that would solve part of the problem, and it won't even introduce breaking changes. You may even add more attributes, for more granular control - so one may wonder what is wrong with at least giving us this?

In my modules I have found that you can parse the command that called your module load so you can take action on that....
[System.Management.Automation.Language.Parser]::ParseInput($MyInvocation.Statement, [ref]$ParsedTokens, [ref]$ParsedErrors)
This will let you parse the import-module command and the parameters. Since you are using your own invocation statement you do not have to validate the module that is loading is yours.
This is a quick sample of how to do it, incase you are like me and need to see code to understand what these words mean. Drop the following code into a module and when you load it use Verbose switch on the import, it should let you know... you can play with it as you see fit. But I was thinking that it should be able to actually implement this in the import command somehow. I wonder if a proxy command would work... you could do it and throw the parameters that you want into a set order for the 'args' array.... or even modify the bound parameters I guess to do it... thats an idea I haven't thought about... I'll go have some fun with that idea this weekend. Anyways, the code:
`[System.Management.Automation.Language.Token[]]$local:ParsedTokens = @()
[System.Management.Automation.Language.ParseError[]]$local:ParsedErrors = @()
[System.Management.Automation.Language.ScriptBlockAst]$local:LastStatementAst = [System.Management.Automation.Language.Parser]::ParseInput($MyInvocation.Statement, [ref]$ParsedTokens, [ref]$ParsedErrors) # statement should only contain the import-module command
[System.Management.Automation.Language.CommandAst]$local:LastImportCommand = @($local:LastStatementAst.Find({$args[0] -is [System.Management.Automation.Language.CommandAst] -and ([System.Management.Automation.Language.CommandAst]$args[0]).GetCommandName() -eq 'Import-Module'}, $false))[0]
[System.Collections.ObjectModel.ReadOnlyCollection[System.Management.Automation.Language.CommandParameterAst]]$local:LastImportParameters = $local:LastImportCommand.CommandElements | Where-Object {$_ -is [System.Management.Automation.Language.CommandParameterAst]}
[System.Management.Automation.Language.ParameterAst]$local:CalledVerboseAst = @($local:LastImportParameters | Where-Object {$_ -is [System.Management.Automation.Language.ParameterAst] -and $_.ParameterName -eq 'Verbose'})[0]
[bool]$Script:IsVerbose = $false # default state
update the IsVerbose variable based on the value of the 'Verbose' parameter
if (-not $null -eq $local:CalledVerboseAst.Argument) { # means 'Verbose:[Variable | Value]' was used
try {
$script:IsVerbose = $local:CalledVerboseAst.Argument.SafeGetValue($true)
} catch [System.InvalidOperationException] { # the extent is unsafe
try { # fallback to extract value from string but compare it to a known valid value to determine the state
$script:IsVerbose = $local:CalledVerboseAst.Argument.Extent.Text.Replace('$','').ToUpper() -eq 'TRUE'
} catch { # ya, that extent is really unsafe
$script:IsVerbose = $false # no hope so we just say false
}
}
} else { # else only the switch is present, which means true for the value
$script:IsVerbose = $true
}
Write-Host "Verbose was $(($Script:IsVerbose ? "used with a resolved value of $IsVerbose" : "not used"))"
`
I just wish I could make it cleaner and more compact that it would be not so distracting at the top of a module.

This was closed as 'completed' in Nov 2023, but seems to still be an issue. It's frustrating having to work around this issue with -Verbose:($PSBoundParameters['Verbose'] -eq $true) everywhere.

@SteveL-MSFT this is a bot-closed issue that is still active and should be reopened.


overall scale values missing since update. Changing any values causes the rest to disappear; bones lost from memory. Other profiles not working at all.

Honestly don't even know what to say about this one. Was working fine yesterday but today it did this. Once this happens the editing file is corrupted and can't be edited again once closed, so the only option is to delete.

Is this scale for a player character? Whatever it is make sure it's present and the name is correct.
If the editor window doesn't open back up disable and enable the plugin in dalamud settings, then it'll pop back up.

Yes it is. I have deleted and remade multiple attempts for the same character, with everything present and written correctly, and disabling and reenabling the plugin doesn't stop the issue. It also doesn't stop the fact that changing any of the values completely breaks the plugin.

Can I get you to post a /xllog?

Restart game
Trigger bugs in C+
Open log
press copy to clipboard button in the top left
paste in here, preferably in a codeblock or even in a text file.

Unfortunately(?) since the update I haven't been able to recreate the bugs.
The function to scale my entire character up and down is still missing though. Was that removed?

welp if its gone its gone, Ill consider that good!
If you just want to use it to scale your char, then yes. Use Penumbra Racial scaling for that, https://twitter.com/oftheholybooty/status/1576278166309830657?t=TWoOm8cPVN4wfez8Kerz-g&s=19
If you want to use it elsewhere (only if you have to) you can unlock it in the settings, top right the Cogwheel, and in the advanced tab.
I will close this here, feel free to reopen if it happens again!


Various documentation

Some suggestions on what might be useful.

Documentation on how to use it.
Documentation for end users on how to install it.
Documentation regarding security.

How To Use:
Documentation on usage exists at http://auroracoin101.is/auroracoin-browser-wallet-tutorial/
Installation:
Need to look at installation process from the Google Store to see where to include manual upgrade process from previous (v1.0)  Extension.
Security:
May be sufficient in the above Documentation.


Expected content of connectors config is not intuitive, add validation and documentation

See discussion here.  The connectors config implements the config like shown here, but it expects only the content inside the connectors key, not the entire connectors: [ ... ].  This is not intuitive and has caught a few users.
We should either improve the documentation or add validation around this.  As the likely user mistake is that someone provides connectors: [ ... ] instead of just [ ... ], we could easily check for a connectors key with nested array and unpack it (and similarly make sure the array contains what looks like valid connectors (maybe checking for a type and id?).

LDAP example:
cat << EOF > /tmp/dex-ldap.yaml
- type: ldap
  id: ldap
  name: LDAP
  config:
    host: ipa.example.com:636
    rootCAData: <base64 encoded CA file>
    bindDN: uid=admin,cn=users,cn=compat,dc=example,dc=com
    bindPW: password
    usernamePrompt: LDAP Username
    userSearch:
      baseDN: cn=users,cn=accounts,dc=example,dc=com
      filter: "(objectClass=person)"
      username: uid
      idAttr: uid
      emailAttr: mail
      nameAttr: cn
    groupSearch:
      baseDN: cn=groups,cn=accounts,dc=example,dc=com
      filter: "(objectClass=posixgroup)"
      userMatchers:
      - userAttr: uid
        groupAttr: memberUid
      - userAttr: DN
        groupAttr: member
      nameAttr: cn
EOF

and then:
juju config dex-auth<EMAIL_ADDRESS>


Add a interface-status annotation to pod

It holds information stored in NetworkInterface object. NetworkInterface will be replaced by this.

@shouri007 Please review

@bowei could you approve this change given @mskrocki is not around?

/lgtm
/approve

/retest

/ok-to-test

/retest


Won't load the server

Describe the issue you are having
I get the following error
DllNotFoundException: RustNative assembly: type: member:(null)
at (wrapper managed-to-native) SystemInfoEx.System_GetMemoryUsage()
at SystemInfoEx.get_systemMemoryUsed () [0x00000] in <11ed8e9d36724eb19facca718a282945>:0
at SystemInfoGeneralText.get_currentInfo () [0x001a9] in <11ed8e9d36724eb19facca718a282945>:0
at Bootstrap+d__17.MoveNext () [0x00272] in <11ed8e9d36724eb19facca718a282945>:0
at UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) [0x00026] in <470ec865e9cd405cbc45cdbc22bb3c0c>:0
What was you doing before it happened
Started the server
Screenshots

What are you running on (please complete the following information):

OS: Unraid v7.4Beta
Browser terminal
Hardware: 2x Xeon 2690v2 CPU's, 96GB DDR3 RAM

Additional information
Add any other detail about the problem here.

I have the same problem


Controller assignment to invited players / guests

Whenever you invite someone to a remote play session for a non steam game (testing with Zelda BOTW on the YUZU emulator), it doesn't show that invited friends / guests have controllers. The icon is entirely gone and you can't assign them any controllers (in the remote play menu).

#7


Add files via upload

dynamics_move_above_staff.lua moves dynamics (expressions whose category is named "dynamics" and hairpins) above a staff, for vocal music. The script attempt to place all dynamics on a system so that they will clear the highest entry for that staff on that system.

Looks great, Jake!


Delays don't seem to be reset when loading

The first run of a delay seems to sometimes be short. Neither Step.Reset() nor UnsyncedModifier.Reset() do a Delay.Duration.Reset(), which might be part of the problem.

I can't reproduce this anymore.

I can't reproduce this anymore.

Actually...

Actually...

Fixed in 44deb0566ad8ea2fa2f21a5b0cf46c0d3940f939.

Fixed in 44deb0566ad8ea2fa2f21a5b0cf46c0d3940f939.


Update reading

Create basic env
Fix notebook

reading images day4 works fine in Colab and M1
lgtm

Works fine on M1 (reading images day4). Colab still testing.

**Run the below if running the plugin in Google Colab** This cell will allow to select an image from your local machine.  The image will be uploaded to Google colab. -> **Run the below if running the plugin in Google Colab** This cell will allow to select an image from your local machine. You MUST upload a .tiff image. The image will be uploaded to Google colab.
I think we have to warn the user not to upload anything else but tiff. ^^^

The cell just after the upload cell is erroring, although I have changed the name to match the name of the uploaded tiff. I also tried to remove the content top folder, but still the same error:

Figure_2024-03-18_15-05-48.tiff(image/tiff) - 34785482 bytes, last modified: n/a - 100% done

Saving Figure_2024-03-18_15-05-48.tiff to Figure_2024-03-18_15-05-48.tiff

....

image_local = skio.imread("includes/Figure_2024-03-18_15-05-48.tiff", plugin="tifffile")

---------------------------------------------------------------------------

FileNotFoundError                         Traceback (most recent call last)

[<ipython-input-10-474d0d273884>](https://localhost:8080/#) in <cell line: 1>()
----> 1 image_local = skio.imread("includes/Figure_2024-03-18_15-05-48.tiff", plugin="tifffile")

6 frames

/usr/local/lib/python3.10/dist-packages/tifffile/tifffile.py in open(self)
  14471             self._file = os.path.realpath(self._file)
  14472             self._dir, self._name = os.path.split(self._file)
> 14473             self._fh = open(
  14474                 self._file, self._mode, encoding=None
  14475             )  # type: ignore

FileNotFoundError: [Errno 2] No such file or directory: '/content/includes/Figure_2024-03-18_15-05-48.tiff'

You need to specify the name correctly it is Figure_2024-03-18_15-05-48.tiff not includes/Figure_2024-03-18_15-05-48.tiff

You need to specify the name correctly it is Figure_2024-03-18_15-05-48.tiff not includes/Figure_2024-03-18_15-05-48.tiff

But this will confuse many: I assumed that I cannot touch the include containing folder - just to replace the name of the tiff

IndexError                                Traceback (most recent call last)

[/usr/local/lib/python3.10/dist-packages/ipywidgets/widgets/interaction.py](https://localhost:8080/#) in update(self, *args)
    255                     value = widget.get_interact_value()
    256                     self.kwargs[widget._kwarg] = value
--> 257                 self.result = self.f(**self.kwargs)
    258                 show_inline_matplotlib_plots()
    259                 if self.auto_display and self.result is not None:

[<ipython-input-17-e489870d1d01>](https://localhost:8080/#) in update(z)
      6     c = 1
      7     fig = plt.figure(figsize=(10, 10))
----> 8     plt.imshow(image_local[z, c, :, :])
      9     plt.tight_layout()
     10     fig.canvas.flush_events()

IndexError: too many indices for array: array is 3-dimensional, but 4 were indexed

I uploaded successfully a tiff, but it has 4 indices, and the following cell crashed ^^^

whatever tiff I am trying to upload, it has always image_local.shape as (xxx, xxx, 4) == will always crash. Not sure why, few of my images are created by OMERO.figure (export option).
the only image which works is the B1...tiff one which I picked in my local checkout of this repo.

the Reading images notebook works fine on M1 and Colab.
But the cell just after upload of tif feature in Colab seems to crash on the inexpected image dimensions. Possibly the cell is too specific for the B1...tif ?

@pwalczysko done

@pwalczysko done

Yes, now it does not crash. Unfotunately though, for all the other images except the B1...tif the display of the image is not true, it just displays something like y-axis instead of the image as checked locally, see screenshot below.
I guess this is because there is a dimension mismatch. I also tried to create a TIF using Fiji (possibly a way which participants might choose) and again, this tif uploads, but it looks like below (it is highlighted wrongly as having hundreds of z-sections.

This really depends on the image I used images from https://downloads.openmicroscopy.org/images/TIFF/ and no problem

Merging so I can move forward and avoid conflict.
I can always go back to it


python310Packages.intellifire4py: 1.0.5 -> 2.0.0

Description of changes
Update to latest upstream release 2.0.0

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
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 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 174986 run on x86_64-linux 1

1 package failed to build:

home-assistant-component-tests.intellifire

2 packages built:

python310Packages.intellifire4py
python39Packages.intellifire4py


Convergence large outflow from small basin

Fixes https://github.com/Deltares/Ribasim/issues/1414

Interesting results for this PR with the new Crystal test model provided by @fati-mon (now part of our test models):
Runtime new branch: ~3.1 seconds
Run current main: Several minutes

Closed in favor of https://github.com/Deltares/Ribasim/pull/1697

This code could be useful in the future, but #1697 will do for a little while :)


introduce secp operators

This is a softfork activated by ENABLE_SECP_OPERATORS. It's based on @cameroncooper 's patch which implements verification of secp256k1 and secp256r1 signatures.
The two new operators are:

name
opcode
cost
description

secp256k1_verify
0x0f423f00
1000000
Verifies a signature given a public key, message digest and signature

secp256r1_verify
0x0f423f01
1000000
Verifies a signature given a public key, message digest and signature

This is best reviewed one commit at a time.

@rostislav pointed out that there's a reason for k1 to be about twice as fast as r1. so maybe it would make sense to reflect that in the cost


feat: use @waku/sdk

Migrate main and simple JS examples to use @waku/sdk.
Next steps:

migrate more complex examples one by one;
check if there are no regressions in the new release;

Resolves the last part of https://github.com/waku-org/js-waku/issues/1353

Validated with local node - working fine.


"is-clustered" validation isn't working

Hi,
The clustered var isn't being filled with boolean result and the manifest always run as a cmode.
lib/puppet/util/network_device/netapp/device.rb#L42
    # Vserver or vfiler based on if clustered?
    clustered = result.child_get_string("is-clustered")
    Puppet.debug("Clustered = #{clustered}.")
    if clustered
      @transport.set_application_name("puppet_netapp_cmode")
    else
      @transport.set_application_name("puppet_netapp_sevenmode")
    end

Testing
[root@puppetmaster puppet]# export FACTER_url=https://root:xxx@smode-lab
[root@puppetmaster puppet]# puppet resource netapp_volume --debug
Debug: Runtime environment: run_mode=user, ruby_version=1.8.7, puppet_version=3.8.2
Debug: Puppet::Util::NetworkDevice::Netapp: connecting via facter url.
Debug: Puppet::Device::Netapp: connecting to Netapp device https://root:****@smode-lab
Debug: Puppet::Device::Netapp: Version = NetApp Release 8.2.3 7-Mode: Thu Jan 15 21:30:45 PST 2015
Debug: Clustered = false.
...
Debug: Puppet::Provider::Netapp_volume.cmode: got to self.instances for cMode provider.
Debug: Puppet::Provider::Netapp_volume.cmode get_volinfo: getting volume info for all volumes.
...
Error: Could not run: Executing api call volume-get-iter tag  failed: "Unable to find API: volume-get-iter"

OS: CentOS 6.7
Ruby: 1.8.7
Puppet: 3.8.2

The fact is also wrong.
lib/puppet/util/network_device/netapp/facts.rb#L23
[root@puppetmaster puppet]# puppet device --verbose --user=root --debug
...
Debug: Finishing transaction<PHONE_NUMBER>1660
Debug: Puppet::Device::Netapp: connecting to Netapp device https://root:****@smode-lab
Debug: Puppet::Device::Netapp: Version = NetApp Release 8.2.3 7-Mode: Thu Jan 15 21:30:45 PST 2015
Debug: Clustered = false.
Debug: Puppet::Device::Netapp: Adding usage log to EMS service
Debug: Using cached certificate for ca
Debug: Using cached certificate for 7mode-lab
...
Debug: Device is clustered.
Debug: Hostname = smode-lab
Debug: Current vserver =
Debug: Not connected to a vserver, so gather system facts
Debug: Result = #<NaElement:0x7fb7f6b58780 @children=[], @name="results", @attrvals=["failed", "Unable to find API: system-get-node-info-iter", "13005"], @attrkeys=["status", "reason", "errno"], @content="">
Error: Could not retrieve local facts: undefined method `children_get' for nil:NilClass
Error: Failed to apply catalog: Could not retrieve local facts: undefined method `children_get' for nil:NilClass

closed with the merge


CSSStyleSheet.cssRules getter: Not allowed to access cross-origin stylesheet

Bug description
I have installed antd-phone-input in a clean vite project (vite v.4.3.2) using ant design v.5.5.2 (i.e. the latest version), but I keep getting an error when accessing the page with the phone-input-component via Firefox (v. 114.0 64-bit, i.e. the latest).
Notably, it works fine in all other browsers I have tested it (Chrome and Safari).
To use the  component, I used the following code (as suggested in the documention):
import FormItem from "antd/es/form/FormItem";
import PhoneInput from "antd-phone-input";
[...]

[...]
The image below, shows the error I keep getting:

Any ideas?
Thanks
Reproduction URL
No response
Reproduction steps

Create a vite project (npm create vite using React and TypeScript)

Install ther latest version of ant design (npm i antd)

Go into any .tsx file (e.g. App.tsx) and
3.1 Introduce the following three import statements: import FormItem from "antd/es/form/FormItem"; import PhoneInput from "antd-phone-input"; import {Form} from "antd";
3.2 Try to use the PhoneInput component, i.e.

Navigate to the page which the PhoneInput component was added in, using Firefox.

Screenshots

Logs
No response
Browsers
Firefox
OS
Mac

Hi @g-vellis-se, thanks for reporting the issue. I have passed the reproduction steps but could not get the error you are facing with. As we can see in the error message, it is correlated with React Router. Could you please try to reproduce the issue on one of the following platforms if it is not open source:

https://codesandbox.io
https://stackblitz.com
https://codepen.io

My environment and dependencies

Node - v19.9.0
npm - 9.6.3

"dependencies": {
   "antd": "^5.6.1",
   "antd-phone-input": "^0.1.6",
   "react": "^18.2.0",
   "react-dom": "^18.2.0"
}

Hi @ArtyomVancyan ,
Thank you very much for the prompt reply.
The issue was caused by the following Firefox plugin: "Adjust Screen Brightness" (see: https://addons.mozilla.org/en-US/firefox/addon/adjust-screen-brightness/). Once I disabled it, everything worked as expected.

same issue

@vishwajit76, please share some code snippets. Try to disable browser add-ons one by one to find the possible cause.


Simbad query plugin

Add plugin that allows to make queries to Simbad (http://simbad.cds.unistra.fr/simbad/) by selected celestial object or celestial point (context menu?).
Result of query should display a table (?) with data.

Reference: https://simbad.cds.unistra.fr/guide/sim-url.htx


fix(reactivity-transform): update check to catch toRef and customRef

closes #6349
Also adds unit tests for these new transforms

Unfortunately, Reactivity Transform has been dropped officially now, so I closed this issue/PR. If you want to keep using it, please consider the community version Vue Macros.

This PR has been merged to Vue Macros https://github.com/sxzz/unplugin-vue-macros/commit/8cc7b4cec38034540f7fecae0626965a9b1e7171.


feat: float.win_opts option

The user can customize the config passed to nvim_open_win() by using float.win_opts.
refer https://github.com/tamago324/lir.nvim/issues/23#issuecomment-868740721
Example:
local actions = require'lir.actions'
local mark_actions = require 'lir.mark.actions'
local clipboard_actions = require'lir.clipboard.actions'

require'lir'.setup {
  -- ...
  float = {
    winblend = 0,

    -- You can define a function that returns a table to be passed as the third
    -- argument of nvim_open_win().
    win_opts = function()
      local width = math.floor(vim.o.columns * 0.8)
      local height = math.floor(vim.o.lines * 0.8)

      return {
        border = require("lir.float.helper").make_border_opts({
          "+", "─", "+", "│", "+", "─", "+", "│",
        }, "Normal"),
        width = width,
        height = height,
        row = 1,
        col = math.floor((vim.o.columns - width) / 2),
      }
    end,
}

A helper functions are provided:
lir.float.helper.make_border_opts(borderchars, highlight)
Returns a table that can be passed to config.border in nvim_open_win() by passing the border string and highlight name.

This is looking good! Although having two keys to configure floating windows seems redundant. We can combine the functionality into one key which either accepts a number or a table or a function and construct the opts table accordingly.
Also, this makes the option borderchars redundant as the user can pass in the same in make_win_config with the border key.

@dhruvmanila Thanks for your feedback!
Yes, I do not think it is desirable to have more than one setting value.
I have fixed the example above.
What do you think?

@tamago324 It works pretty well for me, thanks. I am personally not using any of provided helper functions as I have custom function that builds parameters for nvim_open_win() but that doesn't mean others won't need/use them. Thank you very much for looking into this!

I believe the extending of user options with the default ones should be done internally as it does not make sense for the user to do it. The user will either pass in a table of opts or a function which will return a table of opts and then we can, internally, merge them into the default opts table with the user opts being given preference. Something like this:
require'lir'.setup {
  -- ...
  float = {
    winblend = 0,

    -- either a table or function which returns a table (we can eliminate the possibility by
    -- forcing the user to always use a function)
    window_opts = function()
      return {
        row = 1,
        col = 1,
        width = vim.o.columns * 0.8,
        height = vim.o.rows * 0.6,
      }
    end,
  },
}

And then internally combine them with the default opts table:
default_opts = { ... }

vim.tbl_deep_extend("force", default_opts, user_opts)

This might result in breaking changes, so we would have to warn the users accordingly. Some options in the float table might be eliminated such as size_percentage and borderchars/border. It's always a mess when we change the configuration options lol ;)

Thanks for the great idea! It makes it much easier to understand how to set it up.
I'm going to make x accept only functions.
If this is ok, I'll write a help and merge it.

It is very nice and clean solution. Thanks @tamago324 for implementing it and @dhruvmanila for streamlining the idea!

@dhruvmanila @gegoune Thank you for your help!
Please let me know if you need anything else!

Is there a way to get line numbers using this method? I can't seem to figure out how to get line numbers on lir.

@JulesVerne22
What line number is the line number? I would like you to tell me specifically which line number you want to get in what state.

I use relative line numbers when editing files, and it is nice to be able to jump vertically using motions like '3j' or '4k'. I was hoping to have relative line numbers on the far left of lir menu so that I could quickly jump in the same fashion. NvimTree does a similar thing already, so it would be nice to stay somewhat uniform.


read_sample gives UnexpectedEof error in 0.9

Just tried updating to 0.9, but whenever I call read_sample I'm getting this error:
Err(IoError(Error { kind: UnexpectedEof, message: "failed to fill whole buffer" }))

The mpeg_aac_decoder example seems to work fine, so there might be something I could do differently, but still this did work fine in 0.8.
Here's the branch where I tried the upgrade: https://github.com/probablykasper/redlux/tree/mp4-0.9
commit: https://github.com/probablykasper/redlux/commit/cc8add163a7fbf6009798ddab0722e9f6e8b94d7

It seems that the piece of code raising the error is the following one:
https://github.com/alfg/mp4-rust/blob/56cc260a5c103c66167f3c330be09da0b3e431ac/src/track.rs#L526-L535

Thanks for catching this. Will take a look as soon as I can.

@alfg I think I found the issue
https://github.com/alfg/mp4-rust/blob/93dbb564642cbbc577e706afdff87b8237cdbe4c/src/mp4box/tfhd.rs#L61
The base data offset is always assumed to be present, but I checked how FFmpeg handles this box:
https://github.com/FFmpeg/FFmpeg/blob/2b2380c098569af88e7a77aff78f330d11090512/libavformat/mov.c#L4819-L4821
The base data offset is dependent on the flags. I checked the asset in https://github.com/probablykasper/redlux/issues/4, which had an implicit offset, so the offset was actually being read from the stsd id and default duration, making it incredibly large<PHONE_NUMBER>, greater than the file size).
I can make a PR to fix this, but I'm not sure how you would want this done. Since you're using the ReadBox impl I can't pass along the moof offset.

Hey @Serial-ATA, thanks for checking into this. Sorry, I haven't had much time lately to work on this, but I'm open to suggestions and PRs.

I'll have to either remove the ReadBox impl or somehow return the flags from it, maybe by storing them in the TfhdBox itself? What do you think?

@Serial-ATA any clue why it worked before 0.9?

Could be https://github.com/alfg/mp4-rust/pull/46? Not sure. A quick look through the history didn't turn up anything obvious, and I don't really know the project. :smile:

I suspect this might be fixed in git master thanks to #86 and #106. I don't have a file that is affected – maybe someone in here could test this?

It seems to be fixed, yeah!


fix: deprecate dependabot token support

:tada: This PR is included in version 1.2.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Your audio does not work but your app is a 10/10

For some odd reason audio i was using your app and I also gotta say your app is one of if not the best screen recorder apps I have to give it to you for some reason when I look back at the recording something went wrong there is no audio please fix this bug

We have clarified with @Mellomr99 on Discord. For someone else who might be reading, the audio is implemented in the beta. If you want to gain access to it, just join Fluent Screen Recorder Discord server and/or UWP Community Discord server and ask for the role


Bump velocity-animate to 1.3.1

1.3.0 has no breaking changes according to their README (just code cleanup), and 1.3.1 contains a race condition fix for an error that we saw in production (https://github.com/julianshapiro/velocity/pull/690). 1.3.1 is the current latest version.

Thanks, I'd be happy to spin up a release PR as well.


fix(@angular-devkit/build-angular): ensure proper resolution of linked SCSS files

This commit addresses a bug where SCSS files within linked directories were not being resolved correctly by the Angular CLI. By implementing the necessary adjustments, linked SCSS files are now properly resolved.
Closes #27353

That was quick!


Make calls to groups settings API

description added by ajs11893:
adds the settings box for individual groups, the edit button and "View access and membership settings " link are both added however the functionality for them has not been implemented yet.

Looks good, some buttons don't do anything which can be confusing


Erlang Error in Elixir Language Server with Surface

Describe the bug
I started a new project from zero using the mix phx.new, and then I ran the mix surface.init --demo --catalogue --layouts  to set up Surface.
After I started to follow the Getting Started guide, I realized there is no Surface intellisense when I started to write the slot macro.
I use Visual Studio Code with ElixirLS extension.
Checking the elixir-ls logs I could see the log below:
[Warn  - 16:16:39] ** (ErlangError) Erlang error: "ArgumentError during metadata build pre:\ncould not call Module.register_attribute/3 because the module NoahWeb.Components.ExampleComponent is already compiled\nast node: {:use, [end_of_expression: [newlines: 0, line: 2, column: 24], line: 2, column: 3], [{:__aliases__, [last: [line: 2, column: 15], line: 2, column: 7], [:Surface, :Component]}]}"
    (elixir 1.15.4) lib/module.ex:2310: Module.assert_not_readonly!/2
    (elixir 1.15.4) lib/module.ex:1660: Module.register_attribute/3
    (surface 0.11.0) expanding macro: Surface.BaseComponent.__using__/1
    nofile: NoahWeb.Components.ExampleComponent (module)

How to reproduce it
Create a new project with the last version of Phoenix.
Add the last version of surface.
Use Visual Studio Code with ElixirLS extension. Both in the last version released.
The behavior you expected
Your Environment
Surface: v0.11.0
LiveView: v0.19.5
Elixir: v1.15.4
Erlang: v26.0.2

I have noticed the same, and think it's related to elixir 1.15.x and maybe erlang 26.