access logging: gRPC logger improvements for Envoy as TLS transparent proxy

Signed-off-by: Niek Temme<EMAIL_ADDRESS>Commit Message: access logging: gRPC logger add sni hostname and add fields for Envoy as TLS transparent proxy
Additional Description:
Hi, I would like to suggest five changes/additions to gRPC access loger and accesslog proto file. These changes mainly benefit using Envoy as a TLS transparent proxy. I am not an experienced c++ developer and any feedback is welcome.
The problem is explained here: #22407
After digging into the code, the proposal is to make five modifications/additions to the gRPC logger. A detailed description per modification/addition is listed below.

Set tls_sni_hostname also when TLS connection is not terminated.
Add duration
Add upstream_request_attempt_count
Add connection_termination_details
Add ja3_fingerprint when ja3_fingerprinting is enabled

Details

Set tls_sni_hostname also when TLS connection is not terminated.
This enables it to log the requested hostname when the tls listener filter is used, but the connection is simply forwarded to the upstream cluster. This is for example useful to see if envoy forwards to the correct cluster based on the requested hostname.

Add duration
The existing duration fields in the acceslog.proto are not present when using the tcp listener. The complete duration, based on stream_info.requestComplete(), however is available. A separate duration field is in line with the file access log.

Add upstream_request_attempt_count
Logs the number of times the connection request is attempted upstream. Note that the field is omitted when the connect request was never attempted upstream. This is particularly useful when the max_connect_attempts field is set in the tcp_proxy.

Add connection_termination_details
Connection termination details may provide additional information about why the connection was terminated by Envoy for L4 reasons. This is especiall usefull when network rbac envoy.filters.network.rbac . The connection termination details contains the info why a connection was blocked/allowed.

Add ja3_fingerprint when ja3_fingerprinting is enabled
The tls inspector listner filter has an option to generate ja3 fingerprint (default false). When available this logs the ja3 fingerprint. This field is omitted when the ja3 fingerprint is not available. The field is present when eiter envoy terminates the tls connection or acts as a transparent proxy.

Risk Level:
Low/Medium - four additional fields are added, no fields removed or changed (no behavior changes expected)
The only change is that tls_properties is also added when it is not a terminated tls connection. In this scenario, of the tls_properties only the tls_sni_hostname is available. The other tls_properties fields are not present. As far as I can see, this is consistent with the behavior of the tls listener filter.
This could be a breaking change if the receiving application of the access log message checks for the presence of the tls_properries and when present expect all the fields to be there, or assumes this must be a tls terminated connection.
Testing:
unit tests
Development build using mac os x (m1 if that info is relevant), but with ‘default’ extensions.
All tests pass.
manual testing
Using a sample grpc log service. Displaying accesslog stream using golang protojson.Marshal()
Tested

Tcp with tls
Tcp no tls
Http no tls

Docs Changes:
I have added the documentation in the proto file accesslog.proto for data.accesslog.v3.AccessLogCommon, and data.accesslog.v3.TLSProperties.
Am I right in assuming that the documentation is generated from this file? If not, I have to modify the documentation.
Release Notes:
access_log: log duration, upstream_request_attempt_count, connection_termination_details and tls ja3 field in the grpc access log and also log the tls sni and ja3 field in the grpc access log when envoy is configured  as a tls forward proxy.
Platform Specific Features: N/A
Issues:
Fixes: #22407
[Optional API Considerations:]
ls_sni_hostname:

See risk level above. The other option would be to add a requested_server_name field to the access_log_common properties. That would be present when either the tls connection is terminated or forwarded.
The downside of this solution would be that this would create a duplicate field for tls_sni_hostname when envoy terminates the tls connection.
The proposed solution: Filling tls_properties->tls_sni_hostame either when envoy terminates or forwards the tls connection is consistent with file access logging.

upstream_request_attempt_count

In file logging this field is 0 when there is no upstream connection attempt made. I believe that omitting this field when there is no value is more in line with the grcp ALS service.
In most scenarios the value of this field is 1. This field could also be adapted to a retry count. In that solution the field would be present only if the attempt > 1. This is however not consistent with file logging. The proposed solution is.

Edit 10 August 2022: Added release notes

/wait on CI

Ah I see I made some code format/spelling mistakes. I will try to fix them to today and run check before submitting.
sorry for the rookie mistake

no worries - happens all the time (including for us non-newbies) =P

Ah. I thought my local build setup ran all the integration test, but it does not. Perhaps because I use the Mac OS X build setup. The Mac OS X tests all passed ;-)
I see the grpc access log integration tests fail because it sees unexpected fields. That makes sense. I will probably be able to fix it on Friday and make sure I run all the integration tests locally before I submit again.
Impressive CI pipeline!

/wait
Seems like CI test failures are legit
//test/extensions/access_loggers/grpc:http_grpc_access_log_integration_test FAILED in 2 out of 2 in 20.2s
  Stats over 2 runs: max = 20.2s, min = 20.0s, avg = 20.1s, dev = 0.1s
  /build/tmp/_bazel_envoybuild/b570b5ccd0454dc9af9f65ab1833764d/execroot/envoy/bazel-out/k8-opt/testlogs/test/extensions/access_loggers/grpc/http_grpc_access_log_integration_test/test.log
  /build/tmp/_bazel_envoybuild/b570b5ccd0454dc9af9f65ab1833764d/execroot/envoy/bazel-out/k8-opt/testlogs/test/extensions/access_loggers/grpc/http_grpc_access_log_integration_test/test_attempts/attempt_1.log
//test/extensions/access_loggers/grpc:tcp_grpc_access_log_integration_test FAILED in 2 out of 2 in 7.8s

The implementation makes sense. Can you check CI, and also add tests for those logging field that you added?

The implementation makes sense. Can you check CI, and also add tests for those logging field that you added?

Thanks. Yes, I have fixed the failing existing integration tests by:

Adding the duration field as a field to be removed because it is not deterministic. In the same way time_to_last_rx_byte was already removed.
Adding upstream_request_attempt_count: 1 to the expected output.

I am now looking at creating additional integration tests for

TLS trafic (tls_sni_hostname and  ja3_fingerprint fields)
RBAC (connection_termination_details field).
upstream_request_attempt_count: 2 when retry = 2

This new integration tests are probably a little harder for me to do. I see the integration tests in the listener filters themselves probably give the insight in how to setup the correct configuration and client test set-up. I'll try to finish it over the weekend.

Hi,
I fixed / added the integration tests. All tests in the pipeline success except for Mac (CI?), see below.
Failing Mac step (just CI?)
I see the CI is failing at the mac step.

As far as I can see the tests were actually successful. [  PASSED  ] 52 tests.
It failed on the process test results step with:
Error in download_and_extract: java.io.IOException: Error downloading [https://github.com/indygreg/python-build-standalone/releases/download/20220227/cpython-3.10.2+20220227-x86_64-apple-darwin-install_only.tar.gz] to /Users/runner/work/1/s/_bazel_runner/3d1a7f52fd47fc9a8db71770aacd13e5/external/python3_10_x86_64-apple-darwin/temp12472564453881277793/cpython-3.10.2+20220227-x86_64-apple-darwin-install_only.tar.gz: Bytes read 14876672 but wanted 42785626
I am correct that this is a fault in the CI not the committed code?
It looks like I do not have the rights to redo just this step, or I do not know how.

Fixed in the existing integration test.

Adding the duration field as a field to be removed because it is not deterministic.
Adding upstream_request_attempt_count: 1 to the expected output.

Added integration tests in tcp_grpc_access_log_integegration_test

RBAC (new test). Integration test for connection_termination_details

New test tls_grpc_access_log_integration_test

ssl termination no ja3
ssl termination with ja3
no ssl termination no ja3
no ssl termination with ja3

These run the integration test of the GRPC access logs for the desired TLS fields.
tls_version
tls_cipher_suite
tls_sni_hostname
ja3_fingerprint
local_certificate_properties
- subject_alt_name
- subject
peer_certificate_properties
- subject_alt_name
- subject

Separate test for TLS
The tls access log tests are based on the integration tests of the tls listener filter. The setup is quite different from the tcp tests. That is why I separated it into a new test. As a c++ newbie it is hard to integrate the existing tcp tests with the tls tests. The different test setup could justify a separate test (file) from the tcp access log integration test.
no integration test for upstream_request_attempt_count >1
I was not able to make a good integration test for upstream_request_attempt_count >1. I could not find a way to make sure the value had a deterministic output other than 1. I also could not find an existing envoy integration test that did this.
To do / question
I see I still left to lines committed out in the tcp_access_log_integration test that should be removed. Perhaps a re run will also fix the Mac ci issue. I was hoping to get feedback on this commit first before doing a re-run of the CI.

Small update

Removed unnecessary commented out lines and replaced them with correct comments (as mentioned in previous comment).

Mac CI did run correctly this time (no code change). I see a warning with the CI of package arm -> post job cache ##[error]The server is busy.  Please try again later.
I hope this is not an issue.
I am traveling between August 11 and August 21 and will probably not be able to check back (in a timely manner) during this time. Sorry if this causes an inconvenience.

Sorry,
I realised my proposed code for adding TLS fields could be simplified. Changed it and reran all the tests. This looks better (no redundant code).
Another advantage is that the ja3 filed is now also filled if there is no sni (this is a possibility). I added the integration test for that scenario as well. All passes.

@lizan updated changelogs/current.yaml and accesslog.proto for documentation.

Hi,
Sorry to ask. Is there still something left for met to do? Did I miss something or do something incorrectly?

@niektemme sorry I was off for a week for medical reasons and now back. Can you merge main to resolve conflicts? Otherwise it looks great.

@lizan I hope everything is ok. I updated changelog/current.yaml from main branch. The only conflict now my addition. I can not resolve this myself right as I do not have write access to main? Or do I not understand correctly?

@niektemme you can merge main branch to your PR branch and resolve conflicts, then push that change to your PR branch.

@lizan thank you for the instructions. I did not know that was possible. I merged the main branch and pushed the pr again. The conflict is now resolved. Ci was also now successful.


Compatible with Ruby 2.5

Hi,
jimson depends on rest-client ~> 1 and the latest from this lineage is 1.8.0.
rest-client 1.8.0 is not compatible with ruby 2.5 because of upgraded openssl interface.
"key not found: :ciphers"
rest-client-1.8.0/lib/restclient/request.rb:163:in `fetch'
I don't think that rest-client 1.8.1 will be released, so, do you have any plans to move to newer rest-client , say ~> 2 ?
Thanks.

Closing this because it is compatible now.


changed subtitle from BGP Peer Definition to BGP Configuration Defini…

…tion
Description
The BGPConfiguration resource reference documentation contained a copy-and-paste mistake in the resource definition subtitle which erroneously read BGP Peer Definition.
This has been corrected to read BGP Configuration Definition in both the master and v3.0 directories.
Todos

[ ] Tests
[ ] Documentation
[ ] Release note

Release Note

None required

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Cody McCain seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Cody McCain seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

@emanic any idea what's with the htmlproofer errors about v2.5 docs?

@gunjan5 It's something I'm working on and should have a fix shortly. Then we can rebase off latest master and no more problems. Long story

I don't think this PR causes any htmlproofer problems.. so I'm going to merge it.


[SLH] Add hero lifting option

Before

After

Add an option to lift the hero up to have a better view of it.

Sure


Add new driver for vl53l0x

@brentru @ladyada
This was more straightforward than the vl53l4cd ToF sensor given there is a dedicated Adafruit library for vl53l0x; it was pretty much copy/paste following the MCP9808 guidelines (https://learn.adafruit.com/how-to-add-a-new-component-to-adafruit-io-wippersnapper/adding-an-i2c-component-driver)
As always, your support is so appreciated and please let me know where I go wrong so that improvements can be made on my part. Thank you!! :)

@afp316 You also need to create another pull request within https://github.com/adafruit/Wippersnapper_Components for the V53l0X sensor.
Let me know when the component definition has been created for this sensor and I'll take a look!

Does this match up with the adafruit/Wippersnapper_Components#57 component?

Yes, it does. Thanks!

@brentru The latest PR replaces an instance of proximityEvent->proximity with proximityEvent->data[0] as well as two instances of event.proximity with event.data[0] per your guidance in PR #289

@afp316  The driver looks much better and compiles, thanks for the work! Next, please format it using clang-format (we have a guide on this here: https://learn.adafruit.com/the-well-automated-arduino-library/formatting-with-clang-format) as its failing the clang-format test step (https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/runs/7682729616?check_suite_focus=true).

Copy that, thanks.
I'll check that out this evening...new to clang formatting.
On Fri, Aug 5, 2022 at 11:01 AM Brent Rubell @.***>
wrote:

@afp316 https://github.com/afp316 The driver looks much better and
compiles, thanks for the work! Next, please format it using clang-format
(we have a guide on this here:
https://learn.adafruit.com/the-well-automated-arduino-library/formatting-with-clang-format)
as its failing the clang-format test step (
https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/runs/7682729616?check_suite_focus=true
).
—
Reply to this email directly, view it on GitHub
https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/pull/291#issuecomment-1206556334,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXAAGVQCADKERHKI5R7NWUTVXUUGFANCNFSM55LTMAMQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hi @afp316  - this pull request is still failing on clang-format. It seems like commit https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/pull/291/commits/2e024a688a2c4ac9cfd475e3a034cf9d1e540f52 added some files to the platformio folder?

@afp316 Are you still interested in working on this issue?

Hey Brent, I kind of got sidetracked by other projects. I plan to finish it
up still.
On Tue, Aug 23, 2022, 10:02 Brent Rubell @.***> wrote:

@afp316 https://github.com/afp316 Are you still interested in working
on this issue?
—
Reply to this email directly, view it on GitHub
https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/pull/291#issuecomment-1224122573,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXAAGVR2HOGKVT65JD52DETV2TKYZANCNFSM55LTMAMQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

@afp316 Are you still interested in working on this issue?

Hey Brent.  I kind of lost track on this one, I probably won't be finishing
On Fri, Nov 11, 2022, 13:41 Brent Rubell @.***> wrote:

@afp316 https://github.com/afp316 Are you still interested in working
on this issue?
—
Reply to this email directly, view it on GitHub
https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/pull/291#issuecomment-1312062090,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXAAGVUJQY3QLIRCI5BBKGTWH2HONANCNFSM55LTMAMQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

No problem, @tyeth  is finishing it within https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/pull/363

Thanks @afp316 for your hard work! It wont be wasted, hopefully you get to reap the benefits too soon :)

I appreciate you snagging that! You're time won't go to waste. The driver
stuff isn't too mind boggling but honestly I couldn't figure how to do the
clang formatting and lint... I'm kind of a newb.
On Mon, Nov 14, 2022, 12:22 Tyeth Gundry @.***> wrote:

Thanks @afp316 https://github.com/afp316 for your hard work! It wont be
wasted, hopefully you get to reap the benefits too soon :)
—
Reply to this email directly, view it on GitHub
https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/pull/291#issuecomment-1314116060,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXAAGVXSTOHUYW4J4JNCWITWIJYPBANCNFSM55LTMAMQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hey it threw me a bit too, vscode wasn't getting it 100% with the includes, and scanning seemed to be per file. In the end I cloned adafruits CI repo like the failing build did and ran the same clang / doxygen commands :)


ARTEMIS-2319 Upgrading jboss-logging dependencies

Upgrading versions
Adding wildfly-common dependency as jboss-logmanager now depends on it
for simple common operations such as getting hostname or process id
Updating bootclasspath with wildfly-common

Jira: https://issues.apache.org/jira/browse/ARTEMIS-2319

@clebertsuconic , i see you merged this wildfly is LPGL https://github.com/wildfly/wildfly/blob/master/LICENSE.txt, this isn't a cat A license, can we please revert this.

From what I can tell, Wildfly Common is ASL 2.0. See https://github.com/wildfly/wildfly-common/blob/master/LICENSE.

As per noted, the general wildfly project is LGPL, so when code is added or moved there is risk of LGPL contamination.
As there already is unfortunately common has code in it the LGPL headers.
https://github.com/wildfly/wildfly-common/blob/1.5/src/test/java/org/wildfly/common/string/CompositeCharSequenceTestCase.java
It is best we revert this, and moving forwards a solution not needing a wildfly dep, will be better, else we run risk of code within their code base getting contaminated with LGPL.

@ehsavoie Can you either revert this on a Pull Request, or request an updated license on wildflycommons?
The project is licensed as ASL, but I believe these headers are there for a mistake.

For later reference, if anyone tries to follow along later, related discussion on dev list (around the artifact being used not being affected):
<EMAIL_ADDRESS>

https://github.com/wildfly/wildfly-common/pull/46  the PR for wildfly-common for fixing the missing / wrong license headers


Setup production environment

Precondition:

#6

Todo:

install Alaveteli
install theme
install custom translation
import initial set of companies

Done


Steampipe request rates aren't throttled enough to avoid GitHub rate limits

The Steampipe GitHub plugin should already be doing its own request throttling, but we're clearly still bumping into GitHub's limits sometimes:
ERROR:  rpc error: code = Unknown desc = github: GET https://api.github.com/repos/nextstrain/react-sidebar/actions/workflows?per_page=100: 403 API rate limit of 1000 still exceeded until 2024-02-15 04:58:05 +0000 UTC, not making remote request. [rate reset in 7m26s]

The Steampipe feature to dig into is "limiters": https://steampipe.io/docs/guides/limiter
Maybe also read a bit about caching: https://steampipe.io/docs/guides/caching (but really, I don't expect the cache to help us here: we want the fresh data)
A few thoughts:

It does really seem like this should work out of the box. Worth checking source that it should. And if so, perhaps it's not because it can't properly track rates when we're starting from an empty Steampipe state every time (new Steampipe Pg service, new install, new workflow job, etc.) and doing so frequently?

Since "every 5 minutes" GitHub Actions workflows are not reliably actually every 5 minutes, we could opt instead to launch a long-running workflow on GitHub Actions every ~6 hours or something (with concurrency to have a shallow queue) and do the high frequency polling within it. This would help solve thought 1 too, if indeed that's an issue.

The keen-eyed may note that the above example error references workflows for the nextstrain/react-sidebar repo. They may wonder why we're looking at that repo at all. It's a good question! The answer is that doing so is a) too easy and b) means we don't have to update a query/source code here when a new pathogen repo starts using pathogen-repo-build. But we could probably rewrite bits of the query to avoid making unnecessary requests. I'd count this as a measure of last resort, though.

We've not run into rate limits for ages now, AFAIK. Closing.

Of course we hit the rate limit the day after you close this issue
ERROR:  rpc error: code = Unknown desc = github: GET https://api.github.com/repos/nextstrain/ncov-ingest/contents/.github/workflows/shellcheck.yml?ref=master: 403 API rate limit of 5000 still exceeded until 2024-12-19 20:35:48 +0000 UTC, not making remote request. [rate reset in 3m23s]

orz

Ahhh, I bet I know why this is happening, and in particular, why it happened now. Steampipe's almost certainly abiding by rate limits, but it can't do so across independent machines, e.g. across concurrent runs of our CI (scheduled + for PRs). So we're more likely to see rate limit errors when there's active development happening, but not when things are quiet and scheduled runs are the only thing going on. Our CI concurrency
https://github.com/nextstrain/status/blob/029440b15246e3e118d100eb2ae654669895a397/.github/workflows/ci.yaml#L13-L14
doesn't do anything to prevent concurrent runs on different refs, which was intentional, as it'd be slightly annoying and/or block the scheduled production updates.
I'm sure there are other things we can do here to make rate limit errors less likely, but right now, I'm going to keep not worrying about it!


ARROW-16419: [Python] Properly wait for ExecPlan to finish

How severe this issue is? Does this belong to a new feature? I'm not sure whether we should block the release on it or not.
cc @pitrou

@kszucs It should probably not block the release, but worth including if you cut another RC.
cc @amol-

This by itself is not blocking but see #13036 which is the fix for the segfault I was running into on the ML.


KickoffActivity not found

Welcome to FirebaseUI and thanks for submitting an issue!
Step 3: Describe the problem:
I am facing error when compiling my app in the emulator. I am using FireBase and trying to create a chatapp for android, tutorial from this site: https://code.tutsplus.com/tutorials/how-to-create-an-android-chat-app-using-firebase--cms-27397
Unfortunately, I get the error message

Error:Execution failed for task ':app:processDebugManifest'.
Manifest merger failed with multiple errors, see logs

When I go to logs, it says,

Unable to find explicit activity class {com.myapp.project.chatatwork/com.firebase.ui.auth.KickoffActivity}; have you declared this activity in your AndroidManifest.xml?

In my gradle (app) I have:

dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'com.android.support:appcompat-v7:26.1.0'
implementation 'com.android.support.constraint:constraint-layout:1.0.2'
implementation 'com.google.firebase:firebase-core:12.0.1'
testImplementation 'junit:junit:4.12'
androidTestImplementation 'com.android.support.test:runner:1.0.1'
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.1'
compile 'com.android.support:design:26.0.0'
compile 'com.firebaseui:firebase-ui:3.3.0'
}
apply plugin: 'com.google.gms.google-services'

I really don't know, what I am doing wrong. As far as I understood, KickoffActivity (which is a Firebase activity) should be added automatically when connecting android studio with firebase.

Looks like @PeterHdd answered this a while ago on StackOverflow, closing!


multiConnectError fuction behaves incorrectly.

not ok 414 error description matches

operator: equal
expected:
  'Connection could not be established'
actual:
  'The operation couldn’t be completed. (ThaliTest.AppContextError error 0.)'

Branch to reproduce: iOS_squid48_1611

Unfortunately now we have another issue with We properly fire peer unavailable and then available when connection fails test:
We properly fire peer unavailable and then available when connection fails
2016-12-14 15:12:05 - DEBUG thaliMobileNativeWrapper: 'listening 50760'
2016-12-14 15:12:05 - DEBUG thaliMobileNativeWrapper: 'discoveryAdvertisingStateUpdateNonTCP: {"advertisingActive":false,"discoveryActive":true}'
2016-12-14 15:12:05 - DEBUG thaliMobileNativeWrapper: 'Received peer availability changed event with {"peerIdentifier":"c92fd56b-ef52-4dad-b510-ca0f23c1752a","generation":0,"peerAvailable":true}'
2016-12-14 15:12:05 - DEBUG thaliMobileNativeWrapper: 'handlePeerAvailabilityChanged - Emitting {"peerIdentifier":"c92fd56b-ef52-4dad-b510-ca0f23c1752a","peerAvailable":true,"generation":0,"portNumber":null}'
2016-12-14 15:12:05 - DEBUG thaliMobile: 'Emitting peerAvailabilityChanged from handlePeer {"peerIdentifier":"c92fd56b-ef52-4dad-b510-ca0f23c1752a","connectionType":"MPCF","peerAvailable":true,"generation":0,"newAddressPort":false}'
ok 1 peerIds match
ok 2 peer is available
2016-12-14 15:12:05 - DEBUG thaliMobileNativeWrapper: 'Received peer availability changed event with {"peerIdentifier":"c92fd56b-ef52-4dad-b510-ca0f23c1752a","peerAvailable":false,"portNumber":null,"recreated":true}'
2016-12-14 15:12:05 - DEBUG thaliMobileNativeWrapper: 'Received peer availability changed event with {"peerIdentifier":"c92fd56b-ef52-4dad-b510-ca0f23c1752a","peerAvailable":true,"generation":0,"portNumber":null,"recreated":true}'
ok 3 Failed on right peer
not ok 4 Marked as recreated
  ---
    operator: equal
    expected: true
    actual:   undefined


Unable to install app on aem 6.5.9

Describe the bug
Installing the all package on AEM 6.5.9 (with all required dependencies present) fails due to missing cloud dependencies:
com.adobe.cq.dam.download.api,version=[3.4,4) -- Cannot be resolved but is not required
com.adobe.cq.dam.download.spi,version=[1.1,2) -- Cannot be resolved but is not required

I followed instructions from documentation and added dependency for
<dependency>
    <groupId>com.adobe.aem.commons</groupId>
    <artifactId>assetshare.all</artifactId>
    <version>2.3.4</version>
    <type>zip</type>
</dependency>

Logs when I try to activate the bundle
02.09.2022 13:32:27.758 *ERROR* [qtp1818270852-2448] org.apache.felix.http.jetty Bundles: Cannot start (org.osgi.framework.BundleException: Unable to resolve com.adobe.aem.commons.assetshare.core [620](R 620.0): missing requirement [com.adobe.aem.commons.assetshare.core [620](R 620.0)] osgi.contract; (&(osgi.contract=JavaActivation)(version=1.2.0)) Unresolved requirements: [[com.adobe.aem.commons.assetshare.core [620](R 620.0)] osgi.contract; (&(osgi.contract=JavaActivation)(version=1.2.0))])
org.osgi.framework.BundleException: Unable to resolve com.adobe.aem.commons.assetshare.core [620](R 620.0): missing requirement [com.adobe.aem.commons.assetshare.core [620](R 620.0)] osgi.contract; (&(osgi.contract=JavaActivation)(version=1.2.0)) Unresolved requirements: [[com.adobe.aem.commons.assetshare.core [620](R 620.0)] osgi.contract; (&(osgi.contract=JavaActivation)(version=1.2.0))]

Environment

AEM Version: 6.5.9
Asset Share Commons Version: 2.3.4
Author, Publish or both: both

To Reproduce
Steps to reproduce the behavior:

Install all package on AEM 6.5.9 (or probably any on-prem AEM)

Expected behavior
Application works (bundle active)

Hi! This is expected for 6.5 since the AEM CS download framework is not available on 6.5. This is why these imports are optional.
That said, ASC should fall back on 6.5 to an internal implementation that supports downaloads being orchestrated in the AEM JVM. Please let us know if the download aren't working on 6.5 -- vs just having an optional dependency being unsatisfied (again, it's optional for a reason)

Hi @davidjgonzalez
You are right - missing imports are optional and they do not cause the problem with this bundle. As far as I understand bundle was failing to start because of missing dependency (based on the error log)
02.09.2022 13:32:27.758 *ERROR* [qtp1818270852-2448] org.apache.felix.http.jetty Bundles: Cannot start (org.osgi.framework.BundleException: Unable to resolve com.adobe.aem.commons.assetshare.core [620](R 620.0): missing requirement [com.adobe.aem.commons.assetshare.core [620](R 620.0)] osgi.contract; (&(osgi.contract=JavaActivation)(version=1.2.0)) Unresolved requirements: [[com.adobe.aem.commons.assetshare.core [620](R 620.0)] osgi.contract; (&(osgi.contract=JavaActivation)(version=1.2.0))])
org.osgi.framework.BundleException: Unable to resolve com.adobe.aem.commons.assetshare.core [620](R 620.0): missing requirement [com.adobe.aem.commons.assetshare.core [620](R 620.0)] osgi.contract; (&(osgi.contract=JavaActivation)(version=1.2.0)) Unresolved requirements: [[com.adobe.aem.commons.assetshare.core [620](R 620.0)] osgi.contract; (&(osgi.contract=JavaActivation)(version=1.2.0))]

and mostly this part of the log (osgi.contract=JavaActivation)(version=1.2.0).
I checked the documentation  and found out that on my AEM bundle exporting javax.activation package had version 1.1.1 and asset-share-commons bundle required version 1.2.0
I installed additional bundle locally and it resolved the issue:
<dependency>
    <groupId>org.apache.sling</groupId>
    <artifactId>org.apache.sling.javax.activation</artifactId>
    <version>0.3.0</version>
</dependency>

I guess this still needs some fix in the app - I am not sure whether this should be included in the app package or maybe documentation needs to be extended.

This is a regression of #767. Using dependabot on OSGi dependencies is usually not helpful.

@bartoszWesolowski This should be fixed in 2.4.0 (just released) - thanks to @kwin for spotting this.
I tested it on my 6.5.9 and everything resolves.


Is there a code-coverage mapping for the current tests?

It would be good track it and know where the gaps are (good place to start submitting PRs)

There isn't code coverage currently being run by the spectron test suite.

Mocha + Chai.js unit testing with Istanbul code coverage failed to generate code-coverage mapping on spectron test, what is the current way to do the spectron test code coverage? @DinisCruz @kevinsawicki

Please add code coverage to spectron. It's 2020 and this functionality is still not available.


Unhandled relocation type 286 (0x11e) / R_AARCH64_LDST64_ABS_LO12_NC

Is your feature request related to a problem? Please describe.
R_AARCH64_LDST64_ABS_LO12_NC is unhandled when loading AARCH64 binaries
Describe the solution you'd like
Ghidra to support these 🤟🏼
Describe alternatives you've considered
Added my pot shot guess of the fix at the end, but my confidence is ~=0, so if someone could at least sanity check would be fantastic ❤
Additional context
I think this should be fairly simple given R_AARCH64_LDST32_ABS_LO12_NC is already handled.
My guessed patch is that we need something like this:

    // LD/ST32: (S+A) & 0xFF8
    case AARCH64_ElfRelocationConstants.R_AARCH64_LDST64_ABS_LO12_NC: {
      int oldValue = memory.getInt(relocationAddress, isBigEndianInstructions);
      newValue = (int)((symbolValue + addend) & 0xff8) >> 2;

      newValue = oldValue | (newValue << 10);

      memory.setInt(relocationAddress, (int)newValue, isBigEndianInstructions);
      break;
    }

Not not 100% sure tbh, not my area of expertise (at least not yet)

Based on https://github.com/llvm-mirror/lld/blob/master/ELF/Arch/AArch64.cpp#L371, I think it will have to be >> 3, not >> 2. Otherwise, it should behave the same as R_AARCH64_LDST32_ABS_LO12_NC.

Thank you for the information.  Support for this missing relocation has been added for Ghidra 10.0.3.


Respect limit of max 256 gas coins

Description
Describe the changes or additions included in this PR.
Test plan
How did you test the new or updated feature?

Release notes
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.

[ ] Protocol:
[ ] Nodes (Validators and Full nodes):
[ ] Indexer:
[ ] JSON-RPC:
[ ] GraphQL:
[ ] CLI:
[ ] Rust SDK:
[ ] REST API:

we will need to handle dust for all transaction type, not just for pay sui.... staking will have issue as well if selected coin size > 1024, we will need to perform multiple merge coin operations depending on the size of selected coins.

For the multiple merge-coins I included this in the commit dcbbb9a.
Should we include the merge functionality for the rest of the commands in this PR or make a new PR for them?

Let’s fix all dust related issues in this PR


Add ability to format line

This is an essential feature when working in legacy or external codebases where you would like to have any new code written auto-formatted, but you would not like to touch any other code.  The Clang Format extension supports this via the Tools menu and the Ctrl-K, Ctrl-F hotkey.

Hi,
This functionality is already implemented. All you need to do is to select the code area in the VS Editor and press the Format button from the toolbar. In this way, you will be able to apply clang format on a code section (single line/block of code).
We will add shortcuts in a future release for all the Clang Power Tools commands.


test: refactor try-catch based negative scenarios with Jest matchers

⚠⚠⚠ IMPORTANT: This is an epic that serves as a template for smaller scoped issues where you perform the refactoring work explained here in a few places of the code only (instead of going all out and re-doing the entire codebase all at once).
The reason for the above is that pull requests get exponentially harder to review as their size grows, so, for these cross-cutting project-wide refactors we must break the work down to smaller chunks to allow the maintainers to keep their sanity while reviewing the code.
So, if you'd like to work on this, just open a separate issue and copy paste the content of this one, then specify a few test cases that you'll be refactoring. Then make sure to identify said test cases and their containing package in the issue title, the commit message and the PR title as well.

Description
Jest has very handy assertions (jest-extended to be more specific) which make it possible to assert the contents of an error response coming from the API.
These assertion APIs have easier to read reporting and are less confusing then the manually triggered test failures we are forced to do in the try-catch block's try leg if the operation unexpectedly succeeds with the negative scenario.
Instead of relying on clunky try-catch blocks and exception type casting we should use the native support Jest has.
As an example this is how it should be refactored, see the before and after. The two test assertions are equivalent but one is more concise, reads more like English prose and points out exactly what was not matching the assertions if there is a failure.
before
try {
  await apiClient.getKeychainEntryV1({ key });
  t.fail(
    "Failing because getKeychainEntryV1 did not throw when called with non-existent key.",
  );
} catch (ex) {
  t.ok(ex, "res7 -> ex truthy");
  const res8 = ex.response;
  t.equal(res8.status, 404, "res7.status === 404 OK");
  t.ok(res8.data, "res7.data truthy OK");
  t.ok(res8.data.error, "res7.data.error truthy OK");
  t.equal(typeof res8.data.error, "string", "res7.data.error truthy OK");
  t.true(
    res8.data.error.includes(`${key} secret not found`),
    "res7.data.error contains legible error message about missing key OK",
  );
}

after
const deletionOfNonExistentKey = apiClient.getKeychainEntryV1({ key });
await expect(deletionOfNonExistentKey).rejects.toMatchObject({
  response: expect.objectContaining({
    status: 404,
    data: expect.objectContaining({
      error: expect.stringContaining(key),
    }),
  }),
});

Acceptance Criteria

The test has already been migrated to Jest.
Tests are passing consistently. If the test became  flaky due to the refactor, we have to investigate.

I would like to work on this Issue.

I would like to work on this Issue.

@Deepakchowdavarapu OK, I opened an issue with the limited scope here: https://github.com/hyperledger/cacti/issues/3457
Please send a comment on that one and I can assign it to you. That way it will be a small enough change to get going and you can send more PRs with more of the same changes later on as you see fit.


INFRA-304: use ubuntu base image

include jdk instead of jre
add new integration tests param

Codecov Report

Merging #1051 (c41b637) into 7.x (5ad4546) will decrease coverage by 0.00%.
The diff coverage is n/a.

:exclamation: Current head c41b637 differs from pull request most recent head a59311e. Consider uploading reports for the commit a59311e to get more accurate results

@@             Coverage Diff              @@
##                7.x    #1051      +/-   ##
============================================
- Coverage     62.63%   62.62%   -0.01%
  Complexity    11444    11444
============================================
  Files          1608     1608
  Lines         54933    54933
  Branches       5413     5413
============================================
- Hits          34406    34401       -5
- Misses        18345    18350       +5
  Partials       2182     2182

Impacted Files
Coverage Δ

...ternal/eventbus/netty/AddressBookNettyHandler.java
72.97% <0.00%> (-5.41%)
:arrow_down:

.../b2international/index/es/client/EsClientBase.java
64.77% <0.00%> (-1.14%)
:arrow_down:

.../snomed/core/ecl/SnomedEclRefinementEvaluator.java
88.79% <0.00%> (-0.44%)
:arrow_down:

...index/src/com/b2international/index/es/EsNode.java
85.88% <0.00%> (+1.17%)
:arrow_up:

...national/snowowl/core/locks/OperationLockInfo.java
46.66% <0.00%> (+3.33%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

The 8.x counterpart of this PR is https://github.com/b2ihealthcare/snow-owl/pull/1052.


Simplify form navigation

Description
This PR updates the navigation across ingest and search. The main changes include:

automatic bottom bars that pop up if there are changes detected that will impact the resources created (or if creating for the first time). Within them, can either update the resources, or undo changes and revert to the last saved state. These also work to block the complexity around buttons being enabled/disabled which the users don't need to care about, as navigation is disabled by default while the bottom bar is present and changes need to be updated or reverted first.
state updates of the resources indicating if they are provisioned or not. Shows ingest state on ingest flow, and ingest/search states on search flow for easier visibility
simplifies search flow: rather than handling search within the update, it is now decoupled from the "Update" button. Instead, once successfully updated, we show a toast indicating as such, and automatically navigate to the "search" tab in the Inspector.
general simplification of the form - removing the EuiStepsHorizontal at the top, moving the enable/disable ingestion at the top, and minor rewordings
other: some prop reduction in some related components
other: adds callout in export modal if unsaved resources detected
other: adds quotes around workflow names in modals
other: fixes bug of search resources being created during provisioning on ingest if preset search form values configured (for the preset workflow usecases)

Testing:

custom/empty workflows work as expected
preset workflows with presets in ingest & search work as expected
skipping ingest works as expected
creation and update for ingest and search work as expected
update search -> test flow works as expected
lightweight guardrail testing / bug bashing. more to come later.

Next steps:

finalize if enable/disable can happen at other phases
finalize if deletion is supported on ingest at all (constraints on search pipelines entirely)

Demo video, overview & different states:
screen-capture (16).webm
Demo video 2, with a preset usecase & comparing to custom:
screen-capture (17).webm
Issues Resolved
Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Integ tests will fail until the PR gets reviewed, not blocking or related for this change


Bad, bad error message

I'm converting a WP site to Hugo.
Among the steps taken is to write some cleaning-scripts ... Apparently I did something wrong (or my regexp was a little bit too greedy):
ERROR: 2014/10/30 Unable to read frontmatter at filepos 2545: EOF
Which file?

Managed to come across this today (files to replicate:
https://github.com/DanRunfola/DanRunfola.github.io/tree/fc62523db31e29367553f68254f6f3cab2b77e3e
):
DEBUG 2018/02/07 14:21:14 Template path /home/datalab/Desktop/Git/DanRunfola.github.io/themes/academic/layouts/talk/single.html
DEBUG 2018/02/07 14:21:14 Add template file from path /home/datalab/Desktop/Git/DanRunfola.github.io/themes/academic/layouts/talk/single.html
DEBUG 2018/02/07 14:21:15 Load Data from 2 source(s)
ERROR 2018/02/07 14:21:15 unable to read frontmatter at filepos 249: EOF
ERROR 2018/02/07 14:21:15 unable to read frontmatter at filepos 467: EOF
ERROR 2018/02/07 14:21:15 unable to read frontmatter at filepos 235: EOF

I came across this today.


Unable to Join Room

I'm getting trouble with something, i've follow the steps to run with the correct config, but when I join the room, after about 1 second i get the notification "Unable to Join Room" and get redirected to root page. My ports are config:
`listeningPort         : 3443,
listeningRedirectPort : 8080,
turnAPIKey    : 'examplekey',
turnAPIURI    : 'turn:numb.viagenie.ca',
turnAPIparams : {
'uri_schema' 	: 'turn',
'transport' 		: 'tcp',
'ip_ver'    		: 'ipv4',
'servercount'	: '2'
},
// Backup turnservers if REST fails or is not configured
backupTurnServers : [
	{
		urls : [
			'turn:numb.viagenie.ca'
		],
		username<EMAIL_ADDRESS>		credential : 'muazkh'
	}
],
fileTracker  : 'wss://tracker.lab.vvc.niif.hu:443',`

I've opened in dev, and got the log:

I've tried to run on docker but got the same problem

Hey @AugustoZanoni. Take a look at this solution #529 , it might work for you.

@AugustoZanoni  did you find its solution?

@AugustoZanoni  did you find its solution?

Yes, sure. @pierguinzani posted a solution that helped me. You got to set your ip address locally of u want to test on your machine and set ur public IP if u want to deploy like this: {private:'<IP_ADDRESS>', announced:'172.999.9.99'}
You can comment on the turn server configs. It will use only stun servers. It's only needed to change the port on the server config. Because the app config it's already set 4443 for development. Hope it helps. Check the issue @pierguinzani  mentioned for further details


The app is not minimized when "Start app on login" is enabled

I confirm (by marking "x" in the [ ] below):

[x] This is not a troubleshooting question. Troubleshooting questions go here: http://www.mattermost.org/troubleshoot/.
[x] This doesn't reproduce on web browsers (such as in Chrome). If it does, issue reports go to the Mattermost Server repository.
[x] I have read contributing guidelines.

Summary
The app is not minimized to tray on system (Linux) start-up.
Steps to reproduce

Operating System: Antergos Linux x64, kernel 4.12.4-1
Mattermost Desktop App version: 3.7.0
Mattermost Server version: 4.0.0  (4.0.2-rc1)
Clear steps to reproduce the issue:

Go to File -> Settings
Check "Show icon in the notification area" option just to have a tray icon
Check "Leave app running in notification area when application window is closed" to always have tray icon
Check "Start app on login" option
Reboot your system

Expected behavior
The app is started minimized as stated in the description to "Start app on login" option ("The app will initially start minimized and appear on the taskbar.").
Checked desktop file used for autostarting the app:
[Desktop Entry]
Type=Application
Version=1.0
Name=mattermost-desktop
Comment=mattermost-desktopstartup script
Exec=/usr/lib/mattermost/mattermost-desktop --hidden
StartupNotify=false
Terminal=false

--hidden option is passed
Observed behavior
The app is not minimized.
Maybe useful links
There was already some discussing regarding this topic: https://github.com/mattermost/desktop/pull/230

Also maybe it will be good to have "Start app on login" and "Start app minimized" options separated (like in new Skype for Linux Beta). It will give user more control.

Closed via #571


Add GCWithHeap option to perfcollect

This also removes GCJoin and PinObjectAtGCTime events from GCCollectOnly option.
For #65.
cc @noahfalk @brianrob @maoni0

@sywhang thanks for doing this.  Just saw this change in my inbox.  Can you tell me what kind of testing you did on this?

@brianrob I tested it on my local box to verify we're not getting the events we don't want on GCCollectOnly option as well as the new option I just added. One thing I wanted to ask you - do we have any automated tests for perfcollect? If so I'd like to know where/how to run it because I couldn't find it in this repo.


why there are attentions in ResNet?

why? at first i thought this might be related to inplace_abn, then i checked the paper of inplace_abn, found no relevant info.

What I call attentions there is simply the ultimate feature maps of a resnet block (mod*) just before the ReLU.
For here x = ReLU(att).

What I call attentions there is simply the ultimate feature maps of a resnet block (mod*) just before the ReLU.
For here x = ReLU(att).

oh i understood, thanks


Changes in Shaka

Hi everyone,
I want to share with you some changes that are coming to the Shaka family of projects.  This will be cross-posted to shaka-player-users, shaka-packager-users, and the GitHub Issues pages of all of our projects.
Shaka is moving within Google
After 7.5 years of Shaka under Chrome/Widevine, the Shaka projects are moving.  The Cast team, who has been a primary user of Shaka Player within Google, will be taking over ownership of Shaka from Chrome/Widevine.  We look forward to a closer relationship with Cast!
Seeking volunteer maintainers
We are now offering members of the Shaka community an opportunity to share in maintenance responsibilities, such as responding to issues, reviewing and merging PRs, and making releases.  We think this is long overdue, and will help all Shaka projects move forward more quickly.
If you would like to volunteer as a maintainer for one or more of the Shaka projects, please email me privately at<EMAIL_ADDRESS>Infrastructure is moving to GitHub Actions
We are rewriting our internal tools and processes to make them more publicly accessible.  Having Google-only tools (and even some Google-only tests) has become a barrier for contributors and has slowed down our release timelines.
We are migrating all testing, release, and deployment infrastructure to GitHub Actions, and improving access as much as possible.  All contributors will be able to run the same tests and get faster feedback, and all maintainers will be equally able to create releases and deploy demos and docs.
We will also start sending our own contributions through the public PR process, rather than using a private code review process for Googlers.
Questions?
If you have any questions about these changes, please don't hesitate to ask!  You can email me privately at<EMAIL_ADDRESS>or ask publicly via the GitHub Issues pages for any of our projects.
https://github.com/google/shaka-packager
https://github.com/google/shaka-player
https://github.com/google/shaka-player-embedded
https://github.com/google/shaka-streamer
Joey, on behalf of the Shaka Team

Hey Joey & the Shaka Team,
Glad to see you're moving towards a more community driven approach, I bet this will definitely benefit Shaka in the long run.
I do have a question regarding the items and prioritization of the roadmap. With CAF being an internal Google project and Cast taking ownership, will the roadmap mainly be prioritized according to the needs of CAF?
Best regards,
Mat

With Cast taking ownership, the team at Google will be focusing our time on the priorities of CAF.
My current priority for all of our projects is test and release automation, publicly accessible infrastructure through GitHub Actions, selecting non-Googler maintainers, and documenting processes for those maintainers.  This is for the health of the projects and their communities, so that everyone can contribute more easily, so that we have a larger pool of reviewers and approvers for contributions, and so that every contributor can see their own needs and priorities met without Google being a bottleneck any longer.
(As a side-note, I just posted https://github.com/google/shaka-player/issues/3925 to gather feedback about our release strategy.  Let us know what you think, as this will influence the public maintenance processes and tools we're building.)
So right now, those are my top priorities, beyond any feature or fix.  Once these things are settled, we'll be turning our attention back toward features and bug fixes.

What are CAF's priorities going to be?

Right now our top priorities are to close the feature gaps between CAF's current HLS player (closed source) and Shaka Player, so that Shaka can take over HLS playback in CAF.  So lots of HLS work in the next couple of quarters.


[BUG] POE Error: message_points_display_price_mismatch

Describe the bug / 描述问题

To Reproduce / 复现步骤

Expected behavior / 期望行为

Screenshots / 截图
No response
Devtools Info / 开发者工具信息

OS and version / 操作系统版本
Windows 10
ChatALL version / ChatALL 版本
v1.58.88
Network / 网络
No
Additional context / 其它相关信息
No response

Same issues.
This is probably due to changes to POE's pricing method

still continue issue in latest version

still meet this issue in latest version

same issues
OS: windows 11
ChatALL: Version 1.61

This is important because I have poe payed, and few weeks have same error, I can't use it with your app

Error send prompt to GPT-4-32k@Poe: Error: message_points_display_price_mismatch
	at PoeBot.js:207:22
sendPrompt @ Bot.js:200

ChatALL-1.63.97-win-x64: Still error....

latest version still not works

Pls fix all Poe for next release

still continue issue in latest version

Poe still not work in latest "ChatALL-1.83.108-win-x64"


[UI] Scrollbar visible on settings button when sidebar is collapsed.

Explain the bug
When the sidebar is collapsed through the hamburger menu, the settings button in the bottom left will develop a scrollbar when the cursor is at the right of the button.
To reproduce

Open files
Collapse the sidebar via the hamburger menu at the top left.
Hover your mouse at the very right of the settings button.

Expected behavior
A scrollbar should not be visible when the sidebar is collapsed.
Logfile
not relevant
Screenshots
Add screenshots to help explain your problem if needed.

System Information

OS Version: Dev (OS Build 21332.1000)
App version: <IP_ADDRESS>

Additional comment
None

Happens to me too sometimes

I have this too and made an issue about it. Apparently it a WinUI bug that's suppose to be fixed in WinUI 2.6.

As mentioned by @josh-65, this issue will be resolved once WinUI 2.6 is released.


For provided gateway policies tab should request the same as regular DPP

What happened?
Currently it does the same as builtin gateway. It should be the same as regular DPPs (policies + rules and output of the first is SidecarDataplane.

@lahabana Are the following assumptions correct?
A DataplaneOverview represents a builtin gateway if DataplaneOverview.dataplane.networking.gateway.type === 'BUILTIN'.
A DataplaneOverview represents a delegated gateway in all other cases (i.e. DataplaneOverview.dataplane.networking.gateway.type is absent or a different value than 'BUILTIN').
I’m asking this because our types for the type field said 'builtin' | 'delegated' | undefined, but from looking at some example files in the backend code, it looks like (1) the value is actually all uppercase and (2) it doesn’t necessarily have a 'DELEGATED' value (I couldn’t find any actually).


fix: defer accepted/rejected status until the decision has been accepted in Ahjo (HL-1241)

Additional notes :spiral_notepad:
Only includes the old batch based solution as discussed. Checks for both this and for applicant-side archive status according to the new Ahjo integration will be implemented later.

API branch is deployed to platta: https://helsinkilisa-pr2903.api.dev.hel.ninja/healthz :rocket::rocket::rocket:

APPLICANT branch is deployed to platta: https://helsinkilisa-ui-pr2903.dev.hel.ninja :rocket::rocket::rocket:

HANDLER branch is deployed to platta: https://helsinkilisa-ui-handler-pr2903.dev.hel.ninja :rocket::rocket::rocket:

TestCafe result is success for https://helsinkilisa-ui-handler-pr2903.dev.hel.ninja :laughing::tada::tada::tada:


Auto-reorder  attributes with commands

This resolves #96 by adding two new custom commands to the client extension and the language server:

With Ctrl+Alt+S Ctrl+Alt+P the attributes of the <param> element under the cursor context will be reordered according to the IUC Code Style guidelines:

With Ctrl+Alt+S Ctrl+Alt+D all the <param> elements contained in the document will be processed and sorted at the same time:

The default key-shortcuts can always be redefined in the VSCode/Codium settings.
Many thanks to @bernt-matthias for suggesting this feature :)
TODO:

[x] Add a short description of the features in the readme.

Cool stuff. Looking forward to try this soon :)
May be extended to other tags in the future .. but I'm not even sure if IUC guidelines suggest an order for other tags.

Cool stuff. Looking forward to try this soon :)
May be extended to other tags in the future .. but I'm not even sure if IUC guidelines suggest an order for other tags.

Thanks!

May be extended to other tags in the future .. but I'm not even sure if IUC guidelines suggest an order for other tags.

I didn't find guidelines for other tags, but it is easy to extend to others so I'll be happy to add more in the future if it is helpful.

Thanks!

May be extended to other tags in the future .. but I'm not even sure if IUC guidelines suggest an order for other tags.

I didn't find guidelines for other tags, but it is easy to extend to others so I'll be happy to add more in the future if it is helpful.


don't vendor dependencies

Can you please make cmake stop downloading & building dependencies?

It doesn't work on air gapped build nodes.
It is unsafe because there is no checksum validation
It's not reproducible because you're building arbitrary versions (the master branch...).

Please just use find_package, find_library. At the very least make it possible to disable vendored dependencies.

Hi @haampie
Yes, agree with you on this. We have remove download and build of yaml-cpp with this commit.
Please try with latest master code base.
Thanks and Regards,
Junaid

@haampie we are using yaml-cpp with find_package() .
Closing this issue


bug: ignore in alfred is not working as intended

Workflow version

ignore in Alfred v2022.2

Alfred version

Alfred 5.0.5 [2096]

macOS version

Ventura 13.0.1

Debug Output
[22:37:07.448] Logging Started...
[22:37:15.479] Ignore in Alfred[File Action] Processing complete
[22:37:15.480] Ignore in Alfred[File Action] Passing output '/Users/jaw/flutter' to Automation Task
[22:37:15.482] ERROR: Ignore in Alfred[Automation Task] Task not found 'com.alfredapp.automation.core/files-and-folders/path.tags.add'

More Details
Hi, I am trying to exclude flutter sdk from my home directory. Somehow it is not being excluded. I have restarted my system multiple times. Removeed and Re-added the ignore in alfred workflow multiple times. I have also excluded the flutter folder in spotlight indexing multiple times. Am I missing anything here?

The debug log explains it, you’re missing the Automation Task. Double-click the object in the canvas (it has red in it) and update from it.
The Spotlight privacy is a different method. For that not to work, there may be a problem with your index. But one thing at a time, do the above first.

The debug log explains it, you’re missing the Automation Task. Double-click the object in the canvas (it has red in it) and update from it.
The Spotlight privacy is a different method.
For folders directly under you home, go to Alfred Preferences → Features → Default Results and Reset the Search Scope to Applications and Home.


GitHub file_url API for import_dangerfile

danger.import_dangerfile(github: 'foo/bar') was not respecting the DANGER_GITHUB_HOST setting.
The file_url implementation now calls the API to get the actual download_url of a GitHub file.
import_dangerfile now works with private repos and GitHub Enterprise :D
Fixes #770
@orta Please review

          1 Message

:book:
@hotbott is not a contributor yet, would you like to join the Danger org?

  Generated by :no_entry_sign: Danger

argh - rubocop updates

Ah - nice one @hotbott - thanks!

Shipped to Rubygems


Gpu optimization on Ultrascale+MPSoC

Hi everyone!
I am running armnn on ultrascale+MPSoc with Mali gpu.
If i set my optimizer for Cpu , it works correctly:
armnn::IOptimizedNetworkPtr optNet = armnn::Optimize(*network, {armnn::Compute::CpuAcc}, runtime->GetDeviceSpec());
Instead, if i enable the optimization for Gpu, optNet will be a NULL pointer and obviously it goes on segmentation fault.
armnn::IOptimizedNetworkPtr optNet = armnn::Optimize(*network, {armnn::Compute::GpuAcc}, runtime->GetDeviceSpec());
Do you know why this is happening?

Hi @GAnto85 you should turn on logging (see armnn/Utils.hpp) to see the reason for failing to optimise the network.
I believe the reason for you is that the Mali-400 GPU in the Ultrascale+ does not support OpenCL, which is needed for Arm NN GPU acceleration.

Ah I can see from your other post that logging is not being helpful for you - can you show how you are calling armnn::ConfigureLogging?

Yes sure! Here is the main code:
int main(int argc, char** argv)
{
armnn::ConfigureLogging(true, false, armnn::LogSeverity::Debug);

// Load image
const std::string path = argv[1];
InferenceTestImage image(path.c_str());
std::vector<float> input = image.Resize(224, 224, CHECK_LOCATION(), InferenceTestImage::ResizingMethods::BilinearAndNormalized,
                                            {{0.485f, 0.456f, 0.406f}}, {{0.229f, 0.224f, 0.225f}});

//std::cout<<"input size: "<<input.size()<<std::endl;

// if DataFormat = NCHW
const armnn::PermutationVector NHWCToArmNN = { 0, 2, 3, 1 };
armnn::TensorShape dstShape({1, 3, 224, 224});
std::vector tempImage(input.size());
armnnUtils::Permute(dstShape, NHWCToArmNN, input.data(), tempImage.data(), sizeof(float));
input.swap(tempImage);
std::cout<<"Image loaded \n";

// Import the Onnx model. Note: use CreateNetworkFromBinaryFile for .pb files.
armnnOnnxParser::IOnnxParserPtr parser = armnnOnnxParser::IOnnxParser::Create();
armnn::INetworkPtr network = parser->CreateNetworkFromBinaryFile("mobilenetv2-1.0.onnx");

std::cout<<"Onnx model imported \n";

// Find the binding points for the input and output nodes
armnnOnnxParser::BindingPointInfo inputBindingInfo = parser->GetNetworkInputBindingInfo("data");
armnnOnnxParser::BindingPointInfo outputBindingInfo = parser->GetNetworkOutputBindingInfo("mobilenetv20_output_flatten0_reshape0");

//std::cout<<"Binding points set \n";

// Optimize the network for a specific runtime compute device, e.g. CpuAcc, GpuAcc
armnn::IRuntime::CreationOptions options;
armnn::IRuntimePtr runtime = armnn::IRuntime::Create(options);
armnn::IOptimizedNetworkPtr optNet = armnn::Optimize(*network, {armnn::Compute::GpuAcc}, runtime->GetDeviceSpec());

if(optNet != NULL)
  printf("optNet is NULL \n");

// Load the optimized network onto the runtime device
armnn::NetworkId networkIdentifier;
runtime->LoadNetwork(networkIdentifier, std::move(optNet));

std::cout<<"Network loaded \n";

// Run a single inference on the image
std::array<float,1000> output;

armnn::InputTensors inputTensors{{0, armnn::ConstTensor(runtime->GetInputTensorInfo(networkIdentifier, 0),
                                                        input.data())}};
armnn::OutputTensors outputTensors{{0, armnn::Tensor(runtime->GetOutputTensorInfo(networkIdentifier, 0),
                                                     output.data())}};

armnn::Status ret = runtime->EnqueueWorkload(networkIdentifier, inputTensors, outputTensors);

std::cout<<"Inference done \n";

// Classification
int maxout = std::distance(output.begin(), std::max_element(output.begin(), output.end()));
maxout++;
//std::cout << "Max output: " << maxout << std::endl;

Classify(maxout);

return 0;

}

Hmm, that looks correct, and I would have expected you to see error messages about OpenCL not working. I'll raise that issue internally.
In any case, GPU acceleration will not work on a Mali-400MP2.

Thank you for the info! Saved me a lot of work!

Yes it gives me an error by the way:
ArmNN v20190200
ERROR: None of the preferred backends [GpuAcc ] are supported. Current platform provides [CpuAcc CpuRef ]


use sql query in .moor file with a table declared in dart code

Is it possible to define a sql query in a .moor file which use a table declared in dart?
(ie use the .moor file only for some queries and not for declaring the tables)
I tried and got an error...

It's possible, with the current limitation that files you import from moor must be imported from the @UseMoor and @UseDao files. So let's say you had three files: a.dart, b.moor and c.dart. In that case,
// a.dart
@UseMoor(include: {'b.moor'})
class Database extends _$Database

-- b.moor
import 'c.dart';

// c.dart
class SomeTable extends Table {
  // ...

would NOT work. But if you change a.dart to
// a.dart, updated
import 'c.dart'; // import here so that the moor file can import it

@UseMoor(include: {'b.moor'})
class Database extends _$Database

it should work.

This is a limitation of Dart's build system. There's a more recent version available that doesn't have this limitation, but it's in conflict with the analyzer_plugin package moor also uses. I've opened a tiny PR to fix this around two months ago, but so far not much happened :( This is also blocking #103, so you can believe it's very annoying for me as well.


Hover effects on icons in team section

Hey ! can I contribute on this issue ?

can you once confirm, that if I get the opportunity to contribute, then I have to create hover effects on those classes write?

Hey @Soham56 Wait till 1st jan , after that I will surely assign the issue to you.

Thank you so much @Chaitalishetty, I guess you want to say 1st February write?
Ok, no problem.

I can contribute on that issue

Thank you so much @Chaitalishetty, I guess you want to say 1st February write?
Ok, no problem.

Oh sorry 😂 , 1st Feb.

It's ok 😊

I also wanna contribute to this issue

Do check the readme section.

Hey, This is Sangh Priya Gautam .I am intrested in contributing to this project but how can i work in this project .

I want to work on this issue under JWOC.

hello, I would like to work on this issue

I want to work on this issue under JWOC

@Arun5023 Assigning this issue to you . Happy Coding !

I want to contribute in this issue .

I want to work on this issue under JWOC


No type check for models (TypeScript)

Hi,
I have an example model in TypeScript. However even I access wrong field names type-check does not detect those.
export default class Category extends Model {
  static entity = "categories";

  static fields(): Fields {
    return {
      id: this.string(""),
      name: this.string().nullable(),
      items: this.hasManyBy(Item, "itemIds"),
    };
  }

  id!: string;   // Notice `!`. Tell TS that this property is always defined in class.
  name: string | null;
  items!: Item[];
}

const categories = Category.query()
  .with("items")
  .get();

const direct = new Category();

// Below code passes typescript check without errors:
console.log(categories.xyz);  // I expected error: Property 'xyz' does not exists on "..."
console.log(direct.xyz);  // // I expected error: Property 'xyz' does not exists on "..."

One of the reasons of this is [key: string]: any usage in Model.ts and some other places. As you, of course, know this destroys all benefits of typescript.
How can we benefit type checks in vuex-orm models? Or is there any particular reason for current situation?
I'm not TS expert, but this may be solved using TypeScript Generics, keyof and typeof keyof T etc.
interface CategoryInterface {
...
}

export default class Category extends Model<CategoryInterface> implements CategoryInterface {
...
}

export default class Model<T> {
...
}

Yes wonderful! I've checked the PR and will make a release soon!

Hey all! 👋
Has this been released yet?

@RomainLanz Yes it should!

Related to this - is there any way we can get type safety when updating a record with a payload?
Category.update(
  { data: { name: 'category name' }, where: 1 }  // OK
)
Category.update(
  { data: { madeUpProperty: 'value' }, where: 1 }  // Fails silently
)

Ah, currently not. We can't 100% make sure that to fail because there're no easy way of getting maps for schema properties. For example, if your model have public property called mapUpProperty (and not in fields definition), it will not throw type error but it will fail to update such a property.
Maybe we can do a bit better in Vuex ORM Next though.


Correction for raw affiliation Service de rhumatologie, Centre hospitalier Narbonne, Narbonne, France

Correction needed for raw affiliation Service de rhumatologie, Centre hospitalier Narbonne, Narbonne, France
raw_affiliation_name: Service de rhumatologie, Centre hospitalier Narbonne, Narbonne, France
new_rors:
previous_rors: 022m8c549
works_examples: W4386423747
contact: 7c651c42dbb26ed72ac2e16041554e0b:085156101864ccb8ea3591fb8107a9b8fa5e @ inrae.fr

This issue was accepted and ingested by the OpenAlex team on 2024-10-10. The new affiliations should be visible within the next 7 days.


Moved Debian/Raspbian/Ubuntu installations to OpenJDK JRE 11 due to OpenJDK JRE 8 instabilities

Some Greengrass Lambda functions that are in development, in particular the LLRP functions, cause OpenJDK's JRE 8 to crash. This update uses OpenJDK's JRE 11, which doesn't crash, and symlinks it to java8 so Greengrass can use it.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Running integration tests

Issues with CDDSkeleton, fixing...

Fixed. All tests passed.


fixbug: store constraint issue

branch: feature/0.40.0

Hi, there's some trouble with store constraint.
when I write:
let storedConstraint: Constraint? = nil
someView.snp.makeConstraint({ (make) in
       // ConstraintDescription will create a constraint and store it to `constraint.layoutConstraints`
        storedConstraint = make.someConstraint.equalTo(someValue).constraint
})
//when execute this closure, constraint will be created **again**
// ...some other code

storedConstraint.deactivate()   // this may do nothing, because storedConstraint may not hold the truely layoutConstraint

someView.snp.make.Constraint({ (make) in
        // some new constraints setting
})

@NSLogMeng I believe this is dupe of #285

This is fixed thanks to #285