- Dec 2023
-
arxiv.org arxiv.org
-
TOKEN MERGING: YOUR VIT BUT FASTER
-
- Oct 2022
-
stedolan.github.io stedolan.github.io
-
Multiplying two objects will merge them recursively: this works like addition but if both objects contain a value for the same key, and the values are objects, the two are merged with the same strategy.
Unfortunately, it doesn't merge/concatenate arrays. Sometimes that's what you want (you want the 2nd value to override the 1st but sometimes not.
If you want it to concatenate instead, here are some workarounds:
-
https://stackoverflow.com/questions/53661930/jq-recursively-merge-objects-and-concatenate-arrays
-
If you only need/want to concatenate for some fixed list of keys, you could do it more simply like this (but could get repetitive to repeat for each key you want it for):
⟫ jq -n '[{hosts: ["a"]}, {hosts: ["b"]}] | .[]' | jq -s '.[0] * .[1] * {hosts: (.[0].hosts + .[1].hosts)}' { "hosts": [ "a", "b" ] }
-
-
- Feb 2021
-
github.com github.com
-
ActiveInteraction also supports merging errors. This is useful if you want to delegate validation to some other object. For example, if you have an interaction that updates a record, you might want that record to validate itself. By using the #merge! helper on errors, you can do exactly that.
-
Inside #execute, we merge errors. This is a convenient way to move errors from one object to another.
-
- Oct 2019
-
github.com github.com
-
Thank you for the update! I'll merge this into a next branch. Let's continue the work from there.
-
- Sep 2019
-
www.typescriptlang.org www.typescriptlang.org
-
www.bennadel.com www.bennadel.com
-
Injecting the static method, Array.isEmpty
-
- Jan 2014
-
sandofsky.com sandofsky.com
-
If you’re fighting Git’s defaults, ask why. Treat public history as immutable, atomic, and easy to follow. Treat private history as disposable and malleable. The intended workflow is: Create a private branch off a public branch. Regularly commit your work to this private branch. Once your code is perfect, clean up its history. Merge the cleaned-up branch back into the public branch.
Good defaults are sometimes hard to recognize, especially when the tool is complex.
Questioning the defaults-- and deciding why you would keep them or change them-- is a good antidote to dismissing something due to not understanding it.
If you can't understand why you don't like the defaults, then decide what you would choose instead and why you would change the default as it stands. Does the default make it easy to do the "right" thing AND hard to do the "wrong" thing? The second part of that statement is the most important since it might not be obvious what the "right" thing is.
Even if you don't like the defaults, ask yourself if they continually lead you away from perils and problems that would plague you if a different set of defaults were chosen?
Tags
Annotators
URL
-