The change that makes PowerShell classes' methods run in full-language mode

Yesterday, I noted that PowerShell-defined classes' method bodies are restricted by the runspaces in which they execute. That causes problems for some use cases, and I wanted to figure out how to fix it. Eventually, I found the place to change: InvokeHelper and InvokeHelperT in ClassOps.cs. Just add this line right before the InvokeAsMemberFunction and InvokeAsMemberFunctionT calls:

sb.LanguageMode = PSLanguageMode.FullLanguage;

PowerShell-defined classes' methods are restricted by the runspace they're invoked in

In PowerShell 5, you can define your own .NET types in a script. They can have fields and methods, just like all .NET classes. Method bodies are written in PowerShell. Therefore, you can implement full cmdlet types (not just advanced functions) in PowerShell and allow them to be used in constrained-language runspaces.

Unfortunately, when the method body is run from such a limited runspace, it is subject to the caller's restrictions. This doesn't appear to be for security reasons, since you could just define the type in C# with Add-Type and then approve that cmdlet type for execution in the runspace. Here is a script to test this:

Class TestCmdlet : System.Management.Automation.Cmdlet {
 [void]BeginProcessing() {
  $this.WriteObject('It worked!')
 }
}
$iss = [InitialSessionState]::Create()
$testssce = New-Object System.Management.Automation.Runspaces.SessionStateCmdletEntry ('Test-CustomCmdlet', [TestCmdlet], '')
$iss.Commands.Add($testssce)
$rs = [RunspaceFactory]::CreateRunspace($iss)
$rs.Open()
$rs.LanguageMode = 'ConstrainedLanguage'
$p = $rs.CreatePipeline('Test-CustomCmdlet')
$p.Invoke()

It should return the string It worked!, but it will actually fail with CmdletInvocationException because the script-defined type cannot call its own methods.

I have written a very simple change to a fork of the PowerShell code base that makes this example work. I will see if it can/should be implemented in the real PowerShell.

Building PowerShell when it complains about win10-x86 not being a valid value for a variable

Today I tried to compile the official PowerShell repository, but received an error that started with this:

"The variable cannot be validated because the value is not a valid value for the Runtime variable."

win10-x86 is apparently not one of the supported runtimes for the full-CLR version of PowerShell. I have 64-bit Windows 10, but the Git Shell always ran 32-bit PowerShell. It's possible that the 32-bitness of the calling program caused the dotnet utility to return the x86 version of the OS, but I'm not sure. Anyway, I ended up manually modifying build.psm1 to simply set $Runtime to win10-x64 on line 530, as opposed to running dotnet. Then the official instructions worked as expected.

Volunteering at a different FTC league's meet

Though the local FTC league had its championship a week ago, other leagues are still doing normal meets. I volunteered at one of those yesterday. They had been in need of a field inspector; my local league's manager gave them my information since I had done field inspection several times before. Most of the time here, I was the only one doing the field inspecting, but the person overseeing the event helped when a bunch of teams came through at once. After inspections completed, I stuck around to be an assistant Field Technical Advisor. I don't know as much as I'd like to about the new phone systems, but we got through it.

The event was managed essentially the same as those of the other league. It was very nice that the host school provided a token for a free meal to each volunteer, redeemable at the concession stand. They had "volunteer" vests instead of lanyards, which was nice in that it more clearly showed where the volunteers were. The host school also had their band play between matches, filling the gaps while referees processed the just-completed game.

Namecheap explicitly does not support Let's Encrypt

I received a tip in regard to yesterday's post reminding me of Let's Encrypt, which is a really great and responsibly managed free TLS-certificate-granting project. Unfortunately, my shared hosting provider (Namecheap) does not give me root access with my current plan, which the normal Let's Encrypt program needs. Some shared hosting providers work with Let's Encrypt, but Namecheap is on the list of providers who explicitly do not plan to support it.

I can get SSH access (non-root) by request, so that might let me get free certificates onto the machine. I could always manually copy over a Let's Encrypt cert, but I would much rather have a setup that doesn't require me to set up another machine or VM. I did find this article and this other GitHub repository, which look promising. I'll see how it goes.

FMod - Switching to Amazon S3

A month or so ago, I copied all the Abiathar-related hosted files from my public Dropbox onto the server that hosts Keen Modding and the PCKF, since Dropbox's public folder mechanism will stop working soonish. Unfortunately, I have no SSL certificate for my domains at the moment, and with StartSSL sinking, I can't easily get one. It would be a Very Bad Thing to do automatic updates over an unsecured connection, so that leaves Amazon S3. S3 gives me plenty of space at very little cost; I already pay $0.51 a month for DNS and file hosting, and I can't imagine these few files making that go up any more than a single cent per month. I uploaded all the files to it (which is a weirdly slow affair) and will soon readjust all the URLs embedded in the various Abiathar components.

FMod - Consistent tileinfo opacity

I noticed while adding the foreground highlight that the tile properties render plane behaved differently depending on whether it was drawing the level for the first time. (For performance reasons that may or may not make a difference, the "render the whole level" method doesn't use the "render this one changed tile" method.) Specifically, when replacing a tile, it uses a ColorMatrix to change the alpha component, but that doesn't happen for the first render pass. Therefore, tiles placed after loading the level get a brighter-looking tile property overlay. That's pretty strange, and the visual effect can be replicated perfectly fine by changing the color in the config file if desired, so I removed that extra complication to make it consistent.