text:
2.1.0

focused performance of library for build and runtime

~support macOS from 10.15 (#153)~
remove tutorial (#158)
rename ViewLayout.coordinators to ViewLayout.attachments and improve implementation of UIView.sublayout
apply SL suffix to Layoutable (#159)
test/enchance anchors (#161)
add options to SwiftLayoutPrinter (#162)
revert appkit supporting
update github action
test/performance (#165)
add native api view test (#167)
add run-performance.sh
update run-performance for sorting
update run-performance for sorting
using build in run-performance.sh
update run-performance
update run-performance for test result filtering
Feature/layout debug print (#169)
comment snapshot test
update test sample
comment test from run-performance.sh
update run-performance.sh
update performance
run-performance testing only performancetests
update performance - NSLayoutConstraint+Description.shortDescription
update performance - AnchorsBuilder.build[Block|Array]
update performance - typecheck 50ms
update typecheck script
update performance - NSLayoutConstraint+Description type-check
update performance - function body type-check 100ms
update performance - typecheck Anchors 50ms
update performance - some function body type-check 50ms
cores move to Anchors
convenience move to Anchors
relation move to Anchors
models move to Anchors
layoutguide move to Anchors
update performance test
Activator.layoutIfNeeded run time performance improvement
performance test accuracy up
remove Anchors+LayoutGuide.swift
remove constraint sorting from Anchors
update constraint sorting from Anchors
update how to store sublayout and anchors in ViewLayout
update build performance of ViewLayout.sublayout(_:)
remove script
Removed optional in LayoutExplorer.Component.anchors
remove ViewInformationSet
Revert "remove ViewInformationSet"
Remove unnecessary type validation
add swift ui sample
remove swift ui sample, update tests
add archive.sh
add xcframework
support xcframework
update github action command
add SwiftLayoutWithoutAssistantsView
add SwiftLayoutWithoutIdentifyingView
remove ViewInfomationSet
update archive for xcframework
LayoutElements - create viewDic from components
update xcframework
fix archive process (#170)
remove performance test
remove xcframework things
Revert "feature/remove xcframework"
Revert "Revert "feature/remove xcframework"" (#174)
remove performance test resources
add README_ko.md (#175)

Thank you for your effort.
Let's go to 2.1.0

Thank you for your effort too.
lets go lets go

repo: ioskrew/SwiftLayout


text:
M1 Capability

Issue description
Currently the repository dependencies like electron (arm based) won't work if you're using a Mac with a m1 processor. I would love to fix all the dependencies errors so that the Desktop / iOs will build successfully.
Wallet version
Which version of wallet are you using?

develop branch

System specification
Macbook Air - macOs Big Sur v11.3.1 - Apple M1 Chip
Is it a repeatable issue?
Y
Steps To reproduce the issue
Just try to setup the repository using an M1 Device.
yarn
Expected behaviour
Install all dependencies and setup the project.
Actual behaviour
Dependencie errors...
Errors
[4/4] 🔨  Building fresh packages... [1/2] ⡀ wallet-nodejs-binding error /Users/ingokopp/Documents/Workspace/firefly/node_modules/electron: Command failed. Exit code: 1 Command: node install.js Arguments:  Directory: /Users/ingokopp/Documents/Workspace/firefly/node_modules/electron Output: HTTPError: Response code 404 (Not Found) for https://github.com/electron/electron/releases/download/v9.4.4/electron-v9.4.4-darwin-arm64.zip     at EventEmitter.<anonymous> (/Users/ingokopp/Documents/Workspace/firefly/node_modules/got/source/as-stream.js:35:24)     at EventEmitter.emit (events.js:376:20)     at module.exports (/Users/ingokopp/Documents/Workspace/firefly/node_modules/got/source/get-response.js:22:10)     at ClientRequest.handleResponse (/Users/ingokopp/Documents/Workspace/firefly/node_modules/got/source/request-as-event-emitter.js:155:5)     at Object.onceWrapper (events.js:483:26)     at ClientRequest.emit (events.js:388:22)     at ClientRequest.origin.emit (/Users/ingokopp/Documents/Workspace/firefly/node_modules/@szmarczak/http-timer/source/index.js:37:11)     at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:647:27)     at HTTPParser.parserOnHeadersComplete (_http_common.js:126:17)     at TLSSocket.socketOnData (_http_client.js:515:22)

I've created a branch to fix this issue.
It's ok if you think this fix is unnecessary.  I just want to make it work for me so i can contribute more stuff :)

+1

Closing issue due to inactivity, please upgrade to the latest app version and reopen the issue if the problem persists 🌷

source: gharchive/issue

authors: PatrickHuetter begonaalvarezd ingokpp

repo: iotaledger/firefly

license_type: permissive

license_source: github-api


text:
[Task]: Create Block Signing Popup

Task description
Requires https://github.com/iotaledger/iota-sdk/issues/2054
We should display a block signing popup, but we require a new event

Requires https://github.com/iotaledger/iota-sdk/pull/2100


text:
Reorganize Utils functions

Description
Move util functions to concrete types
const nftAddress: Address = new NftAddress(Utils.nftIdToBech32(nftId, networkName));

Consider making the nftIdToBech32 function internal to NftAddress, e.g.:
const nftAddress: Address = NftAddress.fromNftId(nftId, networkName));

The same applies to

Utils.aliasIdToBech32.
Utils.computeTokenId. It already returns a TokenId so is just a constructor for TokenId without living on the type itself.
Utils.computeOutputId

Conversion function from Output ID to UTXOInput
Add a constructor for UTXOInput that has the functionality of TransactionHelper.inputFromOutputId from iota.js.
Move top-level functions to Utils namespace
The utf8ToBytes, utf8ToHex and hexToUtf8 functions are directly in the top-level namespace of the sdk. Consider moving thos "util" functions to the Utils namespace.
Nits

Utils.computeNftId returns a string instead of the type alias NftId.

Motivation
The address util functions take a string and return one and it's not immediately obvious what that string represents, especially for new users, I imagine. So having them directly on the stronger-typed classes like AliasAddress seems both clearer and more convenient.
Constructors should live on the classes that they construct rather than in Utils. A user checking the API docs for how to construct a certain type would check that type's docs and rarely consider that a constructor is in Utils.
The constructor new UTXOInput requires a transaction ID and output index, but it's not easily possible to extract those from some outputID, because that is just a string. There should be a convenient way to convert.
Are you planning to do it yourself in a pull request?
No.

const nftAddress: Address = new NftAddress(Utils.nftIdToBech32(nftId, networkName));

NFTAddress  takes an NFTId which is hex encoded string, there's no need to convert it to Bech32. Same for other address classes.

Utils.computeTokenId. It already returns a TokenId so is just a constructor for TokenId without living on the type itself

TokenId is a type alias for string, it doesn't have a constructor.

Add a constructor for UTXOInput that has the functionality of TransactionHelper.inputFromOutputId from iota.js.

Will be added.

The utf8ToBytes, utf8ToHex and hexToUtf8 functions are directly in the top-level namespace of the sdk. Consider moving thos "util" functions to the Utils namespace

Everything is top level right now, since there isn't many util functions, keeping everything top level can be beneficial to avoid breaking changes if directory structure changes.

Utils.computeNftId returns a string instead of the type alias NftId

Will be corrected.

NFTAddress takes an NFTId which is hex encoded string, there's no need to convert it to Bech32. Same for other address classes.

True. Not high priorty, and can be changed non-breakingly, but the parameter name of the constructor of AliasAddress and NftAddress should take aliasId: AliasId and nftId: NftId respectively, not address as it currently does. That's where my confusion that the constructor needed a bech32 address initially came from.

authors: PhilippGackstatter abdulmth

repo: iotaledger/iota-sdk


text:
Move boxes from Payload to higher types

Description of change
This moves the Boxed variants from the Payload type to the higher types OptionalPayload and RegularTransactionEssence. The result is a slightly cleaner implementation.
Type of change
Choose a type of change, and delete any options that are not relevant.

Breaking change (fix or feature that would cause existing functionality to not work as expected)

In hindsight, the boxes are important to ensure that the variants are equally sized.

source: gharchive/pull-request


text:
iotexscan displays incorrect result if being called on a proxy-ed contract

https://iotexscan.io/address/0x2c914Ba874D94090Ba0E6F56790bb8Eb6D4C7e5f?format=0x#readAsProxy
It display false:

But in brownie , it displays: True

hi @fulirockx i found this contract has only the deploy transaction one without initilize or something  else.
could you please check the contract address is correct?

It's correct

UniIOTX: 0x236f8c0a61dA474dB21B693fB2ea7AAB0c803894
IOTXClear: 0x7AD800771743F4e29f55235A55895273035FB546
IOTXStaking: 0x2c914Ba874D94090Ba0E6F56790bb8Eb6D4C7e5f

authors: fulirockx uu-z

repo: iotexproject/product-changelog

license: MIT


text:
🛑 备用KMS激活服务器 01 is down

In 9ecf324, 备用KMS激活服务器 01 (s11.ikms.eu.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: 备用KMS激活服务器 01 is back up in 7236789 after 9 minutes.

repo: iougemini/ikms-uptime


text:
fix build failed on aarch64

since linux has drop __NR_open on aarch64, we will get build
failed on aarch64 without __NR_open defined.
Signed-off-by: Chunmei Xu xuchunmei@linux.alibaba.com

Checklist

[ ] Language changes are updated in docs/reference_guide.md
[ ] User-visible and non-trivial changes updated in CHANGELOG.md
[ ] The new behaviour is covered by tests

Looks good to me. Can you fix the clang format, though?

Looks good to me. Can you fix the clang format, though?

Done.

Thanks :)

authors: danobi fbs xuchunmei000

repo: iovisor/bpftrace

license_source: bigquery


text:
files area is half way usablre with  a screen reader

Describe the bug
A clear and concise description of what the bug is.
I'm visually impaired, so need to access the destkop app with  a screenreader called voiceover  in the case of mac os. You will need to hit command plus f5 to access voiceover from anywhere.
To Reproduce
Steps to reproduce the behavior:

launch voiceover
launch the ipfs app
click the status menu, or what they I think call the extras menu, the thign where all the icons for dropbox and yoru time are.
click files
try and use voiceover only to access the files area. . do not use a moniter.
Expected behavior
A clear and concise description of what you expected to happen.
I should be able to navigate all controls using the curser and arrow keys.
Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

mac os 10.15  ips Revision 1b58b62
Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.
If you need a demo  of how voiceover works, please let me know.

Thanks for reporting @marrie! @rafaelramalho19 and @jessicaschilling will look at this, but Monday is a holiday in US so possibly not until Tues.

Lol. Take your time. I'm in the US but I work on Monday, If you have any
questions, please ask. I also found out that I cannot delete files. I
can arrow up and down kind of and see the selected status, but the
buttons for rename and delete get skipped over if I tab and if I curser
over them with control open left and right, I can get to them but
pressing control, option, space does not a thing.
Thanks, and hope all of this can be looked into.

@rafaelramalho19 — can you please take a look at this when you are back! I’m afraid that this is outside my area of expertise. Thank you!

Yes, I love fixing accessibility issues 😄
Thanks for reporting this @marrie, I will look at this soon.

@marrie Thank you once again for reporting this.
I've gone ahead and created a pull request to fix this. I would very much appreciate your input in this if that's possible!

I can't code.  What would you like me to test? Or how would you like me
to go about this. I'll do my 100 percent best. I have some blind friends
on windows. Would you like me to try and link them to you guys for
testing purposes?

@marrie this should be in the next release of ipfs-desktop, so if you could wait for that and then provide feedback to us, it would be awesome!
You're always welcome to open issues with problems you may encounter with ipfs-desktop and webui, as it's really valuable for us the input of someone who uses screen readers daily.
If you're really eager to test this out, we can also create a demo instance of webui with these changes 😄

Thanks. I'm not new to testing, but I cannot compile either. I'll let my
VI people know on my discord what's up and hopefully you should get some
to test, maybe some to code if they know what they are doing.
Thanks again.

That's awesome! Thank you so much @marrie!

authors: autonome jessicaschilling marrie rafaelramalho19

repo: ipfs-shipyard/ipfs-webui


text:
readme: added missing API links

even when linking to a 404 octocat, still better than the current empty links resolving to https://github.com/ipfs/js-ipfs-api/blob/master

you're welcome :)

repo: ipfs/js-ipfs-api

license: mit


text:
🛑 Invitation (og.invt.co - v1) is down

In 1d62bdd, Invitation (og.invt.co - v1) (https://og.invt.co/felix.png?fontSize=%40felix&theme=light&md=1&images=https%3A%2F%2Flh3.googleusercontent.com%2Fa-%2FAOh14GjUk2VKmkWxpgWZgY0CXWRFi_k6t7f2MBSsfSxR%3Ds96-c) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Invitation (og.invt.co - v1) is back up in 66c2927.

repo: iplanwebsites/up


text:
[Release] Deploy 0.2.0

Deploy
Deploy 🛠
Related PRs

#281

Before submitting

[!Warning]
The following is allowed for review only. (No additions or modifications are permitted.)

[x] I have read the Contribution Guidelines.
[x] I agree to the Code of Conduct.

Delete main branch due to broken git tree.
Create an empty main branch, then merge PR#281.

git checkout --orphan main
git push origin

Delete main branch due to broken git tree.
Create an empty main branch, then merge PR #281.

git checkout --orphan main
git commit --allow-empty -m "init"
git merge origin/develop --allow-unrelated-histories --squash -m "[Release] Deploy 0.2.0"

Note
Merged at c5c6043

This did not allow PR of the develop branch to main, so after deleting the main branch, the following was performed:

git checkout --orphan main
git rm -r --cached .
git clean -fxd
git commit --allow-empty -m "init (#282 related)"
git merge --allow-unrelated-histories develop
git push origin

Deploy at 5a79a07945dd567692005f6b8023a44f93b4aa84

repo: iputapp/lounas


text:
Testtakers-Dateien mit zwei Monitoren können zu Endlosschleife führen

... wenn den Monitoren fälschlicher weise Booklets zugeordnet waren

gefixed: https://github.com/iqb-berlin/testcenter/commit/42279281ba00484ead956ace1ee756eda89ed222

repo: iqb-berlin/testcenter


text:
Update README.md

Ran Grammarly on the contents.

How could you accuse me for bad grammar? \j

I want to squash this.

@RechieKho can you approve of the pr?

authors: RechieKho fire


text:
RFC: TopK perf improvements

Request description
This is a RFC proposal for speeding up the current TopK implementation.
Problem that this proposal addresses
In one LLM model we see the TopK function taking fairly long time in the overall execution time - about 7%.
The function is used on inputs of 4x8000xf32 and 1x256128xf32 with outputs of 4x40xf32 and 4x40xi32 and 1x40xf32 and 1x40xi32, respectively.
After analysis of the current implementation, we discovered that the current implementation is sorting every element in the output, which is suboptimal.
Proposal
Generate a function that avoids attempting to sort every input element. The function should scale (yield better perf) with smaller ratio of size of outputs/size of inputs.
If we maintain the smallest element added to the output and the number of elements added, the elements smaller than the smallest element added to the output, should not be considered for insertion (sorting) in the output.
Further, the reading and comparison of the input elements to the smallest added element can be done using vector registers (one with the input and one with the broadcasted smallest element). The use of a vector registers saves up to 30 cycles per every 16 elements (assuming a vector register contains 16 input elements).
To proper tiling of the output, the DispatchLoweringPassPipeline::CPULinalgExtTileAndVectorize tiling pipeline, which tiles the input vector on the size of elements in the input (1x16xf32). Note: In the initial implementation if the input size is not multiple of the number of elements in the vector register, the current implementation will be delegated to. This will be fixed in subsequent revisions of the code.
The implementation is a hybrid implementation where the reading and comparison is done using vectors and the insertion/sorting of the output is done using scalars.
Further, an extra optimization can be achieved if we keep the number of added elements in the output. In case, the output is not filled completely yet and the element being considered is smaller than the smallest element added to the output, there is no need to shift the output elements in order to sort and the new element can be added at the very end of the output and the output will still be sorted.
Prototype implementation
There is currently a prototype/initial implementation of this algorithm that yields the following performance improvements:
The algorithm described above results in significant speedup of the function. The speedup scales with the reduction of the ratio of output/input sizes.
This implementation seems to be about 10% faster even on smaller data sets where the output/input ratio is 1 (see below that benchmark for input 1x32->1x32, which is basically using TopK for sorting).
For bigger datasets we observe even bigger speedups:
For 2x1024 -> 2x40 the speedup is 9.59x
For 1x256128 -> 1x40 the speedup is 6.12x.
Benchmark numbers - each benchmark was ran 10 times.
2x1024 -> 2x40
Using the new algorithm with vector registers
BM_custom_call_topk_tuple_16/process_time/real_time_mean 0.075 ms 0.103 ms 10 items_per_second=13.2933k/s
BM_custom_call_topk_tuple_16/process_time/real_time_median 0.075 ms 0.102 ms 10 items_per_second=13.3588k/s
Current scalar implementation
BM_custom_call_topk_tuple_16/process_time/real_time_mean 0.719 ms 1.32 ms 10 items_per_second=1.39137k/s
BM_custom_call_topk_tuple_16/process_time/real_time_median 0.718 ms 1.32 ms 10 items_per_second=1.39307k/s
1x32 -> 1x32
Using the new algorithm with vector registers
BM_custom_call_topk_tuple_16/process_time/real_time_mean 0.042 ms 0.046 ms 10 items_per_second=23.9746k/s
BM_custom_call_topk_tuple_16/process_time/real_time_median 0.042 ms 0.046 ms 10 items_per_second=23.9371k/s
Current scalar implementation
BM_custom_call_topk_tuple_16/process_time/real_time_mean 0.051 ms 0.055 ms 10 items_per_second=19.5375k/s
BM_custom_call_topk_tuple_16/process_time/real_time_median 0.051 ms 0.055 ms 10 items_per_second=19.6053k/s
1x256128 ->1x40
Using the new algorithm with vector registers
BM_custom_call_topk_tuple_16/process_time/real_time_mean 3.79 ms 3.67 ms 10 items_per_second=264.076/s
BM_custom_call_topk_tuple_16/process_time/real_time_median 3.78 ms 3.67 ms 10 items_per_second=264.459/s
Current scalar implementation
BM_custom_call_topk_tuple_16/process_time/real_time_mean 23.3 ms 23.2 ms 10 items_per_second=42.9361/s
BM_custom_call_topk_tuple_16/process_time/real_time_median 23.2 ms 23.1 ms 10 items_per_second=43.0286/s
Implementation notes
The implementation is done in a pure codegen approach.
There have been some bugs and limitations in the base libraries and dialects discovered in the process, for which there were some workarounds.
Some of them are:

Inability to break out of a scf::For (that required to have extra iter_args to be added, so the loop continues to the end with no modification of returns - this is used in the initialization of the smallest element added and the loop for calculating the insertion position in the output of the inserted element)
Not having support for negative steps in sfc::For (in the shifting elements loop before insertion extra itrer_args were added of the element to be shifted to the next element, thus achieving the same result as negative step loop and alleviating the need for temp var assignments).

Here is the code before and after the code transformation:
Before
func.func @custom_call_topk_tuple_f10_dispatch_0_topk_1x32xf32() attributes {translation_info = #iree_codegen.translation_info<CPULinalgExtTileAndVectorize>} {
  %c16 = arith.constant 16 : index
  %c32 = arith.constant 32 : index
  %c0 = arith.constant 0 : index
  %c128 = arith.constant 128 : index
  %0 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%c0) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<1x32xf32>>
  %1 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%c0) : !flow.dispatch.tensor<readwrite:tensor<1x32xf32>>
  %2 = hal.interface.binding.subspan set(0) binding(2) type(storage_buffer) alignment(64) offset(%c128) : !flow.dispatch.tensor<readwrite:tensor<1x32xi32>>
  %3 = flow.dispatch.tensor.load %0, offsets = [0, 0], sizes = [1, 32], strides = [1, 1] : !flow.dispatch.tensor<readonly:tensor<1x32xf32>> -> tensor<1x32xf32>
  %4 = flow.dispatch.tensor.load %1, offsets = [0, 0], sizes = [1, 32], strides = [1, 1] : !flow.dispatch.tensor<readwrite:tensor<1x32xf32>> -> tensor<1x32xf32>
  %5 = flow.dispatch.tensor.load %2, offsets = [0, 0], sizes = [1, 32], strides = [1, 1] : !flow.dispatch.tensor<readwrite:tensor<1x32xi32>> -> tensor<1x32xi32>
  %6:2 = scf.for %arg0 = %c0 to %c32 step %c16 iter_args(%arg1 = %4, %arg2 = %5) -> (tensor<1x32xf32>, tensor<1x32xi32>) {
    %extracted_slice = tensor.extract_slice %3[0, %arg0] [1, 16] [1, 1] : tensor<1x32xf32> to tensor<1x16xf32>
    %extracted_slice_0 = tensor.extract_slice %arg1[0, %arg0] [1, 32] [1, 1] : tensor<1x32xf32> to tensor<1x32xf32>
    %extracted_slice_1 = tensor.extract_slice %arg2[0, %arg0] [1, 32] [1, 1] : tensor<1x32xi32> to tensor<1x32xi32>
    %7:2 = iree_linalg_ext.topk {lowering_config = #iree_codegen.lowering_config<tile_sizes = [[1, 0], [0, 16]]>} dimension(1) ins(%extracted_slice : tensor<1x16xf32>) outs(%extracted_slice_0, %extracted_slice_1 : tensor<1x32xf32>, tensor<1x32xi32>) {
    ^bb0(%arg3: f32, %arg4: f32):
      %8 = arith.cmpf ogt, %arg3, %arg4 : f32
      iree_linalg_ext.yield %8 : i1
    } -> tensor<1x32xf32>, tensor<1x32xi32>
    %inserted_slice = tensor.insert_slice %7#0 into %arg1[0, %arg0] [1, 32] [1, 1] : tensor<1x32xf32> into tensor<1x32xf32>
    %inserted_slice_2 = tensor.insert_slice %7#1 into %arg2[0, %arg0] [1, 32] [1, 1] : tensor<1x32xi32> into tensor<1x32xi32>
    scf.yield %inserted_slice, %inserted_slice_2 : tensor<1x32xf32>, tensor<1x32xi32>
  }
  flow.dispatch.tensor.store %6#0, %1, offsets = [0, 0], sizes = [1, 32], strides = [1, 1] : tensor<1x32xf32> -> !flow.dispatch.tensor<readwrite:tensor<1x32xf32>>
  flow.dispatch.tensor.store %6#1, %2, offsets = [0, 0], sizes = [1, 32], strides = [1, 1] : tensor<1x32xi32> -> !flow.dispatch.tensor<readwrite:tensor<1x32xi32>>
  return
}

Codegen with comments, using the algorithm proposed above
func.func @custom_call_topk_tuple_f10_dispatch_0_topk_1x32xf32() attributes {translation_info = #iree_codegen.translation_info<CPULinalgExtTileAndVectorize>} {
  %c16 = arith.constant 16 : index
  %c32 = arith.constant 32 : index
  %c0 = arith.constant 0 : index
  %c128 = arith.constant 128 : index
  %0 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%c0) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<1x32xf32>>
  %1 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%c0) : !flow.dispatch.tensor<readwrite:tensor<1x32xf32>>
  %2 = hal.interface.binding.subspan set(0) binding(2) type(storage_buffer) alignment(64) offset(%c128) : !flow.dispatch.tensor<readwrite:tensor<1x32xi32>>
  %3 = flow.dispatch.tensor.load %0, offsets = [0, 0], sizes = [1, 32], strides = [1, 1] : !flow.dispatch.tensor<readonly:tensor<1x32xf32>> -> tensor<1x32xf32>
  %4 = flow.dispatch.tensor.load %1, offsets = [0, 0], sizes = [1, 32], strides = [1, 1] : !flow.dispatch.tensor<readwrite:tensor<1x32xf32>> -> tensor<1x32xf32>
  %5 = flow.dispatch.tensor.load %2, offsets = [0, 0], sizes = [1, 32], strides = [1, 1] : !flow.dispatch.tensor<readwrite:tensor<1x32xi32>> -> tensor<1x32xi32>
// Most of the scf structs (for and if) have the same iter_args/returns output0,
// output1, smallestElem and elemsAdded
// Note: the top loop has an extra arg just before the smallestElem of type i1 denoting if // the amallestElem has been initialized.
// Add extra iter_args for initSmallest, smallestElem and addedElems
  %true = arith.constant true
  %cst = arith.constant 0.000000e+00 : f32
  %c0_0 = arith.constant 0 : index
  %6:5 = scf.for %arg0 = %c0 to %c32 step %c16 iter_args(%arg1 = %4, %arg2 = %5, %arg3 = %true, %arg4 = %cst, %arg5 = %c0_0) -> (tensor<1x32xf32>, tensor<1x32xi32>, i1, f32, index) {
    %extracted_slice = tensor.extract_slice %3[0, %arg0] [1, 16] [1, 1] : tensor<1x32xf32> to tensor<1x16xf32>
    %extracted_slice_1 = tensor.extract_slice %arg1[0, %arg0] [1, 32] [1, 1] : tensor<1x32xf32> to tensor<1x32xf32>
    %extracted_slice_2 = tensor.extract_slice %arg2[0, %arg0] [1, 32] [1, 1] : tensor<1x32xi32> to tensor<1x32xi32>
// Initialize the smallest element to the first element in the input, if not initialized.
    %7:4 = scf.if %arg3 -> (tensor<1x32xf32>, tensor<1x32xi32>, f32, index) {
      %c0_8 = arith.constant 0 : index
      %extracted = tensor.extract %extracted_slice[%c0_8, %c0_8] : tensor<1x16xf32>
      %c0_9 = arith.constant 0 : index
      scf.yield %arg1, %arg2, %extracted, %c0_9 : tensor<1x32xf32>, tensor<1x32xi32>, f32, index
    } else {
      scf.yield %arg1, %arg2, %arg4, %arg5 : tensor<1x32xf32>, tensor<1x32xi32>, f32, index
    }
    %cst_3 = arith.constant 0xFF800000 : f32
    %c0_4 = arith.constant 0 : index
    // Read the imput elements in a vector register.
    %8 = vector.transfer_read %extracted_slice[%c0_4, %c0_4], %cst_3 {in_bounds = [true, true]} : tensor<1x16xf32>, vector<1x16xf32>
    // Broadcast smallestElem in another vector register.
    %9 = vector.broadcast %7#2 : f32 to vector<1x16xf32>
    // Check to see if there are elements in teh input that are
    // greater than the smallest element added.
    %10 = arith.cmpf ogt, %8, %9 : vector<1x16xf32>
    %c32_5 = arith.constant 32 : index
    // Check to see if the outyput is fully filled.
    %11 = arith.cmpi slt, %7#3, %c32_5 : index
    // If not, set the mask of the vector registers to 1s,
    // so the ncoming elements will still be added to the output
    // until is fully filled.
    %12 = scf.if %11 -> (vector<1x16xi1>) {
      %true_8 = arith.constant true
      %15 = vector.broadcast %true_8 : i1 to vector<1x16xi1>
      scf.yield %15 : vector<1x16xi1>
    } else {
      scf.yield %10 : vector<1x16xi1>
    }
    %false = arith.constant false
    // Check to see if any input elemets need to be added to the output.
    // Reduce over the mask register with or to seeif there are elements that need
    // to be added
    %13 = vector.multi_reduction <or>, %12, %false [0, 1] : vector<1x16xi1> to i1
    // If to insert elements if there are nay needing insertion.
    %14:4 = scf.if %13 -> (tensor<1x32xf32>, tensor<1x32xi32>, f32, index) {
      %c0_8 = arith.constant 0 : index
      %c1 = arith.constant 1 : index
      // Iterate over the mask elements.
      %15:4 = scf.for %arg6 = %c0_8 to %c16 step %c1 iter_args(%arg7 = %7#0, %arg8 = %7#1, %arg9 = %7#2, %arg10 = %7#3) -> (tensor<1x32xf32>, tensor<1x32xi32>, f32, index) {
        // Get the mask element for each element in the mask register.
	// Need a shape cast because the vector.extractelement operates on vectors
        //  (arrays) only.
	// The vector::extract currently doesn't support unitDim shapes.
        %16 = vector.shape_cast %12 : vector<1x16xi1> to vector<16xi1>
        %17 = vector.extractelement %16[%arg6 : index] : vector<16xi1>
        // If the mask is true, the element needs insertion.
        %18:4 = scf.if %17 -> (tensor<1x32xf32>, tensor<1x32xi32>, f32, index) {
          // Extract the element that needs to be inserted in the output.
          %19 = vector.shape_cast %8 : vector<1x16xf32> to vector<16xf32>
          %20 = vector.extractelement %19[%arg6 : index] : vector<16xf32>
          // Get the index of the input element by adding the induction vars
          // of the two loops - the one iterating over input with step 16 and
          // the one iterating over the ekements in the vector.
          %21 = arith.addi %arg6, %arg0 : index
          // A flag to denote if the insertion index was found.
          %true_9 = arith.constant true
          %c0_10 = arith.constant 0 : index
          %c0_11 = arith.constant 0 : index
          %c1_12 = arith.constant 1 : index
          // Loop to find the insertion index for the element that is being added.
          %22:2 = scf.for %arg11 = %c0_11 to %arg10 step %c1_12 iter_args(%arg12 = %true_9, %arg13 = %c0_10) -> (i1, index) {
            %true_13 = arith.constant true
            %26 = arith.cmpi eq, %arg12, %true_13 : i1
            // If index not found...
            %27:2 = scf.if %26 -> (i1, index) {
              %c0_14 = arith.constant 0 : index
              // ... extract the element from the output and check to see if this
              // is the insertion index of the new element.
              %extracted = tensor.extract %arg7[%c0_14, %arg11] : tensor<1x32xf32>
              %28 = arith.cmpf olt, %extracted, %20 : f32
              %true_15 = arith.constant true
              %29 = arith.cmpi eq, %28, %true_15 : i1
              %30:2 = scf.if %29 -> (i1, index) {
                %c0_16 = arith.constant 0 : index
                %31 = arith.addi %arg11, %c0_16 : index
                %false_17 = arith.constant false
                scf.yield %false_17, %31 : i1, index
              } else {
                // If the index was found, just iterate to the end with the for loop.
                // Note: there is comment in the code for this to be removed when
                // scf::For supports break.
                scf.yield %arg12, %arg13 : i1, index
              }
              scf.yield %30#0, %30#1 : i1, index
            } else {
              // If no insertion needed, just exit.
              scf.yield %arg12, %arg13 : i1, index
            }
            scf.yield %27#0, %27#1 : i1, index
          }

          %23 = arith.cmpi eq, %arg10, %c32_5 : index
          %24 = arith.andi %23, %22#0 : i1
          // Check to see if the element doesn'y need to be added.
          %25:4 = scf.if %24 -> (tensor<1x32xf32>, tensor<1x32xi32>, f32, index) {
            scf.yield %arg7, %arg8, %arg9, %arg10 : tensor<1x32xf32>, tensor<1x32xi32>, f32, index
          } else {
            // Check to see if the element is appended to the end of the output
            // (output not fully filled yet - no insertion index found.
            %26:4 = scf.if %22#0 -> (tensor<1x32xf32>, tensor<1x32xi32>, f32, index) {
              // Insert the elem and its index at the end
              // and increment the number of added elements.
              %c0_13 = arith.constant 0 : index
              %inserted = tensor.insert %20 into %arg7[%c0_13, %arg10] : tensor<1x32xf32>
              %27 = arith.index_cast %21 : index to i32
              %inserted_14 = tensor.insert %27 into %arg8[%c0_13, %arg10] : tensor<1x32xi32>
              %c1_15 = arith.constant 1 : index
              %28 = arith.addi %arg10, %c1_15 : index
              scf.yield %inserted, %inserted_14, %arg9, %28 : tensor<1x32xf32>, tensor<1x32xi32>, f32, index
            } else {
              // The element needs to be inserted
              %27 = arith.cmpi eq, %arg10, %c32_5 : index
              %28 = scf.if %27 -> (index) {
                // If it is inserted at the end, just add it there, pushing
                // the current last element out.
                // Setting the insertion index and num added elems in a way,
                // that the shifting loop below will not execute.
                %c1_19 = arith.constant 1 : index
                %32 = arith.subi %arg10, %c1_19 : index
                scf.yield %32 : index
              } else {
                scf.yield %arg10 : index
              }
              %c1_13 = arith.constant 1 : index
              %c0_14 = arith.constant 0 : index
              // set the values of the elements that need to be shifted right as
              // iter_args.
              %extracted = tensor.extract %arg7[%c0_14, %22#1] : tensor<1x32xf32>
              %extracted_15 = tensor.extract %arg8[%c0_14, %22#1] : tensor<1x32xi32>
              %c1_16 = arith.constant 1 : index
              // Shift the elements from insertionIndex to the end to the right.
              %29:4 = scf.for %arg11 = %22#1 to %28 step %c1_16 iter_args(%arg12 = %arg7, %arg13 = %arg8, %arg14 = %extracted, %arg15 = %extracted_15) -> (tensor<1x32xf32>, tensor<1x32xi32>, f32, i32) {
                %c1_19 = arith.constant 1 : index
                %32 = arith.addi %arg11, %c1_19 : index
                %c0_20 = arith.constant 0 : index
                // Get the next elements and set it as iter args before...
                %extracted_21 = tensor.extract %arg12[%c0_20, %32] : tensor<1x32xf32>
                %extracted_22 = tensor.extract %arg13[%c0_20, %32] : tensor<1x32xi32>
                // ... setting the previous element values (in the iter_args)...
                %inserted_23 = tensor.insert %arg14 into %arg12[%c0_20, %32] : tensor<1x32xf32>
                %inserted_24 = tensor.insert %arg15 into %arg13[%c0_20, %32] : tensor<1x32xi32>
                // Update the iter_args.
                scf.yield %inserted_23, %inserted_24, %extracted_21, %extracted_22 : tensor<1x32xf32>, tensor<1x32xi32>, f32, i32
              }
              // Get the current last element and update the iter_arg of the outmost loop.
              %extracted_17 = tensor.extract %29#0[%c0_14, %28] : tensor<1x32xf32>
              %30 = arith.addi %28, %c1_13 : index
              %inserted = tensor.insert %20 into %29#0[%c0_14, %22#1] : tensor<1x32xf32>
              %31 = arith.index_cast %21 : index to i32
              %inserted_18 = tensor.insert %31 into %29#1[%c0_14, %22#1] : tensor<1x32xi32>
              scf.yield %inserted, %inserted_18, %extracted_17, %30 : tensor<1x32xf32>, tensor<1x32xi32>, f32, index
            }
            scf.yield %26#0, %26#1, %26#2, %26#3 : tensor<1x32xf32>, tensor<1x32xi32>, f32, index
          }
          scf.yield %25#0, %25#1, %25#2, %25#3 : tensor<1x32xf32>, tensor<1x32xi32>, f32, index
        } else {
          scf.yield %arg7, %arg8, %arg9, %arg10 : tensor<1x32xf32>, tensor<1x32xi32>, f32, index
        }
        scf.yield %18#0, %18#1, %18#2, %18#3 : tensor<1x32xf32>, tensor<1x32xi32>, f32, index
      }
      scf.yield %15#0, %15#1, %15#2, %15#3 : tensor<1x32xf32>, tensor<1x32xi32>, f32, index
    } else {
      scf.yield %7#0, %7#1, %7#2, %7#3 : tensor<1x32xf32>, tensor<1x32xi32>, f32, index
    }
    %inserted_slice = tensor.insert_slice %extracted_slice_1 into %arg1[0, %arg0] [1, 32] [1, 1] : tensor<1x32xf32> into tensor<1x32xf32>
    %inserted_slice_6 = tensor.insert_slice %extracted_slice_2 into %arg2[0, %arg0] [1, 32] [1, 1] : tensor<1x32xi32> into tensor<1x32xi32>
    %false_7 = arith.constant false
    scf.yield %14#0, %14#1, %false_7, %14#2, %14#3 : tensor<1x32xf32>, tensor<1x32xi32>, i1, f32, index
  }
  flow.dispatch.tensor.store %6#0, %1, offsets = [0, 0], sizes = [1, 32], strides = [1, 1] : tensor<1x32xf32> -> !flow.dispatch.tensor<readwrite:tensor<1x32xf32>>
  flow.dispatch.tensor.store %6#1, %2, offsets = [0, 0], sizes = [1, 32], strides = [1, 1] : tensor<1x32xi32> -> !flow.dispatch.tensor<readwrite:tensor<1x32xi32>>
  return
}

Feature PR: https://github.com/iree-org/iree/pull/17045

Thanks @LLITCHEV for the RFC. Some comments though a lot of details here are a bit over my head
The lowering looks very much like "hand-crafted IR", i.e. it is not a sequence of composable transformations that get us to the final state. It is for such canned-handcrafted sequence that the Ukernel path was plumbed through. There is one advantage here though. In terms of deployment you dont need to worry about a specific hardware ISA and writing ukernels for each. It is worth doing that for something like GEMM where getting the right hardware ISA is important.
So I suggest an intermediate solution (leveraging what you already have). For the most part we can piggy back along the ukernel path, i.e.

Recognize the op you want to lower to a ukernel, here the top-k op and lower it to the iree_codegen.ukernel.generic operation
Follow the same path as all other microkernels take till it gets lowered to a function call (i.e. bufferization + lower ukernels to func call)

At this stage you will have an empty function which represents the top-k kernel. You can provide the implementation of that function (i.e. fill in the body of the function) as you want it and then just inline the function. Effectively instead of relying on linking at LLVM level to provide the ukernel function definition, you are just building the function body in MLIR and then lowering it to LLVM.
Thoughts? cc @jpienaar as well?

@MaheshRavishankar Thank you so much for the thoughtfull comments! I really appreciate it!
I have had discussed these with Diego and following are some of the highlights of the conversations I have...

First, I implemented this initially as a stand alone function in C and got very similar perf results. I thought the easiest way forward would be to just incorporate the C function as a RTL and just call it.
It was suggested that implementing it as a scf/vector dialect consumer would be more in-line with the overall value of IREE - a crosplatform implementation that would run on any backend that IREE supports. I do agree with that, since this code should run on GPUs and other hardware we support as well, even HW that doesn't have a LLVM backend - like things that are targeted by scf and vector dialects only (not LLVM). (I have not attempeted it yet, but technically it should just work, although I won't be surprized if there are things that need fixing. There were several issues in different dialects that needed fixing, including missing operation conversions for lower dialect, before this codegen actually worked). I suspect there might be need to fix some things on some of the other backends).
This implementation also made sense since all the other "canned" operations are done in similar way in the same file GenericVecrorization.cpp. The "canned" functions that are generated the same way are PadOp, PackOp, UnpackOp, and LinalgOp that are vectorized.
I also have run into some limitation and correctness issues in the current implementations of the TopK function for the different platforms, and scf/vector solution, like this one would hopefully make moot.
Some examples are:
a. The current CPU implementation has no support for int32 types (it resulted in errors when I tried to compile). I had to disable some tests - look in https://github.com/iree-org/iree/blob/50a134a9c38df30b1c6cacb59416f7f671437b3f/tests/e2e/linalg_ext_ops/top-k-vector.mlir. It also doesn't comply with the layout_config, so if another layer of tiling is introduced for the input/output of the operation, the result will be incorrect.
b. The tests are already disabled on Vulkan with a note that the codegen is incorrect.
c. On Cuda, I had to disable my tests because it was producing wrong results. In particular, the file is https://github.com/iree-org/iree/blob/50a134a9c38df30b1c6cacb59416f7f671437b3f/tests/e2e/linalg_ext_ops/top-k-vector.mlir, and the test vector_call_topk_1x256 fails with duplicating elements in the output. (Issue: https://github.com/iree-org/iree/issues/17275)

/work/runtime/src/iree/modules/check/module.cc:372: Failure
Failed
Expected equality of these values. Contents does not match.
 lhs:
   1x40xi32=[135 135 169 169 247 247 233 233 3 3 7 7 11 11 15 15 19 19 23 23 27 27 31 31 35 35 39 39 43 43 47 47 51 51 55 55 59 59 63 63]
 rhs:
   1x40xi32=[135 169 247 233 3 7 11 15 19 23 27 31 35 39 43 47 51 55 59 63 67 71 75 79 83 87 91 95 99 103 107 111 115 119 123 127 131 139 143 147]```

IMHO, having the codegen done using scf/vector and other mlir dialects is beneficial, because it achieves one of the IREE goals of HW heterogeniality.
Any further thoughts really appreciated?

This implementation also made sense since all the other "canned" operations are done in similar way in the same file GenericVecrorization.cpp. The "canned" functions that are generated the same way are PadOp, PackOp, UnpackOp, and LinalgOp that are vectorized.

I might be mistaken here, but the implementation here is not on par with the other ops you mention. Those do not generate a loop, etc. like you have here. The approach with those ops is generally

Use tiling to generate the loops
Lower to a "straight sequence" of operations for vectorization.
For example, after the code you generate here you cannot "unroll the vectors" (or on GPU you cant distribute the vectors). Its pretty much from here just go down to LLVM (for the most part). So thats the phase ordering issue I see here and we can avoid that by just defering to where the code is generated much closer to LLVM lowering.

I also have run into some limitation and correctness issues in the current implementations of the TopK function for the different platforms, and scf/vector solution, like this one would hopefully make moot.

Sorry, I am missing whether the implementation in your RFC is producing wrong results of IREE is producing wrong results at HEAD.

@MaheshRavishankar Thanks for the comments!
First, this turned out longer than I expected. Sorry! We can discuss it more in Mai-Tai...

Sorry, my understanding (and Diego's from what I understood) is that the pass is generating "canned" operations - operations that generally don't fuse and are standalone piece of code. At least it looked that way to me.
For TopK one can't really fuse anything because of the fact that you have "sort-of" loop carry dependency - the order. Not sure if it is the same for (some) of the rest of the operations - thinking about it a bit, pack/unpack, and even pad have the same property, I think. Order of things matter and the code probably is not really amenable to fusing and a lot of other optimizations. It is possible that I'm missing something, though.
For distribution for the TopK inplementation, in thisproposal (and implementation) is done on the rows, because they are independent of each other. So, each row in the input can/is executed on different core/warp. For the existing implementation (at least on CPU) there is no distribution at all. I tried using some (in the same manner as described above) and the execution time doubled - it looked like the constant sorting was blowing up the caches.
Having the codegen done in SCF and vector dialect also supports codegen for targets that have no LLVM backend. It will just work (hopefully, after all the necessary fixes down the pipeline, if some are required). And of course it works for all the targets that do have LLVM backend.

As far as the failures... I did try it fully disabling my code back when I added my new tests (that fail on Cuda). I just retried it to make sure. The failure still happens... https://github.com/iree-org/iree/actions/runs/8942205116/job/24564575269?pr=17045
My code is completely disabled and the failure is on HEAD from yesterday.
And here  is the issue I opened for that - https://github.com/iree-org/iree/issues/17275

To summarize, IMHO, having the implementation in MLIR builders instead of ukernel has the following benefits:
a. It provides support for non-LLVM backend (I don't know how important is this for IREE?) It also provdes out of box
support for new backends (devices). The different backends compilers (in LLVM and not only) are still free to optimize
this code - splitting the lowered higher level scf loops the way they see fit.
For this codegen in ukernel (LLVM), I think I need  intrinsics for vector registers and last time I checked (sometime ago),
they were not unified between backends fully yet (and very small subset. Some of them are still experimental (like cmpf,
for example).
b. Non-C numerical types (sub-byte types). It seems to me that these can be handled better in MLIR builder codegen.
I don't really see how these will look in ukernels? I think we do care about these.
c. Provides unified implementation between the different backends. There is one implementation that works on all the
backends - consistent, correct, and fast.
IMHO, this reduces also maintanance and the code will behave the same on all the backends. This assumes that
all the backends are well optimized to compile fast MLIR code (which, I think they should be?)

As I said before, I haven't realized that this pass is only for "canned" operations that don't generate for loops. and ifs. If that is the case, i can certainly move the codegen for the TopK canned operation in a different pass.
Thanks!

We can discuss more next week in Mai-Tai... I am not disagreeing that its useful having the IR generated from MLIR, but I am saying this is essentially using a builder API to write a microkernel (which is totally OK). Just saying you do that as an "implementation of a function". Instead of the implementation coming from an llvm bit code file or library, you are building the MLIR implementation of it. Happy to take that, but this isnt a general vectorization recipe. I dont follow your comments on pack/pad etc. Those do not vectorize to scf + vector ops. They generate vector ops as straight line code. We can talk more on Mai Tai.

authors: LLITCHEV MaheshRavishankar

repo: iree-org/iree


text:
FormGroup中的DataTemplate似乎显示不了label?

ursa版本1.1.0
usercontrol:
<UserControl.DataTemplates>
    <DataTemplate DataType="{x:Type vm:DialogTextViewModel}">
        <TextBox
            HorizontalAlignment="Stretch"
            u:FormItem.IsRequired="True"
            u:FormItem.Label="123"
            Text="{Binding Text}" />
    </DataTemplate>
    <DataTemplate DataType="{x:Type vm:DialogComboboxViewModel}">
        <ComboBox
            HorizontalAlignment="Stretch"
            u:FormItem.IsRequired="True"
            u:FormItem.Label="456"
            ItemsSource="{Binding Items}"
            SelectedIndex="{Binding SelectedIndex}" />
    </DataTemplate>
</UserControl.DataTemplates>
......
<u:Form
    Grid.Row="1"
    HorizontalAlignment="Center"
    LabelAlignment="Right"
    LabelPosition="Left"
    LabelWidth="*">
    <u:FormGroup Header="Education" ItemsSource="{Binding Controls}" />
    <u:FormGroup Header="Education2">
        <TextBox
            HorizontalAlignment="Stretch"
            u:FormItem.IsRequired="True"
            u:FormItem.Label="Name" />
        <TextBox
            HorizontalAlignment="Stretch"
            u:FormItem.IsRequired="True"
            u:FormItem.Label="Email" />
    </u:FormGroup>
</u:Form>

vm:
Controls.Add(new DialogTextViewModel { Text = "Textbox 1" });
Controls.Add(
    new DialogComboboxViewModel
    {
        SelectedIndex = 0,
        Items = new ObservableCollection<string> { "Option 1", "Option 2" }
    }
);

form并没有设计mvvm collection的支持，不过我会思考一下怎么能兼容这个方案。

今天确定了一下，是可以做到的，不过我需要一些时间准备示例。

https://github.com/irihitech/Avalonia-Tutorials/tree/main/Tutorials/Form_Dynamic_Generation

authors: rabbitism seishinkouki


text:
Refactor directory

This will make it easier to get things correct.

Done

repo: irisli/stellarterm


text:
onRun not running

Hi in two of my apps on Run is not firing.
I now created an repro and indeed it stopped working.
see: https://github.com/frozeman/meteor-iron-router-onrun

What ever happened with this issue? onRun seems to work for me half the time. Same app. Haven't changed anything, but it doesn't consistently run. @frozeman did you work out what your problem was?

So it does seem to work. It's just when there's a hot code push, onRun stops working - even for future page changes. If you click refresh it starts working again.
See here: https://github.com/iron-meteor/iron-router/issues/982

repo: iron-meteor/iron-router


text:
.findOne works but .find does not inside of data tag

I was trying to render data through the "data" attribute in a route. I realized if I put .findOne, one value would appear, but .find would load no data with no errors in the console log.

Can you try .find().fetch() ?


text:
[MAD][DATA1018][lab-subsetting-and-descriptive-stats] Maris Font

Hola Belen,
Por fin logre terminar el ejercicio, pienso que me fue bien, pero me gustaria tener las respuestas para ver si estoy en lo correcto.
Saludos,
Maris

Hola Belen,
Por fin logre terminar el ejercicio, pienso que me fue bien, pero me gustaria tener las respuestas para ver si estoy en lo correcto.
Saludos,
Maris

Son correctos tus resultados. Sólo te faltó comentar algunas preguntas, como los resultados del boxplot.

license: Unlicense


text:
Added codependence support, minor tweaks

I'm going to have a think about the best way to write tests for the codependent integration. Also we need to release codependent to clojars before we merge this.

I've just made an improvement to the default configuration which I think makes us much more usable. I think basically the API is now worth supporting. I'm currently using utrecht for a project, so as I'm using the API over the next few days, i'll let you know whether we're going to cut to a 1.0 release.

repo: irresponsible/utrecht


text:
Interpolation format is not used during build/server phase

Describe the bug
We're experiencing a translation issue on our Next.JS boilerplate which uses next-i18next for translations.
The boilerplate: https://github.com/CrystallizeAPI/crystallize-nextjs-boilerplate
The interpolation format function does not get executed on the server, resulting in wrong translation output in the initial server response. The correct formatting is applied after client hydration.
Occurs in next-i18next version
8.1.3
Steps to reproduce

Go to the production website, https://furniture.superfast.shop/
Open devtools
Turn off Javascript
Refresh page to see the result from the build

Expected behaviour
Prices should be in the format of e.g.: €60
Screenshots
Before hydration

After hydration

You'll need to provide a minimum reproduction in order for others to debug.

You'll need to provide a minimum reproduction in order for others to debug.

I've added a minimum reproduction now

@hakonkrogh What I meant was that the repo you provided is complex and your problem most likely lies therein. If you would like assistance, you will need to reproduce your error in a simple repo, preferably a copy of the simple example.
Normally in these cases, you will end up discovering an implementation error in the process of creating a minimal repro.
Good luck!

Sounds like a fair request, I'll get on that 👍

Great. Happy to reopen if you can provide a minimum repro.

Created a minimum repo: https://github.com/hakonkrogh/i18next-simple

Is the Intl API defined in your server environment?

Is the Intl API defined in your server environment?

Yes, you should assume Node v14 here as the runtime (I forgot to mention that before)

Why did you choose to override your config only in _app? That is the root of your problem. Please read the documentation carefully. If you want to override the config in either _app or serverSideTranslations, you will need to do so consistently. I recommend just moving your changes into your next-i18next.config.js if they are serialisable.
Good luck!

Why did you choose to override your config only in _app? That is the root of your problem. Please read the documentation carefully. If you want to override the config in either _app or serverSideTranslations, you will need to do so consistently. I recommend just moving your changes into your next-i18next.config.js if they are serialisable.
Good luck!

The issue with this is that functions cannot be serialised as JSON, so we cannot have the interpolation.format function in the next-i18next.js file.

I've just seen we're actually missing the bit about also passing the unserialisable config into serverSideTranslations! That's a mistake.
If you're using TypeScript, you should be able to see the function call signature. This would be a great PR to improve documentation.

I've just seen we're actually missing the bit about also passing the unserialisable config into serverSideTranslations! That's a mistake.
If you're using TypeScript, you should be able to see the function call signature. This would be a great PR to improve documentation.

This is the solution. We're not using typescript in the boilerplate, that would have helped reveal the possible configuration options. I just pushed an update to our boilerplate unserialising the config, and then moving the format function into the proper config file: https://github.com/CrystallizeAPI/crystallize-nextjs-boilerplate/commit/1135ac465fc0c3a55f277d4e05ea7c688748a925.
Thanks for helping out resolving this issue 👍

@hakonkrogh Great! Would you be interested in creating a PR to update the docs?

@hakonkrogh Great! Would you be interested in creating a PR to update the docs?

Yup, on it right now

authors: hakonkrogh isaachinman


text:
Custom server warning in README

I think the readme should include a clear warning, that next-i18next requires a custom server and can therefore not be used with next export or serverless (e.g. now V2).
I guess it's implicitly stated, but it took me quite a long time to piece it together.
This might affect many next users.
Relevant Issues
#25 and #10

It can be used with next export and there's already a notice about this in the README.
The installation instructions clearly state the process involving a custom server and in no way suggest that these steps are optional. What would be a helpful way to communicate this further?
We are tracking serverless support with #274.

It sure had to do with my steep next-learning curve. I didn't realise that custom servers and now v2 don't go well together at first.
Maybe a note with link to the issue (#274) would be helpful.

authors: elbotho isaachinman


text:
feat: Deep merge nested config options

Fixes #179.

@lucasfeliciano Mind taking a look at this, and seeing if it's what you had in mind?
@RonnyVo Mind taking a look at this, and seeing if setting just config.detection.lookupCookie now works for you?

@isaachinman can you tell me how I can test before it get merged? Sorry I don't know much about about these workflow

@RonnyVo Probably the easiest way is:

Clone the repo, checkout this branch
Do npm i && npm run build && npm link
Go to your own project and do npm link next-i18next

@lucasfeliciano Yeah, that's right. I briefly considering pulling something like deepmerge in, but decided I'd rather this sort of deep merging be an intentional opt-in thing instead of all-encompassing.

authors: RonnyVo isaachinman


text:
OS-specificity: case insensitivity on OSX

One more problem:
On Mac:
/pro/web/Dave/app/builder/../proto/index/viewer/script/feature/printer/logger/Logger.s -> /pro/web/Dave/app/proto/index/viewer/script/feature/printer/logger/Logger.s

On Linux:
/pro/web/Dave/app/builder/../proto/index/viewer/script/feature/printer/logger/Logger.s ->

By some reason on OSX it is case insensitive.

If the file system is case insensitive, then this module will be case insensitive. There's not much to be done about that, since all the fs functions will play along with the "wrong" case.

File system on OSX is case sensitive by default.
Also it significantly decreases area of application if function cant act predictable on most platforms.
Anyway thank you for your contribution into open source. It's great deal.

It is only case preserving in some cases.  In this case, node-glob and bash do the same thing:
$ mkdir -p A/B/C
$ echo a/**
a/ a/B a/B/C
$ node -p 'require("./").sync("a/**")'
[ 'a', 'a/B', 'a/B/C' ]

However, there IS a discrepancy here:
$ echo readme.*
README.md
$ node -p 'require("./").sync("readme.*")'
[]

Gonna open a new bug for this.  Thanks for helping to find it :)

authors: Wandalen isaacs

repo: isaacs/node-glob

license: isc


text:
Bug when HOME has a trailing slash

There's a bug in the ini code when the HOME environment variable has a trailing slash. Somehow a slice() call was missed, and the code tries to call HOME as a function.

Weird.  Landed on 66c7eb98541c2b9d89fae636052407e072191e5a, thanks.

authors: isaacs mfncooper

repo: isaacs/npm


text:
support for string type ids

Is your feature request related to a problem? Please describe.
We use string ids in our system.
Describe the solution you'd like
support for string ids, currently only int ids are possible.
Describe alternatives you've considered
I thought of using timestamp as id since it's int, but that will be little weird. If an API only returns say txnId, I won't be able to get by id, I will have to iterate or will have to return timestamp everywhere to use in place of original id.

There have been many similar feature requests recently. Ease use the search to find duplicates 🙂

thanks @Viper-Bit
I will keep that in mind moving forward @leisim, thanks.

repo: isar/isar


text:
Add support for  HDF file format

Good morning, would it be possible to add support for the following data format, please?
https://en.wikipedia.org/wiki/Hierarchical_Data_Format
Thanks

Hello @ll4strw. You can already create standard conformant ISCCs for HDF files (actually for any file type) using the ISCC SUM SubType
Here is an example script to generate ISCCs for any subtype:
"""Create an ISCC-CODE for any file"""
from os.path import basename
import iscc_sdk as idk
import iscc_core as ic

def code_iscc_sum(fp, ld_type="Dataset"):
    # type: (str, str) -> idk.IsccMeta
    """
    Generate a minimal ISCC-CODE (SubType SUM)

    The ISCC-CODE SUM is a combination of the Data-Code and Instance-Code UNITS.
    As such it can handle any file irrespective of the file format.

    :param str fp: Filepath used for ISCC-CODE creation.
    :param str ld_type: JSON-LD schema.org type of the identified file
    :return: ISCC metadata including ISCC-CODE
    :rtype: IsccMeta
    """

    # Prepare basic metadata
    with open(fp, "rb") as infile:
        data = infile.read(4096)
    meta = {
        "@type": ld_type,
        "filename": basename(fp),
        "mediatype": idk.mediatype_guess(data, file_name=basename(fp)),
    }

    # Generate Data-Code and Instance-Code
    data = idk.code_data(fp)
    instance = idk.code_instance(fp)
    iscc_code = ic.gen_iscc_code_v0([data.iscc, instance.iscc])

    # Collect Metadata form UNIT processors
    meta.update(instance.dict())
    meta.update(data.dict())
    meta.update(iscc_code)

    return idk.IsccMeta.construct(**meta)

if __name__ == '__main__':
    fp = "/path/to/test.h5"
    iscc_meta = code_iscc_sum(fp)
    print(iscc_meta.json(indent=2))

The output then looks like this:
{
  "@context": "http://purl.org/iscc/context",
  "@type": "Dataset",
  "$schema": "http://purl.org/iscc/schema",
  "iscc": "ISCC:KUABEKSKSEJGHCQXVBIYEODRUPP5S",
  "filename": "test.h5",
  "filesize": 15072,
  "mediatype": "application/x-hdf",
  "datahash": "1e20a851823871a3dfd92c49834eb03ceba5b182f0e5095e6bf532f8774ff240172f"
}

This is the structure of the ISCC SUM:

(see INSPECT tab on https://huggingface.co/spaces/iscc/iscc-playground)
The Data-Code component of the ISCC SUM would allow to match HDF files that have minimal changes in the raw bitstream. How good that works in practical terms will depend on how deterministic HDF file encoding is.
If you want support for higher level ISCC-UNITs than it gets more complicated. In the end it is use-case dependent. You would need to think about what does HDF file content-similarty mean and what should similarity matching accomplish. For some guidance see: https://eval.iscc.codes/similarity/

Meta-Code: Would require some standardized way of extracting metadata from HDF files
Content-Code: Would require "content"-extraction from HDF files. But what is the content modality? TEXT, IMAGE, AUDIO, VIDEO ...
Same goes for an eventual Semantic-Code

Happy to discuss any ideas around metadata/content extraction from HDF files.

Yes, if you have external metadata then the ISCC NONE SubType is a perfectly valid type for internal use-cases. The problem with using custom/external metadata is interoperability. If other parties only have the HDF file they can likely not reproduce the Meta-Code unit. As far as I see HDF supports internal metadata (Attributes) attached to Group and Dataset objects. It shouldn´t be to hard to create some deterministic metadata extraction from the objects and their attributes.
I guess the best way forward would be to first create some kind of plugin system with hooks for handling specific file types. We could than create separate python packages that could register themselves. There are already some file types supported by the iscc-sdk which I would love to put into a separate package. Otherwise this project will soon suffer from dependency hell :)

Well the metadata situation is tricky. The SDK tries to support metadata extraction, mapping and embedding as good as that is possible for well known file types. See: https://github.com/iscc/iscc-sdk/blob/main/iscc_sdk/metadata.py. The extraction, embedding, and mapping logic is in the individual modules per modality. For example: https://github.com/iscc/iscc-sdk/blob/main/iscc_sdk/image.py#L255
We distinguish between different kinds of metadata. Metadata that is used for calculation of the Meta-Code is called Seed-Metadata. Those are only 3 fields: name,  description,  meta.  There are other fields that are embeddable/extractable but they are purely informational and not processed algorithmically.
For industry specific metadata you would usually define or pick an existing schema, serialize it into a Data-URL and put it into the meta field. The long version: https://ieps.iscc.codes/iep-0002/

repo: iscc/iscc-sdk


text:
DataSet splitting

Nice work!
I want to know the details about the dataset splitting, in the paper, the data sets were randomly split into training (70% of the data), validation (15%), and test set (15%).  But how many random seeds have been used and which seeds?
I think different random seed can get different results and it varies a lot
Thanks!

Hello, please have a look at the code. That information is in there.
Best

authors: isidroc shenwanxiang

repo: isidroc/kekulescope


text:
Wire pull animation

output
https://user-images.githubusercontent.com/52989607/193997632-0f9bd198-5d6a-4079-8af2-5194ab51fcdf.mp4

Creative!!! 🥇


text:
🛑 hgingenieria.isolucion.co is down

In 014d2e7, hgingenieria.isolucion.co (https://hgingenieria.isolucion.co) was down:

HTTP code: 0
Response time: 0 ms

ok

repo: isolucionco/EstadoIsolucionHosting


text:
🛑 dane.isolucion.co is down

In 78b6144, dane.isolucion.co (https://dane.isolucion.co) was down:

HTTP code: 0
Response time: 0 ms

Resolved: dane.isolucion.co is back up in a6cde28.


text:
Add Card API

This should contain basically the whole API as exposed in React Bootstrap. Still need to finish writing the documentation for the function components, but this should be ready once that's done. This is based on the ListGroup PR - I'll rebase it once that one merges.

Let me know if you approve of my modification, if so I will merge it as 0.8.0[^1].

Looks good to me

authors: CraftSpider isosphere

repo: isosphere/yew-bootstrap


text:
gestureHandling='greedy' not working

import React, { PureComponent } from 'react'
import GoogleMapReact from 'google-map-react'
import style from './style.css'

export default class GoogleMapPicker extends PureComponent {
  render () {
    const { latitude, longitude } = this.props

    if (!latitude || !longitude) return null

    const opts = {
      zoom: 16,
      gestureHandling: 'greedy',
      center: {
        lat: latitude,
        lng: longitude
      }
    }

    return (

        <GoogleMapReact
          onChange={p => console.log(p)}
          bootstrapURLKeys={{
            language: 'en',
            key: GMAPS_KEY
          }}
          {...opts}
          gestureHandling='greedy'
        />

    )
  }
}

doesn't seem to be enabling one finger drag, any ideas?

@hanford I'm facing the same issue. Did you find a solution yet?

repo: istarkov/google-map-react


text:
Webhook "pilot.validation.istio.io" reports invalid configuration error for valid config

ServiceEntry fails to create egress rule with host "metadata": https://raw.githubusercontent.com/kbhattac/CoolRetailer/master/setup/istio-manifests/whitelist-egress.yaml
kubectl apply -f setup/istio-manifests/whitelist-egress.yaml
Error from server: error when applying patch:
{"metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{"apiVersion":"networking.istio.io/v1alpha3","kind":"ServiceEntry","metadata":{"annotations":{},"name":"whitelist-egress","namespace":"default"},"spec":{"hosts":["169.254.169.254","metadata.google","metadata.google.internal","accounts.google.com","metadata",".googleapis.com"],"ports":[{"name":"http","number":80,"protocol":"HTTP"},{"name":"https","number":443,"protocol":"HTTPS"}]}}\n"}},"spec":{"hosts":["169.254.169.254","metadata.google","metadata.google.internal","accounts.google.com","metadata",".googleapis.com"]}}
to:
&{0xc42007f800 0xc42007b180 default whitelist-egress setup/istio-manifests/whitelist-egress.yaml 0xc422206df0 1656642 false}
for: "setup/istio-manifests/whitelist-egress.yaml": admission webhook "pilot.validation.istio.io" denied the request: configuration is invalid: invalid host metadata
Hostname "metadata" should be allowed. If not what is the workaround?

I tried to locate which part of the webhook code generates this error and even though I could clearly see the code validating ServiceEntry crd, it does not have any error related to host metadata.  I am using master branch of Istio. I think Steve's request is right about version. It looks to me there is a mismatch between webhook version and ServiceEntry config you try to push.

FWIW, I just ran into this (with a different hostname).  It appears the cause is https://github.com/istio/istio/blob/master/pilot/pkg/model/validation.go#L1818:
// Full wildcard or short names are not allowed in the service entry.
if host == "*" || !strings.Contains(host, ".") {
	errs = appendErrors(errs, fmt.Errorf("invalid host %s", host))
} else {
	errs = appendErrors(errs, ValidateWildcardDomain(host))
}

@tsiq-oliver what was the host name? this code catches is the host name is "*" or not fqdn.

@sbezverk In my case, it was my Travis VM's hostname (something like travis-job-0cc65e30-9e6e-4e18-a2d4-deadbeef).  So indeed not an FQDN, which is also the case for the OP here (metadata).

Hi Folks - is anyone currently working on this issue?

authors: BLaurenB kbhattac sbezverk tsiq-oliver

repo: istio/istio


text:
Authentication Policy

Goals:

Describe policy to support all authentication types: mTLS, TLS, JWT + mTLS, JWT + TLS, etc.
Describe policy to support service-to-service authentication, enduser-to-service authentication, and impersonation
Support incremental Istio authentication enablement

WIP Proposal

https://github.com/istio/api/pull/361

https://github.com/istio/api/pull/361

https://github.com/istio/api/pull/374

@diemtvu , this is the umbrella issue for auth policy, can we close it now?

authors: diemtvu spikecurtis wattli


text:
trace span type of inbound side is not right

Bug description
2 pods with sidecar: sleep pod and helloworld pod
sleep call helloworld service
the trace span TYPE of both side are "CLIENT"

expecting  span TYPE of inbound side (server side/ hellowrld pod) should be "SERVER"
[X] Policies and Telemetry
Expected behavior
span TYPE of inbound side  should be "SERVER"
Steps to reproduce the bug

install 1.5.2
apply sleep and helloworld pod
sleep call helloworld
see jaeger query, and tcp dump the report data from helloworld pod

Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
istioctl version --remote
client version: 1.5.2
control plane version: 1.5.2

kubectl version
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0"
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.3-tke.5"

How was Istio installed?
istioctl manifest apply --set profile=demo

Environment where bug was observed (cloud vendor, OS, etc)
tencent cloud TKE

reproduced in istio 1.6.0! both span.kind is "client"


text:
Workload evidence when using RBAC policy

Describe the feature request
Hello, when using RBAC with Istio and some workload is denied by policies, e.g. AuthorizationPolicy, Istio returns 403 - RBAC: access denied. It would be great to have s possibility to configure Istio/Envoy to return 404 Not Found instead to “hide” workload existence.
Describe alternatives you've considered
[ ] Docs
[ ] Installation
[x] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[x] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

Do you want to customize the rejection code and information of the access denied?
Is it used to isolate different tenants so that they are invisible to each other?

I took a look, xDS does not have this related configuration, and now it may be necessary to support this feature in Envoy first.

Do you want to customize the rejection code and information of the access denied? Is it used to isolate different tenants so that they are invisible to each other?

Yes, customization of the rejection code and information is exactly what I am looking for.
Our use-case here is that we want to hide the existence of the workload from the public network (internet) access by presenting 404, but for internal access (from the private network, we are fine with 403.

I took a look, xDS does not have this related configuration, and it may be necessary to support this feature in Envoy first.

Would you be able to help out with raising it? I am not familiar with Envoy internals and I do not know what to put into the feature request.

Sure, I will take time to follow up on this.

https://istio.io/latest/docs/reference/config/networking/sidecar/#Sidecar
https://github.com/istio/istio/blob/e8c442ea21680a397406fa8bf92aee7f34d0c121/pilot/pkg/networking/core/v1alpha3/httproute.go#L535-L591
Sidecar.OutboundTrafficPolicy, whether it meets your needs, based on namespace isolation, unregistered routes will return 504

Thanks for opening the issue! I think the current workaround is probably to use EnvoyFilter to configure the https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/local_reply (see more details in the Envoy issue).
But I also feel it might still worth to add first-class support in the Envoy RBAC filter directly and then expose it in Istio, One benefit is it could potentially give more flexibility, for example, different response for different RBAC rules, embed policy name in response for debugging purpose. Just commenting the idea here for some more comments from the community.

authors: jaygridley wzshiming yangminzhu


text:
How can we configure route based local rate limiting with Istio?

(This is used to request new product features, please visit https://discuss.istio.io for questions on using Istio)
Describe the feature request
Describe alternatives you've considered
Affected product area (please put an X in all that apply)
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
Additional context

do you read this https://istio.io/latest/docs/tasks/policy-enforcement/rate-limit/#local-rate-limit?

Yeah I have read this, but this not covering the configuration to local rate limit based on routes.

right now, there's no first class API to do this.

But it's mentioned here https://istio.io/latest/docs/tasks/policy-enforcement/rate-limit/#:~:text=Alternatively%2C you can restrict it to a specific route. That this can be done.
Also, Is there any way to define the config for envoy like this https://istio.io/latest/docs/tasks/policy-enforcement/rate-limit/#:~:text=Alternatively%2C you can restrict it to a specific route. via Istio?

you can use EnvoyFilter do that, not first class API .


text:
1.17.0 containers not available through gcr.io/istio-release

Bug Description
The  gcr.io/istio-release repository is documented as official mirror for container images. Currently it lacks the v1.17.0 release containers.
Even though images can still be retrieved through hub.docker.com it's a bit inconvenient for users to switch between repositories.
Would be great to have all versions available on gcr.io/istio-release after the official release.
Version
$ istioctl version
client version: 1.17.0
control plane version: 1.16.2

Additional Information
No response

cc @istio/release-managers-1-17

1.17.1 is out now and fixes this. Sorry we decided we couldn't safely fix the botched 1.17.0 release. Good news is 1.17.1 is even better :wink:

authors: howardjohn tolleiv zirain


text:
TestValidatorCacheDoubleEdits crashing in racetest

blocking #4235
=== RUN   TestValidatorCacheDoubleEdits/put-put-3
2018-03-23T02:40:03.204614Z	info	Publishing 1 events
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x48 pc=0x175fd67]
goroutine 111 [running]:
istio.io/istio/mixer/pkg/runtime2/validator.(*validatorCache).applyChanges(0xc420ad4260, 0xc42045e000, 0x1, 0x32)
/go/src/istio.io/istio/mixer/pkg/runtime2/validator/validatorcache.go:46 +0x147
istio.io/istio/mixer/pkg/runtime2/validator.(*validatorCacheTestController).applyChanges(0xc4207dea20, 0xc42045e000, 0x1, 0x32)
/go/src/istio.io/istio/mixer/pkg/runtime2/validator/validatorcache_test.go:74 +0x6c
istio.io/istio/mixer/pkg/runtime2/validator.(*validatorCacheTestController).(istio.io/istio/mixer/pkg/runtime2/validator.applyChanges)-fm(0xc42045e000, 0x1, 0x32)
/go/src/istio.io/istio/mixer/pkg/runtime2/validator/validatorcache_test.go:64 +0x60
istio.io/istio/mixer/pkg/config/store.WatchChanges(0xc42037e000, 0xc420924360, 0xf4240, 0xc4207460d0)
/go/src/istio.io/istio/mixer/pkg/config/store/listener.go:67 +0x2a5
created by istio.io/istio/mixer/pkg/runtime2/validator.newValidatorCacheForTest
/go/src/istio.io/istio/mixer/pkg/runtime2/validator/validatorcache_test.go:64 +0x727
FAIL	istio.io/istio/mixer/pkg/runtime2/validator	4.407s

no longer be able to repo.


text:
istio side car proxy Version istio/proxyv2:1.15.3 is crashing

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description
we are using istio sidecar for all our workloads, we havent faces any problem but since yesterday,  the envoy proxy has crashed and hence the app is unavailable. however, the proxy version on other clusters are working fine.
Version
kubernetes version 1.23.16
istio version:v2:1.15.3

Additional Information
2024-05-09T05:28:36.469821Z	warning	envoy config	gRPC config for type.googleapis.com/envoy.config.listener.v3.Listener rejected: Error adding/updating listener(s) 0.0.0.0_0: cannot bind '0.0.0.0': Read-only file system
99
98
2024-05-09T05:28:36.497922Z	warn	Envoy proxy is NOT ready: config received from XDS server, but was rejected: cds updates: 15 successful, 0 rejected; lds updates: 0 successful, 15 rejected
97
2024-05-09T05:28:37.012659Z	warn	Envoy proxy is NOT ready: config received from XDS server, but was rejected: cds updates: 16 successful, 0 rejected; lds updates: 0 successful, 15 rejected
96
2024-05-09T05:28:37.115585Z	error	envoy config	listener '0.0.0.0_0' failed to bind or apply socket options: cannot bind '0.0.0.0': Read-only file system
95
2024-05-09T05:28:37.185936Z	warning	envoy config	gRPC config for type.googleapis.com/envoy.config.listener.v3.Listener rejected: Error adding/updating listener(s) 0.0.0.0_0: cannot bind '0.0.0.0': Read-only file system
94
93
2024-05-09T05:28:37.296195Z	error	envoy config	listener '0.0.0.0_0' failed to bind or apply socket options: cannot bind '0.0.0.0': Read-only file system

i have pasted the error logs above, failing to understand what could be the reason, i tried rolling restart of the istiod deployment, didnt help. seeing the same error logs as above in istiod pod logs as well

1.15 was EOL for a long long time, please upgrade and retest.

@zirain  thanks for responding, i do agree, we have to upgrade, do we have any solution for this problem, as we are currently using the same version in prod, it would take us a week to upgrade to new version until we push it prod

0.0.0.0_0 this's wired, possible cause by some incorrect configuration.

can you please help me, which configuration to verify, i'm currently blocked, istio is only being used here as a proxy and other features are currenlty not in use on these clusters

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: >
{"apiVersion":"install.istio.io/v1alpha1","kind":"IstioOperator","metadata":{"annotations":{},"labels":{"app.kubernetes.io/instance":"b-ae1-1-istio-controlplane"},"name":"istio-controlplane","namespace":"istio-system"},"spec":{"components":{"base":{"enabled":true},"cni":{"enabled":false},"egressGateways":[{"enabled":false,"name":"istio-egressgateway"}],"ingressGateways":[{"enabled":false,"name":"istio-ingressgateway"}],"istiodRemote":{"enabled":false},"pilot":{"enabled":true}},"hub":"docker.io/istio","meshConfig":{"accessLogFile":"/dev/stdout","connectTimeout":"6s","defaultConfig":{"proxyMetadata":{"ISTIO_META_DNS_CAPTURE":"true"}},"enableAutoMtls":false,"enablePrometheusMerge":true,"outboundTrafficPolicy":{"mode":"ALLOW_ANY"}},"profile":"empty","tag":"1.15.3","values":{"base":{"enableCRDTemplates":false,"validationURL":""},"gateways":{"istio-egressgateway":{"autoscaleEnabled":true,"env":{},"name":"istio-egressgateway","secretVolumes":[{"mountPath":"/etc/istio/egressgateway-certs","name":"egressgateway-certs","secretName":"istio-egressgateway-certs"},{"mountPath":"/etc/istio/egressgateway-ca-certs","name":"egressgateway-ca-certs","secretName":"istio-egressgateway-ca-certs"}],"type":"ClusterIP","zvpn":{}},"istio-ingressgateway":{"autoscaleEnabled":true,"env":{},"name":"istio-ingressgateway","secretVolumes":[{"mountPath":"/etc/istio/ingressgateway-certs","name":"ingressgateway-certs","secretName":"istio-ingressgateway-certs"},{"mountPath":"/etc/istio/ingressgateway-ca-certs","name":"ingressgateway-ca-certs","secretName":"istio-ingressgateway-ca-certs"}],"type":"LoadBalancer","zvpn":{}}},"global":{"arch":{"amd64":2,"ppc64le":2,"s390x":2},"configValidation":true,"defaultNodeSelector":{},"defaultPodDisruptionBudget":{"enabled":true},"defaultResources":{"requests":{"cpu":"10m"}},"imagePullPolicy":"IfNotPresent","imagePullSecrets":[],"istioNamespace":"istio-system","istiod":{"enableAnalysis":false},"jwtPolicy":"third-party-jwt","logAsJson":false,"logging":{"level":"default:info"},"meshNetworks":{},"mountMtlsCerts":false,"multiCluster":{"clusterName":"","enabled":false},"network":"","omitSidecarInjectorConfigMap":false,"oneNamespace":false,"operatorManageWebhooks":false,"pilotCertProvider":"istiod","priorityClassName":"","proxy":{"autoInject":"enabled","clusterDomain":"cluster.local","componentLogLevel":"misc:error","enableCoreDump":false,"excludeIPRanges":"","excludeInboundPorts":"","excludeOutboundPorts":"","holdApplicationUntilProxyStarts":true,"image":"proxyv2","includeIPRanges":"","logLevel":"warning","privileged":false,"readinessFailureThreshold":30,"readinessInitialDelaySeconds":10,"readinessPeriodSeconds":2,"resources":{"limits":{"cpu":"2000m","memory":"1024Mi"},"requests":{"cpu":"100m","memory":"128Mi"}},"statusPort":15020,"tracer":"zipkin"},"proxy_init":{"image":"proxyv2","resources":{"limits":{"cpu":"2000m","memory":"1024Mi"},"requests":{"cpu":"10m","memory":"10Mi"}}},"sds":{"token":{"aud":"istio-ca"}},"sts":{"servicePort":0},"tracer":{"datadog":{},"lightstep":{},"stackdriver":{},"zipkin":{}},"useMCP":false},"istiodRemote":{"injectionURL":""},"pilot":{"autoscaleEnabled":true,"autoscaleMax":200,"autoscaleMin":50,"configMap":true,"cpu":{"targetAverageUtilization":80},"deploymentLabels":null,"enableProtocolSniffingForInbound":true,"enableProtocolSniffingForOutbound":true,"env":{},"image":"pilot","keepaliveMaxServerConnectionAge":"30m","nodeSelector":{},"replicaCount":1,"traceSampling":1},"sidecarInjectorWebhook":{"rewriteAppHTTPProbe":false},"telemetry":{"enabled":true,"v2":{"enabled":true,"metadataExchange":{"wasmEnabled":false},"prometheus":{"enabled":true,"wasmEnabled":false},"stackdriver":{"configOverride":{},"enabled":false,"logging":false,"monitoring":false,"topology":false}}}}}}
creationTimestamp: '2023-04-12T14:51:27Z'
finalizers:
- istio-finalizer.install.istio.io
generation: 2
labels:
app.kubernetes.io/instance: beta-1-istio-controlplane
managedFields:
- apiVersion: install.istio.io/v1alpha1
fieldsType: FieldsV1
fieldsV1:
'f:metadata':
'f:finalizers':
.: {}
'v:"istio-finalizer.install.istio.io"': {}
manager: operator
operation: Update
time: '2023-04-12T14:51:28Z'
- apiVersion: install.istio.io/v1alpha1
fieldsType: FieldsV1
fieldsV1:
'f:status':
.: {}
'f:componentStatus':
.: {}
'f:Base':
.: {}
'f:status': {}
'f:Pilot':
.: {}
'f:status': {}
'f:status': {}
manager: operator
operation: Update
subresource: status
time: '2023-04-12T14:52:25Z'
- apiVersion: install.istio.io/v1alpha1
fieldsType: FieldsV1
fieldsV1:
'f:metadata':
'f:annotations':
.: {}
'f:kubectl.kubernetes.io/last-applied-configuration': {}
'f:labels':
.: {}
'f:app.kubernetes.io/instance': {}
'f:spec':
.: {}
'f:components':
.: {}
'f:base':
.: {}
'f:enabled': {}
'f:cni':
.: {}
'f:enabled': {}
'f:egressGateways': {}
'f:ingressGateways': {}
'f:istiodRemote':
.: {}
'f:enabled': {}
'f:pilot':
.: {}
'f:enabled': {}
'f:hub': {}
'f:meshConfig':
.: {}
'f:accessLogFile': {}
'f:connectTimeout': {}
'f:defaultConfig':
.: {}
'f:proxyMetadata':
.: {}
'f:ISTIO_META_DNS_CAPTURE': {}
'f:enableAutoMtls': {}
'f:enablePrometheusMerge': {}
'f:outboundTrafficPolicy':
.: {}
'f:mode': {}
'f:profile': {}
'f:tag': {}
'f:values':
.: {}
'f:base':
.: {}
'f:enableCRDTemplates': {}
'f:validationURL': {}
'f:gateways':
.: {}
'f:istio-egressgateway':
.: {}
'f:autoscaleEnabled': {}
'f:env': {}
'f:name': {}
'f:secretVolumes': {}
'f:type': {}
'f:zvpn': {}
'f:istio-ingressgateway':
.: {}
'f:autoscaleEnabled': {}
'f:env': {}
'f:name': {}
'f:secretVolumes': {}
'f:type': {}
'f:zvpn': {}
'f:global':
.: {}
'f:arch':
.: {}
'f:amd64': {}
'f:ppc64le': {}
'f:s390x': {}
'f:configValidation': {}
'f:defaultNodeSelector': {}
'f:defaultPodDisruptionBudget':
.: {}
'f:enabled': {}
'f:defaultResources':
.: {}
'f:requests':
.: {}
'f:cpu': {}
'f:imagePullPolicy': {}
'f:imagePullSecrets': {}
'f:istioNamespace': {}
'f:istiod':
.: {}
'f:enableAnalysis': {}
'f:jwtPolicy': {}
'f:logAsJson': {}
'f:logging':
.: {}
'f:level': {}
'f:meshNetworks': {}
'f:mountMtlsCerts': {}
'f:multiCluster':
.: {}
'f:clusterName': {}
'f:enabled': {}
'f:network': {}
'f:omitSidecarInjectorConfigMap': {}
'f:oneNamespace': {}
'f:operatorManageWebhooks': {}
'f:pilotCertProvider': {}
'f:priorityClassName': {}
'f:proxy':
.: {}
'f:autoInject': {}
'f:clusterDomain': {}
'f:componentLogLevel': {}
'f:enableCoreDump': {}
'f:excludeIPRanges': {}
'f:excludeInboundPorts': {}
'f:excludeOutboundPorts': {}
'f:holdApplicationUntilProxyStarts': {}
'f:image': {}
'f:includeIPRanges': {}
'f:logLevel': {}
'f:privileged': {}
'f:readinessFailureThreshold': {}
'f:readinessInitialDelaySeconds': {}
'f:readinessPeriodSeconds': {}
'f:resources':
.: {}
'f:limits':
.: {}
'f:cpu': {}
'f:memory': {}
'f:requests':
.: {}
'f:cpu': {}
'f:memory': {}
'f:statusPort': {}
'f:tracer': {}
'f:proxy_init':
.: {}
'f:image': {}
'f:resources':
.: {}
'f:limits':
.: {}
'f:cpu': {}
'f:memory': {}
'f:requests':
.: {}
'f:cpu': {}
'f:memory': {}
'f:sds':
.: {}
'f:token':
.: {}
'f:aud': {}
'f:sts':
.: {}
'f:servicePort': {}
'f:tracer':
.: {}
'f:datadog': {}
'f:lightstep': {}
'f:stackdriver': {}
'f:zipkin': {}
'f:useMCP': {}
'f:istiodRemote':
.: {}
'f:injectionURL': {}
'f:pilot':
.: {}
'f:autoscaleEnabled': {}
'f:autoscaleMax': {}
'f:autoscaleMin': {}
'f:configMap': {}
'f:cpu':
.: {}
'f:targetAverageUtilization': {}
'f:deploymentLabels': {}
'f:enableProtocolSniffingForInbound': {}
'f:enableProtocolSniffingForOutbound': {}
'f:env': {}
'f:image': {}
'f:keepaliveMaxServerConnectionAge': {}
'f:nodeSelector': {}
'f:replicaCount': {}
'f:traceSampling': {}
'f:sidecarInjectorWebhook':
.: {}
'f:rewriteAppHTTPProbe': {}
'f:telemetry':
.: {}
'f:enabled': {}
'f:v2':
.: {}
'f:enabled': {}
'f:metadataExchange':
.: {}
'f:wasmEnabled': {}
'f:prometheus':
.: {}
'f:enabled': {}
'f:wasmEnabled': {}
'f:stackdriver':
.: {}
'f:configOverride': {}
'f:enabled': {}
'f:logging': {}
'f:monitoring': {}
'f:topology': {}
manager: argocd-application-controller
operation: Update
time: '2023-04-25T14:17:17Z'
name: istio-controlplane
namespace: istio-system
resourceVersion: '97708879'
uid: 90e94bed-a8e5-4a0d-9b03-4c5d9f9181e3
spec:
components:
base:
enabled: true
cni:
enabled: false
egressGateways:
- enabled: false
name: istio-egressgateway
ingressGateways:
- enabled: false
name: istio-ingressgateway
istiodRemote:
enabled: false
pilot:
enabled: true
hub: docker.io/istio
meshConfig:
accessLogFile: /dev/stdout
connectTimeout: 6s
defaultConfig:
proxyMetadata:
ISTIO_META_DNS_CAPTURE: 'true'
enableAutoMtls: false
enablePrometheusMerge: true
outboundTrafficPolicy:
mode: ALLOW_ANY
profile: empty
tag: 1.15.3
values:
base:
enableCRDTemplates: false
validationURL: ''
gateways:
istio-egressgateway:
autoscaleEnabled: true
env: {}
name: istio-egressgateway
secretVolumes:
- mountPath: /etc/istio/egressgateway-certs
name: egressgateway-certs
secretName: istio-egressgateway-certs
- mountPath: /etc/istio/egressgateway-ca-certs
name: egressgateway-ca-certs
secretName: istio-egressgateway-ca-certs
type: ClusterIP
zvpn: {}
istio-ingressgateway:
autoscaleEnabled: true
env: {}
name: istio-ingressgateway
secretVolumes:
- mountPath: /etc/istio/ingressgateway-certs
name: ingressgateway-certs
secretName: istio-ingressgateway-certs
- mountPath: /etc/istio/ingressgateway-ca-certs
name: ingressgateway-ca-certs
secretName: istio-ingressgateway-ca-certs
type: LoadBalancer
zvpn: {}
global:
arch:
amd64: 2
ppc64le: 2
s390x: 2
configValidation: true
defaultNodeSelector: {}
defaultPodDisruptionBudget:
enabled: true
defaultResources:
requests:
cpu: 10m
imagePullPolicy: IfNotPresent
imagePullSecrets: []
istioNamespace: istio-system
istiod:
enableAnalysis: false
jwtPolicy: third-party-jwt
logAsJson: false
logging:
level: 'default:info'
meshNetworks: {}
mountMtlsCerts: false
multiCluster:
clusterName: ''
enabled: false
network: ''
omitSidecarInjectorConfigMap: false
oneNamespace: false
operatorManageWebhooks: false
pilotCertProvider: istiod
priorityClassName: ''
proxy:
autoInject: enabled
clusterDomain: cluster.local
componentLogLevel: 'misc:error'
enableCoreDump: false
excludeIPRanges: ''
excludeInboundPorts: ''
excludeOutboundPorts: ''
holdApplicationUntilProxyStarts: true
image: proxyv2
includeIPRanges: ''
logLevel: warning
privileged: false
readinessFailureThreshold: 30
readinessInitialDelaySeconds: 10
readinessPeriodSeconds: 2
resources:
limits:
cpu: 2000m
memory: 1024Mi
requests:
cpu: 100m
memory: 128Mi
statusPort: 15020
tracer: zipkin
proxy_init:
image: proxyv2
resources:
limits:
cpu: 2000m
memory: 1024Mi
requests:
cpu: 10m
memory: 10Mi
sds:
token:
aud: istio-ca
sts:
servicePort: 0
tracer:
datadog: {}
lightstep: {}
stackdriver: {}
zipkin: {}
useMCP: false
istiodRemote:
injectionURL: ''
pilot:
autoscaleEnabled: true
autoscaleMax: 200
autoscaleMin: 50
configMap: true
cpu:
targetAverageUtilization: 80
deploymentLabels: null
enableProtocolSniffingForInbound: true
enableProtocolSniffingForOutbound: true
env: {}
image: pilot
keepaliveMaxServerConnectionAge: 30m
nodeSelector: {}
replicaCount: 1
traceSampling: 1
sidecarInjectorWebhook:
rewriteAppHTTPProbe: false
telemetry:
enabled: true
v2:
enabled: true
metadataExchange:
wasmEnabled: false
prometheus:
enabled: true
wasmEnabled: false
stackdriver:
configOverride: {}
enabled: false
logging: false
monitoring: false
topology: false
status:
componentStatus:
Base:
status: HEALTHY
Pilot:
status: HEALTHY
status: HEALTHY
this is the current istio-control plane manifest file

Exec lifecycle hook ([pilot-agent wait]) for Container "istio-proxy" in Pod "cache-7b6b-cb57t_next(852fb1c9-93db-78169afce051)" failed - error: command 'pilot-agent wait' exited with 255: Error: timeout waiting for Envoy proxy to become ready. Last error: HTTP status code 503...
this is the error seen in the worload events

I think I saw this in the past, I recall it was from some invalid config that had port unset and missed validation.
As mentioned though 1.15 is super EOL. It's best to stay on top of upgrades so you don't have to scramble to upgrade when you hit issues... especially if you are relying on community support

thanks for responding @howardjohn , we are in process to migrate, since this is currently in prod, we are trying to mitigate this issue, can you please share more info when you say invalid config that had port unset. which config are you referring here, can you please elaborate, thanks

I think it was a Gateway but not sure, and that wouldn't apply here. It was at a previous company so I don't have access to more info. I recall it was for using an old version though TBH and the issue has been fixed already

Do you have any EnvoyFilters recently changed that may break that?
Most of the issues we faced using Istio v1.15 were due to misconfiguration on EnvoyFilters. (We heavily rely on EnvoyFilter to achieve some routing features.)

authors: MengjiaLiang howardjohn sakulka zirain


text:
documentation not matching current release

Describe the bug
In the istio 1.0.0 documentation in the debugging component part. The commands presented to use with the switch proxy-command are not matching the one available in the binary
from the docs:
istioctl proxy-config endpoint <pod-name> clusters
istioctl proxy-config pilot -n application <pod-name> eds

from istioctl -h
Available Commands:
  bootstrap   Retrieves bootstrap configuration for the Envoy in the specified pod
  cluster     Retrieves cluster configuration for the Envoy in the specified pod
  listener    Retrieves listener configuration for the Envoy in the specified pod
  route       Retrieves route configuration for the Envoy in the specified pod

Expected behavior
The doc to match the available commands
Steps to reproduce the bug
Use the cli following the documentation
Version
1.0.0 for istioctl and doc available here

What istioctl version is this help output from?
The output for the released v1.0.0 istioctl for me is:
Available Commands:
  authn          Interact with Istio authentication policies
  context-create Create a kubeconfig file suitable for use with istioctl in a non kubernetes environment
  create         Create policies and rules
  delete         Delete policies or rules
  deregister     De-registers a service instance
  experimental   Experimental commands that may be modified or deprecated
  gen-deploy     Generates the configuration for Istio's control plane.
  get            Retrieve policies and rules
  help           Help about any command
  kube-inject    Inject Envoy sidecar into Kubernetes pod resources
  proxy-config   Retrieve information about proxy configuration from Envoy [kube only]
  proxy-status   Retrieves the synchronization status of each Envoy in the mesh [kube only]
  register       Registers a service instance (e.g. VM) joining the mesh
  replace        Replace existing policies and rules
  version        Prints out build version information

full log from istioctl version
Version: 1.0.0
GitRevision: 3a136c90ec5e308f236e0d7ebb5c4c5e405217f4
User: root@71a9470ea93c
Hub: gcr.io/istio-release
GolangVersion: go1.10.1
BuildStatus: Clean

full log from istioctl pc -h
A group of commands used to retrieve information about proxy configuration from the Envoy config dump

Usage:
  istioctl proxy-config [command]

Aliases:
  proxy-config, pc

Examples:
  # Retrieve information about proxy configuration from an Envoy instance.
  istioctl proxy-config <clusters|listeners|routes|bootstap> <pod-name>

Available Commands:
  bootstrap   Retrieves bootstrap configuration for the Envoy in the specified pod
  cluster     Retrieves cluster configuration for the Envoy in the specified pod
  listener    Retrieves listener configuration for the Envoy in the specified pod
  route       Retrieves route configuration for the Envoy in the specified pod

Flags:
  -h, --help            help for proxy-config
  -o, --output string   Output format: one of json|short (default "short")

Global Flags:
      --context string                The name of the kubeconfig context to use
  -i, --istioNamespace string         Istio system namespace (default "istio-system")
  -c, --kubeconfig string             Kubernetes configuration file
      --log_as_json                   Whether to format output as JSON or in plain console-friendly format
      --log_caller string             Comma-separated list of scopes for which to include caller information, scopes can be any of [ads, default, model, rbac]
      --log_output_level string       Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, default, model, rbac] and level can be one of [debug, info, warn, error, none] (default "default:info")
      --log_rotate string             The path for the optional rotating log file
      --log_rotate_max_age int        The maximum age in days of a log file beyond which the file is rotated (0 indicates no limit) (default 30)
      --log_rotate_max_backups int    The maximum number of log file backups to keep before older files are deleted (0 indicates no limit) (default 1000)
      --log_rotate_max_size int       The maximum size in megabytes of a log file beyond which the file is rotated (default 104857600)
      --log_stacktrace_level string   Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [ads, default, model, rbac] and level can be one of [debug, info, warn, error, none] (default "default:none")
      --log_target stringArray        The set of paths where to output the log. This can be any path as well as the special values stdout and stderr (default [stdout])
  -n, --namespace string              Config namespace
  -p, --platform string               Istio host platform (default "kube")

Use "istioctl proxy-config [command] --help" for more information about a command.

@ymesika your output is from istioctl -h my issue is that the options listed in the documentation for istioctl pc mismatch the one that I see when i run istioctl pc -h (note the pc here, can be replaced by proxy-config)

@visheyra Right, my bad. Indeed doc issue.

authors: visheyra ymesika