setTransitionName not working within RecyclerView

First off, thank you for this amazing library. It is simple and beautiful!
Now onto the issue: I added setTransitionName() to my RecyclerVIew and it helped, but it didn't catch all the views. My ViewHolder consists of the parent item View, an ImageView, and a TextView. I used setTransitionName() on all three, making sure each name is unique:
holder.mNameView.setText(name);
TransitionManager.setTransitionName(holder.mView, name);
TransitionManager.setTransitionName(holder.mIconView, name + "icon");
TransitionManager.setTransitionName(holder.mNameView, name + "name");

I have uploaded a short video to demonstrate the issue.
Also, the three files I use TransitionsEverywhere in my project are here, here, and here, just search for "TransitionManager".
Perhaps I am doing something wrong or it's a bug.

Hi,
Its hard to use transitions for recycler view because recycler view has some complex asynchronous layout logics.
So, why don't you just use build-in animation from recyclerview? I mean in your case you could

call appropriate notifyInserted, notifyChanged methods from the adapter
do the same things in a more clever way with DiffUtils
apply stable ids for adapter.

Thanks @andkulikov, great suggestions and I'll give one of those options a shot. Probably DiffUtils, seems easiest to implement in my app.


Shapes 7

Please check to make sure Bezier line support is added desirably. Otherwise, this should be good to merge.

It's probably better to just add control point slots %control-point-1 & %control-point-2 to line-2d. If both are given, we draw a cubic curve, if one is given we draw a quadratic curve, if none are given we draw a line.

It's probably better to just add control point slots %control-point-1 & %control-point-2 to line-2d. If both are given, we draw a cubic curve, if one is given we draw a quadratic curve, if none are given we draw a line.

But an issue with this approach is we don't get the nice automatic cubic Bezier that draw-line-bezier gives us. So maybe the %bezier slot could specify one of :auto, :quad, or :cubic. :auto for draw-line-bezier, :quad for draw-line-bezier-quad using %control-point-1, and :cubic as you'd expect.

Actually... couldn't we just keep it a boolean?
NIL = straight line
T with no control points = auto bezier
T with one point = bezier quad
T with two points = bezier cubic

This (https://github.com/defun-games/claylib/pull/23/commits/4a5829c46e3cd1417437afe0b454322bd52c3e0a) works, but I'd like to make constructing the args list conditionally with some repeated args more elegant. I tried this solution, which also works, but is a tiny bit slower and not much prettier:
(defmethod draw-object ((obj line-2d))
  (let* ((bezier (bezier obj))
         (pt (control-pt obj))
         (pt2 (control-pt2 obj))
         (first-args (list (c-struct (start obj))
                           (c-struct (end obj))))
         (last-args (list (thickness obj)
                          (c-struct (color obj))))
         (fn (cond ((and pt2 pt bezier) (progn
                                          (setf last-args (cons (c-struct pt)
                                                                (cons (c-struct pt2) last-args)))
                                          #'claylib/ll:draw-line-bezier-cubic))
                   ((and pt bezier)     (progn
                                          (setf last-args (cons (c-struct pt) last-args))
                                          #'claylib/ll:draw-line-bezier-quad))
                   (bezier              #'claylib/ll:draw-line-bezier)
                   (t                   #'claylib/ll:draw-line-ex))))
    (apply fn (nconc first-args last-args))))

I'd rather not sacrifice any performance in a draw method... Any suggestions are appreciated.

First of all, how much slower is "a tiny bit" and how did you measure this? Enough to be a notable concern or just premature optimization?
A few suggestions for elegance off the top of my head:

A c-structs function to get the structs of multiple things at once
Use a macrolet or just a macro
Separate the cond part into its own flet or function

Just premature optimization. Both solutions should have the same time complexity, but the one pasted above is 10-30 thousand cycles slower (as measured by wrapping draw-object's body in a time call) depending on the method (line/auto/quad/cubic).
I will fix this soon, thanks for the input!

I think this'll have to do. From the most recent commit message:
"This is close to as good as we can get performance and readability
wise, as far as I can tell. The crux of the issue is we can't get
around listing the functions and arguments to pick from without
sacrificing performance. Any attempt to dynamically build the args is
slower than just picking from a known execution path."

Nah, I think this is good actually. Was going to suggest a macro of some kind to remove repetition but you did a pretty good job of that; I don't think it's needed.


Command logging

When writing shell scripts, it could be useful to have a traditional Makefile style command log output.
One way to achieve this could be to just duplicate each line of the script as an associated echo, then have a special option for this in the command engine like shell-log = true or similar.
A global option could also be available with per-task configurations, effectively replacing the current debug.

The main difficulty here is parsing the lines requires a powershell parser... since there is no "echo" mode for powershell.
The alternative is to log the entire command verbatim upfront, regardless of how long it is, similar to debug. Perhaps that is the primary use case anyway.

This is now implemented in https://github.com/guybedford/chomp/pull/88 with a global and per-task echo field. Release will be when it's ready.


500 exceptions if token is invalid

If the user-provided token is invalid, then the API throws a 500 error which is unacceptable and incorrect, as it should return a 400/401/403 response.
This might be related to the error handler, when debugging this the behavior with debug mode enabled will have to be enabled (since there, the error handler is disabled)

fixed by commit 53c7965


Individual API Key not supported

Issue Description
Attempted to use an Individual API Key for the Account Holder to manage the Developer ID Certificate.  It is not possible to do so through a regular API Key.
Command executed
match with JSON key path
Complete output when running fastlane, including the stack trace and command used
[!] The request could not be completed because:
	Authentication credentials are missing or invalid. - Provide a properly configured and signed bearer token, and make sure that it has not expired. Learn more about Generating Tokens for API Requests https://developer.apple.com/go/?id=api-generating-tokens

Environment

I'm experiencing the same issue with<EMAIL_ADDRESS>Normal Team API Key worked perfectly, but if I try to use an individual Key it fails on the upload_to_tesflight step.
app_store_connect_api_key step does not throw any error.
This is the error I get if I run with --verbose
Authentication credentials are missing or invalid. - Provide a properly configured and signed bearer token, and make sure that it has not expired. Learn more about Generating Tokens for API Requests https://developer.apple.com/go/?id=api-generating-tokens
Token has expired, issued-at-time is in the future, or has been revoked! Trying to refresh...

The process for generating a token from an Individual API Key is a little different, so the app_store_connect_api_key step will probably need changes. The important difference is that Individual API Keys don't use the iss key in the JWT payload, and requires the sub key instead.
https://developer.apple.com/documentation/appstoreconnectapi/generating_tokens_for_api_requests

same issue here

### Azure DevOps API Key Issues for deploying to Apple
To get this to successfully work on Azure DevOps Pipeline with an API Key. I ran into so many problems and tried everything I could find and this finally worked.  Azure DevOps says you need use the base64 key.  Well if you open up the .p8 and copy the base64 encoded string in there, that isn't what they want.  They literally want you to copy all of the contenxt in the .p8 file to a base64 string. Don't modify the .p8 file.  I found the solution at the follow source, and once you get the data.b64 file open it and copy the base64 string in that file.  In the following article is discusses how to do this for Windows, Mac, and Ubuntu.
https://github.com/fastlane/fastlane/issues/21531#issuecomment-1873633417

Did you manage to upload builds using an individual API key? If I omit issuer_id I get an error from altool:
[altool] 2024-06-11 09:56:44.263 *** Error: Unable to upload archive. You must specify both '--apiKey' and '--apiIssuer'. (-1011)
Adding back issuer_id gives me an authentication error instead:
[altool] 2024-06-11 10:20:08.361 *** Error: Unable to upload archive. Failed to authenticate for session
I get a feeling uploading apps using an individual API key isn't supported?

@neorth

I get a feeling uploading apps using an individual API key isn't supported?

Currently, spaceship supports individual API key but deliver doesn't.
See https://github.com/fastlane/fastlane/issues/22115 for the detail.

@manicmaniac
I was trying to upload to Testflight (using the pilot command). Got an official response from Apple that altool (that's used by pilot) doesn't support individual API keys: https://forums.developer.apple.com/forums/thread/756929
I guess spaceship and/or deliver dosn't support uploading to Testflight?

@neorth

I guess spaceship and/or deliver dosn't support uploading to Testflight?

Although altool doesn't seem to support Individual API Keys, it is possible to upload builds using an app specific password.
The above issue (#22115) shows how to do this as a workaround.

I did use an individual API key, using the direction I posted above.

@neorth
Right now I opened a draft PR to resolve the issue. #22128
However I think it needs some more testing in real world so I will do it in the next some weeks.
If you want to use deliver or pilot with Individual API Key soon, try it and give me feedback, thank you.

That's great news, good job! I will be on vacation for the next few weeks and unfortunately won't be able to test until late July at the earliest.

The match and sigh – two another tools that do not support individual keys yet

I've tested https://github.com/fastlane/fastlane/pull/22128 and the test passed. The PR is now ready for review.

Do we have a timeline on when the other tools (match, sigh) are going to support individual key?


Non-data fields - Metadata fields to Kafka Connector

enabling users to query using the following syntax -
create table users (
    id TEXT,
    name TEXT,
    offset BIGINT GENERATED ALWAYS AS (metadata('offset_id')) STORED
) with (
    connector = 'kafka',
    ...
);

Demo -

@mwylde can you please trigger the CI again? I am asking because my last commit ran successfully, the failed CI is on master merge.


fix: correct Arbiturm blocktime hint

Recent average block time of Arbitrum is around 0.26s. Data is from https://arbiscan.io/chart/blocktime (download csv)

superseded by #62
closing, opened from main


Update introduction.md

more specific on where you click Edit to change ... so this is my meta-edit!

Thank you for your contribution, we have accepted this into the content set and the page will be updated as soon as the content build process is complete later today.


Bluetooth permission check in Android <= 30

The BLUETOOTH_CONNECT permission does not exist on Android <= 30, so this will always fail.
https://github.com/orbital-systems/react-native-esp-idf-provisioning/blob/b0e240de206abb27a1b7ce46a656d12540c2d89c/android/src/main/java/com/espidfprovisioning/EspIdfProvisioningModule.kt#L161
In fact permission checks seem a bit inconsistent in general. 🤔

Sidenote: It seems you do not need to grant permissions on lower android version, but maybe the permission checks are usefull to ensure bluetooth is enabled in general?
cfr. https://github.com/zoontek/react-native-permissions/issues/468

Thanks for clearing this up! I can currently only test for Android >30 at work so I naively assumed it would return PERMISSION_GRANTED for <= 30.
As for the sidenote; yeah I think it could be useful for developers to know if their users have accidentally disabled bluetooth permissions in system/app settings. But as I can't test lower android versions right now, it's hard to know if the current check is sufficient.

Released in version 0.2.9, feel free to open again.


Add elasticsearch alerts.

Adapted from https://grafana.com/dashboards/2322. Note: the elastic exporter emits green as 0, yellow as 1, and red as 2: https://github.com/justwatchcom/elasticsearch_exporter/blob/master/exporter.go#L568-L578.
I made the alert on yellow optional, since elastic clusters might be yellow for a long time during a rolling restart.
cc @cnelson @LinuxBozo

Thanks for reviewing! Just updated.

Updated again 😅

Thanks @jmcarp!


Small Pointer

One thing that tripped me up was the naming conventions, NotesPage.xaml.cs is NOT the same as Notespage.xaml.cs !, Either way awesome tutorials !

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 60587f77-05de-89b9-8a08-c7e7221d27af
Version Independent ID: 4080b687-b353-f833-4bb7-a7a3f9993338
Content: Perform navigation in a multi-page Xamarin.Forms application - Xamarin
Content Source: docs/get-started/quickstarts/multi-page.md
Product: xamarin
Technology: xamarin-forms
GitHub Login: @davidbritch
Microsoft Alias: dabritch

Thanks for the feedback @CoolinJack


Fix for older Visual Studio

Tried to initialize a vector with a list.  Can't do that in
the older VS.

Thank you for fixing, but we we are going to go with PR#574.


Add cqlsh LWT test for CASSANDRA-11003

This test simply checks that we can execute LWT operations without an error in cqlsh.

Test logic looks good, and thanks for fixing those linter errors. I've run the test locally on the patched branches linked here, where it passes as expected. Each of the assertions failed
as expected on unpatched trunk.
Could you please apply the commit I've put on top of yours here:
https://github.com/mambocab/cassandra-dtest/tree/pr-768
It's just a little refactoring for readability and better error messages. Of course, feel free to clean it up if you have opinions, but make sure the error messages still include the output string and the statement executed. Once that's applied and CASSANDRA-11003 is resolved, go ahead and merge, or ping me for merge.

Thanks for the cleanup commit!  That looks good, so I've cherry-picked it into the branch.


[kibana stats] ingest each kibana request processed by Gatling

Summary
This PR enables Gatling tracing logs to capture requests information (url, body, headers, status, etc) and saves it to response.log file. Before ingestion the file is parsed into the list of Response objects, each of them is later merged with corresponding Response object to have valid request start/end time. In addition, new index with data representing concurrent users during simulation was added.

Checklist
Delete any items that are not applicable to this PR.

[ ] Branch is successfully tested on Kibana CI
[x] Unit tests are added

@dmlemeshko hey man, I noticed the response body seems to be always binary.  Is it ever not binary?
Also, if it's always binary, is it retrievable at all?
If it is not retrievable, do we need this stanza to be ingested?

@dmlemeshko hey man, I noticed the response body seems to be always binary. Is it ever not binary?

its not always binary, it depends on request: /bsearch returns it quite often.

Also, if it's always binary, is it retrievable at all?
If it is not retrievable, do we need this stanza to be ingested?

Gatling does not retrieve it, but tbh it won't give any reasonable info even it will be retrieved. The idea of ingesting response is to catch possible errors ES returns in case of errors. Since I read file line by line I think it makes sense to ingest all requests because it might be useful checking the whole sequence in case of failure, and for this purpose we need other (successful) requests

Hey mate, did you mean to commit the response.log file?

@wayneseymour for test purpose, I tried to keep it small :)

Hey mate, did you mean to commit the response.log file?

@wayneseymour for test purpose, I tried to keep it small :)

Ahhh, makes sense!


Drop astroML dependency

Use crossmatch from astropy to drop astroML dependency.
Used in utils.py
https://github.com/toros-astro/ProperImage/blob/f4e78943cc1306ec464c6cc8e688b57b55d9b64a/properimage/utils.py#L45
and in no other file.

Seems like astropy's cross matching doesn't allow for cross-matching in x, y.
This is the relevant code from astroML:
X1 = np.asarray(X1, dtype=float)
X2 = np.asarray(X2, dtype=float)

N1, D = X1.shape
N2, D2 = X2.shape

if D != D2:
    raise ValueError('Arrays must have the same second dimension')

kdt = cKDTree(X2)

dist, ind = kdt.query(X1, k=1, distance_upper_bound=max_distance)

return dist, ind

We will implement this directly.


Provide PowerShell ARM Template directly without REST and update documentation

The page shows how to create a subscription via a REST, not a powershell deployment which most of us would normally use.
If the ARM template can be applied using New-AzTenantDeployment, can you please include the documentation for it and update this page: https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/deploy-to-tenant?tabs=azure-cli ?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: bd3632da-89e0-cbd4-2d92-311eaacd33b3
Version Independent ID: 9a59177a-4183-cdd8-dee3-9dbeca53544b
Content: Programmatically create Azure subscriptions with the latest APIs
Content Source: articles/cost-management-billing/manage/programmatically-create-subscription.md
Service: cost-management-billing
Sub-service: billing
GitHub Login: @bandersmsft
Microsoft Alias: banders

@jdelforno Thanks for your comment! We will review and provide an update as appropriate.

@jdelforno You have REST API, PowerShell as well as CLI options to create Azure Subscriptions Programmatically in EA:

Reference: https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/programmatically-create-subscription?tabs=rest-getEnrollments%2Cazure-powershell-EA%2Crest-getBillingAccounts%2Crest-getBillingProfiles%2Crest-MCA%2Crest-getBillingAccount-MPA%2Crest-getCustomers%2Crest-getIndirectResellers%2Crest-MPA#create-subscriptions-under-a-specific-enrollment-account

@jdelforno Have you had a chance to see the previous response? Feel free to reach out to us if you've additional questions in this regard.

@jdelforno We haven't heard back from you, so we will now close this issue. If this remains an issue, please reply and we will gladly continue the discussion.

Hi Guys,
Apologies for the late response.
The point of contention is that the page states to call a REST endpoint to apply an ARM Template.
Surely we should be able to simply run an ARM Deployment via PowerShell, as per: https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/deploy-to-tenant?tabs=azure-cli
Cheers,
John

@jdelforno The page https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/programmatically-create-subscription?tabs=rest-getEnrollments%2Cazure-powershell-EA%2Crest-getBillingAccounts%2Crest-getBillingProfiles%2Crest-MCA%2Crest-getBillingAccount-MPA%2Crest-getCustomers%2Crest-getIndirectResellers%2Crest-MPA#create-subscriptions-under-a-specific-enrollment-account already has PowerShell commands to programmatically create EA Subscription.
The first REST API command is only used to check which accounts the user have access to create EA Subs programmatically.
Can you please further elaborate your exact requirement.


Add generated source map to Karma's file object

Found a solution for the misaligned lines/columns.
Fixes #36
Before:

at UserContext.it (main.spec.js:14:17)

After:

at UserContext.it (src/main.spec.js:7:15 <- main.spec.js:14:17)

@jlmakes
I am not sure how to add tests that would actually test this change.
Also, this would obliterate any sourceMap that exists from a prior preprocessor/plugin if any. Taking prior source maps into account would likely require similar logic to what is in karma-coverage. Don't know if you want to add dependencies, and I thought the 1-liner would be an easier pill to swallow.

In your estimation @Lalem001, what other use cases would have upstream preprocessors? It seems like a reasonable fix for most cases to me.

I cannot think of any. I agree it is a reasonable fix for most cases.

Hey @lephyrus thanks for your contributions! I’m going to make sure to cut a new release shortly, but I was hoping you could also share your opinion on this PR as well.

@jlmakes @Lalem001 This is wonderful. For our project, it turns
Expected false to be true.
            at UserContext.<anonymous> (src/specs.ts:92368:70)

into
Expected false to be true.
            at UserContext.<anonymous> (src/platform/browser.spec.ts:29:59 <- src/specs.ts:92160:70)

So that can be massively helpful and I was actually missing that mapping. Luckily, it also doesn't screw up other source mappings (for coverage reports, for in-browser debugging). So a clear 👍 from me.


elisa: 0.2.1 -> 0.2.80

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/elisa/versions.
meta.description for elisa is: '"Elisa Music Player"'.
Compare changes on GitHub

Checks done (click to expand)

built on NixOS
Warning: no invocation of /nix/store/1wx0hbih6l960fp1dj1y06gmz8y675ff-elisa-0.2.80/bin/elisa had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/1wx0hbih6l960fp1dj1y06gmz8y675ff-elisa-0.2.80/bin/.elisa-wrapped had a zero exit code or showed the expected version
0 of 2 passed binary check by having a zero exit code.
0 of 2 passed binary check by having the new version present in output.
found 0.2.80 with grep in /nix/store/1wx0hbih6l960fp1dj1y06gmz8y675ff-elisa-0.2.80
directory tree listing: https://gist.github.com/f3f48c3217059fc6a730577f7ba301e6
du listing: https://gist.github.com/8496db1568298b4833e59bf2c5d533ca

Instructions to test this update (click to expand)

One-time optional setup to skip building using Cachix:

Install cachix from https://cachix.org/
Use r-ryantm's cache:cachix use r-ryantm

Test this update by entering a nix shell, seeing what is inside the
result, and if applicable, running some binaries:
nix-shell --pure -I nixpkgs=https://github.com/r-ryantm/nixpkgs/archive/ce6debe9006544ab39ee25e7106d9726c37b928e.tar.gz -p elisa
ls -la /nix/store/1wx0hbih6l960fp1dj1y06gmz8y675ff-elisa-0.2.80

cc @peterhoeg for testing.

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: elisa
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on aarch64-linux (full log)
Attempted: elisa
Partial log (click to expand)
shrinking /nix/store/ymc9mjjsx0i8bl3jaxj3r9ymahhdqhf0-elisa-0.2.80/lib/qt-5.11/plugins/kcms/kcm_elisa_local_file.so
shrinking /nix/store/ymc9mjjsx0i8bl3jaxj3r9ymahhdqhf0-elisa-0.2.80/lib/qt-5.11/qml/org/kde/elisa/libelisaqmlplugin.so
shrinking /nix/store/ymc9mjjsx0i8bl3jaxj3r9ymahhdqhf0-elisa-0.2.80/lib/libelisaLib.so.0.1
strip is /nix/store/y4ymnvgxygpq05h03kyzbj572zmh6zla-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/ymc9mjjsx0i8bl3jaxj3r9ymahhdqhf0-elisa-0.2.80/lib  /nix/store/ymc9mjjsx0i8bl3jaxj3r9ymahhdqhf0-elisa-0.2.80/bin
patching script interpreter paths in /nix/store/ymc9mjjsx0i8bl3jaxj3r9ymahhdqhf0-elisa-0.2.80
checking for references to /build in /nix/store/ymc9mjjsx0i8bl3jaxj3r9ymahhdqhf0-elisa-0.2.80...
postPatchMkspecs
postPatchMkspecs
/nix/store/ymc9mjjsx0i8bl3jaxj3r9ymahhdqhf0-elisa-0.2.80

Success on x86_64-linux (full log)
Attempted: elisa
Partial log (click to expand)
shrinking /nix/store/1wx0hbih6l960fp1dj1y06gmz8y675ff-elisa-0.2.80/lib/qt-5.11/plugins/kcms/kcm_elisa_local_file.so
shrinking /nix/store/1wx0hbih6l960fp1dj1y06gmz8y675ff-elisa-0.2.80/lib/qt-5.11/qml/org/kde/elisa/libelisaqmlplugin.so
shrinking /nix/store/1wx0hbih6l960fp1dj1y06gmz8y675ff-elisa-0.2.80/bin/.elisa-wrapped
strip is /nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/1wx0hbih6l960fp1dj1y06gmz8y675ff-elisa-0.2.80/lib  /nix/store/1wx0hbih6l960fp1dj1y06gmz8y675ff-elisa-0.2.80/bin
patching script interpreter paths in /nix/store/1wx0hbih6l960fp1dj1y06gmz8y675ff-elisa-0.2.80
checking for references to /build in /nix/store/1wx0hbih6l960fp1dj1y06gmz8y675ff-elisa-0.2.80...
postPatchMkspecs
postPatchMkspecs
/nix/store/1wx0hbih6l960fp1dj1y06gmz8y675ff-elisa-0.2.80


Task Sequence

Is there a way to order tasks like TaskSequence in locust?

It's easy to run in sequence, (e.g., put the code of multiple tasks in one boomer.Task), or you can implement a TaskSet like WeighingTaskSet

Thanks!


Not using image resize function.

https://github.com/BuildFire/sdk/wiki/How-to-use-ImageLib
Scroll to the bottom of the page and make sure we use this to ensure we are always getting the fastest load times.

Hey Ian, in issue https://github.com/deepakshrma/peoplePlugin/issues/24 we have to force the image dimension using css and show cropped image. I have done it using css and buildfire.imageLib.cropImage() and it is working fine. I don't understand where do I need to use resize() method?

Done. please review.
Now small images are being loaded in case of thumbnails. Also fixed carousel images image dimension issue.


Use cargo script for running code.

I've been using cargo scriptfor running code easily on my computer, it'd be nice to be able to use it the same way online. The main benefit here is with the way you can specify external crates. Related to #67.

Would something like this be in favor? Are caching crates the main issue?


Implement image.min() and image.max()

Function that allow you to get the min and respectively max value in the whole image for a given channel.

There is already a function doing this in utils : getMinMax().


Portal has changed

Home Assistant version
2024.12.5
Hochwasserportal integration version
1.0.1
Affected pegel
NW_2725910000100
What happened
Integration isn't able to complete "setup"
https://hochwasserportal.nrw/lanuv/data/internet/stations/stations.json
now returns an 404:
Not Found
The requested URL was not found on this server.
See log:
Setup of NW_2725910000100 failed: nw_api.py: init_NW(): HTTPError: 404 Client Error: Not Found for url: https://hochwasserportal.nrw/lanuv/data/internet/stations/stations.json
Traceback (most recent call last):
File "/usr/local/lib/python3.13/site-packages/lhpapi/nw_api.py", line 85, in init_NW
(name, internal_url, url) = get_basic_station_data(ident)
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^
File "/usr/local/lib/python3.13/site-packages/lhpapi/nw_api.py", line 21, in get_basic_station_data
nw_stations = fetch_json(
"https://hochwasserportal.nrw/lanuv/data/internet/stations/stations.json"
)
File "/usr/local/lib/python3.13/site-packages/lhpapi/api_utils.py", line 50, in fetch_json
response.raise_for_status()
~~~~~~~~~~~~~~~~~~~~~~~~~^^
File "/usr/local/lib/python3.13/site-packages/requests/models.py", line 1024, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://hochwasserportal.nrw/lanuv/data/internet/stations/stations.json
Reproduction steps
Install HACS Integration :-)
Relevant log output
Setup of NW_2725910000100 failed: nw_api.py: init_NW(): HTTPError: 404 Client Error: Not Found for url: https://hochwasserportal.nrw/lanuv/data/internet/stations/stations.json
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/site-packages/lhpapi/nw_api.py", line 85, in init_NW
    (name, internal_url, url) = get_basic_station_data(ident)
                                ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/lhpapi/nw_api.py", line 21, in get_basic_station_data
    nw_stations = fetch_json(
        "https://hochwasserportal.nrw/lanuv/data/internet/stations/stations.json"
    )
  File "/usr/local/lib/python3.13/site-packages/lhpapi/api_utils.py", line 50, in fetch_json
    response.raise_for_status()
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/local/lib/python3.13/site-packages/requests/models.py", line 1024, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://hochwasserportal.nrw/lanuv/data/internet/stations/stations.json

Hi @Cyrelion i don't think that the portal has changed. For me it looks as if the portal is currently down.
If you have a look at https://www.hochwasserzentralen.de you can see that all NRW Pegel have been updated yesterday (22.12.2024 at 14:30) for the last time until now. In addition https://hochwasserportal.nrw/lanuv/webpublic/index.html#/Start shows no data.
This is not the first time that a state portal is down. I recommend waiting a few days, because they typically fix it within a few days.

Hi @Cyrelion, it seems as if LANUV has fixed their portal. NW_2725910000100 is working for me again. Can you please confirm and close this issue.

You’re right. Sorry for bothering you


Small size face keypoint detection

When the image infer by the model， the image downsize 4x， the small face is 2-5 pixl in my data ，the keypoint heatmap center is very close,  and then After the 3x3 maxpooling, the 5 keypoints may doublication, the 3x3 maxpooling is not suit me, How can i slove the problem, Can you gays give me some advise?

2-5 pix face is too small, i think you can enlarge the image.


Keeping your home router up to date and configured properly

A key area of home network security is making sure your router is up to date.
A few recommendations:

Ensure that your router is using the most recent firmware (advanced users can install OpenWRT). This is as easy as downloading a new firmware from the manufacturer of your router and uploading it to your devices admin panel.
Ensure that the admin password on your router is changed from the default.
Set your DHCP settings to offer <IP_ADDRESS> and <IP_ADDRESS> as the advertised DNS server.
Ensure that your wifi is using WPA2 and to disable WPS

Resources:

How to Update Your Router - Toms Guide
Why you need to update your router - Consumer Reports
Rarely Patched Software Bugs in Home Routers Cripple Security

Mesh, auto-updating routers may be the best option for most people: Google WiFi, eero, Orbi, etc.
Just trying to update the stock firmware on most routers is beyond the capability of your non-technical friends and family.
I think going outside the first-party firmware update mechanism (DD-WRT, OpenWRT, etc.) should be considered an "Advanced" topic.

Here is a live list of hostile networks
https://github.com/szepeviktor/debian-server-tools/tree/master/security/myattackers-ipsets
I run a bunch of servers and analyze the blocked IP-s in the firewall, this is the result.


CFR enable in DPD should be removed

We had a discussion with Dale about this: Currently you can enable and disable the pre-DPD CFR and post-DPD CFR but the RDLs don't offer any means to configure the CFR. Therefore we should leave away the whole CFR toggles.

According to the Teams discussion the CFR toggles will stay and the CFR configuration will be added.

Changes are applied in commit https://github.com/NISystemsEngineering/rfic-reference-design-libraries-labview/commit/255b959ae9c1935177754a584cd948008d2f743a


Revert "Revert "fix wrong attribute ordering in the runtime""

Reverts apple/swift#62301
Seems like the problem with attribute ordering is still not fixed on the clang side (https://github.com/apple/llvm-project/pull/5655)

@swift-ci test

cc @compnerd


Readme instructions out of date

There is no ynabamazonparser/driver.py file available to run the program.
I would love current instructions on how to run the program.

Thanks for your interest. I've just merged dev to master and put a decent/up to date readme. I'm definitely looking for feedback/testing/feature requests!


fix: adds union type when operation.message.oneOf is set

Description

adds union type when operation.message.oneOf is set

Related issue(s)
Resolves #1111

@jonaslagoni, please review :)

As this is a breaking change, I am gonna change the title to fix!: 🙂

/rtm


fix(sec): upgrade org.apache.hive:hive-exec to 3.1.3

What happened？
There are 1 security vulnerabilities found in org.apache.hive:hive-exec 2.3.7

CVE-2021-34538

What did I do？
Upgrade org.apache.hive:hive-exec from 2.3.7 to 3.1.3 for vulnerability fix
What did you expect to happen？
Ideally, no insecure libs should be used.
The specification of the pull request
PR Specification from OSCS

Incompatible version, compile error
@zhoumengyks

We should test its compatibility before merging

fix in #16046


mail/messages/remove does not removes the selected messages

When I
PUT api/2.0/mail/messages/remove
Host: yourportal.onlyoffice.com
Content-Type: application/json
Accept: application/json

{
  "ids": [
    1234
  ]
}

Nothing happens.
GET api/2.0/mail/messages/1234
Host: yourportal.onlyoffice.com
Content-Type: application/json
Accept: application/json

I can still get the message and it still shows in the user interface.  I'm on Version <IP_ADDRESS>8,
https://api.onlyoffice.com/portals/method/mail/put/api/2.0/mail/messages/remove

Hello @gofreddo what a response do you get on remove request? Any errors, maybe in web.api.log?

{
"count": 1,
"status": 0,
"statusCode": 200,
"response": [
1234
]
}

Sorry, but i can't reproduce your problem. You can try to regenerate authorization token, reconnect your mail account, update to the latest version of community server, and check web.api.log for the errors.


Casing of signature is an issue when signing with injected MetaMask provider.

Description
When comparing a signature produced with window.ethereum.request({ method: 'personal_sign, params: [message, address] }), SiweMessage instance fails to compare because of address casing issues.
I receive this error message:
Error: Invalid signature.: 0xeE656Ff300be8B8867711139FE496b9790b8d4AE !== 0xee656ff300be8b8867711139fe496b9790b8d4ae

Here is where the error happens: Link to PR showing error
Here is the message being signed without any ethereum convenience library and using the vanilla MetaMask methods:
Link to PR showing error
I am open to submitting a fix. I have had a similar issue in the 2.0 Beta version

Hello, does this issue already have the solution ? bcs I still have this error, I am using 2.0.5

This is not a bug, it's the expected behavior. To improve security SIWE enforces EIP-55

This is not a bug, it's the expected behavior. To improve security SIWE enforces EIP-55

thanks for the response, so the passed address/signer address should be changed? I am using web3 onboard and after wallet connect, I just pass the response address

yes, you probably want https://web3js.readthedocs.io/en/v1.2.11/web3-utils.html#tochecksumaddress

Closing this for now - @malikdev13 please let us know if anything else comes up here.


Support Up-to-date dependencies

Currently, this package depends on rxdart ^0.26.0. Can you please update the rxdart version (to rxdart ^0.27.3)? I want to use this package but I cannot install it because of this version issue :(  Thank you.

I would also appreciate this update. Thank you!

Yes Please +++

I would appreciate this as well, since this causes problems for me with the assets_audio_player.
There is even a fork that uses the newer rxdart (https://github.com/neckaros/secure_application/compare/master...ariefwijaya:master). I have not tried it though.

thanks for the info. I merged a pull request from the repo you provided @JThorvid


Update readme on how to setup Section

Hello,
I'm having trouble with setting up the section propery. What URL does it expect? First entry is displayed correctly, but in the navigation, any other link throws a 404 page no matter what level I move it to.

Hey @tiborsaas, could you link how you have your entry urls set up?

I have no idea what happened, the section I created was having trouble saving entries, it started to throw failed tasks. I deleted it, picked a different handle and it now works fine.
#xfiles

@tiborsaas #spooky https://www.youtube.com/watch?v=hdl9Byw3ej8
Let us know if it happens again and you can reproduce.

LOL
Actually I just caught it again. If the slug has a non-ascii character in it, for example "kezelések" it won't load.

@tiborsaas I've just pushed an update that will fix this for basic non-ascii characters (é,å,ñ, etc). The regex isn't perfect, but I'll improve it over time. Fixed in [b160d622].(https://github.com/hillholliday/Craft-User-Manual/commit/b160d6229debfd60302ef54b9abdf1401ec2bb4d)


Migrate to new protobuf implementation

This PR still needs some cleaning up, but I wanted to start getting review sooner rather than later. Some points:

The most significant change is to logging, pubsub and spanner, because they rely on GAPICs. In particular, the PhpArray codec is replaced by a Serializer object.
The huge number of files is because this PR adds all of the generated protobuf types - these don't need review individually, but we do want to consider what will be the best repo structure for including these types (if indeed we decide to go ahead with that plan), considering our release process.

There are some types that still live in proto-client-php, for example:
https://github.com/googleapis/proto-client-php/tree/proto3/src/Google/Logging/Type
Should these be a part of this PR as well?

If we do keep the protos in this repository, what do you think of the following?
Instead of Google\Logging\V2\CreateSinkRequest - dir: src/proto/Logging/V2
Google\Cloud\Logging\V2\CreateSinkRequest - dir:  src/Logging/V2
A major downside here, is that the protos will live right next to the GAPIC clients - making it hard to distinguish which to use if looking directly at the source. An option then would be to use Google\Cloud\Logging\V2\Proto\CreateSinkRequest - dir: src/Logging/V2/Proto.
On the plus side, we stick to our core namespace of Google\Cloud and managing releases will be easier.

@dwsupplee That seems possible, but one problem is that the proto types do not all use the Google\Cloud namespace (e.g. the logging types are under Google\Logging rather than Google\Cloud\Logging). This is something that we could perhaps push for, by adding support for an option to specify the namespace in the proto file similar to C#: https://github.com/googleapis/googleapis/blob/6ae2d424245deeb34cf73c4f7aba31f1079bcc40/google/logging/v2/logging.proto#L28

That sounds like a great solution to me

Given that, I think it might be best if we make the migration to the new protobuf implementation without including the generated types in google-cloud-php, and instead leaving them in proto-client-php. Then once we have that protobuf feature available, we can change the namespaces and move the generated classes. This has the downside of involving two disruptive changes, but the upside of not blocking on having that protobuf feature available. WDYT?

Is it correct then that for packages we are currently GA on we would end up bumping them to 3.0 in a relatively short time frame? I have some definite reservations there - do you have an idea as to when it may be possible to get the update to change the namespaces?

No, we should not be bumping them beyond 1.0. The affected GA API is Logging, but in that case we have gone GA on the manual layer but not on the GAPIC client or protobuf types, because we knew that these breaking changes would be required (and we documented that the GAPIC layer is still experimental).

An update after some discussions with @bshaffer, @tmatsuo and @TeBoring:
We are now looking to implement the proto option to set the PHP namespace (issue filed here: https://github.com/google/protobuf/issues/3122) before we make the migration over to the new protobuf implementation. This will allow us to move all of the generated protobuf types into the Google\Cloud namespace.
There is also a new issue in protobuf that I discovered today while running Spanner integration tests, which we will need to resolve before we can complete the migration: https://github.com/google/protobuf/issues/3139

I have updated the PR to include:

Protobuf types are now in src/Google/Cloud directories and have correct namespaces (generated from https://github.com/google/protobuf/pull/3162). I think that the clutter, while not ideal, it not too bad - README samples can direct users to the client class, and there is a single place to look if you want to find a class to use.
The protobuf metadata classes are in src/GPBMetadata. I think this is the best place for them - they all reside under the GPBMetadata\\ namespace, and should never be used directly, so having them in the src/Google/Cloud directories doesn't seem right.
Moved the Serializer class into GAX. I think that the functionality will be useful in autogen code as well as google-cloud-php. WDYT?

This PR is awful to review because of the proto files. Since it is not passing test yet anyway, WDYT if I remove the proto types for now?

The protobuf metadata classes are in src/GPBMetadata.

That directory will not be distributed to components. If we are keeping the metadata classes together, they should probably be in src/Core?

Yes, I wanted to discuss that point. I am not sure if we want to:

Keep them in Core
Distribute them to the components, by doing one of:

Have the release process know which classes to pluck from the combined GPBMetadata folder
Have them separated, with each API directory having a metadata folder (e.g. src/PubSub/GPBMetadata)

Which of those do you think is preferable? All else equal, I think that having them distributed is best, by neither of the options for achieving that is ideal.

With option 2 would it would look something like this?
src/PubSub/V1/GPBMetadata/Pubsub.php
If so, I think I like that approach best.

Having src/PubSub/V1/GPBMetadata/Pubsub.php seems fine to me.
The downside of this approach is the noise that it creates in the composer.json file, in the PSR-4 section, because the namespace of these metadata files begins with GPBMetadata. So in this example, we would need to update the autoload section of the composer file with:

Having src/PubSub/V1/GPBMetadata/Pubsub.php seems fine to me.
The downside of this approach is the noise that it creates in the composer.json file, in the PSR-4 section, because the namespace of these metadata files begins with GPBMetadata. So in this example, we would need to update the autoload section of the composer file with:
  "autoload": {
        "psr-4": {
            "Google\\Cloud\\": "src",
            "GPBMetadata\\Google\\Pubsub\\V1": "src/PubSub/V1/GPBMetadata"
        }
    },

Is that acceptable do you think? Otherwise we could look at using classmap rather than psr-4 for these GPBMetadata classes.

In my opinion, having the desired directory structure and distributing the metadata classes along with the relevant package is worth the extra noise in the composer.json file. :)

Will it not be possible to modify the namespace of the GPBMetadata classes?

No, unfortunately not. I mentioned this briefly in the PR for adding the php_namespace option (https://github.com/google/protobuf/pull/3162) but that was referring to changing the namespace to (in the pubsub example) include the Cloud component - not to remove the leading GPBMetadata, which is the cause of the noise.
We can clean up the composer file by placing them in a shared GPBMetadata folder in the root or src, but then we would need to have our release process pluck the correct files out, and distribute them to a GPBMetadata folder in each subrepo.

Gotcha. I'm a bit concerned about the room for err we would be introducing by having to remember to add mappings to the composer's autoload settings for every new library. It isn't the end of the world, but just one more thing that would be easy to forget.
Ultimately, if we keep everything in a shared directory, does it sound correct we would need a mapping for the split process? If so, it appears we are at the same problem (with having to maintain a map), just in a different place.
Between the two, I would prefer with maintaining the mapping in the composer's autoload setting just because it might be a more clear place to manage the information.

Moved the Serializer class into GAX. I think that the functionality will be useful in autogen code as well as google-cloud-php. WDYT?

👍 sounds good to me.

I agree that between the two, the autoloader is preferable. I'd rather not introduce an opportunity for failure which is hard to catch before release, and if we use the autoloader, there is less room for surprise when the component acts entirely differently from the main package with respect to the metadata.

@dwsupplee you are correct that we would need to maintain a mapping in either case.
Sounds like there is agreement to use the autoloader to hold the mapping. If we decide in future that this is not working, we can restructure, which should be non-breaking to users.

Moved the GPBMetadata classes, and added to composer.json - using classmap seemed the cleanest way to include them.
I will also update each API-specific composer file.

There are some types that still live in proto-client-php, for example:
https://github.com/googleapis/proto-client-php/tree/proto3/src/Google/Logging/Type
Should these be a part of this PR as well?

These common types will live in GAX, as they did previously (e.g. the existing HttpRequest type is here: https://github.com/googleapis/gax-php/blob/master/src/generated/http_request.php)
I should not have added them to the proto3 branch in the first place

Moved the GPBMetadata classes, and added to composer.json - using classmap seemed the cleanest way to include them.

Just wanted to note that with a classmap new classes added to the directories won't be autoloaded unless we explicitly run composer install/update/dump-autoload.
I'm betting it will be extremely rare that a new class will be generated in the existing directories, but in the case they do it could lead to some confusion for anyone contributing to the project.

I am happy to not use classmap if it may cause issues, but I think you are right that it will be extremely rare - it will only occur when someone is regenerating the protobuf types for an API, and a new proto file has been added to the API, because each GPBMetadata class corresponds to a file, rather than a proto message.

These common types will live in GAX, as they did previously (e.g. the existing HttpRequest type is here: https://github.com/googleapis/gax-php/blob/master/src/generated/http_request.php)

Sounds good! Does it seem worthwhile to have portions of GAX run through the documentation generator so we can include these types on the site easily?

I am happy to not use classmap if it may cause issues, but I think you are right that it will be extremely rare - it will only occur when someone is regenerating the protobuf types for an API, and a new proto file has been added to the API, because each GPBMetadata class corresponds to a file, rather than a proto message.

I'll defer to your judgement on this one :). I just wanted to make sure it was something we were aware of.

Does it seem worthwhile to have portions of GAX run through the documentation generator so we can include these types on the site easily?

Good question, I think that makes sense, but I'm not 100% sure. Is that the best way to integrate the docs?

The other option I can think of is to do what we are doing currently - which is to just link out to the code in the repo. Having those types be documented in the site seems like it would be more cohesive.
Are there any other existing plans to document GAX currently?

No, there isn't any specific plan, other than generating a github.io doc site for GAX. Linking out to that would be OK, but less cohesive as you mention.

It looks like tests are very close to passing, there are a couple of issues:

Some of the comments in the protobuf types are being picked up as snippets, as they contain "Example:". We could resolve this by (a) tightening the rules around what counts as a snippet, or (b) perhaps adding a new @snippet or @example annotation, or (c) excluding the V* directories from the snippet search.
Doc gen is failing because protobuf type constructors don't have doc blocks. Ideally we would solve this by adding doc blocks to them - is there any other plausible way forward in the short term?

Does updating "Example:" to "Sample Code:" sound okay? I originally didn't use the @example tag because it doesn't support inline examples.
The quickest route I can think of would be to add a condition during doc generation to exclude a certain pattern. Are we planning to build the docs for the protobuf types using the docblocks that currently exist? They don't use proper notation and will look pretty different from the rest of the docs on the site, at times even rather confusing.

Moving to "Sample Code:" SGTM
We are going to improve the generated docblocks - @bshaffer has a PR open here: https://github.com/google/protobuf/pull/3131. I can regenerate using that PR and we can assess the state of the docs and discuss what additional changes we want. But I think that we should try not to delay switching to the new protobuf - if the doc situation is not acceptable, then in the worst case we can leave the protobuf types in proto-client-php (but still make use of the updated namespace option, so that moving them from proto-client-php to google-cloud-php will be a non-breaking change)

I have added support in the documentation generator for classes and methods without doc blocks. This is not something that I want to encourage/make normal though. Currently the places that are missing doc blocks are the protobuf type constructors and the gRPC stub classes, which have comments but use // instead of /* ... */, so those are the changes we need to get from protobuf and grpc respectively.
The question for us I think is - does moving to this new distribution (protobuf types in google-cloud-php) improve our doc situation (vs the current option of linking out to code) or make it worse, given that the generated docs are not fully finished?

If these changes to doc generation will be here for some time, could we add a warning if there isn't a docblock? That will provide at least some coverage to make sure we don't miss something when developing new code.
Here is an example of what the generated docs will look like with the new protobuf types. This will require a lot of manual work for a user to grok what is going on and to be able to link out to the different types required to build up a message.
If we are really pressed to get this out before we can get the updated docs, then I don't see a difference between doing what we are currently (linking out to the code) vs generating into the doc site since the source of the data provides the same information.

I think that we need to include the param and return type updates from https://github.com/google/protobuf/pull/3131. I will regenerate soon with those changes, and we can include them even if they are not in a release of protobuf. I don't know if we are going to be pressed to get the switch out before we can make the updates to the doc gen to fix the missing docblocks - it depends on when protobuf can provide us with a new point release to depend on (which we need for the runtime changes, not the doc changes). But I do want to try as hard as possible not to be blocked once that is available.
Agree that if we include those changes to allow empty doc blocks, we should add warnings.
It looks like tests are passing, except for HHVM, because of this issue: https://github.com/google/protobuf/issues/3224
HHVM isn't listed as supported in the PHP protobuf requirements readme - I will ping the issue to find out what the intention is about HHVM support.

Updated protobuf and grpc type docs - PTAL and let me know if there are other doc generation problems.

A few items of note:

There is a lack of consistency with how we are notating required items. In some cases this information provides no benefit, as it is clear an item is required if it is not optional in the signature. In other cases, I believe it is intended to let a user know which properties on a message must be set before the message can be delivered successfully, this makes more sense. Examples: 1, 2, 3
Are the
 tags necessary? They screw with the styling on the doc site, and I don't see the value in them being there.
Should we be keeping the code samples? Ex: string project_name = 1;. I may be missing something, but I don't see how this will benefit a user - it just seems like it would mislead them.

This is a consequence of the proto documentation. APIs have different conventions, and our documentation for the protobuf types and the GAPIC clients is just copying their comments. See https://github.com/googleapis/googleapis/blob/master/google/devtools/clouderrorreporting/v1beta1/error_stats_service.proto#L289 and https://github.com/googleapis/googleapis/blob/master/google/cloud/speech/v1/cloud_speech.proto#L66. An example of how this SHOULD be done at the proto level (IMHO) is pubsub: Use the proto comments on the message fields to describe the field (https://github.com/googleapis/googleapis/blob/master/google/pubsub/v1/pubsub.proto#L324) and document on the RPC the behaviour of whether fields are required, or what happens if they are missing (https://github.com/googleapis/googleapis/blob/master/google/pubsub/v1/pubsub.proto#L46). I don't think there is much we can do about this in autogen - as we would need to process the comments on a case-by-case basis.
I don't see why they are necessary, lets look at removing them
I think this is just supposed to document the underlying protobuf field from which the method was generated. It should probably not use  tags, lets look at changing them

Alternatively for the  tags, we could just make it clearer what they represent by changing:
string project_name = 1;
to
Generated from protobuf message field: string project_name = 1;
which is more similar to the docblock on the class: https://github.com/GoogleCloudPlatform/google-cloud-php/pull/512/files#diff-7f27caeaa234f9174f9756c3dd215613R16

I like that updated messaging better, but still would prefer removing it altogether. What is a user going to do with that information?

I our case it is probably not that useful, but in general for protobuf generated types it is there to indicate which proto field it came from.
I don't think they will want to remove it entirely. We could perhaps filter it from our doc site, if we thought it was worth it? But I would be unsure about if it was worth handling as a special case.

Regarding documentation of protobuf classes if they are not included in google-cloud-php, what do you think about:

Document them in the main doc site. I don't know what structure we would use though - any ideas?
Or, use a separate doc site. Based on what I have looked at before, something like this: https://michaelbausor.github.io/proto-client-php/master/

@dwsupplee @jdpedrie Protobuf has released 3.3.2, so we are able to switch to using the new protobuf implementation as soon as we are ready. Tests are now passing in this PR. The things that I think need review/consideration are:

I have updated Core so that there are not breaking changes, by adding GPBGrpcTrait and similar for Grpc-based classes that need to change, and adding deprecation notices to GrpcTrait. Do you think this is a reasonable approach? When Core goes to v2, we would remove the GrpcTrait and rename GPBGrpcTrait to GrpcTrait. Note that I have also retained stanley-cheung/protobuf-php as a dev dependency - this was needed
I did a similar thing with Logging/Connection/Grpc , which is the other file in a GA component affected (excluding the Logging GAPIC clients)
What are your thoughts about handling docs for proto-client-php (see previous comment)?
I removed testing of HHVM from Travis - this won't be supported by protobuf until https://github.com/google/protobuf/pull/3225 is included in a release. Should I instead disable only the grpc tests somehow?
Other concerns?

I have updated Core so that there are not breaking changes, by adding GPBGrpcTrait and similar for Grpc-based classes

Since the public methods in these traits haven't changed their signature/return value and the rest of the methods are private - I think it would be acceptable to continue using them as is with the updates we require. The only class we should need to deprecate would be Google\Cloud\Core\PhpArray, I believe.

Note that I have also retained stanley-cheung/protobuf-php as a dev dependency - this was needed to support tests passing, in particular the snippet test suite, which otherwise complains that DrSlump\Protobuf\Codec\PhpArray is missing.

Interesting 🤔, which test(s) did this crop up on?

What are your thoughts about handling docs for proto-client-php?

For now, I like the idea of using our current structure to link out to the generated types hosted here: https://michaelbausor.github.io/proto-client-php. Once we get everything set up in the ideal state, we could then move forward with generating them right into the main docs site - WDYT?

I removed testing of HHVM from Travis - this won't be supported by protobuf until google/protobuf#3225 is included in a release. Should I instead disable only the grpc tests somehow?

I would definitely prefer to disable the grpc tests in HHVM vs. disabling HHVM coverage altogether. We do something similar already by checking if the grpc extension is installed.
if (!defined('HHVM_VERSION')) {
    $this->markTestSkipped('HHVM does not currently support gRPC.');
}

Other concerns?

None at the moment! I will spend some more time tonight looking through the PR to confirm.

Since the public methods in these traits haven't changed their signature/return value and the rest of the methods are private - I think it would be acceptable to continue using them as is with the updates we require. The only class we should need to deprecate would be Google\Cloud\Core\PhpArray, I believe.

I am not opposed to this necessarily, but wouldn't this still count as a breaking change? We would be changing the types of callables that are accepted - callables that use the DrSlump classes would no longer work.

Interesting :thinking:, which test(s) did this crop up on?

It happens in the parsing step before running any snippet tests. I will investigate further.

For now, I like the idea of using our current structure to link out to the generated types hosted here: https://michaelbausor.github.io/proto-client-php. Once we get everything set up in the ideal state, we could then move forward with generating them right into the main docs site - WDYT?

+1

I would definitely prefer to disable the grpc tests in HHVM vs. disabling HHVM coverage altogether. We do something similar already by checking if the grpc extension is installed.

I will investigate doing this

I am not opposed to this necessarily, but wouldn't this still count as a breaking change? We would be changing the types of callables that are accepted - callables that use the DrSlump classes would no longer work.

Good point, after thinking about it a bit I am leaning towards using the classes as is. The breaking change technically takes place in parts of the library we have marked as experimental, whereas this is just a generic wrapper. WDYT @jdpedrie?

Interesting :thinking:, which test(s) did this crop up on?

It happens in the parsing step before running any snippet tests. I will investigate further.

ReflectionClass throws an error if a class cannot be instantiated, which happens in the case of PhpArray if it doesn't have the DrSlump dependency. I could update the process to:

Skip deprecated files/classes. But this is tricky without using reflection...
Have an explicit skip list
Keep the dev dependency
Other?

Keep the dev dependency

I'm okay with this

After much struggling with HHVM, I have come up against a tricky problem. The reason it is failing is this code in protobuf. This is problematic because (1) this code is a PARSE-time error in HHVM, not a runtime error, and (2) this code does NOT follow PSR-4, meaning it is not autoloaded, but always loaded. Therefore, just skipping the gRPC tests is not sufficient - it is necessary to conditionally remove the dependencies on google/protobuf, google/gax and google/proto-client-php for HHVM.
After doing that, we then hit the problem on the snippet parser, which also tries to load all the classes and errors when it can't.
I think this can be solved by adding an exclude list for the snippet parser, which checks for HHVM and conditionally does not check the Spanner files for snippets. This would also allow use to remove the stanley-cheung/protobuf-php dependency.

That sounds like a solid solution for now, and hopefully we can get HHVM support sooner rather than later.

HHVM tests are now passing. I did not need to use an exclusion list for grpc snippets in the end, but having implemented it, I have retained it to remove the DrSlump dev dependency.
I believe this is ready for final review, pending releases of GAX and proto-client-php, and updating their docs to link externally instead of to code.

Did we need to revert the snippet changes (https://github.com/GoogleCloudPlatform/google-cloud-php/pull/512/commits/9c4b04bdbff31f26a8f7146fcb51ae8860f958dc) (https://github.com/GoogleCloudPlatform/google-cloud-php/pull/512/commits/a518c928bc41e642854b8000bd43dfcf5312dbb2)?

We didn't need to, but because we aren't including the protobuf classes, there wasn't a reason to change them, and I wanted to minimize the changes in this PR. If you think they are a worthwhile change in their own right (or just worth adding as preparation) and can add them back in.

I wasn't sure if lines like this may cause issues, but after taking a quick look at the docs it appears we should be okay. Given that, I'm happy to keep the changes in this PR minimal, that works for me!

Great! I believe I have addressed all changes, so this should be ready to merge - PTAL


On android chrome: need to tap paper-input twice to open on-screen-kb

Expected: tapping on a paper-input will bring up the android on screen keyboard
Actual: first tap focuses the paper-input (cursor blinks), but you have to tap a second time to bring up the keyboard

Closing this issue due to age and the release of version 1 of Polymer - please feel free to re-open if this is incorrect.


Invalid authentication

Hello,
I don't know where to find log, please point at me where I can find it to provide them here.
Anyway I can log into the app and not into the integration using the same credentials. The only difference is that I can't put a 0 at the begining of the phone number. I suppose this is the problem maybe...
Excuse me for my poor English as it's not my naative language.
Thank you for your work.

Hi Hydreliox,
Does you Super Soco bike use the old application (Super Soco) or the new one (Vmoto Soco)?
I'm asking because, as of current date, this integration is only compatible with the old application, which is my case (TCmax 2021). I would need access to a new application's user account in order to reverse engineer its API calls and add compatibility.
If that's not the case and you're using the old application, you can see the error logs in Settings > System > Logs. They look similar to this one:

If you wish you can also enable full debug logs by adding these lines into your configuration.yaml file and restarting Home Assistant:
logger:
  default: info
  logs:
    custom_components.super_soco_custom: debug

After that, they should be visible by clicking the "Show full logs" button located at the bottom of the Logs section.

Thank you for your time. I'm using the old app. I will provide logs as soon as possible.

"The only difference is that I can't put a 0 at the begining of the phone number." <- This got me thinking. The phone number field is currently an integer, perhaps it should be a string so it accepts leading zeroes. Honestly, it didn't occur to me that phone numbers could begin with a zero. 😓
I'll try to push a fix as soon as I can.

In France all cell phone numbers starts with 06 or 07.

Done, this should be fixed in 1.0.0-beta.5. Please let me know if the issue persists.

Ok now I can put a 0 on the front of phone number and it solves the authentication issue.
Thank you very much!


[fix][doc] Add client config override

Fixes https://github.com/apache/pulsar/issues/18490
Modifications

Add back the configuration override information introduced in https://github.com/apache/pulsar/pull/15818 but missed on the new Pulsar config site.

Documentation

[x] doc
[ ] doc-required
[ ] doc-not-needed
[ ] doc-complete

With @tisonkun's help, I managed to add the new Pulsar config page (in the Pulsar-site repo) and verify the changes. See https://github.com/apache/pulsar-site/pull/294 for more details.
Maintaining the content in the new config page has pros/cons:

Pros: information is cohesive without a break.
Cons: not that easier for contributors/maintainers to update and verify, compared with the current config page.

Generally, I prefer to add this chunk to the new config page. If you don't have an objection, I will close this PR and continue with https://github.com/apache/pulsar-site/pull/294.
cc @Anonymitaet @DaveDuggins @D-2-Ed

I'm +1 for https://github.com/apache/pulsar-site/pull/294, reasons:

All relevant info is in one place. Docs are not scattered around here and there. It's easier for both readers and maintainers.
Explained in the image


Fixes some problems

Fixes some problems:

After opening Embed Console, after killing the server, the server is still running
Unable to stop the server safely
Wrong parameters

After loading the updated plug-in, you need to modify the existing server configuration to solve some possible problems

Server Port -> 7777
Server Query Port -> 15777
Server Maxplayer -> 4 , please modify as needed
Server Start Param -> -unattended


Module doesn't work and throws this exception

What sheet were you trying to open?

...was it the Tarrasque?

Actually yes :)

Fixed in the latest release :D
The Tarrasque is a level 25 creature, and the creature building tables only go up to 24.  It's literally off the charts!

Thanks a lot


can mergeIntoBag function extend to merge two array?

If my response have some arrays in the entities, the first store init is ok, but when the store changed, bag[key] = transform(assign({}, bag[key], entities[key])); will convert the bag[key] which should be array to object;
Cause it is only a example, so just ask.

What's your API response like?

@gaearon : such as
{_id: "ChopperLee2011", name: "chopperlee", orgs: ["test org1","test org2"], repos: Array[138] }

Why is bag[key] an array? It's supposed to be an object. (Like the one you wrote above.) What am I missing?

key can be 'orgs'', bag[key] is an array :'["test org1","test org2"]', right?

bag itself stores entities, not their field. It looks like:
{
  'ChopperLee2011': {_id: "ChopperLee2011", name: "chopperlee", orgs: ["test org1","test org2"], repos: Array[138] },
  'SomethingElse': { ... }
}

i am wrong, please close it


Add step to set github actions bot as the git user

What does this PR do?
Set github-actions bot as git user which is required to commit changes made during the workflow.
Motivation
Automation of the Agent release process.
Reviewer's Checklist

[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] Changed code has automated tests for its functionality.
[ ] Adequate QA/testing plan information is provided. Except if the qa/skip-qa label, with required either qa/done or qa/no-code-change labels, are applied.
[ ] At least one team/.. label has been applied, indicating the team(s) that should QA this change.
[ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
[ ] If applicable, the k8s/<min-version> label, indicating the lowest Kubernetes version compatible with this feature.
[ ] If applicable, the config template has been updated.

/merge


⚠ Turnos 24x7 has degraded performance

In 14bdff9, Turnos 24x7 (https://reservas-dev.alternativasinteligentes.com/) experienced degraded performance:

HTTP code: 200
Response time: 3167 ms

Resolved: Turnos 24x7 performance has improved in e04cbc5.


Update unaddressed batch config CSV

Motivation and Context
The unaddressed batch requirements have changed, the config here needs updating to match
What has changed

Update CSV unaddressed batch config

How to test?

Double check the config changes against the requirements: https://collaborate2.ons.gov.uk/confluence/display/SDC/Unaddressed+Print+Files
Run through with the new config and check the unaddressed batch files/queue backup dump still works as expected.

Links
https://trello.com/c/CUNdywUZ/872-update-unaddressed-batch-config-3
https://collaborate2.ons.gov.uk/confluence/display/SDC/Unaddressed+Print+Files

 Update unaddressed batch config (3?)


add support for FreeBSD OS, similar to the support for Linux OS

Please merge the following small change to binding.gyp to add support for the FreeBSD operating system, similar to the support for Linux. It is just the same issue: the C++ code needs exceptions and this has to be explicitly enabled. I've tested this with both the system LLVM compiler and an own GCC under FreeBSD. Both worked just fine. Thanks!

Thank you @rse
I will check it.


[icons] Material icons available as independent package

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Summary 💡

I'd like to use  in my react project only material icons without need to install other package

Motivation 🔦
It may be convenient in case someone would like to use only material icons

This sounds very much like https://github.com/adazzle/react-data-grid/issues/1999. Is there any of the explored direction that catches your eye?

yep, we have different root cause but indeed we're going in the same direction.
I believe solution no 1 that you suggested is as simple and fast as possible. I'm opting for that.

@aplaskota I'm not sure how we can implement it effectively. It seems that we would need to split the source. Maybe
import clear from<EMAIL_ADDRESS>
function ClearIcon() {
  return <svg viewBox="0 0 24 24" style={someStyles}>{clear}</svg>;
}

?

@oliviertassinari I think we can hold on to waiting for more followers of that idea. It seems that I'm the only one who requested that change. Actually I can copy and paste some icons into my internal component

what about making the path exported var and default export leave as it is?
in this case refactoring only affects the internals, everything else stays the same. Since the core is already in the peerDeps this shouldn't be a big problem. Time consuming yes, but not complex.

@woss So you are advocating for, using one icon as an example:
diff --git a/packages/material-ui-icons/src/Info.js b/packages/material-ui-icons/src/Info.js
index 27b35d5bf2..c6e6f2d7d8 100644
--- a/packages/material-ui-icons/src/Info.js
+++ b/packages/material-ui-icons/src/Info.js
@@ -1,6 +1,6 @@
 import * as React from 'react';
 import createSvgIcon from './utils/createSvgIcon';

-export default createSvgIcon(
-  <path d="M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2zm1 15h-2v-6h2v6zm0-8h-2V7h2v2z" />
-, 'Info');
+export const path = <path d="M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2zm1 15h-2v-6h2v6zm0-8h-2V7h2v2z" />;
+
+export default createSvgIcon(path, 'Info');

The implementation should be as simple as:
diff --git a/packages/material-ui-icons/templateSvgIcon.js b/packages/material-ui-icons/templateSvgIcon.js
index 40232b111f..e87a42305d 100644
--- a/packages/material-ui-icons/templateSvgIcon.js
+++ b/packages/material-ui-icons/templateSvgIcon.js
@@ -1,6 +1,6 @@
 import * as React from 'react';
 import createSvgIcon from './utils/createSvgIcon';

-export default createSvgIcon(
-  {{{paths}}}
-, '{{componentName}}');
+export const path = {{{paths}}};
+
+export default createSvgIcon(path, '{{componentName}}');

If this allows tree shaking, I think that it's worth trying out.
If it doesn't, solving the problem with:
diff --git a/packages/material-ui/src/utils/createSvgIcon.js b/packages/material-ui/src/utils/createSvgIcon.js
index 2d146ab87d..dc805367f4 100644
--- a/packages/material-ui/src/utils/createSvgIcon.js
+++ b/packages/material-ui/src/utils/createSvgIcon.js
@@ -17,6 +17,8 @@ export default function createSvgIcon(path, displayName) {
     Component.displayName = `${displayName}Icon`;
   }

+  Component.path = path;
+
   Component.muiName = SvgIcon.muiName;

   return React.memo(React.forwardRef(Component));

could be even simpler.
I have tried to advance the reflection on https://github.com/adazzle/react-data-grid/issues/1999, from what I understand, we have these options:

The one presented here. We have developers install @material-ui/core, but thanks to tree-shaking, they don't pay the cost on production. I'm not sure it's going to cut it, the developer might still have concerned about installing @material-ui/core for nothing, especially for a library. But to be fair a library would probably not install a full list of 5,000 icons for using 5.
We create a new file for the paths. We make @material-ui/core an optional peer dependency. I would have concerns about the installation time. Would x2 the number of files create a bottleneck during the unzip of the package archive?
We create a new package for the paths. This might be overkill for the problem at stake and the pain it would solve.

@eps1lon A related question on the size of the icons repository. Do you know when would we be able to drop the .cjs extension?
I'm also wondering. Do we really need to support `import { Info } from '@material-ui/icons';

yeah, exactly that. The implementation looks simple and you don't have to create any new files. :)
As for the simpler solution, i cannot comment since i am not super familiar with the React.memo

@woss I assume by "that", you are referring to option 1. Would you mind sharing more about your use case for using only the SVG path? Thanks

@oliviertassinari  yep, option 1.
as for your question i guess you would like to know how would we use the path exactly?
this is the grommet code for one icon
import { StyledIcon } from '../StyledIcon';

export const Accessibility = props => (
  <StyledIcon viewBox='0 0 24 24' a11yTitle='Accessibility' {...props}>
    <path fill='none' stroke='#000' strokeLinecap='round' strokeLinejoin='round' strokeWidth='2' d='M4,8 L11,8 L11,14 L7,21 M20,8 L13,8 L13,14 L17,21 M12,5 C12.5522847,5 13,4.55228475 13,4 C13,3.44771525 12.5522847,3 12,3 C11.4477153,3 11,3.44771525 11,4 C11,4.55228475 11.4477153,5 12,5 Z M11,8 L13,8 L13,13 L11,13 L11,8 Z' />
  </StyledIcon>
);

So i guess we would make the Wrapper Component similar to this where path would be a prop then use it like
<SvgIcon path={path}/>
I hope i answered your Q

@woss Would it be OK if you still have to install @material-ui/core (what option 1 implies, as far as I know)?

Do you know when would we be able to drop the .cjs extension?

As far as I remember we only use .js extensions for shipped files due to lacking tooling support. As to not shipping a commonjs build: Once we drop support for node 10. Node 10 reaches EOL on 2021-04-30.

@oliviertassinari well i guess installing no, but bundling it yes. not sure atm, i'll have to check with my guys and tell you more after that

on the other hand i got the idea to completely extract paths into the separate folder called paths inside the packages/material-ui-icons ( for the time being and for the discussion) @oliviertassinari  check my fork and implementation here https://github.com/woss/material-ui/tree/woss-extract-paths/packages/material-ui-icons/paths
If we go this way, you could create separate repo just for the paths, then include that into the icons and the rest of us can just install the paths and have our implementations.
Later when google introduces new icons, or changes the current ones, just update this new repo and voilà we all benefit and get then new updated icons without any overhead.
Please tell me what do you think

@eps1lon Ok thanks. It sounds like we will be able to make the icons repository lighter in the near future.
@woss So you are suggesting option 2 or 3 from https://github.com/mui-org/material-ui/issues/21251#issuecomment-688923161?

With this approach option 3 would be the best, don't you think?
Option 2 with the new files that i've created would be a good solution but you would still need to do the same thing as in option 3, difference would be that with option 3 material-io/core is not installed even declared since the files are just strings and it can be used anywhere.
I understand that it requires time to set it up but honestly i've spent 30 min creating these files, mostly went on the how to sed this and that.
Option 3: when you make the new package iconPaths or however you want to call it, let me know and i will add the files from my fork to it. then we PR and merge upon the approval, you publish it and i get to install them and get rid of bloated package we are using now :)

@woss If I understand: a. you don't want to have @material-ui/core bundled, why? b. you don't want @material-ui/core to be installed in your file system, why?
Note that with option 2, we can make @material-ui/core an optional peer dependency, which will solve both a. and b.

@oliviertassinari
a: i really don't need it
b: i really don't need it
Why creating new package that will hold only the svg paths and nothing else doesn't sound like a great approach?

@woss If all you want are the raw SVG paths, you might be better off starting here (Although it seems that whoever at Google is now maintaining this scrapes them! 😆)

I'd also really like a standalone @material-ui/icons package. Having to install the entire @material-ui/core package for a single function createSvgIcon seems pretty crazy to me. Whilst I understand this sits on the file system and doesn't get built into production with tree shaking, it still takes up time locally and on CI installing. And it's confusing for new developers reading our package "why do we have this? aren't we using x framework instead?" And the perfectionist in me can't stand having a dependency we don't directly use 🥲

Further, here's an analysis of a create-react-app bundled app that imports just 3 icons from @material-ui/icons directly (like this: import AccountBalanceWalletOutlinedIcon from "@material-ui/icons/AccountBalanceWalletOutlined";)
19.5kb for three icons is pretty crazy.

19.5kb for three icons is pretty crazy.

The library is not intended to be used with just 3 icons. You should download the icons directly from https://material.io/icons/

I'm closing as the issue didn't get much interest since it has been open.
With v5, the pain is reduced. The overhead of one icon is now about the layer we add on top of styled-components/emotion. Mainly the system, the default theme, and the SvgIcon component.
In v5.0.0-beta.2, with a bare Next.js installation

emotion:
@material-ui/system:
@material-ui/core:

The overhead seems to be 6 kB gzipped now, assuming you would already have emotion or styled-components in your bundle.

It's really a shame that v5 requires emotion, we don't want extra styles runtime lib so we'll stick to v4. 🤷♂

Yeah, would indeed be nice to have this as standalone package.


test: updated getUser route

Test coverage results :test_tube:
:white_circle: Total coverage has not changed
No changes to code coverage between the base branch and the head branch

/ok-to-test sha=5c607ff

/ok-to-test sha=5c607ff

/ok-to-test sha=5c607ff


undefined is not an object (evaluating NativeModuels.UIManager.RCTVideo.Constants')

Getting red screen of death with
undefined is not an object (evaluating NativeModuels.UIManager.RCTVideo.Constants')
on Android
under react-native 0.23.1

Did you try re-running: react-native run-android or react-native run-ios? I had this same problem but this did the trick for me. I forgot to re-run this after installing react-native-video through npm install.

@bbhh: definitely did, happens on Android every time. Thanks for the reply.

Fixed, I think one of the gradles had a typo. For anyone finding this bug, double check that all three files are perfect: build.gradle, settings.gradle, MainActivity.java

I am getting this when react-native run-ios. This can't be a problem in any of the gradle files or the MainActivity.java, right?

I'm having the same issue, running react-native run-ios. please advise on how to fix this?

I'm having the same issue for react-native run-ios.

I am trying to run video in IOS device using react native but I found Unhandled JS Exception: undefined is not an object (evaluating 'NativeModules.UIManager.RCTVideo.Constants') error. Error screen shot here
http://screencast.com/t/xoL6C50QKDi

Same issue here. Has anyone found a solution/workaround for this problem ?

Also looking for solution, using react-native run-android.

@BranoMatan I found out the problem was with the rnpm link react-native-video not working properly.
Solution: open android/app/src/main/java/com/app_name/MainApplication.java in the top section of the file (where all the imports are) add import com.brentvatne.react.ReactVideoPackage; and then in the getPackages() method add new ReactVideoPackage(), build again and run.

Thanks @logileifs ! Worked perfectly

@logileifs where can i find the getPackages() method? i did other changes as you suggested.

@Johnny1109 if your react native version is 0.29.0 or greater you will find it in android/app/src/main/java/com/NAME_OF_YOUR_APP/MainApplication.java
If your react native version is less than 0.29.0 than you will find it in android/app/src/main/java/com/app_name/MainActivity.java

@logileifs thanks logileifs, i got it in MainApplication.java
protected List getPackages() {
return Arrays.asList(
new MainReactPackage();
new ReactVideoPackage();
);
}
is this correct, because still i am getting error

@Johnny1109 You're almost there! Just change the semicolon after new MainReactPackage() to a comma. I should look like this:
    return Arrays.asList(
        new MainReactPackage(),
        new ReactVideoPackage()
    );
}```

@logileifs thank you so much.. it works now

@Johnny1109 you are very welcome :)

@logileifs any idea why video not visible, i can hear the audio.. thanks in advance

@Johnny1109 I'm sorry but that's a totally unrelated problem. Most likely your view is too small so your video is not appearing or it's simply not on the screen itself. You should really ask that question somewhere else like stackoverflow

@logileifs I am getting below error after doing what you suggested
error: cannot find symbol
new ReactVideoPackage()
^
symbol: class ReactVideoPackage
2 errors
:app:compileDebugJavaWithJavac FAILED
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':app:compileDebugJavaWithJavac'.

you are great!

Just wanted to post my most recent workaround for iOS in case someone runs into this again. I blew away node_modules, reset any XCode changes to the .pbxproj related to react-native-video, then did a fresh npm install and a fresh react-native link react-native-video and it worked. I'm assuming the linking got messed up somehow and removing those attempts and starting over helped

undefined is not an object (evaluating 'CardIOUtilities.DETECTION_MODE')
No matter what i do i keep getting this error. What can i do?

@Tzinov15 Still i have the issue after following your steps. I am trying to do this in Expo. Any suggestions?

@varunrayen I'm also experiencing the issue after following @Tzinov15 steps.. Anybody have a solution?

Same issue, not working

$ react-native --version
react-native-cli: 2.0.1
react-native: 0.46.4

on my package.json
...
  "dependencies": {
    "expo": "^19.0.0",
    "react": "16.0.0-alpha.12",
    "react-native": "^0.46.1",
    "react-native-awesome-card-io": "^0.6.4",
    "react-native-video": "^2.0.0"
  }
...

same issue on expo!

@varunrayen I opened an issue on expo, could you help me to provide a repro?

Same issue. The  doc me . Before you use it , you must run rnpm link.When the link may fail,do it manually.

For Expo users, this library doesn't seem compatible with Expo, you can use this library :
https://github.com/expo/videoplayer

I solved it by installing react-native-video with pods :

install pods
add this to your podfile is ios folder of your project :
pod 'react-native-video', path: '../node_modules/react-native-video'
launch pod install
maybe delete the "-obj" in the "target support files" of file "pods". You can find it by opening your xcworkspace file in xcode.
rerun your project

same with expo too

try to add dependencies in build.grade Module: app
dependencies {
.....
compile project(':react-native-video')
}

Run the command of react-native link and after react-native run-android.
The first command links the dependencies and after that it will work!

@Lipfroy I was hoping this would be the magical solution but it broke my build. Metro bundler should supposedly do all this linking manually so doing it in XCode is unnecessary:
error React Native CLI uses autolinking for native dependencies, but the following modules are linked manually:
  - react-native-video (to unlink run: "react-native unlink react-native-video")
This is likely happening when upgrading React Native from below 0.60 to 0.60 or above. Going forward, you can unlink this dependency via "react-native unlink <dependency>" and it will be included in your app automatically. If a library isn't compatible with autolinking, disregard this message and notify the library maintainers.
Read more about autolinking: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md

Found the solution for my case, after re-unlinking the native dependency:
cd ios/
pod install

Thanks to https://github.com/react-native-community/react-native-video/issues/1502#issuecomment-480905260


RFC: Strategy API

RFC: Strategy API
Summary: Enable trybuild to work in non-cargo environments by customizing the logic used to build, run, and check outputs.
This issue proposes to add a Strategy trait to trybuild, allowing a user to run in non-cargo environments (#14). I spent a bit of time prototyping before coming to this particular API, and I’m pretty sure this can be implemented in a way that’s not too disruptive. That said, I wanted to get feedback before doing a full implementation.
The proposed API is below.
pub trait Strategy: Send + Sync + Debug {
    /// Called once, before running all tests.
    fn prepare(&mut self, tests: &[Test]) -> Result<Project, Box<dyn Error + 'static>>;
    /// Returns a command that can be executed to build the given test.
    fn build(&self, test: &Test) -> Command;
    /// Returns a command that can be executed to run the given test.
    fn run(&self, test: &Test) -> Command;
}

/// Describes an individual test being run.
struct Test { ... }
impl Test {
    /// A unique name for the crate and binary.
    pub fn crate_name(&self) -> String;
    /// Path to the source file.
    pub fn path(&self) -> &Path;
    /// Whether this test requires actually building and running a binary.
    pub fn requires_run(&self) -> bool;
}

/// The default strategy used.
pub struct CargoStrategy { ... }
impl CargoStrategy {
    pub fn new() -> Self;
}
impl Strategy for CargoStrategy { ... }

#[derive(Default)]
#[non_exhaustive]
pub struct Project {
    /// Source directory of the project.
    ///
    /// Occurrences of this are replaced with `$DIR` in compile output.
    pub source_dir: Option<String>,
    /// Source directory of the workspace which contains this project.
    ///
    /// Occurrences of this are replaced with `$WORKSPACE` in compile output.
    pub workspace: Option<String>,
}

Finally, a method would be added to TestCases to allow passing in a strategy object (maybe new_with_strategy()).
Possible extensions
Normalization API
After this I’d like to add something like the following API for customizing the normalization strategy. This makes it possible to add your own normalization passes and even to use trybuild with tools besides rustc, which are both use cases I’m interested in.
If this is something you never want in trybuild, that would be good to know 🙂
pub trait Strategy: Send + Sync + Debug {
    /// ... everything above, plus ...

    /// Normalizes the diagnostics in `output` and returns a version
    /// suitable for saving to a file.
    fn normalize(&self, project: &Project, test: &Test, output: &str) -> String {
        crate::normalize::diagnostics(project, test, output)
    }

    /// Checks whether the two outputs `expected` and `actual` are
    /// considered to match.
    fn matches(
        &self, project: &Project, test: &Test, expected: &str, actual: &str
    ) -> bool {
        crate::normalize::matches(project, test, expected, actual)
    }
}

/// Provides normalizing functionality for rustc output.
pub mod normalize {
    pub fn diagnostics(project: &Project, test: &Test, output: &str) -> String;

    pub fn matches(
        project: &Project, test: &Test, expected: &str, actual: &str
    ) -> bool;
}

Parallel execution (#6)
If we want to support parallel test execution, we could added a supports_parallel() method to Strategy, that returns false by default. If needed, we could also add a prepare_thread() method. Strategy has Send + Sync supertraits so these bounds don’t become a problem in the future.

Thanks for putting together this proposal! I think I would prefer not to maintain that API as part of this crate, but it would be awesome for someone to build it as its own crate (trybuild fork or clean slate).

I thought that might be the case :)
Sounds good, I may do that. Closing for now.


Add ability to clone/duplicate an existing server to current or other node

I think being able to spool up a development server by cloning an existing production server would be an extremely useful and powerful tool. Maybe something can be done with rsync between the containers?

As soon as #18 is implemented we could just locally clone the server by copying the files and then transfer it to another node if required.

Firstly, sorry to bump this
But could this be looked into? Would be incredibly useful.

#18 is already included in 1.0. So really this only needs a slight shift to actually impliment now

Closing, preferring newer #2148 in favor.


Fix "directory doesn't exist" in NugetV2

When doing a paket restore using a local nuget repository that is not reachable, the process crashes without telling which package or feed cause the issue. There's already a check if the package is not present in the repository but not if the repository itself is unreachable.
Had the issue with a repo in the paket.lock that can't be reached from another server.

thanks!


feat(live-13282): spacing based on screen resolution

✅ Checklist

[x] npx changeset was attached.
[ ] Covered by automatic tests.
[ ] Impact of the changes:

...

📝 Description

make spacing consistent around swap form
make spacing responsive above 1200px height
change swap tab name

❓ Context

JIRA or GitHub link:
https://ledgerhq.atlassian.net/browse/LIVE-13282

🧐 Checklist for the PR Reviewers

The code aligns with the requirements described in the linked JIRA or GitHub issue.
The PR description clearly documents the changes made and explains any technical trade-offs or design decisions.
There are no undocumented trade-offs, technical debt, or maintainability issues.
The PR has been tested thoroughly, and any potential edge cases have been considered and handled.
Any new dependencies have been justified and documented.
Performance considerations have been taken into account. (changes have been profiled or benchmarked if necessary)

/generate-screenshots

/generate-screenshots


Automated image updates

Automated changes by the image-deps-updater GitHub action

🤦 this was not to main
sorry @emosbaugh


RF Tools spawner only accepts Pumpkins as living matter

question about ATM3 rf-tools spawner.  I play the modpack All the mods 3. I messed around with the rf tools spawner yesterday and found that the living matter has to be pumpkins. Is this for purpose? regarding to wiki a few other things should work (potatose among others) but the dont seem to work.
i connected 3 matter beamers, everything has RF and the beamers got redstone signal as required. I tried to spawn wither skeletons which requires bones, nether rack and a living material (potatoes, wheat and pumpkins) and only pumpkins work for me.

https://github.com/AllTheMods/ATM-3/issues/110

edit: fish seems to work, too. Nothing else i tried so far.

Try something else too - leaves, raw meat, flowers. The config file provided by the modpack doesn't change what counts as living matter or things required to summon a wither (just checked), so that's not it. Did you provide the necessary amount of it (30 items)?

i put in a stack always. i have tried so far wheat (doesnt work), fish (works), raw meat (doesnt work), egg (doesnt work), pumpkins (work), i will try more. The two other requirements are will "over the top" far more the needed. Could that be the problem?

after updating the modpack i use (all the mods 3) to latest 3.2b it seems to work now, wheta, raw meat etc. now works. can be closed


Deserialize TelemetryItem properly from local storage

TelemetryItem.from_dict() deserializes TelemetryItem incorrectly, where the base_data field is of type MonitorDomain, not the actual class that inherits from MonitorDomain (like RequestData). The actual fields are all dumped into "additional_properties". We call as_dict() again on the actual type using additional_properties and assign that to the TelemetryItem.

API change check
API changes are not detected in this pull request.


Dropdown style issue with empty defaultText

Going to close this issue since it's been a couple of months, if this issue still persists please re-open though!


check assumptions before running statistical tests?

Is your feature request related to a problem? Please describe.
Problem with code? No. Problem with how people might use it? Maybe.
Right now, you can call scipy.stats.ttest_ind (for example) on two samples with different sample/population variances, violating the assumption stated in the documentation:

This test assumes that the populations have identical variances by default

Describe the solution you'd like
Check the assumption and raise a warning if violated, so the user knows to not take the test result seriously.
Describe alternatives you've considered
Doing this for other tests. Then again, people could just read the documentation. But let's face it... most will find a solution to "two-sample t-test scipy" online, run their samples through there, see p<0.05 and call it a day.
Additional context (e.g. screenshots)
Math person here... helped someone revisit results from a statistics project. Everything seemed to imply a lack of significant differences, except the results received from the t-test that the textbook said was useful in situations like this one.
If it's not the place of the developers to make sure the code is being used correctly, so be it, I understand. Feel free to close the issue in that case, but I couldn't find a discussion along these lines so I thought I would start one. =D

If it's not the place of the developers to make sure the code is being used correctly

I think that's up to the user for subject issues, i.e. is the test and the underlying assumptions appropriate for the specific case.
The main problem here is how to evaluate that the variances are the same. They will never be exactly the same. Using a equality of variance hypothesis test to decide, turns this into a pre-test estimator with different statistical properties. In many cases they don't have good properties. Test on equality of variances are not very powerful in small samples and depend even more on the underlying assumptions, i.e. are less robust to violating these assumptions than the t-test itself.
A better recommendation is that if the user is not sure that the variances are the same, then go for the version of the test that is robust to different variances. It might loose some power, but will still be correct if variances differ.
(In the more general case for OLS, hypothesis tests can be made robust to differences in variances by using sandwich, heteroscedasticity robust standard errors. Some econometrics textbooks recommend to always use those. However, in small samples, they can be worse than using the usual nonrobust standard errors even if those are "wrong", they can just be less wrong in small samples.)

oh that's a very good point... the threshold would be tricky to define, if possible at all. 5% relative difference? In any case, I think it ultimately is probably up to the user to figure this out and use the equal_var=False flag on their own. Just seems like maybe the False option would be a more reasonable default... but then again, standardizing data is common... (in which case, running the test would still be a wrong thing to do since the means have been set to zero).
Thanks!

Just seems like maybe the False option would be a more reasonable default

I agree with this, however it would require a break with backwards compatibility and it would be less traditional, i.e. users are likely less familiar with it and complain that they don't get the "standard" t-test.
Another problem is that there are many directions in which assumptions could be violated and it is not clear what the appropriate more robust version should be for the default.
(same reasons that statsmodels uses the nonrobust version by default, and has various robust versions for standard errors as option.)