Remove Travis test for Ruby 1.9

Hello @jekyll/archives. In the interests of keeping development of this important (IMHO!) plugin progressing, and in the spirit of being proactive (and following on from the discussion in #58), I’ve updated the Travis tests to remove tests for Ruby 1.9/Jekyll 2.0.
Somewhat related, I removed the version forking in the code, and bumped the minimum supported Jekyll version to 3.0. Controversial? Maybe, but Jekyll 3.0 is 15 months old now. Ducks

Phew! Do let me know if I’ve made the right changes to the Travis config. @parkr @alfredxing

Please don't modify History.markdown. @jekyllbot will take care of that when PRs are merged :+1:
It seems this would be best if it were just 408aeb6f8ff69a6b9c22c6f9d6330328aac919d5 without duplicating everything in #58

@pathawks Ah. I only updated History.markdown because it made no reference to the 2.1.1 release, so appeared outdated. Not sure how the bots go about their work around here… 😉
Honestly, I’m happy whatever gets committed, just eager to see (and help!) things move forwards.

@pathawks Okay, I’ve reduced the scope of this PR to now only moving to supporting Jekyll 3.0 and above only.
I’m guessing such a change necessitates moving to a major version bump? As such, I wonder if @alfredxing wants to include a few other updates and fixes in such a version? Not sure. FYI, I’m hoping to figure out how we can make this plug in accept any array of documents, so not just site.posts but site.documents or site.[collection].docs.

Looks good to me! Thanks @paulrobertlloyd 😄
It would be a breaking change, so unfortunately we would have to bump the major version 😦
I don't think this would be too much of an issue though; most people should be using Jekyll 3.0 by now!

We can always remove support for 1.9.3 without removing support for Jekyll 2.0. It seems pretty easy to hold onto?

@pathawks Happy to squash. I’ve never done this before, so do please let me know what steps I need to take.
@alfredxing @parkr Oh, maybe I could limit this PR to the Travis config, and to remove testing on Ruby 1.9.3? I wrongly assumed there was a stronger link between Ruby 1.9.3 and Jekyll 2.0, but I guess older versions of Jekyll 2.0 will work with newer flavours of Ruby.

@paulrobertlloyd You can squash commits easily with GitKraken GUI.
https://support.gitkraken.com/working-with-files/commits

👍  for a simple PR that removes testing on Ruby 1.9.x

Or from command line:
git reset 67e56d79241225faa0fed1867034226bb0ee54ee
git commit -a

Thanks for the tip about GitKraken @DirtyF, I’ll have to take a look at that in more detail as it looks very helpful.
Meanwhile, with a bit of ‘close my eyes and press Enter‘ in the terminal, I believe I’ve now squashed the commit log for this PR. Is this correct @pathawks?

@paulrobertlloyd :heart::+1:

@jekyllbot: merge +dev


Add a missing line for Triple click

I think this is a part of https://github.com/dmulcahey/zha-device-handlers/issues/177

have you tested this?

No i can't i don't understand the way to change some files in hass.io installation, i can use zha in custom_components, but zhaquirks i couldn't have a way to change the files for testing, i'm really sorry !!!


bip-taro: implement provable burning and verification

One important feature is the ability to burn assets, and also prove to third parties that those assets have been burnt.
This addition is defined currently in this PR to my BIP repo: https://github.com/Roasbeef/bips/pull/21.
At a high level, we'll use a series of non-inclusion proofs, both within the tapscript level and also across the other outputs in the transaction.
This is related to https://github.com/lightninglabs/taro/issues/20 as the set of non-inclusion proofs outlined there will be used to ensure the asset commitment doesn't persist.
Steps To Completion

[ ] Implement a routine that burns an asset by removing the commitment from the asset tree.
[ ] Implement a routine related to the above that generates a non-inclusion proof on the Taro level proving the asset is no longer committed to.
[ ] Use the above, along side #20 to implement the final component which is to prove that no other commitments are valid in the transaction. Assuming widespread BIP 86 usage is a safe assumption.

After some offline discussion with @guggero, I think we've narrowed down the options here. Generally, we're aware of two approaches:

Burn via proof-of-omission. Instead if re-anchoring an asset into the next anchor output, or spending it, omit the asset from the tap tree. This allows for a proof-of-exclusion to serve as a proof-of-burn.

Drawback: May collide with future protocol changes to allow for asset 'teleporting' via ANYPREVOUT-like mechanics, that could replace asset reanchoring with new signatures. I think we could mitigate that possible collision by requiring a more strict asset state before omission, like using a specific sighash.

Burn via a provaly unspendable script key, followed by omission. The proof for the next spend of the asset includes a field in the associated proof that provides the data needed to verify that the current script key is unspendable / unsatisfiable. The asset is then never moved again, and therefore omitted from future spends of the anchor output.

This option cannot use a shared NUMS key, since that would cause burnt assets to collide in the tap tree if transfers are batched in a pocket universe, or other transfer batching scheme (the tree requires tap asset script keys to be unique).

Instead, we can use a uniquely unspendable tweaked script key for the asset. One option may be to use the shared NUMS key used for split asset tombstoning as the internal key, and use a unique unspendable tap script for the tweak. If we use the current asset position in the tap tree as input to generate that tap script (which is already unique to this anchor output), that should provide a sufficiently random tweaked script key.

One example of such an unspendable tap script:

func deriveBurnKey(asset Asset, outpoint Outpoint) PublicKey {

// Use the path of the asset in the tap tree as a unique hash preimage.
burnPreimage := []byte{outpoint, asset.TapCommitmentKey(), asset.AssetCommitmentKey()}

// Use OP_RETURN to make the script unspendable.
var burnScript *ScriptBuilder
burnScript.AddOp(OP_RETURN)
burnScript.AddData(Hash160(burnPreimage))

// Build a tapscript tree from the script and tweak the NUMS key.
burnTapscriptLeaf := NewBaseTapLeaf(burnScript)
burnTapscriptTree := AssembleTaprootScriptTree(burnTapscriptLeaf)
burnTapscriptTreeRoot := burnTapscriptTree.RootNode.TapHash()
burnScriptKey := ComputeTaprootOutputKey(NUMSPubkey, burnTapscriptTreeRoot)

}

Any verifier can recompute the asset script key if the asset proof includes a flag that the asset is unspendable. On the next spend of the anchor output, the asset can be omitted from the tap tree, and the proof chain for the asset would end at the previous transaction.

One consideration is allowing Universe servers to track the total balance burned for an asset; both of these burn options would allow for that without much overhead.
@Roasbeef thoughts?

Burn via proof-of-omission. Instead if re-anchoring an asset into the next anchor output, or spending it, omit the asset from the tap tree. This allows for a proof-of-exclusion to serve as a proof-of-burn.
Drawback: May collide with future protocol changes to allow for asset 'teleporting' via ANYPREVOUT-like

Do you have a concrete conflict here, or is this statement more speculative? In the case of using something noinput-like to not have to add additional signatures for anchored assets, I don't see how that's incompatible with certain assets jut not existing in the next tree.
One other potential drawback (compared to other alternatives) is that proving this requires state N and also state N+1 proofs to show the asset was omitted. This is actually very similar to the ideas re unilateral exit from a Pocket Universe by proving that the Universe operator effectively burned your assets.

Burn via a provaly unspendable script key, followed by omission.

Related to the above: I don't see why omission here is acceptable, but someone incompatible re the above if we just omit all together.
I think one other advantage of sending to a NUMS key is that you only need that single state transition to prove the asset has been burned. One disadvantage here may be that it effectively takes two steps to complete a burn. This might end up requiring a bit more state and a dedicated sub-system to do in a foolproof manner.
Zooming out, I think the idea of deriving a unique burn key from the existing NUMS key and a unique path for the leaf works as well.

Re-capping my current understanding of how we want to proceed (please correct me if incorrect).
The flow for burning would look something like this:

500 units of asset A are minted or received in on-chain TX tx_0, outpoint tx_0:0.
User wants to burn 300 units of that asset, calls BurnAssets(A, 300) which creates a vPSBT with two outputs (internal split), with 200 units going back to a fresh valid script key and 300 units going to the specially constructed NUMS key, using outpoint, asset.TapCommitmentKey(), asset.AssetCommitmentKey() as the preimage, where outpoint is tx_0:0. This is a 1-in-1-out BTC anchor TX in terms of asset commitments (ignoring any fee sponsoring inputs and bip86 outputs).
The proof for the virtual output 0 (200 units of change) is a normal transfer proof
The proof for the virtual output 1 (300 units to burn) is a transfer proof with the new burn_reveal field set, that reveals outpoint, asset.TapCommitmentKey(), asset.AssetCommitmentKey().
Both these assets are re-created in the DB as asset leaves, but the burned one with the new DB field is_burned being set to true (probably makes sense to also set the is_spent to true as well, since you can't spend a burned asset).
During coin selection, any assets that have is_burned (or is_spent) for that matter are filtered out and are not included in the next tree (the same way we today filter out any 0-value tombstones)

This leaves us with the following questions to answer before coding can begin:

What happens if the burn amount is greater than a single asset UTXO we have available? Let's say we want to burn 800 units but only have an asset UTXO of 400 and another of 600 units. Do we need to create two virtual burn outputs, one for each UTXO outpoint we're spending? I would assume yes. So we'd burn 400 units of the first UTXO and 200 units of the second one, giving us 200 in change.
Do we need to be able to combine burns and regular sends into a single on-chain transaction? Or is it okay for now if the burn process just leases/locks/reserves the UTXOs and only makes the change available for further sends once it is confirmed? cc @dstadulis
Do we really need another layer of reveal with hashing the preimage in the OP_RETURN? Or would it be enough to simply put the outpoint, asset.TapCommitmentKey(), asset.AssetCommitmentKey() data in there directly? Since we already reveal the OP_RETURN script leaf in the burn proof/reveal, I don't think we need another layer of indirection.

This matches my understanding - I don't think the transfer proof actually needs to reveal anything on burn though? And burn_reveal can just be a bool. The receiver can recompute the TapCommitmentKey() and AssetCommitmentKey(), and the outpoint is already in the proof elsewhere.
We probably also want to update some RPC filters to exclude burnt assets from sum amounts.
W.r.t. your three points:

I think this would be easiest as an asset UTXO merge + burn the merged amount? So:

Input: 400, 600, Output: 800 (burnt), 200

I think we technically support merging UTXOs right now but I can't think of tests for it.

I assume we want the first?

Good point, I guess we don't need to actually hash there.

May also make sense to have an RPC to show the total set of burned UTXOs for a given asset.

I don't think the transfer proof actually needs to reveal anything on burn though?

Ah, right, that makes sense. But then it needs to be clear what toutpoint was actually being referred to, which kind of is what my other question tried to get at.

I think this would be easiest as an asset UTXO merge + burn the merged amount?

But then the outpoint in the burn proof would refer to the new state transaction's anchor output where the burn resides in? Otherwise, which input outpoint would you use if you merge multiple inputs?

I think we technically support merging UTXOs right now but I can't think of tests for it.

IIRC we removed some of the checks and added an integration test, but not a very extensive suite of tests yet. There are probably some TODOs left in there.

Good point, I guess we don't need to actually hash there.

Cool, so the updated (pseudo) code would look like this:
func deriveBurnKey(asset Asset, outpoint Outpoint) PublicKey {

// Use the path of the asset in the tap tree to get a unique tweak for the script key.
burnData := []byte{outpoint, asset.TapCommitmentKey(), asset.AssetCommitmentKey()}

// Use OP_RETURN to make the script unspendable.
var burnScript *ScriptBuilder
burnScript.AddOp(OP_RETURN)
burnScript.AddData(burnData)

// Build a tapscript tree from the script and tweak the NUMS key.
burnTapscriptLeaf := NewBaseTapLeaf(burnScript)
burnTapscriptTree := AssembleTaprootScriptTree(burnTapscriptLeaf)
burnTapscriptTreeRoot := burnTapscriptTree.RootNode.TapHash()
burnScriptKey := ComputeTaprootOutputKey(NUMSPubkey, burnTapscriptTreeRoot)

}

The proof for the virtual output 1 (300 units to burn) is a transfer proof with the new burn_reveal field set, that reveals outpoint, asset.TapCommitmentKey(), asset.AssetCommitmentKey().

Why do we need a new field for the burn reveal? Isn't it enough that it's sent to a NUMs point? If we want to ensure it's unique each time, then I think the "publicly available" information could be used for derivation (eg: asset ID and the prev input outpoint or something).

What happens if the burn amount is greater than a single asset UTXO we have available? Let's say we want to burn 800 units but only have an asset UTXO of 400 and another of 600 units.

I think the user either consolidates first. Or we have two outputs that are burnt as you mention.

Do we need to be able to combine burns and regular sends into a single on-chain transaction?

I think base version it can be distinct (to minimize scope). In the future, we want to implement optimistic aggregation for sends, and a burn is a special type of send, so it would be folded in.

Do we really need another layer of reveal with hashing the preimage in the OP_RETURN?

Sounds overly complicated? Maybe I need to revisit the entire transcript, the simplest thing IIUC would just be to either re-use the same NUMs key for burning, or make one that's derived from the asset "position" information.

Isn't it enough that it's sent to a NUMs point?

Yes, but we need a unique NUMS point for each burn. See https://github.com/lightninglabs/taproot-assets/issues/24#issuecomment-1578985230, mainly this comment:

This option cannot use a shared NUMS key, since that would cause burnt assets to collide in the tap tree if transfers are batched in a pocket universe, or other transfer batching scheme (the tree requires tap asset script keys to be unique).

That's why we add the unique information as an OP_RETURN in the script tree in order to tweak the static NUMS key which becomes the internal key. But because now every burn key is different, we need some kind of flag on the proof to mark it as a burn script key.

But then the outpoint in the burn proof would refer to the new state transaction's anchor output where the burn resides in? Otherwise, which input outpoint would you use if you merge multiple inputs?

True, after looking at the scheme again I think merging wouldn't work. I think the solution is as you mentioned, to have some simple 'coin selection' for burning to determine which amounts from which inputs are burnt.

Cool, so the updated (pseudo) code would look like this:

Yes, this looks correct.

I think base version it can be distinct (to minimize scope). In the future, we want to implement optimistic aggregation for sends, and a burn is a special type of send, so it would be folded in.

I agree - I think eventually we could have some non-address request accepted by the transfer call to request a burn instead of a send, but def not worth worrying about right now.

Sounds overly complicated? Maybe I need to revisit the entire transcript, the simplest thing IIUC would just be to either re-use the same NUMs key for burning, or make one that's derived from the asset "position" information.

Deriving for asset 'position' information is basically the currently outlined scheme. Without the flag, we can't know which assets we should validate a burn for. Once we know which assets were supposed to use a burning script key, the proof object already has all the data necessary to validate the burn itself.
Wrt. implications for universes and user-facing display, I think the accounting for burnt balances can be handled client-side vs. modifying the actual tree layout. I'm mostly concerned with not changing the invariants we have right now for the root sums of these trees.
E.x., a user burns some assets and sends these proofs to a universe server. The proof objects for the burnt assets have the burnt flag set. The user's tapd has a separate field in the balances call for burnt assets. The universe server validates the burn, and includes a burnt flag when serving the proofs for these assets to users.
I think overall the universe and RPC changes are separate issues from just the spec definition of an asset burn.

After further offline discussion, I think this is actually the best way to make the unspendable key:
https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-23
Where instead of using an unspendable script, we use the unique NUMS key as an invalid tapscript root. I don't think there's a need to reinvent unspendable taproot keys for this use case.

Without the flag, we can't know which assets we should validate a burn for. Once we know which assets were supposed to use a burning script key, the proof object already has all the data necessary to validate the burn itself.

I guess in my mind a burn is no different from a normal state transition. It's spent to some output key, we don't usually do any verification on the output keys though. However, given the deterministic information, which we can use to derive what the burn key would be, we can recognize it as a burn. You would never see a burn when verifying your own asset history, or the history of a "live" asset.

Where instead of using an unspendable script, we use the unique NUMS key as an invalid tapscript root.

Yeah this is what I'm advocating for. You can verify the base NUMs key we use (re-derive it). You can also verify that a key is the result of some information used to tweak the NUMs key. We can go farther and make the NUMs key into a BIP86 key if we want (provably no script path).
No strong feelings on the burn flag/bit or not. Can see how it can be useful for a dedicated RPC.

Mm I think you'd want to track a balance you burnt at a minimum; I can see how you'd do that without actually flagging it in the proof and just flag it locally.
I think it's also a follow-up question that could become clearer once work on this starts tbh, I'm also not married to any particular method for tracking the burnt balance.


Closes #434 remove pharmaversesdtm dependency

Thank you for your Pull Request! We have developed this task checklist from the Development Process Guide to help with the final steps of the process. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the admiral codebase remains robust and consistent.
Please check off each taskbox as an acknowledgment that you completed the task or check off that it is not relevant to your Pull Request. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the main branch until you have checked off each task.

[x] Place Closes #<insert_issue_number> into the beginning of your Pull Request Title (Use Edit button in top-right if you need to update)
[x] Code is formatted according to the tidyverse style guide. Run styler::style_file() to style R and Rmd files
[x] Updated relevant unit tests or have written new unit tests, which should consider realistic data scenarios and edge cases, e.g. empty datasets, errors, boundary cases etc. - See Unit Test Guide
[x] If you removed/replaced any function and/or function parameters, did you fully follow the deprecation guidance?
[x] Update to all relevant roxygen headers and examples, including keywords and families. Refer to the categorization of functions to tag appropriate keyword/family.
[x] Run devtools::document() so all .Rd files in the man folder and the NAMESPACE file in the project root are updated appropriately
[x] Address any updates needed for vignettes and/or templates
[x] Update NEWS.md under the header # admiral (development version) if the changes pertain to a user-facing function (i.e. it has an @export tag) or documentation aimed at users (rather than developers)
[x] Build admiral site pkgdown::build_site() and check that all affected examples are displayed correctly and that all new functions occur on the "Reference" page.
[x] Address or fix all lintr warnings and errors - lintr::lint_package()
[x] Run R CMD check locally and address all errors and warnings - devtools::check()
[x] Link the issue in the Development Section on the right hand side.
[x] Address all merge conflicts and resolve appropriately
[x] Pat yourself on the back for a job well done! Much love to your accomplishment!

@millerg23 these checks are falling over I think related to tibble??

@bms63 we don't import tribble package in admiraldev, we get tribble from dplyr package . I initially added in reference to tibble::tribble (like we do in admiral) which caused the ERRORS in checks.

@bms63 we don't import tribble package in admiraldev, we get tribble from dplyr package . I initially added in reference to tibble::tribble (like we do in admiral) which caused the ERRORS in checks.

yeah - i think we removed that one recently from suggests??  thanks for fixing!!

.....now im wondering if it is wise to deviate between admiral and admiraldev with tibble stuff???  Just might be confusing for team??

yeah I know what you mean, does seem inconsistent. Perhaps a separate ticket and discuss at next meeting?


some rules report false positives

I just discovered some weird cases where angular-whitespace complains about:

 (the l - as in the letter L - must be the confusing part)
<md-icon *ngIf="isOnline | async; else offline">cloud_off</md-icon>
<md-toolbar color="primary"> - might be the same case as the first one
<rj-image-filters (queryChange)="updateFilters($event)"></rj-image-filters> - could be the same case with the letter L
 - might be the ! sign there, nonetheless, comments should be ignored
<md-select [(ngModel)]="timeRangeKey"> - could be the L again
*ngIf="query.isUpdating | async as isUpdating" - there's obviously space there, so not sure what the problem is

And banana-in-a-box:

 - confuses what's inside the quotes I guess

Finally no-access-missing-member :

complains about a prop not existing on the class, but it's actually a local var

<rj-paginated-resources *ngIf="query"
							#pagination="rjPagination"
							[type]="type"
							[query]="query | async">

		<ng-container *ngFor="let image of pagination.items | async; trackBy: trackByImage">

				<rj-image-card [image]="image"></rj-image-card>

		</ng-container>

</rj-paginated-resources>

Thanks you for your issue report. For the last point, there are many issues in the tracker related to template references. For the others, we will investigate.

Can you give me an example of log for this item :
 ?
Concerning the check-pipe, can you remove it form your configuration for this moment because there is an issue opened (issue #365 ).

Definitely:
/users/rolandjitsu/projects/test/src/app/test.component.html
ERROR: 4:4    angular-whitespace        The pipe operator should be surrounded by one space on each side, i.e. " | ".

And if you remove the check-pipe in your lint, what's happening ?

If I remove that, I get no errors 😄

Ok nice. You can monitor this issue for resolution.  I will take a look at this weekend.

Maybe it worth to create a new issue for this, but since the title is a bit generic, let's report it here:
Having:
<md-input-container
  <input type="text"
         placeholder="Some placeholder"
         mdInput
         [mdAutocomplete]="auto"
</md-input-container>

<md-autocomplete #auto="mdAutocomplete">
  <md-option [value]="value" *ngFor="let value of values">
    {{ value }}
  </md-option>
</md-autocomplete>

Results in: the property "auto" that you're trying to access does not exist in the class declaration.

That's the expected behavior from the rule template-use-public.

Lets reopen the issue since there are problems in other rules (angular-whitespace has some flaws).

The problem in all rules which involve EmbeddedTemplate is that the syntax is being desugared from:

to:

which breaks our mapping. Here's the solution by the language service. It's not straightforward. Most likely I'll reuse it, however, we risk to have frequent breaking changes given the private APIs being used there.

mmhm, i hope this will be okay ...

I'm afraid we'll need to keep this. It can be implemented with a strategy, doesn't have to be in a long function but the logic will remain.

Hi @mgechev, have you progress in this issue ?

Haven't done anything here yet. The way to go is custom expression parser for *-prefixed attributes.

ok, I'll look at this If I have time.

I'm still seeing some problems with the check-pipe rule for:

± {{ product.propagationTolerance | number }}

For the latter, removing ± seems to fix it.

@rolandjitsu thanks for pointing this out! I'll move it to a separate issue. Hopefully we'll be able to soon clean the glitches and open a PR to Angular CLI with the new features.


JsonPbCodecFactory needs to check if the protobuf class exists

Environment

Dubbo version: 3.3

Steps to reproduce this issue
In PR Support more content types for Triple protocol protobuf class exists check been removed, bu it is required.
Pls. provide [GitHub address] to reproduce this issue.
Expected Behavior

Actual Behavior

If there is an exception, please attach the exception trace:
Just put your stack trace here!

Fixd in  https://github.com/apache/dubbo/pull/13607


stat/distuv: Extend test coverage for Bernoulli distribution and fix some functions

This change modifies Gonum to provide almost 100% test coverage for Bernoulli distribution type in stats/distuv, fix Quantile and Entropy functions and other minor fixes.
Please take a look.

AppVeyor build failed with what looks like a transient error:
Build started
git clone -q https://github.com/gonum/gonum.git c:\gopath\src\gonum.org\v1\gonum
git fetch -q origin +refs/pull/1337/merge:
git checkout -qf FETCH_HEAD
Restoring build cache
Cache 'C:\Users\appveyor\AppData\Local\go-build' - Restored
%GOROOT%\bin\go version
go version go1.13.3 windows/amd64
%GOROOT%\bin\go get -v -t ./...
go<EMAIL_ADDRESS>Get<EMAIL_ADDRESS>dial tcp: lookup proxy.golang.org: no such host
Command exited with code 1

I kicked it.

PTAL.

Happy 1337 PR!


Standardize the organization of the main and submodules

Follow the convention used within pyswmm: support cleaner importing of the main classes, straighten out the config and definitions.
support these pattern:
from swmmio import Model, FloodReport, ComparisonReport, INPDiff, BuildInstructions

mymodel = Model('model.inp')
mymodel.draw(param, ...) #is there a better function word?
mymodel.conduits = modified_conduits #setters/getters to make changing a model more straightforward

#access global/config variables in a more obvious way
import swmmio
swmmio.config.prj = 'epsg:2272'
swmmio.config.shapefile_directory = '/path/containing/shapefiles/for/basemap'

Coordinate reference information should be stored at the model object level instead of in a global config setting. For example:
mymodel = swmmio.Model('path/to/model.inp')
mymodel.crs = 'epsg:2272'

Getting and setting model data should be straightforward. A possible implementation could look like this:
model = swmmio.Model('path/to/model.inp')

# get dataframe of junctions section from inp file
juncs = model.inp.junctions

# change the datum
juncs['Elevation'] = juncs['Elevation'] + 10
model.inp.junctions = juncs
model.save() #overwrite existing model or optionally set a new filename

# get a geojson representation object of the conduits
model.inp.conduits.to_json()


Make the app more accessible to blind people

We already follow standard usability best-practices like having big enough touch targets.
This PR improves the usability for blind people.
It was tested with TalkBack on Android and VoiceOver on iOS.
It consists of separate changes that ensure UI elements are identified correctly and their purpose can be determined (usually by adding a descriptive text)

Merged the core Touchable changes and several others.
Most of the other commits are also ready to merge, once their dependencies (e.g. textWithUnreadCount) are ready.

@jesse-troy Thanks for the ping. Let's discuss on the issue thread (or chat.zulip.org) -- I've just added a comment there.

#4419 is open, which may mean it'll soon be time to close this PR. We'll want to do at least a quick check that there isn't anything else here in Boris's PR that we want before closing it.
Greg said, at https://github.com/zulip/zulip-mobile/issues/4394#issuecomment-758250719:

Another note: the old PR #2753 contains fixes for some of the items above. In particular:

On the PM-conversations screen, if there's a group-PM thread, the initials that we use for making up an avatar get read out. They shouldn't be.

when you select a stream it says something like "Test here. Five thousand seven hundred and five." (for #test-here with 5705 unreads.) The number should probably say "unreads" or something. Needs playing with other apps to see what conventions are.

most, possibly all, other nav buttons on main screen and in nav bars

On the PM-conversations screen, the avatars are selectable. They shouldn't be

different message for NavBarBackButton between iOS vs. Android

A good place to start would be to revive the changes from that PR.


std::aligned_storage is deprecated in C++23

The type triat std::aligned_storage will be deprecated from C++23 onward, since it's used in some modules, like memory compilation fails if you run it with -Wall -Werror in GCC.

您的邮件我已收到，谢谢合作！


dom-repeat filter/sort needs to be able to observe parent scope

Right now, the dom-repeat filter and sort only refire on array mutations or item subproperty changes with the observe attribute. However this ignores a very common use case for filtering and sorting: user-driven changes to filter. Imagine for instance a simple list of items with a "text search" filter:
<template is="dom-repeat" filter="search">
  <span>[[item.name]]</span>
</template>

<script>
Polymer({
  search: function(item) {
    return item.name.toLowerCase().indexOf(this.q.toLowerCase()) >= 0;
  }
});
</script>

In this scenario, there is no way to make the template re-stamp when an external parameter changes (e.g. q in the example).

Note that because of this limitation I am currently manually calling through to the private _render() method in my app code. I didn't see any other way to achieve the desired effect.

Since dom-repeat isn't bound to that data (q in your example), it won't receive notifications for changes to it (as opposed to items, which is why the convenience observe property is possible).
For now, the pattern will be for external dependencies of sort/filter, the user will need to observe those properties and call render() manually to refresh the list.  This doesn't quite work right now (as you noted), but I'll push a fix this morning to make that go.

@kevinpschaaf How to call render from below code:
<template id="resultList" is="dom-repeat" items="{{ schedules }}" filter="filterRoom" as="schedule" index-as="scheduleId">
...
</template>

???

@euclid1990
this.$.resultList.render();

Call that after you change any external dependencies to the filterRoom function.


cannot upload file to server. no such file or directory, open 'C:\Users\MyPC.ssh\config'

i try to reset my compute. but nothing change. message:
[05-14 17:46:22] [warn] ENOENT: no such file or directory, open 'C:\Users\MyPC.ssh\config' load C:\Users\MyPC.ssh\config failed
[05-14 17:46:23] [warn] Can't set modified time to the file because Failure
[05-14 17:46:23] [error] Error: No such file
at SFTPStream._transform (c:\Users\MyPC.vscode\extensions\liximomo.sftp-1.12.9\node_modules\ssh2-streams\lib\sftp.js:412:27)
at SFTPStream.Transform._read (internal/streams/transform.js:205:10)
at SFTPStream._read (c:\Users\MyPC.vscode\extensions\liximomo.sftp-1.12.9\node_modules\ssh2-streams\lib\sftp.js:183:15)
at SFTPStream.Transform._write (internal/streams/transform.js:193:12)
at writeOrBuffer (internal/streams/writable.js:358:12)
at SFTPStream.Writable.write (internal/streams/writable.js:303:10)
at Channel.ondata (internal/streams/readable.js:719:22)
at Channel.emit (events.js:315:20)
at addChunk (internal/streams/readable.js:309:12)
at readableAddChunk (internal/streams/readable.js:284:9)
at Channel.Readable.push (internal/streams/readable.js:223:10)
at SSH2Stream. (c:\Users\MyPC.vscode\extensions\liximomo.sftp-1.12.9\node_modules\ssh2\lib\Channel.js:167:15)
at SSH2Stream.emit (events.js:315:20)
at parsePacket (c:\Users\MyPC.vscode\extensions\liximomo.sftp-1.12.9\node_modules\ssh2-streams\lib\ssh.js:3288:10)
at SSH2Stream._transform (c:\Users\MyPC.vscode\extensions\liximomo.sftp-1.12.9\node_modules\ssh2-streams\lib\ssh.js:694:13)
at SSH2Stream.Transform._read (internal/streams/transform.js:205:10)
at SSH2Stream._read (c:\Users\MyPC.vscode\extensions\liximomo.sftp-1.12.9\node_modules\ssh2-streams\lib\ssh.js:253:15)
at SSH2Stream.Transform._write (internal/streams/transform.js:193:12)
at writeOrBuffer (internal/streams/writable.js:358:12)
at SSH2Stream.Writable.write (internal/streams/writable.js:303:10)
at Socket.ondata (internal/streams/readable.js:719:22)
at Socket.emit (events.js:315:20)
at addChunk (internal/streams/readable.js:309:12)
at readableAddChunk (internal/streams/readable.js:284:9)
at Socket.Readable.push (internal/streams/readable.js:223:10)
at TCP.onStreamRead (internal/stream_base_commons.js:188:23) when local ➞ remote e:\threejs\index.html

Same problem here on multiple computers. It's because of the VS update.

Temporary fix:
Here are the steps:
Shutdown / Quit VS Code.
Locate the following file:
Mac OS X:
~/.vscode/extensions/liximomo.sftp-1.12.9/node_modules/ssh2-streams/lib/sftp.js
Windows:
C:\Users\account_name.vscode\extensions\liximomo.sftp-1.12.9\node_modules\ssh2-streams\lib\sftp.js
Make a backup copy of the file.
Modify line 388, which should be:
if ( code === STATUS_CODE . OK ) {
changing it to:
if (code === STATUS_CODE.OK || code === STATUS_CODE.NO_SUCH_FILE) {
Save the file.
Relaunch VS Code; test by uploading or downloading from your sftp server. The error should not be present.

New modded version by me that just work 😀
https://github.com/Natizyskunk/vscode-sftp/releases/tag/v1.12.10
To install it just follow thoses steps from within VSCode :

Select Extensions (Ctrl + Shift + X)
Open “More Action” menu(ellipsis on the top) and click “Install from VSIX…”
Locate VSIX file and select
Reload VSCode
Voilà !

I get the "No such file" error on every file, but it still uploads, I can see changes via SSH. is there a way to disable the error message for extension?

@iliailmer be aware that it looks like it's uploading but I get some random empty (0 bytes) files on the server.

I have searched for this uploadOnSave problem and found many different iterations of it. Mine is solved only by opening the sftp.json file and hitting a space bar once to alter that file. Save it. Then immediately switch to my altered regular file that I want uploaded on the save and hitting space bar once randomly somewhere then saving and it uploads properly on that save.
But if I then edit the regular file again in anyway and hit save. It won't upload until I switch over to the sftp.json file and alter it again, then return to the regular file and now alter it again and hit save!
The error I am getting in the debug is
[warn] ENOENT: no such file or directory, open '/Users//.ssh/config' load /Users//.ssh/config failed
So it seems like my .ssh folder maybe is messed up somehow? I thought maybe it wouldn't work while I was running XAMPP at the same time but I have since closed XAMPP and rebooted computer.
When I inspect my .ssh folder in my user folder I indeed do NOT have a config file there, and cannot find any information I trust on what to do next. This problem seems common among WINDOWS users but those solutions don't track with the Mac folder structures etc... I am on a mac.
My problem maybe very simple if someone could kindly help me understand what to add to the .ssh folder in my user folder? And maybe even suggest what I did that caused the .ssh folder to rid itself of the config file? I didn't do that on purpose obviously hahaha.
THANKS!

Just use my version (v1.13.0) that implement the new ssh2 v1.1.0 version that fix every problem 🙂 https://github.com/Natizyskunk/vscode-sftp/releases


mqadmin queryMsgById Command IP Error

i try query msg by msgId , but command Prompt error。 follow message " connect to <<IP_ADDRESS>:5664> failed " is error,IP address is <IP_ADDRESS>,not <IP_ADDRESS>:5664.
./mqadmin queryMsgById -d ppp -g ShowCommand -i 981FA8C0000016220000BD5803150100 -n localhost:9876
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
org.apache.rocketmq.remoting.exception.RemotingConnectException: connect to <<IP_ADDRESS>:5664> failed
at org.apache.rocketmq.remoting.netty.NettyRemotingClient.invokeSync(NettyRemotingClient.java:393)
at org.apache.rocketmq.client.impl.MQClientAPIImpl.viewMessage(MQClientAPIImpl.java:661)
at org.apache.rocketmq.client.impl.MQAdminImpl.viewMessage(MQAdminImpl.java:252)
at org.apache.rocketmq.tools.admin.DefaultMQAdminExtImpl.viewMessage(DefaultMQAdminExtImpl.java:958)
at org.apache.rocketmq.tools.admin.DefaultMQAdminExtImpl.consumeMessageDirectly(DefaultMQAdminExtImpl.java:724)
at org.apache.rocketmq.tools.admin.DefaultMQAdminExt.consumeMessageDirectly(DefaultMQAdminExt.java:397)
at org.apache.rocketmq.tools.command.message.QueryMsgByIdSubCommand.pushMsg(QueryMsgByIdSubCommand.java:269)
at org.apache.rocketmq.tools.command.message.QueryMsgByIdSubCommand.execute(QueryMsgByIdSubCommand.java:237)
at org.apache.rocketmq.tools.command.MQAdminStartup.main0(MQAdminStartup.java:132)
at org.apache.rocketmq.tools.command.MQAdminStartup.main(MQAdminStartup.java:83)

@xox9001 There maybe multi network interfaces in the host, the rocketmq broker will bind to one of them.
You could use mqadmin clusterList to check the binded ip.
Alternatively, you could config the "brokerIP1" in the conf to have a determinate binding.

i config brokerIP1=<IP_ADDRESS>,my cluster only one broker and one namesrv. use code push and consumer no problem,but use mqadmin has error

@xox9001 There maybe multi network interfaces in the host, the rocketmq broker will bind to one of them.
You could use mqadmin clusterList to check the binded ip.
Alternatively, you could config the "brokerIP1" in the conf to have a determinate binding.

i config brokerIP1=<IP_ADDRESS>,my cluster only one broker and one namesrv. use code push and consumer no problem,but use mqadmin has error

@xox9001 There maybe multi network interfaces in the host, the rocketmq broker will bind to one of them.
You could use mqadmin clusterList to check the binded ip.
Alternatively, you could config the "brokerIP1" in the conf to have a determinate binding.

Thanks for your reply

@xox9001 There maybe multi network interfaces in the host, the rocketmq broker will bind to one of them.
You could use mqadmin clusterList to check the binded ip.
Alternatively, you could config the "brokerIP1" in the conf to have a determinate binding.

my cluster runtime is docker,i have modified broker config brokerIP1=<IP_ADDRESS> ，and it's already in effect

close due to time too long, if this issue still occurs on the latest version, please reopen this issue again.


Change gulpfile.js snippet content type to JavaScript

Change the gulpfile.js code snippet content type from JSON to JavaScript to improve syntax highlighting.

@scottaddie,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

@scottaddie  Thanks!


Switch to Intent getter instead of storing it in memory

Looking over at Android docs and other resources (cough StackOverflow cough), they all spawn new Intent objects instead of storing them in memory. I guess it's easier to spawn new Intent instead of storing it in memory and then checking if it's initialized.
(also makes code a bit more readable IMO)

Hmm, makes sense I guess. Thanks!
Notes: Closes #27


Enable tests for MSSQL and Oracle

The latest Vert.x SQL client solves a couple of issues:

Searching the UUID in Oracle
Storing @Lob for MSSQL

I've also updated the limitations for Db2 (@Lob doesn't work)

Great!


Experimental new implementation of Eventing which allows for publishi…

…ng the results of any called endpoint no matter how it was invoked
Just a draft PR, left to do is to devise a good test suite for it, and bake that into the TCK.
Will update this if the design is deemed sound.

Merging … next step is to add verification to the TCK


ERROR: Could not find a version that satisfies the requirement dataclasses~=0.7 (from crslab) ERROR: No matching distribution found for dataclasses~=0.7

How to fix it?

Thanks for your feedback. We have fixed the requirements.txt in the latest update since the package is only needed for python 3.6.

Thanks for your feedback. We have fixed the requirements.txt in the latest update since the package is only needed for python 3.6.


MINOR: remove unused constructor param from ProcessorStateManager

Remove applicationId parameter as it is no longer used.

@guozhangwang @mjsax @enothereska

Merged to trunk.


Revert "chore(apps/prod/triggermesh): add triggermesh core and broker resource"

Reverts PingCAP-QE/ee-ops#857
revert reason:

kubernetes version "1.23.7" is not compatible, need at least "1.25.0-0"

/approve


Remove version: BrightSign.BrightAuthorConfigurator version 1.02

[Automated] It returns code over 400 in all urls
Microsoft Reviewers: Open in CodeFlow

Hi @Exorcism0666,
This manifest has the highest version number for this package. Is it available from another location? (This might be in error if the version is switching from semantic to string, or string to semantic.)
(Automated response - build 876.)

URL: https://brightsignbiz.s3.amazonaws.com/downloads/BrightAuthor_Configurator(BSNEE_3.9).zip
Response status code does not indicate success: 403 (Forbidden).
(Automated message - build 876)

For moderators
This account is automated by Github Actions and the source code was created by CoolPlayLin. If you have any questions about any pull request, don't hesitate to ping Exorcism0666.

[!warning]
With the new version of Komac, numerous Pull Requests may contain bugs or unwanted elements. If such issues arise, please tag russellbanks so that these bugs can be addressed in future updates.

[!important]
Please carefully review these Pull Request before merging. If it is a Pull Request for removing incorrect content and the URLs are issue, free upon manual checking, please close this Pull Request directly. (It is best to inform Exorcism0666 of the closure.)

良い一日をお過ごしください！

URL: https://brightsignbiz.s3.amazonaws.com/downloads/BrightAuthor_Configurator(BSNEE_3.9).zip
Response status code does not indicate success: 403 (Forbidden).
(Automated message - build 876)

URL: https://brightsignbiz.s3.amazonaws.com/downloads/BrightAuthor_Configurator(BSNEE_3.9).zip
Status code: 200
(Automated message - build 634)

URL: https://brightsignbiz.s3.amazonaws.com/downloads/BrightAuthor_Configurator(BSNEE_3.9).zip
Response status code does not indicate success: 403 (Forbidden).
(Automated message - build 876)

URL: https://brightsignbiz.s3.amazonaws.com/downloads/BrightAuthor_Configurator(BSNEE_3.9).zip
Response status code does not indicate success: 403 (Forbidden).
(Automated message - build 876)


Update languages.yml

Added file extension to GLSL language
Description

Added support for GLSL shader file extension .shadron written for Shadron
https://www.arteryengine.com/shadron/

Checklist:

[x] I am associating a language with a new file extension.

[x] The new extension is used in hundreds of repositories on GitHub.com

Search results for each extension:

https://github.com/search?l=&q=glsl+extension%3Ashadron&type=Code

[x] I have included a real-world usage sample for all extensions added in this PR:

Sample source(s):

https://github.com/Fubaxiusz/shadron-shaders/blob/master/Shaders/Neutral LUT.shadron

Sample license(s):

Creative Commons Attribution-ShareAlike 4.0 International License.

[ ] I have included a change to the heuristics to distinguish my language from others using the same extension.

Please read the contribution guidelines and fix this pull request.

Please read the contribution guidelines and fix this pull request.

Guidelines read and pull request fixed ;)

Nop, you're still missing a sample and a proper search query ;)

Nop, you're still missing a sample and a proper search query ;)

Ok I uploaded sample to samples folder and added search query, hope it's legit.
Regarding heuristics I don't know what to do with this, sounds like something you would eat sushi with.

Everything should be tip-top now ;)

When you were reading the contribution guidelines, did you happen across the part stating that GitHub's criteria for officially supported extensions is a minimum of "hundreds of unique repositories and users"...?
These are the only unique users/repositories on GitHub who are using this file extension somewhere in their project:
andrewhills/Raytracer
Atonement100/SassC
BitzaWolf/ObjToShadron
BitzaWolf/shadron
Chlumsky/shadron-example-extension
DomNomNom/ShadronSketches
Fubaxiusz/shadron-shaders
ImSpeakEnglish/fractal-oscillating-rectangles
ManuelSilva/ShadronPlayground
Poudingue/deferred_stuff
Poudingue/material_design_shadron
Poudingue/multiscale-tonemapping-shadron
ronja-tutorials/ShaderTutorials
Shimmen/ShadronPlayground
skrillcon/Shadron
skurmedel/shaders
SvDvorak/Shaders
tankorsmash/ShadronTesting
THISISAGOODNAME/thebookofshader-shadron
trmatthe/shadron
Usami-Renko/vulkan-tutorial-rust
zerox22x/shadronshaders

The full list of URLs is only 145 files:

https://raw.githubusercontent.com/andrewhills/Raytracer/1b6600a618cdc624854c6b8a473f1240028553fb/demo.shadron
https://raw.githubusercontent.com/andrewhills/Raytracer/1b6600a618cdc624854c6b8a473f1240028553fb/demo_rm.shadron
https://raw.githubusercontent.com/Atonement100/SassC/bdcbdeac069347fe9fdc27b81d43fc852b3dd93f/Shadron/crosshair.shadron
https://raw.githubusercontent.com/Atonement100/SassC/bdcbdeac069347fe9fdc27b81d43fc852b3dd93f/Shadron/shieldmonolith.shadron
https://raw.githubusercontent.com/Atonement100/SassC/bdcbdeac069347fe9fdc27b81d43fc852b3dd93f/Shadron/shieldmonolith_bubble.shadron
https://raw.githubusercontent.com/Atonement100/SassC/bdcbdeac069347fe9fdc27b81d43fc852b3dd93f/Shadron/shieldmonolith_old.shadron
https://raw.githubusercontent.com/BitzaWolf/ObjToShadron/452d65c899c776d81af61ff64c0d6d3e9d6b8355/ExampleShadron.shadron
https://raw.githubusercontent.com/BitzaWolf/ObjToShadron/452d65c899c776d81af61ff64c0d6d3e9d6b8355/Output.shadron
https://raw.githubusercontent.com/BitzaWolf/shadron/5a7105073639ffa61086b53406a1afde55c90bd0/Common/SquarePanel.shadron
https://raw.githubusercontent.com/BitzaWolf/shadron/5a7105073639ffa61086b53406a1afde55c90bd0/Cubemap/Cubemap.shadron
https://raw.githubusercontent.com/BitzaWolf/shadron/5a7105073639ffa61086b53406a1afde55c90bd0/Refreaction/Refraction.shadron
https://raw.githubusercontent.com/BitzaWolf/shadron/5a7105073639ffa61086b53406a1afde55c90bd0/Refreaction/ViewDirection.shadron
https://raw.githubusercontent.com/BitzaWolf/shadron/5a7105073639ffa61086b53406a1afde55c90bd0/Refreaction/WolfModel.shadron
https://raw.githubusercontent.com/Chlumsky/shadron-example-extension/3e00de10f5bd8505a58082bec5279de41a21f7c0/extension-test.shadron
https://raw.githubusercontent.com/DomNomNom/ShadronSketches/6d57c30d8d76ede17433426797e00bdb64378063/colorToAlpha.shadron
https://raw.githubusercontent.com/DomNomNom/ShadronSketches/6d57c30d8d76ede17433426797e00bdb64378063/dvd.shadron
https://raw.githubusercontent.com/DomNomNom/ShadronSketches/6d57c30d8d76ede17433426797e00bdb64378063/ebbFlow.shadron
https://raw.githubusercontent.com/DomNomNom/ShadronSketches/6d57c30d8d76ede17433426797e00bdb64378063/fierstein.shadron
https://raw.githubusercontent.com/DomNomNom/ShadronSketches/6d57c30d8d76ede17433426797e00bdb64378063/hilbert.shadron
https://raw.githubusercontent.com/DomNomNom/ShadronSketches/6d57c30d8d76ede17433426797e00bdb64378063/infinizoom.shadron
https://raw.githubusercontent.com/DomNomNom/ShadronSketches/6d57c30d8d76ede17433426797e00bdb64378063/invertZoom.shadron
https://raw.githubusercontent.com/DomNomNom/ShadronSketches/6d57c30d8d76ede17433426797e00bdb64378063/julia.shadron
https://raw.githubusercontent.com/DomNomNom/ShadronSketches/6d57c30d8d76ede17433426797e00bdb64378063/library/colorSpaces.shadron
https://raw.githubusercontent.com/DomNomNom/ShadronSketches/6d57c30d8d76ede17433426797e00bdb64378063/library/complexNumbers.shadron
https://raw.githubusercontent.com/DomNomNom/ShadronSketches/6d57c30d8d76ede17433426797e00bdb64378063/library/lerp.shadron
https://raw.githubusercontent.com/DomNomNom/ShadronSketches/6d57c30d8d76ede17433426797e00bdb64378063/library/loopAnimation.shadron
https://raw.githubusercontent.com/DomNomNom/ShadronSketches/6d57c30d8d76ede17433426797e00bdb64378063/library/random.shadron
https://raw.githubusercontent.com/DomNomNom/ShadronSketches/6d57c30d8d76ede17433426797e00bdb64378063/megatron.shadron
https://raw.githubusercontent.com/DomNomNom/ShadronSketches/6d57c30d8d76ede17433426797e00bdb64378063/particles.shadron
https://raw.githubusercontent.com/DomNomNom/ShadronSketches/6d57c30d8d76ede17433426797e00bdb64378063/perlinLava.shadron
https://raw.githubusercontent.com/DomNomNom/ShadronSketches/6d57c30d8d76ede17433426797e00bdb64378063/pointilism.shadron
https://raw.githubusercontent.com/DomNomNom/ShadronSketches/6d57c30d8d76ede17433426797e00bdb64378063/vibrator.shadron
https://raw.githubusercontent.com/Fubaxiusz/shadron-shaders/1d9cdd655a2c93dc963de648891a8444c5552142/Shaders/Neutral%20LUT.shadron
https://raw.githubusercontent.com/Fubaxiusz/shadron-shaders/42557206e1d04504a3d72f00e755ce363f9521a0/Shaders/Equirect2Equisolid.shadron
https://raw.githubusercontent.com/ImSpeakEnglish/fractal-oscillating-rectangles/a16f1cca9047e4b1d41526fc4e06b08f4eb07cee/code.shadron
https://raw.githubusercontent.com/ManuelSilva/ShadronPlayground/86dc1b7e8050901afbb56d79ee40c342a9bc4171/CircumferenceShader/audioCircumference.shadron
https://raw.githubusercontent.com/ManuelSilva/ShadronPlayground/86dc1b7e8050901afbb56d79ee40c342a9bc4171/CircumferenceShader/CDXShadron.shadron
https://raw.githubusercontent.com/ManuelSilva/ShadronPlayground/86dc1b7e8050901afbb56d79ee40c342a9bc4171/CircumferenceShader/circleShader.shadron
https://raw.githubusercontent.com/ManuelSilva/ShadronPlayground/86dc1b7e8050901afbb56d79ee40c342a9bc4171/CircumferenceShader/shinyCircumference.shadron
https://raw.githubusercontent.com/ManuelSilva/ShadronPlayground/86dc1b7e8050901afbb56d79ee40c342a9bc4171/FakeSphereShader/fakeSphere.shadron
https://raw.githubusercontent.com/ManuelSilva/ShadronPlayground/86dc1b7e8050901afbb56d79ee40c342a9bc4171/GoochShader/goochShading.shadron
https://raw.githubusercontent.com/ManuelSilva/ShadronPlayground/86dc1b7e8050901afbb56d79ee40c342a9bc4171/PerlinPuddleShader/PerlinPuddleShader.shadron
https://raw.githubusercontent.com/ManuelSilva/ShadronPlayground/86dc1b7e8050901afbb56d79ee40c342a9bc4171/PortugalFlagShader/portugalFlag.shadron
https://raw.githubusercontent.com/ManuelSilva/ShadronPlayground/86dc1b7e8050901afbb56d79ee40c342a9bc4171/ToonShader/outline.shadron
https://raw.githubusercontent.com/ManuelSilva/ShadronPlayground/86dc1b7e8050901afbb56d79ee40c342a9bc4171/ToonShader/toonShader.shadron
https://raw.githubusercontent.com/Poudingue/deferred_stuff/9b1efb87e0a58ae68842cc7f1243422803bf9fff/SSDO.shadron
https://raw.githubusercontent.com/Poudingue/deferred_stuff/bbdfb0297bf39d56ae15ec65fb4cfb40bbc99199/material_rendering.shadron
https://raw.githubusercontent.com/Poudingue/deferred_stuff/cea244c8dfc7007d660b3fda97ade8124209a7be/fusion_v0.shadron
https://raw.githubusercontent.com/Poudingue/material_design_shadron/8ac122cd3c75a266d65a45c18eca08a41766c401/simple0.shadron
https://raw.githubusercontent.com/Poudingue/multiscale-tonemapping-shadron/8a4f1bd4f65ba9f50f5d5d770ff3d85d1d3feef7/tonemapping0.shadron
https://raw.githubusercontent.com/ronja-tutorials/ShaderTutorials/0fbf1f3e6b52bf3a7054de8214604aca51052075/Assets/040_Dithered_Lighting/Textures/Circles.shadron
https://raw.githubusercontent.com/ronja-tutorials/ShaderTutorials/0fbf1f3e6b52bf3a7054de8214604aca51052075/Assets/040_Dithered_Lighting/Textures/Stripes.shadron
https://raw.githubusercontent.com/Shimmen/ShadronPlayground/42ed3de693565735d826d3be74551187abfbb140/VintagePhoto.shadron
https://raw.githubusercontent.com/skrillcon/Shadron/9260edd37d129e1917ba7a56b406f86d01d4b1d7/Cogwheel.shadron
https://raw.githubusercontent.com/skrillcon/Shadron/9260edd37d129e1917ba7a56b406f86d01d4b1d7/PulsingCircle.shadron
https://raw.githubusercontent.com/skrillcon/Shadron/9260edd37d129e1917ba7a56b406f86d01d4b1d7/Worley.shadron
https://raw.githubusercontent.com/skurmedel/shaders/c6458070c16fdbe7c574a9a6c97e4d26fac02f88/shadron/crt.shadron
https://raw.githubusercontent.com/skurmedel/shaders/c6458070c16fdbe7c574a9a6c97e4d26fac02f88/shadron/fast_mipmap_bloom.shadron
https://raw.githubusercontent.com/skurmedel/shaders/c6458070c16fdbe7c574a9a6c97e4d26fac02f88/shadron/gamma_correct.shadron
https://raw.githubusercontent.com/skurmedel/shaders/c6458070c16fdbe7c574a9a6c97e4d26fac02f88/shadron/luma.shadron
https://raw.githubusercontent.com/skurmedel/shaders/c6458070c16fdbe7c574a9a6c97e4d26fac02f88/shadron/simple_tonecurve.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_10_koch_snowflake.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_11_falling_snow.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_12_glitch_shader.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_13_continued_glitching.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_14_crosshatch_shading.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_15_infinite_forward.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_16_1_fixed_thresholding.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_16_2_random_dither.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_16_3_patterning.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_16_dither_and_banding.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_17_patterning_improved.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_1_inverted_colors.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_2_color_correction.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_3_black_vignette.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_4_noised_image.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_5_melt_to_middle.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_6_blurred_vignette.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_7_3d_rendering.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_8_multipass_flame.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/AdventOfShaders/Day_9_vertex_snapped_low_res_flame.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/Shadron/banding.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/Shadron/dizzycircle.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/Shadron/radial_blur.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/Shadron/rgb2hsv.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/Shadron/streak.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/Shadron/wave_testing.shadron
https://raw.githubusercontent.com/SvDvorak/Shaders/69918817fc3d379f94d1a30c05b74cadaa189473/Shadron/width_band_bloom.shadron
https://raw.githubusercontent.com/tankorsmash/ShadronTesting/d95937f2de9f494e6f44b7ca74b296e01b2a6c97/test.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/boilerplate.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH02-HelloWorld/script1.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH03-Uniforms/script1.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH03-Uniforms/script2-2.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH03-Uniforms/script2.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH05-ShapingFunctions/script1.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH05-ShapingFunctions/script2.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH05-ShapingFunctions/script3.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH05-ShapingFunctions/script4.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH06-Colors/script1.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH06-Colors/script2.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH06-Colors/script3.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH06-Colors/script4.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH07-Shapes/script1.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH07-Shapes/script2.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH07-Shapes/script3.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH07-Shapes/script4.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH07-Shapes/script5.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH07-Shapes/script6.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH08-2DMatrices/script1.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH08-2DMatrices/script2.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH08-2DMatrices/script3.shadron
https://raw.githubusercontent.com/THISISAGOODNAME/thebookofshader-shadron/af37a05f597d309e76051b58dcc4e0faa15dc574/CH08-2DMatrices/script4.shadron
https://raw.githubusercontent.com/trmatthe/shadron/029b4794776444dd7e7997ac5b50a9521b22e6e0/sort-of-copper-bars.shadron
https://raw.githubusercontent.com/Usami-Renko/vulkan-tutorial-rust/78f5df1a66a811a467e97e324be0e187d5f8b24e/snapshot/CombineImage.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/cogs/cogs.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/cube/cube.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/cubemap/cubemap.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/cubemap/HeightMapTesting.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/demod%20buisniss%20card/BusinessCard.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/demod%20buisniss%20card/util.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/font/RenderText.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/font/RenderTextcommented.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/font/RenderTextmod.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/heightmap/heightmap.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/heightmap/heightmap2.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/heightmap/HeightMapTesting.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/heightmap/New%20folder/heightmap2.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/heightmap/New%20folder/HeightMapTesting.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/heightmap/New%20folder/ModelUtils.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/HeightSphere/HeightMapTesting.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/HeightSphere/HeightSphere.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/HeightSphere/ModelUtils.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/ParticleTest.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/ParticleTest2.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/ParticleTest23.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/perlin%20noise/perlin%20-%20Copy.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/perlin%20noise/perlin.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/perlin%20noise/test.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/perlin%20noise/testSprite.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/scratch/animation.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/scratch/convertshadertor.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/scratch/imageedit.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/scratch/scratch.shadron
https://raw.githubusercontent.com/zerox22x/shadronshaders/5daa7ecabbb20ec84085c680b0a893201a83e8ac/utility.shadron

Country:
State/Region:
City:

Country:
State/Region:
City:

Edit in JSFiddle
HTML
Result

Afghanistan
Åland Islands
Albania
Algeria
American Samoa
Andorra
Angola
Anguilla
Antarctica
Antigua and Barbuda
Argentina
Armenia
Aruba
Australia
Austria
Azerbaijan
Bahamas
Bahrain
Bangladesh
Barbados
Belarus
Belgium
Belize
Benin
Bermuda
Bhutan
Bolivia, Plurinational State of
Bonaire, Sint Eustatius and Saba
Bosnia and Herzegovina
Botswana
Bouvet Island
Brazil
British Indian Ocean Territory
Brunei Darussalam
Bulgaria
Burkina Faso
Burundi
Cambodia
Cameroon
Canada
Cape Verde
Cayman Islands
Central African Republic
Chad
Chile
China
Christmas Island
Cocos (Keeling) Islands
Colombia
Comoros
Congo
Congo, the Democratic Republic of the
Cook Islands
Costa Rica
Côte d'Ivoire
Croatia
Cuba
Curaçao
Cyprus
Czech Republic
Denmark
Djibouti
Dominica
Dominican Republic
Ecuador
Egypt
El Salvador
Equatorial Guinea
Eritrea
Estonia
Ethiopia
Falkland Islands (Malvinas)
Faroe Islands
Fiji
Finland
France
French Guiana
French Polynesia
French Southern Territories
Gabon
Gambia
Georgia
Germany
Ghana
Gibraltar
Greece
Greenland
Grenada
Guadeloupe
Guam
Guatemala
Guernsey
Guinea
Guinea-Bissau
Guyana
Haiti
Heard Island and McDonald Islands
Holy See (Vatican City State)
Honduras
Hong Kong
Hungary
Iceland
India
Indonesia
Iran, Islamic Republic of
Iraq
Ireland
Isle of Man
Israel
Italy
Jamaica
Japan
Jersey
Jordan
Kazakhstan
Kenya
Kiribati
Korea, Democratic People's Republic of
Korea, Republic of
Kuwait
Kyrgyzstan
Lao People's Democratic Republic
Latvia
Lebanon
Lesotho
Liberia
Libya
Liechtenstein
Lithuania
Luxembourg
Macao
Macedonia, the former Yugoslav Republic of
Madagascar
Malawi
Malaysia
Maldives
Mali
Malta
Marshall Islands
Martinique
Mauritania
Mauritius
Mayotte
Mexico
Micronesia, Federated States of
Moldova, Republic of
Monaco
Mongolia
Montenegro
Montserrat
Morocco
Mozambique
Myanmar
Namibia
Nauru
Nepal
Netherlands
New Caledonia
New Zealand
Nicaragua
Niger
Nigeria
Niue
Norfolk Island
Northern Mariana Islands
Norway
Oman
Pakistan
Palau
Palestinian Territory, Occupied
Panama
Papua New Guinea
Paraguay
Peru
Philippines
Pitcairn
Poland
Portugal
Puerto Rico
Qatar
Réunion
Romania
Russian Federation
Rwanda
Saint Barthélemy
Saint Helena, Ascension and Tristan da Cunha
Saint Kitts and Nevis
Saint Lucia
Saint Martin (French part)
Saint Pierre and Miquelon
Saint Vincent and the Grenadines
Samoa
San Marino
Sao Tome and Principe
Saudi Arabia
Senegal
Serbia
Seychelles
Sierra Leone
Singapore
Sint Maarten (Dutch part)
Slovakia
Slovenia
Solomon Islands
Somalia
South Africa
South Georgia and the South Sandwich Islands
South Sudan
Spain
Sri Lanka
Sudan
Suriname
Svalbard and Jan Mayen
Swaziland
Sweden
Switzerland
Syrian Arab Republic
Taiwan, Province of China
Tajikistan
Tanzania, United Republic of
Thailand
Timor-Leste
Togo
Tokelau
Tonga
Trinidad and Tobago
Tunisia
Turkey
Turkmenistan
Turks and Caicos Islands
Tuvalu
Uganda
Ukraine
United Arab Emirates
United Kingdom
United States
United States Minor Outlying Islands
Uruguay
Uzbekistan
Vanuatu
Venezuela, Bolivarian Republic of
Viet Nam
Virgin Islands, British
Virgin Islands, U.S.
Wallis and Futuna
Western Sahara
Yemen
Zambia
Zimbabwe

Edit in JSFiddle
HTML
Result

Afghanistan
Åland Islands
Albania
Algeria
American Samoa
Andorra
Angola
Anguilla
Antarctica
Antigua and Barbuda
Argentina
Armenia
Aruba
Australia
Austria
Azerbaijan
Bahamas
Bahrain
Bangladesh
Barbados
Belarus
Belgium
Belize
Benin
Bermuda
Bhutan
Bolivia, Plurinational State of
Bonaire, Sint Eustatius and Saba
Bosnia and Herzegovina
Botswana
Bouvet Island
Brazil
British Indian Ocean Territory
Brunei Darussalam
Bulgaria
Burkina Faso
Burundi
Cambodia
Cameroon
Canada
Cape Verde
Cayman Islands
Central African Republic
Chad
Chile
China
Christmas Island
Cocos (Keeling) Islands
Colombia
Comoros
Congo
Congo, the Democratic Republic of the
Cook Islands
Costa Rica
Côte d'Ivoire
Croatia
Cuba
Curaçao
Cyprus
Czech Republic
Denmark
Djibouti
Dominica
Dominican Republic
Ecuador
Egypt
El Salvador
Equatorial Guinea
Eritrea
Estonia
Ethiopia
Falkland Islands (Malvinas)
Faroe Islands
Fiji
Finland
France
French Guiana
French Polynesia
French Southern Territories
Gabon
Gambia
Georgia
Germany
Ghana
Gibraltar
Greece
Greenland
Grenada
Guadeloupe
Guam
Guatemala
Guernsey
Guinea
Guinea-Bissau
Guyana
Haiti
Heard Island and McDonald Islands
Holy See (Vatican City State)
Honduras
Hong Kong
Hungary
Iceland
India
Indonesia
Iran, Islamic Republic of
Iraq
Ireland
Isle of Man
Israel
Italy
Jamaica
Japan
Jersey
Jordan
Kazakhstan
Kenya
Kiribati
Korea, Democratic People's Republic of
Korea, Republic of
Kuwait
Kyrgyzstan
Lao People's Democratic Republic
Latvia
Lebanon
Lesotho
Liberia
Libya
Liechtenstein
Lithuania
Luxembourg
Macao
Macedonia, the former Yugoslav Republic of
Madagascar
Malawi
Malaysia
Maldives
Mali
Malta
Marshall Islands
Martinique
Mauritania
Mauritius
Mayotte
Mexico
Micronesia, Federated States of
Moldova, Republic of
Monaco
Mongolia
Montenegro
Montserrat
Morocco
Mozambique
Myanmar
Namibia
Nauru
Nepal
Netherlands
New Caledonia
New Zealand
Nicaragua
Niger
Nigeria
Niue
Norfolk Island
Northern Mariana Islands
Norway
Oman
Pakistan
Palau
Palestinian Territory, Occupied
Panama
Papua New Guinea
Paraguay
Peru
Philippines
Pitcairn
Poland
Portugal
Puerto Rico
Qatar
Réunion
Romania
Russian Federation
Rwanda
Saint Barthélemy
Saint Helena, Ascension and Tristan da Cunha
Saint Kitts and Nevis
Saint Lucia
Saint Martin (French part)
Saint Pierre and Miquelon
Saint Vincent and the Grenadines
Samoa
San Marino
Sao Tome and Principe
Saudi Arabia
Senegal
Serbia
Seychelles
Sierra Leone
Singapore
Sint Maarten (Dutch part)
Slovakia
Slovenia
Solomon Islands
Somalia
South Africa
South Georgia and the South Sandwich Islands
South Sudan
Spain
Sri Lanka
Sudan
Suriname
Svalbard and Jan Mayen
Swaziland
Sweden
Switzerland
Syrian Arab Republic
Taiwan, Province of China
Tajikistan
Tanzania, United Republic of
Thailand
Timor-Leste
Togo
Tokelau
Tonga
Trinidad and Tobago
Tunisia
Turkey
Turkmenistan
Turks and Caicos Islands
Tuvalu
Uganda
Ukraine
United Arab Emirates
United Kingdom
United States
United States Minor Outlying Islands
Uruguay
Uzbekistan
Vanuatu
Venezuela, Bolivarian Republic of
Viet Nam
Virgin Islands, British
Virgin Islands, U.S.
Wallis and Futuna
Western Sahara
Yemen
Zambia
Zimbabwe


Demo not working

Hi Michael, many thanks for your package. I was trying to run the first example in the demo
import numpy as np import bayesfit as bf data = np.array([[0.0010,   45,   90],                  [0.0015,   50,   90],                  [0.0020,   44,   90],                  [0.0025,   44,   90],                  [0.0030,   52,   90],                  [0.0035,   53,   90],                  [0.0040,   62,   90],                  [0.0045,   64,   90],                  [0.0050,   76,   90],                  [0.0060,   79,   90],                  [0.0070,   88,   90],                  [0.0080,   90,   90],                  [0.0100,   90,   90]]); metrics, options = bf.fitmodel(data, sigmoid_type='logistic')
It returns
TypeError: 'float' object cannot be interpreted as an integer
May I know how to solve the issue

Found the dependencies.


NoSuchMethodException using HostRegexTableLoadBalancer

The runtime class loading of the HostRegexTableLoadBalancer is broken. It is likely this happened when it was refactored during the move to SPI. This exception can be seen in the manager log when running SuspendedTabletsIT, which seems to timeout often for me locally but the test can still pass even with this exception.

2021-05-27T10:39:11,473 [balancer.TableLoadBalancer] WARN : Failed to load table balancer class org.apache.accumulo.core.spi.balancer.HostRegexTableLoadBalancer for table !0
java.lang.NoSuchMethodException: org.apache.accumulo.core.spi.balancer.HostRegexTableLoadBalancer.(org.apache.accumulo.core.data.TableId)
        at java.lang.Class.getConstructor0(Class.java:3349) ~[?:?]
        at java.lang.Class.getConstructor(Class.java:2151) ~[?:?]
        at org.apache.accumulo.core.spi.balancer.TableLoadBalancer.constructNewBalancerForTable(TableLoadBalancer.java:58) ~[accumulo-core-2.1.0-SNAPSHOT.jar:2.1.0-SNAPSHOT]
        at org.apache.accumulo.core.spi.balancer.TableLoadBalancer.getBalancerForTable(TableLoadBalancer.java:91) [accumulo-core-2.1.0-SNAPSHOT.jar:2.1.0-SNAPSHOT]
        at org.apache.accumulo.core.spi.balancer.TableLoadBalancer.getAssignments(TableLoadBalancer.java:115) [accumulo-core-2.1.0-SNAPSHOT.jar:2.1.0-SNAPSHOT]
        at org.apache.accumulo.manager.Manager.getAssignments(Manager.java:1735) [accumulo-manager-2.1.0-SNAPSHOT.jar:2.1.0-SNAPSHOT]
        at org.apache.accumulo.manager.TabletGroupWatcher.getAssignmentsFromBalancer(TabletGroupWatcher.java:880) [accumulo-manager-2.1.0-SNAPSHOT.jar:2.1.0-SNAPSHOT]
        at org.apache.accumulo.manager.TabletGroupWatcher.flushChanges(TabletGroupWatcher.java:911) [accumulo-manager-2.1.0-SNAPSHOT.jar:2.1.0-SNAPSHOT]
        at org.apache.accumulo.manager.TabletGroupWatcher.run(TabletGroupWatcher.java:318) [accumulo-manager-2.1.0-SNAPSHOT.jar:2.1.0-SNAPSHOT]
2021-05-27T10:39:11,474 [balancer.TableLoadBalancer] INFO : Using balancer org.apache.accumulo.core.spi.balancer.SimpleLoadBalancer for table !0

@milleruntime Do you get this error every time you run the test? Anything special about your environment or how you are running the test? I have not been able to reproduce locally on my machine.

@milleruntime Do you get this error every time you run the test? Anything special about your environment or how you are running the test? I have not been able to reproduce locally on my machine.

Yes it seems to WARN with the exception every time, whether the test passes or not. I don't know of anything special in my environment. It happens whether I run the test in Intellij individually or on the command line with all the ITs.

Oops, I was just not looking at the right logs. I see the error now. This wasn't caused by moving balancers to the SPI but rather by PR #1888 instead. The test is setting the property TABLE_LOAD_BALANCER to HostRegexTableLoadBalancer, which is wrong since HostRegexTableLoadBalancer is a TableLoadBalancer and is intended to be used only with the property MANAGER_TABLET_BALANCER. This didn't change--the class HostRegexTableLoadBalancer never had a constructor with a single TableId parameter. I'll have a PR in a bit to fix. Given that, I'm going to remove the blocker label from this issue.

Oops, I was just not looking at the right logs. I see the error now. This wasn't caused by moving balancers to the SPI but rather by PR #1888 instead. The test is setting the property TABLE_LOAD_BALANCER to HostRegexTableLoadBalancer, which is wrong since HostRegexTableLoadBalancer is a TableLoadBalancer and is intended to be used only with the property MANAGER_TABLET_BALANCER. This didn't change--the class HostRegexTableLoadBalancer never had a constructor with a single TableId parameter. I'll have a PR in a bit to fix. Given that, I'm going to remove the blocker label from this issue.

Ah ok thanks for looking into this!


Prevent existing IDs from changing when adding new todos

More details: https://github.com/kkga/tdx/pull/9#issuecomment-950131605

I'm thinking of an implementation using gob to serialise the in-memory representation of the todos, along with their id, and save that to a file.
When tdx runs the next time, it'll de-serialise all of them, and only read (1) files that have a modification date later than the dump (2) new files.
This should provide some minor performance improvements while not really increasing complexity, and keep consistent ids.
I can try giving this a shot if this sounds good.

This sounds great.
I started initial work on persistent IDs using a bolt database a while ago, but I only spent a few hours on it to get familiar with how bolt works: https://github.com/kkga/tdx/commit/8a8124c373170f4baa23a2939105ad72e4a8ffea
My idea was to store the representation of vidir in a key-value store with id-filepath entries and then on each consecutive read, tdx will: (1) get the list of entries from the database, (2) walk the vidir path and remove/add any missing and new entries, (3) write the updates to database. This way the IDs will be stored in the database and should not change unless the user decides to rebuild the database by issuing some command. This is probably what todoman does?
I'm not sure of the benefits/downsides between using gob or a database, so feel free to use any approach you're comfortable benefits.


Compilation failure of filament Android library on macOS

I'm getting the following build fail (full text):
1: Task failed with an exception.
-----------
* Where:
Build file '/Users/rupert/GitHub/LearnHub/filament/android/samples/sample-gltf-bloom/build.gradle' line: 4

* What went wrong:
A problem occurred evaluating project ':samples:sample-gltf-bloom'.
> Failed to apply plugin [class 'FilamentToolsPlugin']
   > No such property: filament_tools_dir for class: FilamentToolsPlugin

In case it's relevant, I normally do a clean compile from the command line using the following command:
git clean -fdx; ./build.sh -p desktop -i release; ./build.sh -p android -i release
I narrowed down the change where it started to this commit.
I'm running on macOS Version 10.15.2.

Make sure you have Android Studio 3.6 and do a clean build first (build.sh -c).

I still get the same problem. I've installed Android Studio 3.6 RC 3, checked for updates, rebooted my Mac, cleaned the build, and run a git clean for good measure.
Am I missing some other update? I'll confess I'm not exactly sure where all the build tools live.

The only place where we check this property is properly guarded:
        if (project.hasProperty("filament_tools_dir")) {
            project.ext.filamentToolsPath = project.file("$filament_tools_dir")
        }

Your build logs also mention a missing compileSdkVersion but it is present in the gradle file.
What version of Filament are you trying to build? Would you mind trying a brand new checkout?

A brand new checkout on the master branch has the same problem. I can see the property check as well and no other references except in a tungsten folder, but that's an assignment.

One last thing to try: rm -rf ~/.gradle

OK that fixed it! That also explains why I saw some hysteresis going back-and-forth looking for the check-in that "broke" the build.
Thank you for your help.

This problem has cropped up again in a slightly different context and I seem to have made it go away by changing the accessor slightly. I replaced...
        if (project.hasProperty("filament_tools_dir")) {
            project.ext.filamentToolsPath = project.file("$filament_tools_dir")
        }

...with...
        if (project.hasProperty("filament_tools_dir")) {
            project.ext.filamentToolsPath = project.file(project.property("filament_tools_dir"))
        }

Matching project.hasProperty with project.property rather than relying on the $ property lookup syntax.

Thanks, that's a great catch. I must have introduced that regression during the move to a Gradle plugin.


Docker 25+ error 'API error (400): client version 1.18 is too old.'

What happened?
After updating docker engine i got error:
unable to connect to docker: API error (400): client version 1.18 is too old. Minimum supported API version is 1.24, please upgrade your client to a newer version

How to reproduce it?
Install docker engine version 25+ (where minimum api version higher than 1.18)
$ docker version
Client: Docker Engine - Community
 Version:           25.0.1
 API version:       1.44
 Go version:        go1.21.6
 Git commit:        29cf629
 Built:             Tue Jan 23 23:11:25 2024
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          25.0.1
  API version:      1.44 (minimum version 1.24)
  Go version:       go1.21.6
  Git commit:       71fa3ab
  Built:            Tue Jan 23 23:09:52 2024
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.27
  GitCommit:        a1496014c916f9e62104b33d1bb5bd03b0858e59
 runc:
  Version:          1.1.11
  GitCommit:        v1.1.11-0-g4bccb38
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

And launch weave
weave launch

Versions:

$ weave version
weave script 2.8.1
weave 2.8.1
$ uname -a
Linux fedora 6.6.13-100.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Jan 20 17:28:45 UTC 2024 x86_64 GNU/Linux

Background
In docker version 25.0 they have changed the minimum supported api version from 1.12 to 1.24.
Weave only supports docker has are dependent on docker api 1.18.
Fix for Docker version 25.0
Create file: /etc/systemd/system/docker.service.d/min-api-version.conf
[Service]
Environment="DOCKER_MIN_API_VERSION={{ docker_min_api_version }}"

systemctl daemon-reload
IMPORTANT
Support for API versions lower than 1.24 will be permanently removed in Docker Engine v26, and the minimum supported API version will be incrementally raised in releases following that.
Information sourced from: https://docs.docker.com/engine/deprecated/#deprecate-legacy-api-versions

Fix for Docker version 25.0
Create file: /etc/systemd/system/docker.service.d/min-api-version.conf
[Service]
Environment="DOCKER_MIN_API_VERSION=1.18"

systemctl daemon-reload

After daemon-reload also run systemctl restart docker to apply changes.

Fix for Docker version 25.0
Create file: /etc/systemd/system/docker.service.d/min-api-version.conf
[Service]
Environment="DOCKER_MIN_API_VERSION=1.18"

systemctl daemon-reload

After daemon-reload also run systemctl restart docker to apply changes.

restart of docker isn't necessary. It will sort it out itself but will take longer for it to handle it.

Some great work from @rajch This will resolve weave for docker v26.0
https://github.com/weaveworks/weave/pull/3996/commits/e50040883fe92e224a2b1c4cc2b88cfa37bef12e

There is an active pull requests that has been worked ongoing since August 2023. But unsure if it will ever be merged.
Link to pull requests: https://github.com/weaveworks/weave/pull/3996
If you can't wait for it then you can switch to the releases that is done by the same person as doing the pull requests. https://github.com/rajch/weave/releases/tag/v2.8.4


Clarifications on api-name, filenames and servers object

What type of PR is this?

correction

What this PR does / why we need it:
Missing guideline for file names of API definition files, indirect definition of api-name variable.
This PR adds the definition of api-name to Common Vocabulary and Acronyms and clarifies the name of API definition files and servers object content
Which issue(s) this PR fixes:

Fixes #298 #284
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Special notes for reviewers:
Do we need similar definition of 'api-version'?
JSON format is not currently used in any subproject, should the file extension .json be removed?
Changelog input
 Clarifications on api-name, filenames and servers object

Additional documentation

Closing due to problem with EasyCLA - fixed in the PR #333


Workflows -"Delay submissions" is auto-enabled after upgrading workspace and then auto-disabled

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 9.0.75-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers<EMAIL_ADDRESS>**Issue reported by:**Applause - Internal Team
**Component ** Workspace Settings
Action Performed:

Go to staging.new.expensify.com
Create a workspace
Go to workspace settings > More features
Enable Workflows
Go to Workflows
Enable Add approvals
Click Add approval workflow
Click Upgrade
Note that "Delay submissions" toggle is enabled
Close the upgrade successful RHP

Expected Result:
"Delay submissions" toggle should not change when upgrading workspace to Control and closing upgrade successful RHP
Actual Result:
"Delay submissions" toggle is enabled after upgrading workspace to Control, and disabled after closing upgrade successful RHP
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Standalone
[x] Android: HybridApp
[x] Android: mWeb Chrome
[x] iOS: Standalone
[x] iOS: HybridApp
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/user-attachments/assets/21a04164-a5d0-4a21-b25e-dd43d527f90e
View all open jobs on GitHub

Proposal
Please re-state the problem that we are trying to solve in this issue.
Workflows -"Delay submissions" is auto-enabled after upgrading workspace and then auto-disabled
What is the root cause of that problem?
We always turn on the toggle when the autoReportingFrequency is not instant
https://github.com/Expensify/App/blob/50c1db81004285968c6388bc941860f554d411e6/src/pages/workspace/workflows/WorkspaceWorkflowsPage.tsx#L156
and in this case we are setting it to immediate optimistically on upgrade to corporate
https://github.com/Expensify/App/blob/50c1db81004285968c6388bc941860f554d411e6/src/libs/actions/Policy/Policy.ts#L3386
What changes do you think we should make in order to solve the problem?

We should set it to instant as the BE sets it

                    autoReportingFrequency: CONST.POLICY.AUTO_REPORTING_FREQUENCIES.INSTANT,

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?
What alternative solutions did you explore? (Optional)
we can even leave setting it as I can see that it is set to instant by default

Proposal
Please re-state the problem that we are trying to solve in this issue.
Workflows -"Delay submissions" is auto-enabled after upgrading workspace and then auto-disabled
What is the root cause of that problem?
We always turn on the toggle when the autoReportingFrequency is not instant
https://github.com/Expensify/App/blob/50c1db81004285968c6388bc941860f554d411e6/src/pages/workspace/workflows/WorkspaceWorkflowsPage.tsx#L156
and in this case we are setting it to immediate optimistically on upgrade to corporate
https://github.com/Expensify/App/blob/50c1db81004285968c6388bc941860f554d411e6/src/libs/actions/Policy/Policy.ts#L3386
What changes do you think we should make in order to solve the problem?

We should set it to instant as the BE sets it

                    autoReportingFrequency: CONST.POLICY.AUTO_REPORTING_FREQUENCIES.INSTANT,

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?
What alternative solutions did you explore? (Optional)
we can even leave setting it as I can see that it is set to instant by default

Proposal
Please re-state the problem that we are trying to solve in this issue.
"Delay submissions" is auto-enabled after upgrading workspace and then auto-disabled
What is the root cause of that problem?
When we upgradeToCorporate, we check if the policy is instant submit enabled. If yes, we automatically update autoReportingFrequency to CONST.POLICY.AUTO_REPORTING_FREQUENCIES.IMMEDIATE and enable autoReporting. As a result, the button delay submission is enabled.
https://github.com/Expensify/App/blob/815b4ede21991d6a29f84123774a0f1ad85de4ab/src/libs/actions/Policy/Policy.ts#L3401-L3407
https://github.com/Expensify/App/blob/d03d4b4fdf5955fc60430bff715e7faa41bef3f5/src/pages/workspace/workflows/WorkspaceWorkflowsPage.tsx#L155
After that, when we click Got it, thanks, it triggers the OpenPolicyWorkflowsPage call. The API responds with autoReportingFrequency set to instant. For this reason, the button delay submission is disabled.
https://github.com/user-attachments/assets/edc6bd87-eb51-4607-b8d3-81b8838d4288
The reason is that we set autoReportingFrequency to CONST.POLICY.AUTO_REPORTING_FREQUENCIES.IMMEDIATE in upgradeToCorporate, but the backend did not update the database. As a result, OpenPolicyWorkflowsPage still responds with the old value, causing this issue to occur.
What changes do you think we should make in order to solve the problem?

To resolve this issue, we should use SET_WORKSPACE_AUTO_REPORTING_FREQUENCY to set autoReportingFrequency to CONST.POLICY.AUTO_REPORTING_FREQUENCIES.IMMEDIATE, something like this:
We removed that logic from the optimisticData.
https://github.com/Expensify/App/blob/815b4ede21991d6a29f84123774a0f1ad85de4ab/src/libs/actions/Policy/Policy.ts#L3401-L3407
And when we upgradeToCorporate, we check if the policy is instant submit enabled, then call setWorkspaceAutoReportingFrequency with the frequency set to CONST.POLICY.AUTO_REPORTING_FREQUENCIES.MANUAL
https://github.com/Expensify/App/blob/8bbeaef850151446e00acc49ca316831dd9627a1/src/pages/workspace/upgrade/WorkspaceUpgradePage.tsx#L92-L98
to
    const upgradeToCorporate = () => {
        if (!canPerformUpgrade) {
            return;
        }

        if (PolicyUtils.isInstantSubmitEnabled(policy)) {
            Policy.setWorkspaceAutoReportingFrequency(policy.id, CONST.POLICY.AUTO_REPORTING_FREQUENCIES.MANUAL);
        }

        Policy.upgradeToCorporate(policy.id, feature?.name);
    };

POC
https://github.com/user-attachments/assets/2d3bd539-7e12-4729-bfb7-04ff26697fbf

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Scenario 1: If canPerformUpgrade is false, ensure no actions are performed.
Scenario 2: If isInstantSubmitEnabled(policy) returns true, verify setWorkspaceAutoReportingFrequency is called with CONST.POLICY.AUTO_REPORTING_FREQUENCIES.MANUAL.
Scenario 3: If isInstantSubmitEnabled(policy) returns false, ensure setWorkspaceAutoReportingFrequency is not called.
Scenario 4: If feature is undefined, check that Policy.upgradeToCorporate is called with undefined for the feature name.
Scenario 5: If canPerformUpgrade is true and isInstantSubmitEnabled(policy) returns true, ensure both setWorkspaceAutoReportingFrequency and upgradeToCorporate are called.

What alternative solutions did you explore? (Optional)
Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

Was able to recreate, so going to get eyes on this!

@fedirjh we have a few proposals above for you to review — thanks!

Hey @fedirjh! Just a heads up that we do have some proposals above for review!
Also, I will be OOO starting this afternoon (December 20th) and will be returning January 6th. A handful of folks on the BZ team will be online for a few days in between the 25th and the 1st, but we'll be operating with a skeleton crew. If any action is needed from a BZ perspective, please post this issue in #expensify-open-source and someone on the team will jump in. Otherwise, I will review when I am back in office.
Thank you and Happy Holidays!

@fedirjh Can you take a look at my proposal? When we upgrade advanced approval, we must update autoReporting and autoReportingFrequency according to the previous logic. If we remove this, I believe it will impact the current logic of advanced approval. Currently, when upgrading advanced approval, Delay submissions is turned on and autoReportingFrequency is set to immediate.

yes @fedirjh . thank you!


koordlet: fix can not collect psi metrics

Ⅰ. Describe what this PR does
koordlet can not collect psi metrics.

Ⅱ. Does this pull request fix one issue?

Ⅲ. Describe how to verify it

kernel with psi feature on

sudo grubby --update-kernel="/boot/vmlinuz-4.19.91-24.8.an8.x86_64" --args="psi=1 psi_v1=1"

update-kernel need to be replaced with the actual kernel version

open koordlet's feature for collecting psi metrics.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: koordlet
spec:
  template:
    spec:
      containers:
        - name: koordlet
          image: registry.cn-beijing.aliyuncs.com/koordinator-sh/koordlet:v1.2.0
          command:
            - /koordlet
          args:
            - '-cgroup-root-dir=/host-cgroup/'
            - >-
              -feature-gates=BECPUEvict=true,BEMemoryEvict=true,CgroupReconcile=true,Accelerators=true,CPICollector=true,PSICollector=true
            - '-runtime-hooks-host-endpoint=/var/run/koordlet/koordlet.sock'
            - '--logtostderr=true'
            - '--v=4'

then we can see
3.1. Access to koordlet's metrics api, but didn't get any info about psi
3.2. check koordlet's log:

It seems to be saying that there are no pressure related files under cpuacct cgroup
3.3. looking at the cgroup, we can see that psi-related files exist

then there may be a problem with koordlet handling
The essential cause of the problem：
In golang, global variables are initialized before normal functions, so even though there is logic in the koordlet that modifies CgroupPathFormatter, the initialization of global variables only happens once and before the modification, so the logic in SupportedIfFileExistsInKubepods will use cgroupPathFormatterInSystemd, then the file related to psi can not be find, then making koordlet decide not support psi.

Ⅳ. Special notes for reviews
V. Checklist

[ ] I have written necessary docs and comments
[ ] I have added necessary unit tests and integration tests
[ ] All checks passed in make test

/lgtm

/lgtm
@lucming Please remember to mark the conversation as resolved.

/approve


Handle invalid responses from API

If the API returns a non-200 status with some HTML, then it parses as XML but the resp is unuseable and there is no error so our service is panicking. I added a check for non-200 and a response that contains no status (invalid XML). I also added tests to cover all of these cases.

Looks good to me.