Kissaki

Nushell is a powerful shell and scripting language with strong typing, querying, and piping functionalities.

This release adds runtime pipeline input type checking, several new commands and operators, and various other miscellaneous improvements.

What ultimately pushed me to leave Matrix was discovering that my homeserver's admin was using my account without my consent.

In an encrypted room even with fully verified members, a compromised or hostile home server can still take over the room by impersonating an admin. That admin (or even a newly minted user) can then send events or listen on the conversations.

…, I've decided to move my conversations over to SimpleX.

For the past few months, the Matrix community has been largely inactive (despite having over 5,000 members), while the Telegram community has remained much more vibrant. This is disappointing given that I have been a strong advocate for using Matrix and have promoted it widely. For some reason, people are not moving to Matrix at the rate I had hoped.

GitHub repo

Examples

> (15 kg/m) * 7cm
# (((15 * kg) / m)) * 7 * cm
out = 1050 * g

> 1 |> cos |> log
# 1 |> cos |> log
out = -0.6156264703860141

> display dev
# Display mode: dev (Developer)
>>> 1.5
# 1.5
out = 1.5
    # IEEE 754 - double - 64-bit
    #
    = 0x_3FF80000_00000000
    = 0x____3____F____F____8____0____0____0____0____0____0____0____0____0____0____0____0
    #    seee eeee eeee ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
    = 0b_0011_1111_1111_1000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0000
    #   63                48                  32                  16                   0
    #
    # sign    exponent              |-------------------- fraction --------------------|
    =   1 * 2 ^ (1023 - 1023) * 0b1.1000000000000000000000000000000000000000000000000000

I track and version my Nushell environment and configuration in a public repository.

I added a GitHub Actions workflow that tests these files. That will ensure a more defined environment and prerequisites/assumptions, given that they have to be set up in the workflow configuration. Given that I mostly work on Windows, but set up the CI to run on Linux/Ubuntu, it will also ensure platform neutrality.

Since Nushell version 0.101.0, there's no need for a default, base env.nu or config.nu, and the nu binary can be called with only the custom, minimal env and config files.

The nu binary offers --env-config and --config parameters.

I noticed that when using them, errors do not lead to error exist codes; nu will continue execution and report success despite env or config not loading [correctly]. (Bug Ticket #14745)

Do you version your environment configuration? Only locally, or with a hosted repository as a backup or to share? Do you run automated tests on it?

One of two Azure CDN providers was Edgio, which filed for bankruptcy.

azureedge.net dotnet CDN URLs will cease to work sometime next year after January 15th.

We expect that most users will not be directly affected, however, it is critical that you validate if you are affected and to watch for downtime or other kinds of breakage.

We maintain multiple Content Delivery Network (CDN) instances for delivering .NET builds. Some end in azureedge.net. These domains are hosted by edg.io, which will soon cease operations due to bankruptcy. We are required to migrate to a new CDN and will be using new domains going forward.

Affected domains:

• dotnetcli.azureedge.net
• dotnetbuilds.azureedge.net

Unaffected domains:

• dotnet.microsoft.com
• download.visualstudio.microsoft.com

azureedge.net dotnet CDN URLs will cease to work sometime next year after January 15th.

One of two Azure CDN providers was Edgio, which filed for bankruptcy. CDN migration is in progress.

We expect that most users will not be directly affected, however, it is critical that you validate if you are affected and to watch for downtime or other kinds of breakage.

We maintain multiple Content Delivery Network (CDN) instances for delivering .NET builds. Some end in azureedge.net. These domains are hosted by edg.io, which will soon cease operations due to bankruptcy. We are required to migrate to a new CDN and will be using new domains going forward.

Affected domains:

• dotnetcli.azureedge.net
• dotnetbuilds.azureedge.net

Unaffected domains:

• dotnet.microsoft.com
• download.visualstudio.microsoft.com

• Update dotnetcli.azureedge.net to builds.dotnet.microsoft.com
• Update dotnetcli.blob.core.windows.net to builds.dotnet.microsoft.com

We also noticed that there is a lot of use of our storage account: dotnetcli.blob.core.windows.net. Please also search for it. The storage account is unaffected, however, it would be much better for everyone if you used our new CDN. It will deliver better performance.

• Simplified Startup Configuration
• path self
• chunk-by
• term query
• merge deep
• WASM support (again)
• sys net inclueds new columns mac and ip
• raw string pattern matching
• dates can now be added to durations
• additional explore keybinds
• version in startup banner
• input --default
• PowerShell script invocation on Windows
• new introspection tools

Breaking Changes:

• ++ operator, stricter command signature parsing (resolves silent parse errors)
• group-by now supports "groupers" (multiple criteria)
• timeit
• sys cpu
• from csv and from tsv
• std/iter scan
• completion sorting in custom completers, import module naming with normalization
• display_output hook
• du flag changes
• Code specific environment variables updated during source

ffaattaall eerrrroorr UU11005588: : tteerrmmiinnaatteedd bbyy uusseerr

a new NuGet dependency graph resolver built to dramatically improve performance

The new algorithm they developed uses a more streamlined approach, representing the graph as a flattened set where each node is created only once. This makes the in-memory dependency graph much smaller and easier to work with. Conflicts are resolved as the graph is being built, which avoids the need for the repetitive passes that the old dependency graph resolution algorithm required.

This new approach had dramatic results. The original dependency graph, which in our testing would create 1.6 million nodes for a complex project, was reduced to just 1,200 nodes. With fewer nodes to process, restore times dropped significantly; from 16 minutes down to just 2 minutes.