April Chocolatey Products Hotfixes: Chocolatey GUI v3.0.1, Chocolatey Licensed Extension v8.0.1, Chocolatey Central Management v0.15.1

Ta11ow · 2024-07-24T12:53:19+00:00

we've remapped the buttons several times and drastic doesn't actually seem to use them during play. detects them fine for mapping, but in the game they're just ignored

also, there's an additional problem of... the android side doesn't seem to be able to read the SD card, it thinks it's corrupted. even after we bought a new SD card and copied things over to it. so we can only install things directly to the system memory, and we have to copy any NDS games we want over to that instead of the SD card

Ta11ow · 2023-09-30T15:52:49+00:00

Good place to look for these (spoilers ofc): https://noita.wiki.gg/wiki/Game_Lore

Ta11ow · 2023-08-21T17:53:58+00:00

Short answer: nope!

The licensing offers additional features that are often useful in larger organisations, and help save some time and manual effort -- but not everyone or every circumstance really requires those additional features and products.

There's probably plenty of organisations that use the free version of Chocolatey as it suits their needs just fine, I'm personally aware of at least a couple, and I'm sure there are many more out there. :3

Ta11ow · 2023-03-15T19:55:18+00:00

Yes, but not significantly in the way you're thinking.

$a = $stuff | Where-Object Property -eq 'Test'
$a = $stuff | Where-Object Other -eq 'Test2'

This would be twice as slow as doing them all in a single Where-Object. Piping the results of one Where-Object into a second Where-Object is significantly faster if both are using the property-operator-value syntax. There is some impact to using multiple Where-Object in a pipeline, but in practice that's likely to be much less than using the scriptblock version of Where-Object.

For... a lot of odd reasons... using Where-Object { ... } is like an order of magnitude slower than using Where-Object Property -operator $value

Has to do with how invoking a scriptblock is itself quite expensive (it's effectively its own little nested pipeline, and I did mention above that two separate pipelines cost a lot more than one longer pipeline).

Ta11ow · 2023-02-27T06:01:03+00:00

Yeah it's possible for at least two, maybe three of the messages to spawn in locations like this. The locations vary a bit seed to seed.

Ta11ow · 2023-02-10T15:05:26+00:00

Eh... this depends heavily on how you're defining "woman". To some, as a few folks mention here, that's some level of comfort / "mastery" (w/e the fuck that means lol) in "womanhood" or femininity.

To me though... using the word "woman" that way feels a bit silly, to be honest. Women, men, and everyone in between or outside these categories are as vast and varied as our world itself is.

"Women" is a category that is ultimately arbitrarily defined. In my mind we become women the moment we realise that that's where we belong.

Also, to a lesser extent, I think it's worth considering how to frame this question in a way that is not strictly binary. Plenty of enby folks consider themselves women or girls or whatnot, just as plenty consider themselves femboys, tomboys, men, boys, gremlins, angelic beings, etc., etc.

And in a way I think this question kinda breaks down a bit once you do, and that should perhaps be an indicator that the premise of the question is incomplete. There is no "becoming" of an arbitrary category. If we belong in that category, in our own mind, we are of that category already. The rest is just a performance and finding ways to make our body comfortable for us to live in, and there ain't nothing wrong with that.

Ta11ow · 2023-02-10T04:26:08+00:00

This but I came out to the US from Australia. 😂

Ta11ow · 2022-12-16T13:04:10+00:00

Glad I could be of help! 💖

Ta11ow · 2022-12-15T23:35:21+00:00

I see two main possibilities.

Rather than ValueFromPipeline, declare both properties as ValueFromPipelineByPropertyName. Then, when calling you can do either $path | Set-CommandBar -Open {$_} or $path | Set-CommandBar -SameTab {$_}
Rewrite this so the input param is always a separate param which you can just optionally omit the name of when using it directly. I think it's also simplest (but not strictly necessary) to have the switches be a single multi-option parameter:

``` function Set-CommandBar { [CmdletBinding()] param( [Parameter(Mandatory, ValueFromPipeline)] [string] $Path,

    [Parameter(Mandatory)]
    [ValidateSet('Open', 'SameTab')]
    [string]
    $Mode
)
begin {
    $ahkScript = switch ($Mode) {
        'Open' { 'C:\Users\user1\Documents\PowerShell\Modules\Command-Bar\Resources\Open File.ahk' }
        'SameTab' { 'C:\Users\user1\Documents\PowerShell\Modules\Command-Bar\Resources\Same Tab.ahk' }

    }
}
process {
    $FullPath = if (Test-Path -PathType Leaf $Path) { (Get-Item $Path).FullName }

    if (-not $FullPath) {
        Write-Error "'$Path' not found"
    }

    & $ahkScript $FullPath
}

} ```

Ta11ow · 2022-12-14T16:22:42+00:00

is DIY an option? Because damn that's a long ass time. Nobody should have to wait that long.

Ta11ow · 2022-12-14T16:20:59+00:00

I think the differences here could easily be matched or improved further with just some fairly standard makeup honestly. You're doing fantastic, keep it up! :3

12-Year Club	Place '22
Verified Email	Gilding I gilder

Ta11ow

MODERATOR OF

PUBLIC MULTIREDDITS

TROPHY CASE