Allow IntanRawIO & IntanIO to handle the headerless binary files

Replaces #1318.
After plenty of great discussion with @h-mayorquin I have changed my mind and think it might be better to just incorporate the new file types in the IntanIO family rather than make a new io.
TODO:

[x] Improve comments
[x] Make sure tests pass

Also would fix (https://github.com/SpikeInterface/spikeinterface/issues/194)

@h-mayorquin,
Feel free to give this a read. I think the diff will be easier to tell what was from the original implementation and what is new. Then if you want to improve something that was older we can do that too.

Notes based on discussion with Heberto.
chan_id as native channel name vs chan_name as custom channel name
timestamp assert messaging improvement

Definitely let me know what the issue is. Do you know what the file structure is? Is there a particular signal missing? Maybe I can make a simulated dataset that is similar so I can test on my end too?

@h-mayorquin any chance you would run a cProfile on your data? I'm curious about performance with the many memmaps being created and then maybe reading one chunk of data....

Yep, let me do some profiling.

Why did you decided to go back to structured dtypes for the one-file-per-channel format in this commit? : O

I didn't. It's because we iterate through each channel above so I need this in a giant list so that I can iterate through the list. It is only put in as the actual dtype not a structured.

Ah, OK, since you added the dictionary of number of channels (great idea btw!) we don't need this. See:
https://github.com/zm711/python-neo/pull/3
I also did the pathlib discussed above.

I see what you mean. That was great. Thanks really cleans things up.

@h-mayorquin, Sam is busy for the next few weeks so I doubt he will get to this in that time frame, but are you good with this just so I can ping him to let him know this can be reviewed whenever.

Yeah, I was aware that he has his hands busy with the updates in Spikeinterface and some events.
This is ready on my side. Let's ping him on two weeks (I will put in my calendar) as I would not like to stress him : )

Sounds good. Thanks for all the great feedback and additions during the process. It's been great :)

Sorry to be bouncing from one pull to another. This is in response to @zm711 here.
Sorry, I forgot this was a neo pull and not a spike-interface pull !
What are the second to last elements?
The second to last elements in the header are usually the lower-limit of the dtype of the channel. This is very useful for low-level operations. In this pull request it is set to 0. for all channels. Here's a snippet from a 64-channel probe I use, first using the proposed code :
 ('A-063', 'A-063', 25000.    , 'uint16', 'uV', 1.950e-01,   0.  , '0')
 ('A-AUX1', 'A-AUX1',  6250.    , 'uint16', 'V', 3.740e-05,   0.  , '1')
 ('A-AUX2', 'A-AUX2',  6250.    , 'uint16', 'V', 3.740e-05,   0.  , '1')
 ('A-AUX3', 'A-AUX3',  6250.    , 'uint16', 'V', 3.740e-05,   0.  , '1')
 ('A-VDD1', 'A-VDD1',   195.3125, 'uint16', 'V', 7.480e-05,   0.  , '2')
 ('ANALOG-IN-1', 'ANALOG-IN-1', 25000.    , 'uint16', 'V', 3.125e-04, -10.24, '3')
 ('DIGITAL-IN-01', 'DIGITAL-IN', 25000.    , 'uint16', 'TTL', 1.000e+00,   0.  , '4')]

Next, using the current code:
('A-061', '61', 25000.    , 'uint16', 'uV', 1.950e-01, -6389.76, '0')
 ('A-062', '62', 25000.    , 'uint16', 'uV', 1.950e-01, -6389.76, '0')
 ('A-063', '63', 25000.    , 'uint16', 'uV', 1.950e-01, -6389.76, '0')
 ('A-AUX1', '64',  6250.    , 'uint16', 'V', 3.740e-05,     0.  , '1')
 ('A-AUX2', '65',  6250.    , 'uint16', 'V', 3.740e-05,     0.  , '1')
 ('A-AUX3', '66',  6250.    , 'uint16', 'V', 3.740e-05,     0.  , '1')
 ('A-VDD1', '67',   195.3125, 'uint16', 'V', 7.480e-05,     0.  , '2')
 ('ANALOG-IN-1', '68', 25000.    , 'uint16', 'V', 3.125e-04,   -10.24, '3')
 ('DIGITAL-IN', '69', 25000.    , 'uint16', 'TTL', 1.000e+00,     0.  , '4')]

Channel IDs
I think addressing legacy code is extremely important. Maybe providing very verbose error messages which notify the user of the issue, and/or repeatedly listing the changes in release changelogs for at least 2 releases.

The channel ids issue should be discussed outside of here. It was changed in https://github.com/NeuralEnsemble/python-neo/pull/1415 so it will need to be reverted outside of this.
My initial intuition is that downstream code should not depend on channel_ids. I would like to know use cases for that so we can be more mindful about this in the future if they exists though.

Sorry, I also have to add - this is awesome work.  I/O off of proprietary hardware is probably one of the most paint-staking things to code. Thank you very much for taking this on.

@ChauhanT, the minimum value for an unsigned integer is 0? I'm not sure what the problem is for the dtype question.
As far as the channels this may be a situation where a bug has become a feature. It was not the right choice originally to do it the way we did, but I do understand the concern. I personally use channel_indexes and for most people they could use channel_indexes in place of what they did for chan_ids in the past, but with ints instead of strings. But if this is a huge concern please open an issue @ChauhanT and we three can discuss there and revert if we absolutely need to in another PR.

@zm711  Ah, there might be an issue there. IIrc the dtype for analogue channels is int16 and not unsigned. At least for the one-file-per-channel format.

I still don't understand your proposal above. Is that the header for the signals, the dtype for the signals is here:
https://github.com/NeuralEnsemble/python-neo/blob/6cd8158d84a004217a9318c5aecc3e21df539ee0/neo/rawio/baserawio.py#L94-L103
The second to last element is the offset.

It's not a minimum value it's an offset. From Intan's documentation there is no offset....

@zm711 Gotcha. Thanks for explaining this. And what about the dtype of the amp data ? I just downloaded the manual. Afaict they use int16 for the one-file-per-channel format and uint for the one-file-per-recording formats. Do you reckon that might be an issue ? Without an offset, you'd probably have to use the sign of the signal.

pinging @samuelgarcia on this is on my to-do.

Salut Zach.
I am really sorry for taking so long to read tis pull request.
It is super well written and easy (and so quick) to read.
For me this OK to merge.
Merci infiniment! Big thanks to Ramon that follow this very closly.

Salut Sam! Thanks for reading it over!

I think we can merge. @alejoe91  : do you want to have look ?

Ok for me!


Revert test pass symbol in List reporter

Hello,
The List reporter's output regressed during a past refactoring. This pull request reverts the output to the old correct output but it still retains the benefit of the refactoring.
All tests passing.

Thank you! I noticed that my Putty window was showing green question mark icons for passing tests, even though my font (Consolas) has the CHECK MARK (\u2713) glyph. Turns out Consolas doesn't have MIDDLE DOT (\u00B7).

@Aldaviva nice one.


General pattern to update a key?

Because of the reliance on string keys, it can be tricky to manage updates to a value that affect its key. For the identity map I made in this gist I came up with an update method that makes it pretty straightforward to keep the key in sync when mutations happen. Is this a pattern that could be useful across the library where string keys are in use?
https://gist.github.com/chriseppstein/11ae09e2d96f72af036645a481d879e3#file-identitydictionary-ts-L41-L62

I agree that reliance on string keys in JavaScript is sometimes troublesome but I would refrain from implementing that in the library since it's a core language feature.
Also, I would like to hear other people opinion on this.

Closing this because of old age. If the issue persists, discuss it here and/or open a Pull Request please.


Allow Style Arrays in HOCs

For example, in text.props.ts change style?: TextStyle to style?: TextStyle | TextStyle[]

This will actually need some more work than just TypeScript changes as the style overrides are just splatted into a new object, so the array case would need to be explicitly handled.

@kevinvangelder what else is involved here? Maybe I can take this on.

We would need to detect if the overrideStyles prop is an object or an array, and either splat or map and splat respectively.

Ok, that's simple enough!

@mlaco I think that looks good. Can you update one of the storybook stories to have an array of styles and make sure it doesn't complain?


The add image Plugin

// Verify we have a valid jpeg header 0xff,0xd8,0xff,0xe0,?,?,'J','F','I','F',0x00

if (!imgData.charCodeAt(0) === 0xff ||
    !imgData.charCodeAt(1) === 0xd8 ||
    !imgData.charCodeAt(2) === 0xff ||
    !imgData.charCodeAt(3) === 0xe0 ||
    !imgData.charCodeAt(6) === 'J'.charCodeAt(0) ||
    !imgData.charCodeAt(7) === 'F'.charCodeAt(0) ||
    !imgData.charCodeAt(8) === 'I'.charCodeAt(0) ||
    !imgData.charCodeAt(9) === 'F'.charCodeAt(0) ||
    !imgData.charCodeAt(10) === 0x00) {
        throw new Error('getJpegSize requires a binary jpeg file')
}

Just for the documentation:
All JPEG start with FF D8 FF E0 00 10 4A 46 49 46 00
So the code was correct and this issue was closed correctly.


Swapping left ctrl and caps lock on italian layout, makes altgr become caps lock too

Microsoft PowerToys version
0.68.0
Installation method
GitHub
Running as admin
None
Area(s) with issue?
Keyboard Manager
Steps to reproduce

Swap left ctrl and caps lock while having an italian layout in use.
✔ Expected Behavior
AltGr behaves as AltGr, letting me type the at symbol which now i can't type.
❌ Actual Behavior
Pressing altgr (or the left alt key) will change the caps status.
Other Software
No response

/dup #3497


Refactor to create and destroy kind cluster in e2e tests

          I think we could refactor this PR to create the kind cluster in the Makefile? Correct?

Originally posted by @rphillips in https://github.com/openshift/instaslice-operator/pull/177#discussion_r1806676712

/assign

Separating the targets to create and destroy kind clusters leaves the test suite to just fetch the existing kubeconfig and proceed running the e2e tests.
This helps the test suite to be agnostic to the cluster type and so the extra checks can be removed from the code and restrict the changes just to the Makefile

/close
Closing this issue as the change is part of the following PRs
https://github.com/openshift/instaslice-operator/pull/203
https://github.com/openshift/instaslice-operator/pull/232


STABLE_CONFIGURATION_CACHE 활성화

Ref: https://github.com/chrisbanes/tivi/pull/1011

Close
Plugin 'com.google.gms.google-services': registration of listener on 'Gradle.addListener' is unsupported


[jira] Convert description to markdown

The description of an issue is now converted to markdown before we
render the description. This is necessary because Jira returns the
description in a wiki markup format, which doesn't look good when it is
directly passed to the ReactMarkdown component for rendering.
We also changed the logic to display the details of an issue, so that
only the fields which are relly available are displayed in the details.
This means if for example an issue doesn't have subtasks we do not
display the subtasks section anymore.
We also changed the color of the status label, so that the label matches
the color in Jira. The previously used color field seems to be
deprecated and Jira only allows 3 status categories. For these
categories we set the color: "Done" -> "green", "In Progress" -> "blue"
and "Open" -> "grey".

[x] I added a CHANGELOG entry for this change.
[ ] I adjusted the corresponding documentation for this change.
[ ] I adjusted the values.yaml file and the documentation for all values.

Codecov Report

Merging #415 (889da5e) into main (a51e5e1) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #415   +/-   ##
=======================================
  Coverage   46.35%   46.35%
=======================================
  Files         139      139
  Lines       11776    11776
=======================================
  Hits         5459     5459
  Misses       6176     6176
  Partials      141      141

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Add some perks

AMIK Mahaputra, Yasop, SMAN 2 Balige, SMAN 1 Serang Baru, and Belajar.ID

@bzntm Please provide us with a proof, which confirms that Indonesian Ministry of Education and Culture assign students and teachers with email addresses in a domain belajar.id. Thank you.

@bzntm First stage of verification passed, official domain is amikmahaputra.ac.id as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

@bzntm You probably missed my comment yesterday. Please react:
Please provide us with a proof, which confirms that Indonesian Ministry of Education and Culture assign students and teachers with email addresses in a domain belajar.id. Thank you.

@bzntm Please provide us with a proof, which confirms that Indonesian Ministry of Education and Culture assign students and teachers with email addresses in a domain belajar.id. Thank you.

Let me translate it to English, since the official Belajar.ID webpage is in Bahasa:
Akun Pembelajaran (further called as belajar.id) are assigned to students, teachers, and school administrators from ALL schools, starting from playgroup, primary school, junior high school, senior high school, school for special needs (SLB), and equivalency programme (Kesetaraan/Kejar Paket).
By using belajar.id, you can access anything you need to support learning activites, starting from accessing Kemendikbudristekdikti (Indonesian Ministry of Education, Culture, Research, and Higher Education) up to accessing apps for supporting learning activities
Government's Statement:
belajar.id is a governmental programme through Indonesian Ministry of Education, Culture, Research, and Higher Education to help and support learning activities
Here's attached screenshots in Bahasa:

@bzntm You probably missed my comment yesterday. Please react:
Please provide us with a proof, which confirms that Indonesian Ministry of Education and Culture assign students and teachers with email addresses in a domain belajar.id. Thank you.

See above reply by me, thank you

@bzntm First stage of verification passed, official domain is amikmahaputra.ac.id as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

@bzntm Thank you for the clarification. Pull request merged.


Update reclaim-ai extension

Description
This pull request introduces a utility function filterMultipleOutDuplicateEvents. The function filters out events that are synchronized, managed by Reclaim, and part of multiple calendars. To achieve this, the function groups events based on their start and end times, then filters out the irrelevant events based on specific criteria (e.g., event title matching "Personal Commitment", "Work Commitment", or "Travel Commitment", and events that are both synchronized and managed by Reclaim).
Additionally, the filterMultipleOutDuplicateEvents function has been integrated into the useEvent hook and the notifications component to ensure that the displayed events are filtered according to the new logic.
Here’s a detailed summary of changes made in this PR:

Added filterMultipleOutDuplicateEvents utility function to src/utils/events.ts.
Updated useEvent hook in src/hooks/useEvent.tsx to use filterMultipleOutDuplicateEvents for filtering events.
Updated notifications component in src/notifications.tsx to use filterMultipleOutDuplicateEvents for filtering events.

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Thanks for another update @shkreios 🔥 Do you mind adding a CHANGELOG entry?
@ajohnson1200 do you mind checking this 🙂


Requirement to specifyIAP_BACKEND_SERVICE_ID creates a circular dependency

I do not see a good way to create the cloud run job using an infrastructure as code solution like terraform due to the circular nature of the requirement to specify the IAP_BACKEND_SERVICE_ID in the cloud run service itself, which needs to be created before the backend service can be created.
This is sample failing terraform configuration:
resource "google_service_account" "jit_access" {
  account_id   = "jit-access"
  project      = var.project_id
  display_name = "Grants just-in-time access to IAM roles"
}

resource "google_project_iam_member" "jit_access_iam_admin" {
  project = var.project_id
  role    = "roles/resourcemanager.projectIamAdmin"
  member  = google_service_account.jit_access.member
}

resource "google_project_iam_member" "jit_access_cloudasset_viewer" {
  project = var.project_id
  role    = "roles/cloudasset.viewer"
  member  = google_service_account.jit_access.member
}

resource "google_project_iam_member" "jit_access_token_creator" {
  project = var.project_id
  member  = google_service_account.jit_access.member
  role    = "roles/iam.serviceAccountTokenCreator"
}

resource "google_cloud_run_v2_service" "jit_access" {
  name     = "jit-access"
  location = var.region
  project  = var.project_id
  ingress  = "INGRESS_TRAFFIC_INTERNAL_LOAD_BALANCER"
  traffic {
    type    = "TRAFFIC_TARGET_ALLOCATION_TYPE_LATEST"
    percent = 100
  }
  template {
    containers {
      image = "${var.region}-docker.pkg.dev/${var.project}/containers/jit-access:latest"
      name  = "jit-access"
      env {
        name  = "RESOURCE_SCOPE"
        value = "projects/${var.project_id}"
      }
      env {
        name  = "RESOURCE_CUSTOMER_ID"
        value = var.customer_id
      }
      env {
        name  = "IAP_BACKEND_SERVICE_ID"
        value = google_compute_backend_service.jit_access.generated_id
      }
      resources {
        startup_cpu_boost = true
        cpu_idle          = true
      }
    }

    service_account       = google_service_account.jit_access.email
    execution_environment = "EXECUTION_ENVIRONMENT_GEN2"
  }
}

data "google_iam_policy" "jit_access_iap" {
  binding {
    role = "roles/iap.httpsResourceAccessor"
    members =<EMAIL_ADDRESS>  }
}

resource "google_iap_web_backend_service_iam_policy" "jit_access" {
  project             = var.project_id
  web_backend_service = google_compute_backend_service.jit_access.name
  policy_data         = data.google_iam_policy.jit_access_iap.policy_data
}

resource "google_compute_region_network_endpoint_group" "jit_access" {
  name                  = "jit-access"
  network_endpoint_type = "SERVERLESS"
  region                = var.region

  cloud_run {
    service = google_cloud_run_v2_service.jit_access.name
  }

  lifecycle {
    create_before_destroy = true
  }
}

resource "google_compute_backend_service" "jit_access" {
  name = "jit-access"

  backend {
    group = google_compute_region_network_endpoint_group.jit_access.id
  }
  iap {
    oauth2_client_id     = google_iap_client.my_iap_client.client_id
    oauth2_client_secret = google_iap_client.my_iap_client.secret
  }

  custom_response_headers = local.security_headers
  log_config {
    enable = true
  }
}

Can the required environmental variable IAP_BACKEND_SERVICE_ID be removed from the cloud run job? From the docs, I am not clear on why the cloud run job needs to be aware of the IAP environment feeding traffic to it.

JIT Access completely relies on IAP for authentication and authorization. To verify that (a) IAP is enabled at all and (b) that a request has indeed being vetted by IAP, JIT Access verifies the x-goog-iap-jwt-assertion header. For that, it needs to know what audience to expect in the header.
On AppEngine, the expected audience can be derived from the project ID. On Cloud Run, there's no way for the application to determine the audience automatically, hence the need for the  IAP_BACKEND_SERVICE_ID variable.
To break the cyclic dependency between the load balancer and Cloud Run, you can deploy things in the following order:

Load balancer backend
Cloud Run
Other load balancer components

That's the sequence followed by the manual setup instructions. Maybe you can get Terraform to follow this sequence by using depends_on?

Thanks @jpassing for the response!
Unfortunately, to the best of my knowledge, depends_on doesn't resolve circular dependencies, it only pulls an unconnected dependency into the dependency graph for the current node.
Is there a way we can rely on the terraform configuration to ensure that all traffic flowing in to the jit-access service has already been authenticated and authorized by IAP, and use a new flag to skip re-validation in jit-access? If this is possible, IMHO, the requirement to break infrastructure as code and require a superuser to perform manual steps negates any security improvement from a re-validation of an already validated token.

What should work is to...

Manually create the backend:

gcloud compute backend-services create jitaccess-backend \
  --load-balancing-scheme=EXTERNAL \
  --global

Let the TF module use the existing backend (either by using a data source or passing the backend ID as parameter)

I know it's not great, but (1) is a one-time thing, so any subsequent deployments could be fully automatic.

I think this should be queryable at runtime in cloud run:
The network endpoint group can be found by grabbing self_link from
curl \
  'https://compute.googleapis.com/compute/v1/projects/{projectId}/regions/us-central1/networkEndpointGroups?filter=cloudRun.service={env.K_SERVICE}ANDnetworkEndpointType=serverless

docs for K_SERVICE
We can then use that to query for the backend service:
curl \
  'https://compute.googleapis.com/compute/v1/projects/{projectId}/global/backendServices?filter=iap.enabled=true AND kind=compute#backendService \

Theoretically we would be able to filter in this query by adding backends:group = {neg_link}, but this doesn't seem to work in this query, so we would have to filter for a result that has a backend group set to the neg self_link in code.

Quering the API to determine the backend ID is an interesting idea, and this approach would avoid the potential security risks of accepting all audiences. We could do that lookup during startup.
However, there are a few downsides:

This requires the Compute Engine API, which typically isn't enabled in these projects.
Listing backend services requires the compute.backendServices.list permission, which the application service account doesn't have by default.
It requires an extra Maven dependency.

So maybe it's easier to go ahead with your PR.

Thanks @jpassing for considering this idea, and for your hard work on this project in general.
I agree that the approach here is a lot more work than #449, so we should start with that for now and keep this idea as a longer-term discussion if that's ok with you. I have some thoughts on the downsides you listed.

I disagree on this one, if you are using cloud run, you need to setup a compute backend service, which would require enabling the compute engine API already AFAIK.
I agree that one is definitely a downside in that it is more work/complexity. I don't think compute.backendServices.list is inherently the problem from a security standpoint, because that is a lot less dangerous than the roles/resourcemanager.projectIamAdmin and roles/cloudasset.viewer that are already needed. However, it would need a new custom role which is a little annoying. Maybe this would be a fallback behavior if IAP_BACKEND_SERVICE_ID  is unspecified, and is just a little bit more work if you don't want to specify it? For manual CLI creators, specifying IAP_BACKEND_SERVICE_ID will be a lot easier, and for terraform users a new custom role isn't too bad.
It looks like RuntimeEnvironment.getMetadata already makes REST calls - could that same method be used?

FWIW: we had the same cycle issue and "solved" it by ensuring we know the cloud run name beforehand - removing the pending creation dependency. We did this by simply creating a local variable being the name, and passing that as the cloud run name to the cloud run resource as well as the network endpoint group that is referencing the cloud run. Now in theory this could lead to race conditions, as this means there is no direct dependency on the actual cloud run anymore when creating the network endpoint group - but in reality this has not presented us with any issues. We've done 10s of complete destroy/create cycles of our JIT module, and never had any issues.

Release 1.8.1 now lets you control whether JIT Access should verify the audience of IAP assertions by using the IAP_VERIFY_AUDIENCE configuration option, so I'll close this issue.


Update to string instead of integer

The readme and examples say integer when it is supposed to be a
string. This PR changes the examples and the README to reflect it.

/cc @russellseymour
Signed-off-by: JJ Asghar<EMAIL_ADDRESS>

Hi @jjasghar , Can you please provide us references where it says vlanId needs to be a string?
Thanks.

We got an error when running the code. We converted it to a string and it worked.

Can you Please share the steps to reproduce this error? This attribute is an integer and not a string according to product documentation.
We will reproduce this and check for the root cause.

After investigation to reproduce this error and provide you with a stack trace, I have found that the recipe will compile if the vlanId is set as an integer.
I have been unable to reproduce the inital error I saw several times so this is a non-issue.

Per @russellseymour 's comment I'll close this.


%GC content

Hi,
would it be possible to add a calculated %GC content on the base contents graphs near the base index (top right) ?
Thanks

It's possible.
But how about adding this info in the top summary table?

I thought about that before asking, but for the the informative function, it would be more ergonomic to have it near where the data is graphed.
Doesn't preclude to not put it in the summary, but if you go that route It would be nice to now have 2 sections in the summary, one for each read when doing paired reads.  :)
Thanks.

Good suggestion, I will implement it.

Hi, this is implemented!
Please try the latest v0.11.0

Wow... really nice with the GC.  Cosmetic thing, the right parenthesis seems half cropped on the image after the % sign.
Nice addition also with the KMER table.

Aha...yes, I will figure out how to fix that.

If you have any feature request, please file new issues.
I will implement overrepresented sequence analysis in following step.


kubeadm-upgrade.md: include a generated page about 'diff' and adjust notes

kubeadm-upgrade: include new command kubeadm upgrade diff …
Also:

Include note that this was added in 1.11.
Modify the note about upgrade guidance.

Fixes kubernetes/kubeadm#832
NOTE!!!:
EDIT: @tengqm mentioned that we:

don't have to include generated pages in PRs
the HTML styling issue explained bellow will be fixed (soon)

the generated page kubeadm_upgrade_diff.md does not have HTML formatting like the two other generated pages here - e.g.:
https://github.com/kubernetes/website/blob/master/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_apply.md.
logged issue about the above:
https://github.com/kubernetes/website/issues/8723

/assign

Will dig into scripts for generating. @steveperry-53 seems like I've seen related PRs? Do you have any idea what's going on here?

@Bradamant3
thanks a lot.
this is a bit of a blocker because me and @chuckha need to document some new kubadm commands and they need this missing HTML styling. we don't want to add it by hand.

Turns out the nice tables were generated locally. We're waiting on a PR merge, here: kubernetes-incubator/reference-docs#47

that's a big PR if i've seen one - 21 thousand files.
is there a tool somewhere in there that is used for the nice tables?
if the nice tables were generated locally by a contributor and cannot be reproduced by others, perhaps this styling shouldn't have been accepted in MD files at the website repo before this PR got merged...

I've just tagged pwittrock there, and will continue to monitor. If y'all have ideas about how to get that PR merged (I have not got write access to the repo; I'm not even in the org), that would help.

yes, me too; i don't have powers in that org / repo.
i see that Lucas has powers there and this does affect kubeadm, yet i think this should be addressed to others.

/lgtm
@Bradamant3 @chenopis @neolit123 PTAL again and someone approve if this still looks good to you.
This does not look like a "new feature" to me, but if it is, @neolit123 please add it to the 1.11 feature tracking spreadsheet.

This does not look like a "new feature" to me, but if it is, @neolit123 please add it to the 1.11 feature tracking spreadsheet.

i don't really know.
to my understanding this is something that has a release note but it's not a new feature in the k8s sense (alpha, beta...etc stages):
https://github.com/kubernetes/kubernetes/pull/63930
LMK, if it has to be added to the sheet.

@justaugustus @idvoretskyi PTAL

@mistyhacks @Bradamant3 @tengqm
updated.

In case it's helpful -- there is a new command for kubeadm, per the linked k/k PR. So there is a new feature, but it's not a whole Big New Feature. (From what I've seen of previous releases, features listed on the spreadsheet often stay in the same stage of things, that is alpha | beta anyway, from one release to the next, while things are polished or improved or added to.)
We need to get the generated docs issue straightened out as soon as possible. I'll comment in the PR for the tooling also. We do need the generated doc so we can check the diffs when strings for docs change in k/k code, but if the format is different then the diffs are useless. I'll think some more about what to do in the meantime. For now, I guess, don't include the generated files in the PRs. But if you could hold off on any more PRs that refer to generated files for a few days (as much as a week? Would that work?), let's see what we can work out.

In case it's helpful -- there is a new command for kubeadm, per the linked k/k PR. So there is a new feature, but it's not a whole Big New Feature. (From what I've seen of previous releases, features listed on the spreadsheet often stay in the same stage of things, that is alpha | beta anyway, from one release to the next, while things are polished or improved or added to.)

yes, technically these are new features, but not features in the kubernetes/features sense.
we (sig-cluster-lifecycle) are adding like 4 new sub-commands to kubeadm for 1.11 and the maintainers wanted me to document them.

We need to get the generated docs issue straightened out as soon as possible. I'll comment in the PR for the tooling also. We do need the generated doc so we can check the diffs when strings for docs change in k/k code, but if the format is different then the diffs are useless. I'll think some more about what to do in the meantime. For now, I guess, don't include the generated files in the PRs. But if you could hold off on any more PRs that refer to generated files for a few days (as much as a week? Would that work?), let's see what we can work out.

yes, it's also not possible for sig-docs to review the generated files if we add the includes for them, but not the actual generated files in a PR. i will hold on sending more command PRs for now.
thanks.

kubernetes-incubator/reference-docs#47 is merged now.

yesterday, we spoke with @Bradamant3 and also according to what @tengqm is stating, this PR is good to be merged.
the generated / included .MD will come from the tooling.

rebased against 1.11.

/lgtm

/approve

Hmm, I must be missing something. This was merged into the release-1.11 branch, correct? Then why don't we see the change at either of theses places?
I'm talking about this change: "In Kubernetes v1.11.0 and later, you can use kubeadm upgrade diff to see ..."

http://kubernetes-io-vnext-staging.netlify.com/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/
https://deploy-preview-8617--kubernetes-io-vnext-staging.netlify.com/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/

@steveperry-53
i can see the include for the diff command in the second link, but not in the first one.
both links are missing the In Kubernetes v1.11.0 and later... note.
could be that the note was added later in an amended commit and the tooling did not re-generate a new preview for that.

Let's keep an eye on this. It's especially important that we get a good 1.11 preview here:
http://kubernetes-io-vnext-staging.netlify.com/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/

Let's keep an eye on this

i would ping the preview generation maintainer about this.
the problem can propagate to other RPs.

All Netlify deploys have been failing for a while. I've got a fix in mind, but want to take a real weekend, so I'll fiddle with it on Monday.


a lot of TapGestureRecognizer cause scroll lag in IOS

Details
I am utilizing the TapGestureRecognizer and OnTap callback to retrieve the clicked word in a list of Text widgets. While scrolling is smooth on other platforms, there is a lag when scrolling on iOS.
Target Platform: IOS
Flutter Version: Flutter 3.7.7 stable
Logs

Code sample
import 'package:flutter/gestures.dart';
import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: const WordsView(),
    );
  }
}

const text = '''
Lorem Ipsum is simply dummy text of the printing and typesetting industry.
Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.
It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged.
It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.
''';

class WordsView extends StatelessWidget {
  const WordsView({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
        appBar: AppBar(),
        body: Padding(
          padding: const EdgeInsets.all(8.0),
          child: ListView.builder(
              itemCount: 50,
              itemBuilder: (context, index) {
                return WordClickableText(
                    text: text,
                    onTap: (text) {
                      debugPrint('$text is tapped');
                    });
              }),
        ));
  }
}

class WordClickableText extends StatelessWidget {
  const WordClickableText({
    super.key,
    required this.text,
    this.style,
    this.onTap,
  });

  final String text;
  final TextStyle? style;
  final ValueChanged<String>? onTap;

  @override
  Widget build(BuildContext context) {
    return Text.rich(TextSpan(children: _getTextSpans(text)));
  }

  List<TextSpan> _getTextSpans(String text) {
    final spans = <TextSpan>[];
    final words = text.split(' ');
    for (final word in words) {
      spans.add(TextSpan(
        text: word,
        style: style,
        recognizer: TapGestureRecognizer()
          ..onTap = () {
            onTap?.call(word);
          },
      ));
      spans.add(TextSpan(
        text: ' ',
        style: style,
      ));
    }
    return spans;
  }
}

https://user-images.githubusercontent.com/37981688/227179859-9bbadd00-de0b-4d49-b7f5-058fa435bc00.mp4

It looks like the issue only happens on specific devices. I can scroll smoothly and see the tapped text on the output log as well.

iPhone 7, iOS 15.7.2 (physical device) ✅
iPhone 14 Pro, iOS 16.1 (emulator) ✅
iPad Air 5th generation, iOS 16.1 (emulator) ❌

✅: No Issue ❌: Issue reproduced
Do you have a such physical device (iPad Air 5th generation)? (Since the performance issue should be reproduced on profile/release mode and physical device)

Thanks for your response. But the performance issue should be reproducible in the physical device in profile mode with Skia tracing enabled (see https://github.com/flutter/flutter/issues/74833#issue-795394794 and https://github.com/flutter/flutter/issues/122807#issuecomment-1472451339) so that we may see slow frame/janks/etc and also investigate it better.
So I would suggest you keep an eye on the physical device and observe it to see if it can be reproducible. If you are unable to see it, feel free to close it and write a comment when you can reproduce it on such a device. Thanks!

It is broken in ios 16 (or mostly) but not lower versions.
related issue was filed on the HtmlWidget but later found to be an issue on flutter framework without the widget.
Sample app is there as well if needed but uses html widget
https://github.com/daohoangson/flutter_widget_from_html/issues/875

I was able to know that one iPad Air, 3 iOS version 6.2 was fine and did not reproduce this bug.
The person who had this working software without the bug rarely updates and might have been on a pre 3.7 build.  I'm not sure if this helps.

how can we re-open this issue and please give response as to what information you want.  Non of the devs have an Ipad.. but I can open a testing channel for someone out there to test.  Our app is not so very small.  We have 1,800 users on android alone.  We ship on MacOS and Windows and of course ios.  To make this work we disabled a major feature.  We have a vanilla app we can send you.  Would that be okay?  Then you the flutter devs can figure this out.  It is independent of outside widgets and fails on only 9 list items containing 1 page of text each.  It is not unreasonable to have each word as a gesture.


Update docs according to Inclusive Language guide

Removed STYLE.md (content moved to repo wiki)
Replaced "dummy" with "placeholder" (Exception: when referring to scripts)
Replaced "kill" with "end" or "stop" (Exceptions: commands and references to commands pkill or kill)
Replaced "native" with "built-in", "built for", or omitted

Closes #7720

FYI:

Reached out to the Marketing team to see if we can change "Cloud Native" on the website - we also have a "Cloud Native" in the top nav that was changed superficially but the URL still contains it.

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/27f809a4db2d2815c2b1b35acc7da6a06e64700b/
Edited pages:

CONTRIBUTING.md
archived/training/node-decommissioning.md
archived/training/orchestration-with-kubernetes.md
releases/beta-20160714.md
releases/beta-20160721.md
releases/beta-20170209.md
releases/beta-20170413.md
releases/v1.1-alpha.20170622.md
releases/v19.1.0-rc.2.md
releases/v20.1.0-beta.2.md
releases/v20.2.0-alpha.1.md
v1.0/demo-automatic-cloud-migration.md
v1.0/demo-automatic-rebalancing.md
v1.0/demo-data-replication.md
v1.0/demo-fault-tolerance-and-recovery.md
v1.0/deploy-a-test-cluster.md
v1.0/general-troubleshooting.md
v1.0/go-implementation.md
v1.0/orchestrate-cockroachdb-with-kubernetes.md
v1.0/recommended-production-settings.md
v1.0/secure-a-cluster.md
v1.0/start-a-local-cluster.md
v1.0/stop-a-node.md
v1.1/cluster-setup-troubleshooting.md
v1.1/common-errors.md
v1.1/create-a-file-server.md
v1.1/demo-automatic-cloud-migration.md
v1.1/demo-automatic-rebalancing.md
v1.1/demo-data-replication.md
v1.1/demo-fault-tolerance-and-recovery.md
v1.1/demo-follow-the-workload.md
v1.1/deploy-a-test-cluster.md
v1.1/go-implementation.md
v1.1/kubernetes-performance.md
v1.1/recommended-production-settings.md
v1.1/secure-a-cluster.md
v1.1/show-queries.md
v1.1/start-a-local-cluster.md
v1.1/stop-a-node.md
v19.1/cluster-setup-troubleshooting.md
v19.1/common-errors.md
v19.1/cost-based-optimizer.md
v19.1/create-a-file-server.md
v19.1/demo-automatic-cloud-migration.md
v19.1/demo-automatic-rebalancing.md
v19.1/demo-data-replication.md
v19.1/demo-fault-tolerance-and-recovery.md
v19.1/demo-follow-the-workload.md
v19.1/deploy-a-test-cluster.md
v19.1/gssapi_authentication.md
v19.1/kubernetes-performance.md
v19.1/recommended-production-settings.md
v19.1/remove-nodes.md
v19.1/secure-a-cluster.md
v19.1/show-experimental-ranges.md
v19.1/show-queries.md
v19.1/sql-audit-logging.md
v19.1/start-a-local-cluster.md
v19.1/stop-a-node.md
v19.2/cluster-setup-troubleshooting.md
v19.2/cockroach-quit.md
v19.2/cockroach-sql.md
v19.2/common-errors.md
v19.2/cost-based-optimizer.md
v19.2/create-a-file-server.md
v19.2/demo-automatic-cloud-migration.md
v19.2/deploy-a-test-cluster.md
v19.2/gssapi_authentication.md
v19.2/kubernetes-performance.md
v19.2/recommended-production-settings.md
v19.2/remove-nodes.md
v19.2/show-queries.md
v19.2/sql-audit-logging.md
v2.0/common-errors.md
v2.0/create-a-file-server.md
v2.0/demo-automatic-cloud-migration.md
v2.0/demo-automatic-rebalancing.md
v2.0/demo-data-replication.md
v2.0/demo-fault-tolerance-and-recovery.md
v2.0/demo-follow-the-workload.md
v2.0/deploy-a-test-cluster.md
v2.0/go-implementation.md
v2.0/kubernetes-performance.md
v2.0/recommended-production-settings.md
v2.0/secure-a-cluster.md
v2.0/show-experimental-ranges.md
v2.0/show-queries.md
v2.0/sql-audit-logging.md
v2.0/start-a-local-cluster.md
v2.0/stop-a-node.md
v2.1/common-errors.md
v2.1/create-a-file-server.md
v2.1/demo-automatic-cloud-migration.md
v2.1/demo-automatic-rebalancing.md
v2.1/demo-data-replication.md
v2.1/demo-fault-tolerance-and-recovery.md
v2.1/demo-follow-the-workload.md
v2.1/deploy-a-test-cluster.md
v2.1/go-implementation.md
v2.1/kubernetes-performance.md
v2.1/recommended-production-settings.md
v2.1/remove-nodes.md
v2.1/secure-a-cluster.md
v2.1/show-experimental-ranges.md
v2.1/show-queries.md
v2.1/sql-audit-logging.md
v2.1/start-a-local-cluster.md
v20.1/cluster-setup-troubleshooting.md
v20.1/cockroach-quit.md
v20.1/cockroach-sql.md
v20.1/common-errors.md
v20.1/cost-based-optimizer.md
v20.1/create-a-file-server.md
v20.1/demo-automatic-cloud-migration.md
v20.1/deploy-a-test-cluster.md
v20.1/gssapi_authentication.md
v20.1/kubernetes-performance.md
v20.1/recommended-production-settings.md
v20.1/remove-nodes.md
v20.1/show-queries.md
v20.1/sql-audit-logging.md
v20.2/cluster-setup-troubleshooting.md
v20.2/cockroach-quit.md
v20.2/cockroach-sql.md
v20.2/common-errors.md
v20.2/cost-based-optimizer.md
v20.2/create-a-file-server.md
v20.2/demo-automatic-cloud-migration.md
v20.2/deploy-a-test-cluster.md
v20.2/gssapi_authentication.md
v20.2/kubernetes-performance.md
v20.2/recommended-production-settings.md
v20.2/remove-nodes.md
v20.2/show-queries.md
v20.2/sql-audit-logging.md

This change is


bcp out -x is no working

When running bcp out -x on Linux container it is not working.
But bcp out -x is working on Windows (export xml format).
We are running vertion : bcp -v : 17.6.0001.1

-x also does not exist on 18.1.0001.1
usage: /opt/mssql-tools18/bin/bcp {dbtable | query} {in | out | queryout | format} datafile
  [-m maxerrors]            [-f formatfile]          [-e errfile]
  [-F firstrow]             [-L lastrow]             [-b batchsize]
  [-n native type]          [-c character type]      [-w wide character type]
  [-N keep non-text native] [-q quoted identifier]
  [-t field terminator]     [-r row terminator]
  [-a packetsize]           [-K application intent]
  [-S server name or DSN if -D provided]             [-D treat -S as DSN]
  [-U username]             [-P password or tokenfile]
  [-T trusted connection]   [-v version]             [-R regional enable]
  [-k keep null values]     [-E keep identity values][-G Azure Active Directory Authentication]
  [-h "load hints"]         [-d database name]
  [-Y encrypt option]       [-u trust server certificate]```


Add CollapsibleTableSectionViewController by @jeantimex to Table View / Collection View.

Project URL
https://github.com/jeantimex/CollapsibleTableSectionViewController
Description
Add CollapsibleTableSectionViewController by @jeantimex to Table View / Collection View.
Why it should be included to awesome-ios (optional)
This pod has been requested by many users from this repo: https://github.com/jeantimex/ios-swift-collapsible-table-section, and the usage of this pod is as easy as using a UITableViewController.
You can find the medium of the detail implementation here: https://medium.com/@jeantimex/how-to-implement-collapsible-table-section-in-ios-142e0c6266fd
Checklist

[x] Only one project/change is in this pull request
[x] Addition in chronological order (bottom of category)
[x] Supports iOS 9 / tvOS 10 or later
[x] Supports Swift 3 or later
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

Let me create a separate branch.


Update scripts

Remove old script
Update to ts some of them

What is the script you are refering to ?


provides recheck button on verification screen

After receiving verification, user can click the "check again" button to continue doing what they were doing instead of reloading the app.

We should add it to this screen too: https://github.com/lbryio/lbry-desktop/blob/master/src/ui/page/rewards/view.jsx#L57

Added Tom's change.
I find the bottom table jumping up on refresh jarring now, though.

@jessopb I'd be fine with that. I've noticed it can be a little jumpy so anything to improve that would be great


[BugFix] Fix be crash caused by uncaught future_error exception

Why I'm doing:
future_error exception is uncaught， which causes be crash, especially in shutting down
What I'm doing:
catch the future_error exception, protect be crash
Fixes https://github.com/StarRocks/StarRocksTest/issues/7898
What type of PR is this:

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

[ ] This is a backport pr

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[x] 3.3
[x] 3.2
[x] 3.1
[ ] 3.0
[ ] 2.5

Need a clear root cause analysis before making fix. The code change doesn't hurt anything, but it may conceal the real problem.

@kevincai When be shutting down,  the delete_file_thread_pool will shutdown, but some packaged_tasks in queue are cleaned up before they are executed. If a packaged_task destructed before it is executed, the corresponding future will throw  future_error exception in its get function. We can catch this  future_error exception to protect be from crash during be shutting down.


Can't log in: Communication with the service provider failed: PKIX path building failed

I go to http://maproulette.org, the greeter modal comes up, I click “Get Started”
The start page is shown. I click “Sign in” in the top right corner
I would expect to be taken to the OSM OAuth page. Instead an error message is displayed:

Communication with the service provider failed: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
This seems to be a backend error, because I see in the network tab in the developer tools that the first request to /auth/authenticate?redirect=/mr3/ directly results in a 308 redirect to /mr3/error?errormsg=Communication+with+the+service+provider+failed….
This happens in Firefox 61.0 and Chromium 67.0.3396.87 on Linux.
Other OAuth clients work for me, e.g. http://umap.openstreetmap.fr/

I encounter the same issue since yesterday on: Chromium 66.0.3359.181 and Firefox 61.0

Same here

I can reproduce this. Hang on while we look into it..Thanks for reporting!

This is resolved now. Please try again. If you see the same issue again, first try clearing your cookies and then logging in again. If it persists please reopen this bug so that we can look into it again.

I get a different error now.

I click 'sign in' (either on the comments section or top right corner)
It takes me to the OSM auth page where I then authorize access to my account.
It takes me back to the MapRoulette website with the Error message: "Please sign in to continue."

I cleared Cookies, Cache, Hard Reload, everything there is to clear. Using the latest Chrome version 67.0.3396.99 (Official Build) (64-bit)

http://maproulette.org/ works for me now, thanks!
The remaining problem can be discussed over at #313.


Fix semantics of get and set EnableSessionCreation

Per the javadocs for SSLEngine, setEnableSessionCreation controls
whether or not new sessions are allowed to be created, or whether this
SSLEngine is restricted to resuming existing sessions. The default is
true, i.e., allow new sessions to be created. Because the OpenSSL
SSLEngine implementation does not limit the creation of new sessions,
getEnableSessionCreation should always return true, not false, and the
set operation should only yield an exception when the parameter is
false.
Signed-off-by: Alexander Scheel<EMAIL_ADDRESS>
I haven't looked for any existing BZs discussing this topic; the code also appears unused within Tomcat so this is mostly an implementation nit. This could potentially break existing code (if someone was calling setEnableSessionCreation(false)) -- but if they were truly expecting Tomcat's OpenSSL implementation to not create a new session, they'd be in for a surprise. This'd hopefully help them to fix their code (or better -- provide a PR adding this functionality if they truly need it). :-)
I found this while working on JSS's SSLEngine and re-reading the semantics of both what Tomcat expects/does and what the javadocs say to do.
Note: I'm not sure how StringManager works -- do I have to provide translations for the exception for other languages now? Hopefully this exception is sufficiently clear in case anyone does stumble across it:

OpenSslEngine does not permit restricting the engine to only resuming existing sessions

LGTM. It is missing an entry in the change log. I'll add that.


Prefilled fields doesnt' emit events

General information

SDK version: 3.27.0, using hosted fields
Environment: Sandbox
Browser and OS: Windows 10. Chrome Versión 68.0.3440.106 (Build oficial) (64 bits)

Issue description
Prefilled fields seems to not emit events.
I need to prefill Expiration Month and Expiration Year to show Customer's credit card information. That information should be able to be changed in the future, so When the customer make any change I need to register this event. Strangely , these fields above are not capable of emitting any type of event when modified.
creditCardFormConfig() {
      return {
        fields: {
          number: {
            selector: '#card-number',
            placeholder: 'xxxx xxxx xxxx '.concat(this.last4),
          },
          cvv: {
            selector: '#cvv',
            placeholder: 'Never Stored',
          },
          expirationMonth: {
            selector: '#expiration-month',
            placeholder: 'Expiration month',
            select: {
              options: this.monthOptions,
            },
            prefill: '07',
          },
          expirationYear: {
            selector: '#expiration-year',
            placeholder: 'Expiration year',
            select: true,
            prefill: '2031',
          },
        },
      };
    }

I've edited your comment to make the code snippet easier to read.
Did a quick check, and I was getting events firing for all the fields with prefills in them. Can you provide your event handling logic?

Of course.
onValidityChange(event) {
      return Promise.resolve().then(() => {
        const isFormValid = Object.keys(event.fields).every(key => event.fields[key].isValid);

        if (isFormValid) {
          this.complete = true;
          this.isLoading = true;
          return this.createCreditCardToken()
            .then(creditCardToken => {
              this.isLoading = false;
              this.isValidToken = true;
              this.$emit('complete', creditCardToken);
            })
            .catch(err => {
              this.isValidToken = false;
              this.$emit('error', err);
            });
        } else {
          this.complete = false;
          this.isValidToken = false;
          this.$emit('invalid');
        }
      });
    },
createCreditCardToken() {
      return this.hostedFieldsInstance.tokenize();
    },

I accidentally closed it.
Here is the event handler.
onValidityChange(event) {
      return Promise.resolve().then(() => {
        const isFormValid = Object.keys(event.fields).every(key => event.fields[key].isValid);

        if (isFormValid) {
          this.complete = true;
          this.isLoading = true;
          return this.createCreditCardToken()
            .then(creditCardToken => {
              this.isLoading = false;
              this.isValidToken = true;
              this.$emit('complete', creditCardToken);
            })
            .catch(err => {
              this.isValidToken = false;
              this.$emit('error', err);
            });
        } else {
          this.complete = false;
          this.isValidToken = false;
          this.$emit('invalid');
        }
      });
    },
createCreditCardToken() {
      console.log('++++++++++++++');
      return this.hostedFieldsInstance.tokenize();
    },

Without the prefilled info the fields works fine and emit events.

Is the same true for the number and cvv fields?

Strangely enough, when I prefill number and cvv fields and then I change both values an event is emitted. So number and cvv works fine. Still having issues with month and year...

Text input prefilled fields working fine!! The issue is with prefilled select fields.

@manujimenez23 I wasn't able to reproduce the issue on v3.36.0. Can you confirm that you are changing the selects either from a valid -> invalid state or invalid -> valid state?
For instance, if you pre-fill the selects with month = 11 and year = 2018, changing the month to 12 or the year to anything higher will not trigger the validity change event, since it went from a valid -> valid state. If you'd change the month to 5, that'd make the computed date 5/2018, which would be going from valid -> invalid and an event should fire. (and it does in my test)

@manujimenez23 I haven't heard back from you, so I'm assuming everything is working. Going to close this now, but comment here if you still need assistance.


Fix indention due to closing brackets

Thanks! I can't believe I missed this!

Fixed. I also added you to the AUTHORS file (which I just added).


Standalone-indexer: cold start / recover from arweave

Motivations

Would you like to implement this feature? [y/n]

Solution

Alternatives

Additional context

@jingchen2222  I need you to continue this issue

Todo

[ ] persist indexer status (BlockState(block, order, entry_id))
[ ] fetch and uncompress block from arweave
[ ] apply mutation


Please consider making non-npm dependent standalone releases of redux and react bindings available

Given the recent left-pad controversy showcasing weaknesses on npm and the arbitrary code execution vurnerebility that was marked as won't fix by npm, could you please consider making a usable static usable version of redux and react binfings for redux available without npm dependencies for safety?
Today, react can be already used without npm but I have struggled to make redux work with react without npm.

Redux and react-redux already provides a UMD build. For their READMEs:

If you don’t yet use npm or a modern module bundler, and would rather prefer a single-file UMD build that makes Redux available as a global object, you can grab a pre-built version from cdnjs.

redux)
react-redux
If you're having issues you may want to try StackOverflow or Discord :+1:

Thanks! I found I was able to make the redux UMD work for me by manually managing subscriptions. Haven't tried react-redux yet though.


Geobuf format and streaming writes

/cc @mourner @springmeyer @artemp
The problem
The geobuf format as it is currently defined can't be written in a stream. Instead, the whole data has to be assembled in memory first and then written out. This directly follows from the way Protobuf encodes its messages. A good description of the problem can be found in the header comments of the protobuf writer of the UPB library. In short the problem is that Protobuf uses nested messages to encode the data and each message has a length header which is encoded as a Varint. But we can't write out the length (or even know how long the length field is, because a Varint is of variable length) before we have the whole message assembled.
This is, of course, a major problem for a format that is intended for huge files.
A possible solution: Remove outermost message
Because this is an inherent limitation of the Protobuf format we have to look outside the format for a solution. Of course we could throw away the whole Protobuf format, but thats not needed. Whats needed is a wrapper around it so that the Protobuf encoder/decoder only sees part of the data. In the simplest case we encode the data in pieces:
We remove the outermost message Data and then write each of the other data pieces on their own as their own protobuf message. We might want to move the keys, dimensions, and precision into a message Header or so. The oneof data_type construct doesn't work any more, instead we just have to keep reading messages until EOF. But we don't know which kind of messages will be in there (Feature, FeatureCollection, etc.) so we have to add this information to the newly introduced message Header in some way and then parse accordingly. This should certainly be doable and doesn't require a lot of change. But I think there is...
A better solution: Chunking the data
This looks slightly more complicated in the beginning but has many advantages, so bear with me. Lets encode the data in chunks, each chunk gets a length field and the data:
CHUNK
    LENGTH (4 bytes)
    DATA (LENGTH bytes)
CHUNK
    LENGTH (4 bytes)
    DATA (LENGTH bytes)
...

Each DATA block is a complete Protobuf message which can be parsed on its own. This idea is, of course, not new. It is what the OpenStreetMap OSM PBF is doing.
A typical DATA field will contain maybe a few thousand geometries or features. Note that this does not mean that the contents of the different chunks are somehow logically distinct. Logically this is still one data stream. The chunking is purely an encoding issue and files with the same data split up into different sized chunks would still represent the same data.
This format some added advantages:

the LENGTH field can tell us how much memory to allocate for buffering the DATA part
reading and writing can be done in parallel, because several threads can work on encoding/decoding different chunks at the same time. In fact thats what Libosmium does when parsing OSM PBF.
concatenating two files is trivial: deal with the headers, then just copy data chunks

Now it gets a little bit more complicated than that. (This is again based on experience with the OSM PBF format.) The first chunk should probably contain some kind of header. This could include metadata such as the dimensions setting and the keys. All other chunks contains the data itself. So chunks (OSM PBF calls them Blobs) need to contain some kind of type identifier to differentiate between a header chunk and a data chunk. OSM PBF does this by adding another level of Protobuf encoding (See BlobHeader and Blob messages) which seems like overkill to me. It makes the implementation rather confusing and probably slower. Instead we can just add a type field:
CHUNK
    HEADER (fixed size)
        TYPE (1 byte, first chunk always =META)
        LENGTH (4 bytes)
    DATA (LENGTH bytes)
CHUNK
    HEADER (fixed size)
        TYPE (1 byte, following chunks always =GEOMDATA)
        LENGTH (4 bytes)
    DATA (LENGTH bytes)
...

Strictly speaking we can live without that TYPE field, because the header always has to be the first chunk and following chunks data, but it seems cleaner and allows us more flexibility if we have this type. And maybe we want to have different types of data? This is something which has to be explored.
OSM PBF adds another useful functionality: Encoding chunks (or Blobs) with zlib or other compression formats. Each chunk can be optionally compressed and the type of compression is noted in the chunk header. This can squeeze out the last bytes from the resulting files, but it is still possible to encode and decode the file in chunks and in parallel. To add this we need, again, some type field. And we should also store the size of the uncompressed data, because it allows us to give the decompressor a buffer with the correct size.
Note that I have used 4 byte length fields in my description. This is probably enough for each chunk, in fact chunks should not get too big, because each one has to fit into memory after all (several is we encode/decode in parallel). OSM PBF has some extra constraints on sizes of different structures which can help with implementations because fixed-sized buffers can be used.
Note also that there is no overall length field for the whole file. Thats important, because it allows use to streaming write the data without knowing beforehand how many features the file will contain or how big it will be. (We might want to end the file with some END chunk that marks the end of file to guard against truncation. Optionally it could contain a checksum. This is something that OSM PBF is missing, but could be useful to detect data corruption.)
And while we are at it, I suggest adding a fixed 4-byte (or so) magic header that is always the same but can be used by tools such as find to determine the file size easily and a fixed-size version field for future-proofing the format.
This brings us to something like this:
MAGIC (fixed size)
VERSION (=1, fixed size)
CHUNK
    HEADER (fixed size)
        TYPE (1 byte, first chunk always =META)
        COMPRESSION_TYPE (1 byte)
        RAW_LENGTH (4 bytes)
        ENCODED_LENGTH (4 bytes)
    DATA (LENGTH bytes)
CHUNK
    HEADER (fixed size)
        TYPE (1 byte, first chunk always =GEOMDATA)
        COMPRESSION_TYPE (1 byte)
        RAW_LENGTH (4 bytes)
        ENCODED_LENGTH (4 bytes)
    DATA (LENGTH bytes)
...
CHUNK
    HEADER (fixed size)
        TYPE (1 byte, last chunk always =END)
        COMPRESSION_TYPE (1 byte)
        RAW_LENGTH (4 bytes)
        ENCODED_LENGTH (4 bytes)
    DATA (LENGTH bytes)
        CHECKSUM

Some padding might be necessary to have length fields on 4-byte boundaries etc. And all length fields should probably be encoded in network byte order. Those details can be worked out.
Inside the DATA we'd still use the Protobuf-encoded data (nearly) as before. No big change there. For some things such as the keys we have to discuss whether they fit better in the META header or the DATA part. In the META and END blocks we can use Protobuf, too, or any other encoding. Because thats not a lot of data it isn't that important that we pack it so tightly and using a simpler format might allow simpler access to the metadata. On the other hand Protobuf is tried and true and allows for easy extensibility.

:+1: awesome, thanks for writing this out

Wow, that's a lot of information to process. Thanks for the detailed write-up, I'll follow up with comments.

@joto Chunking, yes... I've been thinking about this in the context of GeoJSON: https://github.com/geojson/geojson-feature-sequences. Might be useful for geobuf, yes.

Thought about this for a while... Before we decide whether to chunk or not to chunk, there's another problem to solve.
One of the Geobuf requirements is lossless GeoJSON compression, meaning that Geobuf should retain the full structure of the original file to be able to recreate it. So we can't limit Geobuf to a particular sequence of data types.
GeoJSON is arbitrarily nested — FeatureCollection can contain a Feature which contains GeometryCollection which contains other geometries, some of them might be GeometryCollections as well etc. It's a big problem for streamable writing if we encode nesting by means of embedded messages. So there's an obvious alternative — completely flatten the structure, encoding things sequentially, and add additional fields that we can use to recreate the tree. Several ways we could do that:

Autogenerate internal ids for each "parent" object and then reference the ids from children.
Reference parents by index each parent is encoded in the message (e.g. obj1,obj2,obj2_child would have parent field 1, referring to obj2).
For each parent object, indicate how many children follow in the encoded message.
Your idea.

Thoughts?

Anyone? @joto @tmcw @artemp @sgillies @brendan-ward

@mourner first off, my bias: I was hoping to use geobuf as a transport and possibly storage format for smallish (maybe a few hundred MB or less) simple features (no arbitrary nesting).  These would all be coming from other GIS formats with much flatter data structures.  I wasn't thinking of the chunked streaming case as well described by @joto since I was thinking we'd subdivide data across geobufs as needed, and deal with associations between them out-of-band.  The solution proposed by @joto looks like this would allow geobuf to go MUCH bigger, without too much overhead for the case of small features (depending on chunk size), so I'm not at all opposed if it can be done without losing too much of the existing compression benefits of geobuf or adding significantly to the implementation complexity.
Some things to consider:

lossless does not have to mean support for all possible variants of GeoJSON; it should mean that for whatever variants are supported, no information / precision should be lost along the way, and unsupported variants rejected outright.  At present, I don't think it would be unreasonable to limit geobuf to a well-stated level of collections within collections (e.g., 1-2 levels deep), and stop at that.  But I'm biased.

How would you allow child collections to be split across chunks?  If you don't allow them to split, then this may make the chunks arbitrarily big; if you do split them, you have to retain additional information about prior chunks as you are stream processing each new chunk (to look back and find the parents).  I think your 1-2 could work in this case, but may require indexing a lookup to the parents or keeping them entirely in memory.  This problem becomes much easier if each chunk is self-contained and doesn't need to traverse cross-references to other chunks.

there may be some ideas lurking in Google's Dremel approach (summarized here) that may be useful here with respect to nested data structure issues.

with respect to chunking, the terminating chunk can possibly be simplified down to an empty message, similar to HTTP chunked encoding

@sgillies how are you planning to handle arbitrary nesting of collections in GeoJSON feature sequences?

I don't think this arbitrary nesting is that useful in practice. Can you cite any examples where this is used in some real-world application? Because I can't see how this rather complex format will actually be used productively, I can't really see how best to implement it (and whether it is actually worth implementing).
Here is another way of seeing this: GeoJSON could have been written as two standards: One that describes how to encode Simple Feature Geometries in JSON, the other how to assemble those geometries plus extra information into higher level structures. The first part is useful without the second and is the base for the second at the same time. GeoJSON didn't do it that way, but maybe we could.
We could have one standard that describes how to efficiently code Simple Feature Geometries and then (possibly multiple) further "standards" that describe how this can be used to describe larger structures. This way we can standardize now what we actually need for our own uses and later have further standards if the need arises. Those family of standards would allow some code reuse but at the same time not burdon us now with a complexity we are not sure we'd really need.

@brendan-ward the only thing I am sure about with respect to arbitrary nesting of geometry collections is that serializing nested geometry collections and serving them to users shows an indifference to other developers verging on malice. Multi-linestrings and multi-polygons are useful in our models so that we can do antimeridian cutting of geometries in geographic coordinates while continue to attest that there is a single geometric object. Generalized geometry collections exist in GeoJSON because they existed in OGC simple features, and they exist in the OGC standard because it was written by people who crave complexity and can't say "no." I think geobuf can say no to data like
{ "geometry":
  { "type": "GeometryCollection",
    "geometries": [
       { "type": "GeometryCollection",
         "geometries": [
           { "type": "Point", "coordinates": [0, 0] }
         ] } ] } }

if we want.

Revisiting the issue again. Some points:

Agreed with @brendan-ward and @sgillies that we don't have to support unlimited level of nesting — we can say no to anything below 1-2 levels. However my feeling is that if we do implement 1-2 levels nesting with a flat structure and reference fields, the implementation will be inductive in the sense that if 1-2 levels work, more levels will work with the same approach, so limitation would be artificial, not technical.
I'm not in favor of chunking because for if we want to win with Geobuf, we need to put our stakes on simplicity. Chunking creates complexity that I'd like to avoid. If we can support easy streaming reads/writes by just flattening the structure and avoiding deeply nested messages, I'd go for that instead because it's much simpler.
Even if we limit nesting to 1-2 levels, we still need to decide about technical approach to implementing flattened encoding of features. So my comment https://github.com/mapbox/geobuf/issues/37#issuecomment-86965846 remains relevant still needs feedback.

@mourner from a purely streaming perspective, I think your option 2 wins for simplicity, so long as one tracks the current state while parsing from geobuf and builds an index of features by order in the buffer; then looking back to the parent is easy, and doesn't require extra storage in the parent to accomplish this like in option 1.
Perhaps an even easier way to approach this when the tree is encoded depth first is simply to use the state of a variable (let's call it parent) with one of 3 states to indicate nesting level (absent means no parent, switch between 0 and 1 for each level).  Each new value of 0 or 1 indicates it is the first child and previous node is the parent.  Take this example, with more nesting than I like:
   A        G
  / \         \
 B    C         H
     / \
   D    E
         \
          F

Could be encoded as:
A:   (parent is absent)
B:  parent: 0      (this means look back at previous node, which is parent)
C:  parent: 0
D:  parent:1   (since this is not 0, this means it is not a continuation of children under the first, and thus points at the previous node as its parent)
E:  parent:1
F: parent:0  (since this is not 1, this means previous node is parent)
G:    (parent is absent)
H: parent:0
So, nesting could be accomplished with a single optional bool rather  than a uint.

@brendan-ward nice approach, but considering that boolean takes the same amount of bytes as small varint, I'd go with something more explicit.

@mourner explicit is almost always better.  I thought we were trying to cover streaming issues for large datasets, so I figured that a boolean would end up being smaller in the buffer in the long run.  But as a total percentage of the overall buffer size, either is likely to be tiny so this is sort of irrelevant.  Depends a lot of the number of features and ratios of parents to children.
Were you thinking of storing an index of features by order in buffer during parsing, then looking back into that to retrieve parents?  That was the issue I was struggling with and tried to deal with during the above approach; if you encode depth first, then you only ever need to look back at the previous node or parent - though recursion is involved...  I was thinking it would lend itself to emitting the stream of data from the buffer as well, so that you don't have to hold onto things in memory beyond the previous node or parent until you start recursing.  When encountering G in the example above, because there is no parent, then the entire set of A-F could be written to the output stream at that point.
But - I'm not the one to argue for complexity when simple & explicit will get it done.

@brendan-ward I think we can have the same wins with a more explicit encoding of nesting. Instead of recursion, we can just keep a stack of parents, which would always be tiny since there are no more than 1-2 levels of nesting, and we wouldn't have to store all nesting fields in memory. When we encounter a feature that has a different parent reference than the last one in the stack, we pop the stack and can output the corresponding object to the stream.

@brendan-ward attempting to implement a proof of concept now, and came up with a much simpler approach. Basically, we assume two limitations:

geometry collections can't contain other geometry collections (because wtf)
objects are encoded in the same order they flow in GeoJSON

Then we can derive the structure by just keeping 3 references — last parsed feature collection, feature and geometry. Then e.g. if we parse a feature, then our last parsed feature collection will be the parent if it's present. If we parse a geometry, then the parent is either last parsed geometry collection or last parsed feature. We solve the ambiguity by resetting the geometry collection reference when a feature is encountered. It may sound a bit confusing, but it should be really easy to implement, and more importantly the performance will be stellar — no need to keep stacks, etc.

@mourner sounds very reasonable to me!  :+1:

A work in progress happening in #51. I think the new schema is pretty cool — it's much simpler than what we had before while having the same compression. After the revision is done, I'll make a separate repo geobuf-stream for a streaming implementation

Hey there,
Almost 2 years later, is there any workaround / temparary solution to use geobuf as a stream right now ? Even a beta implementation that I can test ? I was hoping than this issue was "forgotten" and adressed by an implementation somewhere, but I coun't find it so just asking :D

@cyrilchapon for now, a good workaround is to simply encode each feature separately and then do a length-prefixed stream, e.g. with https://github.com/mafintosh/length-prefixed-stream

Hum, sound promising, but way above my skills.
I'm trying to find an alternative to a dynamic, massive, GeoJSON download.
I'm currently streaming from database and piping to an http response like this :
      let geojsonStream = jsonStream.stringify(
        '{"type":"FeatureCollection","features":[',
        req.app.get('json spaces') ? '\n,\n' : ',',
        ']}',
        req.app.get('json spaces')
      );

      //then later
      coordinatesDatabaseStream
      .pipe(coordinateToFeature)
      .pipe(geojsonStream)
      .pipe(res);

I had in mind that I could just trade my GeoJSON encoding (through json-stream) with a protobuff-write stream (geobuf style), and just pipe that stream to my response
      coordinatesDatabaseStream
      .pipe(coordinateToFeature)
      .pipe(geobuf.encodeAsStream)//<- the part I'm asking here
      .pipe(res);

Any chance you could provide an example, or an idea how to implement what you were suggesting, for this use-case ?

I'm coming to this extremely late, but a couple of comments:
Don't support nested geometries
@mourner wrote:

GeoJSON is arbitrarily nested — FeatureCollection can contain a Feature which contains GeometryCollection which contains other geometries, some of them might be GeometryCollections as well etc.

This is not exactly true. The specification actually says:

To maximize interoperability, implementations SHOULD avoid nested GeometryCollections. Furthermore, GeometryCollections composed of a single part or a number of parts of a single type SHOULD be avoided when that single part or a single object of multipart type (MultiPoint, MultiLineString, or MultiPolygon) could be used instead.

Furthermore, a FeatureCollection can't contain other FeatureCollections.
(Feature "properties" objects themselves can be arbitrarily nested, I guess, but I don't think that causes a problem here?)
So it's entirely reasonable for the Geobuf format to avoid arbitrarily nested geometries files, which probably never occur in reality. (I'm not sure I've ever seen even a single GeometryCollection, let alone a nested one).
Consider a geobuf equivalent to newline-delimited GeoJSON?
I'm a bit in love with newline-delimited GeoJSON, which basically removes the outer FeatureCollection layer, and puts one feature per line. Perhaps there's a GeoBuf equivalent, as hinted above (removing the outer Data layer, although possibly requiring some new header).
(Hmm, I just realised there is https://github.com/mapbox/geobuf/pull/51 so all of this is probably very redundant now anyway :))


fix health indicator state transition

refer to the same state

Pull Request Test Coverage Report for Build 34

5 of 7 (71.43%) changed or added relevant lines in 5 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.3%) to 71.569%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

reader/src/main/java/com/mercateo/eventstore/reader/EventSubscriptionHealthIndicator.java
0
2
0.0%

Totals

Change from base Build 31:
0.3%

Covered Lines:
365

Relevant Lines:
510

💛  - Coveralls


External Auth Login with IPA always fails

After configuring External Auth to IPA, logging in with IPA credentials always gives us IPA Authentication Error.
Tracing this down, we see that config[:mode] in authenticator.rb returns "database" instead of httpd so it's authenticating with the wrong subclass.
@jvlcek @gtanzillo

The issue is that the config sent down to the authenticator was not seeing the config mode.
following code change in app/models/user.rb fixes this (note reload! was necessary).
def self.authenticator(username = nil)
-    Authenticator.for(VMDB::Config.new("vmdb").config[:authentication], username)
+    Authenticator.for(Settings.reload!.authentication, username)
end

@Fryguy I'm not sure why I needed the reload! above for this to work.  Thoughts ?

@Fryguy The only thing that pops into my mind is the UI saves the setting on 3000, but the WS worker on 4000 doesn't see it unless a reload is done. but I may be wrong.

it should not be needed...in fact, no one should ever have to call that
Are you changing a remote server's configuration or the local server's configuration?

local server, i.e. Configure->Configuration->Authentication->Mode changed to External (httpd).

I sat with @abellotti and we realized that the current code for "poking" a server will not poke other workers within the same server.  That is, if a UI worker and a WebService worker are on the same server, then a change in the UI will update the UI worker, but the WebServiceWorker will not see the poke to update the configuration.
The fix is to poke the local server regardless, but I have to make sure we don't infinite loop

This might be related to #7585

I need to fix #7585 first because I can't tell if the changes I made even work :sweat_smile:


MINOR:Add hint for resumeDeletions in TopicDeletionManager

The resumeDeletions method is called from multiple places and is the core logic responsible for executing the deletion. Therefore, adding comments to indicate where this method is being called can help better understand this part of the logic.
The isTopicDeletionInProgress method has the same name and parameters in both TopicDeletionManager and ControllerContext, but the meanings they express are entirely different. In the context of TopicDeletionManager, this method accurately indicates whether any replicas of the corresponding topic are currently in the process of being deleted on the broker. Topics in this state are not eligible for further deletion logic. On the other hand, in ControllerContext, the method simply indicates whether the topic has begun the deletion process, regardless of whether it is in the pre-deletion, mid-deletion, or post-deletion state on the broker. Therefore, the meanings and roles of the two methods are completely different, and having the same name can cause confusion when reading the code. To address this issue, it is recommended to rename the isTopicDeletionInProgress method in one or both classes to more accurately reflect their respective meanings. For example, in TopicDeletionManager, the method could be renamed to isTopicReplicaDeletionInProgress to emphasize that it checks for replicas of the topic that are currently being deleted. And in ControllerContext, the method isTopicDeletionInProgress could clarify that it only checks if the deletion process has begun for the topic. By doing so, code readability and maintainability will be improved, and confusion will be reduced.

Hi, @jlprat , could you help to review this pr?


Remove Typescript definitions from project

What does this PR do?
Removes Typescript from the repo and mentions usage of https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/react-native-snap-carousel

Thanks @radko!


Version 1.21 incompatible with Fabric 1.21.1

Fabric doesn’t let me run the 1.21 version on 1.21.1.

Duplicate of #35


update monaco-editor to 0.20.0

Update monaco-editor and its webpack plugin to the latest versions. Note there are some breaking changes; mostly options removed (see https://github.com/microsoft/monaco-editor/blob/master/CHANGELOG.md )
Tested the example; seems to work 👌

Netlify is failing because of "System error"?
https://app.netlify.com/sites/vue-monaco/deploys/5e65617d4ce0ef0008e74e46
5:19:57 PM: Build ready to start
5:21:00 PM: System Error

Going to try closing an opening a new PR? Maybe that will unbreak netlify.


Bebop shows "0" gas estimate

When integrating with Your SDK, we've noticed that some routes have a zero gasEstimate (and gasCostUSD). I think I've narrowed it down to bebop.
If the gasEstimate could not be calculated for whatever reason, I think it would be cleaner to not include that field. Example of such;
{
    "id": "b0871e90-4f66-4171-8589-feab40919212",
    "fromChainId": 1,
    "fromAmountUSD": "0.8804",
    "fromAmount": "225000000000000",
    "fromToken": {
        "address": "0x0000000000000000000000000000000000000000",
        "chainId": 1,
        "symbol": "ETH",
        "decimals": 18,
        "name": "ETH",
        "coinKey": "ETH",
        "logoURI": "https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/ethereum/assets/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2/logo.png",
        "priceUSD": "3912.79"
    },
    "fromAddress": "[REDACTED]",
    "toChainId": 1,
    "toAmountUSD": "0.8746",
    "toAmount": "874663",
    "toAmountMin": "874663",
    "toToken": {
        "address": "0xdAC17F958D2ee523a2206206994597C13D831ec7",
        "chainId": 1,
        "symbol": "USDT",
        "decimals": 6,
        "name": "USDT",
        "coinKey": "USDT",
        "logoURI": "https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/ethereum/assets/0xdAC17F958D2ee523a2206206994597C13D831ec7/logo.png",
        "priceUSD": "0.99998"
    },
    "toAddress": "[REDACTED]",
    "gasCostUSD": "0.0000",
    "containsSwitchChain": false,
    "steps": [
        {
            "type": "lifi",
            "id": "b0871e90-4f66-4171-8589-feab40919212:0",
            "tool": "bebop",
            "toolDetails": {
                "key": "bebop",
                "name": "Bebop",
                "logoURI": "https://raw.githubusercontent.com/lifinance/types/main/src/assets/icons/exchanges/bebop.svg"
            },
            "action": {
                "fromToken": {
                    "address": "0x0000000000000000000000000000000000000000",
                    "chainId": 1,
                    "symbol": "ETH",
                    "decimals": 18,
                    "name": "ETH",
                    "coinKey": "ETH",
                    "logoURI": "https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/ethereum/assets/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2/logo.png",
                    "priceUSD": "3912.79"
                },
                "fromAmount": "225000000000000",
                "toToken": {
                    "address": "0xdAC17F958D2ee523a2206206994597C13D831ec7",
                    "chainId": 1,
                    "symbol": "USDT",
                    "decimals": 6,
                    "name": "USDT",
                    "coinKey": "USDT",
                    "logoURI": "https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/ethereum/assets/0xdAC17F958D2ee523a2206206994597C13D831ec7/logo.png",
                    "priceUSD": "0.99998"
                },
                "fromChainId": 1,
                "toChainId": 1,
                "slippage": 0.005,
                "fromAddress": "[REDACTED]",
                "toAddress": "[REDACTED]"
            },
            "estimate": {
                "tool": "bebop",
                "approvalAddress": "0x1231DEB6f5749EF6cE6943a275A1D3E7486F4EaE",
                "toAmountMin": "874663",
                "toAmount": "874663",
                "fromAmount": "225000000000000",
                "feeCosts": [],
                "gasCosts": [
                    {
                        "type": "SEND",
                        "price": "10284487980",
                        "estimate": "0",
                        "limit": "243000",
                        "amount": "0",
                        "amountUSD": "0.0000",
                        "token": {
                            "address": "0x0000000000000000000000000000000000000000",
                            "chainId": 1,
                            "symbol": "ETH",
                            "decimals": 18,
                            "name": "ETH",
                            "coinKey": "ETH",
                            "logoURI": "https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/ethereum/assets/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2/logo.png",
                            "priceUSD": "3912.79"
                        }
                    }
                ],
                "executionDuration": 30,
                "fromAmountUSD": "0.8804",
                "toAmountUSD": "0.8746"
            },
            "includedSteps": [
                {
                    "id": "82fbe963-7d60-406e-8900-31e278a55f85",
                    "type": "swap",
                    "action": {
                        "fromChainId": 1,
                        "fromAmount": "225000000000000",
                        "fromToken": {
                            "address": "0x0000000000000000000000000000000000000000",
                            "chainId": 1,
                            "symbol": "ETH",
                            "decimals": 18,
                            "name": "ETH",
                            "coinKey": "ETH",
                            "logoURI": "https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/ethereum/assets/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2/logo.png",
                            "priceUSD": "3912.79"
                        },
                        "toChainId": 1,
                        "toToken": {
                            "address": "0xdAC17F958D2ee523a2206206994597C13D831ec7",
                            "chainId": 1,
                            "symbol": "USDT",
                            "decimals": 6,
                            "name": "USDT",
                            "coinKey": "USDT",
                            "logoURI": "https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/ethereum/assets/0xdAC17F958D2ee523a2206206994597C13D831ec7/logo.png",
                            "priceUSD": "0.99998"
                        },
                        "slippage": 0.005,
                        "fromAddress": "[REDACTED]"
                    },
                    "estimate": {
                        "tool": "bebop",
                        "fromAmount": "225000000000000",
                        "toAmount": "874663",
                        "toAmountMin": "874663",
                        "approvalAddress": "0xbbbbbBB520d69a9775E85b458C58c648259FAD5F",
                        "executionDuration": 30,
                        "feeCosts": [],
                        "gasCosts": [
                            {
                                "type": "SEND",
                                "price": "10284487980",
                                "estimate": "0",
                                "limit": "0",
                                "amount": "0",
                                "amountUSD": "0.0000",
                                "token": {
                                    "address": "0x0000000000000000000000000000000000000000",
                                    "chainId": 1,
                                    "symbol": "ETH",
                                    "decimals": 18,
                                    "name": "ETH",
                                    "coinKey": "ETH",
                                    "logoURI": "https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/ethereum/assets/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2/logo.png",
                                    "priceUSD": "3912.79"
                                }
                            }
                        ]
                    },
                    "tool": "bebop",
                    "toolDetails": {
                        "key": "bebop",
                        "name": "Bebop",
                        "logoURI": "https://raw.githubusercontent.com/lifinance/types/main/src/assets/icons/exchanges/bebop.svg"
                    }
                }
            ],
            "integrator": "goodwallet"
        }
    ],
    "tags": [
        "RECOMMENDED",
        "CHEAPEST",
        "FASTEST"
    ]
}

@SMLaursen hey, thank you! I'll forward this to our BE team 🙂

Hey, it should be fixed on production. Thank you 🙂


Add custom operator code generator script

This script uses jinja2 templates to generate the following:

C++ Header file that defines the operator class, templated on Device.
C++ Header file that defines the CPU implementation of the operator.
C++ Source file with Shape Function, REGISTER_OP and  REGISTER_KERNEL_BUILDER constructs.
Cuda Header that defines the GPU implementation of the operator,  including a CUDA kernel.
Cuda Source file with GPU REGISTER_KERNEL_BUILDER's for the operator.
python unit test case, which constructs random input data, and calls   the operator.
Makefile for compiling the operator into a shared library, using g++   and nvcc.

Operator inputs, outputs, polymorphic type attributes, other attributes and documentation can be specified.

Can one of the admins verify this patch?

I felt the content in the README.md was too large to be included in the Adding a New op howto, but it may be appropriate to add a link to this tool in that file.

I signed it!

Thanks! While it's nice, it'll take some effort to keep this in sync. I would suggest trying for contrib instead.

Indeed, this is cool, but probably would be better as an external repo for now. GitHub doesn't provide great community tools for managing and supporting external code that isn't core to the codebase.  Can this love on your own repo on GitHub for now?

Apologies for not getting back sooner -- other commitments required my attention
I've packaged this up at https://github.com/sjperkins/tfopgen.
Its also available on pypi -- pip install tfopgen


[BUG]

Describe the bug
New errors when switching to new Flutter 2.10 and using photo_manager 1.3.10.
App does not install on iOS anymore since switching to Flutter 2.10:
/dev/flutter/SDK/.pub-cache/hosted/pub.dartlang.org/photo_manager-1.3.10/ios/Classes/PMPlugin.m:63:43: warning: cast to smaller integer type 'BOOL' (aka 'signed char') from 'id _Nullable'
[-Wpointer-to-int-cast]
        PMLogUtils.sharedInstance.isLog = (BOOL) call.arguments;
                                          ^~~~~~~~~~~~~~~~~~~~~

/dev/flutter/SDK/.pub-cache/hosted/pub.dartlang.org/photo_manager-1.3.10/ios/Classes/core/PMManager.m:114:84: warning: values of type 'NSUInteger' should not be used as format arguments; add
an explicit cast to 'unsigned long' instead [-Wformat]
            NSLog(@"collection name = %@, count = %ld", collection.localizedTitle, result.count);
                                                  ~~~                              ^~~~~~~~~~~~
                                                  %lu                              (unsigned long)

/dev/flutter/SDK/.pub-cache/hosted/pub.dartlang.org/photo_manager-1.3.10/ios/Classes/core/PMManager.m:873:122: warning: values of type 'NSUInteger' should not be used as format arguments; add
an explicit cast to 'unsigned long' instead [-Wformat]
    [PMLogUtils.sharedInstance info:[NSString stringWithFormat:@"save image with data, length: %ld, title:%@, desc: %@", data.length, title, desc]];
                                                                                ~~~                       ^~~~~~~~~~~
                                                                                %lu                       (unsigned long)

To Reproduce
Switch an existing project to Flutter 2.10 and try to compile it for iOS.
Expected behavior
No error messages and successful compile as under Flutter 2.8.
Flutter version

flutter doctor -v
[✓] Flutter (Channel stable, 2.10.0, on macOS 12.2 21D49 darwin-arm, locale en-US)
• Flutter version 2.10.0 at /Users/yyy/dev/flutter/SDK
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision 5f105a6ca7 (2 days ago), 2022-02-01 14:15:42 -0800
• Engine revision 776efd2034
• Dart version 2.16.0
• DevTools version 2.9.2

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
• Android SDK at /Users/yyy/Library/Android/sdk
• Platform android-31, build-tools 31.0.0
• Java binary at: /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 11.0.11+0-b60-7772763)
• All Android licenses accepted.
[✓] Xcode - develop for iOS and macOS (Xcode 13.2.1)
• Xcode at /Applications/Xcode.app/Contents/Developer
• CocoaPods version 1.11.2
[✓] Chrome - develop for the web
• Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
[✓] Android Studio (version 2021.1)
• Android Studio at /Applications/Android Studio.app/Contents
• Flutter plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 11.0.11+0-b60-7772763)
[✓] VS Code (version 1.63.2)
• VS Code at /Applications/Visual Studio Code.app/Contents
• Flutter extension can be installed from:
🔨 https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter
[✓] Connected device (3 available)
• cpgPhone11 (mobile) • 00008030-000E0CEA36C0802E • ios            • iOS 15.3 19D50
• macOS (desktop)     • macos                     • darwin-arm64   • macOS 12.2 21D49 darwin-arm
• Chrome (web)        • chrome                    • web-javascript • Google Chrome 97.0.4692.99
[✓] HTTP Host Availability
• All required HTTP hosts are available
• No issues found!
Smartphone (please complete the following information):

Device: iPhone 11, iOS 15.3
OS: MacOS Monterrey 12.2
Browser: n/a
Version: n/a

I got it running now with version 2.0.0-dev.6 ...

These are warnings.


pull request for e2e test at 01/12/2017 03:56:11

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Test Build failed for "sh: 1: Cannot fork "

Suspect it's a jenkins setting up or master-slave network issue. Details:
https://github.com/AdoptOpenJDK/openjdk-tests/issues/274

Could anyone label this as urgent, which make build fail and exit?

Happened again:
https://ci.adoptopenjdk.net/view/OpenJDK tests/job/openjdk8_hs_openjdktest_x86-64_linux/39/console

Both test machines were configured with two executors - have dropped this to one as it could be purely down to overloading the machines - the CPU load was sitting around 14 on the scaleway box.
Machines changed:

https://ci.adoptopenjdk.net/computer/test-scaleway-ubuntu1604-x64-1/
https://ci.adoptopenjdk.net/computer/test-packet-ubuntu1604-x64-1/

For https://ci.adoptopenjdk.net/computer/test-packet-ubuntu1604-x64-1/ I can still see there are two executors.

If it's due to machine changes I should see this issue twice at most. Once for each machine unless the change is back and forward.
Confused seems it happened more than twice.
If this wont happen again I will close this.

@sophia-guo It may have still been showing 2 when you looked because there were already jobs running on both executors and the change can't take effect until one of them is freed.

@sophia-guo could you let us know if you see this again with @sxa555's changes applied. If not I will close this issue in the next day or two

The last time I saw it is on Feb 27. Ever since that didn't see it again. Suppose it should be good to close it.