Remove supportOldDangerousPassword support

Fixes #771
Description
I removed supportOldDangerousPassword. And also there is no usage of verifyDanger() anymore I also deleted it. I didn't update the docs because docs already have the information about deprecation for version 1.0.0 release.
Checklist:

[ ] Securely signed commits
[ ] Component(s) with PHPDoc blocks, only if necessary or adds value
[ ] Unit testing, with >80% coverage
[ ] User guide updated
[ ] Conforms to style guide

@omerimzali,
Please fix phpStan by changing below to 8:
https://github.com/codeigniter4/shield/blob/1d9a659dae107ceff1f65700f2f789b8df4ad28e/phpstan-baseline.php#L321
Also, run the following command to fix the code style:
composer cs-fix

@datamweb Allright I'll try these and update the PR.

Allright I'll try these and update the PR.

what do you mean?

@datamweb I repushed the PR with sign. It was not easy to sign last 3 commits I'm not sure if it went well. and with change of this line below like you mentioned. I use composer-fix but here's the thing, I don't really know why did you ask to change this phpstan config.
https://github.com/codeigniter4/shield/commit/1d9a659dae107ceff1f65700f2f789b8df4ad28e
 'count' => 8,
Feel free to reject the PR I can create a fresh one if it's not okay.

I use composer-fix but here's the thing, I don't really know why did you ask to change this phpstan config.

The reason for this request was the failure in examination phpstan. In fact, we had already suppressed the number of 9 errors detected by PHPStan.
With this PR you have removed the following code:
    public function testCheckSuccessOldDangerousPassword(): void
    {
        /** @var Auth $config */
        $config                              = config('Auth');
        $config->supportOldDangerousPassword = true; // @phpstan-ignore-line

        fake(
            UserIdentityModel::class,
            [
                'user_id' => $this->user->id,
                'type'    => Session::ID_TYPE_EMAIL_PASSWORD,
                'secret'  =><EMAIL_ADDRESS>                'secret2' => '$2y$10$WswjNNcR24cJvsXvBc5TveVVVQ9/EYC0eq.Ad9e/2cVnmeSEYBOEm',
            ]
        );

        $result = $this->auth->check([
            'email'    =><EMAIL_ADDRESS>            'password' => 'passw0rd!',
        ]);

        $this->assertInstanceOf(Result::class, $result); // This causes an error
        $this->assertTrue($result->isOK());

        $foundUser = $result->extraInfo();
        $this->assertSame($this->user->id, $foundUser->id);
    }

Therefore, one error will be less.
Regarding command composer cs-fix, this command automatically checks the code styles and fixes it if there is a problem.
As you can see now, everything turned green:

I repushed the PR with sign. It was not easy to sign last 3 commits I'm not sure if it went well.

Please refer to the link below:
https://github.com/codeigniter4/shield/pull/672#issuecomment-1468658726
https://github.com/codeigniter4/shield/pull/672#issuecomment-1468722608

@datamweb Thank you for all these explanations. Specially on PHPStan part. I was confused at first about replacing 9 to 8.
No I think ı signed well. It seems legit.

@datamweb  🙏  PR need a reviewer and approving review by reviewers, but will you wait to merge because of the scope of this PR?

@omerimzali I added a ref link  to your PR description, but haven't had time to review it carefully yet.
Changes may be needed, in any case you will be notified.
@kenjis, what's the next version?

The next version is 1.0.0-beta.7.

@datamweb thank you, feel free to ping me for any changes.

No feedback.
Closed by #976


Create monett.txt

Would like to add Monett MO schools to the list.

Monett MO Schools

@jcphlux Pull request merged, thank you!


Use GA repo for the EC task ref used by RHTAP

NOTE: As noted mentioned in the comments in the of the file, this change has no impact on Konflux since Konflux uses the upstream task definition, not this one.
Since EC has been declared GA, it's now able to push to the normal repo rather than the tech preview repo. So let's update the image reference in the verify-enterprise-contract task accordingly.
There's a similar change in the related task definition in the tssc-sample-pipelines repo, see https://github.com/redhat-appstudio/tssc-sample-pipelines/pull/39 .
Ref: EC-571
Before you complete this pull request: Look for any open pull requests in the repository with the title "e2e-tests update" and  see if there are recent e2e-tests updates that will be applicable to your change.

The ec image is now available in rhtas/ec-rhel9, (more details in EC-570) so this can come out of draft now.

Not sure what the merge queue failure was, but I'll be optimistic and try it again.


[📑 Docs]: Adapt coming from OpenAPI tutorial for v3

For AsyncAPI v3, we need to adapt the coming from OpenAPI tutorial  (https://www.asyncapi.com/docs/tutorials/getting-started/coming-from-openapi) to be usable with AsyncAPI v3.
Here are the main points that need to change:

Re-add the docs/tutorials/getting-started/coming-from-openapi.md file.
Adapt the interactive comparison chart, to use AsyncAPI v3
Because of the new request/reply feature, you can now 100% convert OpenAPI to AsyncAPI documents (not sure if this should be displayed as an example?)

Make sure you base your change on the next-major-spec branch and target it in your PR 🙂 If you have any questions, don't hesitate to ask.

@alequetzalli  I want to work on this issue kindly assign it to me.

@jonaslagoni what you expect from third point?

That we would be able to see that you can map most if not all the things from the OpenAPI document to AsyncAPI 😄
Not sure how much info you need @AbhishekCS3459 ?

done with https://github.com/asyncapi/website/pull/2307


Context passed to run is undefined

When I .run(context) the interactor, the context object passed to the method is undefined

I spoke too early, I confirm context is passed in .run(context) and .organize(context)


envoy grpc_transcoder cannot call POST method

So, I created the proto file which can send request with POST method using google.api.http option like below
syntax = "proto3";

package soapv004;
import "annotations.proto";

service Soapv004 {
    rpc CurrencyCall (CurrencyRequest) returns (CurrencyResponse) {
        option (google.api.http) = {
            post: "/soapv004/v1/CurrencyCall"
            body: "*"
        };
    }
}

message CurrencyRequest {
     string from_currency = 1;
     string to_currency = 2;
}

message CurrencyResponse {
     double conversion_rate_result = 1;
}

and I created descriptor file for this proto as well, and envoy can load everything just fine. But when I call it it has no response and the log said 404. But route is fine I think
{
    "virtual_hosts": [
        {
            "domains": [
                "*"
            ],
            "routes": [
                {
                    "timeout_ms": 0,
                    "prefix": "/soapv004/v1/CurrencyCall",
                    "headers": [
                        {
                            "name": "content-type",
                            "value": "application/grpc"
                        }
                    ],
                    "cluster": "grpc1"
                }
            ],
            "name": "grpc_service"
        }
    ]
}

and here's envoy access log
[2017-09-04T04:54:20.929Z] "POST /soapv004.Soapv004/CurrencyCall HTTP/1.1" 404 NR 0 0 0 - "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36" "338ee060-ac40-40e0-8e69-33d15754ed49" "localhost" "-"

Is it any additional configuration to allow POST method? Because GET method have no problem so far.
Thank's in advance

@lizan ^

@syukur91 the route config is the cause, you should always specify a gRPC prefix for routes, not HTTP binding.
Changing the prefix in envoy config to /soapv004.Soapv004/CurrencyCall should work.

@lizan can we add some more specific docs/examples to https://lyft.github.io/envoy/docs/configuration/http_filters/grpc_json_transcoder_filter.html ?

@lizan so the http binding in google option is useless and can't be used anymore? I think the http binding in google option would be human readable. And I saw in this document https://grpc.io/blog/coreos that you can specify url for http binding

@syukur91 the http binding in google option does work, but the routing happens after the filter convert the path according to the http binding, so the prefix in your route config should be gRPC one, not before the conversion.
@mattklein123 sure.

@lizan It works when I set in my local, but when I try in my remote machine and using TLS and have specific domain in each route it doesn't works.

@syukur91 Can you elaborate your usecase on your remote machine, including a full config? If you want to share it to me privately, find me on gitter.

Closing this out for now. Please reopen if there are further questions.


use the conductoross/conductor:3.15.0  issue some problems

Describe the bug
I want to use the image(conductoross/conductor:3.15.0) in local to try conductor . But when I use the  conductor.db.type=redis_standalone   and run it , some error message appeared.
Details
Conductor version:   docker-image: conductoross/conductor:3.15.0
Persistence implementation: Redis , es
Queue implementation:  Redis
Lock: Redis
this is the configuration
# Database persistence type.
# Below are the properties for redis
conductor.db.type=redis_standalone
conductor.queue.type=redis_standalone

conductor.redis.hosts=<IP_ADDRESS>:6379
conductor.redis-lock.serverAddress=redis://<IP_ADDRESS>:6379
conductor.redis.taskDefCacheRefreshInterval=1
conductor.redis.workflowNamespacePrefix=conductor
conductor.redis.queueNamespacePrefix=conductor_queues

# Elastic search instance indexing is enabled.
conductor.indexing.enabled=true
conductor.elasticsearch.url=http://<IP_ADDRESS>:9200
conductor.elasticsearch.indexName=conductor
conductor.elasticsearch.version=7
conductor.elasticsearch.clusterHealthColor=yellow

# Additional modules for metrics collection exposed to Prometheus (optional)
conductor.metrics-prometheus.enabled=true
management.endpoints.web.exposure.include=prometheus

# Load sample kitchen sink workflow
loadSample=true

this is the run command
docker run -v /home/config-redis.properties:/app/config/config.properties --init -p 8080:8080 -p 1234:5000   conductoross/conductor:3.15.0

this is error message.

I want to know what is wrong with the configuration. Thank you.

Hi @antz-H , Can you please try giving redis hosts as conductor.redis.hosts=<IP_ADDRESS>:6379:us-east-1c? The last argument is the availability zone which can be any string currently.

@manan164  Thanks a lot . This issue was resolved after configuration.
But another issue appeared.
Some issue about postgresql which I don't want to use it and I don't confige it in above configuration-file.

ok, when i add below configuration , every thing is ok
spring.datasource.url=jdbc:postgresql://<IP_ADDRESS>:5432/postgres
spring.datasource.username=postgres
spring.datasource.password=root


feat(iroh): Gossip client

Description
This makes gossip available in iroh. Using iroh-gossip directly, while not horrible, is a bit verbose.
Breaking Changes
Not sure. It exports a few more things, and adds things. But in theory it should not modify existing things.
Notes & open questions

There can be some scenarios where this can cause trouble. E.g. when subscribing and then unsubscribing to a topic that is also used for doc sync.
Gossip messages are deduped it seems. So if you send the exact same message twice it will be dropped. If that's how it work we must document it.
I see lots of errors like the following:

2024-05-01T13:16:20.430596Z ERROR sync{me=kkpbi4eb5h6jcdjz}:sync{me=kkpbi4eb5h6jcdjz}: iroh::sync_engine::gossip: Failed to process gossip event namespace=atqlwoptbmnd724j err=Serde Deserialization Error

It seems that the sync engine thinks that it "owns" gossip, so it uses subscribe_all and then will deserialize everything, even messages that are not for it. How can we avoid that? Using an entirely different ALPN for normal gossip?

What should be the behaviour when a subscriber lags? Close it or just send Lagged and continue?

I think that relying on guaranteed delivery for gossip is not a good idea in any case. so maybe just sending a Lagged but then continuing is best? Forcing the client to resubscribe could be a bit annoying.
Change checklist

[ ] Self-review.
[ ] Documentation updates if relevant.
[ ] Tests if relevant.
[ ] All breaking changes documented.

I think it is safe to just ignore any messages that are not for us. See https://github.com/n0-computer/iroh/pull/2258/commits/b88398e743935c5975571e8b4fcb54c929ddc5e8
Obviously you can mess with things by subscribing to a namespace that is currently being synced, but doing so accidentally is highly unlikely. And you can also mess with other stuff by using the low level blobs api, so 🤷 .

It seems that due to the fact that the rpc protocol is public, we can not ever do an additional rpc request without breaking compat.
--- failure constructible_struct_adds_field: externally-constructible struct adds field ---

Description:
A pub struct constructible with a struct literal has a new pub field. Existing struct literals must be updated to include the new field.
        ref: https://doc.rust-lang.org/reference/expressions/struct-expr.html
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.31.0/src/lints/constructible_struct_adds_field.ron

Failed in:
  field Iroh.gossip in /home/runner/work/iroh/iroh/iroh/src/client.rs:44

--- failure enum_variant_added: enum variant added on exhaustive enum ---

Description:
A publicly-visible enum without #[non_exhaustive] has a new variant.
        ref: https://doc.rust-lang.org/cargo/reference/semver.html#enum-variant-new
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.31.0/src/lints/enum_variant_added.ron

we need to mark the rpc enums as non exhaustive, that should solve this

longterm I wish the rpc types where all private anyway

It seems that the sync engine thinks that it "owns" gossip, so it uses subscribe_all

@Frando can we change this? seems unfortunate to subscribe to everything by default

It seems that the sync engine thinks that it "owns" gossip, so it uses subscribe_all

@Frando can we change this? seems unfortunate to subscribe to everything by default

I think we can, yes. What is our primitive of choice these days to merge a changing list of streams?

https://docs.rs/futures-lite/latest/futures_lite/stream/trait.StreamExt.html#method.race

#2265 changes the sync engine usage of gossip to not use subscribe_all (based on this branch).
However as outlined in the previous comment I think I'd prefer to move the new gossip_dispatcher module to iroh_gossip, and make both the node's gossip client and the node's sync engine use that dispatcher.

@Frando so the basic idea of the gossip dispatcher is just to have a thing that wraps the gossip and does some management so that it is less fragile to use.
If you agree with / can live with the public interface (which is just the subscribe function), we could move something with that signature into iroh-gossip as a higher level interface and then I would use it here, and you could update docs to use it (or not...).
The interface is basically this:
    pub fn subscribe(
        &self,
        msg: GossipSubscribeRequest,
        updates: UpdateStream,
    ) -> impl Stream<Item = RpcResult<GossipSubscribeResponse>> {

where UpdateStream is just a stream of either broadcast or broadcast_neighbours:
/// Send a gossip message
#[derive(Serialize, Deserialize, Debug)]
pub enum GossipSubscribeUpdate {
    /// Broadcast a message to all nodes in the swarm
    Broadcast(Bytes),
    /// Broadcast a message to all direct neighbors
    BroadcastNeighbors(Bytes),
}

I think the API is fine. And still very much in favor of having only one and not 2 high level dispatch interfaces to gossip.

Ok, I will clean up the dispatcher a bit and make sure it is independent of the rpc protocol, in preparation for moving it into iroh-gossip.

Moved the dispatcher to iroh-gossip and moved the types into the dispatcher file.
I reexported some of the dispatcher types instead of making newtypes for them in the rpc protocol. Not 100% sure about this, but making so many single element newtypes is a drag...

This is missing adapting the docs stuff to the new gossip dispatcher.

Also at least a smoke test for the gossip client API would be good so that we don't break things.

@Frando I have added a test. It seems to work, now that I have added the ability to tell the endpoint about node addrs (see https://github.com/n0-computer/iroh/pull/2433 ).
I think this kind of test is nice, because it forces us to make the client API sufficiently rich that you can do tests with it. Also it is much less likely to fluke out than a full cli type tests.
But - do you think this test for gossip will reliably work? I am connecting two nodes and then send a msg from one to the next. Can there be a situation where I send the message too early and it gets lost?

But - do you think this test for gossip will reliably work? I am connecting two nodes and then send a msg from one to the next. Can there be a situation where I send the message too early and it gets lost?

Yes, Gossip::join is awaited here, and that waits for at least one neighbor to come up before completing.
So the remaining TODO is to merge the two dispatchers (in dispatcher.rs and net.rs) so that messages flow only over a single channel and not two. We should do this, but IMO it can also happen in a followup.


goflow should not silently drop sampled header formats it can't understand

It does report it into the logs but we have no monitoring for it


Another technique?

Hey, I was diving into this subject while opening this bug that drove me crazy (If you have answer I would be happy to hear what you think about that).
Anyway I was thinking of another technique: Within DllMain, creating a thread that waits on DllMain to finish, and only then resumes to run the payload.
If it sounds good to you let me know and I can PR that.

Hey, I was diving into this subject while opening this bug that drove me crazy (If you have answer I would be happy to hear what you think about that). Anyway I was thinking of another technique: Within DllMain, creating a thread that waits on DllMain to finish, and only then resumes to run the payload. If it sounds good to you let me know and I can PR that.

Or you can just use QueueUserAPC like so:
VOID CALLBACK CallWithoutLoaderLock(ULONG_PTR dwParam)
{
    // Do your stuff here
}

BOOL APIENTRY DllMain( HINSTANCE hinstDLL,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
        if (!QueueUserAPC(CallWithoutLoaderLock, GetCurrentThread(), 0))
            std::abort();
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}


Issue with SQLite :memory: database losing tables

It seems Flagr 1.1.12 has some issues when configured with SQLite in-memory database. Refreshing the details for a flag a couple of times very quickly leads to errors like "an unknown error occurred while looking up flag 1: no such table: distributions" in the web UI.
Steps to Reproduce (for bugs)

Spin up a Docker container with Flagr configured with a in-memory database: docker run -e FLAGR_DB_DRIVER=sqlite3 -e 'FLAGR_DB_DBCONNECTIONSTR=:memory:' -it -p 18000:18000 checkr/flagr.
Navigate to http://localhost:18000/#/ in a browser, "Create Simple Boolean Flag" (a description of foo_bar_baz should do the trick).
Click the new flag (navigate to e.g. http://localhost:18000/#/flags/1).
Refresh the browser a couple of times.

Sometimes the error happens as soon as you navigate to the flag details, sometimes it survives a couple of refreshes.
Your Environment

Version used (flagr version): v1.1.12
Host OS: macOS 10.15.7
Docker Desktop <IP_ADDRESS> (Docker Engine 19.03.13)

Looking at the output from Flagr, there doesn't seem to be any mentions of errors, closing the database connection or anything, before the tables disappear:

INFO[0077] started handling request                      method=GET remote="<IP_ADDRESS>:37880" request=/
INFO[0077] completed handling request                    measure#flagr.latency=273200 method=GET remote="<IP_ADDRESS>:37880" request=/ status=304 text_status="Not Modified" took="273.2µs"
INFO[0077] started handling request                      method=GET remote="<IP_ADDRESS>:37880" request=/api/v1/flags/1
INFO[0077] started handling request                      method=GET remote="<IP_ADDRESS>:37876" request=/api/v1/flags/entity_types
INFO[0077] started handling request                      method=GET remote="<IP_ADDRESS>:37872" request=/api/v1/tags
INFO[0077] completed handling request                    measure#flagr.latency=1238200 method=GET remote="<IP_ADDRESS>:37876" request=/api/v1/flags/entity_types status=500 text_status="Internal Server Error" took=1.2382ms
INFO[0077] error/go/src/github.com/checkr/flagr/pkg/handler/crud.go:192no such table: flag_entity_types
INFO[0077] completed handling request                    measure#flagr.latency=1118800 method=GET remote="<IP_ADDRESS>:37872" request=/api/v1/tags status=500 text_status="Internal Server Error" took=1.1188ms
INFO[0077] error/go/src/github.com/checkr/flagr/pkg/handler/crud.go:354no such table: tags
INFO[0077] error/go/src/github.com/checkr/flagr/pkg/handler/crud.go:146no such table: constraints
INFO[0077] error/go/src/github.com/checkr/flagr/pkg/handler/crud.go:146no such table: constraints
INFO[0077] error/go/src/github.com/checkr/flagr/pkg/handler/crud.go:146no such table: constraints
INFO[0077] error/go/src/github.com/checkr/flagr/pkg/handler/crud.go:146no such table: constraints
INFO[0077] completed handling request                    measure#flagr.latency=4679900 method=GET remote="<IP_ADDRESS>:37880" request=/api/v1/flags/1 status=500 text_status="Internal Server Error" took=4.6799ms
INFO[0077] started handling request                      method=GET remote="<IP_ADDRESS>:37880" request=/favicon.png
INFO[0077] completed handling request                    measure#flagr.latency=353900 method=GET remote="<IP_ADDRESS>:37880" request=/favicon.png status=200 text_status=OK took="353.9µs"
ERRO[0078] reload evaluation cache error                 err="no such table: flags"
INFO[0078] error/go/src/github.com/checkr/flagr/pkg/handler/eval_cache_fetcher.go:144no such table: flags
INFO[0081] error/go/src/github.com/checkr/flagr/pkg/handler/eval_cache_fetcher.go:144no such table: segments
INFO[0081] error/go/src/github.com/checkr/flagr/pkg/handler/eval_cache_fetcher.go:144no such table: segments
INFO[0081] error/go/src/github.com/checkr/flagr/pkg/handler/eval_cache_fetcher.go:144no such table: segments
ERRO[0081] reload evaluation cache error                 err="no such table: segments"
ERRO[0084] reload evaluation cache error                 err="no such table: flags"
INFO[0084] error/go/src/github.com/checkr/flagr/pkg/handler/eval_cache_fetcher.go:144no such table: flags
INFO[0087] error/go/src/github.com/checkr/flagr/pkg/handler/eval_cache_fetcher.go:144no such table: segments
INFO[0087] error/go/src/github.com/checkr/flagr/pkg/handler/eval_cache_fetcher.go:144no such table: segments

Hi, I think this is related to how sqlite3 handles db connections and processes that connect to the in-memory db. For example, https://www.sqlite.org/inmemorydb.html#temp_db

If two or more distinct but shareable in-memory databases are needed in a single process, then the mode=memory query parameter can be used with a URI filename to create a named in-memory database:
rc = sqlite3_open("file:memdb1?mode=memory&cache=shared", &db);

So I tried the following and it works.
FLAGR_DB_DBCONNECTIONSTR=file:memdb1?mode=memory&cache=shared

In the unit tests of flagr, we only use :memory:, it has only one process and one connection established, that's probably why it passes the unit tests.

Hi, I think this is related to how sqlite3 handles db connections and processes that connect to the in-memory db. For example, https://www.sqlite.org/inmemorydb.html#temp_db

If two or more distinct but shareable in-memory databases are needed in a single process, then the mode=memory query parameter can be used with a URI filename to create a named in-memory database:
rc = sqlite3_open("file:memdb1?mode=memory&cache=shared", &db);

So I tried the following and it works.
FLAGR_DB_DBCONNECTIONSTR=file:memdb1?mode=memory&cache=shared

In the unit tests of flagr, we only use :memory:, it has only one process and one connection established, that's probably why it passes the unit tests.


build(maven): set Java 8 as target version

Java 7 has been End Of Lifed (EOL).
Java 8 is going to be EOL.
This updates compiler target to Java 8.
Soon we should look into a Java 9 upgrade.

Contributor License Agreement adherence:

[x] This Contribution is under the terms of Individual Contributor License Agreements (and also Corporate Contributor License Agreements to the extent applicable) appearing in the Apereo CLA roster.

:construction_worker_man: :no_entry: Build errors resolved by #733

Rebased off fixed master branch.


OOBE visual improvements

Update "Whats new" icon
fix padding inside scrollviewer
add space between shortcut and description
~Hyperlinks are now on a new line~
remove background on Peek page

I have an idea, based on the picture with title / content / actions, i have an idea. Move the important bits from the content area into a dedicated area in OobeContentPage.xaml

This has been worked on during the 0.77 Release sprint. Please update PowerToys to the latest release: https://github.com/microsoft/PowerToys/releases


Bugfix: Fix issue in deep dream example

The expression of  pictures should be (img_height, img_width, 3) or (3, img_height, img_width), not (img_width, img_height, 3) or (3, img_width, img_height).

Yes, you are correct.


Bug: Failure deploying SHIR, error

Deployment Mode
Azure DevOps
Steps to reproduce
Deploy unaltered Bicep templates via ADO. When specifying SHIR = true, the SHIR VMSS is created, but the Custom Script Extension fails with the error message shown below.
Unsure whether there is a defect in the Custom Script Extension code, or some other environmental factor.
Error Message
Here is the error message we receive when deploying Data Landing Zone, SHIR. Notice the ‘ ‘ space in the runtime-datafactory string ('@ServiceEndpoint=entlz-d-runtime-datafac tory001')

VM has reported a failure when processing extension 'dowazd0004544-integrationruntime-shir'. Error message: "Command execution finished, but failed because it returned a non-zero exit code of: '1'. The command had an error output of: 'Failed to run process: exitCode=53, errVariable=, errContent=, outContent=Failed to get service token from ADF service with key IR@c863fffe-3c21-42bd-a54e-1e3b4ac48867@entlz-d-runtime-datafactory001@ServiceEndpoint=entlz-d-runtime-datafac tory001.northc...' For more information, check the instance view by executing Get-AzVmssVm or Get-AzVm (https://aka.ms/GetAzVm).

Screenshots
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

This issue should be closed. We found a DNS configuration issue in our deployment that created the failure. With proper DNS lookup, the SHIR deployment succeeds.


Error facing when testing tonomy id staging

When install app and go to onboarding getting error: "useWalletStore() Error clearing wallet state:"
When I am on the Explore Page, while clicking the "pitch Decks" link, I get the message "page not found."
While I am scanning  with demo app getting duplicate transaction error.
If I stay on the Assets page for more than 1 minute, it throws an error: Unexpected JS Error "{"context: "client"}"
While Scanning with React app after scanning click on login Then  on Assets page It throws an error: Unexpected JS Error "{"context: "client"}"

Steps  to replicate the issue

Install the TestFight   from the app store
Install the Tonomy ID  staging app and click on open
Click on "Next"
Click on Start Testing
Click on Proceed
Click on Create Account
Give a Username and click on "Next"
Rember the passphrase then Click on "Next"
Please enter the correct passphrase
Click on "Next" read the Terms&Conditions then click on "Accept"
Click on Checkboxes  to receive updates then click on "AAccept"
Click on the check box on the Human Verification page
Click on the correct image for Hcaptcha verification and click on verify
Click on "Create Account" Then Click on ok
Then it showed "Welcome to Pangea Virtual Nation, With Username" on Citizenship page
Click on "Explore" Then Click on "Pitch Decks" about Pangea links

*What do you expect to happen?
It should be open on the Canava homepage
**What actually happens
After clicking Pitch Decks it showed an error like page not found
**Your environment

Operating System: IOS -17.6.1
Tonomy Id staging -Mobile app
Tonomy Id Staging version:-0.126.0

https://github.com/user-attachments/assets/b9fdbe03-c16a-4844-bd56-2a92d3f4dcab

4. If I stay on the Assets page for more than 1 minute, It throws an error: Unexpected JS Error "{Context: "Client"}"
Steps to replicate the issue
Install the TestFight from the app store
Install the Tonomy ID staging app and click on open
Click on "Next"
Click on Start Testing
Click on Proceed
Click on Create Account
Give a Username and click on "Next"
Rember the passphrase then Click on "Next"
Please enter the correct passphrase
Click on "Next" read the Terms&Conditions then click on "Accept"
Click on Checkboxes to receive updates then click on "Accept"
Click on the check box on the Human Verification page
Click on the correct image for Hcaptcha verification and click on verify
Click on "Create Account" Then Click on ok
Then it showed "Welcome to Pangea Virtual Nation, With Username" on Citizenship page
Click on "Assets"
What do you expect to happen?
Assets home page should be stable
**What actually happens
If I leave Assets page for more than 1 minute, It throws an error: Unexpected  JS Error "{"context: "client"}"
Your environment
Operating System: IOS -17.6.1
Tonomy Id staging -Mobile app
Tonomy Id Staging version:-0.126.0
https://github.com/user-attachments/assets/bd2052eb-6391-4085-b866-2f9ece56a1a8

5) ** While Scanning with wallet Connect after scanning click on login Then  on Assets page It throws an error: Unexpected JS Error "{"context: "client"}"**
Steps to replicate the issue
Install the TestFight from the app store
Install the Tonomy ID staging app and click on open
Click on "Next"
Click on Start Testing
Click on Proceed
Click on Create Account
Give a Username and click on "Next"
Remember the passphrase then Click on "Next"
Please enter the correct passphrase
Click on "Next" read the Terms&Conditions then click on "Accept"
Click on Checkboxes to receive updates then click on "AAccept"
Click on the check box on the Human Verification page
Click on the correct image for Hcaptcha verification and click on verify
Click on "Create Account" Then Click on ok
Then it showed "Welcome to Pangea Virtual Nation, With Username" on Citizenship page
Then open URL link  https://react-app.walletconnect.com/
Click on Ethereum Sepolia then click on Connect then Click on New pairing
Click on "Assets"  Then Click on  Scan with Connect your wallet
Then Click on "Log in " on your mobile React app page
**What do you expect to happen? **
It should  show Asset page without any errors
What actually happens
After clicking login, It goes to Asset page and throws an error: Unexpected JS Error "{"context: "client"}"
Your environment
TestFlight Version: 3.5.2
Operating System: IOS -17.6.1
Tonomy Id staging -Mobile app
Tonomy Id Staging version:-0.126.0
https://github.com/user-attachments/assets/e42284fc-a68b-44dc-9046-9616c042824c

I retested with a new version(0.134.0) of Tonomy ID Staging and could not replicate this bug.


Kadane's Algorithm

Enter your question -
Find the contiguous sub-array(containing at least one number) which has the maximum sum and return its sum.
Enter link to the question(if question belongs to any online platform) -
https://practice.geeksforgeeks.org/problems/kadanes-algorithm-1587115620/1#
Tags for the question(eg - Array, Basic, Stack, etc.) -
Array

Kindly Assign this to me.

@RAshid602,
Surely I'll look into it


use of vars results in invalid dbt run command

Reading the source vars is used like:
dbt_run = DbtRunOperator(
    task_id="dbt_run",
    models="MY_MODEL",
    vars={"EXECUTION_DATE": "{{ ds }}"},
)

This generates an invalid dbt command where vars is formatted like:
--vars {"EXECUTION_DATE": "2020-12-22"}

What is valid is:
--vars '{"EXECUTION_DATE": "2020-12-22" }'

noting the extra '
I believe this is a bug.
dbt=0.18
airflow=1.10.14

OK this was a red herring, the error was arising due to a broken dbt model. I didn't know that dbt will compile all models in a project even if only a single model is to be run.
Cheers


How to set the font in exported pdf?

I convert a dwg file to pdf, but the font in pdf is not what I want. How can I set the font. I have tried the following code, but does not work. And I can see the lines in the graph are too thick in the exported pdf. Can I also set the size of the line when converting dwg file to pdf file?
// Iterate over the items of CadStyleDictionary
for (CadStyleTableObject style : (Iterable)objImage.getStyles())
{
// Set the font name
style.setPrimaryFontName("sans-serif.ttf");
}

Hello, this setting of font should work. We need to try this on your file, you may attach it on our forums here: https://forum.aspose.com/c/cad/19.


Assessment style

#121  restyles the assessment page

@digitalWestie looks like there's still styling to incorporate from here?
http://upcloseandpixelated.com/ODMAT/pages/assessment-overview.html
Download links, button colours, etc? Although that version doesn't have the edit in place text.

Ah, I was basing off an earlier vers!

Updated now


OP specific beacon consensus crate

Describe the feature
A new crate op-beacon-core should be made with a new type OptimismBeaconConsensus. The crate should live alongside the beacon-core crate. The type OptimismBeaconConsensus should impl reth_interfaces::consensus::Consensus trait. The goal with this is to remove the optimism feature from the beacon-core consensus crate.
How this new type should be plugged into the node, needs design. Possibly by replacing usage of the BeaconConsensus type with a Consensus trait object. However since this requires a lot of changes, for the scope of this PR, let's just bring either type into scope with a feature gate here
https://github.com/paradigmxyz/reth/blob/a2654650bac5a9d3d6ec988fff59637d5b716de6/crates/consensus/beacon/src/lib.rs#L11
as such
#[cfg(not(feature = "optimism"))]
pub use reth_beacon_consensus_core::BeaconConsensus;
#[cfg(feature = "optimism")]
pub use reth_beacon_consensus_core::OptimismBeaconConsensus;

Additional context
No response

Will OptimismBeaconConsensus be a struct?


added DateTime Extension

-> added DateTime Extension
-> Updated Gradle version of the testing app from 7.3.3-bin to 7.4-bin
-> Changed min SDK of the testing app from 21 to 26
-> Changed target SDK of library and testing app from 32 to 33

Looks good


Ensure VCAP_APPLICATION/cf_api can be used from both outside the cluster and within an app workload pod

Background
In the korifi helm chart we are configuring the api url in the controllers config to whatever value is set into .Values.api.apiServer.url. That value eventually ends up in VCAP_APPLICATION. When we deploy on kind, that value is localhost which is not great - localhost from app containers` point of view is the container itself, not the api - therefore, that value is unusable.
In a normal deployment scenario one would use a load balancer and configure the api url with its address. In the local kind development scenario this is not the case. I am therefore unsure whether this is a bug or a chore.
Action to take
Figure out how to configure VCAP_APPLICATION/cf_api so that the URL can be used from both

the app workload container (i.e. the app can talk to the CF API if it wants to)
outside of the cluster (i.e. if the app returns an URL returned from the CF API response directly, or composed by concatenating the cf_api value with a CF API REST endpoint)

Impact
App workloads can talk to the CF API when deploying on kind
Dev Notes
See related slack thread: https://cloudfoundry.slack.com/archives/C0297673ASK/p1678960985499479
WIP branch: https://github.com/cloudfoundry/korifi/tree/wip-cfapi-nipio
The wip branch above only works for Linux. On mac,there is no docker0 network interface, therefore the docker network IP cannot be determined reliably (or at least I could not figure it out).

We have spiked on an alternative approach that changes the Coredns config of the kind cluster so that it redirects a local host like localtest.me back to the ingress service, but found out that not all network calls pass through Coredns which resulted in a mess.
We have decided to live with the linux-specific slolution for now


Importing full zip doesn't work for WinTak but importing individual .XMLs does seem to work.

Might want to note that in the instructions and possibly create a release that groups them all in one folder to be imported at once.

Thanks for the heads up @sntrenter . I updated the much over due instructions with commit: 1b57d2ee8448d4f815674f6b0ef7c8b823c883b8


Update PR template to front-load issue references

Description
Currently, when PRs have long and detailed descriptions (a good thing!!!), it's
hard to find the reference to the issue(s) that they close. This updates the
template so that those issues are linked right at the top, before the
description.
I think a lot of the stuff at the bottom of the PR template is cruft (it was
created a long time ago), but we can discuss that in separate issues/PRs.

+1, looks great!

Why not just use the development section of the right panel?

@Czaki I don't know what magic GitHub does to put those there, with "may close" — is it all references? Only ones with the keywords? The text description around the reference can be more informative. Also, that view is not present in all versions of the GH UI, e.g. mobile, narrow windows. Let alone the final commit message!

It looks on keyword like closes #num full list is here:
https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword
On the narrow window, it requires scrolling down at the end of the page (that may be problematic). Same on the mobile version of the browser.
In the mobile app, this information is under (i) button.
I'm not against this change. I would like to highlight options provided by the GitHub interface that will work in all projects.


TUF client initialization panics when $HOME/.sigstore or its contents are read-only

TUF client initialization fails if the $HOME/.sigstore directory and its contents aren't writable, causing panics like panic ... creating root cert pool: retrieving trusted root; local cache may be corrupt: creating cached local store: mkdir $HOME/.sigstore: read-only file system
See also: https://github.com/sigstore/cosign/issues/1207

Can fix with in-memory fetching only, writing failures can be gracefully failing.

SGTM @asraa :)


Would like the build data restored to the warehouse for non-XAML builds

It would be helpful to restore the build data to the warehouse.  We use an on-premises version and produce reports for compliance and traceability using the warehouse.

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

ID: 126a5a77-d3fe-af1f-12e5-260ed45151d2
Version Independent ID: c2adedfc-bc7b-a73c-9c5c-43d8a03346d5
Content: Build Details tables - TFS
Content Source: docs/report/sql-reports/table-reference-build-details.md
Product: devops
GitHub Login: @KathrynEE
Microsoft Alias: kaelli

@cubonesmash - Thank you for your inquiry. I recommend you post your request to our  Support page.


Include prefixed units in suggestions

When using Mib instead of MiB, a user will get something like
>>> Mib
error: while type checking
  ┌─ <input>:1:1
  │
1 │ Mib
  │ ^^^ unknown identifier
  │
  = Did you mean 'in'?

If we would include prefixed units (in this case: MiB) in the potential suggestions, we would get the "correct" suggestion here.

If someone wants to implement this, check out the comment here: https://github.com/sharkdp/numbat/issues/414#issuecomment-2069853931


Installation issue

I'm pretty new to the world of Python but just hit this issue so thought it worth reporting. Likely I'm doing something wrong though!
pip3 install geopandas movingpandas rasterio rioxarray jupyter

Ends in this error message on my desktop:
ERROR: movingpandas 0.9rc2 has requirement shapely<1.8, but you'll have shapely 1.8.0 which is incompatible.
Installing collected packages: pillow, bokeh, pyshp, cartopy, geographiclib, geopy, param, pyct, colorcet, pyviz-comms, panel, holoviews, geoviews, hvplot, movingpandas
Successfully installed bokeh-2.4.2 cartopy-0.20.2 colorcet-3.0.0 geographiclib-1.52 geopy-2.2.0 geoviews-1.9.3 holoviews-1.14.7 hvplot-0.7.3 movingpandas-0.9rc2 panel-0.12.6 param-1.12.0 pillow-9.0.0 pyct-0.4.8 pyshp-2.1.3 pyviz-comms-2.1.0

Issue first spotted on reproducible docker build: https://github.com/geocompr/docker/runs/5008434217?check_suite_focus=true#step:8:715

Hi @Robinlovelace, good to hear from you. Any chance you can use conda? Pip isn't really supported by MovingPandas, as described in https://github.com/anitagraser/movingpandas#installation

Yes good chance I can... Need to figure out how to get it all working in Docker. Recalling discussions of pip vs conda vs poetry on other threads. However, is it right that movingpandas depends on an earlier (<1.8) version of shapely (guess I can check the yml files for that, will do ; )

Confirmed: https://github.com/anitagraser/movingpandas/blob/master/environment.yml#L25 I think one of the packages required for another project I'm working on rasterio ? @michaeldorman probably knows better, needs a higher version, meaning it's hard to have the 2 pkgs in the same environment, unless conda can sort that...

Minor update, trying with
conda install -c conda-forge movingpandas geopandas rasterio rioxarray jupyter

So far so good...

Update, I get this:
conda install -c conda-forge movingpandas geopandas rasterio rioxarray jupyter
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.

Not sure if this is reproducible on other computers.

We had to pin shapely because Geoviews 1.9.2 was not yet compatible with shapely-1.8.0.
This should be fixed, according to https://github.com/holoviz/geoviews/releases. So we can remove the pin again.


Fix crash on book selector

Problem can occur if you are going from a high chapter number (Like Genesis 50) to a book with fewer chapters.  The initial setup of the verse grid is using the old chapter number and not finding it in the new book, which causes an exception in SelectGrid.

If switching books, set the nextRef chapter to point to 1 initially


Error importing from Specter 1.14.5

I successfully imported several other wallets from Specter exports, however, one produces the following error on multiple attempts to import to Sparrow 1.8.1 (path redacted):
Imported Specter Desktop wallet was invalid: Keystore coldcard derivation of XXXXXX' in P2WPKH wallet matches another default script type.

You can disable derivation path validation in the General Preferences.

Yes, this friction is intentional. Reusing a derivation path means reusing keys, which means a loss of privacy. Even though you may have two wallets with different script types, they will be linked on the blockchain if using the same derivation path. There are good reasons why different script types have different derivation paths.


Broadcasting.html not displaying anything

Hi, I cloned the repo and tried to run it exactly as in the instructions.  Please see
Please see https://1798-138-207-214-238.ngrok.io/broadcaster.html and https://1798-138-207-214-238.ngrok.io/index.html
The broadcaster client is not displaying anything except buttons (which don't work), and the audience client only displays the camera.
Can you help with this please?

I found the solution for this.  I had to download the latest version of the AgoraRTCSDK because the old one in the repo was not compatible with the current version of chrome.  So, host side now displays the 3D model.
However, on the audience side I only see the camera view of the mobile device.  Nothing in AR in terms of the broadcaster 3D model.  Any ideas on this?  Thanks

Did you print out the marker image?


Changelog not including commits for initial version

Summary
I have auto-changelog set up in my NPM "version" script as suggested in this project's README, but when I do npm version patch the first time, commits don't get included in the generated CHANGELOG.
In addition, the section in CHANGELOG.md for the initial version does not contain the v prefix.
Steps to reproduce issue:

Start from empty directory
Run following command to initialize directory:git init && npm init -y && npm install --save-dev auto-changelog

Add to package.json scripts section:"version": "auto-changelog -p && git add CHANGELOG.md"

Create an initial commit:git add --all && git commit -m "initial commit"

Create an initial version:npm version patch

Expected results:
CHANGELOG.md should contain a section for v1.0.1 that contains the "initial commit" commit
Actual results:
Here is the contents of the generated CHANGELOG.md:
### Changelog

All notable changes to this project will be documented in this file. Dates are displayed in UTC.

Generated by [`auto-changelog`](https://github.com/CookPete/auto-changelog).

#### 1.0.1

> 14 July 2020

As you can see, the 1.0.1 section does NOT contain the v prefix, and does not list any commits.

@CookPete any thoughts on this issue?

@patlillis Sorry, I attempted to fix this as part of a refactor weeks ago, then forgot about it and didn't push.
I've just published v2.2.1 which I'm hoping will fix this problem. Let me know?

It seems that this is still relevant. I just experimented with my repository template. It has no tags.
After running auto-changelog --latest-version 20.12.11 -l false --unreleased-only -u I received:
### Changelog

All notable changes to this project will be documented in this file. Dates are displayed in UTC.

Generated by [`auto-changelog`](https://github.com/CookPete/auto-changelog).

#### 20.12.11

While experimenting, I tried to add a v0.0.0 tag to the initializing commit and run the same command again. In this scenario, a completely correct change log was generated, which contained a complete list of all commits.

It seems that this is still relevant. I just experimented with my repository template. It has no tags.
After running auto-changelog --latest-version 20.12.11 -l false --unreleased-only -u I received:
### Changelog

All notable changes to this project will be documented in this file. Dates are displayed in UTC.

Generated by [`auto-changelog`](https://github.com/CookPete/auto-changelog).

#### 20.12.11

While experimenting, I tried to add a v0.0.0 tag to the initializing commit and run the same command again. In this scenario, a completely correct change log was generated, which contained a complete list of all commits.

Same happens for me, when there is not tags in the repository the generated changelog is empty.
Once I tagged the first commit with v0.0.0 the generated changelog was full with all the commits.


running into RAM limitations for freertos tasks

First of all, thank you for the excellent project. It's a great library with tons of options, well done.
We have a large project that runs on a stm32 with Freertos. We use littlefs to store persistent variables and files. This has worked well for a couple of years until recently we ran into very slow lfs_renames.
Together, with removing lfs_rename we also updated littleFS to the latest version.
This is throwing some issues because some operations require a lot more stack than before. We need to bump each task that stores some variable in littlefs.
How would you structure the littlefs integration if you have for example 30 Freertos tasks that all require storing a unique single value in littlefs? The current solution to store the variable directly from the tasks is not workable, because each task requires a stack increase of +2000 bytes to be able to open the files.
Is there a solution in littlefs that we are missing? Our solution might be to write a caching layer in a task that contains littlefs to a single task.
Does anyone with a similar problem already fixed this?

Hi @geky, sorry for the slow response.
We upgraded from 2.4.0 -> 2.9.1
In the meantime, we optimized the configs to ensure the small variables are stored as metadata. This already decreases the amount of erased data.
We also freed the scheduler on some of the hal calls this unblocks the MCU enough for the high prior tasks.
In the long term, we are looking for a different solution to store small variables to solve the high stack usage in each task.
In the meantime, we are trying to force the LFS formats into a low-priority task to decrease the blocking time for high-priority tasks.  It looks that garbage collection doesn't work for the metadata blocks.

We upgraded from 2.4.0 -> 2.9.1

Ah, v2.5 was when we finally removed all remaining recursion. Prior to this it was still possible for specific situations to end up with a theoretically unbounded stack.
I'm curious if what you're seeing is a result of previously unmeasurable stack usage becoming measurable, or an actual increase in real stack usage (via stack canary, watermarking, etc).

We also freed the scheduler on some of the hal calls this unblocks the MCU enough for the high prior tasks.

This is smart when not filesystem-bound.

In the meantime, we are trying to force the LFS formats into a low-priority task to decrease the blocking time for high-priority tasks.  It looks that garbage collection doesn't work for the metadata blocks.

I'm sorry, I'm having difficulty understanding this. Do you mean block erases? lfs_format does not really make sense here, unless I'm misunderstanding something.
Right now lfs_fs_gc does not pre-erase blocks. This is a wishlist item, but unfortunately it requires quite a bit of extra infrastructure to implement (global block map).
Though if the files are small enough, lfs_fs_gc with a sufficiently low compact_thresh configuration should usually be able to avoid erases. Though this currently requires the files fit in cache_size, maybe cache_size is too small?

In the long term, we are looking for a different solution to store small variables to solve the high stack usage in each task.

If your RTOS provides a thread-safe queue/fifo, and the files/variables can fit in the queue/fifo, you could implement a single "storage" task that reads from the queue and writes the variables to the filesystem. This is the best solution I can think of short of reimplementing littlefs...


Minor edits

Minor edits

I've re-worked the readme in #307 instead, deferring to the docs site for more of the installation instructions.


Gauge LSP: Execute a specification

Proposed behavior
Execute all the scenarios in the specification
Out of scope

Debugging
Parallel

Steps

Provide a Code lens link to execute all scenarios in the specification.

Test Cases

[ ] Execute all the scenarios in the specification, show the results in the output window.

Should be available in gauge nightly >= 05-10-2017 and gauge-vscode nightly >= 6-10-2017


Some general code quality improvements and 2 small fixes

This is currently not intended to be merged, it should be fully functional though.
Have a look and tell me what you think!
Find 1
While looking through the code I noticed new Random instances are created for each villager/golem name, which is not only inefficient but can heavily impact the random generation:
https://github.com/OverlordsIII/VillagerNames/blob/26f931257e26b91db0acc65da09d236ba6e84eb0/src/main/java/io/github/overlordsiii/villagernames/util/VillagerUtil.java#L46
https://github.com/OverlordsIII/VillagerNames/blob/26f931257e26b91db0acc65da09d236ba6e84eb0/src/main/java/io/github/overlordsiii/villagernames/util/VillagerUtil.java#L58
This is easily fixed by just creating one static Random instance and reusing it.
Find 2
I also noticed this check before updating the name of a villager gaining a profession:
https://github.com/OverlordsIII/VillagerNames/blob/9b99751226e50c74f8060489fe22701898b2c738/src/main/java/io/github/overlordsiii/villagernames/util/VillagerUtil.java#L87
It would block any villager with "the" in their name (like Matheus) from getting a profession text.
The easy fix is to use " the ", although I'm not sure why the contains check is there in the first place, can a villager get "updated" without changing his profession?
General
While reading some more I saw a lot of code duplication for anything villager and golem name related, so I started refactoring.
E.g. GolemNameArgumentType and VillagerNameArgumentType are moved into one neat little package named NameArgumentType which contain Golem and Villager inner classes and the golemName() and villagerName() helper functions.
The villager and golem configs are also abstracted a little bit so it's very easy to have a general pickRandomName().
I also touched some of the inconsistent code styling, but quickly gave up on it because I'm not sure in which direction to go, e.g. is it if (){ or is it if () {?
Changelist

general style improvements, less code duplication for villager and golem name related code
don't create a new Random on each use
fix check in villager name update from containing "the" to " the "

Some more questions
I don't understand the reason for FormattingDummy, can't Formatting be used directly?
I also don't quite understand the random name generation, usedUpNames sounds like a name should never be picked again, instead these names gets rerolled once.
With the current amount of names (6700+ for villagers) it is already very unlikely to have common names, so I'm not entirely sure why it is done this way.

This looks like good stuff, thanks for taking the time to do this!
Sorry for the late response, I forgot to check on the repo in a while, sorry about that!
As for some of your findings

This is a valid point, and I guess should be quite easy to fix, I fully agree with what you are saying

This should be changed to " the ", but as for why the contains check exists in the first place is used when either catching something that createVillagerNames missed or when used for children names feature

FormattingDummy is used to make sure that its toString representation is properly used by the config. The config uses an api called ClothConfig and when using enum types, uses its toString representation. The problem is that minecraft's formatting as a string is represented as a formatting code with the wierd symbol, so the selection box for the villager text formatting would not carry the correct values, and would instead have a wierd symbol for the user to select.

Basically, if we use minecraft Formatting instead of it using the normal text of the specific formatting, it will use something like this: §4

I guess this is a fair point, I think it should eventually be rolled back though, maybe when its size is equal to the villager names list size, so around 6700 or so

Overall though, most of the changes make sense and I am really thankful that you would spend the time to do this. I recently started minecraft modding and coding in general, so I hope I learn more along the way.

1. This is a valid point, and I guess should be quite easy to fix, I fully agree with what you are saying

It's fixed in this PR, so if you decide to merge, nothing more needs to be done.
I initially said this PR isn't yet intended to be merged, mainly because I haven't fully tested every change, but I'm pretty confident everything is working. Most changes are refactoring through my IDE, so there is little chance of error.
I just noticed Github says "Draft pull requests cannot be merged" and now I'm confused.
I thought drafts could be merged because I'm 99% sure I had a draft in the past (on another account) that got merged earlier than I wanted it to.
Oh well, in that case, it's now open and ready to merge.

2. This should be changed to " the ", but as for why the contains check exists in the first place is used when either catching something that createVillagerNames missed or when used for children names feature

Hm... but children can't have a profession, right? The contains check is just after the check if the villager has a profession.
I can't say I fully understand, but it's probably best to not mess with it and just leave the check in.

3. FormattingDummy is used to make sure that its toString representation is properly used by the config.

Ah, got it.

4. I guess this is a fair point, I think it should eventually be rolled back though, maybe when its size is equal to the villager names list size, so around 6700 or so

Ah, I think there's some misunderstanding here, I'm not saying how the random name generation should work, I'm just trying to understand the reasoning behind how it currently works.
Like this is the current implementation (in this PR, but master works exactly like this):
        List<String> names = namesConfig.getNameList();

        //pick a random name
        int index = random.nextInt(names.size());

        //when more than half of all names were "used up", unmark all names
        if (usedUpNames.size() > names.size()/2)
            usedUpNames.clear();

        //if the name was "used up", reroll it once
        if (usedUpNames.contains(names.get(index)))
            index = random.nextInt(names.size()); //confusing: this new name could still be "used up"

        //mark the name "used up"
        usedUpNames.add(names.get(index));

        return names.get(index);

I'm basically asking what 'issue' the "used up names" concept is solving, because if you compare the above implementation with the most basic one:
        List<String> names = namesConfig.getNameList();

        //pick a random name
        int index = random.nextInt(names.size());

        return names.get(index);

common names should still be pretty rare because there just are so many of them.
I just did some math, so here are the numbers.
With the basic implementation, the chance that the first 100 villager names are unique is
(6700/6700 * 6699/6700 * 6698/6700 * ... * 6600/6700) or 47% which is already pretty high.
With the current implementation, all 100 names are "used up" and hence rerolled if they were to collide, which means the chance that all 100 names are unique should look like this:
((6699/6700 + 1/6700*6699/6700) * (6698/6700 + 2/6700*6698/6700) *  ... * (6600/6700 + 100/6700*6600/6700)) or 99.2%!
(Only after about 470 names would it reach the 'low' 47% chance like above)
So I guess I answered my own question, the current implementation does make common names practically (though not actually) impossible.
If you want to guarantee unique names though, the easiest way is to just shuffle the list once via Collections.shuffle(list); and progressively take the ith element (reshuffling the list and resetting i once reaching the end).
If I were to now talk about how it should work, I don't think it's bad to have a chance of duplicate names, it is human afterall, so personally I'd probably use the 'basic' implementation.
Maybe I'll implement both variants and a config option in another pull request.

I'm going to level with you here
The whole reason that last feature (the one for making sure names dont get repeated) was added very early in this mod's lifecycle, when we only had 300 names to use. Now that we have more, it's not that useful. This comment here
if (usedUpNames.contains(names.get(index)))
            index = random.nextInt(names.size()); //confusing: this new name could still be "used up"
``` is just there because I was counting on the name just to not be in there. Even if it is, it lowers the chance more. But honestly I agree with what you are saying, so I am just going to check a final look around before merging.

Hmmm I'm not sure why github didn't add you to the contributors list.... if you want to, just make a dummy pr and ill accept it to get you on there

Ah, I think that's because I left the git author email field empty.
Github doesn't seem to think my commits are from me - not sure how to fix that, but it's no big deal, the PR itself is documentation enough and I saw you added me to the authors in fabric.mod.json as well and that's already more than I would ask for.


feat: use IErrors in IStore and IWorldCore

fixes https://github.com/latticexyz/mud/issues/559
Since systems are called via IWorld, I assume System doesn't need to inherit IErrors?

fixes #559
Since systems are called via IWorld, I assume System doesn't need to inherit IErrors?

in autonomous mode, isn't a system a store? or is a store deployed separately?

or did we end up centralizing all storage on the world and controlling it with access/namespace stuff?

^ this
Store could be used standalone, but then systems just aren't a thing because they need World


Make the treatment view look nicer and add some moar fields

Right now the treatment supports very rudimentary fields. Add some more with a nice UI.
See Wiki: Treatment View

i'm okay with it, looks good. could be nicer, and some more fields, but for the moment its sufficient.


Mr

Hi, I have been a patron for sauce for strava for 2 months now. This morning i can only access the free features and it is asking me to become a patron. However, i can see that on the 3rd of May a new payment went in so I guess I should have all the features available. please could you help me to recover my patron account?
Thank you
Santi

Hi @Santi-Nieva
Can you try relinking to patreon using this link: https://www.saucellc.io/patreon-oauth
If that doesn't work, send me an email to<EMAIL_ADDRESS>and I'll get your squared away.

Thanks a lot. All sorted now.
Santi
On Saturday, May 7, 2022, 09:32:04 AM GMT+1, Justin Mayfield @.***> wrote:
Closed #115.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>


Documentation on existing language wrappers for aca-py

I do not know if this is a complete list, but I think this might be useful information for anyone getting started on implementing their own controllers.
Signed-off-by: Philipp Etschel<EMAIL_ADDRESS>

Thanks @etschelp -- good addition.  Can you please update the PR so we can merge it?


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_83whuv3b9a/clone/recipe/meta.yaml:14: pip_install_args: pip install should be run with --no-deps.
ERROR: /tmp/abs_83whuv3b9a/clone/recipe/meta.yaml:21: missing_wheel: For pypi packages, wheel should be present in the host section
WARNING: /tmp/abs_83whuv3b9a/clone/recipe/meta.yaml:42: missing_description: The recipe is missing a description
Errors were found


Error in running the INSTALL target

Hi  Patrik
Thanks for the code
I have this error message when I try to build the install project in /visual Studio 2015.
Unhandled exception at 0x000007FEFCCEA06D in 4dface.exe: Microsoft C++ exception: cereal::Exception at memory location 0x00000000001C0F40.

Hi,
I don't think this error can occur when building, so I don't think this has anything to do with the INSTALL target. I think you're running 4dface.exe actually.
In that case can you please run it in debug mode and pinpoint the exact line where the problem occurs in the 4dface code? You'll find all you need in the callstack window.
It might just be that you give it a wrong path or file.

Hi
Thanks It works now
But I want to run on a video, how can I do that. It just works with a camera.
Regards

I don't know what you mean with "It just works with a camera", but how you run it on videos depends on your database and landmarks. In any case, you can have a look at 4dface.

This is an error that I got
C:\phd\codes\4dface-master\build\Debug>4dface.exe -i Copy of bgia5a.mpg
warning: Error opening file (../../modules/highgui/src/cap_ffmpeg_impl.hpp:537)
Couldn't open the given file or camera 0.

Try without spaces in the filename. If that doesn't work either, maybe your OpenCV has problems reading mpg files?


Optimise bundling to reduce extension size

🤔 What's changed?

Migrated documentation image storage from git to GitHub CDN
Extended bundle ignore file to exclude non-required paths - such as .github/, scripts/, etc.
Changed to the larger logo

⚡ What's your motivation?
Reduces extension size from 15,696,312 bytes to 1,038,033 bytes - a 93.4% decrease. Closes #194.
🏷 What kind of change is this?

:bank: Refactoring/debt/DX (improvement to code design, tooling, documentation etc. without changing behaviour)

♻ Anything particular you want feedback on?

Whether there is any opportunity to optimise the Cucumber logo - currently 33KB. SVG images are not accepted.
Whether the provided GitHub CDN URLs are acceptable or need to be defined at a different GitHub CDN domain.

📋 Checklist:

[x] I agree to respect and uphold the Cucumber Community Code of Conduct
[x] Users should know about my change

[x] I have added an entry to the "Unreleased" section of the CHANGELOG, linking to this pull request.

Summary
I think in essence it's a question of: "Do we want to store documentation images in git?" - which is probably a point of preference.
My answer to that question would have been 'no' as they are not necessarily part of the extension, however looking at Microsoft-developed extensions - storing them within git appears to be their in-house convention - so I have no problem adhering to that.
With that in mind, shall I proceed to revert the images to the repository, link their GitHub CDN references on the raw subdomain, and exclude them from the bundle? Will give the desired outcome of optimising the bundle size.
Detail

Solution wise, looking at plugins published by MS, they link to to https://raw.githubusercontent.com. That seems a reasonable way to go. I suppose you would then exclude the images from being bundled with VSCode.
https://marketplace.visualstudio.com/items?itemName=ms-python.python
And see: https://raw.githubusercontent.com/microsoft/vscode-python/main/README.md

Yes, the two distinct approaches to prevent including the images in the bundle appear to be either:

Commit images to git, and then reference them via the raw subdomain (raw.githubusercontent.com) rather than their relative path. In the example, this is via the main branch
<img src=https://raw.githubusercontent.com/microsoft/vscode-python/main/images/OpenOrCreateNotebook.gif width=1029 height=602>

From the Cucumber Extension in the marketplace, if you open an image in a new tab, you will observe that it currently uses this domain - thus, including the images in the bundle is redundant.
Storing image binaries in git repositories that do not relate to the software can have its own challenges, though is a divisive and opinionated topic.

The other option is to create a fix link for them in the GitHub CDN for that project. This can be done by opening the project in GitHub and either copying the image into an Issue or the web editor - GitHub will create the links for you.
![Using the "Quick Fix" action to fix a violation](https://user-images.githubusercontent.com/1309177/205176932-44cfc03a-120f-4bad-b710-612bdd7765d6.gif)

Examples
Extensions storing images in git

Microsoft extensions, however there are some exceptions (see below)
Precommit Helper
etc.

Extensions storing images

Ruff - astral - November 2022
Live Share - microsoft - created January 2018
Remote Development - microsoft - created May 2019
Makefile Tools - microsoft - created Februrary 2021
etc.

With that in mind, shall I proceed to revert the images to the repository, link their GitHub CDN references on the raw subdomain, and exclude them from the bundle?

Okay. Please use tbe raw subdomain.
It has two advantages

It keeps everything in version control and available. Once the CDN is used, the origin image is "gone".
The raw domain uses the actual path to the file. This makes it possible for people to find the resource.

@kieran-ryan I think your force push messed things up a bit.

@mpkorstanje updated now. Have additionally provided a before and after of the directory structure in the PR description; and changed to a whitelisting strategy for including files in the bundle - which should be less susceptible to introducing redundant artifacts.


Investigate Dockerfile issue (change made on 1/12/2023)

Is there further documentation on the issue here that can be referenced for others?

this one was copy/pasted out of of tracking spreadsheet the app team was using before we migrated to github - @thehannahlerman, @sebruiz or @bcinman will have the insight


Release parquet-mr 1.11.0

Reporter: Nándor Kollár / @nandorKollar
Assignee: Gabor Szadovszky / @gszadovszky
Related issues:

Upgrade parquet to 1.11.1 (blocks)
Start using the new logical types API of Parquet 1.11.0 instead of the deprecated one (blocks)
Use Parquet LogicalTypes (blocks)
Parquet support for TIMESTAMP WITH LOCAL TIME ZONE (blocks)
Parquet support for TIMESTAMP WITHOUT TIME ZONE (blocks)
UserDefinedPredicate throw NPE (is blocked by)
Page row count limit causes empty pages to be written from MessageColumnIO (is blocked by)
Implement unit test to validate column/offset indexes (is blocked by)
Publish 1.11.0 to maven central (is duplicated by)

Note: This issue was originally created as PARQUET-1434. Please see the migration documentation for further details.

Ke Li:
Any updates about this?

Ryan Blue / @rdblue:
My concern is that it has not been reviewed well enough to be confident that the write path implements the spec correctly. So there aren't specific issues to address.
I made suggestions on an integration test Zoltan wrote, but that wasn't committed to the Parquet repository. Getting that cleaned up and committed is the only thing I can think of for now.

Junjie Chen / @chenjunjiedada:
@gszadovszky,  What remaining contents are still in discussing? Could you please help to list here or put some links to the discussions?

Yuming Wang / @wangyum:
https://github.com/apache/parquet-mr/releases/tag/apache-parquet-1.11.0
It didn't pushed to maven repository?

Gabor Szadovszky / @gszadovszky:
@rdblue, is it possible to create jiras about your concerns related to column indexes and link them here?

Gabor Szadovszky / @gszadovszky:
Unfortunately, we still don't have consensus about the content of this release.

Nándor Kollár / @nandorKollar:
@wangyum the release is not yet finished, voting is not yet closed.

Gabor Szadovszky / @gszadovszky:
That one is the last release candidate. I think, it is stable but until it is released the community would not give any support. That's why I've suggested to update a released version with the fix you need (e.g. 1.10.1). That would be the safest choice.

Gabor Szadovszky / @gszadovszky:
Still waiting for the community to approve the column-indexes feature.
PARQUET-968 is an early fix just after 1.10.0. So, if you need it ASAP, I would suggest creating you own build by cherry-picking the fix on the top of apache-parquet-1.10.0.

Gabor Szadovszky / @gszadovszky:
@rdblue,
I've created PARQUET-1650 to track the latter one. Also, I have a PR for it. Could you check that out?

George Haddad:
@gszadovszky is this stable enough: https://github.com/apache/parquet-mr/releases/tag/apache-parquet-1.11.0 ?

George Haddad:
Any ETA on this?
Been waiting for https://issues.apache.org/jira/browse/PARQUET-968 for a while and we really need this ASAP.


chore: disable lean4checker in regular CI

Expect ~12 minutes off every single CI run!

Thank you: I'm very happy with this!
I reviewed the PR, but honestly I trust more the fact that it passed CI than my review!

Nice!
bors d+

bors merge


Elaborated kns members and ministers

Create a service which elaborate about a specific current kns member, and another service which elaborate  about a specific current minister. Both services needs to get an id as  an argument to get info from db.
No id argument will result in showing error page.

Done


Update WalletMainView.qml

responsive to project - disable channel tab.

Looks good. Just need one tester to confirm the GUI display is as intended.


Imageuploader not resetting after images are uploaded

When images are uploaded, i am sending back empty array to set selected images to [], but even as the selected images have become [] they are showing in the preview.

For the ones searching for a quick fix..
Add an ref to your component
  <ImageUploader               ref={this.myRef}
In your constructor:
 this.myRef = React.createRef();
In the function which will be called after success upload:
     this.setState({pictures: []});       this.myRef.current.state.pictures = [];

So I was able to find a workaround. The reference has its own state that can be accessed.
const imageUploadRef = useRef(null);
<ImageUploader ref={imageUploadRef} ... />
Reset all uploads after onChange call
imageUploadRef.current.state.pictures = [];
imageUploadRef.current.state.files = [];

So I was able to find a workaround. The reference has its own state that can be accessed.
const imageUploadRef = useRef(null);
<ImageUploader ref={imageUploadRef} ... />
Reset all uploads after onChange call
imageUploadRef.current.state.pictures = [];
imageUploadRef.current.state.files = [];


Rot90 in all 4 possible rotations, k=imgaug.ALL gives error

Considering the documentation for:
imgaug.augmenters.geometric.Rot90(k, keep_size=True, name=None, deterministic=False, random_state=None)
k is defined to be an int, list of int, tuple of int or imgaug.ALL, where imgaug.ALL, then equivalant to list [0, 1, 2, 3].
Since I'm interested in all four possible rotations I try with k = imgaug.ALL but receive the following error:
Traceback (most recent call last):
File "", line 1, in
File "/snap/pycharm-community/150/helpers/pydev/_pydev_bundle/pydev_umd.py", line 197, in runfile
pydev_imports.execfile(filename, global_vars, local_vars)  # execute the script
File "/snap/pycharm-community/150/helpers/pydev/_pydev_imps/_pydev_execfile.py", line 18, in execfile
exec(compile(contents+"\n", file, 'exec'), glob, loc)
File ".../test_lib_imgaug.py", line 18, in
rotate = iaa.geometric.Rot90(k=imgaug.ALL, keep_size=True, name=None, deterministic=False, random_state=None)
File ".../lib/python3.6/site-packages/imgaug/augmenters/geometric.py", line 3138, in init
allow_floats=False)
File ".../lib/python3.6/site-packages/imgaug/parameters.py", line 98, in handle_discrete_param
name, "number" if allow_floats else "integer", [type(v) for v in param],))
File .../lib/python3.6/site-packages/imgaug/imgaug.py", line 1869, in do_assert
raise AssertionError(str(message))
AssertionError: Expected iterable parameter 'k' to only contain integer, got [<class 'str'>, <class 'str'>, <class 'str'>].
It seems like it's not possible to use k=imgaug.ALL as an argument? Or could you please explain how to be able to retrieve all 4 rotations.

Yes, the docstring and actual implementation are not in sync there.
To get all rotations use Rot90((0, 3)) or Rot90([0, 1, 2, 3]).

Using Rot90((0, 3)) or Rot90([0, 1, 2, 3]) only return one of the rotations, not all four.  So far, looping through all four indices, one at the time, seems to be the solution.

Rot90 now supports imgaug.ALL in master.
But if your goal is to get for each image always all four possible rotations, then a loop is still your best choice as the library is not really made for that use case. Though you can then feed all images through the augmenter in each iteration, so its only four calls, independent of the number of images.

Okey,  then I go for that. Thanks for the update!


The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client

I always get this error whenever I synced my charging sessions via the app via bluetooth.
Even restarting the esp32 does not help. The weird thing is that when I reupload the firmware it can create a bluetooth connection again.
INFO ESPHome 2024.6.4
INFO Reading configuration /config/esphome/nexxtender.yaml...
INFO Updating https://github.com/geertmeersman/nexxtender@None
INFO Detected timezone 'Europe/Brussels'
WARNING GPIO0 is a strapping PIN and should only be used for I/O with care.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
INFO Starting log output from <IP_ADDRESS> using esphome API
INFO Successfully connected to nexxtender @ <IP_ADDRESS> in 0.131s
WARNING nexxtender @ <IP_ADDRESS>: Connection error occurred: nexxtender @ <IP_ADDRESS>: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.6.4).
WARNING Can't connect to ESPHome API for nexxtender @ <IP_ADDRESS>: nexxtender @ <IP_ADDRESS>: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.6.4). (HandshakeAPIError)
INFO Trying to connect to nexxtender @ <IP_ADDRESS> in the background
INFO Successfully connected to nexxtender @ <IP_ADDRESS> in 0.044s
WARNING nexxtender @ <IP_ADDRESS>: Connection error occurred: nexxtender @ <IP_ADDRESS>: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.6.4).
INFO Successfully connected to nexxtender @ <IP_ADDRESS> in 0.074s
WARNING nexxtender @ <IP_ADDRESS>: Connection error occurred: nexxtender @ <IP_ADDRESS>: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.6.4).
INFO Successfully connected to nexxtender @ <IP_ADDRESS> in 0.052s

Hi @cosmos1978 , can you check with ESPHome 2024.6.4
Have seen a lot of issues linked to the encryption (not linked at all with my code I fear)
https://github.com/esphome/issues/issues/5790

Which config are you using for the api part?

Using a ESP 32 and getting the following error "The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.6.6)."
I have an encryption key in the code and upload to device.

Can you share the config (differences from the one in my packages)?

I had no encryptrion key configured in the api section.
It was empty. I added the encryption key from the secrets file as I did for other esphome devices I i use.
I will do some tests to see if it improves with this change.

Ok, thanks. I just upgraded to the latest esphome version and am still unable to reproduce your issue

Still the same issue.
[20:38:18][W][component:237]: Component esp32_ble took a long time for an operation (77 ms). [20:38:18][W][component:238]: Components should block for at most 30 ms. [20:38:20][D][esp32_ble_client:110]: [0] [D9:D9:E7:B1:F6:FC] ESP_GATTC_READ_CHAR_EVT [20:38:20][D][text_sensor:064]: 'Generic data': Sending state '\xde.\x8cf' [20:38:22][D][sensor:094]: 'Car P1': Sending state 0.00000 kW with 2 decimals of accuracy [20:38:22][D][sensor:094]: 'Car P3': Sending state -0.00100 kW with 2 decimals of accuracy [20:38:22][D][sensor:094]: 'Car Current': Sending state 0.00000 A with 1 decimals of accuracy [20:38:22][D][sensor:094]: 'Grid Power': Sending state 3260.00000 W with 0 decimals of accuracy [20:38:23][D][esp32_ble_client:110]: [0] [D9:D9:E7:B1:F6:FC] ESP_GATTC_READ_CHAR_EVT [20:38:23][D][text_sensor:064]: 'Serial Number': Sending state '2222-00013' [20:38:23][D][esp32_ble_client:110]: [0] [D9:D9:E7:B1:F6:FC] ESP_GATTC_NOTIFY_EVT [20:38:23][D][text_sensor:064]: 'nexxtender_charging_car_data': Sending state '//\x8cf' [20:38:23][D][nexxtender_charging_car_data:075]: 2F.2F.8C.<IP_ADDRESS>.<IP_ADDRESS>.00.FF.FF.00.00.88.CE (18) [20:38:23][D][esp32_ble_client:110]: [0] [D9:D9:E7:B1:F6:FC] ESP_GATTC_NOTIFY_EVT [20:38:23][D][text_sensor:064]: 'nexxtender_charging_grid_data': Sending state '//\x8cf' [20:38:23][D][nexxtender_charging_grid_data:075]: 2F.2F.8C.<IP_ADDRESS>.<IP_ADDRESS>.00.07.FF.C0.C3 (16) [20:38:23][D][esp32_ble_client:110]: [0] [D9:D9:E7:B1:F6:FC] ESP_GATTC_NOTIFY_EVT [20:38:23][D][text_sensor:064]: 'nexxtender_charging_basic_data': Sending state '' [20:38:23][D][nexxtender_charging_basic_data:075]: <IP_ADDRESS>.<IP_ADDRESS>.<IP_ADDRESS>.00.00 (14) [20:38:23][D][text_sensor:064]: 'Discriminator': Sending state 'Stopped' [20:38:23][D][text_sensor:064]: 'Status': Sending state 'Unplugged' [20:38:23][D][sensor:094]: 'Charging Phase Count': Sending state 0.00000  with 0 decimals of accuracy WARNING nexxtender @ <IP_ADDRESS>: Connection error occurred: [Errno 104] Connection reset by peer INFO Processing unexpected disconnect from ESPHome API for nexxtender @ <IP_ADDRESS> WARNING Disconnected from API WARNING Can't connect to ESPHome API for nexxtender @ <IP_ADDRESS>: Error connecting to [AddrInfo(family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, proto=6, sockaddr=IPv4Sockaddr(address='<IP_ADDRESS>', port=6053))]: [Errno 111] Connect call failed ('<IP_ADDRESS>', 6053) (SocketAPIError) INFO Trying to connect to nexxtender @ <IP_ADDRESS> in the background INFO Successfully connected to nexxtender @ <IP_ADDRESS> in 0.031s WARNING nexxtender @ <IP_ADDRESS>: Connection error occurred: nexxtender @ <IP_ADDRESS>: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.6.6). INFO Successfully connected to nexxtender @ <IP_ADDRESS> in 0.014s WARNING nexxtender @ <IP_ADDRESS>: Connection error occurred: nexxtender @ <IP_ADDRESS>: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.6.6). INFO Successfully connected to nexxtender @ <IP_ADDRESS> in 0.015s WARNING nexxtender @ <IP_ADDRESS>: Connection error occurred: nexxtender @ <IP_ADDRESS>: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.6.6). INFO Successfully connected to nexxtender @ <IP_ADDRESS> in 0.014s WARNING nexxtender @ <IP_ADDRESS>: Connection error occurred: nexxtender @ <IP_ADDRESS>: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.6.6). INFO Successfully connected to nexxtender @ <IP_ADDRESS> in 0.051s WARNING nexxtender @ <IP_ADDRESS>: Connection error occurred: nexxtender @ <IP_ADDRESS>: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.6.6). INFO Successfully connected to nexxtender @ <IP_ADDRESS> in 0.017s WARNING nexxtender @ <IP_ADDRESS>: Connection error occurred: nexxtender @ <IP_ADDRESS>: The connection dropped immediately after encrypted hello; Try enabling encryption on the device or turning off encryption on the client (ESPHome Logs 2024.6.6). INFO Successfully connected to nexxtender @ <IP_ADDRESS> in 0.013s
Config
`packages:
nexxtender:
url: https://github.com/geertmeersman/nexxtender
files: [config/nexxtender.yaml, config/nexxtender_packages/webserver.yaml]
refresh: 0s
substitutions:
name: "nexxtender"
friendly_name: nexxtender BLE
Uncomment and modify when you want to use a different threshold.
charging_mode_eco_threshold: "8"      # Single phase (6A + 2 margin)
charging_mode_eco_bi_threshold: "14"  # Bi-phase (12A + 2 margin)
charging_mode_eco_tri_threshold: "20" # Tri-phase (18A + 2 margin)
slider_max_car_charging_speed: "32"     # The max value of the slider for the maximum car charging speed slider, default set to 32
slider_max_available_capacity: "40"     # The max value of the slider for the maximum available capacity slider, default set to 40
esphome:
name: ${name}
friendly_name: ${friendly_name}
name_add_mac_suffix: false
project:
name: esphome.web
version: '1.0'
esp32:
board: esp32dev
Enable logging
logger:
Enable Home Assistant API
api:
encryption:
key: !secret esphome_api_key
Allow Over-The-Air updates
ota:
Allow provisioning Wi-Fi via serial
improv_serial:
wifi:
Set up a wifi access point
ap: {}
In combination with the ap this allows the user
to provision wifi credentials to the device via WiFi AP.
captive_portal:
dashboard_import:
package_import_url: github://esphome/example-configs/esphome-web/esp32.yaml@main
import_full_config: true
Sets up Bluetooth LE (Only on ESP32) to allow the user
to provision wifi credentials to the device.
esp32_improv:
authorizer: none
To have a "next url" for improv serial
web_server:
`

Config
`
packages:
nexxtender:
url: https://github.com/geertmeersman/nexxtender
files: [config/nexxtender.yaml, config/nexxtender_packages/webserver.yaml]
refresh: 0s
substitutions:
name: "nexxtender"
friendly_name: nexxtender BLE
Uncomment and modify when you want to use a different threshold.
charging_mode_eco_threshold: "8"      # Single phase (6A + 2 margin)
charging_mode_eco_bi_threshold: "14"  # Bi-phase (12A + 2 margin)
charging_mode_eco_tri_threshold: "20" # Tri-phase (18A + 2 margin)
slider_max_car_charging_speed: "32"     # The max value of the slider for the maximum car charging speed slider, default set to 32
slider_max_available_capacity: "40"     # The max value of the slider for the maximum available capacity slider, default set to 40
esphome:
name: ${name}
friendly_name: ${friendly_name}
name_add_mac_suffix: false
project:
name: esphome.web
version: '1.0'
esp32:
board: esp32dev
Enable logging
logger:
Enable Home Assistant API
api:
encryption:
key: !secret esphome_api_key
Allow Over-The-Air updates
ota:
Allow provisioning Wi-Fi via serial
improv_serial:
wifi:
Set up a wifi access point
ap: {}
In combination with the ap this allows the user
to provision wifi credentials to the device via WiFi AP.
captive_portal:
dashboard_import:
package_import_url: github://esphome/example-configs/esphome-web/esp32.yaml@main
import_full_config: true
Sets up Bluetooth LE (Only on ESP32) to allow the user
to provision wifi credentials to the device.
esp32_improv:
authorizer: none
To have a "next url" for improv serial
web_server:
`

I now removed everything from the yaml file besides packages: and esphome: like in the example since the api config is included via the url option.
So it had 2 api sections.
lets see if it is more stable now

nope still the same.
works for some time and then the error pops up
`substitutions:
Uncomment and modify when you want to use a different device name.
device_name: nexxtender
friendly_name: Nexxtender
Uncomment and modify when you want to use a different threshold.
charging_mode_eco_threshold: "8"      # Single phase (6A + 2 margin)
charging_mode_eco_bi_threshold: "14"  # Bi-phase (12A + 2 margin)
charging_mode_eco_tri_threshold: "20" # Tri-phase (18A + 2 margin)
slider_max_car_charging_speed: "32"     # The max value of the slider for the maximum car charging speed slider, default set to 32
slider_max_available_capacity: "40"     # The max value of the slider for the maximum available capacity slider, default set to 40
`

I fear it somehow is linked to esphome and not really to my code...

ah, I see your ota section:
Since june esphome changed the ota configuration.
ota:
  - platform: esphome

https://github.com/geertmeersman/nexxtender/commit/fe5bd5264518b33e518cb64923e27c42b7357d93

give it a try

Yes adding the correct ota setting fixed it

What does it mean that you corrected the OTA because I have the same error :)

With the latest code? as here: https://github.com/geertmeersman/nexxtender/commit/fe5bd5264518b33e518cb64923e27c42b7357d93


Set hxcpp to version 3.2.205 [y/n/a] ? n

Prompts to update hxcpp to a previous version even though I have the latest applied.
haxelib upgrade
...
Set hxcpp to version 3.2.205 [y/n/a] ? n
....
haxelib list
hxcpp: 3.2.102 3.2.171 3.2.180 3.2.193 3.2.205 [3.2.94]

It is a newer version, patch 205 > patch 94,
the listing isn't in the right order.
Fixed but not yet deployed (https://github.com/HaxeFoundation/haxelib/issues/83), same for the website (https://github.com/HaxeFoundation/haxelib/issues/236)

Is this still not deployed? Still keeps setting it to previous version and breaking build.
hxcpp: 3.2.102 3.2.171 3.2.180 3.2.193 [3.2.205] 3.2.94

The website was deployed but not the tool,
3.2.205 is still the latest though,
do you mean that it changes on its own?

When I run haxelib upgrade, it tries to set version as 3.2.205 when in fact it should be 3.2.94

No no, hxcpp 3.2.205 was released after 3.2.94,
205 > 94
it's the list that's not in order.
3.2.94 : 2015-05-11
3.2.205 : 2015-12-24
there's even 4 versions between them
http://lib.haxe.org/p/hxcpp/versions/

Oh right, I thought it was an old version as when I try and build with hxcpp I get:
Library hxcpp version 3.2.205 does not have a run script

Seems to be a known issue https://groups.google.com/forum/#!topic/haxeflixel/1Sor7iv7c5w

Ehm, I guess hxcpp 3.2.205 has been reuploaded with a run script. Anyway, this is not a haxelib issue.


[Minor]change log info and if-else logic in metadata table

A little change want to do during reading meta data table related code.

Wrong describe for  warn log HoodieMetadataConfig.IGNORE_SPURIOUS_DELETES.key() + " config is set to false" ->  HoodieMetadataConfig.IGNORE_SPURIOUS_DELETES.key() + " config is set to true"
do metadataConfig.ignoreSpuriousDeletes() instead of !metadataConfig.ignoreSpuriousDeletes() (a little confusing). Maybe can just ignore when set ignore true.
some typos.

Verify this pull request
(Please pick either of the following options)
This pull request is a trivial rework / code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end.
Added HoodieClientWriteTest to verify the change.
Manually verified the change by running a job locally.

Committer checklist

[ ] Has a corresponding JIRA in PR title & commit

[ ] Commit message is descriptive of the change

[ ] CI is green

[ ] Necessary doc changes done or have another open PR

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

Hi @nsivabalan and @yihua would you mind to take a look at your convince? Thanks a lot !

@nsivabalan do you want to double check the changes?


Fixed issue with ApiKey in home directory

Checklist

[ ] I've run bundle exec rspec from the root directory to see all new and existing tests pass
[ ] I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary.

I cannot run the rspec and rubocop on M1 somehow...

Motivation and Context
If you want to specify where the api key is stored, you are not able to use home directory. Ruby by default does not expand path of ~/ to /Users/username/

Description
When checking if the file exists, we need to first expand the path.
Not sure if this is correct solution and I don't have an idea how to add a testcase for this scenario (due to zero knowledge about CI runners fastlane uses) so would love to get some feedback.
Testing Steps

@googlebot I signed it!


40_Text_to_Speech_Generation example notebook throws a ContextualVersionConflict error

Running this cell in the tts example notebook  on google colab:
%%capture

from txtai.pipeline import TextToSpeech

# Create text-to-speech model
tts = TextToSpeech()

throws the following exception:
ContextualVersionConflict                 Traceback (most recent call last)
[<ipython-input-2-fd4b30fd0bec>](https://localhost:8080/#) in <module>
----> 1 from txtai.pipeline import TextToSpeech
      2
      3 # Create text-to-speech model
      4 tts = TextToSpeech()

11 frames
[/usr/local/lib/python3.8/dist-packages/txtai/pipeline/__init__.py](https://localhost:8080/#) in <module>
     13 from .text import *
     14 from .tensors import Tensors
---> 15 from .train import *

[/usr/local/lib/python3.8/dist-packages/txtai/pipeline/train/__init__.py](https://localhost:8080/#) in <module>
      5 from .hfonnx import HFOnnx
      6 from .hftrainer import HFTrainer
----> 7 from .mlonnx import MLOnnx

[/usr/local/lib/python3.8/dist-packages/txtai/pipeline/train/mlonnx.py](https://localhost:8080/#) in <module>
      6
      7 try:
----> 8     from onnxmltools import convert_sklearn
      9     from onnxmltools.convert.common.data_types import StringTensorType
     10

[/usr/local/lib/python3.8/dist-packages/onnxmltools/__init__.py](https://localhost:8080/#) in <module>
     23 from .convert import convert_h2o
     24 from .convert import convert_catboost
---> 25 from .utils import load_model
     26 from .utils import save_model

[/usr/local/lib/python3.8/dist-packages/onnxmltools/utils/__init__.py](https://localhost:8080/#) in <module>
      1 # SPDX-License-Identifier: Apache-2.0
      2
----> 3 from .main import load_model
      4 from .main import save_model
      5 from .main import set_model_version

[/usr/local/lib/python3.8/dist-packages/onnxmltools/utils/main.py](https://localhost:8080/#) in <module>
      2
      3 import os
----> 4 from ..proto import onnx_proto
      5 from ..convert.common import utils as convert_utils
      6 from os import path

[/usr/local/lib/python3.8/dist-packages/onnxmltools/proto/__init__.py](https://localhost:8080/#) in <module>
     19
     20
---> 21 _check_onnx_version()
     22
     23

[/usr/local/lib/python3.8/dist-packages/onnxmltools/proto/__init__.py](https://localhost:8080/#) in _check_onnx_version()
     15     import pkg_resources
     16     min_required_version = pkg_resources.parse_version('1.0.1')
---> 17     current_version = pkg_resources.get_distribution('onnx').parsed_version
     18     assert current_version >= min_required_version, 'ONNXMLTools requires ONNX version 1.0.1 or a newer one'
     19

[/usr/local/lib/python3.8/dist-packages/pkg_resources/__init__.py](https://localhost:8080/#) in get_distribution(dist)
    464         dist = Requirement.parse(dist)
    465     if isinstance(dist, Requirement):
--> 466         dist = get_provider(dist)
    467     if not isinstance(dist, Distribution):
    468         raise TypeError("Expected string, Requirement, or Distribution", dist)

[/usr/local/lib/python3.8/dist-packages/pkg_resources/__init__.py](https://localhost:8080/#) in get_provider(moduleOrReq)
    340     """Return an IResourceProvider for the named module or requirement"""
    341     if isinstance(moduleOrReq, Requirement):
--> 342         return working_set.find(moduleOrReq) or require(str(moduleOrReq))[0]
    343     try:
    344         module = sys.modules[moduleOrReq]

[/usr/local/lib/python3.8/dist-packages/pkg_resources/__init__.py](https://localhost:8080/#) in require(self, *requirements)
    884         included, even if they were already activated in this working set.
    885         """
--> 886         needed = self.resolve(parse_requirements(requirements))
    887
    888         for dist in needed:

[/usr/local/lib/python3.8/dist-packages/pkg_resources/__init__.py](https://localhost:8080/#) in resolve(self, requirements, env, installer, replace_conflicting, extras)
    775                 # Oops, the "best" so far conflicts with a dependency
    776                 dependent_req = required_by[req]
--> 777                 raise VersionConflict(dist, req).with_context(dependent_req)
    778
    779             # push the new requirements onto the stack

ContextualVersionConflict: (protobuf 3.19.6 (/usr/local/lib/python3.8/dist-packages), Requirement.parse('protobuf<4,>=3.20.2'), {'onnx'})

Some base Colab packages need a restart and rerun after upgrading. Usually that resolves issues like this.

Thanks. Restarting the kernel fixes it. I made PR #410 to document this behavior in case it will be useful for future users.

Coming to this from #442
I'm just getting started with Colab, but it appears fairly obvious to the above for me that I can't restart the runtime. Is the runtime equivalent to the kernel?
If not, how do I restart the kernel?
Thanks

Leaving for future incomers, as I'm sure there will be many to this awesome project.

To resolve, run everything, run into the error with dependencies, and then restart the runtime and run everything again.