# the original version that didn't parse
# because ',' made number endings ambiguous
'1,000,2,000,3,000,0,000,1,000,2,000,3,000,0,000' -split '\,'
| Join-String -sep ' ' -SingleQuote
| Label 'original' -Before 1
'1000', '2000', '3000', '0', '1000', '2000', '3000'
| Join-String -sep ' ' { '{0:n0}' -f @( $_ -as 'int' ) } -SingleQuote
| Label 'should be' -Before 1 -After 1
$result ??= @{}
( $result.Steps1 ??= ai '# first 100 numbers modulous 4, multiplied by a factor of 1e6' )
| renderNice | Label 'Step1' -bef 1
hr
label 'step3' -after 1 'This time it''s parsable, but, the numbers are not the same different.'
$result.Steps3 -split ',' -replace "'", '' | renderNice
PowerQuery has metadata that you don’t normally see. For example, take the function Table.FromRecords
Create a new blank query, and set the value to a function’s name. When you reference a function without arguments or parenthesis, it displays documentation. ( It’s mostly the same as the online docs )
Where does this come from? A lot of it is generated by metadata on the function’s type itself.
Let’s start drilling down. Using the function Value.Type you can view the type’s definition
It doesn’t seem very useful at first. The data we want is from the metadata, the Ascribed types.
How do you document your own functions? Here’s a medium example. The function declared further below starts with this definition:
Text.ReplacePartialMatches_impl = (
source as text, mapping as table
) as text => ...
To create the type, you start your function type almost the exact same as the definition. Then wrap it inside a type function
Text.ReplacePartialMatches.Type = type function(
source as text,
mapping as table
) as text meta [ .. ]
Next you start adding records to the final type’s metadata. If you haven’t seen the meta operator, check out Ben’s series:
The part that comes after meta operator is a regular record
let
Text.ReplacePartialMatches = Value.ReplaceType( Text.ReplacePartialMatches_impl, Text.ReplacePartialMatches.Type ),
Text.ReplacePartialMatches.Type = type function(
source as text,
mapping as Table.Type
) as text meta [
Documentation.Name = "Text.ReplacePartialMatches",
Documentation.LongDescription = Text.Combine({
"Test strings for partial text matches. Replace the entire cell/value with the new replacement text.",
"",
"Mapping table requires two columns: <code>[Partial]</code> and <code>[New Value]</code> "
}, "<br>")
],
Text.ReplacePartialMatches_impl = ( source as text, mapping as table ) as text =>
// todo: performance, exit early on first replacement
let
mappingList = Table.ToRecords( mapping ),
result = List.Accumulate(
mappingList,
source,
(state, cur) =>
if Text.Contains( state, cur[Partial], Comparer.OrdinalIgnoreCase )
then cur[New Value] else state
)
in result
in
Text.ReplacePartialMatches
options is an record, when used this way it’s similar to Python’s kwargs
Merging two records with update the existing fields, adding new fields, if they do not yet exist
(in PowerQuery) the order of steps don’t change the final result (order of execution is the same) That’s why defaults after config works
Sometimes readability improves when placing large “blocks” like values_list out of order so the logic is on top
I replaced values *before* converting them to text so you have more control (before coercion )
Text.JoinSpecialValues_impl = (source as list, optional options as nullable record) as text =>
let
config = Record.Combine({defaults, options ?? []}),
defaults = [
Separator = "|",
UseSpecialSymbols = true
],
text_list = List.Transform( values_list, Text.From),
joined_string = Text.Combine( text_list, config[Separator] ),
values_list = if not config[UseSpecialSymbols] then source else
List.ReplaceMatchingItems( source,
{
// replace true null, and true empty strings (vs whitespace)
{ null, "␀"},
{ "#(cr,lf)", "#(240d)" }, // is #(2424)" }
{ "#(lf)", "" }, // is #(2424)" }
{"", "␠"}
} )
in
joined_string,
Powershell
Goto Everything
Goto /c/foo/bar
# go back
> Goto -Back
> Goto '-' # normal cd history works too
> Goto '+'
# Goto the world
$Profile | goto # go to string's path
Get-Item $PROFILE | goto # cd to the FileItem's path
gcm EditFunc | goto # jump to function declaration
gmo NameIt | Goto # go to module's folder
[CompletionResult] | goto # to docs for
# <https://docs.microsoft.com/en-us/dotnet/api/System.Management.Automation.CompletionResult>
# Open git repos in browser
goto git microsoft/powerquery-parser | goto
goto git@github.com:microsoft/powerquery-parser.git | goto
# goto the newest log
Get-ChildItem 'c:\root\manyLogs' -Recurse
| Sort LastWriteTime -desc -top 1 | goto
Is it a bug, or, is the extra y-axis padding working as intended in a situation where intended is not intended ( ie: column count orders of magnitude larger than the terminal’s column count )
# For every file fd finds, print the first 15 lines
PS> fd --exec-batch bat --line-range=:15 --paging=always
# forcing paging /on/off
PS> fd --exec-batch bat --line-range=:15 --paging=never
Pwsh🐒> # test whether it's resolved by coerce to [type]
'catman' -as 'type' -is 'type'
'batman' -as 'type' -is 'type'
True
False
Pwsh🐒> # test whether it's resolved by coerce to [type]
'catman' -as 'type' -is 'type'
'batman' -as 'type' -is 'type'
True
False
# after
Pwsh🐒> @(
# Declaring a new type in inside a [ScriptBlock]
& {
class batman { [string]$Name }
[batman]
}
# verses dotsourcing a type into the current scope
. {
class catman { [string]$Name }
[catman]
}) | ft -AutoSize
Namespace: <4cf9efd5>
Access Modifiers Name BaseType
------ --------- ---- --------
public class batman object
Namespace: <f2200555>
Access Modifiers Name BaseType
------ --------- ---- --------
public class catman object
# 1] highlight matches in red
# 2] preserves all lines
> history | grep --perl-regex --ignore-case --color=always 'less|$'
# 3] add paging
> history | grep --perl-regex --ignore-case --color=always 'less|$' | less --raw-control-chars
# 4] View a log
> less someLog
# 5 start on the last line of a log
> less +G someLog
Power Query Sugar for selecting distinct filters. If the condition is not true, then it throws an error. Name = "Orders" works because it results in a distinct value from the column Name It’s valid even though the final query is many records. It’s the “distinctness” of the filter that is required to be true