test: integration test for tekton on cluster build

Changes

:broom: Integration test for tekton on cluster build.

Great s2i on cluster build just finished with:
        error preparing container for next step: error creating build container: error creating container: creating read-write layer with ID "d531de0ae4a8d9be6d6b28a755cd99073ac26dcfc9b85cd4110df14c6059e9df": no space left on device

@zroubalik @jrangelramos PTAL

Great, s2i on cluster build just crashed with:
        error preparing container for next step: error creating build container: error creating container: creating read-write layer with ID "d531de0ae4a8d9be6d6b28a755cd99073ac26dcfc9b85cd4110df14c6059e9df": no space left on device

It happened at least 3 times in row, not good.
How does is come that e2e with s2i works? @jrangelramos

Great, s2i on cluster build just crashed with:
        error preparing container for next step: error creating build container: error creating container: creating read-write layer with ID "d531de0ae4a8d9be6d6b28a755cd99073ac26dcfc9b85cd4110df14c6059e9df": no space left on device

It happened at least 3 times in row, not good. How does is come that e2e with s2i works? @jrangelramos

Hmm.. how big gitlab is.. ? I remember trying that a long ago and it used to be big. Might be consuming host running space..

@jrangelramos  It takes 1-2 GB of memory (RAM) not sure about disk.

I'm not sure we can have a gh runner with larger disk space.. Perhaps you could stick your tests with pack builder for now. s2i task is also tested against all supported runtime e2e on cluster test and runtime tests.. so we should be covered.

@lance @jrangelramos for now I decided to skip s2i test.
Please re-lgtm and override the linter error.

@matejvasek what about increasing func-s2i to 0.2? we could start incrementing these yaml version whenever we modify them.. wdty?

@matejvasek what about increasing func-s2i to 0.2? we could start incrementing these yaml version whenever we modify them.. wdty?

@jrangelramos TBH I am not even sure we want to have the version on file path. So I would prefer leave it and maybe discus later.

@jrangelramos look for instance on https://github.com/openshift-pipelines/pipelines-as-code , they have yamls in ./config and on release cut they compile uber-yaml that is then available on URL containing version/branch/tag.
IMO having version as named directory would make sense if we were maintaining multiple version of task at once (not just rename on each update).
So I would prefer to remove version from file path entirely.

@zroubalik or @lance  please override the linter error.

/override "style / suggester / shell"

/lgtm


add algorithm and algorithmic compatibility

Lists algorithm as currently-incompatible because it defines the algorithm environment with the float package so is not tagged as a float.
Lists algorithmic as compatible and adds a test. The algorithmic environment is implemented as a list which I guess is okay for tagging algorithms.
Removes the "algorithms" entry since that's just the CTAN name for these two packages.

Removes the "algorithms" entry since that's just the CTAN name for these two packages.

@FrankMittelbach  TLC3 index errata?

Removes the "algorithms" entry since that's just the CTAN name for these two packages.

@FrankMittelbach TLC3 index errata?

that's an odd one. it is true the bundle on ctan generates 2 .sty files but if you want to get to the documentation then that is called "algorithms", e.g. texdoc algorithms finds it but using algorithm gives you a list of options. hmmm

ah then I remembered incorrectly and my change in tlc was wrong it should change to algorithmic then and we should alter the included-in on both.
(I don't have space on that page so can put in only one name :-) and anyway it is about making algorithms not making them float os algorithmic it is ...

changed the entries


对话错误

Traceback (most recent call last):
File "bot_emulator.py", line 97, in
main(sys.argv[1], sys.argv[2])
File "bot_emulator.py", line 67, in main
obj = requests.post(url, data=json.dumps(payload), headers=json_header).json()
File "/home/xutongxin/.local/lib/python2.7/site-packages/requests/api.py", line 116, in post
return request('post', url, data=data, json=json, **kwargs)
File "/home/xutongxin/.local/lib/python2.7/site-packages/requests/api.py", line 60, in request
return session.request(method=method, url=url, **kwargs)
File "/home/xutongxin/.local/lib/python2.7/site-packages/requests/sessions.py", line 533, in request
resp = self.send(prep, **send_kwargs)
File "/home/xutongxin/.local/lib/python2.7/site-packages/requests/sessions.py", line 646, in send
r = adapter.send(request, **kwargs)
File "/home/xutongxin/.local/lib/python2.7/site-packages/requests/adapters.py", line 516, in send
raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPConnectionPool(host='<IP_ADDRESS>', port=8010): Max retries exceeded with url: /search?access_token=····················································································（确定是access_token)(Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f246d8e5490>: Failed to establish a new connection: [Errno 111] Connection refused',))

DM Kit服务是否已在本地正常启动？

我应该已经按照步骤一步步操作，但是似乎是没有开启，只是完成了编译，如何开启？
谢谢

在_build目录下运行./dmkit

谢谢


Fix git tag assignment to get absolute latest tag

This PR fixes the logic for assigning the git tag to the EKS-A cluster controller image/manifests.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/override eks-anywhere-release-tooling-presubmit
This will pass after the git tag change goes through.

/override eks-anywhere-release-tooling-presubmit


Cross-type number comparisons

Rendered

Besides the listed downsides, it will negatively affect type type inference. Currently code like
let x = 2_u16;
dbg!(x > 5);

compiles, because there is a single possible impl  for comparison with u16. If comparisons with other types are added, this code will fail to compile, since there will no longer be a default impl to fall back to.
It's also a correctness footgun. If I understand the proposition correctly,<PHONE_NUMBER>_f32 ==<PHONE_NUMBER> should be true, but that goes against reasonable expectations. It's an extra footgun if the result of comparison would depend on the exact integer and floating point types.
Overall, writing the comparison explicitly is simple enough and shouldn't be common enough to warrant those issues.

I want to note I think there's a slight difference between comparing integer types and comparing between integer and floating point types. Including float<->integer comparisons introduces some things that you could potentially view as a problem:

Slightly larger performance than you might expect for a comparison, with multiple branches
Unintuitive (non-integer-logic) behavior when the float is a NaN
The<PHONE_NUMBER>_f32 ==<PHONE_NUMBER> issue described above

I am not sure any of these are an argument not to do the thing, particularly because all of them apply in the existing case of float-to-float comparisons: float can be expensive on softfpu systems; float-to-float comparison does something that programmers often misunderstand, leading to bugs, if one float is NaN; Currently Rust evaluates "true" for the expression<PHONE_NUMBER>_f32 ==<PHONE_NUMBER>_f32. But at least you can form the argument, whereas I don't think any of these apply in the case of integer-to-integer comparisons (unless a single branch in the case of a signed-to-unsigned comparison is a performance concern, which seems really tenuous).

I think the inference issues make this a non-starter. I'd expect this to break all the rust code where a variable of numeric type is compared against a number literal (for example, a == 0). We had a similar (but less extreme) issue in std::simd, and it broke a ton of code (even things that didn't care at all about simd).

Type inference shouldn't be affected by this change, because the generic parameter on PartialOrd and PartialEq is defaulted to Self. Therefore, expressions like 1 == 1_u8 will continue to work by correctly inferring the first literal to be a u8.

Sadly, I don't believe this is how type inference works, at least not at the moment (and my understanding is that	extending it to handle defaults the way some folks expect requires some nontrivial design work, at the very least).

@mcclure How would you compare i64::MIN and u64::MAX without extra branching? You can't cast them to a larger native type.
I think the only comparisons which are more or less reasonable are comparison of same-sign different-width integers, e.g. i16 vs isize or u8 vs u64. But the inference issue remains, and it's unclear whether it helps that much in practice.
What would help imho is if 1_u8.into() == 1_u32 could compile, rather than throw a type inference error. It's a safe, unambiguous and correct way to perform such comparisons, but it can't compile since the type of the LHS can't be inferred (formally it could map into any T which has a PartialEq<u32> impl).
@scottmcm That inference error is quite similar to the one plaguing try blocks. Do you think there could be some change of inference which solves them both? Feels like there could be some "choose the minimal solution" logic possible.

@mcclure How would you compare i64::MIN and u64::MAX without extra branching?

I would use branching.

cascadingly change numbers to be of the same type

And that's the right thing to do, in most cases.

or, hand-roll cross-type comparisons

Not, if cross-type comparisons are provided as regular non-operator functions by the standard library, for the remaining cases where it's really necessary.

It's really enough that rustc gives helpful error messages imho, likely already the case.
There are some nasty footguns if Rust introduces additional branches inside simple equality comparisons.  It makes auditing code for being constant time far harder for example.
We already have Froms that makes conversions fairly easy.  In fact, this might breaks code like x.into() == y.  It's be particularly awful if people convert better code like x.into() == y into worse ambiguous code like x == y just to silence bad new error.

Thanks everyone for the thoughts. I compiled the arguments mentioned in the comments:

type interference will be broken
correctness footgun<PHONE_NUMBER>_f32 ==<PHONE_NUMBER>)

arguably not a problem, because this is an intrinsic property to floats:<PHONE_NUMBER>_f32 ==<PHONE_NUMBER>_f32` is already true in current Rust

unexpectedly expensive operation for a comparison / auditing code for constant time is harder

remains to be benchmarked (there may be clever algorithms that are very fast / constant time)

for int<->uint comparisons, the naive impl is already optimized to constant-time, almost zero-overhead x86 assembly
int<->int, uint<->uint and float<->float comparisons only require upcasting, which is constant-time and fast too
only int/uint<->float is tricky

a subset of this proposal which doesn't include int/uint<->float comparisons could be posted

these problems already apply to soft-fpu configurations anyways

cross-type comparisons can be provided as regular non-operator functions by the standard library
"writing the comparison explicitly is simple enough" / "We already have Froms that makes conversions fairly easy"

this is a deceiving attitude because many comparison routines are unexpectedly non-trivial. I guess should have expanded on this in the RFC:
e.g. iN vs uN:

casting both to the largest signed integer doesn't work for i128 vs u128 and has suboptimal performance
casting uN to iN or iN to uN will wrap-around half the values, which is a subtle bug

e.g. float vs int:

casting float to int before comparing breaks for large floats that exceed int range: 1e30_f32 as u64 > u64::MAX wrongly returns false
casting int to float unnecessarily rounds the int and causes wrong results: (2_u64.pow(6) + 1) as f64 > 2_f64.powi(6) wrongly returns false
even if you have a correct solution; making it fast is a can of worms in itself

the correct solution requires in-depth knowledge of integer overflow and float rounding

As thomcc mentioned, the type interference issue make the RFC in its current form a non-starter. However, the issue remains that cross-type comparisons are deceptively simple, making people reach for incorrect ad-hoc implementations instead of depending on num-ord, thereby causing subtle correctness bugs.
Therefore, support for cross-type number comparisons should be "provided as regular non-operator functions by the standard library". Some ideas:

.comparable()/.cmp()/.orderable()/.ord() methods on numbers which returns a struct that can be compared against any other number
.compare_to() method on numbers which returns std::cmp::Ordering
new comparison trait

Should that new proposal happen in a new RFC, or ACP, or pre-RFC discussion on IRLO, or somewhere else?

Correct integer comparisons for anything fitting in 64 bits (which is almost always the case in practice) and without specific low-level requirements are easy to implement. Just cast everything to i128: i128::from(x) > i128::from(y). It's even likely that LLVM will output the optimal comparison anyway. i128 and u128 aren't that easy to compare, but their main use is precisely easy correct implementation of arithmetics on smaller integers.
For float to int comparison, it doesn't even make sense to say that one specific comparison is "correct". There are many more or less valid ways to compare, with no universal choice. If we round the float, do we round up, down, to zero or somehow else? If we cast an integer to float, how do we deal with the loss of precision? How should we represent a float if no exact representation is possible?
Various choices are possible, but the most important thing is to be explicit about the choice you make. For that reason I would be strongly against adding float-to-int comparison under any kind of generic nondescript function name. Certainly not a PartialEq impl, but a function name like compare_to is just as bad.
What is the use case where float-to-int comparisons would be common enough to warrant such ergonomic features?

x.into() == y doesn't work when one type is not a strict subset of the other

Correct integer comparisons for anything fitting in 64 bits (which is almost always the case in practice) and without specific low-level requirements are easy to implement. Just cast everything to i128: i128::from(x) > i128::from(y). It's even likely that LLVM will output the optimal comparison anyway. i128 and u128 aren't that easy to compare, but their main use is precisely easy correct implementation of arithmetics on smaller integers.

True, this is a simple solution, but: LLVM does not output the optimal comparison (5.1ns vs 5.4ns on my machine, see benchmark from RFC), and why should we not support comparing i128 with u128?

For float to int comparison, it doesn't even make sense to say that one specific comparison is "correct". There are many more or less valid ways to compare, with no universal choice. If we round the float, do we round up, down, to zero or somehow else? If we cast an integer to float, how do we deal with the loss of precision? How should we represent a float if no exact representation is possible?

We use the IEEE-754 specified exact mathematical value of the float and compare it against the mathematical value of the integer. Any rounding or casting of numbers is merely an implementation detail and does not affect semantics

1999999999_f32 ==<PHONE_NUMBER>_f32 is acceptable because float comparison clear indicates that it is not a full equivalence reason. But when I write something == int or int == something, whether this is a full equivalence would depend on the type of something, which is arguably confusing. (Of course, you can already implement a PartialEq<i32>, but it is probably confusing to users anyway)

But when I write something == int or int == something, whether this is a full equivalence would depend on the type of something, which is arguably confusing

Fair.
In any case, this wouldn't be a problem with explicit .comparable()/.cmp()/.orderable()/.ord() methods on numbers, since any gotchas could be extensively documented on the methods. To get back to this, what would be a better place to discuss this new idea (explicit ordering methods)? A pre-RFC discussion on IRLO, or a new ACP or RFC?

@kangalioo
Don't forget the most important question:

What is the use case where float-to-int comparisons would be common enough to warrant such ergonomic features?

If you're going to propose something that controversial, point №1 is to gather the evidence that there is indeed a real significant problem with downsides outweighing the ones in your proposal. You need to show some real-world projects where it's an issue, and not because they just messed up their type design.
I don't think this proposal can fly without such real-world data.

What is the use case where float-to-int comparisons would be common enough to warrant such ergonomic features?

Plenty can be found in grep.app by searching for e.g. as f64 > (try f32 or </== for more results).
These projects implement float<->int comparisons as utility functions and get it wrong:

This GUI code seems to compare mouse pointer coordinates (f64) to a known point on the screen (integer) and gets it wrong (although GUI projects don't have numbers in the range where float inaccuracies begin to show):

Next instance, although float inaccuracies won't show up here either because percentages are max 100:

This code checks if a point lies within a circle and is subject to float inaccuracies at coordinates beyond 94906265 (square root of dense float range end):

This code compares DNA-related usize's to a f64 threshold and is subject to float inaccuracies beyond<PHONE_NUMBER>740992:


Question: should we remove version_self

Should we remove this function? When I understand correctly it's only relevant for developers, not users. If we want the functionality to bump versions of python projects we should probably move it into your "bump-version-of-language" package, right? Suggestion: deprecate for now and remove when releasing v2.0 after the semester.

@mhuttner

Not worth the effort


Kubectl patch command for faster secret addition

Install method: Using helm
Platform: Openshift 4.10.30
CSI driver 1.3.0
This is not really a bug but we need some assistance in creating a kubectl/oc patch command to inject a new secret1 array objects into the existing yaml structure shown below for our automation whenever a new secret is added to Azure Key Vault:
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-test
  namespace: abc
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "false"
    userAssignedIdentityID: ""
    keyvaultName: "test-vault"
    objects: |
      array:
        - |
          objectName: secret1
          objectType: secret
          objectVersion: ""
    tenantId: "dxxxx"
  secretObjects:
    - secretName: secret1
      type: Opaque
      data:
        - objectName: secret1
          key: json

@aramase


Add Schema record

@jtbandes renamed to schema record

I've let this bake overnight and still feel like the more natural place for message_encoding is alongside the fields in the Schema record. Here's my thinking:
When an end user reader encounters a Message record, it will want to deserialize the message data into some object appropriate for language/environment. How's does it do that? It needs to know the message encoding and the schema. Those two bits of information describe how to decode a message. These two things are naturally related and should occur together to simplify reasoning about how one impacts the other.
Some questions:

Does protobuf message encoding imply a specific schema format? Its hard to imagine general purpose mcap readers where this isn't true? Maybe by mcap design its on the end-reader to enforce the pairing of message encoding+schema that the reader supports. In this case, these fields are still used together.
For ros1 message encoding, readers would "typically" need schemas in the .MSG format to decode the serialized messages.
CBOR and JSON message encoding are self-contained. They can be decoded without any schema - tho mcap still encourages (requires) a schema to aid in tooling making sense of the file. If you wanted to write cbor or json without a schema there other options.
For ros2 systems, the message encoding default is CDR and the schemas are in .MSG format. ROS2 allows for different message encodings, but its not so clear how this influences (or is influenced by the schema format used). i.e. if you wanted to use protobuf encoding with ros2 would you use .msg or re-write all your .msg files into .proto files?

After writing out the above, I'm starting to think schema_encoding actually dictates the range of allowed (expected?) message encodings. For example:

schema encoding jsonschema allows for message encoding of cbor and json
schema encoding proto allows for message encoding of proto
schema encoding ros1msg allows for message encoding of ros1
schema encoding ros2msg allows for message encoding of cdr

Would this prohibit using a ros1msg schema encoding and using proto or cbor message encoding? We don't have to "prohibit" it - but there's also some limit to how readers and writers are expected to inter-operate. Most message serialization formats I'm familiar with (which have an IDL) have a 1:1 relationship with their IDL. The tooling to decode uses the IDL to understand how to decode. cbor and json have no IDL, so we've flipped around the relationship of the schema encoding and message encoding - saying that jsonschema is a way of indicating cbor or json encoded messages. And for ros2, which claims to support many different encodings, today is practically .msg schema files with CDR encoded messages.

After writing out the above, I'm starting to think schema_encoding actually dictates the range of allowed (expected?) message encodings.

The relationship of encoding to schema is many to many: jsonschema and typeschema can both be used with cbor and json encoding respectively. Not all combinations are allowed, but I would argue the encoding defines supported schema types, not the other way around.
I think putting encoding inside Schema record is more confusing semantically than putting it inside ChannelInfo, especially when you consider that some encodings (cbor/bson/json) do not require a schema.
Encoding is a property of messages, and messages are contained within channels. Some encodings (ros1/cdr/proto) cannot be decoded without the schema, so we allow the channel to reference a Schema record (extracted to a dedicated record type only because of space savings). Other encodings (cbor/bson/json) do not require a schema, and I would argue that we should allow schema_id=0 (or a Schema with a name and no data) in that case to indicate no schema available.
Semantically, it is more sensible to ask "what is the encoding of this ChannelInfo" than to ask "what is the encoding of this Schema".


Use irc-message v3.0

Update dependencies
Change parseMessage to parse
Replace every parseHostmaskFromPrefix

This is just a temporary fix though. We really should replace lstream with irc-messages new createStream().
Maybe do this at the same time as #30 ?

Thank you for your PR!
Yes we should replace lstream; there are a lot of changes that we need to do with issue #30. The plan is to make it work with tags at any time and support TC1-4. Right now it supports all of them but TC1 is very limited because the messages from jtv aren't sent as private messages.

Has twitch client 4 been released?


Code::Stats don't track

When I use terminal vim it updates stats without any problem, but MacVim just don't seem to do anything, panel just keeps XP and that is all

What's Code::Stats? Is that https://codestats.net (from casual online search)? What does it do?

It is a plugin to track your coding stats in IDE's and editors. Separated by languages you use and experience you get by coding

https://gitlab.com/code-stats/code-stats-vim/issues/10
Here is about the error

This is the error

Closing this because this is an issue with the plugin. Discussions should be done there instead.


Underlying filesystem (NFS) errors cause bower to fail silently

When running bower install on a vagrant environment where the source directory was NFS mounted to the host, I consistently got an indeterminate set of packages left in an 'unpacked' state (e.g. I would see bower_components/angular/bower-angular-x.y.z). The exit code from bower install was zero.
Diagnosing the issue, I manually installed several bower components via the command line and came across the following error:
bower angular-mocks#*                     EBUSY EBUSY, unlink '/vagrant/myproject/.bower-tmp/angular-mocks-12849-Zdgw44/.nfs0000000003f3469600000015'

Stack trace:
Error: EBUSY, unlink '/vagrant/myproject/.bower-tmp/angular-mocks-12849-Zdgw44/.nfs0000000003f3469600000015'

Console trace:
Error
    at StandardRenderer.error (/usr/lib/node_modules/bower/lib/renderers/StandardRenderer.js:82:37)
    at Logger.<anonymous> (/usr/lib/node_modules/bower/bin/bower:110:22)
    at Logger.emit (events.js:95:17)
    at Logger.emit (/usr/lib/node_modules/bower/node_modules/bower-logger/lib/Logger.js:29:39)
    at /usr/lib/node_modules/bower/lib/commands/index.js:45:20
    at _rejected (/usr/lib/node_modules/bower/node_modules/q/q.js:844:24)
    at /usr/lib/node_modules/bower/node_modules/q/q.js:870:30
    at Promise.when (/usr/lib/node_modules/bower/node_modules/q/q.js:1122:31)
    at Promise.promise.promiseDispatch (/usr/lib/node_modules/bower/node_modules/q/q.js:788:41)
    at /usr/lib/node_modules/bower/node_modules/q/q.js:604:44
System info:
Bower version: 1.4.1
Node version: 0.10.39
OS: Linux 3.13.0-55-generic x64

After making sure that .bower-tmp, .bower-cache, and .bower-registry were no longer on an NFS-mounted directory, a regular bower install worked correctly.
So, it seems that "bower install" is not reporting underlying errors correctly, whereas "bower install [component...]" is.

Thanks for reporting this. I don't have time to fix this, but PR by anyone is welcome.

I experienced the same issue.  Our source directories have been mounted on NFS for a long time without issue.  A recent change on our servers set the TMP_DIR to a nfs mounted directory and this is when we started seeing issue.  Setting TMP_DIR back to the system's local storage fixed the issue.

Does Bower 1.5.x work for you? Could you post stack trace with --verbose flag on?

If I do bower cache clean, the first bower install results in the following error message:
bower angular-bootstrap#~0.13                         EBUSY EBUSY, unlink '/data_storage/linear/tmp/linear_frontend/bower/angular-bootstrap-22417-QrkxeU/.nfs000000001743a1e50000079f'

Stack trace:
Error: EBUSY, unlink '/data_storage/linear/tmp/linear_frontend/bower/angular-bootstrap-22417-QrkxeU/.nfs000000001743a1e50000079f'
From previous event:
    at PackageRepository._resolve (/usr/lib/node_modules/bower/lib/core/PackageRepository.js:185:6)
    at /usr/lib/node_modules/bower/lib/core/PackageRepository.js:77:29
From previous event:
    at /usr/lib/node_modules/bower/lib/core/PackageRepository.js:63:10
From previous event:
    at PackageRepository.fetch (/usr/lib/node_modules/bower/lib/core/PackageRepository.js:45:6)
    at Manager._fetch (/usr/lib/node_modules/bower/lib/core/Manager.js:299:51)
    at Array.forEach (native)
    at Manager.resolve (/usr/lib/node_modules/bower/lib/core/Manager.js:102:23)
    at Project._bootstrap (/usr/lib/node_modules/bower/lib/core/Project.js:542:6)
    at /usr/lib/node_modules/bower/lib/core/Project.js:79:21

Console trace:
Trace
    at StandardRenderer.error (/usr/lib/node_modules/bower/lib/renderers/StandardRenderer.js:82:17)
    at Logger.<anonymous> (/usr/lib/node_modules/bower/bin/bower:110:22)
    at Logger.emit (events.js:95:17)
    at Logger.emit (/usr/lib/node_modules/bower/node_modules/bower-logger/lib/Logger.js:29:39)
    at /usr/lib/node_modules/bower/lib/commands/index.js:40:20
    at _rejected (/usr/lib/node_modules/bower/node_modules/q/q.js:797:24)
    at /usr/lib/node_modules/bower/node_modules/q/q.js:823:30
    at Promise.when (/usr/lib/node_modules/bower/node_modules/q/q.js:1035:31)
    at Promise.promise.promiseDispatch (/usr/lib/node_modules/bower/node_modules/q/q.js:741:41)
    at /usr/lib/node_modules/bower/node_modules/q/q.js:557:44

System info:
Bower version: 1.3.12
Node version: 0.10.33
OS: Linux 2.6.32-504.3.3.el6.x86_64 x64

Then subsequent bower install runs yield no errors, but some of my dependencies are now inside the normal directory but a level deeper under a version number.
Ex: app/bower_components/angular-bootstrap/bootstrap-bower-0.13.4/ui-bootstrap.min.js
instead of just app/bower_components/angular-bootstrap/ui-bootstrap.min.js
I'll have to see if I can get the latest bower installed on this machine, do you suspect that this was fixed since 1.3.12?

1.6.3 has graceful-fs on all system calls so I suspect it should work for you both.
Please let me know if you still experience this error on newest ower

Given no feedback I guess it's fixed now. Anyway we'll update graceful-fs further to 4.x in next release


Non-docker runtime support?

Installed splunk otel via helm to an AWS EKS cluster with containerd runtime. No problems with the deployment, able to see some metrics on signalfx console (map, nodes, workloads). However there's no metrics in Node Details (not able to see CPU / Memory) and also no metrics in Workload Details (can only see some metrics on 'Pods by Phase' and all the pods, not able to see 'CPU% Pctile over Containers', 'Mem Usage Pctile', or 'Workload Events' / 'Workload Properties').
How do I configure the otel agent to work with non-docker (in this case containerd) runtime?
Logs:
2021/08/23 06:18:52 main.go:189: Set config to /conf/relay.yaml
2021/08/23 06:18:52 main.go:272: Set ballast to 165 MiB
2021/08/23 06:18:52 main.go:286: Set memory limit to 450 MiB
2021-08-23T06:18:52.978Z	info	service/collector.go:296	Starting otelcol...	 Begin running and processing data.
W0823 06:18:53.183508       1 warnings.go:70] batch/v1beta1 CronJob is deprecated in v1.21+, unavailable in v1.25+; use batch/v1 CronJob
W0823 06:18:53.582292       1 warnings.go:70] batch/v1beta1 CronJob is deprecated in v1.21+, unavailable in v1.25+; use batch/v1 CronJob
2021-08-23T06:18:53.676Z	info	k8sclusterreceiver@v0.31.0/receiver.go:80	Completed syncing shared informer caches.	{"kind": "receiver", "name": "k8s_cluster"}
W0823 06:26:00.392197       1 warnings.go:70] batch/v1beta1 CronJob is deprecated in v1.21+, unavailable in v1.25+; use batch/v1 CronJob
W0823 06:34:23.394843       1 warnings.go:70] batch/v1beta1 CronJob is deprecated in v1.21+, unavailable in v1.25+; use batch/v1 CronJob
W0823 06:44:15.398123       1 warnings.go:70] batch/v1beta1 CronJob is deprecated in v1.21+, unavailable in v1.25+; use batch/v1 CronJob
Kubectl version
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.0", GitCommit:"cb303e613a121a29364f75cc67d3d580833a7479", GitTreeState:"clean", BuildDate:"2021-04-08T21:15:16Z", GoVersion:"go1.16.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"21+", GitVersion:"v1.21.2-eks-0389ca3", GitCommit:"8a4e27b9d88142bbdd21b997b532eb6d493df6d2", GitTreeState:"clean", BuildDate:"2021-07-31T01:34:46Z", GoVersion:"go1.16.5", Compiler:"gc", Platform:"linux/amd64"}
Containerd version
containerd://1.4.6

Hi @dmitryax , can you please check if you can run this command ?
kubectl top nodes

Closing for inactivity. Please reopen if you see this issue is still happening.


useLogout(): doesn't log users out

Heyo...
the useLogout hook, as the title suggests, does not log users out.
The SHOP_TOKEN token is not removed, and thus the user remains logged in.

user error!

user error!


WIP: Faster listing of stake pools.

Issue Number
#2082 (Listing stake pools time grows when there are wallets syncing in background.)
Overview
This PR:

changes the implementation of ListStakePools to execute a small number of handwritten SQL queries with native joins, rather than issuing multiple queries and joining together the results in memory.

adds a new operation listPoolLifeCycleData. The SQLite implementation of this operation uses a single hand-optimized query to return lifecycle data for all pools.

Benefits

:heavy_check_mark: Reduced execution time
The time taken to execute ListStakePools is greatly reduced, even when there are multiple wallets syncing in the background.

No. of WalletsSyncing
Time Required(seconds)master
Time Required(seconds)more-efficient-list-pools

0
8
3

5
30
7

10
60
8

15
72
9

20
95
10

:heavy_check_mark: Fewer queries required
The number of select queries required for a single call to ListStakePools is greatly reduced.

Branch
Network
No. of Pools
No. of Queries

master
mainnet
1,124
12,365

more-efficient-list-pools
mainnet
1,124
4

Testing
This PR adds a property test for listPoolLifeCycleData, consisting of the following steps:

Add an arbitrary sequence of pool registration and retirement certificates to the database, for multiple pools.
Call listPoolLifeCycleData once to fetch lifecycle data for all active pools.
Call readPoolLifeCycleStatus multiple times, once for each known pool, and coalesce the results.
Test that the results returned in steps 2 and 3 are identical.

Notes
System used for Benchmarking
The system used for benchmarking (4 cores):
vendor_id       : GenuineIntel
cpu family      : 6
model           : 85
model name      : Intel(R) Xeon(R) CPU
stepping        : 7
microcode       : 0x1
cpu MHz         : 2800.176
cache size      : 33792 KB

bors try

bors try

bors try

bors try

bors try

bors cancel

bors try

bors try

bors cancel

bors try-

bors try

bors try

bors try

I'm not sure what the exact policies wrt committing are, but I feel 29 commits is a bit hard to follow and they should be squashed. After all, it's one atomic change with one topic. Cherry-picking, reverting, bisecting etc will become a lot harder with 29 commits that are inter-connected.

I'm not sure what the exact policies wrt committing are

I would say that we generally aim to make each commit satisfy the following properties:

each commit is an atomic change that does just one thing.
each commit compiles without errors or warnings.
each commit passes the test suite with 0 failures.

Collectively, the commits of PR must tell a coherent story that evolve the code from its initial state to the final state.

but I feel 29 commits is a bit hard to follow and they should be squashed. After all, it's one atomic change with one topic. Cherry-picking, reverting, bisecting etc will become a lot harder with 29 commits that are inter-connected.

In my experience, when we have discovered bugs not covered by an existing test suite, it's much easier to discover the source of the bug if commits are kept small and atomic. With the "one big commit" approach, it often takes quite a bit more effort to figure out where the error was introduced.
For this reason, I generally am not in favour of squashing PRs into single commits.
However, if you prefer to review code by viewing all commits squashed together, it's easy to do this with the Files Changed tab in GitHub.

each commit is an atomic change that does just one thing

Well, IMO, atomic doesn't mean small. Atomic means self-evident: the commit can be understood by itself by looking at the changes and the commit message. This isn't the case for most of the commits in this PR. It also doesn't mean a PR must consist of one commit only.
Tight logical dependencies between commits is a sign of non-atomicity.

In my experience, when we have discovered bugs not covered by an existing test suite, it's much easier to discover the source of the bug if commits are kept small and atomic.

To discover the source of bug you have to read further down the commit history to understand the context, even after you found the bad commit. Now you have to read 10+ commits and still won't know what it does.

Well, IMO, atomic doesn't mean small.

By an atomic commit, I mean that:

applying the commit will not break the build.
applying the commit will not cause the tests to fail (unless we are specifically introducing a failing test that will be fixed by a later commit).
the commit has just one purpose, which can be:

a refactoring, or
a behavioural change (but not both).

Typically, I prefer to keep refactorings and behavioural changes in separate commits, as described in this blog article.

Atomic means self-evident: the commit can be understood by itself by looking at the changes and the commit message. This isn't the case for most of the commits in this PR.

Can you give an example of a commit in this PR that cannot be understood by looking at the changes and the commit message?
I'd like to better understand your perspective.

By an atomic commit, I mean that:
applying the commit will not break the build.
applying the commit will not cause the tests to fail (unless we are purposefully introducing a failing test that will be fixed by a later commit).

I don't think either of these are a proper indicators of atomicity. You can write a single logical change in 200 commits without breaking the build or the tests.

the commit has just one purpose, which can be:
    a refactoring, or
    a behavioural change (but not both).

Yes, I believe this PR could have 2, maybe 3 commits due to this distinction.

Can you give an example of a commit in this PR that cannot be understood by looking at the changes and the commit message?

https://github.com/input-output-hk/cardano-wallet/pull/2111/commits/161068e76cef7563da09779d1a2f481ea635797b
A type was added to the test suite with an arbitrary instance. It's not self-evident why the type exist, what test it will be used for and why that test (that isn't in this commit) might even be interesting to have.
This is definitely not atomicity, IMO.

Yes, I believe this PR could have 2, maybe 3 commits due to this distinction.

In that case, I suspect we have very different philosophies about how to structure a PR into separate commits.
I'm happy to discuss the topic with you further, but could we discuss it over a call?
I'd very much like to keep the discussion for this PR focused on its content, rather than the general question about how to break up a PR into multiple commits. (There are clearly multiple schools of thought about how to do this.) I find written discussions can sometimes consume a lot of time, especially when parties have very different points of view to reconcile. I think a call would help us to reach a compromise more quickly.

A type was added to the test suite with an arbitrary instance. It's not self-evident why the type exist, what test it will be used for and why that test (that isn't in this commit) might even be interesting to have.

The MultiPoolCertificateSequence type will be used by two later commits:

8af20d89e733c0beaeb109ef0d96806703cb6af5: (Uses MultiPoolCertificateSequence to simplify a property.)
28e734cbe3a37cbe8af0abd6e0895b50aa932a65: (Uses MultiPoolCertificateSequence in a completely new property.)

I don't think these commits should be squashed together, as they have different purposes.
I would agree with you though that we could squash the following commits into a single commit:

161068e76cef7563da09779d1a2f481ea635797b (Add MultiPoolCertificateSequence type in test suite).
6c91f026b187e0f1b3e457eb845452ceed9785dd (Test generator coverage of MultiPoolCertificateSequence).

In that case, I suspect we have very different philosophies about how to structure a PR into separate commits.

Sure, I'm suspecting everyone is free to follow their own way of structuring commits then.

bors r+

bors r+


ci: manual releases

Move away from semantic release and use manual releases instead.

Codecov Report

Merging #194 (16e09e3) into master (7267397) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master      #194   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            2         4    +2
  Lines           63        73   +10
  Branches        13        12    -1
=========================================
+ Hits            63        73   +10

Impacted Files
Coverage Δ

src/index.ts
100.00% <0.00%> (ø)

src/utils.ts
100.00% <0.00%> (ø)

src/invariants.ts
100.00% <0.00%> (ø)

src/logger.ts
100.00% <0.00%> (ø)

Continue to review full report at Codecov.

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


Error: Non 5-bit word

After running npm start update-key and entering the 24-word bip39 mnemonic of the feeder account when prompted, I get the error
Error: Non 5-bit word
    at Object.encode (/home/aw/oracle-feeder/feeder/node_modules/bech32/dist/index.js:95:23)
    at MnemonicKey.get (/home/aw/oracle-feeder/feeder/node_modules/@terra-money/terra.js/src/key/Key.ts:50:19)
    at Object.save (/home/aw/oracle-feeder/feeder/src/keystore.ts:76:36)
    at updateKey (/home/aw/oracle-feeder/feeder/src/updateKey.ts:34:18)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at async main (/home/aw/oracle-feeder/feeder/src/index.ts:112:5)

I'm using commit https://github.com/terra-money/oracle-feeder/commit/dba87f762726a1a0c2d69076c08659e26c4677a8, node v14.19.3 and Ubuntu 20.04. Problem goes away on release v2.0.1
How can I fix this problem on my system? Thanks!

Hello @athenawisdoms, I assume the issue is not relevant anymore or you have upgraded the version of the oracle feeder. If the issue is not solved please open it again or if there is any other new issue I encourage you to open it again. Thanks!


Hope to provide an interface to modify the status of the debugging suspension bar

Is it possible to provide an interface to modify the status of the debugging suspension bar, and to modify the highlighting and graying capabilities of run, single-step and other buttons?

In certain scenarios, I hope that the run button can be grayed out, like the single-step run button.

I don't understand what you're asking for


Is there a way to declare the API key programmatically?

I don't want to expose my API key in the file config.xml because this file is public, and I want to use your Google Maps API for Android.
Is there a way to submit my key in the Javascript code?

No


Improve cacheability of facet requests

We compute facets by making JSON requests, one per each facet.
For example, faceting by creation_date and tags results in these two requests:
https://dux-demo.fly.dev/superuser/posts.json
  ?_sort=id
  &_facet_year=creation_date
  &_facet_array=tags
  &post_type__exact=question
  &_size=0
  &_nocount=1
  &_dux_facet=_facet_year           <--
  &_dux_facet_column=creation_date  <--

https://dux-demo.fly.dev/superuser/posts.json
  ?_sort=id
  &_facet_year=creation_date
  &_facet_array=tags
  &post_type__exact=question
  &_size=0
  &_nocount=1
  &_dux_facet=_facet_array <--
  &_dux_facet_column=tags  <--

Even though each request is only for a single facet, we include both _facet_year=creation_date and _facet_array=tags in both requests so that the URLs that get constructed are correct.
If you remove the creation_date facet, the request for the tags facet will have a different set of parameters:
https://dux-demo.fly.dev/superuser/posts.json
  ?_sort=id
  &_facet_array=tags
  &post_type__exact=question
  &_size=0
  &_nocount=1
  &_dux_facet=_facet_array
  &_dux_facet_column=tags

This means that even though we have a perfectly good cached response for this facet, we won't be able to use it.
A possible alternative would be to omit all _facet_* parameters except the facet under consideration, and then teach fixupToggleUrl how to re-add the other columns.
A good solution would also re-add the deleted parameters in the same location to ensure a high cache rate. This feels pretty involved for what is probably not that big of a problem.

Too fiddly for too small of a problem


missing key prop on the config object.

Following the instructions, i was getting this:
actions-on-google/dialogflow-name-psychic-nodejs/functions
> eslint --fix "**/*.js"

✔  functions: Finished running predeploy script.
i  functions: ensuring necessary APIs are enabled...
✔  functions: all necessary APIs are enabled
i  functions: preparing functions directory for uploading...

Error: Error occurred while parsing your function triggers.

TypeError: Cannot read property 'key' of undefined
    at Object.<anonymous> (/Users/baskint/src/actions-on-google/dialogflow-name-psychic-nodejs/functions/index.js:25:25)
    at Module._compile (module.js:660:30)
    at Object.Module._extensions..js (module.js:671:10)
    at Module.load (module.js:573:32)
    at tryModuleLoad (module.js:513:12)
    at Function.Module._load (module.js:505:3)
    at Module.require (module.js:604:17)
    at require (internal/module.js:11:18)
    at /usr/local/lib/node_modules/firebase-tools/lib/triggerParser.js:18:11
    at Object.<anonymous> (/usr/local/lib/node_modules/firebase-tools/lib/triggerParser.js:38:3)

Upon inspection, if we change the line 25 of functions/index.js file to this, we get our API key back.
  key: config.map.key
After this change, I was able to deploy the firebase function.
  functions: Finished running predeploy script.
i  functions: ensuring necessary APIs are enabled...
✔  functions: all necessary APIs are enabled
i  functions: preparing functions directory for uploading...
i  functions: packaged functions (42.29 KB) for uploading
✔  functions: functions folder uploaded successfully
i  functions: creating function namePsychic...
✔  functions[namePsychic]: Successful create operation.
Function URL (namePsychic): https://***

✔  Deploy complete!

Now test simulator is crapped out, but that is across all the Google Action projects. Oh well.

Can you clarify what you mean and where this stacktrace comes from?

This above stack trace was coming from the Chrome Dev console, but I cannot seem to regenerate it. There could be a few minutes of delay when the app is generated and test simulator is ready. I had observed this error on the test simulator as it is invoked a few seconds the app is created.
I am seeing the list of intents, and I cannot make sure what the last entry should be. I deleted and restored the intents from the ZIP file as instructed. Still seeing the last entry.

Yes, a brief delay in running may be required.
I am not sure what the last intent is either, probably something specific to a deep link "Talk to  about <something it doesn't recognize>"

After the post, I removed the above mentioned  unrecognized intent, reattached the fulfillment URL and the API endpoint. I have the app configured and working as expected. Closing issue.. Thank you.


Problem with focus/editing input

Hi, it's worked only first time when I write something into input and choose option.
On chrome / firefox OSX and ubuntu I'm not able to edit input..
Please help me.
I record video..  link (all the time I press buttons on keyboard)
My code:
'<ui-select on-select="to.onSelected($item)" ng-model="to.object[to.model]" theme="selectize" ng-disabled="to.disabled" reset-search-input="false" title="{{to.input.title}}">' +
            '<ui-select-match placeholder="{{to.input.placeholder}}">{{$select.selected.name}}</ui-select-match>'+
            '<ui-select-choices refresh="to.asyncDetailCollection($select.search)" repeat="option in to.options | filter: $select.search">

             </ui-select-choices>' +
          '</ui-select>'

I'm use ui-select with formly.
"angular-ui-select": "~0.13.2",
"angular-formly": "~7.1.2",
"angular-formly-templates-bootstrap": "~6.1.0",

I found solution. I removed theme='selectize'.


Implicit task dependencies for shared build services

One of the use-cases for a shared build service is to setup and tear down a server needed for testing only when the test task/s is/are going to be executed.
This often involves deploying of a build result that can then be tested by the test code.
Currently, as far as I have figured out, you need to configure an explicit task dependency from the test task to the producer task in Gradle 8.0.2.
If you have the following:
abstract class Producer : DefaultTask() {
    @get:OutputFile
    abstract val output: RegularFileProperty

    @TaskAction
    fun produce() {
        output.get().asFile.writeText("FOO")
    }
}

val producer by tasks.registering(Producer::class) {
    output.set(layout.buildDirectory.file("foo"))
}

abstract class DeployingService : BuildService<DeployingService.Params> {
    interface Params : BuildServiceParameters {
        val deployable: RegularFileProperty
    }

    @get:InputFile
    val deployable = parameters.deployable
}

abstract class IntegTest : DefaultTask() {
    @get:Nested
    abstract val deployingService: Property<DeployingService>

    @TaskAction
    fun test() {
        println(deployingService.get().deployable.get().asFile.readText())
    }
}

val deployingServiceProvider = gradle.sharedServices.registerIfAbsent("deployingService", DeployingService::class) {
    parameters.deployable.set(producer.flatMap { it.output })
}

val integTest by tasks.registering(IntegTest::class) {
    usesService(deployingServiceProvider)
    deployingService.set(deployingServiceProvider)
}

Then it would be nice if calling gw integTest would automatically run producer first.
Currently if the output file is not present, the task complains as the file is missing.
If the output file is already present, it works and does not give a warning about missing task dependency (will create a separate issue for that).
If you add an explicit dependsOn(producer) to the integTest task it works as intended, but it would be nice if it worked without.

Thank you for your interest in Gradle!
This issue will be closed as a duplicate of

#21599

Please add your use case and 👍 to that issue.


Investigate why the out-file test is failing on AppVeyor

It doesn't fail locally so it's a bit hard to reproduce exactly what's going on.

There is a way to rdp to the worker machine: https://github.com/appveyor/ci/blob/master/scripts/enable-rdp.ps1

Fixed. There were two issues at play - first, a new version of pester started asking for encoding when comparing file contents, which the provider didn't support. Second, intermittent failures were caused due to github API propagation delay, so the test which did multiple dependent actions how has a delay, which has made it more consistently pass.


Fixed incorrect string test

An incorrect order of state.ResumeTiming() and state.PauseTiming() calls designed to exclude the std::array's destructor calls from benchmark actually caused the test to crash, since benchmark code calls PauseTiming() which asserts that timing isn't paused (which fails) in the != operator when finishing the iteration over state (see State::FinishKeepRunning() and StateIterator::operator!= in benchmark.cc and .h)
I propose to move the allocation and destruction of the arrays outside the cycle and use the pause functionality to reset the array and destroy copied strings.
I hereby agree to the terms of the CLA available at: link.

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/
recheck

recheck

recheck

recheck

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/

recheck

I've tried my best.

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/

recheck


SR-3359: Add a fix-it to remove @discardableresult on functions that return void

This commit adds a fix-it to remove @discardableresult on functions that return void. The fix-it is at the warning level. A test was added to verify that the fix-it removes the @discardableresult. This issue was reported in SR-3359:
https://bugs.swift.org/browse/SR-3359
Changes:
TypeCheckDecl.cpp: Added a test to add a fix-it for an @discardableresult declared on functions that return void.
DiagnosticsSema.def: Added a warning with a diagnostic message.
LoggingWrappers.swift.gyb, HashedCollections.swift.gyb: Removed @discardableresult on functions that return void.
fixits-apply-all.swift, fixits-apply-all.swift.result: Added a test to verify that @discardableresult is removed from a function that returns void.

@swift-ci Please smoke test

While you're at it, wouldn't it be wise to do the same for functions that return Never (or in fact, any uninhabited enum, since the core team has apparently decided that Never should work like any other uninhabited enum)?

This looks great, Matthew! I agree with Xiaodi's comments here both on diagnostic phrasing and on supporting Never as well. Mind making those changes?

I wonder if this wouldn't be more appropriate as part of the EarlyAttributeChecker visitor.

Thanks @jrose-apple!
Thanks for your comments @xwu. I'll make the changes you suggested.

Ah, IIRC EarlyAttributeChecker runs before things have even been type-checked, so we can't do it there.

…but it might make sense in the regular AttributeChecker, so the point is valid anyway!

Jordan and Robert,
I left the test for @discardableResult on functions returning Void or Never in validateAttributes. It seems like a good place for it to me since @objc and @nonobjc declared on functions are handled there. But I'm happy to move it. Just let me know.
Thanks!
Matthew

I think validateAttributes is for attributes that have to be resolved even when the declarations are only being used (perhaps from another file), rather than diagnosed only in the file that declared them. That makes AttributeChecker a better choice for this new diagnostic.
(I should beef up the doc comment to explain that.)

I moved the diagnostic into AttributeChecker::visitDiscardableResultAttr, and squashed the commits into d2f9768.

Looks good to me! @xwu, any remaining comments?
@swift-ci Please smoke test

No other comments--looks good!

Thanks, Matthew!


How do I know if mxnet was compiled with USE_CUDA=1 ?

I'm working on a remote cluster environment where mxnet is installed but not by me.
This page says it will only work with CUDA if it was compiled accordingly:
https://github.com/dmlc/mxnet/blob/master/docs/how_to/multi_devices.md
Is there a way I can check if my version of mxnet was compiled with USE_CUDA=1?

ldd libmxnet.so to see if there is a link to cuda.so like
inux-vdso.so.1 =>  (0x00007ffc420c3000)
	/lib64/libharfbuzz.so (0x00007fe736167000)
	libcudart.so.7.5 => /usr/local/cuda/lib64/libcudart.so.7.5 (0x00007fe735f09000)
	libcublas.so.7.5 => /usr/local/cuda/lib64/libcublas.so.7.5 (0x00007fe73462a000)
	libcurand.so.7.5 => /usr/local/cuda/lib64/libcurand.so.7.5 (0x00007fe730dc1000)
	libopenblas.so.0 => /lib64/libopenblas.so.0 (0x00007fe72e9ab000)
...

mxnet/make/config.mk

Thank you both.
It could make a nice feature to have this available programatically, i.e.
>>> mxnet.using_cuda
True # or False

This issue is closed due to lack of activity in the last 90 days. Feel free to reopen if this is still an active issue. Thanks!


Multithreaded + Optimization + GPU for Footfall AI

Code refactoring for:

Deleted extra containers for imageprocessing and imageserver
Move everything into single container
Used Flask source_url method for rendering video
Added GPU+CUDA support
Remove OpenVino engine, use ultralytics directly
Multithreaded optimization
Separate video capture thread to main flask thread
Updated dependencies

@dkirby-ms  yes - Waiting to finish code to publish the new Dockerfile with golden images


README links are broken

Hi, just wanted to point out that the links in the items 1, 2 and 3 of the README are 404ing (not sure if broken or private, anyway).

Thank you for reporting this. Should be fixed now.


Clunk Control.

It'd be really great if you use the Accelerometer and Gyroscope to swipe between the views with just a Clunk or a slight jerk. I've written a very nice wrapper around CoreMotion Framework too.
https://github.com/MHaroonBaig/MotionKit

I appreciate the suggestion, but I'm not sure if people will appreciate that, especially because there are a few cocoa pod users (who will automatically get the update). It seems like an entirely different repo!


Change the IConnection contract to be an IDuplexPipe

This is a design change that we considered in the past but moved away from while we were discussiong messaging vs streams. We're firmly in the streams camp now so I think we should make this change (it also cleans and a bunch of things and introduces problems 😄 ).

The IConnection implements IDuplexPipe, it's a very simple contract, the IConnection is responsible for writing to the IDuplex pipe that is exposed.
We already changed the HttpConnection to use pipelines internal so the change there was deleting code.
This change is also required to support SignalR on top of TCP.
The server and client dispatching loop look more similar.
We were able to remove all callback handling from this layer.
The event queue is gone, the pipe is single producer and single consumer. The hub connection layer is the only one that has to implement callbacks.
With this change we don't allow running client callbacks in parallel (not sure why we even bothered before) so we were able to remove the event queue.

Quirks:

Completing the pipe is messy, do we still need StopAsync and DisposeAsync?
Who is responsible for completing the PipeReader and PipeWriter exposed by the connection? At a minimum the IConnection impl needs to complete the application sides.
~No errors if the you write to the connection before it starts or after it is disposed. This is possible but requires wrapping the PipeReader and PipeWriter returned.~ (solved)
~The current implementation gives you a null pipe if you you don't call Start first, this can be fixed by making a wrapping PipeWriter and PipeReader.~ (solved)
IConnection.DisposeAsync doesn't own the receive loop anymore so it returns before the loop ended. This might be fixable if we hook the right events. This also makes it hard to reuse pipes.(not solved)
Today we have an ill defined contract as to which part of the client is reusable, is that part of the IConnection contract? This might make that a bit tricker.

Today we have an ill defined contract as to which part of the client is reusable, is that part of the IConnection contract? This might make that a bit tricker.

I wonder if maybe IConnection should be non-restartable and we move the restart logic to HubConnection. After all, the main reason is to keep Hub callbacks bound. It would mean HubConnection needs an IConnection-factory rather than an IConnection but I think that's cleaner. It also means the pipelines, transports, etc. all just get dumped when a reconnect happens.

Agree @anurse but not as part of this change. It also means your paying for negotiation each time. But maybe that’s ok.

It also means your paying for negotiation each time

Only for WebSockets, for the other transports you have to pay that cost on reconnect anyway. In theory we could try to detect that WebSockets worked and just do a bare WebSocket connection on reconnect, but that would make transport fallback on reconnect tricky. I think the cost is minimal and acceptable.

https://github.com/aspnet/SignalR/issues/1450

I'll be back with something else


Fix/credit card type is ignored

Description
When using random card number or card number which is preMasked and manually setting creditTypeCard, the creditTypeCard is ignored and no credit card provider logo is shown.
Checklist

[ ] I have updated the package version number in pubspec.yaml and README.md.
[ ] I have updated the CHANGELOG.md with a brief description of my changes.
[ ] I have updated the README.md documentation to reflect my changes.
[ ] I have updated any images in README.md that need to be changed.
[x] My code follows the code style of this project.
[x] I have run the tests and they all pass locally.

Screenshots (if appropriate)

Before
After

@ksochacki123  I have a card detection logic, if credit card is null, it should determine from the card
Ideally 1234 **** **** 5678 is not a valid credit card.
Example—
Visa: Starts with 4.
MasterCard: Starts with numbers between 51 and 55 or 2221 to 2720.
American Express: Starts with 34 or 37.
Discover: Starts with 6011, 622126–622925, 644–649, or 65.

So to me, starting with 1234 won't show any credit card logo unless you set it, i think the logic is still correct, let me know if your thinking is different, otherwise we can close this PR, thanks.


kde: cleanup from closure-size merge

Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

cc: @ttuegel

cc @ttuegel for being kde maintainer.


Incorrect link when making new PRs

When making a PR there is a link to the following as ex-require:
https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/keyboard.py#L16
It should be line 14:
https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/keyboard.py#L14

Thanks! 🐬 🍪 💯


Make traits like StringOrFunction public

It would be good to either make them public or improve the documentation everywhere they are used, so that you can have a quick look on what actually are the restrictions on the function e.g. here: https://docs.rs/nvim-oxi/latest/nvim_oxi/api/fn.create_user_command.html where you cannot click on StringOrFunction.

I agree we should expand the documentation but I'd leave them private for now.


Refactor indexing/docs/article

Should fix this error:
ERR [Extension Host] Error converting URL to article components TypeError: Invalid host defined options
    at stringToArticle (/.vscode/extensions/continue.continue-0.9.91-darwin-arm64/out/extension.js:210618:23)
    at pageToArticle (/.vscode/extensions/continue.continue-0.9.91-darwin-arm64/out/extension.js:210639:12)
    at indexDocs (/.vscode/extensions/continue.continue-0.9.91-darwin-arm64/out/extension.js:210671:27)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async /.vscode/extensions/continue.continue-0.9.91-darwin-arm64/out/extension.js:211179:32

There were await imports that remain untranspiled to the CommonJS stile.
Here is why: https://github.com/evanw/esbuild/issues/1540
So there were ES module imports in a CommonJS environment.

@germankrause any chance you could change the base branch of this PR to preview instead of main? I think it looks good and want to merge, but to be safe it should go through preview (and therefore pre-release) first.

Thank you @germankrause !


Investigate why ELK stack crashed

Today only the container docker-elk_logspout_1 was running though it was constantly restarting. The three containers listed below were stopped.

docker-elk_logstash_1
docker-elk_kibana_1
docker-elk_elasticsearch_1

I run docker-compose stop followed by docker-compose up. The above three containers were then running but docker-elk_logspout_1 was still restarting. A couple of hours later (now), docker-elk_logspout_1 seems to be running fine.
Task

Collect information on what happened.

When did ELK stopped: Aug 06 06:34:19

Consider monitoring specific log messages using CloudWatch.
Consider exporting docker logs to syslog, then to ELK (see https://devconnected.com/docker-logs-complete-guide/).

Kernel logs are being flooded with the following messages.
Note: I have currently the same issue with a personal project where I'm running a stack with docker-compose.
$ sudo cat /var/log/kern.log
Aug 10 18:40:43 ip-10-255-21-47 kernel: [7033680.045360] br-3563230c915f: port 1(veth57e5ce0) entered disabled state
Aug 10 18:40:43 ip-10-255-21-47 kernel: [7033680.045433] device veth57e5ce0 entered promiscuous mode
Aug 10 18:40:43 ip-10-255-21-47 kernel: [7033680.365546] eth0: renamed from veth8e92727
Aug 10 18:40:43 ip-10-255-21-47 kernel: [7033680.381452] IPv6: ADDRCONF(NETDEV_CHANGE): veth57e5ce0: link becomes ready
Aug 10 18:40:43 ip-10-255-21-47 kernel: [7033680.381537] br-3563230c915f: port 1(veth57e5ce0) entered blocking state
Aug 10 18:40:43 ip-10-255-21-47 kernel: [7033680.381539] br-3563230c915f: port 1(veth57e5ce0) entered forwarding state
Aug 10 18:40:48 ip-10-255-21-47 kernel: [7033685.481871] br-3563230c915f: port 1(veth57e5ce0) entered disabled state
Aug 10 18:40:48 ip-10-255-21-47 kernel: [7033685.481968] veth8e92727: renamed from eth0
Aug 10 18:40:48 ip-10-255-21-47 kernel: [7033685.519298] br-3563230c915f: port 1(veth57e5ce0) entered disabled state
Aug 10 18:40:48 ip-10-255-21-47 kernel: [7033685.524291] device veth57e5ce0 left promiscuous mode
Aug 10 18:40:48 ip-10-255-21-47 kernel: [7033685.524295] br-3563230c915f: port 1(veth57e5ce0) entered disabled state
Aug 10 18:41:20 ip-10-255-21-47 kernel: [7033716.737296] br-3563230c915f: port 1(veth06320fa) entered blocking state
Aug 10 18:41:20 ip-10-255-21-47 kernel: [7033716.737298] br-3563230c915f: port 1(veth06320fa) entered disabled state
Aug 10 18:41:20 ip-10-255-21-47 kernel: [7033716.737376] device veth06320fa entered promiscuous mode
Aug 10 18:41:20 ip-10-255-21-47 kernel: [7033717.115059] eth0: renamed from vethf25aa97
Aug 10 18:41:20 ip-10-255-21-47 kernel: [7033717.130071] IPv6: ADDRCONF(NETDEV_CHANGE): veth06320fa: link becomes ready
Aug 10 18:41:20 ip-10-255-21-47 kernel: [7033717.130146] br-3563230c915f: port 1(veth06320fa) entered blocking state
Aug 10 18:41:20 ip-10-255-21-47 kernel: [7033717.130148] br-3563230c915f: port 1(veth06320fa) entered forwarding state
Aug 10 18:41:20 ip-10-255-21-47 kernel: [7033717.196003] br-3563230c915f: port 2(veth387fab8) entered blocking state
Aug 10 18:41:20 ip-10-255-21-47 kernel: [7033717.196006] br-3563230c915f: port 2(veth387fab8) entered disabled state
Aug 10 18:41:20 ip-10-255-21-47 kernel: [7033717.196128] device veth387fab8 entered promiscuous mode
Aug 10 18:41:20 ip-10-255-21-47 kernel: [7033717.196349] br-3563230c915f: port 2(veth387fab8) entered blocking state
Aug 10 18:41:20 ip-10-255-21-47 kernel: [7033717.196350] br-3563230c915f: port 2(veth387fab8) entered forwarding state
Aug 10 18:41:20 ip-10-255-21-47 kernel: [7033717.411681] br-3563230c915f: port 3(vethb438dc0) entered blocking state
Aug 10 18:41:20 ip-10-255-21-47 kernel: [7033717.411683] br-3563230c915f: port 3(vethb438dc0) entered disabled state
Aug 10 18:41:20 ip-10-255-21-47 kernel: [7033717.411747] device vethb438dc0 entered promiscuous mode
Aug 10 18:41:20 ip-10-255-21-47 kernel: [7033717.411834] br-3563230c915f: port 3(vethb438dc0) entered blocking state
Aug 10 18:41:20 ip-10-255-21-47 kernel: [7033717.411836] br-3563230c915f: port 3(vethb438dc0) entered forwarding state
Aug 10 18:41:21 ip-10-255-21-47 kernel: [7033717.724602] eth0: renamed from veth6614e9f
Aug 10 18:41:21 ip-10-255-21-47 kernel: [7033717.738921] br-3563230c915f: port 2(veth387fab8) entered disabled state
Aug 10 18:41:21 ip-10-255-21-47 kernel: [7033717.739036] br-3563230c915f: port 3(vethb438dc0) entered disabled state
Aug 10 18:41:21 ip-10-255-21-47 kernel: [7033717.740785] IPv6: ADDRCONF(NETDEV_CHANGE): veth387fab8: link becomes ready
Aug 10 18:41:21 ip-10-255-21-47 kernel: [7033717.740836] br-3563230c915f: port 2(veth387fab8) entered blocking state
Aug 10 18:41:21 ip-10-255-21-47 kernel: [7033717.740838] br-3563230c915f: port 2(veth387fab8) entered forwarding state
Aug 10 18:41:21 ip-10-255-21-47 kernel: [7033717.943298] eth0: renamed from vethf4ab668
Aug 10 18:41:21 ip-10-255-21-47 kernel: [7033717.966464] IPv6: ADDRCONF(NETDEV_CHANGE): vethb438dc0: link becomes ready
Aug 10 18:41:21 ip-10-255-21-47 kernel: [7033717.966538] br-3563230c915f: port 3(vethb438dc0) entered blocking state
Aug 10 18:41:21 ip-10-255-21-47 kernel: [7033717.966540] br-3563230c915f: port 3(vethb438dc0) entered forwarding state
Aug 10 18:41:48 ip-10-255-21-47 kernel: [7033745.478319] br-3563230c915f: port 4(veth66a7447) entered blocking state
Aug 10 18:41:48 ip-10-255-21-47 kernel: [7033745.478321] br-3563230c915f: port 4(veth66a7447) entered disabled state
Aug 10 18:41:48 ip-10-255-21-47 kernel: [7033745.478388] device veth66a7447 entered promiscuous mode
Aug 10 18:41:48 ip-10-255-21-47 kernel: [7033745.478468] br-3563230c915f: port 4(veth66a7447) entered blocking state
Aug 10 18:41:48 ip-10-255-21-47 kernel: [7033745.478470] br-3563230c915f: port 4(veth66a7447) entered forwarding state
Aug 10 18:41:48 ip-10-255-21-47 kernel: [7033745.478801] br-3563230c915f: port 4(veth66a7447) entered disabled state
Aug 10 18:41:49 ip-10-255-21-47 kernel: [7033746.041035] eth0: renamed from veth30a2e5f
Aug 10 18:41:49 ip-10-255-21-47 kernel: [7033746.055140] IPv6: ADDRCONF(NETDEV_CHANGE): veth66a7447: link becomes ready
Aug 10 18:41:49 ip-10-255-21-47 kernel: [7033746.055208] br-3563230c915f: port 4(veth66a7447) entered blocking state
Aug 10 18:41:49 ip-10-255-21-47 kernel: [7033746.055211] br-3563230c915f: port 4(veth66a7447) entered forwarding state
Aug 10 18:41:49 ip-10-255-21-47 kernel: [7033746.324061] br-3563230c915f: port 4(veth66a7447) entered disabled state
Aug 10 18:41:49 ip-10-255-21-47 kernel: [7033746.325787] veth30a2e5f: renamed from eth0
Aug 10 18:41:49 ip-10-255-21-47 kernel: [7033746.375076] br-3563230c915f: port 4(veth66a7447) entered disabled state
Aug 10 18:41:49 ip-10-255-21-47 kernel: [7033746.379709] device veth66a7447 left promiscuous mode
Aug 10 18:41:49 ip-10-255-21-47 kernel: [7033746.379713] br-3563230c915f: port 4(veth66a7447) entered disabled state
Aug 10 18:42:49 ip-10-255-21-47 kernel: [7033806.326297] br-3563230c915f: port 4(veth76b4d20) entered blocking state
Aug 10 18:42:49 ip-10-255-21-47 kernel: [7033806.326300] br-3563230c915f: port 4(veth76b4d20) entered disabled state
Aug 10 18:42:49 ip-10-255-21-47 kernel: [7033806.326361] device veth76b4d20 entered promiscuous mode
Aug 10 18:42:49 ip-10-255-21-47 kernel: [7033806.326432] br-3563230c915f: port 4(veth76b4d20) entered blocking state
Aug 10 18:42:49 ip-10-255-21-47 kernel: [7033806.326433] br-3563230c915f: port 4(veth76b4d20) entered forwarding state
Aug 10 18:42:49 ip-10-255-21-47 kernel: [7033806.327497] br-3563230c915f: port 4(veth76b4d20) entered disabled state
Aug 10 18:42:50 ip-10-255-21-47 kernel: [7033806.651766] eth0: renamed from veth878d8a8
Aug 10 18:42:50 ip-10-255-21-47 kernel: [7033806.679912] IPv6: ADDRCONF(NETDEV_CHANGE): veth76b4d20: link becomes ready
Aug 10 18:42:50 ip-10-255-21-47 kernel: [7033806.679988] br-3563230c915f: port 4(veth76b4d20) entered blocking state
Aug 10 18:42:50 ip-10-255-21-47 kernel: [7033806.679990] br-3563230c915f: port 4(veth76b4d20) entered forwarding state

Trying to look at the log of the three main container but they are cropped to today when I (re)started them.
docker logs --since 2021-08-05 docker-elk_logstash_1

The logs of the container docker-elk_logspout_1 are crowded with repetition of an error. Interestingly, these errors stopped at he same time the repeating messages stopped in /var/log/kern.log.
$ docker logs --since 2021-08-05 docker-elk_logspout_1
2021/08/10 18:34:11 persist:/mnt/routes
2021/08/10 18:34:16 !! lookup logstash: Try again
2021/08/10 18:35:16 # logspout v3.2.13-custom by gliderlabs
2021/08/10 18:35:16 # adapters: logstash raw tcp udp
2021/08/10 18:35:16 # options :
2021/08/10 18:35:16 persist:/mnt/routes
2021/08/10 18:35:21 !! lookup logstash: Try again
2021/08/10 18:36:22 # logspout v3.2.13-custom by gliderlabs
2021/08/10 18:36:22 # adapters: raw tcp udp logstash
2021/08/10 18:36:22 # options :
2021/08/10 18:36:22 persist:/mnt/routes
2021/08/10 18:36:27 !! lookup logstash: Try again
2021/08/10 18:37:27 # logspout v3.2.13-custom by gliderlabs
2021/08/10 18:37:27 # adapters: raw tcp udp logstash
2021/08/10 18:37:27 # options :
2021/08/10 18:37:27 persist:/mnt/routes
2021/08/10 18:37:32 !! lookup logstash: Try again
2021/08/10 18:38:33 # logspout v3.2.13-custom by gliderlabs
2021/08/10 18:38:33 # adapters: logstash raw tcp udp
2021/08/10 18:38:33 # options :
2021/08/10 18:38:33 persist:/mnt/routes
2021/08/10 18:38:38 !! lookup logstash: Try again
2021/08/10 18:39:38 # logspout v3.2.13-custom by gliderlabs
2021/08/10 18:39:38 # adapters: logstash raw tcp udp
2021/08/10 18:39:38 # options :
2021/08/10 18:39:38 persist:/mnt/routes
2021/08/10 18:39:43 !! lookup logstash: Try again
2021/08/10 18:40:43 # logspout v3.2.13-custom by gliderlabs
2021/08/10 18:40:43 # adapters: raw tcp udp logstash
2021/08/10 18:40:43 # options :
2021/08/10 18:40:43 persist:/mnt/routes
2021/08/10 18:40:48 !! lookup logstash: Try again
2021/08/10 18:41:49 # logspout v3.2.13-custom by gliderlabs
2021/08/10 18:41:49 # adapters: udp logstash raw tcp
2021/08/10 18:41:49 # options :
2021/08/10 18:41:49 persist:/mnt/routes
#   ADAPTER     ADDRESS         CONTAINERS      SOURCES OPTIONS
#   logstash    logstash:5000                           map[]
2021/08/10 18:41:49 # jobs    : pump routes http[health]:80
2021/08/10 18:41:49 # routes  :
2021/08/10 18:41:49 logstash: could not write:write udp <IP_ADDRESS>:55326-><IP_ADDRESS>:5000: write: connection refused
2021/08/10 18:42:50 # logspout v3.2.13-custom by gliderlabs
2021/08/10 18:42:50 # adapters: raw tcp udp logstash
2021/08/10 18:42:50 # options :
2021/08/10 18:42:50 persist:/mnt/routes
2021/08/10 18:42:50 # jobs    : http[health]:80 pump routes
2021/08/10 18:42:50 # routes  :
#   ADAPTER     ADDRESS         CONTAINERS      SOURCES OPTIONS
#   logstash    logstash:5000                           map[]

Using an approach like below could prevent the loss of container logs:
docker run --log-driver=syslog
    --log-opt syslog-address=udp://logsN.papertrailapp.com:XXXXX
    image-name

The ELK stack stopped on Aug 06 06:34:19 as shown by the docker logs. Before that the last docker logs happened on Jul 21 06:26:58.
$ sudo journalctl -u docker.service | less
Jul 21 06:26:54 ip-10-255-21-47 dockerd[23615]: time="2021-07-21T06:26:54.312597722Z" level=info msg="Waiting for containerd to be ready to restart event processing" module=libcontainerd namespace=moby
Jul 21 06:26:55 ip-10-255-21-47 dockerd[23615]: time="2021-07-21T06:26:55.312429578Z" level=warning msg="grpc: addrConn.createTransport failed to connect to {unix:///run/containerd/containerd.sock  <nil> 0 <nil>}. Err :connection error: desc = \"transport: Error while dialing dial unix:///run/containerd/containerd.sock: timeout\". Reconnecting..." module=grpc
Jul 21 06:26:55 ip-10-255-21-47 dockerd[23615]: time="2021-07-21T06:26:55.312564297Z" level=warning msg="grpc: addrConn.createTransport failed to connect to {unix:///run/containerd/containerd.sock  <nil> 0 <nil>}. Err :connection error: desc = \"transport: Error while dialing dial unix:///run/containerd/containerd.sock: timeout\". Reconnecting..." module=grpc
Jul 21 06:26:57 ip-10-255-21-47 dockerd[23615]: time="2021-07-21T06:26:57.647921388Z" level=warning msg="grpc: addrConn.createTransport failed to connect to {unix:///run/containerd/containerd.sock  <nil> 0 <nil>}. Err :connection error: desc = \"transport: Error while dialing dial unix:///run/containerd/containerd.sock: timeout\". Reconnecting..." module=grpc
Jul 21 06:26:58 ip-10-255-21-47 dockerd[23615]: time="2021-07-21T06:26:58.158405264Z" level=warning msg="grpc: addrConn.createTransport failed to connect to {unix:///run/containerd/containerd.sock  <nil> 0 <nil>}. Err :connection error: desc = \"transport: Error while dialing dial unix:///run/containerd/containerd.sock: timeout\". Reconnecting..." module=grpc
Aug 06 06:34:19 ip-10-255-21-47 systemd[1]: Stopping Docker Application Container Engine...

Aug 06 06:34:29 ip-10-255-21-47 systemd[1]: Starting Docker Application Container Engine...

Docker populates /etc/resolv.conf by copying the host's /etc/resolv.conf, and filtering out any local nameservers such as <IP_ADDRESS>. If there are no nameservers left after that, Docker will add Google's public DNS servers (<IP_ADDRESS> and <IP_ADDRESS>).

Source: https://stackoverflow.com/a/39400887

Add non-local DNS servers to resolved
Edit /etc/systemd/resolved.conf to include non-local DNS servers (here Google DNS):
[Resolve]
DNS=<IP_ADDRESS> <IP_ADDRESS> 2001:4860:4860::8888 2001:4860:4860::8844

Don't forget to reload configuration and to restart services:
$ sudo systemctl daemon-reload
$ sudo systemctl restart systemd-networkd
$ sudo systemctl restart systemd-resolved

Source: https://unix.stackexchange.com/a/442599

Why does the container logspout keep restarting?
From the container logs:
2021/08/10 22:41:31 !! lookup logstash on <IP_ADDRESS>:53: no such host
2021/08/10 22:41:44 # logspout v3.2.13-custom by gliderlabs
2021/08/10 22:41:44 # adapters: udp logstash raw tcp
2021/08/10 22:41:44 # options :
2021/08/10 22:41:44 persist:/mnt/routes

@thomasyu888 Do you have an idea on why the ELK stack stopped on Aug 06 06:34:19?

Conclusion

We have not identified why the ELK stack stopped on Aug 06 06:34:19.
We have added two non-local DNS servers to systemd-resolved to prevent a message from repeating in docker daemon logs.
The container logspout was restarting in loop because it depends on the ELK network/containers, which were down at the time.
The CloudWatch agent is now collecting logs, hopefully we will have more information available next time the ELK stack stop.
The repeating log messages similar to br-3563230c915f: port 3(vethb438dc0) entered blocking stat are still a mystery.


KMS Key creation fails when entering "application_account_numbers = [""]

Describe the bug
KMS Key creation fails when entering "application_account_numbers = [""]
To Reproduce

Fill out application_account_numbers = [""] in main.tf of day0 mgmt AWS Ramppak
Terraform apply

Expected behavior
KMS Key creation success
Screenshots
│ Error: creating KMS Key: operation error KMS: CreateKey, https response error StatusCode: 400, RequestID: 904f66d0-65dc-4319-b2ef-96c94b9b0046, MalformedPolicyDocumentException: Policy contains a statement with one or more invalid principals.
│
│  with module.account-setup.module.config_kms_key[0].aws_kms_key.kms_key,
│  on .terraform/modules/account-setup.config_kms_key/main.tf line 1, in resource "aws_kms_key" "kms_key":
│   1: resource "aws_kms_key" "kms_key" {

Additional context
If you remove the quotes, and do it like this application_account_numbers = [] it will work but cause issues with bucket policies

Opened a PR to be reviewed to address this issue. Tested successfully in Coalfire GovCloud sandbox environment. Related PR also open for terraform-aws-securitycore module to address bucket policy creation for s3-tstate based on list of app account numbers.


mediapipe conversion

Hello,
I need to use these libraries in my python scripts but they are written in C++ and provided for JS.
https://blog.tensorflow.org/2020/11/iris-landmark-tracking-in-browser-with-MediaPipe-and-TensorFlowJS.html
https://google.github.io/mediapipe/solutions/face_mesh
https://github.com/vladmandic/human
Can I convert them to python using your converter?
I actually looking for a model/library/package for facemesh and iris detection to use them in my model. I am writing an algorithm in python and I don't know JavaScript and C++.

Hi,
the converter can only help with converting the model data to Tensorflow (Python).
The code you need to work with the models (preparation of inputs and evaluating outputs) cannot be converted automatically.
I did a python version of the old facemesh version, but didn't publish it because it was of limited use (to me anyway).
Unfortunately I didn't keep it, so I'm afraid I cannot help you with that.
If it's not too urgent, I might be able to create a python package for the new Face Landmarks Detection model, which includes Iris detection.

@patlevin thank you very much for your response.
I REALLY need the converted of the new version of facemesh and iris detection, It is not very urgent.
I am new to these topics but I can help you if there is anything that I can do :)
Did you also checked the third link ı sent you?

Did you also checked the third link ı sent you?

I did. I am familiar with Vladimir's work and he actually contributed to this tool, too by giving very valuable feedback.
I am pretty impressed by what he managed to build 👍

actually he suggested this repo!
Do you have any estimation about the time you can open that converted version repo?

Do you have any estimation about the time you can open that converted version repo?

It's difficult to make a realistic estimation. The models contain quite a lot of setup and post-processing code as well as a bunch of browser-specific stuff. I will first have to think about a reasonable way to turn this into a Python library (input/output types, etc.).
I'll have a closer look at it over the weekend and maybe get a first draft done by Sunday or so. But no promises 😉

ok, thank you so much.
Then please let me know whenever you did :)

@lghasemzadeh It's been a while and I didn't forget about your request. Unfortunately what I did forget about was publishing the repo.
You can find my try at converting the MediaPipe code to Python here: Face Detection for Python
I included a little example for iris recolouring. I'll put it on PyPi later as well.

@patlevin
Thank you very much Patrick.
I am curious to see the outputs as soon as I get rid of errors.
Just a question:
To find the iris (iris detection), did you used a pre-trained model as used here?
As far as I understood you used image processing techniques such as ROI, masking and contouring to find iris location, right?
Actually, I was doing sth similar: face detection --> tensorflow or dlib face landmarks --> eye region landmarks --> ROI, masking and contouring to find iris. BUT at the end I got very low accuracy for realtime video streams. That is why I decided to use MediaPipe and this package because for the iris detection part they use Deep Learning. I mean they collected data, labeled iris and train a model, not image processing and maths. that is why these packages seems more robust in finding iris.
Waiting for your response
thx

@lghasemzadeh

To find the iris (iris detection), did you used a pre-trained model as used here?

Yep, I used the exact same model. Accuracy isn't great and depends on the image quality and (funnily enough) the eye colour.
It works great with high contrast eyes (e.g. blue or grey eyes and well-lit environments) and not so great with input from webcams.
I described the details here and the code with all the details can be found here.
There are a couple of ways to improve this, but they would increase latency a lot. One approach included gamma-correction and noise reduction on the input image before running the detection pipeline. Performing detection and recolouring on gamma-corrected input works much better.
Hope that helps

Thank you very much for your help and guide :)


Update README.md

Added the build badge per the new Chef Partner cookbook guide guidelines.

Looks like you have a failing build also.
Please take a look here: https://jenkins-01.eastus.cloudapp.azure.com/job/3scale-cookbook/lastFailedBuild/console


Missing "New Package Request" issue template

Description
Based on older issues, it seems there used to be an actual template for issues requesting new packages; as also suggested by the adding-new-packages.md file.
The template appears to be missing. I believe templates are managed outside of git; so I can't point to a commit where it was removed.

As a side note, is this the right place to request qemu-guest-agent? Or is there a more specific place for packages that are only needed in certain distribution images?

An issue here for qemu-guest-agent is good, thanks

What other platforms would need the qemu-guest-agent, openstack? Do you suggest making it part of the /usr partition and then having a unit with ConditionVirtualization=qemu run it?

 The generic image is quite good for usage with QEMU and is easy to customize through mounting it without any conversion, that's why I wouldn't want to make the QEMU "OEM image" more mandatory by introducing extra features that are otherwise not available.


Fix some bugs with the new release pipeline

actions/upload-artifact follows symlinks when asked to archive a directory, which results in the release package having three copies of each macos/catalyst library. To fix this, skip extracting the zip before archiving even though it results in an awkward nested zip.
Building RealmSwift also builds Realm, so we don't need the obj-c specific build jobs.
Docs and update checker publishing were failing due to s3cmd not being installed. Docs publishing still doesn't work because the s3 account we're using doesn't have access to the bucket. Passing the token as a CLI argument hits a bug in s3cmd where access denied errors are reported as the config file being malformed, while passing them as env variables gives more accurate errors.
Using setup-ruby plus bundler to install ruby and gems makes it only take 5-10 seconds and lets us pin specific versions of the gems.

Successful run with the new tokens: https://github.com/realm/realm-swift/actions/runs/7904978638/job/21576536648


Increasing cel compliance

There's a bunch of stuff in here:

Failable functions
Bunch of type conversion implementations so that it's easy to load primitives into the interpreter

Since this project is not maintained apparently, I'll probably keep the fork going over on my side https://github.com/clarkmcc/cel-rust/pull/1

Yeah, it’s not something I have time to work on anymore 😢.
I’m more than happy to make you a maintainer here, or transfer the actual crate to you so you can publish it and then archive this?

I'm happy to take on the project! Let me know how you'd like to proceed.


[release/1.2] Update cri to 2bb57d27203d82fc79c496aea724aec593b2705a.

Changes: https://github.com/containerd/cri/compare/f913714917d2456d7e65a0be84962b1ce8acb487...2bb57d27203d82fc79c496aea724aec593b2705a
Bugfixes:

Do not log AuthConfig. containerd/cri#960
Fix a bug that pod can't be stopped if its permanent network namespace is closed unexpectedly. https://github.com/containerd/cri/pull/950

Signed-off-by: Lantao Liu<EMAIL_ADDRESS>

Codecov Report

Merging #2784 into release/1.2 will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff              @@
##           release/1.2    #2784   +/-   ##
============================================
  Coverage        47.41%   47.41%
============================================
  Files               91       91
  Lines             8410     8410
============================================
  Hits              3988     3988
  Misses            3699     3699
  Partials           723      723

Flag
Coverage Δ

#linux
47.41% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


[Feature Request] A switch/button

So, we all know levers. I want a bit more fancy button with on off state. There was a mod in 1.6.4 that had a switch. Just a small square with a red and green square showing if it was on or off.
Could you please add such a thing? :)
It would make my spawner room so much cooler.

I second that. The conduit switch has a weird shape and is useless if you're making a flat control panel.


Remove optional/required demands

This was the wrong way to go, users can manage how the dialog behaves in the callback. See issue #50

They are all required atm (PermissionScope.swift#L848), since requiredAuthorized() and allAuthorized() return the same value.

Removed the demands in swift2 a few days ago.


Automatic code formatting

We want something like gofmt for python. We want to minimize changes to existing code while defining a style we agree to. Ideally it should automatically format files on save (PyCharm integration would be great) and/or as a precommit hook.
One option: https://github.com/google/yapf
From @eukreign on Slack:
but to elegantly switch to yapf would require:

defining a new config that's as close to current code as reasonable
running the converter and adding a comment to any datastructure that is uglified by yapf

whoever takes on this project should be willing to carefully skim through the changes yapf makes to make sure it's not uglier (at least not too much uglier) than before

I think black can be a great choice. the python community is slowly accepting it.
It's PEP8 compliant as well

Leading to this I checked lbry-sdk on lgtm.com seems there are a lot of issues related to Unused Imports etc.
I suggest we could add pylint to catch this kind of stuff, if code quality is important

I hate black. I don't like it because it tends to produce code with parentheses in different lines, like in a C style, which tends to look bad in Python.
Regular Python
def some_function(arg):
    return

With black
def some_function(
    arg
):
    return

I call it "sad style" because of the final sad face that is produced ):
Maybe black can be configured to avoid this, and adjust some properties but I have never tested it.
My preferred style is the one used by scientific libraries like numpy and scipy. If you use the Spyder editor, it automatically checks your code as you write, and it gives you the best formatting suggestions according to pycodestyle (optional dependency). Basically following those suggestions is enough to have a consistent style; it becomes second nature after a while.

Compliance with Python's PEP8 can be checked with flake8.
flake8 --ignore=E226,W503 --max-line-length=80 file.py

We may ignore certain errors and warnings.

E226: spaces around arithmetic operators *, /, +, -; sometimes we don't need a space.
W503: break lines before a binary operator like and and or. The W503 warning will be changed in the future so we can ignore it for now.
Line length is typically 80 characters, but of course, we could be flexible; 100 is common as well.
See the meaning of the error codes in the pycodestyle documentation. As I mentioned, this style is automatically checked by some editors, like Spyder.

A good way to test entire folders for compliance is to run the following command.
find lbry/ -name '*.py' -exec flake8 --ignore=E226,W503 --max-line-length=80 '{}' '+'

Hi @shyba  ,
I'm interested in contributing to this issue, so before I start working
it, would you mind sparing your time explaining what the issue is about and pointing me to some resources to get started.

Hi @shyba,
I'm interested in contributing to this issue, is it still required?


Allow additional origins without replacing the default one.

Pull Request (PR) description
This PR enables the users to specify extra origins, in order to have a combination of the automatic default origins and further origins.
This Pull Request (PR) fixes the following issues
This does not fix, but refers, to #105

Thanks for the review. I committed your suggestion. I guess we should also do that for the other (already existing) array Params.


Design: More efficient usage pattern for CopyOnWrite dictionary

This change incorporates the key principle of the "copy-on-write" pattern into a set of building blocks that are more readily digestible based on the performance need and willingness to endure syntactic salt.
If this is deemed useful, I'll give the same treatment to my copy on write list implementation and move it over.
I want to implement copy-on-write semantics inside my custom dictionary type
The pattern for this is to include CopyOnWriteDictionaryHolder as a member of your class. This gives you strongly typed access to the dictionary type in use (not IDictionary<>) which avoids boxing in some key performance scenarios. See ModelStateDictionary in MVC for a canonical example.
In your implementation, you can safely forward calls to the 'holder' and do optimizations to avoid boxing where it's needed for your scenario. With any custom dictionary type, it's strongly recommended to implement custom enumerator types, this change lets you do so without boxing.
This used to cost you an object allocation and 4 fields (1 in your class, 3 in the CoW class). It now costs you no allocations and 2 or 3 fields depending on your backing store. It seems like a safe assumption that we can cache the 'factory' as our comparers general vary based on the dictionary's purpose, not based on user input.

@dougbu updated

LGTM but why is this still showing as a designer PR? :shipit: if it is just titled incorrectly.


Getting a ton of warnings due to missing sourcemaps

Hi Contra. I get a ton of warnings when using yarr in create-react-app 5. They look like this:
Failed to parse source map from '/Users/me/projects/test-app/node_modules/yarr/src/components/Link.tsx' file: Error: ENOENT: no such file or directory, open '/Users/me/projects/test-app/node_modules/yarr/src/components/Link.tsx'
Apparently, you should either add the source .ts files to the output, or tell node not to generate sourcemaps. See https://github.com/facebook/create-react-app/discussions/11767. I don't want to set the GENERATE_SOURCEMAP env variable to false, since that will remove all sourcemaps.
Steps to reproduce

npx<EMAIL_ADDRESS>test-app --typescript
npm install --save yarr
Import any yarr thing in App.tsx
npm start

Hey @jakobvase!
Thanks for reporting. This is fixed in v3. You can give it a try today via the beta tag.
V3 should be out next week. The only breaking change is changing minimum Node engine version to v16 or above.
This issue will automatically be closed once released on main.


Bug report and some suggestions on v2.6.0

Hello it seems that 2.6.0 has some issues with playing adhan as i said in the past and muezzin media player is opened for no reason on muezzin starts. also could you please add Asia/Mashhad adhan times to muezzin?

Salam, can you check now, I think I forgot previously to update the release.
About the Asia/mashhad, I didn't make the timezone list myself, it's imported.

The issue should be fixed inshaAllah, if you have any more suggestions please feel free to open a new issue ! Assalam Alaykoum & Jazzaka Lahu khairan.


luci-app-openvpn: Update Spanish translation

Update Spanish translation
Signed-off-by: Franco Castillo<EMAIL_ADDRESS>

The same thing again. all 844 lines deleted and re-created.
You have edited the same file last time two weeks ago, and then there was no problem. What has happened in the meanwhile?

The same thing again. all 844 lines deleted and re-created.
You have edited the same file last time two weeks ago, and then there was no problem. What has happened in the meanwhile?

I do not know what it could be. There must be a problem with the file. I will try another way.

Typical reason might be DOS-Unix line-ednings difference (CRLF vs. LF)
But hard to figure out why that would manifest now.

Please verify the file difference after committing to your own fork,  before publishing the actual PR.


Removing deploy key does not remove key

Version:<IP_ADDRESS>5
When removing an added deploy key. It says it has removed the key, but in the view the removed key is still visible. Neither database nor authorized_keys will be updated.

Thanks your report!

Hi, I've pushed fixed code to develop  branch and you can also test on https://try.gogs.io !

It works :) Removal confirmed. Authorized_keys is clean and table public_key is clean.
Tested with 1 and with 2 keys just to check if with 2 keys it did not remove all keys.

Thanx

@amavis442 thanks your confirmation!