Invoices - Invoices badge is $0.00 instead of 0,00 US$ when app language is Spanish

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 9.0.74-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: Exp
Email or phone of affected tester (no customers<EMAIL_ADDRESS>Issue reported by: Applause Internal Team
Action Performed:
Precondition:

App language is Spanish.
Default workspace currency is USD.
Invoices feature is enabled.

Note that the currency and amount in the Wallet (Billetera) badge is in the format of 0,00 US$
Go to workspace settings.

Expected Result:
The currency and amount in the Invoices (Facturas) badge will change to the format of 0,00 US$
Actual Result:
The currency and amount in the Invoices (Facturas) badge is still $0.00.
Workaround:
Unknown
Platforms:

[x] Android: Standalone
[x] Android: HybridApp
[x] Android: mWeb Chrome
[x] iOS: Standalone
[x] iOS: HybridApp
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
https://github.com/user-attachments/assets/47424e3c-2efc-45e4-9877-5d2556b4861b
View all open jobs on GitHub

Proposal
Please re-state the problem that we are trying to solve in this issue.
The currency and amount in the Invoices (Facturas) badge is still $0.00.
What is the root cause of that problem?
We are returning the wrong type of badge text here
https://github.com/Expensify/App/blob/c1454f772b8b780e015c01c1bffc4669d5383a78/src/pages/settings/InitialSettingsPage.tsx#L303
What changes do you think we should make in order to solve the problem?

We should convert this function to return the same format as we did here
https://github.com/Expensify/App/blob/b49e1bdc1444271f71e156e40fa72ab1dc590c5b/src/pages/workspace/WorkspaceInitialPage.tsx#L204-L207
What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

What alternative solutions did you explore? (Optional)
Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

Proposal
Please re-state the problem that we are trying to solve in this issue.
The currency and amount in the Invoices (Facturas) badge is still $0.00.
What is the root cause of that problem?
The invoice badge is always displayed with the format ${currency}{amount} that is inconsistent with the balance that we displayed in WorkspaceInvoiceBalanceSection here and I notice that the badge is also displayed with the wrong currency. It displays with  the workspace currency while in WorkspaceInvoiceBalanceSection we display with USD currency with the same value is policy?.invoice?.bankAccount?.stripeConnectAccountBalance

https://github.com/Expensify/App/blob/20b4c7db47969f7d2209f1c0b8fd765ce883f92c/src/pages/workspace/WorkspaceInitialPage.tsx#L204-L207
What changes do you think we should make in order to solve the problem?
We should use convertToDisplayString function without currency code then it will default to USD as we did here
badgeText: CurrencyUtils.convertToDisplayString(policy?.invoice?.bankAccount?.stripeConnectAccountBalance ?? 0),

https://github.com/Expensify/App/blob/20b4c7db47969f7d2209f1c0b8fd765ce883f92c/src/pages/workspace/WorkspaceInitialPage.tsx#L204-L207
What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

What alternative solutions did you explore? (Optional)
If the correct currency should be the workspace currency, we need to add the worksapce currency to convertToDisplayString here
badgeText: CurrencyUtils.convertToDisplayString(policy?.invoice?.bankAccount?.stripeConnectAccountBalance ?? 0, currencyCode),

https://github.com/Expensify/App/blob/20b4c7db47969f7d2209f1c0b8fd765ce883f92c/src/pages/workspace/WorkspaceInitialPage.tsx#L204-L207
and here
CurrencyUtils.convertToDisplayString(policy?.invoice?.bankAccount?.stripeConnectAccountBalance ?? 0, policy?.outputCurrency)

https://github.com/Expensify/App/blob/20b4c7db47969f7d2209f1c0b8fd765ce883f92c/src/pages/workspace/invoices/WorkspaceInvoiceBalanceSection.tsx#L31

I'm OOO Dec 16-20, I think this might be a quick fix so adding a leave buddy
next steps:

@dukenv0307 to review and select a proposal

Happy to help @sonialiap - FYI I'm out from the 19th, but that's just a day where we don't have overlap.

Thanks Jason! That's probably ok, most likely it won't need a B0 until I'm back anyway

Bumping @dukenv0307 for reviews


Update Example name for Azure Application Gateway

Update Example name for Azure Application Gateway
Name needed to reflect the suggested naming convention
Suggestion: -aag
Old Name: profx-agw
New Name: profx-aag

Hi @Lachlan-White, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

@Lachlan-White : Thanks for your contribution to the Azure documentation! The author, @telmosampaio, has been notified to review your proposed change.

We will not make that change to the documentation at this point. We might re-evaluate the suggested name the next time we review the document. But for now we will keep -agw.

#please-close


Ability to use the plugin without Docker in Docker

We have a usecase where we don't have sysbox in the container's runtime environment and there isn't a secure way to run dind (We used to mount docker socket but we've removed it due to the the nature of the sensitive workload). However, we still want to use the plugin. Perhaps it makes sense to add an additional option, assuming that Ruby is in the runtime, to run the junit xml analysis and annotation in the runtime environment w/o dind.
Here's my try to support this in the repo: https://github.com/buildkite-plugins/junit-annotate-buildkite-plugin/pull/239

Thanks @erict-square! The PR is merged and released in v2.6.0


Requesting a copy causes item to be undeletable

Describe the bug
If we have an item with one or more Bitstreams that are under embargo for which an EPerson has done a "Request a Copy" call, that item will not be deletable as an entry is created in the RequestItem table which won't be deleted on item deletion, causing a Foreign Key Constraint exception to be thrown as can be seen hereunder
org.hibernate.engine.jdbc.spi.SqlExceptionHelper @ ERROR: update or delete on table "item" violates foreign key constraint "requestitem_item_id_fkey" on table "reques titem"   Detail: Key (uuid)=(a1d0b513-749f-43cc-acbf-83eebf218b10) is still referenced from table "requestitem".
To Reproduce
Steps to reproduce the behavior:

Create an Item in the Repository
Add a bitstream to this Item, making sure it's under embargo
As an anonymous user, request a copy of this bitstream
Try to delete this item as the admin user
Verify that the error is thrown & that the item is not deleted

Expected behavior
The item should be deleted
Atmire would like to claim the work to fix this & it should require 4 hours of dev work including a test

Suggestions:

The copy request should be updated to set the Item reference to NULL.  IIRC we seem to keep historical requests which have been resolved.
The requester and the request recipients should receive an email saying that the request was resolved by deleting the requested object.

@Raf-atmire : If you have time to quickly create a PR for 7.5, we can do our best to see if we can find a reviewer in time.  If the fix is large or complex though, it may need to wait for 7.6.  Either way, I'll assign to you and add the estimate.


README links are dead

Hey there
https://msdn.microsoft.com/en-us/commandline/wsl/about
https://msdn.microsoft.com/en-us/commandline/wsl/release_notes
These links seem dead.

@hut8 Looks like MSDN is experiencing an outage in general, doesn't seem specific to WSL. Could you check back in some time?

:+1:


Log ethereum address on bee init/start

Inform the user about her generated Ethereum address as soon as possible when calling bee init or bee start. Fixes #969

I start reviewing

Hi Pavle,
I just checked out your branch and ran bee init. Just to ensure with @vandot that this also works with CLEF. Additionally, I would suggest that the init command not only logs the keys, but also returns them, so other programs can interface with the init command easily.
@janos , wdyt?

@Eknir Yes, I saw the comment in the issue regarding this, but I wasn't sure where to take it. Should we return it to stdout?

@Eknir returning complete keys would mean printing them to stdout. Would that help in some cases @vandot?

LGTM!
We can do a follow-up PR to also print to stdout


feat(MeasureTheory/Function): stronger version of Vitali's convergence theorem

Prove a stronger version of Vitali's convergence theorem, which does not require an IsFiniteMeasure hypothesis. Instead it uses a new uniform tightness hypothesis. The hypothesis UnifTight is implemented closely following the structure of the existing UnifIntegrable.

[x] depends on: #14570
[x] depends on: #14646
[x] depends on: #14954

Thanks a lot for the PR! Sorry that it tooks weeks to react to it. The reason it was missed by the reviewers is that it lacks labels. You should add the awaiting-review label to signal the PR is ready for other people to look at it. There is a special queue where only PRs with that label appear, and reviewers tend to look at that queue. When a PR is not yet ready for review, please add the label WIP. Basically never leave a PR without a label.
Also, to help sorting the PRs, adding the topic label t-measure-probability is helpful.
I have added these labels for you now.
About the PR: it is quite large and contains parts that should be PRed separately: the coercions between measurability properties is a big change in the way we use them, and should have its own PR. Could you open another PR with those changes, and edit the first message of this PR to note that it depends on the other one?

Thanks, good to know. I tried following the instructions in the Contributing Guidelines. I wasn't sure that the labels are something for the submitter to choose.
About splitting out the coercions. The main proof doesn't really use them. So if they are somehow against the Mathlib philosophy, they can just be dropped. Or is the point of the separate PR is that's where such a decision would be made?

About the coercions: I don't know yet if they are a good idea or not and a separate PR would be a good place to discuss that.
Making this PR independent of the new coercions would make it simpler to review, so if they are indeed not used much, that would be a good thing to do.

Could you please use explicit terms in calc blocks, so that they're readable without looking at the proofs?

Could you please use explicit terms in calc blocks, so that they're readable without looking at the proofs?

Done. I ungolfed the calc blocks. Hopefully they are more readable now.
P.S.: Is it good etiquette to merge with the master branch when doing updates on a PR? I haven't done it this time.

I changed the definition so that

it deals with ENNReals right away, no Reals involved;
it doesn't require s to be measurable; existence of a measurable set (and more) follows from this one, see new lemma;

Also, I generalized .add lemma so that it doesn't need 1 ≤ p anymore.
Could you please fix the rest of the file? If you need to get a measurable set from (hf : UnifTight ...), then you call the new exists_measurableSet_indicator lemma.

Fixed the rest of the file (UnifTight.lean). Changed exists_measurableSet_indicator to use ≤ instead of <, to be more consistent with the definition of UnifTight (making it easier to fix the rest of the file).

I asked @RemyDegenne to have another look at the final statement. I'll review the style tomorrow.

A note about terminology. Is UnifTight an appropriate name for the new hypothesis? I've checked two references Wikipedia and Fremlin (258Xj, Measure Theory vol.2). Both define the term '(uniformly) tight' for a family of measures, with Fremlin not dropping 'uniformly'. For measures, the property refers to the uniform smallness of the measure assigned to the complement of a compact set on a topological space.
The property that I defined didn't have a name in any references on Vitali's theorem that I've seen, so I named it by close analogy with the notion above. At the moment I'm happy with UnifTight as being sufficiently descriptive, specific and not contradicting convention (an equally good alternative could be TightFamily). If it is worth trying to avoid a future clash with the similarly named but distinct notion for measures, one could use instead TightFuncFamily or <appropriate namespace>.UnifTight. Alternatively, the notion for measures could be introduced in the future as MeasureTheory.Measure.UnifTight. Just some thoughts...

Let's ask @sgouezel about names and the final statement as well. I will review the style once the main statement is cleared.

UnifTight seems to be a good name for that notion (UniformlyTight could be perhaps better since more explicit and not too long? But UnifTight matches our UnifIntegrable, so it's good). Such families of functions are called tight in Royden and Fitzpatrick, Real Analysis, 4th ed (page 98). Their Vitali convergence theorem uses it (same page).
The related measure notion could be simply called Tight.

Latest update has responded to all comments.

New update responds to most comments (see individual replies above for details).

I golfed some helpers lemmas. I'll go over the main file on Monday.

I golfed some helpers lemmas. I'll go over the main file on Monday.

Should the PR switch over to < ε instead of ≤ ε everywhere? Your last update is mixing the two kinds of inequalities together.

You would get better feedback if you split off the prerequisites. I see at least three separate prerequisite PRs you could open:
* The new lemmas in `Analysis.SpecialFunctions.Pow.NNReal`
* The new lemma in `Data.ENNReal.Operations`
* The various measure theoretic prerequisites.

It turns out that the new lemmas that I had added in Data.ENNReal.Operations and in Analysis.SpecialFunctions.Pow.NNReal became unnecessary after the refactoring that was already done earlier. So I just removed them. I think that the only remaining changes that are outside the new UnifTight.lean file were moved there through the refactoring and review carried out by @urkud.
I can of course still split the PR, but perhaps Yury can chime in on whether that's really necessary.

It turns out that the new lemmas that I had added in Data.ENNReal.Operations and in Analysis.SpecialFunctions.Pow.NNReal became unnecessary after the refactoring that was already done earlier. So I just removed them.

Feel free to open independent PRs for them if you think they are generally useful, though (it happens to me a lot that I write lemmas that I end up not needing, and I usually do PR them anyway).

Can you also split off the definition of uniform tightness to a preliminary PR?

I'm sorry for a long silence. I unassigned this PR from me, because I've failed to review it in time.

All PR dependencies have been accepted and merged. the finite/nonFinite renaming has been completed. A couple of lemmas from the UnifTight API strengthened (according to the easy hypotheses/hard theorems philosophy).

bors merge


How to export to GCP Cloud Trace?

I tried to setup trace exports from my Clojure app to GCP Cloud Trace with official OpenTelemetry tooling, but I'm not sure if this is expected to work with clj-otel. Here's what I did:
;; deps.edn
{:deps {,,,
        com.github.steffan-westcott/clj-otel-api {:mvn/version "0.2.6"}
        com.google.cloud.opentelemetry/exporter-trace {:mvn/version "0.20.0"}
        io.opentelemetry/opentelemetry-api {:mvn/version "1.34.1"}
        io.opentelemetry/opentelemetry-sdk {:mvn/version "1.34.1"}
        io.opentelemetry/opentelemetry-exporter-otlp {:mvn/version "1.34.1"}
,,,}}

And in code:
(ns myapp.prod
  (:gen-class)
  (:import (com.google.cloud.opentelemetry.trace TraceExporter)
           (io.opentelemetry.sdk OpenTelemetrySdk)
           (io.opentelemetry.sdk.trace SdkTracerProvider)
           (io.opentelemetry.sdk.trace.export SimpleSpanProcessor)))

(defn init-opentelemetry []
  (let [trace-exporter (TraceExporter/createWithDefaultConfiguration)
        span-processor (.build (SimpleSpanProcessor/builder trace-exporter))
        tracer-provider (-> (SdkTracerProvider/builder)
                            (.addSpanProcessor span-processor)
                            .build)]
    (-> (OpenTelemetrySdk/builder)
        (.setTracerProvider tracer-provider)
        .buildAndRegisterGlobal)))

This code runs, but I don't see any traces in GCP. I also have not wired it to clj-otel in any way, so am not that surprised it didn't work. Any hints on how to achieve this?

Edit: I changed the last .build to .buildAndRegisterGlobal, and now I'm running into some conflict with the clj-otel tooling. The exception message was:

java.lang.IllegalStateException: GlobalOpenTelemetry.set has already been called. GlobalOpenTelemetry.set must be called only once before any calls to GlobalOpenTelemetry.get. If you are using the OpenTelemetrySdk, use OpenTelemetrySdkBuilder.buildAndRegisterGlobal instead. Previous invocation set to cause of this exception

Relevant lines from the stack trace:
Caused by: java.lang.Throwable
	at io.opentelemetry.api.GlobalOpenTelemetry.set(GlobalOpenTelemetry.java:115)
	at io.opentelemetry.api.GlobalOpenTelemetry.get(GlobalOpenTelemetry.java:85)
	at steffan_westcott.clj_otel.api.otel$get_global_otel_BANG_.invokeStatic(otel.clj:15)
	at steffan_westcott.clj_otel.api.otel$get_global_otel_BANG_.invoke(otel.clj:15)
	at steffan_westcott.clj_otel.api.otel$get_default_otel_BANG_.invokeStatic(otel.clj:46)
	at steffan_westcott.clj_otel.api.otel$get_default_otel_BANG_.invoke(otel.clj:39)
	at steffan_westcott.clj_otel.api.metrics.instrument$get_meter.invokeStatic(instrument.clj:47)
	at steffan_westcott.clj_otel.api.metrics.instrument$get_meter.invoke(instrument.clj:30)
	at steffan_westcott.clj_otel.api.metrics.instrument$get_meter.invokeStatic(instrument.clj:41)
	at steffan_westcott.clj_otel.api.metrics.instrument$get_meter.invoke(instrument.clj:30)
	at steffan_westcott.clj_otel.api.metrics.instrument$get_default_meter_BANG_.invokeStatic(instrument.clj:68)
	at steffan_westcott.clj_otel.api.metrics.instrument$get_default_meter_BANG_.invoke(instrument.clj:62)
	at steffan_westcott.clj_otel.api.metrics.instrument$instrument.invokeStatic(instrument.clj:257)
	at steffan_westcott.clj_otel.api.metrics.instrument$instrument.invoke(instrument.clj:221)
	at steffan_westcott.clj_otel.api.metrics.instrument$instrument.invokeStatic(instrument.clj:254)
	at steffan_westcott.clj_otel.api.metrics.instrument$instrument.invoke(instrument.clj:221)

I don't have any experience with Google Cloud Platform, so unfortunately I don't have solid advice. However, it may be easier to use Google Cloud Exporter in Collector Contrib rather than programmatically configure the SDK in your application.

I don't think GCP specifics are important here - the question is more one of how can I set a TraceExporter instance that clj-otel will use?
I checked out your link, but I honestly don't understand what it is or how to use it. Looks like a lot of go code? Is it a separate service? I really just want to export traces from my JVM-app directly to GCP.

The OpenTelemetry Collector is a runnable process that forwards telemetry data from applications to telemetry backends. Almost all of the examples in clj-otel demonstrate use of the Collector.
Collector Contrib is an extended version of the standard Collector that has extra receivers, processors and exporters. Google Cloud Exporter is present in Collector Contrib. The Google documentation for working with OpenTelemetry in Java has a quickstart example that uses Google Cloud Exporter.
I suggest getting traces working using the Collector as per the Google quickstart example. Programmatically configuring the SDK is possible, but is the most challenging option to get working correctly.

If you decide not to use the Collector, the next easiest option is to use the OpenTelemetry autoconfigure SDK extension. Google provide a library that works with this. The shaded variant can, in addition, be used as an extension to the OpenTelemetry instrumentation agent. Here is a full program with manual instrumentation that uses the agent extension:
deps.edn
{:paths   ["src"]
 :deps    {org.clojure/clojure                      {:mvn/version "1.11.3"}
           com.github.steffan-westcott/clj-otel-api {:mvn/version "0.2.7"}}
 :aliases {:otel {:jvm-opts [;; Download the following from
                             ;; https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/download/v2.5.0/opentelemetry-javaagent.jar
                             "-javaagent:opentelemetry-javaagent.jar"

                             ;; Download the following from
                             ;; https://repo1.maven.org/maven2/com/google/cloud/opentelemetry/exporter-auto/0.30.0-alpha/exporter-auto-0.30.0-alpha-shaded.jar
                             "-Dotel.javaagent.extensions=exporter-auto-0.30.0-alpha-shaded.jar"

                             "-Dotel.resource.attributes=service.name=my-app"
                             "-Dotel.traces.exporter=google_cloud_trace"
                             "-Dotel.metrics.exporter=google_cloud_monitoring"
                             "-Dotel.logs.exporter=none"

                             ;; Supply your configuration details below
                             "-DGOOGLE_CLOUD_PROJECT=<my-project-id>"
                             "-DGOOGLE_APPLICATION_CREDENTIALS=<my-credentials>"]}}}

src/org/example/my_app.clj
(ns org.example.my-app
  (:require [steffan-westcott.clj-otel.api.trace.span :as span]))

(defn foo []
  (span/with-span! "Doing foo things"
    (println "foo")))

Thanks a lot for all the pointers 👍 🙏


Can you ease add a sample code for better understanding?

Sample code would help reader better understand the scenario and use case.

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

ID: b591a085-2835-71e4-2b3a-17b9a23c846a
Version Independent ID: aa6d27e9-9492-1ea1-343e-619932e4e91e
Content: Dependency and execution order in asynchronous operations (Developer Guide for Dynamics 365 for Customer Engagement apps)
Content Source: ce/developer/dependency-execution-order-asynchronous-operations.md
Service: crm-online
GitHub Login: @JimDaly
Microsoft Alias: jdaly

This topic has been cleaned up, trimmed down and (I hope) made clearer at:
https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/asynchronous-service
@KumarVivek
Can we retire this topic and just redirect people to the newer one?


Allows to configure routes

Is your feature request related to a problem? Please describe.
The route paths and middleware can't be configured atm.
Describe the solution you'd like
Update config to support route path and middleware similar to laravel/telescope

Thanks for your request! Could you please provide a bit more detail on how you'd like it to work? Is it the API route prefix you'd like to change or the other routes?

I want to change the both route prefix and paths. And also, I want to apply my middleware since I dont want to use fully qualified class name for shoppable_type in order_items table so I'm using morphMap to customize polymorphic types.  Ideally, I think you shouldn't register routes automatically. You could use the route macro to add your method i.e Route::cart() similar to Route::auth() from Laravel so developers can decide whether the route should be registered.

Right. I'll make the middleware and prefixes + paths configurable in the next release.
I'm currently working on a public API for managing the cart without using the REST API, when that's done I was planning on making the REST API optional. Is that what you meant?

Yes, please. Giving developers more power to do whatever they want


[UI] Fix connection page crash

Notes for Reviewers
This PR fixes #

Signed commits

[ ] Yes, I signed my commits.

Thanks @Yashsharma1911 , i already had a fix for this scenario: https://github.com/meshery/meshery/pull/9860 so it is another null check left, right?

@sudhanshutech Yes, I'm merging this as this is urgent error


build: add mkdocs for documentation generation (DSP-460)

[x] add MkDocs site configuration
[x] update Makefiles
[x] update documentation on how to use it
[x] publish to docs.knora.org
[x] update links on knora.org
[x] automate publishing docs on every release

=> orchestration through Bazel will be implemented in a future PR (DSP-469)

Thanks for the review :-)


Count Children in tree module

With this PR we now have the possibility to count the children in a node. This is important in so far as you can better display the tree module on the frontend you now have the option to display the popup elements differently if a node has no children.
Like so:

Why not use the new count-feature from viur-datastore you recently added there?

I also think that count is more appropriate here. Just keep in mind that this takes longer with larger result sets (at least that was the case in the python2 environment) and should therefore run best deferred.


Deprecated Bower version

The version attribute of Bower is deprecated: https://github.com/bower/spec/blob/master/json.md#version
Bower is using the versions listed on:

https://github.com/paroga/cbor-js/releases

Coverage remained the same at 99.262% when pulling 909f5f42feb6f68651b14fb35c652b2007dc6325 on bennyn:patch-2 into 65dc49611107db83aff8308a6b381f4d7933824b on paroga:master.


引入库后报 Type 'FlutterWindow' not found.

../../.pub-cache/hosted/pub.dev/flutter_screenutil-5.6.0/lib/src/screen_util.dart:58:5: Error: Type 'FlutterWindow' not found.
    FlutterWindow? window,
    ^^^^^^^^^^^^^

version:5.6.0
fock一份修复试试

• Flutter version 3.7.0-23.0.pre.22 on channel master at /home/juzi/flutter
• Upstream repository https://github.com/flutter/flutter
• Framework revision 0bbb5ec0c2 (8 小时前), 2023-01-19 01:22:08 -0500
• Engine revision 40f7f0f099
• Dart version 3.0.0 (build 3.0.0-136.0.dev)
• DevTools version 2.20.0

我已经尝试修复了这个问题，我怎么提交上来

whats the soliution pls...am having that issue

@AndromedaX7 what is the solution

using stable branch

using stable branch

Or modify library source code.

lib/src/screen_util.dart
lib/src/screenutil_init.dart
https://github.com/OpenFlutter/flutter_screenutil/pull/451/files

@AndromedaX7 Thanks

fixed at  5.6.1


Foresee admin command to clear the content of a box

This was is spin off of issue #58
This command should only be accessible and executable by the admin user of a box

Check if the user (using the phonenumber) is the admin user of a box (see IBoxStore)
Delete all messages and images from the respective MediaServiceProviders.

done


Feedbaack on Annotation-Statement cardinality

Hoping folks will review and provide feedback on the Annotation Content Model (ACM) outlined here.
In particular, review the recent additions about 'primary' vs 'secondary' statements, and there being only one primary statement per annotation.
Input welcome in this ticket, or using comments on the ACM google doc itself, concerning: (A) whether the concepts, terms, and distinctions made in the ACM are clear, intuitive, and pragmatic, and (B) what implications that these conceptual / terminological decisions may have for our data model.

I am a little concerned about when a secondary statement conflicts with the primary.  For example, this variant has conflicting annotations in ClinVar.  Can we provide an explicit example of how this should be represented?


updated testing docs

Updated testing docs regarding some gotchas...

Coverage remained the same at ?% when pulling 6ab9a1fd6def7f8f3dad3374b15680630d35e433 on update-testing-docs into 67f5fdd71b21e2b97a2ae5162cf3dcb17d6ea467 on master.


Custom pull request description

I always mannually enter Fixes #${issueNumber} in my descriptions, I'd like to have this done automatically. Ability to provide custom pull request description with advanced settings similar to the setting: githubIssues.issueBranchTitle

Is this still being worked on? Would love to work on it if possible so that I could fix this problem because I like this extension but this is a feature I would like to have.

Well, for example I usually write on the description "Closes [issue number]" then GitHub automatically links the PR with the issue and when merged, the issue gets closes.

How should the extension know/guess which issue number should be written in the description?

Oh sorry actually I have realized I misunderstood the original issue. What I want is a suggestion popup when I start writing a # just like in GitHub. Maybe I create another issue for this?

The "Create" view and the PR description are webviews, so we don't have completions there. That feature request is https://github.com/microsoft/vscode-pull-request-github/issues/2401.

Oh I see that's quite unfortunate. But after checking the source code, it seems there's a component responsible for the description input. Wouldn't it be possible to listen for changes and show the popup when someone types the # symbol. Sorry but I initially thought this was an easy thing to do. It's because I don't have a good understanding of the code I guess.

Closing as a duplicate of https://github.com/microsoft/vscode-pull-request-github/issues/2401.


D/S ratio

Maybe the wrong place for this, but we are developing a thermal sensing application for reading body temperature using the MLX90632. I can't find any information on the distance to spot ratio for this sensor. We are trying to determine how far from the sensor we can get and still obtain accurate reading of say the forehead area.

Dear sir,
This is indeed not the right place for this non-software related question.  Our application engineers are not monitoring github.
Please contact your distributor or<EMAIL_ADDRESS>


[BUG] unstable deployment of POD prometheus-0

Describe the bug

The deployment of POD prometheus-rancher-monitoring-prometheus-0 is not stable.
To Reproduce
Steps to reproduce the behavior:

Manually install a 2-node harvester, the first node is naturally the control-plane node, the second is a compute node.  The POD prometheus-rancher-monitoring-prometheus-0 is deployed in control-plane node.

The
NAME                                                     READY   STATUS    RESTARTS       AGE
prometheus-rancher-monitoring-prometheus-0               3/3     Running   0              167m
rancher-monitoring-grafana-d9c56d79b-sbdm8               3/3     Running   0              168m
..

prometheus-rancher-monitoring-prometheus-0   is deployed in control-plane node harv21
308-                    }
309-                ],
310:                "nodeName": "harv21",
311:                "nodeSelector": {
312-                    "kubernetes.io/os": "linux"
313-                },

NAME     STATUS   ROLES                       AGE   VERSION          INTERNAL-IP       EXTERNAL-IP   OS-IMAGE           KERNEL-VERSION                CONTAINER-RUNTIME
harv2    Ready    <none>                      56m   v1.22.7+rke2r1   <IP_ADDRESS>   <none>        Harvester master   5.3.18-150300.59.54-default   containerd://1.5.9-k3s1
harv21   Ready    control-plane,etcd,master   23h   v1.22.7+rke2r1   <IP_ADDRESS>    <none>        Harvester master   5.3.18-150300.59.54-default   containerd://1.5.9-k3s1

Power off both nodes

Power on control-plane node (harv21) first, after 5 seconds, power on compute-node (harv2)

Check the prometheus-rancher-monitoring-prometheus-0 it is deployed in compute-node

                    }
                ],
                "nodeName": "harv2",
                "nodeSelector": {
                    "kubernetes.io/os": "linux"
                },

The first issues is:
When control-plane node is ready, for  some time, the "Cluster Metric" is unavailable in the WebUI.
Expected behavior

When there is nothing changed by the user, the prometheus-rancher-monitoring-prometheus-0 should keep stable.
Support bundle

Environment:

Harvester ISO version:  Version: master-75cc3ced-head
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630):  KVM based 2-node Harvester

Additional context
Add any other context about the problem here.

Step 5: Power off compute-node harv2

"Cluster Metric" is not shown in WebUI

prometheus-rancher-monitoring-prometheus-0 POD can not be terminated, the "Cluster Metric" is not available
NAME                                                     READY   STATUS    RESTARTS      AGE
prometheus-rancher-monitoring-prometheus-0               3/3     Running   0             55m
rancher-monitoring-grafana-d9c56d79b-jg677               3/3     Running   0             56m
rancher-monitoring-kube-state-metrics-5bc8bb48bd-jgk8c   1/1     Running   3 (57m ago)   23h
rancher-monitoring-operator-559767d69b-v6wq6             1/1     Running   3 (57m ago)   23h
rancher-monitoring-prometheus-adapter-8846d4757-pw84b    1/1     Running   3 (57m ago)   23h
rancher-monitoring-prometheus-node-exporter-6f647        1/1     Running   3 (57m ago)   23h
rancher-monitoring-prometheus-node-exporter-msgzt        1/1     Running   1 (56m ago)   74m

 k  logs -n cattle-monitoring-system prometheus-rancher-monitoring-prometheus-0
Error from server: Get "https://<IP_ADDRESS>:10250/containerLogs/cattle-monitoring-system/prometheus-rancher-monitoring-prometheus-0/prometheus": dial tcp <IP_ADDRESS>:10250: connect: no route to host

NAME                                                     READY   STATUS        RESTARTS      AGE
prometheus-rancher-monitoring-prometheus-0               3/3     Terminating   0             59m
rancher-monitoring-grafana-d9c56d79b-jg677               3/3     Terminating   0             60m
rancher-monitoring-grafana-d9c56d79b-zdln9               0/3     Init:0/2      0             108s
rancher-monitoring-kube-state-metrics-5bc8bb48bd-jgk8c   1/1     Running       3 (61m ago)   23h
..
..

NAME                                                     READY   STATUS        RESTARTS      AGE
prometheus-rancher-monitoring-prometheus-0               3/3     Terminating   0             61m
rancher-monitoring-grafana-d9c56d79b-jg677               3/3     Terminating   0             62m
rancher-monitoring-grafana-d9c56d79b-zdln9               0/3     Init:0/2      0             3m56s
rancher-monitoring-kube-state-metrics-5bc8bb48bd-jgk8c   1/1     Running       3 (63m ago)   23h
..

NAME                                                     READY   STATUS        RESTARTS      AGE
prometheus-rancher-monitoring-prometheus-0               3/3     Terminating   0             72m
rancher-monitoring-grafana-d9c56d79b-jg677               3/3     Terminating   0             73m
rancher-monitoring-grafana-d9c56d79b-zdln9               0/3     Init:0/2      0             14m
..

NAME                                                     READY   STATUS        RESTARTS      AGE
prometheus-rancher-monitoring-prometheus-0               3/3     Terminating   0             80m
rancher-monitoring-grafana-d9c56d79b-jg677               3/3     Terminating   0             81m
rancher-monitoring-grafana-d9c56d79b-zdln9               0/3     Init:0/2      0             23m
rancher-monitoring-kube-state-metrics-5bc8bb48bd-jgk8c   1/1     Running       3 (82m ago)   24h
..

The latest test in https://github.com/harvester/harvester/issues/1531  may also be related.

FYI: @TachunLin @guangbochen @yasker

Update: Even for single-node harvester, after power off and reboot, the POD prometheus-rancher-monitoring-prometheus-0 is re-created.
POD owner Statefulset and ancester CRD Prometheus did not changed after creation.
The AGE of prometheus-rancher-monitoring-prometheus-0 is also less than uptime after system re-power-on, normal POD was booted 7m3s ago, but prometheus-rancher-monitoring-prometheus-0 POD was booted 4m39s ago.
NAMESPACE                   NAME                                                     READY   STATUS      RESTARTS        AGE
cattle-fleet-local-system   fleet-agent-8649b7d5b6-s752w                             1/1     Running     1 (7m3s ago)    5h18m
cattle-fleet-system         fleet-controller-8445657945-7l5wh                        1/1     Running     1 (7m3s ago)    5h18m
cattle-fleet-system         gitjob-6cd5874f8c-2v7dl                                  1/1     Running     1 (7m3s ago)    5h18m
cattle-monitoring-system    prometheus-rancher-monitoring-prometheus-0               3/3     Running     0               4m39s
cattle-monitoring-system    rancher-monitoring-grafana-d9c56d79b-8wqbf               3/3     Running     0               5m19s
cattle-monitoring-system    rancher-monitoring-kube-state-metrics-5bc8bb48bd-8wks8   1/1     Running     1 (7m3s ago)    5h17m
..
harvester-system            harvester-56c94f649f-q8sxj                               1/1     Running     2 (5m42s ago)   5h17m

{
    "apiVersion": "v1",
..
                },
                "creationTimestamp": "2022-03-16T20:24:10Z",
                "generateName": "prometheus-rancher-monitoring-prometheus-",
                ..
                "ownerReferences": [
                    {
                        "apiVersion": "apps/v1",
                        "blockOwnerDeletion": true,
                        "controller": true,
                        "kind": "StatefulSet",
                        "name": "prometheus-rancher-monitoring-prometheus",
                        "uid": "7ac78661-0a5b-4c5d-b910-6db7b01faae3"
                    }
                ],

{
..
                "creationTimestamp": "2022-03-16T15:11:11Z",
                "generateName": "harvester-56c94f649f-",

The owner of prometheus-rancher-monitoring-prometheus-0,  StatefulSet prometheus-rancher-monitoring-prometheus was created when cluster was installed, had generation 1
NAMESPACE                  NAME                                       READY   AGE
cattle-monitoring-system   prometheus-rancher-monitoring-prometheus   1/1     5h24m
harvester-system           kube-vip-cloud-provider                    1/1     5h25m

k get statefulset -n cattle-monitoring-system prometheus-rancher-monitoring-prometheus -o JSON
{
    "apiVersion": "apps/v1",
    "kind": "StatefulSet",
    "metadata": {
        "annotations": {
            "meta.helm.sh/release-name": "rancher-monitoring",
            "meta.helm.sh/release-namespace": "cattle-monitoring-system",
            "objectset.rio.cattle.io/id": "default-mcc-rancher-monitoring-cattle-fleet-local-system",
            "prometheus-operator-input-hash": "16123941925411477401"
        },
        "creationTimestamp": "2022-03-16T15:11:34Z",
        "generation": 1,
        "labels": {
            "app": "rancher-monitoring-prometheus",
            "app.kubernetes.io/instance": "rancher-monitoring",
            "app.kubernetes.io/managed-by": "Helm",
            "app.kubernetes.io/part-of": "rancher-monitoring",
            "app.kubernetes.io/version": "100.1.0_up19.0.3",
            "chart": "rancher-monitoring-100.1.0_up19.0.3",
            "heritage": "Helm",
            "objectset.rio.cattle.io/hash": "a8c87f2d01731fdad3b988f675a7c8a7da10d382",
            "operator.prometheus.io/name": "rancher-monitoring-prometheus",
            "operator.prometheus.io/shard": "0",
            "release": "rancher-monitoring"
        },
        "name": "prometheus-rancher-monitoring-prometheus",
        "namespace": "cattle-monitoring-system",
        "ownerReferences": [
            {
                "apiVersion": "monitoring.coreos.com/v1",
                "blockOwnerDeletion": true,
                "controller": true,
                "kind": "Prometheus",
                "name": "rancher-monitoring-prometheus",
                "uid": "4defedd2-9647-4fd5-8d15-c293bc62f15a"
            }
        ],
        "resourceVersion": "31470",
        "uid": "7ac78661-0a5b-4c5d-b910-6db7b01faae3"
    },

The owner of prometheus-rancher-monitoring-prometheus,  Prometheus rancher-monitoring-prometheus  was created when cluster was installed, had generation 1
 k get Prometheus -A
NAMESPACE                  NAME                            VERSION   REPLICAS   AGE
cattle-monitoring-system   rancher-monitoring-prometheus   v2.28.1   1          5h30m

k get Prometheus rancher-monitoring-prometheus -n cattle-monitoring-system -o JSON
{
    "apiVersion": "monitoring.coreos.com/v1",
    "kind": "Prometheus",
    "metadata": {
        "annotations": {
            "meta.helm.sh/release-name": "rancher-monitoring",
            "meta.helm.sh/release-namespace": "cattle-monitoring-system",
            "objectset.rio.cattle.io/id": "default-mcc-rancher-monitoring-cattle-fleet-local-system"
        },
        "creationTimestamp": "2022-03-16T15:11:29Z",
        "generation": 1,

fleet-agent did the upgrade for those bundledeployment, it caused the POD to be re-deployed.
k logs -n cattle-fleet-local-system fleet-agent-8649b7d5b6-s752w
I0316 20:22:46.463797       1 leaderelection.go:243] attempting to acquire leader lease cattle-fleet-local-system/fleet-agent-lock...
I0316 20:22:46.507933       1 leaderelection.go:253] successfully acquired lease cattle-fleet-local-system/fleet-agent-lock
..
time="2022-03-16T20:23:02Z" level=info msg="performing update for rancher-monitoring-crd"
time="2022-03-16T20:23:02Z" level=info msg="creating upgraded release for rancher-monitoring-crd"
time="2022-03-16T20:23:02Z" level=info msg="performing update for rancher-monitoring"
time="2022-03-16T20:23:03Z" level=info msg="dry run for rancher-monitoring"
time="2022-03-16T20:23:03Z" level=info msg="updating status for upgraded release for harvester-crd"
time="2022-03-16T20:23:03Z" level=info msg="getting history for release harvester-crd"

time="2022-03-16T20:23:46Z" level=info msg="getting history for release harvester"
time="2022-03-16T20:23:46Z" level=info msg="performing update for rancher-monitoring"
time="2022-03-16T20:23:47Z" level=info msg="getting history for release harvester"
time="2022-03-16T20:23:47Z" level=info msg="dry run for rancher-monitoring"
W0316 20:23:47.384699       1 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
time="2022-03-16T20:23:47Z" level=info msg="Helm: Upgrading mcc-rancher-monitoring"
time="2022-03-16T20:23:47Z" level=info msg="preparing upgrade for rancher-monitoring"
time="2022-03-16T20:23:47Z" level=error msg="bundle mcc-harvester: configmap.v1 longhorn-system/longhorn-storageclass missing"
time="2022-03-16T20:23:47Z" level=info msg="getting history for release harvester"
W0316 20:23:47.929471       1 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
E0316 20:23:48.018105       1 memcache.go:196] couldn't get resource list for custom.metrics.k8s.io/v1beta1: Got empty response for: custom.metrics.k8s.io/v1beta1
time="2022-03-16T20:23:49Z" level=info msg="updating status for upgraded release for rancher-monitoring-crd"
time="2022-03-16T20:23:49Z" level=info msg="getting history for release rancher-monitoring-crd"
time="2022-03-16T20:23:49Z" level=info msg="performing update for rancher-monitoring"

time="2022-03-16T20:24:42Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-16T20:24:42Z" level=info msg="getting history for release rancher-monitoring"
W0316 20:24:43.071005       1 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
time="2022-03-16T20:24:43Z" level=info msg="getting history for release rancher-monitoring"
time="2022-03-16T20:24:43Z" level=info msg="getting history for release rancher-monitoring"
W0316 20:24:44.290635       1 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
time="2022-03-16T20:24:44Z" level=error msg="bundle mcc-rancher-monitoring: mutatingwebhookconfiguration.admissionregistration.k8s.io rancher-monitoring-admission modified {\"webhooks\":[{\"admissionReviewVersions\":[\"v1\",\"v1beta1\"],\"clientConfig\":{\"caBundle\":\"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJkakNDQVJ5Z0F3SUJBZ0lSQU5QWEUyZ3BZdUlJWEt0dDdtQzZUdG93Q2dZSUtvWkl6ajBFQXdJd0R6RU4KTUFzR0ExVUVDaE1FYm1sc01UQWdGdzB5TWpBek1UWXhOVEEyTWpaYUdBOHlNVEl5TURJeU1ERTFNRFl5TmxvdwpEekVOTUFzR0ExVUVDaE1FYm1sc01UQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJCTkZEb2hiCkVTSm1RL2NSSkZjc1FWMEdldDVCVDVIQTlMd2lvNWRTOWpOYm9aa0FxelBWSXRpQ1krY2ZtSStsMVJOVXNGbisKSXIwckdtNkpVN2dIV3R1alZ6QlZNQTRHQTFVZER3RUIvd1FFQXdJQ0JEQVRCZ05WSFNVRUREQUtCZ2dyQmdFRgpCUWNEQVRBUEJnTlZIUk1CQWY4RUJUQURBUUgvTUIwR0ExVWREZ1FXQkJTVXBVN0N1QWhxTzNpdHlFSURHa2doCmx3N1VsREFLQmdncWhrak9QUVFEQWdOSUFEQkZBaUFFNTAyMnBja2kzNFdKZG15bGtQTHBSK25wV00zLzBaU2cKbjIwK1A4RzVwZ0loQU1jZ29RYk4wdCsrUHhuWlZuNlhFbDhhc2xEN1VLUnNmcGhaU2EwTFovdnIKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=\",\"service\":{\"name\":\"rancher-monitoring-operator\",\"namespace\":\"cattle-monitoring-system\",\"path\":\"/admission-prometheusrules/mutate\",\"port\":443}},\"failurePolicy\":\"Ignore\",\"matchPolicy\":\"Equivalent\",\"name\":\"prometheusrulemutate.monitoring.coreos.com\",\"namespaceSelector\":{},\"objectSelector\":{},\"reinvocationPolicy\":\"Never\",\"rules\":[{\"apiGroups\":[\"monitoring.coreos.com\"],\"apiVersions\":[\"*\"],\"operations\":[\"CREATE\",\"UPDATE\"],\"resources\":[\"prometheusrules\"],\"scope\":\"*\"}],\"sideEffects\":\"None\",\"timeoutSeconds\":10}]}"
time="2022-03-16T20:24:44Z" level=info msg="getting history for release rancher-monitoring"
W0316 20:24:45.154043       1 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
time="2022-03-16T20:24:45Z" level=info msg="getting history for release rancher-monitoring"
time="2022-03-16T20:24:45Z" level=info msg="getting history for release rancher-monitoring"
W0316 20:24:46.406559       1 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
time="2022-03-16T20:24:46Z" level=error msg="bundle mcc-rancher-monitoring: mutatingwebhookconfiguration.admissionregistration.k8s.io rancher-monitoring-admission modified {\"webhooks\":[{\"admissionReviewVersions\":[\"v1\",\"v1beta1\"],\"clientConfig\":{\"caBundle\":\"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJkakNDQVJ5Z0F3SUJBZ0lSQU5QWEUyZ3BZdUlJWEt0dDdtQzZUdG93Q2dZSUtvWkl6ajBFQXdJd0R6RU4KTUFzR0ExVUVDaE1FYm1sc01UQWdGdzB5TWpBek1UWXhOVEEyTWpaYUdBOHlNVEl5TURJeU1ERTFNRFl5TmxvdwpEekVOTUFzR0ExVUVDaE1FYm1sc01UQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJCTkZEb2hiCkVTSm1RL2NSSkZjc1FWMEdldDVCVDVIQTlMd2lvNWRTOWpOYm9aa0FxelBWSXRpQ1krY2ZtSStsMVJOVXNGbisKSXIwckdtNkpVN2dIV3R1alZ6QlZNQTRHQTFVZER3RUIvd1FFQXdJQ0JEQVRCZ05WSFNVRUREQUtCZ2dyQmdFRgpCUWNEQVRBUEJnTlZIUk1CQWY4RUJUQURBUUgvTUIwR0ExVWREZ1FXQkJTVXBVN0N1QWhxTzNpdHlFSURHa2doCmx3N1VsREFLQmdncWhrak9QUVFEQWdOSUFEQkZBaUFFNTAyMnBja2kzNFdKZG15bGtQTHBSK25wV00zLzBaU2cKbjIwK1A4RzVwZ0loQU1jZ29RYk4wdCsrUHhuWlZuNlhFbDhhc2xEN1VLUnNmcGhaU2EwTFovdnIKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=\",\"service\":{\"name\":\"rancher-monitoring-operator\",\"namespace\":\"cattle-monitoring-system\",\"path\":\"/admission-prometheusrules/mutate\",\"port\":443}},\"failurePolicy\":\"Ignore\",\"matchPolicy\":\"Equivalent\",\"name\":\"prometheusrulemutate.monitoring.coreos.com\",\"namespaceSelector\":{},\"objectSelector\":{},\"reinvocationPolicy\":\"Never\",\"rules\":[{\"apiGroups\":[\"monitoring.coreos.com\"],\"apiVersions\":[\"*\"],\"operations\":[\"CREATE\",\"UPDATE\"],\"resources\":[\"prometheusrules\"],\"scope\":\"*\"}],\"sideEffects\":\"None\",\"timeoutSeconds\":10}]}"
time="2022-03-16T20:24:46Z" level=info msg="getting history for release rancher-monitoring"
W0316 20:24:47.196081       1 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
E0316 20:24:47.513597       1 memcache.go:196] couldn't get resource list for custom.metrics.k8s.io/v1beta1: Got empty response for: custom.metrics.k8s.io/v1beta1

fleet-agent complains: mutatingwebhookconfiguration.admissionregistration.k8s.io rancher-monitoring-admission modified
The object: rancher-monitoring-admission (kind: MutatingWebhookConfiguration) is trully updated one more time when Helm is upgrading the chart rancher-monitoring.

reboot the harvester cluster, 2 changes of rancher-monitoring-admission are observed:
(generation 29, 30)
29 vs 30

reboot the harvester cluster, anohter 2 changes of rancher-monitoring-admission are observed:
(generation 31 at 17:46:47, 32  at 17:46:48)
30 vs 31

31 vs 32

timeline:
Fleet-agent call Helm to DeployBundle:  17:46:14 ~ 17:47:01
time="2022-03-29T17:46:14Z" level=warning msg="DEV bd: name:mcc-rancher-monitoring DeployBundle BB B, notify to fleet-agent, last update time:2022-03-29T15:05:49Z, cur release:cattle-monitoring-system/rancher-monitoring:14, cur deployID:s-3037063ddd777fc28a3f1c7cba6f6d98748123942a7f6da3c4c921dbca782:35485de4670526d587c0858d6ab4d60e635fca2497fa06d60b9bd45e49b8e4f3"

time="2022-03-29T17:47:01Z" level=warning msg="DEV bd: name:mcc-rancher-monitoring DeployBundle BB E, last update time:2022-03-29T15:05:49Z, new release:cattle-monitoring-system/rancher-monitoring:16, == cur release?:false, new deployID:s-3037063ddd777fc28a3f1c7cba6f6d98748123942a7f6da3c4c921dbca782:35485de4670526d587c0858d6ab4d60e635fca2497fa06d60b9bd45e49b8e4f3, == cur deployID?:true"

Helm start to upgrade at  17:46:19
time="2022-03-29T17:46:19Z" level=info msg="Helm: Upgrading mcc-rancher-monitoring"

The next round: Fleet-agent call Helm to DeployBundle: 17:47:05 ~ 17:47:06
time="2022-03-29T17:47:05Z" level=warning msg="DEV bd: name:mcc-rancher-monitoring DeployBundle BB B, notify to fleet-agent, last update time:2022-03-29T15:05:49Z, cur release:cattle-monitoring-system/rancher-monitoring:14, cur deployID:s-3037063ddd777fc28a3f1c7cba6f6d98748123942a7f6da3c4c921dbca782:aa7ef45dce9483e766c3d3fb589035b1b3fe1e0941aa65016dd7ee8208b0a3db"
time="2022-03-29T17:47:06Z" level=warning msg="DEV bd: name:mcc-rancher-monitoring DeployBundle BB E, last update time:2022-03-29T15:05:49Z, new release:cattle-monitoring-system/rancher-monitoring:14, == cur release?:true, new deployID:s-3037063ddd777fc28a3f1c7cba6f6d98748123942a7f6da3c4c921dbca782:aa7ef45dce9483e766c3d3fb589035b1b3fe1e0941aa65016dd7ee8208b0a3db, == cur deployID?:true"

Error messages from fleet-agent/Helm, the real time result of the on-going upgrade. It first reports "rancher-monitoring-grafana [progressing] Deployment does not have minimum availability", when grafana error is gone,  it then reports "rancher-monitoring-admission modified".
It is not that the second error happened later. The fleet-agent monitor-bundle exits loop when first error is found.
time="2022-03-29T17:47:03Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-29T17:47:07Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-29T17:47:11Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-29T17:47:14Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-29T17:47:17Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-29T17:47:21Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-29T17:47:24Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-29T17:47:27Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-29T17:47:30Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-29T17:47:33Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-29T17:47:36Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-29T17:47:40Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-29T17:47:43Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-29T17:47:46Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-29T17:47:49Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-29T17:47:52Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-29T17:47:56Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-29T17:47:59Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-29T17:48:02Z" level=error msg="bundle mcc-rancher-monitoring: deployment.apps cattle-monitoring-system/rancher-monitoring-grafana [progressing] Deployment does not have minimum availability., Available: 0/1"
time="2022-03-29T17:48:06Z" level=error msg="bundle mcc-rancher-monitoring: mutatingwebhookconfiguration.admissionregistration.k8s.io rancher-monitoring-admission modified {\"webhooks\":[{\"admissionReviewVersions\":[\"v1\",\"v1beta1\"],\"clientConfig\":{\"caBundle\":\"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJkVENDQVJ1Z0F3SUJBZ0lRZW5PY0t3WWZSeG1EMVo1MFpLTUR1REFLQmdncWhrak9QUVFEQWpBUE1RMHcKQ3dZRFZRUUtFd1J1YVd3eE1DQVhEVEl5TURNeU56RXdNVGt5TkZvWUR6SXhNakl3TXpBek1UQXhPVEkwV2pBUApNUTB3Q3dZRFZRUUtFd1J1YVd3eE1Ga3dFd1lIS29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRXNPSnc4T0pXCm9ZK1RBQ1RRWTZFSnZFUjV0TGxIZlN3RmZHOWtPT3BpQyt6MzNkN2g3Qk9pSUt6bUQ5bEtnUzlKU3NkbXl5eFYKbG9ObHpxWUJwclZiL3FOWE1GVXdEZ1lEVlIwUEFRSC9CQVFEQWdJRU1CTUdBMVVkSlFRTU1Bb0dDQ3NHQVFVRgpCd01CTUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3SFFZRFZSME9CQllFRlBOd2k1bGZ6SDJDY2F4cVZSSjB0R0laCkduUUlNQW9HQ0NxR1NNNDlCQU1DQTBnQU1FVUNJUUN5M3dGK09lemV2ZElvWGZ2MFErcm5sVXNpcGhqY2k1aFQKREU1MVhiZmZOd0lnTEZiRFFtNXpWd3U4M0wyVWVLWGRKZkNWUnhJOXpoUlFvMTdvdlVsRDg3ND0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=\",\"service\":{\"name\":\"rancher-monitoring-operator\",\"namespace\":\"cattle-monitoring-system\",\"path\":\"/admission-prometheusrules/mutate\",\"port\":443}},\"failurePolicy\":\"Ignore\",\"matchPolicy\":\"Equivalent\",\"name\":\"prometheusrulemutate.monitoring.coreos.com\",\"namespaceSelector\":{},\"objectSelector\":{},\"reinvocationPolicy\":\"Never\",\"rules\":[{\"apiGroups\":[\"monitoring.coreos.com\"],\"apiVersions\":[\"*\"],\"operations\":[\"CREATE\",\"UPDATE\"],\"resources\":[\"prometheusrules\"],\"scope\":\"*\"}],\"sideEffects\":\"None\",\"timeoutSeconds\":10}]}"

Summary:
When fleet-agent/Helm upgrades mcc-rancher-monitoring, it expects the rancher-monitoring-admission generations is 31 here, but it is updated to 32, which brings the error message.
Who does the second time updating of  rancher-monitoring-admission following Helm? TBD

Update:
POD cattle-monitoring-system/prometheus-rancher-monitoring-prometheus-0 is re-created even in single-node Harvester cluster, after the rebooting of cluster.  It is related to PVC, details are under investigation.
prometheus-0, grafana are re-created, notice the AGE.

kubelet log explains:
I0414 12:56:38.460325    2021 operation_generator.go:617] MountVolume.MountDevice succeeded for volume "pvc-09e84c10-33ab-4e74-9a31-0373b3cf97e6" (UniqueName: "kubernetes.io/csi/driver.longhorn.io^pvc-09e84c10-33ab-4e74-9a31-0373b3cf97e6") pod "prometheus-rancher-monitoring-prometheus-0" (UID: "35d51fd3-c88d-4750-b569-1aa443bc6885") device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-09e84c10-33ab-4e74-9a31-0373b3cf97e6/globalmount"

E0414 12:56:38.899544    2021 kuberuntime_manager.go:864] init container &Container{Name:init-config-reloader,Image:rancher/mirrored-prometheus-operator-prometheus-config-reloader:v0.50.0,Command:[/bin/prometheus-config-reloader],Args:[--watch-interval=0 --listen-address=:8080 --config-file=/etc/prometheus/config/prometheus.yaml.gz --config-envsubst-file=/etc/prometheus/config_out/prometheus.env.yaml --watched-dir=/etc/prometheus/rules/prometheus-rancher-monitoring-prometheus-rulefiles-0],WorkingDir:,Ports:[]ContainerPort{ContainerPort{Name:reloader-web,HostPort:0,ContainerPort:8080,Protocol:TCP,HostIP:,},},Env:[]EnvVar{EnvVar{Name:POD_NAME,Value:,ValueFrom:&EnvVarSource{FieldRef:&ObjectFieldSelector{APIVersion:v1,FieldPath:metadata.name,},ResourceFieldRef:nil,ConfigMapKeyRef:nil,SecretKeyRef:nil,},},EnvVar{Name:SHARD,Value:0,ValueFrom:nil,},},Resources:ResourceRequirements{Limits:ResourceList{cpu: {{100 -3} {<nil>} 100m DecimalSI},memory: {{52428800 0} {<nil>} 50Mi BinarySI},},Requests:ResourceList{cpu: {{100 -3} {<nil>} 100m DecimalSI},memory: {{52428800 0} {<nil>} 50Mi BinarySI},},},VolumeMounts:[]VolumeMount{VolumeMount{Name:config,ReadOnly:false,MountPath:/etc/prometheus/config,SubPath:,MountPropagation:nil,SubPathExpr:,},VolumeMount{Name:config-out,ReadOnly:false,MountPath:/etc/prometheus/config_out,SubPath:,MountPropagation:nil,SubPathExpr:,},VolumeMount{Name:prometheus-rancher-monitoring-prometheus-rulefiles-0,ReadOnly:false,MountPath:/etc/prometheus/rules/prometheus-rancher-monitoring-prometheus-rulefiles-0,SubPath:,MountPropagation:nil,SubPathExpr:,},VolumeMount{Name:kube-api-access-gcqhp,ReadOnly:true,MountPath:/var/run/secrets/kubernetes.io/serviceaccount,SubPath:,MountPropagation:nil,SubPathExpr:,},},LivenessProbe:nil,ReadinessProbe:nil,Lifecycle:nil,TerminationMessagePath:/dev/termination-log,ImagePullPolicy:IfNotPresent,SecurityContext:nil,Stdin:false,StdinOnce:false,TTY:false,EnvFrom:[]EnvFromSource{},TerminationMessagePolicy:FallbackToLogsOnError,VolumeDevices:[]VolumeDevice{},StartupProbe:nil,} start failed in pod prometheus-rancher-monitoring-prometheus-0_cattle-monitoring-system(35d51fd3-c88d-4750-b569-1aa443bc6885): CreateContainerConfigError: cannot find volume "config" to mount into container "init-config-reloader"

E0414 12:56:38.899570    2021 pod_workers.go:190] "Error syncing pod, skipping" err="failed to \"StartContainer\" for \"init-config-reloader\" with CreateContainerConfigError: \"cannot find volume \\\"config\\\" to mount into container \\\"init-config-reloader\\\"\"" pod="cattle-monitoring-system/prometheus-rancher-monitoring-prometheus-0" podUID=35d51fd3-c88d-4750-b569-1aa443bc6885
I0414 12:56:47.665327    2021 request.go:668] Waited for 1.189828582s due to client-side throttling, not priority and fairness, request: GET:https://<IP_ADDRESS>:6443/api/v1/namespaces/cattle-monitoring-system/persistentvolumeclaims/prometheus-rancher-monitoring-prometheus-db-prometheus-rancher-monitoring-prometheus-0

I0414 12:56:48.153101    2021 reconciler.go:224] "operationExecutor.VerifyControllerAttachedVolume started for volume \"config-out\" (UniqueName: \"kubernetes.io/empty-dir/2778c627-0121-4822-ad30-eaec637c13fb-config-out\") pod \"prometheus-rancher-monitoring-prometheus-0\" (UID: \"2778c627-0121-4822-ad30-eaec637c13fb\") "

pod="cattle-monitoring-system/prometheus-rancher-monitoring-prometheus-0"
podUID changed from 35d51fd3-c88d-4750-b569-1aa443bc6885 to
"prometheus-rancher-monitoring-prometheus-0" (UID: "2778c627-0121-4822-ad30-eaec637c13fb

Update:  (During a cluster rebooting, the POD prometheus-rancher-monitoring-prometheus-0 is re-created)
The root cause is narrowed down to 2 possibilities:
A. LH CSI driver is a bie slow to be registerted, but the POD prometheus-rancher-monitoring-prometheus-0 needs those LH mounted volumes, kubelet/kube-controller-manager/... deletes the POD actively and restart a new POD to retry.   The restarted POD will run OK as the CSI driver is ready then.
Will try to slow down the POD starting, e.g. use InitContainers to delay.
B. When rebooting, there is a HELM upgrade of mcc-harvester, which may causes the prometheus-rancher-monitoring-prometheus-0 POD to be deleted, created.  But the statefulset prometheus-rancher-monitoring-prometheus is not changed (generation is same) after upgrading, which is the owner of POD prometheus-o.
Will try to hold the HELM upgrade.
some helpful logs:
kubelet.log:I0427 13:23:28.983200    1941 event.go:291] "Event occurred" object="cattle-monitoring-system/prometheus-rancher-monitoring-prometheus-0" kind="Pod" apiVersion="v1" type="Warning" reason="FailedMount" message="MountVolume.MountDevice failed for volume \"pvc-94466e07-0050-4539-888d-f335257aba93\" : kubernetes.io/csi: attacher.MountDevice failed to create newCsiDriverClient: driver name driver.longhorn.io not found in the list of registered CSI drivers"
kubelet.log:I0427 13:23:59.678423    1941 status_manager.go:576] "Pod was deleted and then recreated, skipping status update" pod="cattle-monitoring-system/prometheus-rancher-monitoring-prometheus-0" oldPodUID=a8d0e804-b15f-488d-803c-b95d428de529 podUID=88194dfd-c4b0-42ac-ae92-ec9f0bd4ea2c
kubelet.log:I0427 13:24:08.415385    1941 event.go:291] "Event occurred" object="cattle-monitoring-system/prometheus-rancher-monitoring-prometheus-0" kind="Pod" apiVersion="v1" type="Warning" reason="FailedMount" message="Unable to attach or mount volumes: unmounted volumes=[tls-assets config kube-api-access-27tcw prometheus-rancher-monitoring-prometheus-db prometheus-nginx nginx-home config-out prometheus-rancher-monitoring-prometheus-rulefiles-0 web-config], unattached volumes=[tls-assets config kube-api-access-27tcw prometheus-rancher-monitoring-prometheus-db prometheus-nginx nginx-home config-out prometheus-rancher-monitoring-prometheus-rulefiles-0 web-config]: timed out waiting for the condition"
A partial similar issue for reference:
https://github.com/rook/rook/issues/2953

Summary:
For now, the rancher-monitoring has following issues regarding this topic:
(1) The POD replacement of rancher-monitoring after cluster rebooting, is caused by https://github.com/longhorn/longhorn/issues/3941, and may have no (easy) solution at the moment.
(2) The replaced rancher-monitoring POD can be scheduled to any NODE of the cluster, if the NODE is ( accidently ) down, then the rancher monitoring will be not usable, the related POD stucks in "Terminating", user need to delete POD manually
https://github.com/harvester/harvester/issues/2243
The workaround will be documented.
BTW: due to restrictions, rancher-monitoring StatuefulSet has only 1 replicas, which is vulnerable to be single-point-failure.
    "kind": "StatefulSet",
        "name": "prometheus-rancher-monitoring-prometheus",
        "replicas": 1,

(3) When (2) happens, fleet-agent is very busy, needs to be solved in
https://github.com/rancher/fleet/issues/760 , and re-valdated in:  https://github.com/harvester/harvester/issues/1893

Why the prometheus and grafana POD are deleted when rebooting?
Happend to find it in https://github.com/longhorn/longhorn/issues/4302
When Harvester cluster rebooting, LH set RemountRequestedAt in ReconcileVolumeState, which leads to handlePodDeletionIfVolumeRequestRemount calls kc.kubeClient.CoreV1().Pods(pod.Namespace).Delete
When rebooting, kubelet wait CSI to mount the PVC to start the POD, but LH consider that it just picked up the PVCs, and the best/feasible way is to delete the POD and let k8s replace the POD,  it is a transferred remount.
@PhanLe1010 @joshimoo @yasker @guangbochen @innobead
Technically speaking, are there better ways for LH to remount the PVC instead of delete POD from internal ? thanks.

@w13915984028
Like you mentioned, when a Longhorn volume is crashed (turn off the node where engine is running on, the instance-manager-e-xxx of the engine process is crashed, ...) then Longhorn delete the workload pod so Kubernetes can try the whole flow: unmount -> detach -> attach -> mount -> start the pod again.
There is not an easy wait to remount the PVC without restarting the container thus restarting the pod.
Is there a problem with this design? Sorry i am not very sure about the current issue after reading the above thread

@PhanLe1010
When Harvester is rebooting, the prometheus, grafana will takes about 90+ additional seconds to be ready than other PODs.  As they will be deleted until LH decides to, and then there is a long path as you said unmount -> detach -> attach -> mount -> start .
If the user login into Harvester dashboard asap, they will get a blank page of grafana metrics, until those PODs are ready.
I am not fully sure where the time is used, but roughly 90+ seconds seems long,  there may be something to optimize to speed up.

In fact, all VM/POD with PVC, they will be deleted and replaced when Harvester is rebooting.
For massive deployment, I am not sure we have additional strategy like: the newly replaced VM/POD should select the NODE which has the related PVC replica.

Following log shows the GAP.
LH manager POD: 2022-07-27T13:50:49 deletes the POD, it sets 30s as gracetime
time="2022-07-27T13:50:49Z" level=info msg="Deleted pod
 prometheus-rancher-monitoring-prometheus-0
so that Kubernetes will handle remounting volume pvc-076c7e6b-dd8c-4e92-b1ae-33fd6a262584" controller=longhorn-kubernetes-pod node=harv1

prometheus POD: 2022-07-27T13:52:20.534  main.go start to run
harv1:~ # kk logs -n cattle-monitoring-system prometheus-rancher-monitoring-prometheus-0 | more
level=info ts=2022-07-27T13:52:20.534Z caller=main.go:443

msg="Starting Prometheus" version="(version=2.28.1, branch=HEAD, revision=b0944590a1c9a6b35dc5a696869f75f422b107a1)"
level=info ts=2022-07-27T13:52:20.534Z caller=main.go:448 build_context="(go=go1.16.5, user=root@2915dd495090, date=20210701-15:20:10)"

@PhanLe1010
Back to this issue https://github.com/harvester/harvester/issues/2013 itself:
As prometheus has only 1 replica of POD to deply, in a multi-NODE Harvester cluster, each rebooting of cluster, will see that the promethes POD floats to different NODE.  That's the naming of this issue unstable deployment of POD prometheus-0, until yesterday I knew exactly who deletes the POD.
Again, when such strategy meets massive deployment, it will be a concern. @guangbochen

Meanwhile we found that, https://github.com/harvester/harvester/issues/2243,  when the prometheus host NODE is accidently down, the POD is not automatically recovered, it needs manually force deleting.
In longhorn-manager's code, I found following:
(kc *KubernetesPodController) handlePodDeletionIfNodeDown, but it needs conditions
// Force delete a pod when all of the below conditions are meet:
// 1. NodeDownPodDeletionPolicy is different than DoNothing
// 2. pod belongs to a StatefulSet/Deployment depend on NodeDownPodDeletionPolicy
// 3. node containing the pod is down
// 4. the pod is terminating and the DeletionTimestamp has passed.
// 5. pod has a PV with provisioner driver.longhorn.io

maybe we can set NodeDownPodDeletionPolicy of promethes, grafana, try to utilize LH's ability to recover from #2243.

An roughly timeline of a single-node Harvester cluster rebooting:
+ 0 minutes  OS power on:
+ 4 minutes  POD LH instance-manager starts
+ 6 minutes  POD guest vm vm1 starts (with PVC, 2Gb)
+ 7 minutes  POD prometheus starts (with PVC 50Gb)

uptime (30 minutes)
 10:31:27  up   0:30,  1 user,  load average: 2.39, 1.72, 2.09

Following PODs, the AGE is not 8d, are PODS that are replaced after rebooting
NAMESPACE                   NAME                                                     READY   STATUS      RESTARTS   AGE
..
cattle-fleet-system         fleet-controller-5746685958-dd7qx                        1/1     Running     20         8d
..
cattle-monitoring-system    alertmanager-rancher-monitoring-alertmanager-0           2/2     Running     0          23m  -- PVC backed
cattle-monitoring-system    prometheus-rancher-monitoring-prometheus-0               3/3     Running     0          23m  -- PVC backed
cattle-monitoring-system    rancher-monitoring-grafana-d9c56d79b-6wqqr               3/3     Running     0          24m  -- PVC backed
..
default                     virt-launcher-vm1-bhfrf                                  1/1     Running     0          24m  -- PVC backed
..

longhorn-system             backing-image-manager-2a7c-5018                          1/1     Running     0          25m
..
longhorn-system             instance-manager-e-ec7fd683                              1/1     Running     0          26m
longhorn-system             instance-manager-r-3d868255                              1/1     Running     0          26m
..
longhorn-system             longhorn-manager-lxfh5                                   1/1     Running     22         8d
..


Mintapi fails when installing on python2.7 due to dependencies requiring python>=3.6

When running "pip install mintapi" the following error occurs:
Collecting oathtool (from mintapi)
Could not find a version that satisfies the requirement oathtool (from mintapi) (from versions: )
No matching distribution found for oathtool (from mintapi)

This is likely a internet connection issue or something like that from pip
not being able to query PyPI. You'll probably be able to find the cause of
the issue from somewhere else in the error stack trace.
On Sun, Nov 7, 2021, 11:48 AM matt199x 'notifications at github.com'
<jaron-github+reply+ADGNKUFL4BVDG5R7K36JDSV7SPZH3EVBNHHD4ZIILA=
@.***> wrote:

When running "pip install mintapi" the following error occurs:
Collecting oathtool (from mintapi)
Could not find a version that satisfies the requirement oathtool (from
mintapi) (from versions: )
No matching distribution found for oathtool (from mintapi)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mintapi/mintapi/issues/334, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADGNKUFPQYIKPI2MXWCIJ43UK23X3ANCNFSM5HRBZRKA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

I have been able to install several other items using "pip install" today. I tried on another raspberry bi and it has the same issue.

Is there a full stack trace you can paste as per the bug report template?

running "sudo pip3 install mintapi" instead of "pip install mintapi" fixed the issue.

I don't think this is a mintapi issue but rather something about your
python setup. I was just able to install mintapi on a raspberry pi without
sudo or any other hiccups. The full stack trace should lead you to what the
issue is.
On Sun, Nov 7, 2021, 7:03 PM matt199x 'notifications at github.com'
<jaron-github+reply+ADGNKUEX73MRKLVVPCJCFGN7SRMGLEVBNHHD4ZIILA=
@.***> wrote:

running "sudo pip3 install mintapi" instead of "pip install mintapi" fixed
the issue.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mintapi/mintapi/issues/334#issuecomment-962725213,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADGNKUCELQXG6UMMRLU6NH3UK4OWLANCNFSM5HRBZRKA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

pi@raspberrypi:~ $ pip install mintapi Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple Collecting mintapi   Downloading https://files.pythonhosted.org/packages/f6/94/6542c1a3d82ad599aa2bfcea4cfa10c84e99bd0ace2a830888a9993d8c84/mintapi-1.54.tar.gz Collecting future (from mintapi)   Downloading https://files.pythonhosted.org/packages/45/0b/38b06fd9b92dc2b68d58b75f900e97884c45bedd2ff83203d933cf5851c9/future-0.18.2.tar.gz (829kB)     100% |████████████████████████████████| 829kB 324kB/s  Requirement already satisfied: mock in /usr/lib/python2.7/dist-packages (from mintapi) (2.0.0) Collecting oathtool (from mintapi)   Could not find a version that satisfies the requirement oathtool (from mintapi) (from versions: ) No matching distribution found for oathtool (from mintapi) pi@raspberrypi:~ $
This was attempted on a 3b, 4 and a fresh install of Raspberry Pi OS on a 3B+. All with the same error.

Ah, that makes sense. pip is using python2.7 while when adding pip3 it is using python3. Your command switch fixes it by changing python versions, not by using sudo (which you should never do by the way. PyPI has had security vulnerabilities before and there is no need to run as sudo. If want pip to install at the user level, use the --user flag).
The reason your initial pip install command failed is because oathtool requires python>=3.6. We don't put a python version requirement which is why it initially worked for mintapi but failed when installing the oathtool dependency.
A fix for this would be to require python3.6. We should also remove the compatibility code.

The readme should be updated to remove where it says "ensure you have python 2"


Initialize the pipeline task scheduler by default

What problem does this PR solve?
Issue Number: ref #6518
Problem Summary:
What is changed and how it works?

Initialize the pipeline task scheduler by default, and then enable_pipeline and enforce_enable_pipeline can take effect immediately without restarting the tiflash process.
The three groups of threads in pipeline task scheduler(WaitReactor, CPU/IO Task Thread Pool) are blocked when no tasks are submitted, the cpu utilization rates are 0, and the default total number of threads is 1 + 2 * cpu core num, so the impact of the default Initializing is small.

from https://github.com/pingcap/tiflash/pull/7584
support set enable_pipeline from tidb, related to https://github.com/pingcap/tidb/pull/44467

Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Documentation

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Changes MySQL compatibility

Release note

None

/rebuild

/run-all-tests

/assign

/merge

/approve

/run-integration-test

/run-integration-test

/run-integration-test

/run-integration-test

/run-integration-test

/run-integration-test

/run-integration-test


Save a project's open scenes in editor between sessions

This is a feature request related to #20994, but was a bit off-topic to post in that thread, so I made a separate issue for it.
Editor folding defaults sound like they are currently saved in project.godot.  One quality-of-life improvement similar to saving the folding defaults would be to save the tabs for open scene views in a project so that they can be reloaded automatically the next time the project is opened.  This would probably have similar issues with version control compared to folding defaults if implemented in a similar fashion.

The option exists already:

much appreciated; I had no idea.  (I tried searching for a dupe issue first, I promise!)


FLAKE: //test/core/end2end:h2_http_proxy_nosec_test@graceful_server_shutdown[darwin-opt]

https://source.cloud.google.com/results/invocations/4d9cf363-61d7-4cd5-84b0-68529befdd89/targets/%2F%2Ftest%2Fcore%2Fend2end:h2_http_proxy_nosec_test@graceful_server_shutdown/log
exec ${PAGER:-/usr/bin/less} "$0" || exit 1
Executing tests from //test/core/end2end:h2_http_proxy_nosec_test@graceful_server_shutdown
-----------------------------------------------------------------------------
D0201 00:10:09.414726000<PHONE_NUMBER>12384 test_config.cc:385]           test slowdown factor: sanitizer=1, fixture=1, poller=1, total=1
D0201 00:10:09.416119000<PHONE_NUMBER>12384 ev_posix.cc:174]              Using polling engine: poll
D0201 00:10:09.416238000<PHONE_NUMBER>12384 dns_resolver_ares.cc:503]     Using ares dns resolver
I0201 00:10:09.416370000<PHONE_NUMBER>12384 graceful_server_shutdown.cc:37] Running test: test_early_server_shutdown_finishes_inflight_calls/chttp2/fullstack
I0201 00:10:09.416393000<PHONE_NUMBER>12384 http_proxy_fixture.cc:616]    Proxy address: localhost:7660
D0201 00:10:09.419749000<PHONE_NUMBER>20288 http_proxy_fixture.cc:464]    on_read_request_done: 0x7fae7f800600 "No Error"
I0201 00:10:09.419775000<PHONE_NUMBER>12384 http_connect_handshaker.cc:328] Connecting to server localhost:7659 via HTTP proxy ipv6:[::1]:7660
D0201 00:10:09.420391000<PHONE_NUMBER>20288 http_proxy_fixture.cc:464]    on_read_request_done: 0x7fae7f804800 "No Error"
I0201 00:10:09.421184000<PHONE_NUMBER>12384 chttp2_transport.cc:1771]     ipv6:[::1]:63201: Sending goaway err={"created":"@1580515809.421140000","description":"Server shutdown","file":"src/core/lib/surface/server.cc","file_line":323,"grpc_status":0}
I0201 00:10:09.421226000<PHONE_NUMBER>12384 chttp2_transport.cc:1771]     ipv6:[::1]:63202: Sending goaway err={"created":"@1580515809.421141000","description":"Server shutdown","file":"src/core/lib/surface/server.cc","file_line":323,"grpc_status":0}
I0201 00:10:09.421305000<PHONE_NUMBER>20288 http_proxy_fixture.cc:178]    HTTP proxy server read: {"created":"@1580515809.421294000","description":"Socket closed","fd":17,"file":"src/core/lib/iomgr/tcp_posix.cc","file_line":781,"grpc_status":14,"target_address":"ipv6:[::1]:7659"}
I0201 00:10:09.421347000<PHONE_NUMBER>12384 subchannel.cc:1055]           New connected subchannel at 0x7fae7cc0d930 for subchannel 0x7fae7e302c60
I0201 00:10:09.421347000<PHONE_NUMBER>20288 http_proxy_fixture.cc:178]    HTTP proxy client read: {"created":"@1580515809.421335000","description":"FD shutdown","file":"src/core/lib/iomgr/ev_poll_posix.cc","file_line":491,"grpc_status":14,"referenced_errors":[{"created":"@1580515809.421294000","description":"Socket closed","fd":17,"file":"src/core/lib/iomgr/tcp_posix.cc","file_line":781,"grpc_status":14,"target_address":"ipv6:[::1]:7659"}]}
D0201 00:10:09.421387000<PHONE_NUMBER>20288 http_proxy_fixture.cc:131]    endpoints: 0x7fae7e100fe0 0x7fae7e3064f0
E0201 00:10:09.421500000<PHONE_NUMBER>12384 cq_verifier.cc:299]           unexpected event (expected nothing): OP_COMPLETE: tag:0x1 OK

*******************************
Caught signal SIGABRT
  no backtrace
/Volumes/BuildData/tmpfs/tmp/bazel/a002d9727939acebf422134be2d181ab/sandbox/darwin-sandbox/4126/execroot/com_github_grpc_grpc/bazel-out/darwin-opt/bin/test/core/end2end/h2_http_proxy_nosec_test@graceful_server_shutdown.runfiles/com_github_grpc_grpc/test/core/end2end/h2_http_proxy_nosec_test@graceful_server_shutdown: line 22: 19633 Abort trap: 6           "$1" "$2"

I don't see a failure since 23rd March. Closing this. (Probably fixed by https://github.com/grpc/grpc/pull/22420 )


Error "Unable to parse response body into JSON: 4" when sending request

Hello, I think I'm doing everything right:
$gateway = Omnipay::create("Coinbase");
$gateway->initialize(['apiKey' => 'my_api_v2_key_with_all_perm', 'secret' => 'my_api_secret', 'accountId' => 'my_acc_id']);
$transaction = $gateway->purchase(['amount' => 10, 'currency' => 'USD', 'description' => 'something']);
$response = $transaction->send();

but getting an error message on send():

Unableto parse response body into JSON: 4

Whats going on? I've managed to check that this error is caused by empty (NULL) json returned by guzzle. But what causes it?

+1, I also ran into this in the InvoicePlane implementation.
https://community.invoiceplane.com/t/topic/4572/6?u=epec

@konrad-ch did you ever get to the bottom of this? I'm having the same issue


Fix spelling of “orthorhombic” Fixes #354

Fixes https://github.com/chemfiles/chemfiles/issues/354

By the way, since you may know that: do you have any idea why GCC 5.5 is so slow on OS X 10.13? (except because we are using old releases of everything ^^) It takes 30min to run the build, compared to 7min for clang on OS X or ~8min for gcc on Ubuntu 16.04.
Could it be related to the flood of section "__textcoal_nt" is deprecated warnings we get from the linker/assembler?

 I'll look into this, and potentially update the CI to something more recent.

Travis is happy at https://travis-ci.org/github/chemfiles/chemfiles/builds/710787958, looks like the github UI did not update.

why GCC 5.5 is so slow on OS X 10.13?

There is no reason it should. But seriously, don't use it.

I'm trying to stay conservative regarding which compiler version are supported (we still support GCC 4.8.5 since that's the default in CentOS 7, which will EOL in 2024), but we could update on macOS since way less people are using ancient GCC there. I'll try to look up version statistics.


FIX expose Kernel explainer

closes #2451
This PR exposes the Kernel method to the new Explainer.

Thanks for starting this! If you run into issues with the current test failures let me know.


Is LoRaNow.loop() necessary during sleeping

Dear Ricaun,
I am learning to use your library.
I have a question about the LoRaNow.loop() method and the State Machine.
Can I sleep de uC in the onSleep callback for a long time (i.e. 15 minutes) without calling LoRaNow.loop()?
Besides I found this small typo in the API.

Kind regards from Madrid

Another question.
When is this state enabled?

I am learning to use your library.

👍

I have a question about the LoRaNow.loop() method and the State Machine.
Can I sleep de uC in the onSleep callback for a long time (i.e. 15 minutes) without calling LoRaNow.loop()?

We the onSleep callback you can put the uC on sleep mode forever if you want.
The idea of the onSleep callback is to make sure the node sends the payload and waits for some response, then go to sleep.

Besides I found this small typo in the API.

Opsss 😄

Another question.
When is this state enabled?

This state is not used, I create for the first version but never used.
I need to remove it.

Thank you very much ricaun and Happy 2020...


Unable to finetune T5 or BART

Thanks for sharing the code @Mandar-Sharma!
I tried finetuning T5 using python finetuneT5.py --model_name_or_path t5-small --output_dir T5Models --data_dir Datasets/. However, the script seems to only create the model and doesn't really train it. It would be great if you could please help with the training code snippet for finetuning T5 or BART.
Alternatively, it would be great if you could share the T5Models/T5Both.ckpt checkpoint file via a cloud storage platform.
Thanks and regards,
Sayan.

Hi @americast - thanks for reaching out! The script finetuneT5.py does train the model. Perhaps you are running this script on a recent version of the transformers/PyTorch library. Please try sticking to the exact versions of the libraries outline in requirements.txt. It should work.


TBS Added

So I run the tests with your scanner, and to be honest it's really slow.
Looking at your code, you are optimising for the wrong case.
You are using SIMD to try and compare multiple bytes at a given position (acting like memcmp), but 99% of the time, even just the first byte won't match.
You want to be using SIMD to compare multiple multiple positions at once (acting like memchr) instead.
mem::simd_scanner                |<PHONE_NUMBER> cycles =  0.217 cycles/byte |  1.00x
mem::boyer_moore_scanner         |<PHONE_NUMBER> cycles =  0.874 cycles/byte |  4.04x
Simple                           |<PHONE_NUMBER>7 cycles =  2.486 cycles/byte | 11.48x
DarthTon                         |<PHONE_NUMBER>9 cycles =  2.570 cycles/byte | 11.87x
CFX                              |<PHONE_NUMBER>2 cycles =  3.225 cycles/byte | 14.89x
TBS                              |<PHONE_NUMBER>8 cycles = 10.083 cycles/byte | 46.56x
Forza (Boyer-Moore Variant)      | failed
DarthTon v2                      | failed
mrexodia (horspool)              | failed

i see good, suggestion, i will add a case for that, also, the reason why it consume so much cycles, its because the type of overhead from data structures potentially, TBS thrives better in large scale setups, like multiple patterns + multiple targets + shared targets, batch scan likes setups

Regarding your comment

You are using SIMD to try and compare multiple bytes at a given position (acting like memcmp), but 99% of the time, even just the first byte won't match.
You want to be using SIMD to compare multiple multiple positions at once (acting like memchr) instead.

i would love to get more insight on what it exactly means, you correctly pointed the fact that the code is always checking for multiple bytes at once even if the first byte is wrong, which is valid case for improvement, but regarding the point of acting like memcmp vs acting like memchr, can you explain a bit more on it

Duration Bench
in the duration aspect of TBS searching is insanely fast, locally it outperforms all the other libraries as shown next:
FindPattern benchmark
Page size: 4096, allocating 64 pages (including 2 guard pages).
Running tests on 17 different implementations
===========
Running learn_more
Finding pattern 0 x 1024 took 943.973 ms.
Finding pattern 1 x 1024 took 1196.57 ms.
===========
Running learn_more v2
Finding pattern 0 x 1024 took 551.838 ms.
Finding pattern 1 x 1024 took 504.597 ms.
===========
Running fdsasdf
Finding pattern 0 x 1024 took 227.914 ms.
Finding pattern 1 x 1024 took 228.882 ms.
===========
Running DarthTon
Finding pattern 0 x 1024 took 398.162 ms.
Finding pattern 1 x 1024 took 425.736 ms.
===========
Running DarthTon v2
Finding pattern 0 x 1024 took 47.102 ms.
Finding pattern 1 x 1024 took 50.934 ms.
===========
Running Forza (Boyer-Moore Variant)
Finding pattern 0 x 1024 took 82.555 ms.
Finding pattern 1 x 1024 took 23.215 ms.
===========
Running Forza (SIMD With OpenMP)
Finding pattern 0 x 1024 took 25.226 ms.
Finding pattern 1 x 1024 took 25.937 ms.
===========
Running kokole
Finding pattern 0 x 1024 took 601.645 ms.
Finding pattern 1 x 1024 took 532.926 ms.
===========
Running mrexodia
Finding pattern 0 x 1024 took 1070.98 ms.
Finding pattern 1 x 1024 took 1041.12 ms.
===========
Running atom0s
Finding pattern 0 x 1024 took 428.373 ms.
Finding pattern 1 x 1024 took 432.73 ms.
===========
Running atom0s (mrexodia modification)
Finding pattern 0 x 1024 took 1706.57 ms.
Finding pattern 1 x 1024 took 1711.16 ms.
===========
Running mrexodia (horspool)
Finding pattern 0 x 1024 took 133.752 ms.
Failed to find pattern.
===========
Running dom1n1k_Patrick
Finding pattern 0 x 1024 took 524.371 ms.
Finding pattern 1 x 1024 took 535.93 ms.
===========
Running Michael
Finding pattern 0 x 1024 took 387.001 ms.
Finding pattern 1 x 1024 took 385.19 ms.
===========
Running superdoc1234
Finding pattern 0 x 1024 took 232.073 ms.
Finding pattern 1 x 1024 took 229.238 ms.
===========
Running stevemk14ebr
Finding pattern 0 x 1024 took 908.208 ms.
Finding pattern 1 x 1024 took 1099.22 ms.
===========
Running TBS
Finding pattern 0 x 1024 took 8.787 ms.
Finding pattern 1 x 1024 took 11.462 ms.
Done.

Duration Bench in the duration aspect of TBS searching is insanely fast, locally it outperforms all the other libraries as shown next:
FindPattern benchmark
Page size: 4096, allocating 64 pages (including 2 guard pages).
Running tests on 17 different implementations
===========
Running learn_more
Finding pattern 0 x 1024 took 943.973 ms.
Finding pattern 1 x 1024 took 1196.57 ms.
===========
Running learn_more v2
Finding pattern 0 x 1024 took 551.838 ms.
Finding pattern 1 x 1024 took 504.597 ms.
===========
Running fdsasdf
Finding pattern 0 x 1024 took 227.914 ms.
Finding pattern 1 x 1024 took 228.882 ms.
===========
Running DarthTon
Finding pattern 0 x 1024 took 398.162 ms.
Finding pattern 1 x 1024 took 425.736 ms.
===========
Running DarthTon v2
Finding pattern 0 x 1024 took 47.102 ms.
Finding pattern 1 x 1024 took 50.934 ms.
===========
Running Forza (Boyer-Moore Variant)
Finding pattern 0 x 1024 took 82.555 ms.
Finding pattern 1 x 1024 took 23.215 ms.
===========
Running Forza (SIMD With OpenMP)
Finding pattern 0 x 1024 took 25.226 ms.
Finding pattern 1 x 1024 took 25.937 ms.
===========
Running kokole
Finding pattern 0 x 1024 took 601.645 ms.
Finding pattern 1 x 1024 took 532.926 ms.
===========
Running mrexodia
Finding pattern 0 x 1024 took 1070.98 ms.
Finding pattern 1 x 1024 took 1041.12 ms.
===========
Running atom0s
Finding pattern 0 x 1024 took 428.373 ms.
Finding pattern 1 x 1024 took 432.73 ms.
===========
Running atom0s (mrexodia modification)
Finding pattern 0 x 1024 took 1706.57 ms.
Finding pattern 1 x 1024 took 1711.16 ms.
===========
Running mrexodia (horspool)
Finding pattern 0 x 1024 took 133.752 ms.
Failed to find pattern.
===========
Running dom1n1k_Patrick
Finding pattern 0 x 1024 took 524.371 ms.
Finding pattern 1 x 1024 took 535.93 ms.
===========
Running Michael
Finding pattern 0 x 1024 took 387.001 ms.
Finding pattern 1 x 1024 took 385.19 ms.
===========
Running superdoc1234
Finding pattern 0 x 1024 took 232.073 ms.
Finding pattern 1 x 1024 took 229.238 ms.
===========
Running stevemk14ebr
Finding pattern 0 x 1024 took 908.208 ms.
Finding pattern 1 x 1024 took 1099.22 ms.
===========
Running TBS
Finding pattern 0 x 1024 took 8.787 ms.
Finding pattern 1 x 1024 took 11.462 ms.
Done.

I think you need to clear the cache in runOne, since it does multiple iterations of each pattern

Regarding your comment

You are using SIMD to try and compare multiple bytes at a given position (acting like memcmp), but 99% of the time, even just the first byte won't match.
You want to be using SIMD to compare multiple multiple positions at once (acting like memchr) instead.

i would love to get more insight on what it exactly means, you correctly pointed the fact that the code is always checking for multiple bytes at once even if the first byte is wrong, which is valid case for improvement, but regarding the point of acting like memcmp vs acting like memchr, can you explain a bit more on it

Well let's say you load 16 bytes with SIMD. You could check if those bytes match 16 bytes of the pattern. That's like memcmp. If the data you are searching has lots of near-matches, then that might be useful.
But you are searching data where there is probably only 1 match. So most of the time even 1 byte won't match.
Instead, you could check if any of those 16 bytes match a specific byte of the pattern. That's like memchr. This can let you very quickly eliminate positions, ie if there are no matches in those 16 bytes, you've just eliminated 16 positions.

Instead, you could check if any of those 16 bytes match a specific byte of the pattern. That's like memchr

inline bool CompareWithMask(const UByte* chunk1, const UByte* chunk2, size_t len, const UByte* wildCardMask) {

  if ((chunk1[0] & ~wildCardMask[0]) != (chunk2[0] & ~wildCardMask[0]))
      return false;

  ...
}

this should techincly do the trick, and avoid all the extra 15 bytes check overhead.

I think you need to clear the cache in runOne, since it does multiple iterations of each pattern

you are correct in pointing that out. it looks like it actually under-perform the other libraries impls
Running TBS
Finding pattern 0 x 1024 took 1089.66 ms.
Finding pattern 1 x 1024 took 2129.22 ms.
Done.

mem::simd_scanner                |<PHONE_NUMBER> cycles =  0.217 cycles/byte |  1.00x
mem::boyer_moore_scanner         |<PHONE_NUMBER> cycles =  0.874 cycles/byte |  4.04x
Simple                           |<PHONE_NUMBER>7 cycles =  2.486 cycles/byte | 11.48x
DarthTon                         |<PHONE_NUMBER>9 cycles =  2.570 cycles/byte | 11.87x
CFX                              |<PHONE_NUMBER>2 cycles =  3.225 cycles/byte | 14.89x
TBS                              |<PHONE_NUMBER>8 cycles = 10.083 cycles/byte | 46.56x
Forza (Boyer-Moore Variant)      | failed
DarthTon v2                      | failed
mrexodia (horspool)              | failed

mem::simd_scanner                |<PHONE_NUMBER> cycles =  0.324 cycles/byte |  1.00x | 0 failed
mem::boyer_moore_scanner         |<PHONE_NUMBER> cycles =  1.281 cycles/byte |  3.95x | 0 failed
TBS                              |<PHONE_NUMBER>3 cycles =  2.985 cycles/byte |  9.20x | 0 failed
DarthTon                         |<PHONE_NUMBER>0 cycles =  3.871 cycles/byte | 11.94x | 0 failed
CFX                              |<PHONE_NUMBER>2 cycles =  5.426 cycles/byte | 16.73x | 0 failed
Simple                           |<PHONE_NUMBER>6 cycles =  6.100 cycles/byte | 18.81x | 0 failed
Forza (Boyer-Moore Variant)      |<PHONE_NUMBER> cycles =  0.417 cycles/byte |  1.29x | 201 failed
DarthTon v2                      |<PHONE_NUMBER> cycles =  0.585 cycles/byte |  1.80x | 73 failed
mrexodia (horspool)              |<PHONE_NUMBER> cycles =  0.935 cycles/byte |  2.88x | 197 failed

with the overhead removed, ranking third in the bench

mem::simd_scanner                |<PHONE_NUMBER> cycles =  0.354 cycles/byte |  1.00x | 0 failed
TBS                              |<PHONE_NUMBER> cycles =  0.480 cycles/byte |  1.35x | 0 failed
mem::boyer_moore_scanner         |<PHONE_NUMBER> cycles =  1.205 cycles/byte |  3.40x | 0 failed
DarthTon                         |<PHONE_NUMBER>0 cycles =  3.718 cycles/byte | 10.49x | 0 failed
Simple                           |<PHONE_NUMBER>4 cycles =  4.093 cycles/byte | 11.55x | 0 failed
CFX                              |<PHONE_NUMBER>7 cycles =  5.081 cycles/byte | 14.34x | 0 failed
Forza (Boyer-Moore Variant)      |<PHONE_NUMBER> cycles =  0.440 cycles/byte |  1.24x | 215 failed
DarthTon v2                      |<PHONE_NUMBER> cycles =  0.512 cycles/byte |  1.44x | 73 failed
mrexodia (horspool)              |<PHONE_NUMBER> cycles =  0.774 cycles/byte |  2.19x | 207 failed

Running TBS
Finding pattern 0 x 1024 took 51.185 ms.
Finding pattern 1 x 1024 took 49.249 ms.
Done.

@0x1F9F1 Take a look

mem::simd_scanner                |<PHONE_NUMBER> cycles =  0.354 cycles/byte |  1.00x | 0 failed
TBS                              |<PHONE_NUMBER> cycles =  0.480 cycles/byte |  1.35x | 0 failed
mem::boyer_moore_scanner         |<PHONE_NUMBER> cycles =  1.205 cycles/byte |  3.40x | 0 failed
DarthTon                         |<PHONE_NUMBER>0 cycles =  3.718 cycles/byte | 10.49x | 0 failed
Simple                           |<PHONE_NUMBER>4 cycles =  4.093 cycles/byte | 11.55x | 0 failed
CFX                              |<PHONE_NUMBER>7 cycles =  5.081 cycles/byte | 14.34x | 0 failed
Forza (Boyer-Moore Variant)      |<PHONE_NUMBER> cycles =  0.440 cycles/byte |  1.24x | 215 failed
DarthTon v2                      |<PHONE_NUMBER> cycles =  0.512 cycles/byte |  1.44x | 73 failed
mrexodia (horspool)              |<PHONE_NUMBER> cycles =  0.774 cycles/byte |  2.19x | 207 failed

Running TBS
Finding pattern 0 x 1024 took 51.185 ms.
Finding pattern 1 x 1024 took 49.249 ms.
Done.

@0x1F9F1 Take a look

Looking a lot better :)
Let me know when you are finished tweaking it and ready to merge.

ready to merge.

Finals Revisions Completed, Ready to merge...


Continue to use the deprecated node external id through 1.10

Resolves #534

Coverage remained the same at 23.233% when pulling<PHONE_NUMBER>caa07d81e341cf9bb1ed175c86c6b1 on 534-externalid into b3024f88de42bc9074e76afe951712212720d528 on master.


Allow custom losses to have mismatching target shapes.

In response to these comments, this PR partly reverts the changes made in https://github.com/fchollet/keras/pull/8056 . That PR had the unintended side effect of forcing target blobs to have the same shape as output blobs for custom loss functions, which is currently frequently used as a workaround (discussion).

Thank you. Do you have any idea if a v2.1.2 is to be released soon? This bug was preventing me from using 2.1.0+.


#9 : Prepare for Backend Integration

Description

Set up environment variables (use .sample.env) and prepare API utility functions for connecting to the backend.
Document the API schema expected and prepare mock functions to simulate API calls.
Ensure that components are ready to integrate with real-time data without major refactoring.

@Sweetdevil144  i would like to work on this issue

I'd prefer you working on rest of Issues before winding up this one


Auto-delete and exclusive queues

It would be a great addition to Mela if it had the option to configure consumer-declared queues to be exclusive and/or auto-delete.
To avoid potential data loss and conflicts, perhaps this should only be allowed if the queue which the consumer is attempting to create does not already exist. Alternatively, this may apply only to server-named queues as per official RabbitMQ guidelines (https://www.rabbitmq.com/queues.html#properties)

Implemented in >v1.1, but not documented yet.