Add example for secret.md for envFrom field

Hi,
As I am learning k8s. I find the secret is missing an example like configmap about evnFrom. So, I copy the example from configmap with a small change then add it back to secret.md file.
Best,
Alpha
reference
https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#configure-all-key-value-pairs-in-a-configmap-as-container-environment-variables

live preview : https://deploy-preview-20439--kubernetes-io-master-staging.netlify.app/docs/concepts/configuration/secret/

I'd vote for amending the tasks pages rather than adding more examples to the concept page.

I'd vote for amending the tasks pages rather than adding more examples to the concept page.

Sure. My original Idea just wants to remain the same example in ConfigMap and Secret page.
As I find that the documents in k8s.io are actually not that friendly and each page does not remain the same style. So I would like to improve it to enable more people to adopt k8s

/lgtm

Looking for some follow up PRs on further improvements!
/approve


XLA's Dot should follow broadcast semantics from np.matmul, not np.dot

I notice that the XLA Dot operation copies "outer-product style" broadcast semantics from numpy.dot:

Input
Output
Semantics

array [p x q x r] dot array [s x r x t]
array [p x q x s x t]
array dot product (read below)

In brief, I think this is a mistake. It would be better to follow the "matmul style" style broadcasting semantics of Python's @ operation and NumPy's matmul.
matmul's broadcasting is much more general, and in my opinion, also easier to understand. For example, it can do batch matrix-multiplication, but also can still do outer product style broadcasting if you insert dummy dimensions of length 1 (the axes do end up in a different order), e.g.,
batch match: [p x q x r] dot [p x r x t] -> [p x q x t]
outer product: [p x 1 x q x r] dot [1 x s x r x t] -> [p x s x q x t]
If we could go back in time as NumPy developers, we assuredly would change dot to work this way (now we cannot, because of backwards compatibility concerns). So it would be nice to change this for XLA before we lock in this behavior.

@cwhipkey, @andydavis1 and @prb12 , could you please comment on this? Thanks.

@shoyer thanks for the suggestion -- we'll think about it

Based on this input and other considerations, we've decided to restrict the semantics of XLA's Dot operation to 1D and 2D arrays in the initial release. We may consider expanding it to higher dimensions in the future, and at that point we'll be considering different possible semantics. For the time being, however, this issue can be closed.
Thanks for the feedback!


FuzzyTermEnums sets negative boost for fuzzy search & highlight [LUCENE-9568]

Description
When user indexes a word with an apostrophe and constructs a fuzzy query for highlighter, it throws an exception with set negative boost for a query.
Repro Steps

Index a text with apostrophe. E.g. doesn't
Parse a fuzzy query e.g.: se~, se~2, se~3
Try to highlight a text with apostrophe
The exception is thrown (for details see attached test test with repro steps)

Actual Result
java.lang.IllegalArgumentException: boost must be a positive float, got -1.0
Expected Result

No exception.
Highlighting marks are inserted into a text.

Workaround

not known.

Migrated from LUCENE-9568 by Juraj Jurčo, 1 vote, updated Oct 14 2020
Attachments: FindSqlHighlightTest.java

You might already be thinking of this beyond apostrophes, but just in case I've recently come across this (with Elasticsearch) for characters other than apostrophes, specifically Thai language characters (E.g. "การที่ได้ต้องแงงว่").


[SystemUiController] Remove @Stable from SystemUiController

@Stable has a strong contract:
 * When applied to a class or an interface, [Stable] indicates that the following must be true:
 *
 *   1) The result of [equals] will always return the same result for the same two instances.
 *   2) When a public property of the type changes, composition will be notified.
 *   3) All public property types are stable.

The current implementation of SystemUiController definitely does not adhere to item 2, since properties are being backed by calls to platform APIs that aren't snapshot state aware and won't notify composition if they change.
I'm not entirely sure what the ramifications are for having @Stable when the points above aren't satisfied, but it seems safest to remove @Stable?

Closing this for now, tracking in #1277


Add dereferenceUses plugin

This PR adds the dereferenceUses plugin, which dereferences <use/> elements, replacing it with the targeted node.
It also takes the special attribute inheritance rules into account.
You can already try this feature branch by installing it using this npm command:
npm install github:strarsis/svgo#dereferenceUses-plugin
Note that this plugin currently doesn't run by default and has to be explicitly enabled:
svgo --enable=dereferenceUses [...]
The original/source elements are kept by this plugin as those may still be needed,
but can (and will by default) be removed using the existing removeUselessDefs plugin (that runs afterwards by default).

I'm trying to run this using "svgo": "git://github.com/strarsis/svgo#dereferenceUses-plugin" as dependency, and then running the following command:
>npx svgo 9215d05705c8e8a7ebd718ae6f690371.svg --enable=dereferenceUses

9215d05705c8e8a7ebd718ae6f690371.svg:
Done in 42 ms!
15.119 KiB - 0% = 15.119 KiB

however, the resultant SVG still has all its <use...> in place:
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="423" height="75" viewBox="0 0 317 56"><defs>...snip...</defs><use xlink:href="#a" x="-.475" y="30.513"/><use xlink:href="#b" x="8.946" y="30.513"/><use xlink:href="#c" x="15.27" y="30.513"/><use xlink:href="#d" x="19.586" y="30.513"/><use xlink:href="#e" x="30.082" y="30.513"/><use xlink:href="#f" x="36.921" y="30.513"/><use xlink:href="#f" x="40.484" y="30.513"/><use xlink:href="#g" x="44.046" y="30.513"/><use xlink:href="#h" x="53.407" y="30.513"/><use xlink:href="#d" x="59.349" y="30.513"/><use xlink:href="#i" x="69.845" y="30.513"/><use xlink:href="#c" x="74.496" y="30.513"/><use xlink:href="#j" x="78.812" y="30.513"/><use xlink:href="#k" x="86.774" y="30.513"/><use xlink:href="#l" x="99.399" y="30.513"/><use xlink:href="#m" x="103.471" y="30.413"/><use xlink:href="#c" x="119.407" y="30.413"/><use xlink:href="#c" x="133.682" y="30.413"/><use xlink:href="#n" x="138.005" y="26.073"/><use xlink:href="#c" x="153.228" y="30.413"/><use xlink:href="#o" x="157.544" y="26.073"/><use xlink:href="#p" x="162.804" y="30.513"/><use xlink:href="#q" x="169.523" y="30.513"/><use xlink:href="#r" x="175.506" y="19.056"/><use xlink:href="#s" x="175.506" y="29.224"/><use xlink:href="#s" x="175.506" y="37.779"/><use xlink:href="#t" x="175.506" y="53.925"/><use xlink:href="#m" x="188.13" y="8.745"/><use xlink:href="#u" x="213.367" y="8.745"/><use xlink:href="#u" x="238.605" y="8.745"/><use xlink:href="#u" x="263.854" y="8.745"/><use xlink:href="#u" x="188.13" y="23.19"/><use xlink:href="#u" x="213.367" y="23.19"/><use xlink:href="#m" x="238.605" y="23.19"/><use xlink:href="#u" x="263.854" y="23.19"/><use xlink:href="#v" x="183.48" y="37.636"/><use xlink:href="#w" x="192.781" y="37.636"/><use xlink:href="#w" x="213.368" y="37.636"/><use xlink:href="#v" x="233.955" y="37.636"/><use xlink:href="#x" x="243.256" y="37.636"/><use xlink:href="#v" x="259.192" y="37.636"/><use xlink:href="#m" x="268.493" y="37.636"/><use xlink:href="#x" x="188.13" y="52.082"/><use xlink:href="#v" x="208.717" y="52.082"/><use xlink:href="#x" x="218.018" y="52.082"/><use xlink:href="#m" x="238.605" y="52.082"/><use xlink:href="#m" x="263.854" y="52.082"/><use xlink:href="#y" x="274.483" y="19.056"/><use xlink:href="#z" x="274.483" y="29.224"/><use xlink:href="#z" x="274.483" y="37.779"/><use xlink:href="#A" x="274.483" y="53.925"/><use xlink:href="#q" x="285.114" y="30.513"/><use xlink:href="#r" x="291.094" y="19.056"/><use xlink:href="#s" x="291.094" y="29.224"/><use xlink:href="#s" x="291.094" y="37.779"/><use xlink:href="#t" x="291.094" y="53.925"/><use xlink:href="#B" x="299.67" y="8.745"/><use xlink:href="#C" x="306.639" y="11.698"/><use xlink:href="#B" x="299.67" y="23.19"/><use xlink:href="#n" x="306.639" y="26.144"/><use xlink:href="#B" x="299.068" y="37.636"/><use xlink:href="#D" x="308.597" y="33.296"/><use xlink:href="#C" x="306.038" y="40.766"/><use xlink:href="#B" x="299.068" y="52.082"/><use xlink:href="#D" x="308.597" y="47.742"/><use xlink:href="#n" x="306.038" y="55.211"/><use xlink:href="#y" x="312.501" y="19.056"/><use xlink:href="#z" x="312.501" y="29.224"/><use xlink:href="#z" x="312.501" y="37.78"/><use xlink:href="#A" x="312.501" y="53.925"/></svg>

Github won't let me attach the SVG file itself, so here's the full content as code block:
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="423" height="75" viewBox="0 0 317 56"><defs><symbol overflow="visible" id="a"><path d="M9.281-8.438c0-.03-.219-.25-.328-.25a.701.701 0 00-.328.172l-.672.75c0 .016-.672-.921-2-.921-2.672 0-5.562 2.765-5.562 5.546C.39-1.17 2.016.266 3.844.266c1.031 0 2.078-.516 2.703-1.063C7.657-1.78 7.922-2.969 7.922-3c0-.125-.203-.031-.203-.031l-.125-.219c-.078 0-.344.156-.36.25-.109.344-.328 1.094-1.156 1.797-.812.672-1.422.828-2.047.828-1.078 0-2.156-.484-2.156-2.344 0-.687.188-2.531 1.39-3.922C4-7.5 4.986-8.062 6.048-8.062c1.219 0 1.719.796 1.719 2.187 0 .469-.032.484-.032.61 0 .109.329.25.375.25.157 0 .36-.157.407-.376zm0 0"/></symbol><symbol overflow="visible" id="b"><path d="M6.14-1.844c0-.11-.296-.25-.327-.25-.125 0-.344.188-.375.344-.204.781-.22 1.36-.704 1.36-.328 0-.171-.188-.171-.422 0-.266.03-.36.156-.891l.265-1.063.438-1.687c.078-.328.078-.36.078-.406 0-.204-.344-.454-.547-.454-.281 0-.656.407-.703.657h.406c-.218-.438-.765-.89-1.297-.89-1.406 0-3.078 1.89-3.078 3.64 0 1.125.86 2.031 1.781 2.031.25 0 .97-.078 1.422-.<IP_ADDRESS>7.61 <IP_ADDRESS>1 0 .827-.297 1.015-.688l.062-.093c.203-.438.297-1.094.297-1.094zm-2.03-2.25c0 .063-.016.14-.032.203l-.594 2.344c-.062.203 0 .14-.187.344-.531.656-.875.812-1.203.812-.594 0-.578-.53-.578-1 0-.593.328-1.968.593-2.515.375-.703.782-1.11 1.266-1.11.766 0 .734.844.734.922zm0 0"/></symbol><symbol overflow="visible" id="c"><path d="M4.14-5.156c0-.125-.312-.266-.53-.266h-.83c.39-1.562.453-1.797.453-1.875 0-.203-.328-.453-.53-.453-.032 0-.579.14-.688.563l-.422 1.765H.64c-.25 0-.563.14-.563.36 0 .156.297.28.531.28h.813C.594-1.515.547-1.311.547-1.093c0 .64.656 1.219 1.312 1.219 1.22 0 2.079-1.875 2.079-1.969 0-.11-.282-.25-.329-.25-.109 0-.328.172-.375.297C2.72-.547 2.281-.39 1.875-.39c-.25 0-.172-.03-.172-.421 0-.282.016-.375.063-.579l.859-3.39h.953c.25 0 .563-.125.563-.375zm0 0"/></symbol><symbol overflow="visible" id="d"><path d="M10.328-1.844c0-.11-.297-.25-.328-.25-.125 0-.328.172-.39.344-.172.64-.36 1.36-1.016 1.36-.203 0-.094.015-.094-.266 0-.297.11-.594.219-.844.219-.625.719-1.953.719-2.64 0-.766-.657-1.407-1.563-1.407-.89 0-1.64.563-2.094 1.203l.344.094c-.016-.156-.11-.656-.453-.953-.297-.25-.813-.344-1.11-.344-1.078 0-1.796.797-2 1.078l.329.094c-.063-.688-.75-1.172-1.282-1.172-.562 0-.921.5-1.03.719C.358-4.406.14-3.61.14-3.578c0 .125.484.219.484.219l-.14.03c.124 0 .328-.14.406-.405.203-.844.25-1.282.671-1.282.188 0 .172-.046.172.407 0 .265-.03.39-.187 1.015L.844-.844c-.031.188-.11.469-.11.516 0 .219.375.453.563.453.14 0 .547-.219.656-.547-.078.156.125-.5.203-.797l.266-1.078c.062-.265.14-.531.203-.797l.14-.594c.188-.374.626-1.328 1.766-1.328.532 0 .438.313.438.704 0 .296-.078.625-.172.984l-.344 1.39c-.11.438-.125.516-.234.907-.047.25-.157.656-.157.703 0 .219.375.453.547.453.375 0 .641-.422.735-.813l.718-2.875c.032-.156.47-1.453 1.782-1.453.515 0 .437.266.437.704 0 .671-.5 2.046-.734 2.671-.11.297-.156.422-.156.657 0 .562.625 1.109 1.187 1.109 1.11 0 1.75-1.875 1.75-1.969zm0 0"/></symbol><symbol overflow="visible" id="e"><path d="M6.688-1.844c0-.11-.297-.25-.344-.25-.11 0-.328.188-.375.344-.157.672-.188 1.36-.688 1.36-.25 0-.172-.032-.172-.422 0-.266.141-.829.235-1.25l.328-1.282c.047-.187.156-.64.203-.812.063-.282.188-.735.188-.797 0-.219-.36-.469-.547-.469-.047 0-.563.156-.657.563l-.906 3.593c-.015.047-.281.875-1.156.875-.625 0-.547-.406-.547-.859 0-.656.328-1.61.64-2.438.141-.359.204-.515.204-.75 0-.53-.578-1.109-1.172-1.109C.782-5.547.14-3.687.14-3.578c0 .125.484.219.484.219l-.14.03c.124 0 .328-.155.39-.343.297-1.031.563-1.344 1.016-1.344.109 0 .093-.125.093.266 0 .281-.125.625-.203.813-.437 1.171-.687 1.921-.687 2.5 0 1.14 1.015 1.562 1.672 1.562.78 0 1.343-.563 1.328-.5<IP_ADDRESS>.531 1.156.531.422 0 .828-.297 1.016-.688l.062-.093c.203-.438.297-1.094.297-1.094zm0 0"/></symbol><symbol overflow="visible" id="f"><path d="M3.219-8.203s-.14-.36-.297-.36c-.266 0-1.14.094-1.453.126-.094.015-.422.156-.422.374 0 .141.312.266.5.266.562 0 .375-.016.375.078l-.031.235L.375-1.5a1.376 1.376 0 00-.047.406c0 .672.719 1.219 1.281 1.219.407 0 .891-.36 1.094-.797C2.922-1.125 3-1.75 3-1.75l.063-.094c0-.11-.297-.25-.344-.25-.11 0-.328.188-.36.344-.203.781-.234 1.36-.703 1.36-.36 0-.172-.25-.172-.422 0-.282.016-.344.063-.579L3.28-8.297zm0 0"/></symbol><symbol overflow="visible" id="g"><path d="M7.516-6.734c0 .406-.125 1.125-.594 1.593-.313.313-.797.657-1.875.657h-1.11l.735-2.985c.078-.281-.078-.281.14-.312.11-.016.5-.016.735-.016.844 0 1.969-.125 1.969 1.063zM9.219-1.25c0-.14-.203-.047-.203-.047l-.141-.219c-.094 0-.328.22-.36.297-.296.89-.609.953-.874.953-.391 0-.297-.125-.297-.593 0-.375.078-.985.125-1.36a3.59 3.59 0 00.047-.562c0-.922-.985-1.422-1.313-1.547v.266C7.406-4.329 9.031-5.298 9.031-6.5c0-1.031-1.281-1.922-2.844-1.922H2.781c-.234 0-.547.125-.547.36 0 .14.313.265.532.265l.14-.031s.125.031.328.062c.204.016.11-.093.11.063 0 .047-.016.078-.047.219L1.703-1.063c-.<IP_ADDRESS>2-.89.422C.593-.64.28-.5.28-.266c0 .<IP_ADDRESS>.235L.656 0l1.5-.031L3.687 0c.094 0 .422-.125.422-.375 0-.125-.296-.266-.53-.266C3.14-.64 3-.5 3-.719c0-.062.031-.125.031-.203l.766-3.031h1.265c1.079 0 1.094.531 1.094.953 0 .172-.093.547-.172.828-.078.328-.187.766-.187 1.016C5.797.125 7.437.266 7.594.266c1.015 0 1.625-1.344 1.625-1.516zm0 0"/></symbol><symbol overflow="visible" id="h"><path d="M5.797-3.39c0-1.25-1.031-2.157-2.11-2.157-1.593 0-3.406 1.828-3.406 3.531C.281-.844 1.297.125 2.406.125c1.594 0 3.39-1.781 3.39-3.516zM4.53-3.86c0 .47-.187 1.626-.64 2.407-.407.687-.922 1.062-1.47 1.062-.515 0-.858-.25-.858-1.171 0-.594.25-1.782.64-2.391.594-.922 1.14-1.063 1.485-1.063.687 0 .843.438.843 1.157zm0 0"/></symbol><symbol overflow="visible" id="i"><path d="M4.156 2.719a.504.504 0 00-.11-.203c-1.234-.922-2-3.22-2-5.141v-1c0-1.906.767-4.203 2-5.14a.457.457 0 00.11-.188c0-.063-.25-.25-.312-.25a1.01 1.01 0 00-.203.062C2.312-8.156 1-5.67 1-3.625v1C1-.578 2.313 1.906 3.64 2.906a.997.997 0 00.204.063c.062 0 .312-.203.312-.25zm0 0"/></symbol><symbol overflow="visible" id="j"><path d="M3.64-2.625v-1c0-2.047-1.328-4.531-2.64-5.516a.774.774 0 00-.203-.062c-.063 0-.313.187-.313.25 0 .<IP_ADDRESS>.187 1.25.938 2.016 3.235 2.016 5.141v1c0 1.922-.766 4.219-2.016 5.14-.015.032-.094.157-.094.204 0 .<IP_ADDRESS>3.25A.774.774 0 001 2.906c1.313-1 2.64-3.484 2.64-5.531zm0 0"/></symbol><symbol overflow="visible" id="k"><path d="M8.828-4.281c0-.125-.312-.375-.437-.375H.906c-.125 0-.437.25-.437.375 0 .14.312.375.437.375h7.485c.125 0 .437-.235.437-.375zm0 2.328c0-.14-.312-.375-.437-.375H.906c-.125 0-.437.234-.437.375 0 .125.312.36.437.36h7.485c.125 0 .437-.235.437-.36zm0 0"/></symbol><symbol overflow="visible" id="l"><path d="M3.938 3.203c0-.14-.297-.375-.454-.375h-.859v-11.89h.86c.156 0 .453-.235.453-.376 0-.156-.297-.39-.454-.39H1.72V3.578h1.765c.157 0 .454-.234.454-.375zm0 0"/></symbol><symbol overflow="visible" id="m"><path d="M5.203-.125v-.516h-.578c-1.078 0-.922 0-.922-.437v-6.703c0-.282-.187-.438-.578-.438-.766.797-1.672.766-2.266.766v.625c.438 0 1.282-.031 1.563-.172v5.922c0 .437.172.437-.906.437H.937v.672C1.547-.03 2.595-.03 3.079-.03c.469 0 1.516 0 2.125.062zm0 0"/></symbol><symbol overflow="visible" id="p"><path d="M2.14-9.828H.579c-.14 0-.453.234-.453.39 0 .141.313.376.453.376h.86v11.89h-.86c-.14 0-.453.235-.453.375s.313.375.453.375h1.75V-9.828zm0 0"/></symbol><symbol overflow="visible" id="q"><path d="M2.484-3.125c0-.344-.468-.766-.828-.766-.343 0-.828.422-.828.766 0 .36.485.766.828.766.36 0 .828-.407.828-.766zm0 0"/></symbol><symbol overflow="visible" id="r"><path d="M7.922-17.703c0-.203-.344-.485-.547-.485H3.641V0H4.75v-17.219h2.625c.203 0 .547-.281.547-.484zm0 0"/></symbol><symbol overflow="visible" id="s"><path d="M4.75-.125v-12.094H3.64V0h1.11zm0 0"/></symbol><symbol overflow="visible" id="t"><path d="M7.922-.484c0-.204-.344-.5-.547-.5H4.75v-17.203H3.64V0h3.735c.203 0 .547-.281.547-.484zm0 0"/></symbol><symbol overflow="visible" id="u"><path d="M5.688-3.953c0-.953-.063-1.922-.47-2.797-.562-1.156-1.734-1.469-2.234-1.469-.718 0-1.796.438-2.28 1.547-.376.828-.438 1.766-.438 2.719 0 .89.109 2.062.593 2.969.516.968 1.532 1.25 2.11 1.25.656 0 1.75-.391 2.281-1.516.375-.828.438-1.766.438-2.703zm-1.391-.14c0 .89 0 1.702-.125 2.468C4-.485 3.516-.265 2.969-.265 2.516-.266 2-.438 1.78-1.579c-.125-.719-.125-1.813-.125-2.516 0-.765 0-1.562.094-2.203.219-1.422.922-1.406 1.219-1.406.406 0 .984.094 1.219 1.266.109.671.109 1.578.109 2.343zm0 0"/></symbol><symbol overflow="visible" id="v"><path d="M8.828-3.125c0-.125-.312-.36-.437-.36H.906c-.125 0-.437.235-.437.36 0 .14.312.375.437.375h7.485c.125 0 .437-.234.437-.375zm0 0"/></symbol><symbol overflow="visible" id="w"><path d="M5.656-2.172c0-.984-.953-2.047-2.187-2.297v.266c.984-.328 1.86-1.297 1.86-2.234 0-.985-1.235-1.782-2.391-1.782-1.204 0-2.313.844-2.313 1.75 0 .39.469.75.813.75.375 0 .796-.39.796-.734 0-.594-.75-.734-.656-.734.234-.36.89-.47 1.313-.47.484 0 .953.126.953 1.204 0 .14.031.734-.281 1.266-.36.578-.626.578-.922.578a4.76 4.76 0 01-.47.046c-.093.016-.374.157-.374.266 0 .14.281.266.484.266h.531c.985 0 1.22.687 1.22 1.86 0 1.624-.626 1.843-1.157 1.843-.516 0-1.266-.172-1.531-.<IP_ADDRESS>7-.375.687-.828 0-.437-.515-.796-.86-.796-.28 0-.874.296-.874.812C.297-.656 1.609.266 2.922.266c1.453 0 2.734-1.22 2.734-2.438zm0 0"/></symbol><symbol overflow="visible" id="x"><path d="M5.36-2.344h-.47c-.077.485-.109.922-.234 1.094-.078.11-.718.063-.984.063H1.89l1.03-1c1.86-1.657 2.642-2.391 2.642-3.579 0-1.375-1.266-2.453-2.735-2.453C1.484-8.219.391-7 .391-5.922c0 .656.796.797.843.797.204 0 .813-.281.813-.766 0-.312-.406-.75-.828-.75-.094 0-.125 0 .125-.093.187-.547.64-.86 1.328-.86 1.094 0 1.406.844 1.406 1.828 0 .954-.547 1.797-1.203 2.532L.578-.672C.453-.532.391-.422.391 0h4.812l.375-2.344zm0 0"/></symbol><symbol overflow="visible" id="y"><path d="M4.328-.125v-18.063H.594c-.203 0-.563.282-.563.485s.36.484.563.484h2.625V0h1.11zm0 0"/></symbol><symbol overflow="visible" id="z"><path d="M4.14-12.219h-.92V0h1.11v-12.219zm0 0"/></symbol><symbol overflow="visible" id="A"><path d="M4.328-.125v-18.063h-1.11V-.983H.595c-.203 0-.563.296-.563.5 0 .203.36.484.563.484h3.734zm0 0"/></symbol><symbol overflow="visible" id="B"><path d="M9.39-8.156c0-.094-.265-.266-.359-.266-.312 0-.656.031-.969.031-.406 0-.812-.03-1.187-.03-.078 0-.438.124-.438.358 0 .126.313.266.407.266.312.031.343.016.343.266 0 .187.157.547.157.547l-.282-.188-3.671 5.828.343.094-.812-6.313c0-.203.078-.234.625-.234.172 0 .5-.125.5-.36 0-.109-.297-.265-.36-.265-.484 0-1 .031-1.484.031-.219 0-.453-.015-.656-.015-.219 0-.453-.016-.656-.016-.079 0-.422.125-.422.36 0 .14.312.265.5.265.672 0 .484-.016.515.281L2.422-.14c.047.235.297.407.453.407.188 0 .36-.094.453-.25l4.313-6.86c.578-.922.953-.922 1.39-.953.156-.016.297-.266.297-.266zm0 0"/></symbol><symbol overflow="visible" id="n"><path d="M4.234-1.844H3.75c-.047.344-.063.735-.172.813-.062.047-.562 0-.687 0H1.812c.563-.5.86-.735 1.36-1.125.625-.5 1.265-1.14 1.265-1.938 0-1-1.093-1.781-2.171-1.781-1.032 0-1.954.89-1.954 1.656 0 .422.579.625.657.625.203 0 .656-.297.656-.61 0-.14-.266-.593-.422-.593.188-.437.547-.469.938-.469.843 0 1.062.5 1.062 1.172 0 .735-.453 1.203-.719 1.5l-2.03 2C.374-.516.311-.39.311 0h3.844l.313-1.844zm0 0"/></symbol><symbol overflow="visible" id="o"><path d="M4.516-1.61c0-.656-.75-1.468-1.672-1.656v.313c.89-.313 1.406-1.094 1.406-1.61 0-.656-.969-1.312-1.89-1.312-.938 0-1.86.61-1.86 1.281 0 .282.39.594.64.594.266 0 .641-.344.641-.578 0-.25-.375-.578-.297-.578.094-.11.532-.157.844-.157.375 0 .688.016.688.75 0 .344-.047.625-.266.891-.281.313-.36.281-.781.313-.203.015-.235.015-.266.015l.14.281s-.437-.109-.437-.015c0 .125.282.281.422.281h.453c.656 0 .922.297.922 1.188 0 1.046-.39 1.187-.89 1.187-.329 0-.922-.031-1.094-.266.078-.015.375-.453.375-.625 0-.265-.407-.625-.672-.625-.235 0-.672.297-.672.641C.25-.5 1.328.172 2.344.172 3.5.172 4.516-.766 4.516-1.61zm0 0"/></symbol><symbol overflow="visible" id="C"><path d="M4.172-.156v-.469H3.64c-.829 0-.625.063-.625-.219v-4.64c0-.235-.235-.391-.563-.391-.578.578-1.203.531-1.75.531v.625c.406 0 1.11-.047 1.219-.11v3.985c0 .281.203.219-.625.219h-.53v.64L2.469-.03l1.703.047zm0 0"/></symbol><symbol overflow="visible" id="D"><path d="M3.063-4.313c0-.25-.422-.609-.672-.609-.172 0-.563.281-.61.406l-1.5 3.72H1L2.922-3.97c.047-.062.14-.265.14-.344zm0 0"/></symbol></defs><use xlink:href="#a" x="-.475" y="30.513"/><use xlink:href="#b" x="8.946" y="30.513"/><use xlink:href="#c" x="15.27" y="30.513"/><use xlink:href="#d" x="19.586" y="30.513"/><use xlink:href="#e" x="30.082" y="30.513"/><use xlink:href="#f" x="36.921" y="30.513"/><use xlink:href="#f" x="40.484" y="30.513"/><use xlink:href="#g" x="44.046" y="30.513"/><use xlink:href="#h" x="53.407" y="30.513"/><use xlink:href="#d" x="59.349" y="30.513"/><use xlink:href="#i" x="69.845" y="30.513"/><use xlink:href="#c" x="74.496" y="30.513"/><use xlink:href="#j" x="78.812" y="30.513"/><use xlink:href="#k" x="86.774" y="30.513"/><use xlink:href="#l" x="99.399" y="30.513"/><use xlink:href="#m" x="103.471" y="30.413"/><use xlink:href="#c" x="119.407" y="30.413"/><use xlink:href="#c" x="133.682" y="30.413"/><use xlink:href="#n" x="138.005" y="26.073"/><use xlink:href="#c" x="153.228" y="30.413"/><use xlink:href="#o" x="157.544" y="26.073"/><use xlink:href="#p" x="162.804" y="30.513"/><use xlink:href="#q" x="169.523" y="30.513"/><use xlink:href="#r" x="175.506" y="19.056"/><use xlink:href="#s" x="175.506" y="29.224"/><use xlink:href="#s" x="175.506" y="37.779"/><use xlink:href="#t" x="175.506" y="53.925"/><use xlink:href="#m" x="188.13" y="8.745"/><use xlink:href="#u" x="213.367" y="8.745"/><use xlink:href="#u" x="238.605" y="8.745"/><use xlink:href="#u" x="263.854" y="8.745"/><use xlink:href="#u" x="188.13" y="23.19"/><use xlink:href="#u" x="213.367" y="23.19"/><use xlink:href="#m" x="238.605" y="23.19"/><use xlink:href="#u" x="263.854" y="23.19"/><use xlink:href="#v" x="183.48" y="37.636"/><use xlink:href="#w" x="192.781" y="37.636"/><use xlink:href="#w" x="213.368" y="37.636"/><use xlink:href="#v" x="233.955" y="37.636"/><use xlink:href="#x" x="243.256" y="37.636"/><use xlink:href="#v" x="259.192" y="37.636"/><use xlink:href="#m" x="268.493" y="37.636"/><use xlink:href="#x" x="188.13" y="52.082"/><use xlink:href="#v" x="208.717" y="52.082"/><use xlink:href="#x" x="218.018" y="52.082"/><use xlink:href="#m" x="238.605" y="52.082"/><use xlink:href="#m" x="263.854" y="52.082"/><use xlink:href="#y" x="274.483" y="19.056"/><use xlink:href="#z" x="274.483" y="29.224"/><use xlink:href="#z" x="274.483" y="37.779"/><use xlink:href="#A" x="274.483" y="53.925"/><use xlink:href="#q" x="285.114" y="30.513"/><use xlink:href="#r" x="291.094" y="19.056"/><use xlink:href="#s" x="291.094" y="29.224"/><use xlink:href="#s" x="291.094" y="37.779"/><use xlink:href="#t" x="291.094" y="53.925"/><use xlink:href="#B" x="299.67" y="8.745"/><use xlink:href="#C" x="306.639" y="11.698"/><use xlink:href="#B" x="299.67" y="23.19"/><use xlink:href="#n" x="306.639" y="26.144"/><use xlink:href="#B" x="299.068" y="37.636"/><use xlink:href="#D" x="308.597" y="33.296"/><use xlink:href="#C" x="306.038" y="40.766"/><use xlink:href="#B" x="299.068" y="52.082"/><use xlink:href="#D" x="308.597" y="47.742"/><use xlink:href="#n" x="306.038" y="55.211"/><use xlink:href="#y" x="312.501" y="19.056"/><use xlink:href="#z" x="312.501" y="29.224"/><use xlink:href="#z" x="312.501" y="37.78"/><use xlink:href="#A" x="312.501" y="53.925"/></svg>

@Pomax: Oh right, sorry, that I hadn't explicitly mentioned this, but the plugin is not enabled by default (as this may not always be wished for default optimization) and has to be explicitly enabled when using svgo (CLI or config):
svgo --enable=dereferenceUses [...]

right, but that's what I used?

Maybe I'm doing something wrong here, but I'm not seeing it replace the the <use> elements yet... I reinstalled installed your branch by first uninstalling svgo and confirming it was gone, then setting "svgo": "git://github.com/strarsis/svgo#dereferenceUses-plugin" in package.json and running npm install. I verified that it indeed puts your branch in node_modules by checking the file tree: the svgo/plugins/dereferenceUses.js exists.
I then tried both npx svgo 9215d05705c8e8a7ebd718ae6f690371.svg --enable=dereferenceUses and npx svgo --enable=dereferenceUses 9215d05705c8e8a7ebd718ae6f690371.svg but in both cases the resultant file still ends with that huge block of <use xlink:href="#..." x="..." y="..."/> instructions.

@Pomax: This may be the explanation. Try ./bin/svgo instead, to ensure the svgo executable from the feature branch is used, not some globally installed svgo (in system PATH).

@Pomax: Alright, the reason was that the dereferenceUses plugin had not been listed in the .svgo.yml, this is always necessary.
I pushed a fix to the feature branch. Please reinstall and then invoke svgo:
`./bin/svgo --enable=derferenceUses 9215d05705c8e8a7ebd718ae6f690371.svg -o 9215d05705c8e8a7ebd718ae6f690371.min.svg

aha! let me give it another go =)

Side note: All <use/>d elements from <symbol/> are placed inside a <svg> element (as browsers would do).
However, using the symbolContainer plugin option, g can also be used. Then the collapseGroups plugin can be used to unwrap single, wrapped SVG elements. Note that the current version of the collapseGroups plugin seems to have issues with some wrapped elements, notably <path>, as such does not support the x/y attributes, and transform has to be used instead.
This is outside of the scope of the dereferenceUses plugin and this PR. The collapseGroup plugin requires a fix that makes it able to apply the x/y attributes of the wrapping element <g/> onto the the <path/> elements as transform or some other supported mechanism of positional translation.

Sweet, that's working quite well now. It grows the file, of course, but the improvement in inspectability and (with --pretty) readability is night and day. Awesome work!

@Pomax: Please also notice the side note above! It is possible to unwrap these elements using the existing, built-in collapseGroups plugin, however, the plugin has some issues with <path/> elements as these don't support the x and y attribute.

I do notice that all the nested <svg> have overflow="visible" which a single <style>:root > svg { overflow: visible }</style> would take of, would it make sense to add that in to shave off some more bytes? For files like these, that's 1~2kb saved because of the crazy number of <use...> =)
(specifically, this, and about 250 files like it, are the result of running a latex -> pdfcrop -> pdf2svg -> svgo chain)

@Pomax: It may be negligible, always check the gzipped file size of the SVG.
Either by uploading + getting the SVG and checking the actual size in Network tab of Web Developer Tools or by compressing the SVG file yourself using the gzip command: gzip input.svg.

fair point: once gzip is involved there is no size difference.

@Pomax: There is the inlineStyles plugin. Another, "externalizeStyles" plugin was planned, that could try to move all inline styles to external styles and simplify, but with GZIP it may be too much of a hassle.

yeah definitely. Plus, for what I need, externalizing styles is not really an option, the files need to stay self-contained. If gzip/brotli makes it a non-optimization over the wire, then no reason to try to micro-optimize there.

I think this PR got lost: is it still possible to land this?

I think this PR got lost: is it still possible to land this?

How can I resolve this file conflict? I can't select the Resolve conflicts button.

@TrySound: Ready to merge! The collapseGroup plugin needs a fix, in another PR.

It appear that a style attribute on a <use> element causes a problem. Here is a minified example:
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 1 1" height="64" width="64">
    <defs>
        <symbol id="a" overflow="visible">
            <path/>
        </symbol>
    </defs>
    <use xlink:href="#a" style="fill:#000"/>
</svg>

@@@

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 1 1" height="64" width="64">
    <defs>
        <symbol id="a" overflow="visible">
            <path/>
        </symbol>
    </defs>
    <svg style="fill:#000">
        <path/>
    </svg>
</svg>

@@@

{"keepHref":true}

And the resulting error:
TypeError: properties.forEach is not a function
      at CSSStyleDeclaration.getCssText (lib/svgo/css-style-declaration.js:121:14)
      at CSSStyleDeclaration.getStyleValue (lib/svgo/css-style-declaration.js:56:15)
      at Function.entries (<anonymous>)
      at JS2SVG.createAttrs (lib/svgo/js2svg.js:292:38)
      at JS2SVG.createElem (lib/svgo/js2svg.js:271:12)
      at JS2SVG.convert (lib/svgo/js2svg.js:100:19)
      at JS2SVG.createElem (lib/svgo/js2svg.js:261:27)
      at JS2SVG.convert (lib/svgo/js2svg.js:100:19)
      at module.exports (lib/svgo/js2svg.js:50:29)
      at optimize (lib/svgo.js:49:13)
      at /home/zoey/repos/svgo/test/plugins/_index.js:34:26

@zoeyfyi: I added your plugin test and indeed the test run fails now.

I have a fix here. From my limited understanding, here is what I discovered:

Map's become objects with the JSON seralize/deseralize deep clone trick, hence the properties.forEach is not a function error (https://github.com/zoeyfyi/svgo/blob/49533cf48a3216747d6aa7d45ed266cc5fef9f6b/lib/svgo/css-style-declaration.js#L35)
The addAttr method does not handle adding style attributes correctly (https://github.com/zoeyfyi/svgo/blob/49533cf48a3216747d6aa7d45ed266cc5fef9f6b/plugins/dereferenceUses.js#L68)

@zoeyfyi: Fix for the underlying issue: zoeyfyi

@TrySound: Ready to merge! 🐱

@TrySound: So I looked further into the visitor pattern for plugins.
Should the plugin traverse all the <use> and target nodes on its own and map them to each other -
or just use the root node and use querySelectorAll/querySelector to query for these elements?

See https://github.com/svg/svgo/pull/1624
You can collect all elements why traversing and finish transformations in root.exit

@strarsis just notice this is still taking up space in my "mentioned PRs" list, given how long it's taken for it not to get merged in, it's probably worth closing?

parentNode is passed to element callback in visitor
structuredClone can copy elements

@TrySound: The tests all pass except for the regressions test, but not because of the plugin but of a failing test setup.
An additional, separate PR fixes that issue: https://github.com/svg/svgo/pull/1759
A polyfill for structuredClone is added for support of the older node versions that are tested against.

Any updates on this?

Also note that structuredClone does not need a polyfill, literally everything supports it.

@kuhler-Stratege, @Pomax: I merged all the changes and updated the plugin code and documentation.

Due to how long this PR's been taking, all versions of Node that are still in support, support structuredClone.

The CI tests still include Node 16 which does not natively support structuredClone and requires a polyfill:
https://github.com/svg/svgo/actions/runs/10619846377/job/29438306446?pr=1279

Note that Node 16 is no longer supported by Node itself, the current maintenance LTS is v18 and active LTS is v20 - it should definitely be removed from any CI tasks with svgo itself bumped up a major version. The benefit of semver: no one is inconvenienced.

All checks are passing except the node version 16 one (that may have to be removed).
Except for two lines (that are only used for type-correctness) the plugin has full test coverage.
So from my perspective the plugin is ready to be merged in.
One thing though: How can I force this plugin to run before/after specific other plugins,
even with this plugin being not one in the default preset?

@TrySound is there anyone else who can marked as reviewer? Sure, it's been years, but if the plugin still works, no reason to not still land it =)

@SethFalco ☝🏻


Should I worry? "[Violation] 'requestAnimationFrame' handler took 80ms"

hey man,
I keep seeing that message in console. Is it debug?

don't worry, change the log level in Chrome to not show the level 'Verbose'

thanks.


Use Bazel's builtin patch support.

This removes a dependency on the system having a patch executable.

We had issues in the past where patching wouldn't work on Windows/Linux. We have tried git patch, git apply and patch.
Adding gunan@ to verify if this is likely to solve all issues form above and if the diffs are also ok, as I was not expecting them to be generated given PR title/description

I had to regenerate some of the patch files because the builtin patch is stricter than patch(1). (Basically, I just did patch -p1 old.patch and diff -ru.)

As long as presubmits pass, I think we can accept this change.

Only "Windows Bazel GPU " appears to have failed, but it also is broken on master.

Will import this manually, something breaks


Proposed fix for Issue 52

This is in reference to https://github.com/GitGuardian/gg-shield/issues/52
Don't throw exception when CWD is /
Do throw an exception when git is not found
Update exception message to indicate situation (not found vs rejected)
Enhance PATH/CWD comparisons to avoid symlinks from causing issues

Regarding the lint fail, that appears to be a mypy bug.

Codecov Report

Merging #53 (6cc0b77) into main (18b72b4) will decrease coverage by 0.03%.
The diff coverage is 85.71%.

@@            Coverage Diff             @@
##             main      #53      +/-   ##
==========================================
- Coverage   89.62%   89.59%   -0.04%
==========================================
  Files          24       24
  Lines        1176     1182       +6
==========================================
+ Hits         1054     1059       +5
- Misses        122      123       +1

Flag
Coverage Δ

unittests
89.59% <85.71%> (-0.04%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

ggshield/git_shell.py
70.42% <85.71%> (+0.72%)
:arrow_up:

ggshield/cmd.py
85.91% <0.00%> (+0.20%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 45c3534...6cc0b77. Read the comment docs.


Provide value name when provider not available

This implementation doesn't work, as null return is an accepted value for valueOrNull methods.


Add element to model created with Capella 6.0.0 failed

I have a model created with Capella 6.0.0  and want to add a component.
I used the following code to do this.
model = capellambse.MelodyModel(path_to_model, jupyter_untrusted=True)
newitem = model.pa.root_component.owned_components.create(name='Test')

This leads to the following error:
ValueError: Namespace 'org.polarsys.capella.core.data.pa' already registered with URI 'http://www.polarsys.org/capella/core/pa/6.0.0'

By checking the source I found out that only the first plugin version is added to the NAMESPACES dict.
Changing the order of the versions and the script runs without any problem.
file: _namespaces.py
        "org.polarsys.capella.core.data.pa": Plugin(
            "http://www.polarsys.org/capella/core/pa/", ("6.0.0", "5.0.0")
        ),

Is there a way to define which version shall be loaded to the global NAMESPACES dict?
Regards,
Andreas

This unfortunately comes down to how capellambse handles namespaces in general, and is somewhat difficult to solve properly in place. However, we're currently working on a rewrite of the core model component, which will address this and several other issues.
#277 changed the ValueError you're seeing to a warning message, which should at least alleviate the immediate issue of it crashing. Please update with pip install -U capellambse and you should be good to go.

Thanks for the fast reply. Its working!


documentation with examples

documentation with examples and use cases

In progress gitbook.io/types-ddd/

In progress gitbook.io/types-ddd :rocket:

This tools may helps to generate modules and files
https://github.com/4lessandrodev/types-generator


Add support for cross-compilation with Nix

The aim here is to build fully statically-linked binaries for Linux and Windows. This will make distribution easier. I particularly have in mind Steam games which distribute Monpad.
Various potentially-useful links about building static Haskell binaries:

https://cabal.readthedocs.io/en/3.6/cabal-project.html?highlight=--enable-executable-static#cfg-flag---enable-executable-stati
https://www.reddit.com/r/haskell/comments/ssxb65/generating_static_binary_ci_questions/
https://input-output-hk.github.io/haskell.nix/tutorials/cross-compilation.html
https://www.joachim-breitner.de/blog/776-Distributing_Haskell_programs_in_a_multi-platform_zip_file#cb18-9
https://github.com/NixOS/nixpkgs/issues/43795
https://github.com/tweag/rules_haskell/pull/1390
https://vaibhavsagar.com/blog/2018/01/03/static-haskell-nix/
https://www.reddit.com/r/haskell/comments/rm664w/notes_on_distributing_crossplatform_haskell/

We should also look at the setups of projects that do this (GHCup, HLS, Dhall...). Also note that we can't legally link GMP statically. Fortunately support for native Haskell bignums was recently added to Haskell.nix.

This looks interesting: https://gitlab.com/macaroni.dev/macaroni.nix.


Update .gitignore

prevent your autoplaylist.txt to get overwritten on update

All my carefully picked songs were gone after an update :'(

This is already in review. https://github.com/Just-Some-Bots/MusicBot/blob/review/.gitignore#L12


Scan + Xcode 13.1: WARNING: Using the first of multiple matching destinations

When using scan with Xcode 13.1
scan({
    devices: ["iPhone 13"],
    ....
  })

there is a warning:
WARNING: Using the first of multiple matching destinations
This makes it harder to have CI logs cleaner to easier find some errors.

🚫 fastlane environment 🚫
Stack

Key
Value

OS
12.0.1

Ruby
3.0.2

Bundler?
false

Git
git version 2.33.0

Installation Source
~/.gem/bin/fastlane

Host
macOS 12.0.1 (21A559)

Ruby Lib Dir
~/.rbenv/versions/3.0.2/lib

OpenSSL Version
OpenSSL 1.1.1l  24 Aug 2021

Is contained
false

Is homebrew
false

Is installed via Fabric.app
false

Xcode Path
/Applications/Xcode-13.1..app/Contents/Developer/

Xcode Version
13.1

Swift Version
5.5.0

System Locale

Error

No Locale with UTF8 found 🚫

fastlane gems

Gem
Version
Update-Status

fastlane
2.197.0
✅ Up-To-Date

Loaded fastlane plugins:

Plugin
Version
Update-Status

fastlane-plugin-appcenter
1.11.1
✅ Up-To-Date

Loaded gems

Gem
Version

did_you_mean
1.5.0

atomos
0.1.3

claide
1.0.3

colored2
3.1.2

nanaimo
0.3.0

rexml
3.2.5

xcodeproj
1.21.0

rouge
2.0.7

xcpretty
0.3.0

terminal-notifier
2.0.0

terminal-table
1.8.0

plist
3.6.0

public_suffix
4.0.6

addressable
2.8.0

multipart-post
2.0.0

word_wrap
1.0.0

optparse
0.1.1

tty-screen
0.8.1

tty-cursor
0.7.1

tty-spinner
0.9.3

artifactory
3.0.15

babosa
1.0.4

colored
1.2

highline
2.0.3

commander
4.6.0

unf
0.1.4

domain_name
0.5.20190701

http-cookie
1.0.4

faraday-cookie_jar
0.0.7

fastimage
2.2.5

gh_inspector
1.1.3

mini_magick
4.11.0

naturally
2.2.1

rubyzip
2.3.2

security
0.1.3

xcpretty-travis-formatter
1.0.1

dotenv
2.7.6

simctl
1.6.8

google-cloud-env
1.5.0

google-cloud-core
1.6.0

google-cloud-storage
1.34.1

tsort
0.1.0

uri
0.10.1

set
1.0.1

CFPropertyList
3.0.4

unicode-display_width
1.8.0

excon
0.88.0

ruby2_keywords
0.0.5

faraday-rack
1.0.0

faraday-patron
1.0.0

faraday-net_http_persistent
1.2.0

faraday-net_http
1.0.1

faraday-httpclient
1.0.1

faraday-excon
1.1.0

faraday-em_synchrony
1.0.0

faraday-em_http
1.0.0

faraday
1.8.0

unf_ext
0.0.8

faraday_middleware
1.2.0

json
2.6.1

bundler
2.2.26

jwt
2.3.0

webrick
1.7.0

httpclient
2.8.3

multi_json
1.15.0

signet
0.16.0

os
1.1.1

memoist
0.16.2

googleauth
1.1.0

mini_mime
1.1.2

retriable
3.1.2

trailblazer-option
0.1.1

declarative
0.0.20

uber
0.1.0

representable
3.1.1

google-apis-core
0.4.1

google-apis-playcustomapp_v1
0.6.0

google-apis-androidpublisher_v3
0.13.0

google-cloud-errors
1.2.0

google-apis-iamcredentials_v1
0.8.0

google-apis-storage_v1
0.9.0

rake
13.0.6

digest-crc
0.6.4

emoji_regex
3.2.3

aws-eventstream
1.2.0

aws-sigv4
1.4.0

aws-partitions
1.525.0

jmespath
1.4.0

aws-sdk-core
3.122.0

aws-sdk-kms
1.51.0

aws-sdk-s3
1.105.0

forwardable
1.3.2

logger
1.4.3

pathname
0.1.0

shellwords
0.1.0

cgi
0.2.0

date
3.1.0

timeout
0.1.1

stringio
3.0.0

openssl
2.2.0

io-nonblock
0.1.0

ipaddr
1.2.2

io-wait
0.1.0

zlib
1.1.0

resolv
0.2.0

securerandom
0.1.0

digest
3.0.0

time
0.1.0

open-uri
0.1.0

mutex_m
0.1.1

net-protocol
0.1.0

rack
2.2.3

rack-test
1.1.0

fileutils
1.5.0

tempfile
0.1.1

delegate
0.2.0

tmpdir
0.1.2

ostruct
0.3.1

strscan
3.0.0

english
0.7.1

erb
2.2.0

abbrev
0.1.0

io-console
0.5.7

base64
0.1.0

singleton
0.1.1

net-http
0.1.1

open3
0.1.1

nkf
0.1.0

nokogiri
1.12.5

racc
1.6.0

prettyprint
0.1.0

pp
0.1.0

find
0.1.0

yaml
0.1.1

psych
3.3.0

fastlane-plugin-appcenter
1.11.1

csv
3.2.0

generated on: 2021-11-05

xcrun instruments -s devices should be change to:
xcrun xctrace list devices

react-native fix: https://githubmemory.com/repo/facebook/react-native/issues/32331

@joshdholtz just FYI.

look's like still relevant for Xcode 13.2 RC

And still an issue with Xcode 13.2 proper.

Looks to still be a problem with Xcode 13.2.1
Has anybody managed to workaround this problem? I'm getting stuck with an error because it's not picking up the device I'm specifying? (Any iOS Device is the first one it picks up)

xcodebuild: error: Failed to build project XXX with scheme XXX
Reason: Cannot test target “UnitTests” on “Any iOS Device”: Tests must be run on a concrete device

@gobetti Hey 👋  So I am specifying a device (iPhone 12 Pro) but it's not detecting it which is, on reflection, showing a slightly different error to the one mentioned here. I'll open a new issue with my details as to not distract from this thread. Apologies all.

I'm getting this issue as well.  It's just a warning but it's bothersome.  The message logs when xcodebuild -resolvePackageDependencies is running.  It's called without a destination presumably because it doesn't need one to do the job, but xcodebuild thinks it is.
The source lane:
  lane :swiftui_unit_tests do
    scan(
      workspace: "Heap-Integration.xcworkspace",
      scheme: "Heap.SwiftUI",
      testplan: "SwiftUI Unit Tests",
      destination: "platform=iOS Simulator,id=#{@udid}",
      result_bundle: true,
      include_simulator_logs: false
    )
  end

The message:
[15:53:09]: ------------------
[15:53:09]: --- Step: scan ---
[15:53:09]: ------------------
[15:53:09]: Resolving Swift Package Manager dependencies...
[15:53:09]: $ xcodebuild -resolvePackageDependencies -workspace Heap-Integration.xcworkspace -scheme Heap.SwiftUI
[15:53:10]: ▸ Command line invocation:
[15:53:10]: ▸     /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -resolvePackageDependencies -workspace Heap-Integration.xcworkspace -scheme Heap.SwiftUI
[15:53:10]: ▸ User defaults from command line:
[15:53:10]: ▸     IDEPackageSupportUseBuiltinSCM = YES
[15:53:11]: ▸ Resolve Package Graph
[15:53:11]: ▸ Resolved source packages:
[15:53:11]: ▸   Swifter: https://github.com/heap/swifter.git @ 1.4.7-Xcode12
[15:53:11]: ▸ --- xcodebuild: WARNING: Using the first of multiple matching destinations:
...

any news here? thx

I am also facing the exact same issue as described originally. Is there any plan regarding this?

+1
▸ --- xcodebuild: WARNING: Using the first of multiple matching destinations:

Same here, and the even more annoying thing with this warning is that, since we're using Buildkite as a CI, and any line starting with --- is interpreted as a collapsible section in the logs, this makes it super hard to navigate the logs, and cut the logs into sections in random places which don't make sense, hiding important sections (like actual fastlane steps running) under those.
Concrete Example
Here's a concrete example of how it makes it all quite unusable in our CI logs:

In the example above our Fastfile's lane looks something like this (over-simplified):
scan(build_for_testing: true, …)
create_missing_simulators_for_screenshots # custom lane of ours
[true, false].each do |dark_mode_enabled|
      capture_ios_screenshots(…, test_without_building: true, dark_mode: dark_mode_enabled, devices: …)
end

And in the CI logs screenshoted above, this shows like this

xcodebuild: WARNING: Using the first of multiple matching destinations: | 4s (mostly empty, just list of sims)
xcodebuild: WARNING: Using the first of multiple matching destinations: | 11s (mostly empty, just list of sims)
xcodebuild: WARNING: Using the first of multiple matching destinations: | 11s (mostly empty, just list of sims)
xcodebuild: WARNING: Using the first of multiple matching destinations: | 8m 43s

"Summary for scan 2.206.2" ASCII table
Invocation of scan ("Compiling …" logs)
Call of our custom create_missing_simulators_for_screenshots lane
Header for "Step: capture_ios_screenshots"
Calls for xcodebuild -resolvePackageDependencies and xcodebuild -showBuildSettings made by that action
And that's it; the logs for the actual run of capture_ios_screenshots (aka snapshot) are in another section below instead.

xcodebuild: WARNING: Using the first of multiple matching destinations: | 3s (mostly empty, just list of sims)
xcodebuild: WARNING: Using the first of multiple matching destinations: | 18s (mostly empty, just list of sims)
xcodebuild: WARNING: Using the first of multiple matching destinations: | 8s (mostly empty, just list of sims)
xcodebuild: WARNING: Using the first of multiple matching destinations: | 12m 15s

"Summary for snapshot 2.206.2" ASCII table
Logs for that actual first run of snapshot (aka capture_ios_screenshots)
"snapshot results" ASCII table
Header for "Step: capture_ios_screenshots" (the 2nd invocation, for dark mode)
Calls for xcodebuild -resolvePackageDependencies and xcodebuild -showBuildSettings made by that action
And that's it; the logs for the actual run of capture_ios_screenshots (aka snapshot) are in another section below instead.

xcodebuild: WARNING: Using the first of multiple matching destinations: | 3s (mostly empty, just list of sims)
xcodebuild: WARNING: Using the first of multiple matching destinations: | 4s (mostly empty, just list of sims)
xcodebuild: WARNING: Using the first of multiple matching destinations: | 11s (mostly empty, just list of sims)
xcodebuild: WARNING: Using the first of multiple matching destinations: | 9m 5s

"Summary for snapshot 2.206.2" ASCII table (the 2nd run for dark mode)
Logs for that actual first run of snapshot (aka capture_ios_screenshots)
"snapshot results" ASCII table
"fastlane summary" final ASCII table

You can see how those unwanted --- xcodebuild: WARNING: … spread into our logs completely mess up everything and makes it quite complicated to follow and debug our logs!

i think, i know the fix to resolve this warning... 🤞  will try to open a PR to test...and update this thread

still happening with 2.207.0


Index out of range when using dict on AUDITLOG_INCLUDE_TRACKING_MODELS

Stack trace:
│ Traceback (most recent call last):                                                                                │
│   File "/app/manage.py", line 33, in <module>                                                                                │
│     main()                                                                                │
│   File "/app/manage.py", line 29, in main                                                                                │
│     execute_from_command_line(sys.argv)                                                                                │
│   File "/opt/pysetup/.venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 442, in execute_from_command_line                                                                                │
│     utility.execute()                                                                                │
│   File "/opt/pysetup/.venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 416, in execute                                                                                │
│     django.setup()                                                                                │
│   File "/opt/pysetup/.venv/lib/python3.10/site-packages/django/__init__.py", line 24, in setup                                                                                │
│     apps.populate(settings.INSTALLED_APPS)                                                                                │
│   File "/opt/pysetup/.venv/lib/python3.10/site-packages/django/apps/registry.py", line 124, in populate                                                                                │
│     app_config.ready()                                                                                │
│   File "/opt/pysetup/.venv/lib/python3.10/site-packages/auditlog/apps.py", line 12, in ready                                                                                │
│     auditlog.register_from_settings()                                                                                │
│   File "/opt/pysetup/.venv/lib/python3.10/site-packages/auditlog/registry.py", line 322, in register_from_settings                                                                                │
│     self._register_models(settings.AUDITLOG_INCLUDE_TRACKING_MODELS)                                                                                │
│   File "/opt/pysetup/.venv/lib/python3.10/site-packages/auditlog/registry.py", line 263, in _register_models                                                                                │
│     model["model"] = self._get_model_classes(model["model"])[0]                                                                                │
│ IndexError: list index out of range

My relevant settings look like this:
AUDITLOG_INCLUDE_TRACKING_MODELS = (
    {
        "model": "django.contrib.auth.models.User",
        "include_fields": [
            "username",
            "email",
            "groups",
            "user_permissions",
            "is_staff",
            "is_active",
            "is_superuser",
        ],
        "exclude_fields": ["last_login", "password", "date_joined"],
    },
)

Secondary note that this doesn't result in an exception:
AUDITLOG_INCLUDE_TRACKING_MODELS = (
    "django.contrib.auth.models.User",
)

but it also doesn't result in the User model being tracked.

The model in AUDITLOG_INCLUDE_TRACKING_MODELS should be in <appname>.<model1> format.
Probably it can be fixed by replacing "model": "django.contrib.auth.models.User", with "model": "django.contrib.auth.User",


Create fontbakery-list-variable-source.py

Simple inspector from Marc

@m4rc1e I'll merge it as-is since the issues I saw seem harmless, but during code-review I have added 2 comments and I would be happy if you could address those in a subsequent pull request with those values being passed as command line attributes.


Make classes Open instead of Public (Swift 3)

I'm wanting to create a subclass of ScannedPeripheral or Peripheral (to add a property). In Swift 3, I can't just do "class pairingPeripheral: ScannedPeripheral { ..." -- that throws and error "Cannot inherit from non-open class ScannedPeripheral outside its defining module" ...
Changing Public to Open in the various classes would fix ...

Hello @jack4git
What is your case for inheriting? Why don't you just compose this additional property and ScannedPeripheral in new object?
Just trying to find out, maybe it makes sense :)
Regards,
Kacper

Hey Kacper -- apologies for delay in responding.
My workaround was composing as you suggested.
So my question is, are you intentionally keeping access to Public to prevent subclassing because it's a bad idea? Or is this just a new Swift 3 feature that you aren't yet taking advantage of?

Hello,
It's not our intent to use this Swift 3 feature, because in our opinion subclassing in this case is unncessary. We've designed classes as closed components that shouldn't be modified(at least we don't see any profit from this).
In fact I think that it would be a good idea to mark these classes as final and we will do it in next version of library.

Thanks for quick response --


Remove override in User show for labels

Remove the overrides in user show adde here: https://github.com/psu-stewardship/scholarsphere/commit/a550bb6b385f2fc0d106fb63db76d14fb6689dbc
Make sure this ticket has been closed in sufia: projecthydra/sufia#1056

Check in SUfia 6.3  This is not quite fixed.  When the user has no highlights the wording still says files.

Looks like ti was put in the PCDM version of sufia.

Verify, or backport to Sufia 6 from Sufia 7.

Backported in projecthydra/sufia#1524


Missing Files

Missing following Genome files for the Free Bayes and GATK variant analysis scripts Step 3 f are missing
1- 1000G_omni2.5.hg38.vcf.gz and (.tbi)
2- 1000G_phase1.snps.high_confidence.hg38.vcf.gz and(.tbi)
3- hapmap_3.3.hg38.vcf.gz and (.tbi)
Missing files are present in /proj/eva-public-PG0/Genome_Data

#!/usr/bin/env bash

DEST_DIR="/mydata"
SOURCE_DIR="/proj/eva-public-PG0/Genome_Data/"
FILES=(
"1000G_omni2.5.hg38.vcf.gz"
"1000G_omni2.5.hg38.vcf.gz.tbi"
"1000G_phase1.snps.high_confidence.hg38.vcf.gz"
"1000G_phase1.snps.high_confidence.hg38.vcf.gz.tbi"
"hapmap_3.3.hg38.vcf.gz"
"hapmap_3.3.hg38.vcf.gz.tbi"
)

for file in "${FILES[@]}"; do
        echo $file
	cp $SOURCE_DIR$file $DEST_DIR
done


Duck typing verification made easier

I find that I keep making wrappers around these to make it easier to duck-type them in, as well as verify that the ducked-type pertains to a result of one of the Wrapper type functions, and I figured it may be worthwhile to share.
Completely understandable if this is rejected on the grounds that it is a breaking change (albeit a minor one), in exchange for a non-global use-case. My personal use case for this lies mainly in making and using functions which only care about one or two particular capabilities of a vtable parameter, without having to rely on the looseness of duck-typing.
Addendum: it was after the last pull request I made about changing the {}Wrapper type functions to take in a slice of {}Command that I realized I hadn't entirely solved the issue of comptime memoization over generic functions, since comptime slices in stage1 are not guaranteed to be equal regardless of contents, due to possibly different pointers, so this is also, in part, a sort of amendment to that.

Something that was on my mind was to provide easier ways of combining function pointers from multiple extensions. My plan was to predefine a []Command for every extension, which you would be able to concatenate at build to get the complete list of commands. I think that would look something along the lines of
const commands = vk.device_commands.v1_0
  ++ vk.device_commands.swapchain
  ++ (if (windows) vk.device_commands.win32_surface else .{});

I haven't really experimented with syntax like this yet though. One advantage of this type of system over bools is that it's much easier to include multiple commands at the same time.
Can you point me to your use-case of a feature like this?

@Snektron The main goal of this change lies in the value of using a struct vs using a slice; where using a comptime slice can lead to multiple instances of what is functionally the same type, using an explicit struct value is guaranteed to always produce the same type for the same contents. This ultimately makes it easier to implement a function like this (when used in tandem with the other changes):
const std = @import("std");
const vk = @import("vulkan");
fn isInstanceWrapper(comptime T: type) bool {
    if (@typeInfo(T) != .Struct) return false;
    if (!@hasDecl(T, "commands")) return false;
    if (!std.meta.declarationInfo(T, "commands").is_pub) return false;
    return vk.InstanceWrapper(T.commands) == T;
}

This can then be subsequently used for type verification in other functions, which can then also do something like: comptime assert(@TypeOf(instance_dispatch).commands.{required command});.
I can definitely see the value in your method, though I could also argue that such a capability isn't made impossible by this change, just slightly more verbose, whilst your approach doesn't make it possible to make guarantees while using the duck-typing method.
If you do veto this, then the change I would subsequently request is to at least include the cmds parameter as a commands declaration inside the Wrapper types, which, while it wouldn't be nearly as ergonomic or provide the same type-consistency, would be an acceptable trade-off for me.

Something that was on my mind was to provide easier ways of combining function pointers from multiple extensions. My plan was to predefine a []Command for every extension, which you would be able to concatenate at build to get the complete list of commands.

It seems to me @InKryption's modifications would provide a better system for this. If you treat wrapper inputs as just normal flags, rather than an array (which technically allows repeating a command more than once), you could just do something like:
const commands =
  vk.device_commands.v1_0.union(
  vk.device_commands.swapchain.union(
  if (windows) vk.device_commands.win32_surface else .{}));

which although possibly less ergonomic makes more semantic sense, I think - as what you're doing is identical to any other union-of-flags-ing that you might be doing in Vulkan.

Yes that is true. I think I am convinced.
One question though; do you think its a good its a good idea to accept an EnumSet instead of en EnumFieldStruct? This already provides the relevant set operations.

@Snektron After the change, the declaration for {0s}CommandSet does become a bit ugly:
\\pub const {0s}CommandSet = {0s}CommandSet: {{
\\    @setEvalBranchQuota(3000);
\\    break :{0s}CommandSet std.enums.EnumSet({0s}Command);
\\}};

Because the EnumSet has to iterate over every field a good few times. Not a big deal, but then: the procedure for defining the Wrapper types with your suggestion becomes something like:
const InstanceDispatch = vk.InstanceWrapper(blk: {
    @setEvalBranchQuota(10_000);
    break :blk vk.InstanceCommandSet.init(.{
        .destroyInstance = true,
        .createDevice = true,
        .destroySurfaceKHR = true,
        .enumeratePhysicalDevices = true,
        .getPhysicalDeviceProperties = true,
        .enumerateDeviceExtensionProperties = true,
        .getPhysicalDeviceSurfaceFormatsKHR = true,
        .getPhysicalDeviceSurfacePresentModesKHR = true,
        .getPhysicalDeviceSurfaceCapabilitiesKHR = true,
        .getPhysicalDeviceQueueFamilyProperties = true,
        .getPhysicalDeviceSurfaceSupportKHR = true,
        .getPhysicalDeviceMemoryProperties = true,
        .getDeviceProcAddr = true,
    });
);

Because the init function provided by EnumSet also needs to iterate over all of the fields, and quickly uses up the eval branch quota. We could define a struct with an EnumSet member, and wrap the functions in which we raise the eval branch quota, but at that point we may as well just define the functions manually, for the precise use cases required, without that level of indirection.
All that considered, what would you prefer? And if you decide that we should define our own functions, would you like me to do that in this PR, or will you do it in a separate PR?

Another thing that occurs to me is that we could generate the struct alongside the associated enum, which would require less comptime magic.

@Snektron Are you very busy? If you are, I apologize, but some sort of indication as to what to do here would be appreciated.

Sorry for the wait. Let try it.

Something that was on my mind was to provide easier ways of combining function pointers from multiple extensions. My plan was to predefine a []Command for every extension, which you would be able to concatenate at build to get the complete list of commands.

It seems to me @InKryption's modifications would provide a better system for this. If you treat wrapper inputs as just normal flags, rather than an array (which technically allows repeating a command more than once), you could just do something like:
const commands =
  vk.device_commands.v1_0.union(
  vk.device_commands.swapchain.union(
  if (windows) vk.device_commands.win32_surface else .{}));

which although possibly less ergonomic makes more semantic sense, I think - as what you're doing is identical to any other union-of-flags-ing that you might be doing in Vulkan.

Did the ability to union (merge) these ever make it?

Did the ability to union (merge) these ever make it?

It never did actually, sort of slipped my mind as soon as this change unblocked the stuff I was doing; quite inconsiderate on my part. I'll try and look at making a PR for that at some point soon, or anyone else, feel free to do so.


tDEM and dDEM classes

Two convenience classes; dDEM and tDEM are added.
dDEM
A subclass of geoutils.georaster.Raster.
Contains start_time, end_time and error attributes, as well as a couple of new functions.
tDEM
A temporal DEM collection.
This class is primarily used to generate and handle dDEMs
Example
import xdem
import geoutils as gu
import datetime

# Load some example data
dem_2009 = gu.georaster.Raster(xdem.examples.FILEPATHS["longyearbyen_ref_dem"])
dem_1990 = gu.georaster.Raster(xdem.examples.FILEPATHS["longyearbyen_tba_dem"])
glaciers_1990 = gu.geovector.Vector(xdem.examples.FILEPATHS["longyearbyen_glacier_outlines"])

# Extract the Scott Turnerbreen glacier as an example and make a boolean mask from it.
scott_1990 = gu.geovector.Vector(glaciers_1990.ds.loc[glaciers_1990.ds["NAME"] == "Scott Turnerbreen"])
mask = scott_1990.create_mask(dem_2009) == 255).reshape(dem_2009).data.shape

# Fake a 2060 DEM by making the glacier 30 m smaller.
dem_2060 = dem_2009.copy()
dem_2060[mask] -= 30

# Create the temporal DEM collection with appropriate timestamps.
tdem = xdem.volume.tDEM(
    dems=[dem_1990, dem_2009, dem_2060],
    timestamps=[datetime.datetime(year, 8, 1) for year in [1990, 2009, 2060]],
    reference_dem=1  # This can be either an index of the 'dems' list or the instance of the DEM.
)

# Create the dDEMs. These are both returned, and saved in the class (`self.ddems`)
tdem.subtract_dems(resampling_method="nearest")

# Calculate the cumulative dH within the Scott Turnerbreen mask
cumulative_dh = tdem.get_cumulative_dh(mask=mask)

print(cumulative_dh)

prints:
1990-08-01     0.000000
2009-08-01   -13.721097
2060-08-01   -57.442195
dtype: float64

Steps ahead

Add functionality for temporally varying glacier outlines
Add error calculations
Add DEM/dDEM interpolation shortcuts.

What do you think about this so far?

Great work, I think the idea and structure is there. In particular the Class methods are great!
For the tDEM and dDEM classes themselves - everything related to init() - I suggest we move all to a composition primarily based on xarray for the following reasons:

xarray has a great handling of datetime (np.datetime64) through similar abilites as pandas but in N-dimensions.
xarray will hold all variables with the proper referenced dimensions (e.g., a stack of 10 DEMs of size (x=100,y=100,t=10) accessible through ds.h and a reference DEM of size (x=100,y=100) accessible through ds.ref in the same Dataset object.
the time dimension (and other attributes, such as vertical referencing) will be properly linked to each slice of the objects.
we can pass down the crs to the xarray dataset, and this will save to netCDF to visualize/share the georeferenced time stack/dDEM stack directly.
we can easily implement chunking/parallel computing on the xarray.Dataset through Dask
the list goes on... ;D

@rhugonnet I have heard lots of people talk about the advantages of xarray (or is it a few people talking lots about it?? Often hard to tell the difference!). I've never touched it myself.
I like the idea of keeping dependencies low, and this would be yet another framework for people to learn. I am not completely against it though. @adehecq what do you think?

I'm curious: when do you use Optional[] in annotations? Doesn't the = None already fulfills that message?

Optional[Type] is a shortcut for Union[None, Type]. In the same way that def func(value: int = 1.1) is technically incorrect, so is def func(value: float = None). I understand the argument that python should be able to understand the latter context and convert it implicitly to def func(value: Optional[float] = None), but I'm sure there's a good reason why (one that I don't know!).
The current approach is similar to other languages, for example rust:
fn func(value: f32, optional_value: Option<f32>) -> f32 {
    // do stuff
}

func(1.0, None)
func(1.0, 1.1)

(in rust, arguments can't have default values, so you have to specify None explicitly. This is to reduce unexpected behaviour I think)

I'm looking forward to hear from you what you think of this! I've started on interpolation functionality for dDEMs. Right now, I only have one linear spatial interpolation using scipy.interpolate.griddata() which is really slow, but it serves as a proof of concept. @adehecq , as soon as you have the interpolation stuff ready, we can implement it here!
# Load everything like the example in the top

# Create the dDEMs. These are both returned, and saved in the class (`self.ddems`)
tdem.subtract_dems(resampling_method="nearest")

# Since the dDEM has no gaps, the filled_data is equal to the data attribute
assert tdem.ddems[0].filled_data is tdem.ddems[0].data

# Generate 10000 NaN values randomly in the dDEM
tdem.ddems[0].data[np.random.randint(0, tdem.ddems[0].data.shape[0], 100),
                   np.random.randint(0, tdem.ddems[0].data.shape[1], 100)] = np.nan

# Now the dDEM has gaps, but the _filled_data attribute is empty, so this is now None
assert tdem.ddems[0].filled_data is None

# This will in the future be done concurrently!
tdem.interpolate_ddems(method="linear")

# Now the dDEM data attribute has NaNs, but the filled_data is available
assert tdem.ddems[0].filled_data is not None and np.count_nonzero(np.isnan(tdem.ddems[0])) > 0

# Calculate the cumulative dH within the Scott Turnerbreen mask
# This will warn if the analysis is done on the unfilled data (nans_ok=False; if filled_data is None)
cumulative_dh = tdem.get_cumulative_dh(mask=mask, nans_ok=False)

So the most important part I guess is that the dDEM class (which is now a subclass of DEM, not Raster) has a normal .data attribute, which may or may not have NaNs, and a .filled_data which will never have NaNs (assuming it exists).
Thoughts about this?

I'm looking forward to hear from you what you think of this! I've started on interpolation functionality for dDEMs. Right now, I only have one linear spatial interpolation using scipy.interpolate.griddata() which is really slow, but it serves as a proof of concept. @adehecq , as soon as you have the interpolation stuff ready, we can implement it here!
# Load everything like the example in the top

# Create the dDEMs. These are both returned, and saved in the class (`self.ddems`)
tdem.subtract_dems(resampling_method="nearest")

# Since the dDEM has no gaps, the filled_data is equal to the data attribute
assert tdem.ddems[0].filled_data is tdem.ddems[0].data

# Generate 10000 NaN values randomly in the dDEM
tdem.ddems[0].data[np.random.randint(0, tdem.ddems[0].data.shape[0], 100),
                   np.random.randint(0, tdem.ddems[0].data.shape[1], 100)] = np.nan

# Now the dDEM has gaps, but the _filled_data attribute is empty, so this is now None
assert tdem.ddems[0].filled_data is None

# This will in the future be done concurrently!
tdem.interpolate_ddems(method="linear")

# Now the dDEM data attribute has NaNs, but the filled_data is available
assert tdem.ddems[0].filled_data is not None and np.count_nonzero(np.isnan(tdem.ddems[0])) > 0

# Calculate the cumulative dH within the Scott Turnerbreen mask
# This will warn if the analysis is done on the unfilled data (nans_ok=False; if filled_data is None)
cumulative_dh = tdem.get_cumulative_dh(mask=mask, nans_ok=False)

So the most important part I guess is that the dDEM class (which is now a subclass of DEM, not Raster) has a normal .data attribute, which may or may not have NaNs, and a .filled_data which will never have NaNs (assuming it exists).
Thoughts about this?

I will add some interpolation functionalities yes, but I won't have time to do this today I believe... But Erik, if you have gap-filling/resampling scripts somewhere, please put them in the google drive so I can have a look.
But in the meantime, you could also just use rasterio's fill: https://rasterio.readthedocs.io/en/latest/api/rasterio.fill.html
Regarding the data vs filled_data, it seems like a good idea. But how will you treat the case where there is no NaN in data? Will you duplicate the data, or just have filled_data point to data?

I will add some interpolation functionalities yes, but I won't have time to do this today I believe... But Erik, if you have gap-filling/resampling scripts somewhere, please put them in the google drive so I can have a look.
But in the meantime, you could also just use rasterio's fill: https://rasterio.readthedocs.io/en/latest/api/rasterio.fill.html
Regarding the data vs filled_data, it seems like a good idea. But how will you treat the case where there is no NaN in data? Will you duplicate the data, or just have filled_data point to data?

Ah, I had forgotten about rasterio fill. I'll have a look when I next have time (probably not today).
filled_data is data if data contains no NaNs.

Wow, that was an easy fix... @adehecq, I replaced the scipy.interpolate.griddata() with rasterio.fill.fillnodata() in 1c4ada6 and it works like 10 times faster.

I've now added volume change and temporally variable (glacier) outlines support!
import datetime

import geoutils as gu
import xdem

# Read 1990 and 2009 (ish) DEMs and glacier outlines.
dem_2009 = xdem.dem.DEM(xdem.examples.FILEPATHS["longyearbyen_ref_dem"])
dem_1990 = xdem.dem.DEM(xdem.examples.FILEPATHS["longyearbyen_tba_dem"])
outlines_1990 = gu.geovector.Vector(xdem.examples.FILEPATHS["longyearbyen_glacier_outlines"])
outlines_2010 = gu.geovector.Vector(xdem.examples.FILEPATHS["longyearbyen_glacier_outlines_2010"])

# Fake a 2060 DEM
mask_2010 = (scott_2010.create_mask(self.dem_2009) == 255).reshape(self.dem_2009.data.shape)
dem_2060 = self.dem_2009.copy()
dem_2060.data[mask_2010] -= 30

# This can also be parsed automatically if DEM.datetime exists on all given DEMs
timestamps = [datetime.datetime(1990, 8, 1), datetime.datetime(2009, 8, 1), datetime.datetime(2060, 8, 1)]

# Extract the outlines for Scott Turnerbreen
scott_1990 = gu.geovector.Vector(outlines_1990.ds.loc[outlines_1990.ds["NAME"] == "Scott Turnerbreen"])
scott_2010 = gu.geovector.Vector(outlines_2010.ds.loc[outlines_2010.ds["NAME"] == "Scott Turnerbreen"])

# Create a tDEM object with the DEMs and outlines for 1990 and 2010
tdem = xdem.volume.tDEM(
              [self.dem_1990, self.dem_2009, dem_2060],
              timestamps=timestamps,
              outlines=dict(zip(timestamps[:2], [scott_1990, scott_2010])),
              reference_dem=1
)

# Create and interpolate dDEMs
tdem.subtract_dems(resampling_method="nearest")
tdem.interpolate_ddems(method="linear")

# Calculate cumulative dH and dV series
# The values are masked with the outlines as described by the self.get_ddem_mask() method.
# In short; if outlines exist from the start and end time of a dDEM, the union of the two masks are used.
# If only outlines from the start year exists, it will use that.
# If only one outline was provided, it will always use that as a mask
# Otherwise, it will just use the whole dDEM
# A custom mask can always be provided with the mask= keyword argument. Then, outlines are ignored.
cumulative_dh = tdem.get_cumulative_series(kind="dh")
cumulative_dv = tdem.get_cumulative_series(kind="dv")

print(cumulative_dh)
print(cumulative_dv)

prints the following:
1990-08-01     0.000000
2009-08-01   -13.379259
2060-08-01   -43.379259
dtype: float64

1990-08-01    0.000000e+00
2009-08-01   -5.676017e+07
2060-08-01   -1.543202e+08
dtype: float64

What do you think?

Looks promising, but I have several questions:

for now I don't see a lot of interest in the dDEM class, if one simply provides it with a single raster. Why not provide two rasters (DEMs) and have methods such as difference, coregister, calculate volume etc
how does tDEM scale with size? Loading into memory each DEM can be impossible in some cases, and here we basically double the amount of data with the differences
it seems like tDEM would also not apply well for Romain's work, for example if you have a series of DEMs and want to fit an elevation trend or so
My idea of tDEM was that, upon initialization, it would reproject all DEMs to a common grid and save the data cube into an xarray with chunks. This would allow to perform operations such as differencing or volume change calculation on a large volume with chunks.

Looks promising, but I have several questions:
* for now I don't see a lot of interest in the dDEM class, if one simply provides it with a single raster. Why not provide two rasters (DEMs) and have methods such as difference, coregister, calculate volume etc

* how does tDEM scale with size? Loading into memory each DEM can be impossible in some cases, and here we basically double the amount of data with the differences

* it seems like tDEM would also not apply well for Romain's work, for example if you have a series of DEMs and want to fit an elevation trend or so
  My idea of tDEM was that, upon initialization, it would reproject all DEMs to a common grid and save the data cube into an xarray with chunks. This would allow to perform operations such as differencing or volume change calculation on a large volume with chunks.

The dDEM class handles interpolation and will handle error assessment. I don't think that counts as uninteresting. I would argue that coregistration has nothing to do with DEM subtraction (although dDEMs are of course sometimes an intermediate step in some methods), so this should be independent on the dDEM class.
I tried loading 10 instances of the same KH-9 DEM you sent me, and the memory usage from start to finish was about 12 GiB. @rhugonnet and I discussed that it would be nice to have the core functionality in place before worrying too much about the performance part. Of course, these go slightly hand in hand, as we shouldn't create something that cannot be optimised later (if it needs to be optimised), so I am open to approaches that would reduce this. One very easy optimisation could be to use float32 values in the dDEMs  as default instead of the current float64's.
Maybe @rhugonnet can answer this? How much memory is too much? Reprojecting DEMs to fit each other perfectly and then merging them into a stack sounds great. This has to be after coregistration, however, as the DEMs would otherwise be projected twice (which I would argue is risky because it will modify the data unnecessarily). My aim with this tDEM object was to make it as simple as possible to coregister, subtract, and assess DEMs. Your approach sounds great for the two second points, but I struggle to see where the first comes in.

Perhaps we should think of renaming these things? The "tDEM" object I create can be renamed to a DEMCollection, which handles coregistration and reprojection. The class can have a method called DEMCollection.create_tdem(), which converts it to @adehecq's "tDEM" version.
I guess this is the risk one faces by developing a tool with no specific use-case in mind: different people's needs complicates the others' needs. My use case is comparing, say, up to five DEMs with extents of less than or equal to 10000x10000 pixels, for which my approach would fit perfectly. I think the most relevant question we have to ask ourselves is: what will others require? Will most others require blazing fast 100000x100000x2000 temporal DEM comparisons, or will most just need to subtract two differently projected DEMs?
I think we need a thorough discussion on this moving forward. I won't do anything else on this until we have a plan. I've already spent a week on this so I don't want to spend more time only to have it completely revised.

* The dDEM class handles interpolation and will handle error assessment. I don't think that counts as uninteresting. I would argue that coregistration has nothing to do with DEM subtraction (although dDEMs are of course sometimes an intermediate step in some methods), so this should be independent on the dDEM class.

I was not saying that it does not have an interest per se, but I do not see a lot of benefit of having it as a separate class of Raster or DEM. We could have an interpolation method in Raster that would return a filled version of the DEM. My point was that I would find it more useful if one would provide two rasters, rather than a wrapper around a single raster, which already exists with Raster/DEM. If we provide both DEM rasters, then we can include methods such as coregistration (which would just be a wrapper around coreg functions) and subtract. That makes it a lot more interesting as a separate class.

* I tried loading 10 instances of the same KH-9 DEM you sent me, and the memory usage from start to finish was about 12 GiB. @rhugonnet and I discussed that it would be nice to have the core functionality in place before worrying too much about the performance part. Of course, these go slightly hand in hand, as we shouldn't create something that cannot be optimised later (if it needs to be optimised), so I am open to approaches that would reduce this. One very easy optimisation could be to use float32 values in the dDEMs  as default instead of the current float64's.

Good to know! And yes, I think the default should be float32. I've never encountered situations where float64 was needed for this kind of calculation...

* Maybe @rhugonnet can answer this? How much memory is too much? Reprojecting DEMs to fit each other perfectly and then merging them into a stack sounds great. This has to be after coregistration, however, as the DEMs would otherwise be projected twice (which I would argue is risky because it will modify the data unnecessarily). My aim with this tDEM object was to make it as simple as possible to coregister, subtract, and assess DEMs. Your approach sounds great for the two second points, but I struggle to see where the first comes in.

Yes, I thought that the idea of tDEM (or DEMCollection) was to accept any DEM, make sure that all DEMs would be co-registered to each other and resampled to a common grid, to ease further operations. Of course, saving to an xarray could be an option for large datasets only. In this sense, I do not think the current framework would need a lot of re-writing, it would mostly be about having an additional method to create the DEM stack and save it as xarray.

Perhaps we should think of renaming these things? The "tDEM" object I create can be renamed to a DEMCollection, which handles coregistration and reprojection. The class can have a method called DEMCollection.create_tdem(), which converts it to @adehecq's "tDEM" version.
I guess this is the risk one faces by developing a tool with no specific use-case in mind: different people's needs complicates the others' needs. My use case is comparing, say, up to five DEMs with extents of less than or equal to 10000x10000 pixels, for which my approach would fit perfectly. I think the most relevant question we have to ask ourselves is: what will others require? Will most others require blazing fast 100000x100000x2000 temporal DEM comparisons, or will most just need to subtract two differently projected DEMs?
I think we need a thorough discussion on this moving forward. I won't do anything else on this until we have a plan. I've already spent a week on this so I don't want to spend more time only to have it completely revised.

Yes, we can talk about it tomorrow, since we're supposed to meet already. Sorry if that felt like huge criticism, but it was not. I think you could more or less merge that PR and we can move from there.

I think we need a thorough discussion on this moving forward. I won't do anything else on this until we have a plan. I've already spent a week on this so I don't want to spend more time only to have it completely revised.

Yes, sorry I'm not more active this week! I have other things to tend to...
I agree we should press pause on these aspects. As I said last Friday, I will get back to you two on a structure + its relation to existing tools, as I am most familiar with those. After working nearly 3 years on these things (either DEM time series, sequential or simple DEM differences), I have a good idea of how to put this together. This will make things easier. I should have more time early next week.
I think it's great progress and we'll definitely be able to use the work you've being doing moving forward :+1:

Thanks for the replies, @adehecq and @rhugonnet.
I am relieved to hear we seem to be more or less on the same page, and I appreciate the clarifications above! Let's indeed discuss these things in person. I'm having three talks within 4 work-days so I'm quite stressed, which is maybe why I took this a bit too personal, even though I know I shouldn't!

Good luck with the talks!!

I now changed the tDEM name to DEMCollection and moved it and dDEM to xdem/dem.py.
I imported all the dem.py classes in the __init__.py to simplify the syntax a bit:
import xdem

# Previously: (note: this still works)
dem = xdem.dem.DEM("path/to/file")

# Now:
dem = xdem.DEM("path/to/file")
dems = xdem.DEMCollection(list_of_dems)

Do you agree on this latest change, @rhugonnet  and @adehecq ?
Also, @rhugonnet, I couldn't get any of your tests to pass using the latest main. Do they pass for you?

I now changed the tDEM name to DEMCollection and moved it and dDEM to xdem/dem.py.
I imported all the dem.py classes in the __init__.py to simplify the syntax a bit:
import xdem

# Previously: (note: this still works)
dem = xdem.dem.DEM("path/to/file")

# Now:
dem = xdem.DEM("path/to/file")
dems = xdem.DEMCollection(list_of_dems)

Do you agree on this latest change, @rhugonnet and @adehecq ?

I'm happy with the new names and setup!

I'm happy with the new names and setup!

Nice! Maybe I can merge once I have an okay from @rhugonnet and clarification with the tests?

In 0154255, I added something quite exciting. Pandas/GeoPandas supports queries made within them, so Vectors support that as well by this slightly hacky approach:
all_outlines = gu.Vector("...")

scott_outline = all_outlines.copy()
scott_outline.ds = scott_outline.ds.query("NAME == 'Scott Turnerbreen'")

The syntax here refers to the column called NAME which must be equal to the string 'Scott Turnerbreen'. Maybe I'll add Vector.query() as a PR for geoutils. What do you think, @adehecq and @rhugonnet?
These queries are now implemented in the DEMCollection object:
In [1]: import datetime

In [2]: import geoutils as gu

In [3]: import xdem

# Read 1990 and 2009 (ish) DEMs and glacier outlines.
In [4]: dem_2009 = xdem.DEM(xdem.examples.FILEPATHS["longyearbyen_ref_dem"], datetime=datetime.datetime(2009, 8, 1))
No metadata could be read from filename.

In [5]: dem_1990 = xdem.DEM(xdem.examples.FILEPATHS["longyearbyen_tba_dem"], datetime=datetime.datetime(1990, 8, 1))
No metadata could be read from filename.

In [6]: outlines = {
    datetime.datetime(1990, 8, 1): gu.Vector(xdem.examples.FILEPATHS["longyearbyen_glacier_outlines"]),
    datetime.datetime(2009, 8, 1): gu.Vector(xdem.examples.FILEPATHS["longyearbyen_glacier_outlines_2010"]),
}

In [7]: dems = xdem.DEMCollection(dems=[dem_2009, dem_1990], outlines=outlines)

In [8]: dems.subtract_dems()

In [9]: dems.interpolate_ddems()

# Get dV for Scott Turnerbreen
In [10]: dems.get_cumulative_series(kind="dv", outlines_filter="NAME == 'Scott Turnerbreen'")
Out [10]:
1990-08-01    0.000000e+00
2009-08-01    -5.676017e+07
dtype: float64

# Get dV for the neighbouring Ayerbreen
In [11]: dems.get_cumulative_series(kind="dv", outlines_filter="NAME == 'Ayerbreen'")
Out [11]:
1990-08-01    0.000000e+00
2009-08-01    -3.909687e+07
dtype: float64

This addition means that dDEMs are only calculated once for an entire area, and then one can cherry-pick the glaciers to look at. The glacier-specific mask can for any purpose be extracted by:
dems.get_ddem_mask(dems.ddems[0], outlines_filter="whatever filter")  # This returns a numpy ndarray

I'm still a bit afraid the dem.py will end up being ~5000 lines long if we keep all in the same place, I think a ddem.py and "demcollection.py" would make more sense, but we can worry about this later ;)

@erikmannerfelt On the tests, all is passing on my side:
============================ 18 passed, 32 warnings in 507.15s (0:08:27) ============================
Some are taking too long (10 min for testing is too much), we'll have to work on quicker tests.

I agree with what you say @rhugonnet, and I've now moved the dDEM and DEMCollection objects to two separate modules! I'll merge now.


Proposed Solution for #674 Permissions Changes

Changed the ChannelPermission, GuildPermission enums to match the Discord API. Adjusted relevant methods to match this change. Also added view audit logs permission to guild permission while I was at it.
Will using System.Math.Pow cause compatibility issues? (had to import System)
This is a breaking change, both the values and names of the enum definition have been modified.
My discord handle is ChrisJ#8703 if you want to contact me.

You updated just before I commented.

Also, the comments categorizing each section of permissions would be nice to still have in source. And maybe put an _ every two digits for readability.

Added @Joe4evr suggested changes

Added @foxbot 's suggested changes

Added @FiniteReality 's requested changes

Formatted the two enums so that they are displayed in neat columns in the source.
Also, could we add the Hacktoberfest label to this PR?

I think hacktoberfest labels only apply to issues: PRs are automagically counted.


Cannot use copilot chat , always get Error on conversation request. Check the log for more details.

VS Code Version:
OS Version:
Logs:

Steps to Reproduce:
1.open chat session
2. type anything
Result

Hello，sir，have u solven this issue？


Revert --batch change for pipeline_job.sh

Is your feature request related to a problem? Please describe.
One cannot run multiple batches at the same time (the input of a batch may overlap, of course).
Describe the solution you'd like
Remove change to pipeline_job.sh again. Rather, allow to specify an optional SNAPPY_BATCH.
Describe alternatives you've considered
N/A
Additional context
N/A

We can use the following snippet:
# Allow selection of batch
if [[ ! -z "${SNAPPY_BATCH-}" ]]; then
    SNAKEMAKE_BATCH_ARG="--batch ${SNAKEMAKE_BATCH_RULE-default}=${SNAPPY_BATCH}"
else
    SNAKEMAKE_BATCH_ARG=
fi


[Feature]

Description
The font of the events page can be improved so that it looks more decent and elegant
Screenshots

Additional Information
No response

I would like to work on this issue under gssoc'23

I would like to work on this issue under gssoc'23

This issue is already been fixed, @Shatakshi0 Please look out for any other issue. Happy Contributing.


Suggested/Minimum memory requirement

I noticed from past runs that fastp suggests 1-16 cpus per run, but is their a suggested/minimum memory requirement?  I could not find it your docs.

fastp requires a little RAM. 2G is more than enough.
BTW, usually 2 or 3 cpus are enough.  fastp is I/O limited since it runs too fast than read/write.

@sfchen thanks for your reply, on the memory requirements.  Are you suggesting that 2-3 cpus is as efficient as 16?


add Interceptors for okhttp client

Hi, I'm using this lib, is there any chance to add a interceptor for okhttp client, I want add a StethoInterceptor for network request debug

We don't currently support adding interceptors. I internally we only use OkHttp thru okhttp-urlconnection interface. As we look to upgrade to Retrofit 2 and OkHttp3 we will keep this use case in mind.
Is there an issue you are trying to debug we can help with?

No, thank you


Customresource spec.deployment is only a limited subset

When setting overrides on the deployment, only the following parameters are available:
spec:
  deployment:
    affinity: [...]
    containers: [...]
    imagePullSecret: [...]
    nodeSelector: [...]
    replicas: [...]
    serviceAccountName: [...]
    tolerations: [...]

I would like to be able to configure, amongst other things spec.strategy. Could the operator allow the full deployment spec to be configured?
/kind feature

/triage accepted

This can be added to our deployment spec in provider's API

Hey @johanjk @alexander-demicev. I've been taking a look at this and, assuming the fields of interest are the ones in DeploymentSpec here, there are a few of them that are not optional. Is it expected to support overriding only a selection of these fields or would it be useful to have this struct embedded inline and have access to all fields considering some of them would be required?

@salasberryfin We had a bad experience with embedding structures in API, if something changes in the structure our API can get broken

Hey @johanjk you can use manifest patch to apply things which are not supported by default spec

Hey @johanjk you can use manifest patch to apply things which are not supported by default spec

Based on ^, closing this.


Fix viewportTolerance with defaults

@bkoval This is completely my fault.  I didn't have a test for the viewportTolerance.
This is a small fix, but in reality there still are a few things we can still improve - better tests for viewportTolerance and intersectionThreshold, allow % for viewportTolerance in the IntersectionObserver case, etc.  I'll make a follow up issue.
References #121

Only one change to the in-viewport mixin.  Will merge this morning if everybody is ok with this.

Thanks so much @snewcomer - super quick reaction!


feat(SPV-978) remove "contacts" menu item from user view

Pull Request Checklist

[ ] 📖 I created my PR using provided  : CODE_STANDARDS
[ ] 📖 I have read the short Code of Conduct: CODE_OF_CONDUCT
[ ] 🏠 I tested my changes locally.
[ ] ✅ I have provided tests for my changes.
[ ] 📝 I have used conventional commits.
[ ] 📗 I have updated any related documentation.
[ ] 💾 PR was issued based on the Github or Jira issue.

The commit message should be:
feat(SPV-978): ...
I mean, you forgot about :


Selected visualizations are discarded when adding a column

Steps to reproduce

Add a column
Switch the visualization in the toolbar of the column
Add another column

Observed behavior

The visualization type is restored to its default

Expected behavior

Keep the selected visualization from the user OR even better do not replace the multiform when adding a new column, but only rescale it (if necessary)

@bikramkawan Could you please have a look into that tomorrow? Maybe you can fix that already while working #157?

Ok I will finish 157 first and I can take over this.

Sure. Thanks. 👍

This is the approach for single multiform and the same logic will be applied once https://github.com/Caleydo/mothertable/pull/177  is fixed.

I will close this since it is merged

It was broken after multiform. So I reopen again.

What means "after multiform"?

It's after I reimplemented sorting and stratification it is broken.


feature request: exit with non-zero code upon validation errors

Is your feature request related to a problem? Please describe.
Make the CLI exit with non-zero code if validation fails
Current behavior:
$ istanbul-badges-readme
Info: 0. Istanbul Badges Readme process started
Info: 1. Config check process started
- Readme file exists... ✔.
Error: Coverage file does not exist in ./coverage/coverage-summary.json
Error: Please refer to the documentation
Error: https://github.com/olavoparno/istanbul-badges-readme/blob/master/README.md
Info: 0. Istanbul Badges Readme process finished
Done in 0.17s.
$ echo $?
0

Exiting with 0 prevent other tools (like GitHub Actions) to detect any validation errors of istanbul-badges-readme easily
Describe the solution you'd like
adding process.exitCode = 1; below will do the trick work but I'm pretty sure it will be a breaking change as some users could be relying on istanbul-badges-readme success exit code
https://github.com/olavoparno/istanbul-badges-readme/blob/805ab2e19931201fb80a949d1c9693ea29aac00d/src/factory.ts#L20-L24
thus, to avoid breaking changes, this feat could be optional and enabled via --exit-code flag, like git-diff do
Describe alternatives you've considered
In my use case, the coverage directory might not exists and I need to report this as an error. I'm doing the following:
$ [ -d './coverage' ] && istanbul-badges-readme || exit 1

but I think it would be cool if istanbul-badges-readme abstracts this for us :)

Hello @micalevisk thanks for opening the issue. Yeah, I think it was a bad design decision, indeed, I think I forgot to throw the error after logging them, so now we have to deal this behavior haha
I will look into your suggestion! Thank you once again :)

@micalevisk hello again, sir, I am not having lots of spare time right now, would you mind opening a PR? If not, it's ok, I will try to do ASAP.

@olavoparno sure. Should I add --exit-code optional flag?

Yes, I think this is fine. If there's an explanation in the docs I think people will understand :) thank you, really.

btw I saw that other flags are following camel case then I've chose --exitCode instead :smile:

@micalevisk hello again! Sorry for the dalay, I was caught up with other things :( oh man, I took advantage of your WIP commit and I have already commited to the develop branch a version of exitCode. Sorry for your work, but I think it accomplishes the same thing as I think I got your idea.

@all-contributors please add @micalevisk for idea, code, bug

Please do take a look at version 1.8.0 https://www.npmjs.com/package/istanbul-badges-readme/v/1.8.0
Once again, thanks for the patience, mister @micalevisk

I'm not sure if I'm using the flag correctly (or understood it correctly), but it always fails:
> istanbul-badges-readme --logo='jest' "--ci" "--exitCode=1"

Istanbul Badges Readme process started
Config check process started
- Readme file exists... ✔.
- Coverage file exists... ✔.
- Coverage hashes exist... ✔.
- Readme hashes exist... ✔.
Config check process ended
Editor process started
- Getting readme hashes...
- Getting new readme data...
- Getting coverage badge url for statements...
- Writing new readme data...
Editor process ended
Istanbul Badges Readme process finished
Error: Process completed with exit code 1.

after running this, what's the output of echo $??

nvm. You're right. I just tested. This is a bug

@myknbani and @micalevisk there is indeed a bug. Thank you @myknbani for testing it. @micalevisk do you want to open a PR fixing it or shall I do so? Thank you too for your support by the way, I really appreciate it :)

Also digging through the source code, it seems to just obey --exitCode=whatever all the time :cold_sweat:

@micalevisk is fast :sweat_smile:

@could you guys test it again https://www.npmjs.com/package/istanbul-badges-readme/v/1.8.1?
Thank you both for the help as always.

@all-contributors please add @myknbani for bug

@olavoparno
it is working as expected now. ty for the quick release!

Works on my end too.  Thank you @olavoparno and @micalevisk :tada: :partying_face:


add mcchrish/zenbones.nvim

Zenbones is a light vim/nvim colorscheme designed to highlight code using contrasts and font variations. Colors are tasked only for other roles such as diagnostics, diffs, search matches.

Thanks for the PR!


⚠ Bofrost.at has degraded performance

In 211028e, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1566 ms

Resolved: Bofrost.at performance has improved in ba4b064.


code128: reduce extended latch cut-off from 5 to 4

Latch/unlatch extended on 4 chars instead of 5 for better
encodation in certain cases (and no pessimizations found so far),
part addresses PR #272, props lyngklip
Also fix masked extended chars matching ASCII digits in numsscr
(skipped using re-synced numEA array)
This is the first of two alternative PRs, the second one being
an implementation of Alex Geller's divide & conquer algorithm as
used by ZXing (and Zint)

Closing in favour of PR #278


Add @TheAwesome98-Real Zap Sound Effect for New Messages

Sound effect created by @TheAwesome98-Real

@all-contributors please add @test for test

@all-contributors please add @TheAwesome98-Real for ideas, audio


Change Twitter character limit

Tweets can now be up to 280 characters, so this should be accounted for in the feedback section.

lgtm

@ethernetcable unless I am mistaken, the same old limit applies for people typing in CJK languages, no? So your fix does not seem to account for that.

@bpasero you are right, I have changed the limit if the user's display language is not CJK.

Can anyone tell me why this would fail hygiene? I can't work it out.

Thanks 👍

This doesn't look right to me. The limit is calculated in a per-character basis, so it won't show the correct limit for mixed characters or emoji (also double-counted)

@bpasero this won't work for the reasons I highlighted in this comment. Twitter will update their library in mid-Dec to give a correct solution.

@chrbala @kumarharsh I would still argue this is an improvement to the way it was before. We never accounted for mixed characters or emojis in our previous solution. We can still tweak this further to resolve those issues, but for the majority of people the limit of 280 will be correct.

Yeah, makes sense. Good enough is better than nothing 👍