text:
How do I activate the endorser in a docker-compose instance of Traction?

I have Traction running locally using docker compose.  I'd like to use the Endorser to be able to write transactions to the BCovrin Network.  Here's how far I have gotten so far:
In the Traction Dashboard -> User -> Profile -> Endorser, there is a message Innkeeper has not approved endorser connections.
In the Innkeeper -> Tenants -> Settings I can activate the Endorser and registering a Public DID.
Back in the Traction Dashboard -> User -> Profile -> Endorser, I can now toggle the "Connect Tenant To Endorser", but after activating it, the status stays at Connection not Active yet, refresh or come back later. State: request.
I tried looking at the Endorser side, and according to the "Get Connections" endpoint, the Endorser has one connection and it is active has no connections.
What do I do next?  I think the .env settings are all correct, but not sure...what should I be checking?

Some progress.  Reviewing the Endorser logs exposed the following (see below).
Got past that by adding requests-through-public-did: true to the endorser-acapy-args.yml file.  This was added after the previous version of ACA-Py used in Traction was tagged (after 1.0.0-rc1).  I'll submit a PR to add it to traction.
scripts-endorser-agent-1                | 2023-06-06 20:16:07,313 aiohttp.access INFO 172.21.0.1 [06/Jun/2023:20:16:07 +0000] "POST / HTTP/1.1" 200 149 "-" "Python/3.6 aiohttp/3.8.4"
scripts-endorser-agent-1                | 2023-06-06 20:16:07,321 aries_cloudagent.connections.base_manager WARNING No corresponding DID found for sender verkey: B3g3C7n9hkPqm53vgP2DLGMWaENGVLiNo2nyq6Fb3N1L
scripts-endorser-agent-1                | 2023-06-06 20:16:07,351 aries_cloudagent.messaging.base_handler ERROR Error receiving RFC 23 connection request
scripts-endorser-agent-1                | Traceback (most recent call last):
scripts-endorser-agent-1                |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/aries_cloudagent/protocols/didexchange/v1_0/handlers/request_handler.py", line 44, in handle
scripts-endorser-agent-1                |     else context.message_receipt.recipient_verkey
scripts-endorser-agent-1                |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/aries_cloudagent/protocols/didexchange/v1_0/manager.py", line 488, in receive_request
scripts-endorser-agent-1                |     "Unsolicited connection requests to " "public DID is not enabled"
scripts-endorser-agent-1                | aries_cloudagent.protocols.didexchange.v1_0.manager.DIDXManagerError: Unsolicited connection requests to public DID is not enabled

After the previous fix was applied, a problem still exists. When the endorser is trying to respond to the connection request from the Tenant, it is getting a 403.  Likely something in the Docker setup.
scripts-endorser-agent-1  | 2023-06-06 20:46:36,203 aries_cloudagent.transport.outbound.manager ERROR >>> Error when posting to: http://endorser-api:5000/webhook/topic/connections/; Error: (<class 'aries_cloudagent.transport.outbound.base.OutboundTransportError'>, OutboundTransportError('Unexpected response status 403, caused by: Forbidden',), <traceback object at 0x7fbee96aeac8>); Re-queue failed message ...
scripts-endorser-agent-1  | 2023-06-06 20:46:36,707 aries_cloudagent.transport.outbound.manager ERROR >>> Error when posting to: http://endorser-api:5000/webhook/topic/connections/; Error: (<class 'aries_cloudagent.transport.outbound.base.OutboundTransportError'>, OutboundTransportError('Unexpected response status 403, caused by: Forbidden',), <traceback object at 0x7fbee96aed48>); Re-queue failed message ...
scripts-endorser-agent-1  | 2023-06-06 20:46:36,759 aries_cloudagent.transport.outbound.manager ERROR >>> Error when posting to: http://endorser-api:5000/webhook/topic/connections/; Error: (<class 'aries_cloudagent.transport.outbound.base.OutboundTransportError'>, OutboundTransportError('Unexpected response status 403, caused by: Forbidden',), <traceback object at 0x7fbee96b4048>); Re-queue failed message ...
scripts-endorser-agent-1  | 2023-06-06 20:46:36,761 aries_cloudagent.transport.outbound.manager ERROR >>> Error when posting to: http://endorser-api:5000/webhook/topic/ping/; Error: (<class 'aries_cloudagent.transport.outbound.base.OutboundTransportError'>, OutboundTransportError('Unexpected response status 403, caused by: Forbidden',), <traceback object at 0x7fbee96b4288>); Re-queue failed message ...
scripts-endorser-agent-1  | 2023-06-06 20:46:46,112 aries_cloudagent.transport.outbound.manager ERROR >>> Error when posting to: http://endorser-api:5000/webhook/topic/connections/; Error: (<class 'aries_cloudagent.transport.outbound.base.OutboundTransportError'>, OutboundTransportError('Unexpected response status 403, caused by: Forbidden',), <traceback object at 0x7fbee96aef48>); Re-queue failed message ...
scripts-endorser-agent-1  | 2023-06-06 20:46:46,212 aries_cloudagent.transport.outbound.manager ERROR >>> Error when posting to: http://endorser-api:5000/webhook/topic/connections/; Error: (<class 'aries_cloudagent.transport.outbound.base.OutboundTransportError'>, OutboundTransportError('Unexpected response status 403, caused by: Forbidden',), <traceback object at 0x7fbee96ae0c8>); Re-queue failed message ...
scripts-endorser-agent-1  | 2023-06-06 20:46:46,716 aries_cloudagent.transport.outbound.manager ERROR >>> Error when posting to: http://endorser-api:5000/webhook/topic/connections/; Error: (<class 'aries_cloudagent.transport.outbound.base.OutboundTransportError'>, OutboundTransportError('Unexpected response status 403, caused by: Forbidden',), <traceback object at 0x7fbee9719688>); Re-queue failed message ...
scripts-endorser-agent-1  | 2023-06-06 20:46:46,768 aries_cloudagent.transport.outbound.manager ERROR >>> Error when posting to: http://endorser-api:5000/webhook/topic/connections/; Error: (<class 'aries_cloudagent.transport.outbound.base.OutboundTransportError'>, OutboundTransportError('Unexpected response status 403, caused by: Forbidden',), <traceback object at 0x7fbee96ac448>); Re-queue failed message ...
scripts-endorser-agent-1  | 2023-06-06 20:46:46,770 aries_cloudagent.transport.outbound.manager ERROR >>> Error when posting to: http://endorser-api:5000/webhook/topic/ping/; Error: (<class 'aries_cloudagent.transport.outbound.base.OutboundTransportError'>, OutboundTransportError('Unexpected response status 403, caused by: Forbidden',), <traceback object at 0x7fbee96acd88>); Re-queue failed message ...
scripts-endorser-agent-1  | 2023-06-06 20:46:56,126 aries_cloudagent.transport.outbound.manager ERROR >>> Outbound message failed to deliver, NOT Re-queued.
scripts-endorser-agent-1  | Traceback (most recent call last):
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/asyncio/tasks.py", line 180, in _step
scripts-endorser-agent-1  |     result = coro.send(None)
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/aries_cloudagent/transport/outbound/http.py", line 87, in handle_message
scripts-endorser-agent-1  |     f"Unexpected response status {response.status}, "
scripts-endorser-agent-1  | aries_cloudagent.transport.outbound.base.OutboundTransportError: Unexpected response status 403, caused by: Forbidden
scripts-endorser-agent-1  | 2023-06-06 20:46:56,170 aries_cloudagent.transport.outbound.manager ERROR Outbound message could not be delivered to http://endorser-api:5000/webhook/topic/connections/
scripts-endorser-agent-1  | Traceback (most recent call last):
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/asyncio/tasks.py", line 180, in _step
scripts-endorser-agent-1  |     result = coro.send(None)
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/aries_cloudagent/transport/outbound/http.py", line 87, in handle_message
scripts-endorser-agent-1  |     f"Unexpected response status {response.status}, "
scripts-endorser-agent-1  | aries_cloudagent.transport.outbound.base.OutboundTransportError: Unexpected response status 403, caused by: Forbidden
scripts-endorser-agent-1  | 2023-06-06 20:46:56,222 aries_cloudagent.transport.outbound.manager ERROR >>> Outbound message failed to deliver, NOT Re-queued.
scripts-endorser-agent-1  | Traceback (most recent call last):
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/asyncio/tasks.py", line 180, in _step
scripts-endorser-agent-1  |     result = coro.send(None)
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/aries_cloudagent/transport/outbound/http.py", line 87, in handle_message
scripts-endorser-agent-1  |     f"Unexpected response status {response.status}, "
scripts-endorser-agent-1  | aries_cloudagent.transport.outbound.base.OutboundTransportError: Unexpected response status 403, caused by: Forbidden
scripts-endorser-agent-1  | 2023-06-06 20:46:56,271 aries_cloudagent.transport.outbound.manager ERROR Outbound message could not be delivered to http://endorser-api:5000/webhook/topic/connections/
scripts-endorser-agent-1  | Traceback (most recent call last):
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/asyncio/tasks.py", line 180, in _step
scripts-endorser-agent-1  |     result = coro.send(None)
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/aries_cloudagent/transport/outbound/http.py", line 87, in handle_message
scripts-endorser-agent-1  |     f"Unexpected response status {response.status}, "
scripts-endorser-agent-1  | aries_cloudagent.transport.outbound.base.OutboundTransportError: Unexpected response status 403, caused by: Forbidden
scripts-endorser-agent-1  | 2023-06-06 20:46:56,728 aries_cloudagent.transport.outbound.manager ERROR >>> Outbound message failed to deliver, NOT Re-queued.
scripts-endorser-agent-1  | Traceback (most recent call last):
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/asyncio/tasks.py", line 180, in _step
scripts-endorser-agent-1  |     result = coro.send(None)
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/aries_cloudagent/transport/outbound/http.py", line 87, in handle_message
scripts-endorser-agent-1  |     f"Unexpected response status {response.status}, "
scripts-endorser-agent-1  | aries_cloudagent.transport.outbound.base.OutboundTransportError: Unexpected response status 403, caused by: Forbidden
scripts-endorser-agent-1  | 2023-06-06 20:46:56,774 aries_cloudagent.transport.outbound.manager ERROR Outbound message could not be delivered to http://endorser-api:5000/webhook/topic/connections/
scripts-endorser-agent-1  | Traceback (most recent call last):
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/asyncio/tasks.py", line 180, in _step
scripts-endorser-agent-1  |     result = coro.send(None)
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/aries_cloudagent/transport/outbound/http.py", line 87, in handle_message
scripts-endorser-agent-1  |     f"Unexpected response status {response.status}, "
scripts-endorser-agent-1  | aries_cloudagent.transport.outbound.base.OutboundTransportError: Unexpected response status 403, caused by: Forbidden
scripts-endorser-agent-1  | 2023-06-06 20:46:56,780 aries_cloudagent.transport.outbound.manager ERROR >>> Outbound message failed to deliver, NOT Re-queued.
scripts-endorser-agent-1  | Traceback (most recent call last):
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/asyncio/tasks.py", line 180, in _step
scripts-endorser-agent-1  |     result = coro.send(None)
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/aries_cloudagent/transport/outbound/http.py", line 87, in handle_message
scripts-endorser-agent-1  |     f"Unexpected response status {response.status}, "
scripts-endorser-agent-1  | aries_cloudagent.transport.outbound.base.OutboundTransportError: Unexpected response status 403, caused by: Forbidden
scripts-endorser-agent-1  | 2023-06-06 20:46:56,781 aries_cloudagent.transport.outbound.manager ERROR Outbound message could not be delivered to http://endorser-api:5000/webhook/topic/connections/
scripts-endorser-agent-1  | Traceback (most recent call last):
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/asyncio/tasks.py", line 180, in _step
scripts-endorser-agent-1  |     result = coro.send(None)
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/aries_cloudagent/transport/outbound/http.py", line 87, in handle_message
scripts-endorser-agent-1  |     f"Unexpected response status {response.status}, "
scripts-endorser-agent-1  | aries_cloudagent.transport.outbound.base.OutboundTransportError: Unexpected response status 403, caused by: Forbidden
scripts-endorser-agent-1  | 2023-06-06 20:46:56,783 aries_cloudagent.transport.outbound.manager ERROR >>> Outbound message failed to deliver, NOT Re-queued.
scripts-endorser-agent-1  | Traceback (most recent call last):
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/asyncio/tasks.py", line 180, in _step
scripts-endorser-agent-1  |     result = coro.send(None)
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/aries_cloudagent/transport/outbound/http.py", line 87, in handle_message
scripts-endorser-agent-1  |     f"Unexpected response status {response.status}, "
scripts-endorser-agent-1  | aries_cloudagent.transport.outbound.base.OutboundTransportError: Unexpected response status 403, caused by: Forbidden
scripts-endorser-agent-1  | 2023-06-06 20:46:56,783 aries_cloudagent.transport.outbound.manager ERROR Outbound message could not be delivered to http://endorser-api:5000/webhook/topic/ping/
scripts-endorser-agent-1  | Traceback (most recent call last):
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/asyncio/tasks.py", line 180, in _step
scripts-endorser-agent-1  |     result = coro.send(None)
scripts-endorser-agent-1  |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/aries_cloudagent/transport/outbound/http.py", line 87, in handle_message
scripts-endorser-agent-1  |     f"Unexpected response status {response.status}, "
scripts-endorser-agent-1  | aries_cloudagent.transport.outbound.base.OutboundTransportError: Unexpected response status 403, caused by: Forbidden

Further progress -- in my setup, "localhost" must be defined as the IP address of the machine running docker.  Updated that, and I now can connect to the Endorser.
Failing on the "Register Public DID".  Looking at the logs for the Endorser, it is trying to register the DID, but failing, getting a VDR Timeout.  I've confirmed that the genesis file for the ledger is correct.
Sigh...
scripts-endorser-agent-1                | 2023-06-06 22:04:27,865 aries_cloudagent.core.conductor ERROR Exception in message handler:
scripts-endorser-agent-1                | Traceback (most recent call last):
scripts-endorser-agent-1                |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/aries_cloudagent/ledger/indy_vdr.py", line 375, in _submit
scripts-endorser-agent-1                |     request_result = await self.pool.handle.submit_request(request)
scripts-endorser-agent-1                |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/indy_vdr/pool.py", line 115, in submit_request
scripts-endorser-agent-1                |     result = await fut
scripts-endorser-agent-1                |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/asyncio/futures.py", line 327, in __iter__
scripts-endorser-agent-1                |     yield self  # This tells Task to wait for completion.
scripts-endorser-agent-1                |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/asyncio/tasks.py", line 250, in _wakeup
scripts-endorser-agent-1                |     future.result()
scripts-endorser-agent-1                |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/asyncio/futures.py", line 243, in result
scripts-endorser-agent-1                |     raise self._exception
scripts-endorser-agent-1                | indy_vdr.error.VdrError: Pool timeout

The issue appears to be with BCovrin Test: the ledger is taking too long to respond, and it is causing the VDR timeout error. A similar result is achievable by using the ledger browser and searching for anything, as an example the nym SVfHGCEEvEFmpBPcxgNqRR (the default endorser DID for the dockerized project). Pointing to BCovrin Dev by updating the references in the .env file "fixes" the issue (i.e.: it is possible to connect to the endorser and register a public did for the tenant).
I suspect the problem might be the resources assigned to run the test ledger as it has grown in size exponentially. I will need to loop in @WadeBarnes to assess/increase resources as I do not have access to it anymore (new machine, new keys, etc.). We recently bumped the resources by quite a bit, but it seems like it might not be quite enough.
In the meantime, a couple of recommendations/suggestions for your scenario (if you haven't already done so):

you will want to update the ACAPY_ENDORSER_SEED and ACAPY_ENDORSER_PUBLIC_DID values in your .env file, to avoid having another local instance of Traction "steal" your agent endpoint (overwriting it on startup)
you will want to manually register the new agent seed/did using the ledger browser before you start the endorser agent for the first time.

I tried submitting a query to the ledger browser and it succeeded this time, although after a LONG wait.
I am, however, getting an error when trying to start-up the agents: it appears that they are unable to fetch the genesis transaction successfully.

There is definitely a difference in response time between resolving a DID and querying the ledger via the Ledger Browser.  We need to fix up the ledger browser to deal with the volume of entries — e.g. limit the “search” to DIDs and index the transactions by DIDs on the ledger.  Or use IndyScan instead.

Logged the ledger browser stuff in its repo: https://github.com/bcgov/von-network/issues/266
Let me know if/when things seem to work so I can close this issue.

Cool — I’ll give it a try.

Extending this vs. opening a new issue.
I updated to the latest Traction, and then tried it, using a new DID that is unique to me setup. I registered the DID on BCovrin Test and confirmed it is there.  Then I restarted everything and went through this sequence:

Created the Tenant
Logged into Innkeeper
Tried to activate the new Tenant being an issuer -- failed with a red error box

I then reverted to before the most recent merge and restarted -- commit bc4558b0.  Rebuilt, restarted and repeated the steps and everything worked to the point above.  @esune --- should I open a separate issue on that or could it have been something else.
With that working, I went into the Tenant and tried to become an issuer (User -> Profile -> Endorser) and the connection to the Endorser could not be established.  Don't know what that was -- perhaps my ngrok had been active too long?

Logs on error with current main branch:
Error is AxiosError: Request fails with status 404
Logs:
scripts-traction-agent-1                | =================
scripts-traction-agent-1                | Traceback (most recent call last):
scripts-traction-agent-1                |   File "/home/indy/traction_plugins/traction_innkeeper/v1_0/innkeeper/routes.py", line 69, in wrapper
scripts-traction-agent-1                |     ret = await func(request)
scripts-traction-agent-1                |   File "/home/indy/traction_plugins/traction_innkeeper/v1_0/innkeeper/routes.py", line 400, in tenant_config_update
scripts-traction-agent-1                |     tenant_record = await TenantRecord.retrieve_by_id(session, tenant_id)
scripts-traction-agent-1                |   File "/home/indy/.venv/lib/python3.6/site-packages/aries_cloudagent/messaging/models/base_record.py", line 239, in retrieve_by_id
scripts-traction-agent-1                |     cls.RECORD_TYPE, record_id, {"forUpdate": for_update, "retrieveTags": False}
scripts-traction-agent-1                |   File "/home/indy/.venv/lib/python3.6/site-packages/aries_cloudagent/storage/askar.py", line 95, in get_record
scripts-traction-agent-1                |     raise StorageNotFoundError(f"Record not found: {record_type}/{record_id}")
scripts-traction-agent-1                | aries_cloudagent.storage.error.StorageNotFoundError: Record not found: innkeeper_tenant/undefined

@swcurran ngrok WILL timeout any active tunnel after a certain amount of time. You might be able to work around this by signing-up for a free account and adding your token to the ngrok container - see here for an example.
I just checked out the latest main (d3c3be5, rebuilt everything and starting from scratch and was able to connect to the endorser and create a public DID without issues. I would suggest trying starting with a clean slate again.
Additionally, if you customized settings in the .env file let me know what you changed so I can try with similar settings to the best of my possibilities - not sure whether that could cause issues.

authors: esune swcurran

repo: bcgov/traction


text:
Long get_lock times with 3.0.1

Seeing long times for get_lock sometimes:
6.1876  	SELECT GET_LOCK('63cae926484ea98ca6466ec10c1979b225d1af32', 300) AS ci_session_lock

Other times it completes in 0.0x seconds.  There are at most 2 users using this particular build.
Can someone please drop some clues as to what gives?  CI 3.0.1

Are you reporting a bug or ...?
If so, please provide more information.
If not, please close the issue and post on the forums instead - we don't provide general support here.

source: gharchive/issue

authors: QuakePhil narfbg

repo: bcit-ci/CodeIgniter

license: MIT

license_type: permissive

license_source: github-api


text:
Email not working in Codeigniter develop

Hello,
While sending a email there comes a error.
Codeigniter in complaning about a variable $atpos.
The fix seen in https://github.com/bcit-ci/CodeIgniter/issues/5300 does work.
Line 1824 in libraries/email.php
if (function_exists('idn_to_ascii') && $atpos = strpos($email, '@'))
instead of
if (function_exists('idn_to_ascii') && strpos($email, '@'))
Greetings,
Ubel Jan van Wijhe

Thanks, a merge seems to have broken it.

Why not doing tests before do the merge?

Some unit tests for those most used components would be useful, actually :)

authors: Nudasoft gxgpet narfbg ubeljan


text:
CLI with parameters is not working

Hi,
While trying to test migrations using CLI and adding parameters it will not work.
example:
run: php ci.php migrate:version 007
will get: Command 'migrate:version 007' not found
the problem is in CLI/console line 68 ($this->app->setPath("ci{$path}");) the setpath will implode all command segments.
Also line 69 (return $this->app->run();) should send command parameters this means that no parameters are passed to CLI command.
I can suggest a fix as the following:

getURI should return only first command segment.
CLI/CLI.php should return have function which returns command parameters
return $this->app->run(); should be something like return $this->app->run(CLI::getPrams());

If this solution is ok I can make a pull request :)

I found the issue it was eraser than I expect. in CLI file line 675 function getURI():
change return implode(' ', static::$segments); to return implode('/', static::$segments);

Good find! That was a leftover from when I recently refactored how the whole bootstrap process worked.

Thank you ... I can help in many issues like this

I look forward to it!

authors: baselbj lonnieezell

license: mit

license_source: bigquery


text:
PHPCBF - CodeIgniter4-Standard

What do you think of mentioning the CodeIgniter4-Standard in the user guide?

He has offered to transfer the repo to us, so it will get integrated somehow.
Mentioning a third party repo in the user guide has problems, as it is out of our control.

Ok. Thank you sir.

authors: jim-parry natanfelles


text:
Return value of callback function to main function

I'm using this crawler library to crawler a specific page and get the website title, for this I'm working with express and that library:
app.get('/crawler/', function(req, res){

var returnedTitle = crawlerTest(req.query.urlsite);
res.send({'title' : returnedtitle});
res.end();

});

function crawlerTest(urlsite){
var c = new Crawler({
    maxConnections : 10,
    // This will be called for each crawled page
    callback : function (error, res, done) {
        if(error){
            console.log(error);
        }else{
            var $ = res.$;
            // $ is Cheerio by default
            //a lean implementation of core jQuery designed specifically for the server
            console.log($("title").text());
        }
        done();
    }
});

// Queue just one URL, with default callback
c.queue(urlsite);
}

In the code above I am using the basic example of the library itself.
In this case, the crawlerTest function enters the site and can extract the page title.
But there is a flaw, I need to find a way to return the website title $("title").text() straight to the crawlerTest function, so that the returnedTitle variable can store the website title to send in response to res.send()
I know we should always call done() function for each crawled page, but I can't think of a way to do this.

You can try to wrap the crawler part by a Promise, and then resolve the result. Then use 'then' to get the resolved result inside your main function

Looks to me like you don't even need a crawler library. Just use fetch to load the html and then get the title with cheerio, jsdom or an xml parser

close due to inactive.

authors: mauricedoepke mayinghan micilini mike442144

repo: bda-research/node-crawler


text:
Safe to use current ae2stuff with the new AE2 beta?

I see there is a new AE2 beta out. I'm reluctant to update to it on my client/server since the last update caused AE2stuff to behave somewhat irratic.
Thanks! :)

I've just pushed a build made with alpha 8 (there is no beta for 1.10 yet AFAIK). I don't know of any specific issues from my cursory testing, but if you run into any please report them.
Also the bug tracker isn't really an appropriate place for questions like that.

authors: SubsterNL bdew


text:
Folder to exclude doesn't be excluded

Hello,
Thanks for the addon, it helps me a lot!
Recently I've just found an issue even if I've set the folders under the 'Folder to exclude' under 'update' and 'created' function settings, it's still be added the corresponding 'front matter' in the excluded files.
Basically, all the excluded folders I set are the folders that contain the template files, and each time they've been added the 'update' and 'created' front matters is the time it's been imported by triggering the template function in Obsidian. In addition, the 'created' time will remain the time it's been first imported and added to the 'created' front matter.

I'm having this same issue, reinstalling doesn't seem to help. any insights?

Not much insight, but a tip for usage. Try to type something in a new created file first and import the needed template after the auto timestamp has been made.

I, too, have excluded my Templates folder – to no effect.
The folder is buried under "3-Resources/Templates" but the plugin allows "Example: folder1/folder2"
Nevertheless, updated and created Properties are created.
Any resolution?

I can't reproduce the issue, since I'm myself using this plugin, with a folder that is excluded deeply nested and I don't have any issues.
A reproduction vault is welcomed so that I can actually see the issue

beaussan,  it works on some folders but not others. As we've seen here, others are having the same problem with their Templates folder.
I'm wondering: does it have a hard time with pre-existing folders (created before installing the plugin) but work with subsequently created folders?
If so, might one the Template folder, recreate a new Templates folder, then migrate old Template files into the new folder? Admittedly, this is after editing all the Template files with an editor external to Obsidian to remove the created/updated metadata.

Alas, no. I tried moving all the Templates out of the Template folder, edited each one in Visual Studio Code to remove the created/updated lines, and then moved them back into the Template folder. They still come in to a note with created/updated lines.

I was having the same issue, and was able to resolve it by closing other instances of Obsidian that I had open at the same time (specifically, Obsidian was open on my laptop while I was working on my Desktop). Once I closed the laptop Obsidian, the "exclude" folders are indeed now excluded from updates.
So it seems that if you add an exclusion while Obsidian is also open on a different machine (or phone, presumably) then it generates some kind of race/conflict.

authors: andrewsavikas beaussan billpetro drmbt duduOliver

repo: beaussan/update-time-on-edit-obsidian


text:
Convert !0 and !1 to boolean (true/false)

Converting !0 & !1 to boolean (true/false) would make the code more readable and easier to
reverse engineering
Input
The code looked like this before beautification:
window.foo = !0

Expected Output
The code should have looked like this after beautification:
window.foo = true

Actual Output
The  code actually looked like this after beautification:
window.foo = !0

#1632

authors: bitwiseman jimmywarting

repo: beautify-web/js-beautify


text:
How to use Show and hide in reactabular ?

How to use Show and hide in reactabular ? I have tried but the search part and the header part is coming.
Please my reactabular code ...

That's more general React problem. You'll need to wrap all of it within your visibility logic. Pseudocode:
{showTable ? this.renderTable() : this.renderSomethingElse()}

renderTable would deal with search/header/table and so on while the other branch with the rest. The exact solution you want might be different but hopefully this puts you in the right direction.

Hi Sir,
Onclick tot working on React-bootstrap Tab

What is the solution for it?
Thanks
Ranjan
On Wed, Sep 30, 2015 at 4:13 PM, Juho Vepsäläinen notifications@github.com
wrote:

That's more general React problem. You'll need to wrap all of it within
your visibility logic. Pseudocode:
{showTable ? this.renderTable() : this.renderSomethingElse()}
renderTable would deal with search/header/table and so on while the other
branch with the rest. The exact solution you want might be different but
hopefully this puts you in the right direction.
—
Reply to this email directly or view it on GitHub
https://github.com/bebraw/reactabular/issues/91#issuecomment-144353076.

Sorry, no idea as I don't use the library. Let's keep this issue tracker Reactabular specific only. :)

repo: bebraw/reactabular


text:
Error: 500 Cannot read properties of undefined (reading 'colorModePreferenceCookieName')

version: 1.13
on Nuxt ^3.12.1

add config nuxt.config.ts
runtimeConfig: {
    public: {
      naiveui: {
        colorModePreferenceCookieName: 'userColorMode',
      },
    },
  },

repo: becem-gharbi/nuxt-naiveui


text:
detect browser name in mobile device

if i use a firefox browser in android or ios system , i get safari result.

the problem has been fixed

repo: becher/angular-device-information


text:
Remove fixture loading on cli entrypoint

This doesn't look intentional considering it's one of the commands echoed out. Just had a bunch of fixtures imported in prod after loading up the cli and I suspect this was the source.

Fixed in https://github.com/bedrockio/bedrock-core/pull/232

source: gharchive/pull-request

authors: beatlevic jmnsf

repo: bedrockio/bedrock-core


text:
java.net.SocketException: Too many open files

I am Using Postgrest to communicate with the Postgres Database,My Application is a real-time monitoring system , which sends continues requests to the Postgrest , But While using this which throws the error Too many open files,
While checking in google  I got the reason something like "the socket connections are treated like files and they use file descriptor, which is a limited resource".
Is there any issues with the closing of socket connections, or can you please recommend any solution for reducing the number of connections.

Hmm, that's not good. Let's figure it out.

Which version of postgrest are you using? (Check for the contents of the Server response header when you send it a request)
Which operating system?
Which version of postgresql?
What value do you get if you run psql -c 'show max_connections;'?
What command line arguments are you passing to postgrest?

Postgrest Version : postgrest-0.2.11.1
OS: Ubuntu 14.04.3 LTS, 1GB RAM, 1CPU
psql (PostgreSQL) version: 9.5.0
max_connections : 100
command line arguments: /opt/postgrest-0.2.11.1 --db-host  --db-port 5432 --db-name  --db-user  --db-pool 200 --anonymous  --port 3002

@ratheeshcitrus

how many clients are connected to postgrest at the same time? are they closing the connection after each request?
check your file descriptor limit, maybe it's too low http://serverfault.com/questions/208916/understanding-max-file-descriptors-for-linux-and-nginx-and-best-value-for-worke
put postgrest behind nginx (you should anyway if the service is open to the internet) and see if this fixes things for you

@ratheeshcitrus did you find a solution for this problem?

@ratheeshcitrus I notice you were using db-pool 200 which exceeds the max connections of 100. Try lowering the value. Also try the new postgrest 0.4.
I'm closing this issue because it is old, but if you're still having the problem them please re-open it.

authors: begriffs ratheeshcitrus ruslantalpa

repo: begriffs/postgrest


text:
Run GC every 2s rather than 0.3s

Fixes #565

Looks like cabal check is confusing the RTS option with a ghc-option:
stack exec -- cabal check
The following warnings are likely affect your build negatively:
* Instead of 'ghc-options: -I2"' use 'include-dirs: 2"'

Hackage would reject this package.

Or maybe grouped quoted options is not valid in a cabal file. I'll consult the docs...

This builds and passes cabal check. Looking at its eventlog the GC doesn't run much as I use the program. Although going back to the original rtsopts the GC didn't seem to run much either.
Also if I change it to "-with-rtsopts=-N -K8" it will not crash the program whereas running with +RTS -K8 -RTS will. So I'm not sure it's actually using this configuration.

Turns out I had to run stack clean for the rtsopts to take effect in a new build. Merging.

Turns out I had to run stack clean for the rtsopts to take effect in a new build. Merging.

Is it required for those of us building PostgREST from source?

my guess is yes
On Thu, May 26, 2016 at 3:42 PM, Eric Bréchemier notifications@github.com
wrote:

Turns out I had to run stack clean for the rtsopts to take effect in a
new build. Merging.
Is it required for those of us building PostgREST from source?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/begriffs/postgrest/pull/604#issuecomment-221859752

To pick up changed GHC flags it's better to clean to be on the safe side.

authors: begriffs eric-brechemier ruslantalpa


text:
Control characters in name table entries

XML disallows characters < U+0020 except for U+0009, U+000A, and U+000D.  Currently we print those out to XML either raw or as XML entities.  Either way, expat fails to read them back in.
There are two categories of this: 1. when the character is truly a Unicode character we write out (ie unicode="True"), and 2. when it's simply a byte of a non-Unicode encoding.  Now, the byte usecase is serious in multibyte encodings that are not ASCII-safe...  But I'm not sure how common they are.  It will happen if a sequence fails to decode as Unicode, eg if a UTF-16 sequence has broken bytes in it or something.
We can approach fixing this a few separate ways:

For control characters, and for byte output of non-Unicode entries, introduce a xx xx syntax, or better, a  syntax.  That's very verbose, but semantically correct whereas current way we do this is incorrect XML,

Drop control characters.  That's rather safe for Unicode names, but again, may have bad consequences for non-ASCII compatible byte encodings,

Looking at failures, looks like many cases are where UTF-16BE is written out under Apple encodings.  In all cases I see, those are ASCII names.  We can detect this as every even byte is 0, and convert appropriately (with a warning).

is "DELETE" (0x007F) one of those "control characters" disallowed by XML as well?
We are using "\x7f" in the subset.py name obfuscation.
I haven't tested yet, but I wonder if that could create any problems with the XML parser.

No.  Delete is fine:
http://www.w3.org/TR/REC-xml/#charsets
I'm developing a few heuristics to recover badly marked and badly-endianed UTF-16.  All the cases I have at hand can be fixed that way.

ok, thanks!

Looks like there's more junk.  Like this one:
    <namerecord nameID="7" platformID="3" platEncID="1" langID="0x356" unicode="False">
      �Adobe Caslon is a trademark of Adobe Systems Incorporated.
    </namerecord>

So someone took the ASCII string, prepended one nul byte and wrote it as UTF-16BE!  Fun times...

good luck!

Another commit: https://github.com/behdad/fonttools/commit/c4fb6459b0b6979139f180c37ffb7b5c464dacfd

Ok, all the other ones I had got fixed by handling double-encoded UTF-16BE.
Lets close this and reopen as more bad stuff comes in.  We need to handle the control-chars-are-invalid-XML at some point, but lets wait for actual data that can't be decoded before doing that.

authors: anthrotype behdad

repo: behdad/fonttools


text:
[ttGlyphPen] only add empty ttProgram to simple glyphs, not to composites

Unlike simple glyphs (i.e. with contours) which must always have instructionLength field, the latter is optional in composite glyphs and depends on whether WE_HAVE_INSTR flag is set:
https://www.microsoft.com/typography/otspec/glyf.htm
In the previous code, the TTGlyphPen was adding an empty program attribute to all new glyphs, including composites, whereas it should only do it for simple glyphs.
For example, if you take Roboto-Regular.ttf from here:
https://github.com/google/roboto/releases/tag/v2.129
The font (unhinted) was compiled using the ttGlyphPen. It has 1434 composite glyphs. For each of them, a USHORT value for the number of instructions (0) is written, so the binary ttf is 2.868 KB greater than
what it should be.
/cc @jamesgk

LGTM!


text:
Don't Write Result in Input Without Always Show

سلام خدمت شما دوست عزیز
این بسته خیلی خوبه امیدوارم با بوت استرپ زیبا تر هم بشه
فقط یه مشکل خیلی مهم
اینه که من وقتی alwaysShow رو نمیزارم در واقع متن نتیجه تاریخ که باید توی input نوشته بشه نمی نویسه و زود میره
و یه نکته که من از JQuery  3.6.0 استفاده می کنم
نمی دونم گفتم شاید تاثیر داشته باشه ولی با alwaysShow کار می کنه
ممنون

اگر فایل رو به صورت زیر شروع کنید مشکل alwaysShow = false و عدم انتخاب تاریخ حل میشه:

یعنی این خطها باید اولین خط های پروژه باشن

repo: behzadi/persianDatepicker


text:
Fix bug of retrieving more docs than specified: Use heapq to maintain top-K

In the current version of BeIR, the exact_search will store much more documents  in the results than specified, since the code actually accumulates the top-k docs for each chunk:
https://github.com/beir-cellar/beir/blob/c3334fd5b336dba03c5e3e605a82fcfb1bdf667d/beir/retrieval/search/dense/exact_search.py#L68-L78
This will be a really severe issue when the corpus is large, which will result in a really huge memory burden, e.g. 60GB+ for MS MARCO. One could do some simulation about how much RAM it would take:
import random
import psutil

def entry():
	return {'corpus_id': random.randint(0, 100000), 'score': random.random()}

msmarco_docs = 8800000
corpus_chunk_size = 50000
top_k = 1000
queries = 100
# queries = 7000

print("Available RAM (GB), before:", psutil.virtual_memory().available / 1024 / 1024 / 1024)

query_results = [entry() for _ in range(msmarco_docs // corpus_chunk_size * top_k * queries)]

print("Available RAM (GB), after:", psutil.virtual_memory().available / 1024 / 1024 / 1024)

# Available RAM (GB), before: 16.977794647216797
# Available RAM (GB), after: 11.836997985839844

To fix this, for each query (result), a heap is used to maintain the top-K in an efficient manner.
The comparison and results can be found in this Colab notebook: https://colab.research.google.com/drive/1fr8cpJXi750FnPS0eYmPvyDq1VEdrgFy?usp=sharing

@thakur-nandan

Thanks @kwang2049, for the heapq implementation!
Could we check whether we have identical scores for a larger dataset such as TREC-COVID or MSMARCO?
I will have this pull request added in the weekend.
Thanks!

@thakur-nandan thanks for your quick response!
Sure, I have done the check with the script on msmarco:
from beir import util, LoggingHandler
from beir.retrieval import models
from beir.datasets.data_loader import GenericDataLoader
from beir.retrieval.evaluation import EvaluateRetrieval
from beir.retrieval.search.dense import DenseRetrievalExactSearch as DRES

import logging
import pathlib, os

#### Just some code to print debug information to stdout
logging.basicConfig(format='%(asctime)s - %(message)s',
                    datefmt='%Y-%m-%d %H:%M:%S',
                    level=logging.INFO,
                    handlers=[LoggingHandler()])
#### /print debug information to stdout

#### Download scifact.zip dataset and unzip the dataset
dataset = "msmarco"
url = "https://public.ukp.informatik.tu-darmstadt.de/thakur/BEIR/datasets/{}.zip".format(dataset)
out_dir = "datasets"
data_path = util.download_and_unzip(url, out_dir)

#### Provide the data_path where scifact has been downloaded and unzipped
corpus, queries, qrels = GenericDataLoader(data_folder=data_path).load(split="dev")

#### Load the SBERT model and retrieve using cosine-similarity
model = DRES(models.SentenceBERT("msmarco-distilbert-base-tas-b"), batch_size=16)
retriever = EvaluateRetrieval(model, score_function="dot") # or "cos_sim" for cosine similarity
results = retriever.retrieve(corpus, queries)

#### Evaluate your model with NDCG@k, MAP@K, Recall@K and Precision@K  where k = [1,3,5,10,100,1000]
print(retriever.evaluate(qrels, results, retriever.k_values))

print("Retrieved #docs per query: ", sum([len(topk) for qid, topk in results.items()]) / len(results))

The current version gives results:
2022-10-06 22:30:21 - Loading Corpus...
...
2022-10-07 02:00:02 - NDCG@1: 0.2205
2022-10-07 02:00:02 - NDCG@3: 0.3307
2022-10-07 02:00:02 - NDCG@5: 0.3694
2022-10-07 02:00:02 - NDCG@10: 0.4076
2022-10-07 02:00:02 - NDCG@100: 0.4650
2022-10-07 02:00:02 - NDCG@1000: 0.4773
2022-10-07 02:00:02 -

2022-10-07 02:00:02 - MAP@1: 0.2151
2022-10-07 02:00:02 - MAP@3: 0.3011
2022-10-07 02:00:02 - MAP@5: 0.3229
2022-10-07 02:00:02 - MAP@10: 0.3390
2022-10-07 02:00:02 - MAP@100: 0.3509
2022-10-07 02:00:02 - MAP@1000: 0.3514
2022-10-07 02:00:02 -

2022-10-07 02:00:02 - Recall@1: 0.2151
2022-10-07 02:00:02 - Recall@3: 0.4102
2022-10-07 02:00:02 - Recall@5: 0.5030
2022-10-07 02:00:02 - Recall@10: 0.6187
2022-10-07 02:00:02 - Recall@100: 0.8840
2022-10-07 02:00:02 - Recall@1000: 0.9771
2022-10-07 02:00:02 -

2022-10-07 02:00:02 - P@1: 0.2205
2022-10-07 02:00:02 - P@3: 0.1415
2022-10-07 02:00:02 - P@5: 0.1045
2022-10-07 02:00:02 - P@10: 0.0645
2022-10-07 02:00:02 - P@100: 0.0093
2022-10-07 02:00:02 - P@1000: 0.0010
Retrieved #docs per query:  177176.97779369628

And the fix gives results:
2022-10-06 22:32:32 - Loading Corpus...
...
2022-10-07 01:36:02 - NDCG@1: 0.2205
2022-10-07 01:36:02 - NDCG@3: 0.3307
2022-10-07 01:36:02 - NDCG@5: 0.3694
2022-10-07 01:36:02 - NDCG@10: 0.4076
2022-10-07 01:36:02 - NDCG@100: 0.4650
2022-10-07 01:36:02 - NDCG@1000: 0.4773
2022-10-07 01:36:02 -

2022-10-07 01:36:02 - MAP@1: 0.2151
2022-10-07 01:36:02 - MAP@3: 0.3011
2022-10-07 01:36:02 - MAP@5: 0.3229
2022-10-07 01:36:02 - MAP@10: 0.3390
2022-10-07 01:36:02 - MAP@100: 0.3509
2022-10-07 01:36:02 - MAP@1000: 0.3514
2022-10-07 01:36:02 -

2022-10-07 01:36:02 - Recall@1: 0.2151
2022-10-07 01:36:02 - Recall@3: 0.4102
2022-10-07 01:36:02 - Recall@5: 0.5030
2022-10-07 01:36:02 - Recall@10: 0.6187
2022-10-07 01:36:02 - Recall@100: 0.8840
2022-10-07 01:36:02 - Recall@1000: 0.9771
2022-10-07 01:36:02 -

2022-10-07 01:36:02 - P@1: 0.2205
2022-10-07 01:36:02 - P@3: 0.1415
2022-10-07 01:36:02 - P@5: 0.1045
2022-10-07 01:36:02 - P@10: 0.0645
2022-10-07 01:36:02 - P@100: 0.0093
2022-10-07 01:36:02 - P@1000: 0.0010
Retrieved #docs per query:  1000.0

Thanks for computing the scores. The changes look good to me! Thanks for the implementation, i think using a heapq definitely helps with the memory a lot.
I will integrate it over the weekend thanks!

I raised some concerns about the implementation here:
https://github.com/UKPLab/sentence-transformers/pull/1715
Where it might lead to wrong results at the end of the heap

I raised some concerns about the implementation here: UKPLab/sentence-transformers#1715
Where it might lead to wrong results at the end of the heap

Could you please tell me more about your finding? Any example script?

Thanks for @nreimers 's eagle eye🦅! I have found the issue: One should use heapq.heappushpop instead of heapq.heapreplace when the heap is full of top-k docs. The difference is, heapq.heapreplace is actually something like "heapq.heappoppush", i.e. it pops the smallest first and then push the new element. heapq.heappushpop, on the other hand, pushes the new element and then pops the smallest. One can refer to the official doc.
I have update the code and also the colab (in the PR desc). Please have a look. 2a3ec6c

authors: kwang2049 nreimers thakur-nandan

repo: beir-cellar/beir


text:
koreksi terhadap len()

Description

Saya Menggunakan

OS : Linux (Opensuse Leap 15
Python: version 3.6.15

close spam issue

repo: bellshade/Python


text:
После обновления на bem-core v3 сломались спеки

Error: Seems like you have no base templates from i-bem.bemhtml
Подскажите куда копать?

Обновить версию bem-xjst?

@kompolom, вот пример конфига, обрати внимание на секцию templateEngine и scripts.
specs.configure({
        destPath: 'desktop.specs',
        levels: ['common.blocks'],
        sourceLevels: levels.concat('libs/bem-pr/spec.blocks'),
        jsSuffixes: ['vanilla.js', 'browser.js', 'js'],
        depsTech: require('enb-bem-techs').deps,
        langs: true,
        scripts: ['https://yastatic.net/es5-shims/0.0.2/es5-shims.min.js'],
        templateEngine: {
            templateTech: require('enb-bemxjst/techs/bemhtml'),
            templateOptions: { sourceSuffixes: ['bemhtml', 'bemhtml.js'] },
            htmlTech: require('enb-bemxjst/techs/bemjson-to-html'),
            htmlTechOptionNames: { bemjsonFile: 'bemjsonFile', templateFile: 'bemhtmlFile' }
        }

Что-то не пойму. Такая же проблема возникает при обновлении на bem-components@v5 и bem-core@v4. Пробовал в сборку добавить
        scripts: ['https://yastatic.net/es5-shims/0.0.2/es5-shims.min.js'],
        templateEngine: {
            templateTech: require('enb-bemxjst/techs/bemhtml'),
            templateOptions: { sourceSuffixes: ['bemhtml', 'bemhtml.js'] },
            htmlTech: require('enb-bemxjst/techs/bemjson-to-html'),
            htmlTechOptionNames: { bemjsonFile: 'bemjsonFile', templateFile: 'bemhtmlFile' }
        }

таже ошибка...

необходимо добавить engineOptions : { elemJsInstances : true }, т.к. начиная с bem-core v4 появилась поддержка JS у элементов.

@tadatuta сейчас такой конфиг
    config.module('enb-bem-specs').createConfigurator('specs').configure({
        destPath       : 'common.specs',
        levels         : [].concat(project),
        sourceLevels   : [].concat(specs, libs, project),
        jsSuffixes     : ['vanilla.js', 'browser.js', 'js'],
        depsTech       : techs.bem.depsOld,
        scripts        : ['https://yastatic.net/es5-shims/0.0.2/es5-shims.min.js'],
        templateEngine : {
            bemtreeTemplateTech : require('enb-bemxjst/techs/bemtree'),
            templateTech        : require('enb-bemxjst/techs/bemhtml'),
            templateOptions : {
                sourceSuffixes : ['bemhtml', 'bemhtml.js'],
                engineOptions  : { elemJsInstances : true }
            },
            htmlTech : require('enb-bemxjst/techs/bemjson-to-html'),
            htmlTechOptionNames : { bemjsonFile : 'bemjsonFile', templateFile : 'bemhtmlFile' }
        }
    });

выпадает ошибка
...
15:00:09.370 - [failed] [common.specs/validation_card/validation_card.spec.js] borschik
15:00:09.371 - [failed] [common.specs/validation_length/validation_length.spec.js] borschik
15:00:09.372 - [failed] [common.specs/validation_numbers/validation_numbers.html] bemjson-to-html
15:00:09.372 - [failed] [common.specs/validation/validation.html] bemjson-to-html
15:00:09.372 - [failed] [common.specs/validation_required/validation_required.spec.js] borschik
15:00:09.372 - [failed] [common.specs/validation_email/validation_email.browser.template.js] bemhtml
15:00:09.372 - [failed] [common.specs/validation_money/validation_money.browser.template.js] bemhtml
15:00:09.373 - [failed] [common.specs/validation_numbers/validation_numbers.pre.spec.js] file-merge
15:00:09.373 - [failed] [common.specs/validation/validation.pre.spec.js] file-merge
15:00:09.373 - [failed] [common.specs/validation_pattern/validation_pattern.pre.spec.js] file-merge
15:00:09.374 - build failed
SyntaxError: Unexpected identifier
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:374:25)
    at Object.Module._extensions..js (module.js:417:10)
    at Module.load (module.js:344:32)
    at Function.Module._load (module.js:301:12)
    at Module.require (module.js:354:17)
    at require (internal/module.js:12:17)
    at doRequire (/home/sergey/projects/bem-forms/node_modules/enb-async-require/lib/async-require.js:23:30)
    at /home/sergey/projects/bem-forms/node_modules/enb-async-require/lib/async-require.js:35:9
    at Object.Promise (/home/sergey/projects/bem-forms/node_modules/vow/lib/vow.js:308:9)

Убрал
sourceSuffixes : ['bemhtml', 'bemhtml.js'], собралось. Но теперь другая проблема
Failed to start mocha: Init timeout на всех тестах

@belozyorcev правильный конфиг для bem-core v4 можно посмотреть в https://github.com/bem/bem-components/commit/f427fc39fb8e3ad4cc56e417c794f3d1d4dcb3fd
Он совершенно точно работает.

@tadatuta вроде завелоь.
Сейчас правда борюсь с  Error: Module "spec": can't resolve dependence "i-bem-dom"
вроде что-то нашёл
https://github.com/bem/bem-components/issues/1565

authors: apsavin belozyorcev kompolom tadatuta

repo: bem/bem-forum-content-ru


text:
mergeRules removes my top: 3px :(

Why is this happening?

Hi @IIIu6ko,
Would you be able to provide a minimal amount of CSS that can reproduce the problem?

@ben-eb If mergeRules: false, then everything is fine.
But if you do not disconnect it, it removes the top: 3px from the logo__stars class.
In the screenshots above, I showed everything. I do not know how to explain it better.
mergeRules: false
.logo__stars{position:absolute;top:3px;right:0}
mergeRules: true
.logo__stars{position:absolute;right:0}
Where does the top disappear: 3px? In the code there is no second class .logo__stars.

@IIIu6ko I tried to reproduce the problem you're having, but to no avail. Are you still experiencing the issue? If so, could you produce a minimal configuration which reproduces the problem?

I'm closing this for now. If a snippet is posted demonstrating the problem I'll reopen the issue again.

authors: IIIu6ko andyjansson ben-eb

repo: ben-eb/cssnano


text:
Lunchtime stab at adding temporary halts on payments

Had a spare half hour. Initially went the route of removing payments but that approach would result in dodgy behaviour (I think!) when the following scenario occurs:

Halt a payment because of non delivery before payment date
Resolve dispute before payment date
Wish to reinstate payment before payment date

Therefore the non-destructive approach with filtering seemed to make more sense.
Hence putting it in a separate piece of state.
TODO:

Needs some unit tests
Versions are out-of-date so need to bump & fix

Relates to #5

I like this approach. Only question is whether or not the halting should be a bit more granular. You could halt individual payments, rather than all payments to a recipient. And if you wanted to halt all payments to a specific recipient, you can pass in multiple payment ids to do so, which gives you feature parity with this draft.


text:
cant open up (ERR_TOO_MANY_REDIRECTS)

so I cant open up https://pockethost.io and cant open my project. I always get the error ERR_TOO_MANY_REDIRECTS.
I tried everything. Deleted all my cookies, used diffrent browser and used different devices but it does not work

Moved to #223

repo: benallfree/pockethost


text:
fixed slovak translation

fixed slovak translation that caused i18 sync error

Oops sorry my bad, I was editing on mobile 😅

authors: AuroPick daloes

repo: benawad/dogehouse


text:
ci: update and split workflows

Description
split push event to dedicate yaml, so that Github can get the status
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds new typings)
[ ] Breaking change (fix or feature that would cause existing functionality not to work as expected)

:tada: This PR is included in version 0.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

authors: benbenbang ptah-lgtm

repo: benbenbang/types-confluent-kafka


text:
feat!: special tokens encoded by default

Special tokens are now also encoded by both Huggingface and Tiktoken tokenizers. This is closer to the default behavior on the Python side, and should make sure if a model adds tokens at the beginning or end of a sequence, these are accounted for as well.

@Jeadie I saw you guys forked to do something similar. Since your fork doesn't have issues, I thought I would ask the question here:
Is this feature the main reason you had to fork? and if so, is the reason because embedding models often need to add in extra tokens at the beginning/end and these weren't accounted for in the chunk size?

Yes, some embedding models have hard constraints on the number of tokens they can use as input. This includes special tokens. We needed to account for this when splitting inputs in preparation. This PR has those changes in our upstream: https://github.com/spiceai/spiceai/pull/3713
I had a note to upstream our changes, so I'm glad to see you've already done it

@Jeadie thanks for the input. It totally makes sense. I'm trying to figure out if I need a way to let the user decide this behavior to be somewhat backwards compatible in case like for tiktoken the recommendation is not to enable this in most cases... Which might require a wrapper. But I think having it be the default makes sense as I think in most cases this is desired

authors: Jeadie benbrandt

repo: benbrandt/text-splitter


text:
Test Issue: Please Ignore

This is a test issue created by an AI assistant to demonstrate the GitHub API tools. Please feel free to close this issue.

ignored


text:
Refactor structure to work similar to Django's model package

Refactor structure to work with imports from timescale.db import models rather than direct imports. Currently it requires direct verbose imports to the get to the features, following Djangos model package would make it nicer:
from timescale.db import models as tsdb

Looks like in the backends the schema causes a circular import when delcaring the field, testing out a solution by using an inner class on the model and using this to determine if its a hypertable or not.

class Metric(TimescaleModel):

          class Timescale:
                    hypertable = True
                    field = "time"

Looks like in the backends the schema causes a circular import when delcaring the field, testing out a solution by using an inner class on the model and using this to determine if its a hypertable or not.

class Metric(TimescaleModel):

          class Timescale:
                    hypertable = True
                    field = "time"

class Metric(TimescaleModel):

          class Timescale:
                    hypertable = True
                    field = "time"

Hey @bencleary
This looks like a good method to store "meta", one issue though - this wont trigger migrations (in backend creating or migrating to "hypertable") - one workaround for that would be to have "special migrations opertaions" (like migrations.CreateHypertable(name='db_name', field='time', migrate=True)) written which user have to manually put in migration file.

I have thought about it - having Meta like class for timescale related info (django fails for any arbitaary info in Meta).
I was pondering on how to "declaretively" define - retention/compression/etc policies that Timescale provides, MyModel.TimescaleMeta kind of approach wont help - instead I have thought of defining various "migration operations" like migrations.CreateRetentionPolicy, etc and user will just put them in migration file.
So to summarise, this approach as I see from current implmentation has only one advantage - that the "partition column", could be any arbitarily named field (currently in README it says to have it named "time", not sure why? though? as in queries too, the column name is passed.). Am I right? Do we see any other use case?

@ schlunsen Why is the name "time" for partion column necessary (as mentioned in README)?

authors: bencleary daadu

repo: bencleary/django-timescaledb


text:
React-cookie, removeCookie doesn't work when url have dynamic url or more than two depth url with url access, not by react -router-dom

   "react": "^18.2.0"
   "react-router-dom": "5.1.2"
   "react-cookie": "^4.1.1"

When we use dynamic url or more than two depth url, the removeCookie doesn't work. In the condition that if we access to the page by the URL. Not by the react-router-dom.
For example, we often try to access to the url like "URL/report/:reportId", "URL/report/reportDetail". Also we want to access to the page in url. Because we want to share the specific report. When we access to the url with authorized token, we can access to the  page.
However, when we try to logout, The removeCookie doesn't work. here is the code.
Router.js
 <BrowserRouter>
            <Switch>
                 {.......other routers.......}
                <AuthorizedRouter exact path="/report/reportDetail/:reportId" component={<ReportDetail/>} /> // This router check the token is valid
                <AuthorizedRouter exact path="/reportList" component={<ReportList/>} />
            </Switch>
</BrowserRouter>

ReportDetail.js
import {useCookie} from "react-cookie"

 const ReportDetail = ()=> {
const [,,removeCookie] = useCookie();

const onLogout = ()=>{
    removeCookie("loginToken")
}

return <div>
   <button onClick={onLogout}/>
</div>
}

Now, the removeCookie doesn't work at all.
However in the same logic with different url like "/reportList" which has just one depth Url.  The removeCookie works well even though we accessed to the page in url.
I don't know why this bug happen. So i just used the vanilla way to remove the cookie
const onLogout = ()=>{         document.cookie = "loginToken=; expires=0; path=/;"; }
It works, but i don't like to use vanilla way in react. Is there any proper solution with this problem?

You need to make sure to set the path to / when calling removeCookie. Here, you are including it in the vanilla javascript version, but not in the React version.

authors: eXon songjihyeok

repo: bendotcodes/cookies


text:
Fixed printing of non null terminated char array

The ordered[i].word in c optimized version isn't null terminated, printing it with %s causes ub.

Good spotting, thank you!

authors: ansingh benhoyt

repo: benhoyt/countwords


text:
Split out Annotations (and interface) into neutral Jar.

Cleanly wrapping the project as a base component for a framework is quite hard to do without at minimum the annotations being separated. Please generate an API Jar In a simple neutral namespace ( like osgi, aop, javax).
I think that elements of the API that specify bits of functionality should also be included as separate interfaces parameterised only by the message type.
Off the top of my head behaviour for publishing and subscribing are candidates, but other elements like the model interface IMessagePublication and other similar interfaces should also be split out.
I wouldn't mind doing this bit of work.

I agree that modularity in terms of deployable artefacts could and should be improved. I was also thinking about this because of the work made by @dorkbox --> bennidi/eventbus-performance#1
It would be great to have a mechanism that allows to plugin extensions like a specific queue implementation that only works, for example with Java 8. Another idea would be the separation of the sync / async parts of message publications.
However, I did not understand your suggestion in detail. For example what would you put in the namespace neutral jar? The annotations only? What is your requirement for it? Are you aware that you can introduce your own annotations? Probably not flexible enough for your usecase but checkout #74 and CustomHandlerAnnotationTest.
I also did not understand what you mean by "elements of the API that specify bits of functionality should also be included as separate interfaces parameterised only by the message type." Can you explain?
Generally, if you want to contribute with making mbassador more modular you are more than welcome. Thank you!

authors: bennidi hsyed

repo: bennidi/mbassador


text:
Advertising: threestudio for 3D content generation

Hi guys! I've been working on a new project:
https://github.com/threestudio-project/threestudio
threestudio is a unified framework for 3D content generation from text prompts, single images and few-shot images. With the recently released text-to-image model DeepFloyd IF, threestudio can reproduce the stunning results of DreamFusion and Magic3D. We have also implemented several other state-of-the-art methods, and more to come!

For those who are interested in this topic, welcome to have a try! The code structure is similar to this repository, and it should be easy for you to get started if you have worked with instant-nsr-pl. Cheers!

Damn cool man

authors: bennyguo xiaohulihutu

repo: bennyguo/instant-nsr-pl


text:
chore: avatar/melt-ui

Add melt builder for the avatar component.

Removed the if check for url since melt handles display of fallback automatically.

@0xHati thank you for your work on this. I was re-doing all the docs in a massive PR and changed the Avatar component quite a bit so I decided to already address the Melt stuff in there. Thank you again for the PR though. It should be easier now to add new components so feel free to commit new ones.

repo: bennymi/ato-ui


text:
error when trying to open a file via dropbox

Getting the following error when trying to open a file via dropbox...
Dropbox error (400: {"error": "v1_retired"}).

API v1 retirement
In June 2016, we announced the deprecation timeline for API v1. When API v1 is retired in September 2017, any further API v1 calls will fail with a 400 error with the body:
{"error": "v1_retired"}

from: https://www.dropbox.com/developers/reference/migration-guide

Can you try with the new v5 please ? (https://stackedit.io/app)

yes, worked.  PDF exporter, unfortunately is not working yet in 'app'.  I assume you're aware.

I have issues opening file from Dropbox.
For instant I synchronized with my Dropbox account the Welcome File (Welcome file.md).
I authorized StackEdit "Restrict" access (Namely access StackEdit folder only).
When I tried opening it again in a new session I got this:

On top of that a small suggestion, why the name of StackEdit folder has the (restricted) in it?
Couldn't it be StackEdit and that's it?
Thank You.

To add information, saving file does work.
This is in version 5.71.

Ping? Same issue

authors: BlackHC RoyiAvital benweet theoryshaw

repo: benweet/stackedit


text:
Update init.bash

the color cancelling code should be length calculating escaped, otherwise will cause prompt length error when ctrl-a / ctrl-e.

oops, it's the same as #95

Yeah, sorry
I've been busy again.... Hopefully this weekend I'll do it
Sent from mobile. Please excuse my brevity.

authors: berdario hansluk

repo: berdario/pew


text:
Plugin attempted to register task while disabled

Info
Please provide the following information:

BkCommonLib Version (BKCommonLib-1.19.3-v2-SNAPSHOT-1454):
TrainCarts Version (TrainCarts-1.19.3-v2-SNAPSHOT-1288):
Server Type and Version (purpur-1.19.3-1892):

Bug
Description
https://paste.gg/p/ConaII_/11a9fb2c1e5445598503b570ff6c0d9e

This should help https://ci.mg-dev.eu/job/TrainCarts/1289/

Indeed it did

authors: LcyDev bergerkiller

repo: bergerhealer/TrainCarts


text:
Switch from jshint to eslint

Eslint seems powerful and flexible and I'm more familiar with it. It seems we don't even have an .jshint file now, so we are just using  the default rules.

At this point this doesn't seem to be reasonable switch as jshint works better when code has e.g. "not allowed" language features.

Looking now.

authors: markstos walokra

repo: bergie/passport-saml


text:
introduction of FBP parser and splitting of repo

introduce FBP dsl parser, rework graph
shutdown optimizations
update README to have all info concerning the new functionality from FBP parser
add example(s) for FBP file loading

@aretecode did the requested changes, also rewrote part of the README of https://github.com/phpflo/phpflo-fbp/blob/master/README.md#fbp-dsl-defintions according to our discussion on FBP format ;-)

repo: bergie/phpflo


text:
Add Windows instructions

Instructions here: https://github.com/junegunn/vim-plug
This is also useful in tandem with Visual Studio VsVim.

Not sure what (if possible, any) packages need to be installed with something like Chocolatey.

Ruby and Python definitely need to be installed.

On Windows, convention is to use _vimrc etc, as well as keep files in vimfiles instead of .vim.

Running into an issue with getting Python working for UltiSnips and Ctrl+P.


text:
🛑 SIDAP is down

In 3b5e56c, SIDAP (http://uladap.adm.ula.ve/sidap/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: SIDAP is back up in efd070e after 12 minutes.

repo: berlinserver/estatus


text:
about the pretrained .net.mat file

Hi Luca,
is there any files can help to use the pretrained .mat file like '2016-08-17.net.mat' for training my own dataset?
thank you!

Hi and sorry for the late answer.
I am not sure to understand your question:

The file you mention is a pretrained network you can use for the "tracking only" mode described in the README
You can use it as a starting point and "fine tune" it for your purpose

authors: AnnaraMA bertinetto

repo: bertinetto/siamese-fc


text:
Format dates with browser native Intl.DateTimeFormat?

Goal
Use browser's native Intl.DateTimeFormat API to format dates instead of using date-fnss format function, following the approach described here: https://dev.to/dmtrkovalenko/you-might-not-need-date-fns-23f7
This way we could remove date-fns dependency.
How to test
Check that the dates at 2 following places:

At the footer of all page, the time data was updated: The last update was 3 hours ago (at 6:16 AM).
In the /timeline page, check the dates of creation for each project (E.g. August 2006)

Screenshots
Footer

Timeline

Impact on the bundle sizes
Comparing the sizes of the bundles in the browser, this change would only save 6 kB.

Before https://bestofjs-git-develop-bestofjs.vercel.app/ 180.05
After https://bestofjs-git-try-native-intl-date-time-format-bestofjs.vercel.app/ 174.13.

So I'm not sure it's the best move 😄 !

repo: bestofjs/bestofjs-webui


text:
🎨 Affiche le simulateur PL adapté à l'entreprise

fixes #1634
Je n'ai finalement pas voulu modifier le state de l'Engine (comme on le fait dans useSimulationConifg), car selon moi le code NAF ne suffit pas à déduire avec assurance le type d'entreprise dont il s'agit. Par exemple, un médecin peut exercer soit en PL soit en salarié, me semble-t-il. Il faut donc laisser le choix à l'utilisateur.

@johangirod j'ai repris tes commentaires et rebasé. Mes dernières modifs sont dans un commit séparé pour que tu puisses vérifier. Je pense que c'est squash-and-mergeable, mais je reste dispo s'il faut ajuster autre chose. Bonne année!

repo: betagouv/mon-entreprise


text:
Lines are not responsive, they disappear when the tab breaks

Problem
Lines are HTML elements and do not replicate when the tab breaks.
Solution
Use an image to auto replicate the background.

:white_check_mark: Done!

repo: betofigueiredo/oaktabs


text:
Processamento de requests por chunks

Visando não sobrecarregar o servidor com muito conteúdo enviado ao mesmo tempo, mudamos pra chunks de requests para que haja uma folga entre os grupos.
Por enquanto está como 1500ms de intervalo em chunks de tamanho 50.
Nota: pensei em adicionar uma dependência com o lodash pra usar o _.chunk que tem nele, mas por agora deixei a implementação no código mesmo e nao adicionei o lodash.
Aqui um print do terminal mostrando o log das requests:

Ele mostra a quantidade de grupos (chunks) que serão divididos os requests, baseado no total de arquivos extraídos pelo git (nesse caso enviei o conteúdo completo). E também mostra qual grupo iniciou o processamento, seu término e o início do próximo. E a mensagem final de que todos foram processados

@raigons você tem algum valor ou estimativa agora de quanto tempo, demora pra criar uma versão seguindo o fluxo completo ?

@raigons você tem algum valor ou estimativa agora de quanto tempo, demora pra criar uma versão seguindo o fluxo completo ?

authors: Caciquez raigons

repo: betrybe/process-content


text:
Resizing causes a crash on latest stable Nvidia driver 550

Bevy version
Affects both 0.13 and main (21adeb684261eacd39acecaa8b056e0b9e918268)
Relevant system information
cargo 1.76.0 (c84b36747 2024-01-18)
KDE desktop X11

AdapterInfo { name: "NVIDIA GeForce RTX 3070 Ti", vendor: 4318, device: 9346, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "550.54.14", backend: Vulkan }
SystemInfo { os: "Linux rolling EndeavourOS", kernel: "6.7.6-arch1-1", cpu: "AMD Ryzen 7 5800X3D 8-Core Processor", core_count: "8", memory: "31.3 GiB" }

What you did
Run cargo run --example window_resizing or pretty much any example. Then drag a window corner to resize.
What went wrong
Outputs this and crashes.
thread 'Compute Task Pool (6)' panicked at crates/bevy_render/src/view/window/mod.rs:357:26:
Error reconfiguring surface: Outdated
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Encountered a panic in system `bevy_render::view::window::prepare_windows`!
thread 'Compute Task Pool (1)' panicked at crates/bevy_render/src/pipelined_rendering.rs:49:67:
called `Result::unwrap()` on an `Err` value: RecvError

Additional information
550 was very recently stabilized (https://www.phoronix.com/news/NVIDIA-550.54.14-Linux-Driver).
Everything starts working again if I downgrade to the 545 driver.
I tested an example from the winit repository cargo run --example window and there was no issues.
Other applications I use aren't affected by this issue, so it might not be Nvidia's fault.
Complete log of the bevy example with backtrace:
❯ RUST_BACKTRACE=1 cargo run --example window_resizing
    Finished dev [unoptimized + debuginfo] target(s) in 0.12s
     Running `target/debug/examples/window_resizing`
2024-02-29T12:17:29.654613Z  INFO bevy_winit::system: Creating new window "App" (0v1)
2024-02-29T12:17:29.654883Z  INFO winit::platform_impl::platform::x11::window: Guessed window scale factor: 1.1666666666666667
2024-02-29T12:17:29.722909Z  INFO bevy_render::renderer: AdapterInfo { name: "NVIDIA GeForce RTX 3070 Ti", vendor: 4318, device: 9346, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "550.54.14", backend: Vulkan }
2024-02-29T12:17:30.120325Z  INFO gilrs_core::platform::platform::gamepad: Gamepad /dev/input/event9 (Generic X-Box pad) connected.
2024-02-29T12:17:30.203046Z  INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "Linux rolling EndeavourOS", kernel: "6.7.6-arch1-1", cpu: "AMD Ryzen 7 5800X3D 8-Core Processor", core_count: "8", memory: "31.3 GiB" }
2024-02-29T12:17:30.215488Z  INFO bevy_input::gamepad: Gamepad { id: 0 } Connected
thread 'Compute Task Pool (6)' panicked at crates/bevy_render/src/view/window/mod.rs:357:26:
Error reconfiguring surface: Outdated
stack backtrace:
   0: rust_begin_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_fmt
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:72:14
   2: core::result::unwrap_failed
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/result.rs:1649:5
   3: core::result::Result<T,E>::expect
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/result.rs:1030:23
   4: bevy_render::view::window::prepare_windows
             at ./crates/bevy_render/src/view/window/mod.rs:355:33
   5: core::ops::function::FnMut::call_mut
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:166:5
   6: core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:294:13
   7: <Func as bevy_ecs::system::function_system::SystemParamFunction<fn(F0,F1,F2,F3,F4,F5,F6,F7,F8) .> Out>>::run::call_inner
             at ./crates/bevy_ecs/src/system/function_system.rs:661:21
   8: <Func as bevy_ecs::system::function_system::SystemParamFunction<fn(F0,F1,F2,F3,F4,F5,F6,F7,F8) .> Out>>::run
             at ./crates/bevy_ecs/src/system/function_system.rs:664:17
   9: <bevy_ecs::system::function_system::FunctionSystem<Marker,F> as bevy_ecs::system::system::System>::run_unsafe
             at ./crates/bevy_ecs/src/system/function_system.rs:504:19
  10: bevy_ecs::schedule::executor::multi_threaded::ExecutorState::spawn_system_task::{{closure}}::{{closure}}
             at ./crates/bevy_ecs/src/schedule/executor/multi_threaded.rs:621:26
  11: core::ops::function::FnOnce::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
  12: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panic/unwind_safe.rs:272:9
  13: std::panicking::try::do_call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  14: __rust_try
  15: std::panicking::try
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  16: std::panic::catch_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  17: bevy_ecs::schedule::executor::multi_threaded::ExecutorState::spawn_system_task::{{closure}}
             at ./crates/bevy_ecs/src/schedule/executor/multi_threaded.rs:614:23
  18: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::future::future::Future>::poll
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panic/unwind_safe.rs:297:9
  19: <futures_lite::future::CatchUnwind<F> as core::future::future::Future>::poll::{{closure}}
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-lite-2.2.0/src/future.rs:588:42
  20: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panic/unwind_safe.rs:272:9
  21: std::panicking::try::do_call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  22: __rust_try
  23: std::panicking::try
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  24: std::panic::catch_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  25: <futures_lite::future::CatchUnwind<F> as core::future::future::Future>::poll
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-lite-2.2.0/src/future.rs:588:9
  26: async_executor::Executor::spawn::{{closure}}
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-executor-1.8.0/src/lib.rs:158:20
  27: async_task::raw::RawTask<F,T,S,M>::run::{{closure}}
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-task-4.7.0/src/raw.rs:550:21
  28: core::ops::function::FnOnce::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
  29: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panic/unwind_safe.rs:272:9
  30: std::panicking::try::do_call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  31: __rust_try
  32: std::panicking::try
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  33: std::panic::catch_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  34: async_task::raw::RawTask<F,T,S,M>::run
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-task-4.7.0/src/raw.rs:549:23
  35: async_task::runnable::Runnable<M>::run
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-task-4.7.0/src/runnable.rs:781:18
  36: async_executor::Executor::run::{{closure}}::{{closure}}
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-executor-1.8.0/src/lib.rs:254:21
  37: <futures_lite::future::Or<F1,F2> as core::future::future::Future>::poll
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-lite-2.2.0/src/future.rs:449:33
  38: async_executor::Executor::run::{{closure}}
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-executor-1.8.0/src/lib.rs:261:32
  39: futures_lite::future::block_on::{{closure}}
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-lite-2.2.0/src/future.rs:99:19
  40: std::thread::local::LocalKey<T>::try_with
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/thread/local.rs:270:16
  41: std::thread::local::LocalKey<T>::with
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/thread/local.rs:246:9
  42: futures_lite::future::block_on
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-lite-2.2.0/src/future.rs:78:5
  43: bevy_tasks::task_pool::TaskPool::new_internal::{{closure}}::{{closure}}::{{closure}}::{{closure}}
             at ./crates/bevy_tasks/src/task_pool.rs:180:37
  44: std::panicking::try::do_call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  45: __rust_try
  46: std::panicking::try
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  47: std::panic::catch_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  48: bevy_tasks::task_pool::TaskPool::new_internal::{{closure}}::{{closure}}::{{closure}}
             at ./crates/bevy_tasks/src/task_pool.rs:174:43
  49: std::thread::local::LocalKey<T>::try_with
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/thread/local.rs:270:16
  50: std::thread::local::LocalKey<T>::with
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/thread/local.rs:246:9
  51: bevy_tasks::task_pool::TaskPool::new_internal::{{closure}}::{{closure}}
             at ./crates/bevy_tasks/src/task_pool.rs:167:25
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Encountered a panic in system `bevy_render::view::window::prepare_windows`!
thread 'Compute Task Pool (0)' panicked at crates/bevy_render/src/pipelined_rendering.rs:49:67:
called `Result::unwrap()` on an `Err` value: RecvError
stack backtrace:
   0: rust_begin_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_fmt
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:72:14
   2: core::result::unwrap_failed
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/result.rs:1649:5
   3: core::result::Result<T,E>::unwrap
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/result.rs:1073:23
   4: bevy_render::pipelined_rendering::RenderAppChannels::recv::{{closure}}
             at ./crates/bevy_render/src/pipelined_rendering.rs:49:26
   5: bevy_render::pipelined_rendering::update_rendering::{{closure}}::{{closure}}::{{closure}}::{{closure}}
             at ./crates/bevy_render/src/pipelined_rendering.rs:185:60
   6: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::future::future::Future>::poll
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panic/unwind_safe.rs:297:9
   7: <futures_lite::future::CatchUnwind<F> as core::future::future::Future>::poll::{{closure}}
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-lite-2.2.0/src/future.rs:588:42
   8: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panic/unwind_safe.rs:272:9
   9: std::panicking::try::do_call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  10: __rust_try
  11: std::panicking::try
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  12: std::panic::catch_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  13: <futures_lite::future::CatchUnwind<F> as core::future::future::Future>::poll
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-lite-2.2.0/src/future.rs:588:9
  14: async_executor::Executor::spawn::{{closure}}
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-executor-1.8.0/src/lib.rs:158:20
  15: async_task::raw::RawTask<F,T,S,M>::run::{{closure}}
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-task-4.7.0/src/raw.rs:550:21
  16: core::ops::function::FnOnce::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
  17: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panic/unwind_safe.rs:272:9
  18: std::panicking::try::do_call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  19: __rust_try
  20: std::panicking::try
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  21: std::panic::catch_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  22: async_task::raw::RawTask<F,T,S,M>::run
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-task-4.7.0/src/raw.rs:549:23
  23: async_task::runnable::Runnable<M>::run
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-task-4.7.0/src/runnable.rs:781:18
  24: async_executor::Executor::run::{{closure}}::{{closure}}
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-executor-1.8.0/src/lib.rs:254:21
  25: <futures_lite::future::Or<F1,F2> as core::future::future::Future>::poll
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-lite-2.2.0/src/future.rs:449:33
  26: async_executor::Executor::run::{{closure}}
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-executor-1.8.0/src/lib.rs:261:32
  27: futures_lite::future::block_on::{{closure}}
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-lite-2.2.0/src/future.rs:99:19
  28: std::thread::local::LocalKey<T>::try_with
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/thread/local.rs:270:16
  29: std::thread::local::LocalKey<T>::with
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/thread/local.rs:246:9
  30: futures_lite::future::block_on
             at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-lite-2.2.0/src/future.rs:78:5
  31: bevy_tasks::task_pool::TaskPool::new_internal::{{closure}}::{{closure}}::{{closure}}::{{closure}}
             at ./crates/bevy_tasks/src/task_pool.rs:180:37
  32: std::panicking::try::do_call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  33: __rust_try
  34: std::panicking::try
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  35: std::panic::catch_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  36: bevy_tasks::task_pool::TaskPool::new_internal::{{closure}}::{{closure}}::{{closure}}
             at ./crates/bevy_tasks/src/task_pool.rs:174:43
  37: std::thread::local::LocalKey<T>::try_with
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/thread/local.rs:270:16
  38: std::thread::local::LocalKey<T>::with
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/thread/local.rs:246:9
  39: bevy_tasks::task_pool::TaskPool::new_internal::{{closure}}::{{closure}}
             at ./crates/bevy_tasks/src/task_pool.rs:167:25
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Can you reproduce this upstream on winit's examples? If so, please open an issue there and link this issue for us <3

I tested older versions of bevy and it looks like 0.9 is the latest version that works :D

Bisected the issue to the introduction of pipelined rendering 2027af4c54082007fed2091f112a11cb0bc5fc08 :)

FYI @james7132 @hymm. Thanks a ton for bisecting!

Also works on main if I disable the multi-threading feature as it disables pipelined rendering.

I just ran into this myself. Arch linux with nvidia drivers 550.54.14-2.

I have the same issue on the newest nvidia drivers and X11

Also works on main if I disable the multi-threading feature as it disables pipelined rendering.

after disabling multithreading i'm getting the following error:
thread 'main' panicked at /home/colin/.cargo/registry/s
c/index.crates.io-6f17d22bba15001f/bevy_render-0.13.0/s
c/view/window/mod.rs:346:18:
Error configuring surface: Outdated
note: run with `RUST_BACKTRACE=1` environment variable
o display a backtrace
Encountered a panic in system `bevy_render::view::windo
::prepare_windows`!

I did some more investigation and found that we call surface.get_current_texture() directly after WindowEvent::Resized, while wgpu examples only do it on WindowEvent::RedrawRequested. If I modify the wgpu examples to do that, they crash too.
I tried to remove those calls from bevy by commenting out these lines, and the crashes went away and everything worked fine. I don't know if doing this is safe overall, as I'm not experienced in wgpu. Why do we even call this function when wgpu examples don't?

Excellent digging. I'd be happy to review a PR that changes this behavior in Bevy: it sounds like we're doing work overly eagerly for no real benefit.

I'm not actually sure if our code is too eager. It's just that with this specific driver surface.get_current_texture doesn't work if called just after surface.configure. Maybe as a workaround maybe we could skip drawing a frame on resize? I'm not really familiar with bevy or wgpu internals though, just testing stuff out.

2024-03-06T20:26:51.531143Z DEBUG present_frames: wgpu_core::present: Removing swapchain texture Id(12,115,vk) from the device tracker
2024-03-06T20:26:51.549641Z DEBUG present_frames: wgpu_core::present: Presented. End of Frame
2024-03-06T20:26:51.550759Z DEBUG wgpu_core::device::global: configuring surface with SurfaceConfiguration { usage: TextureUsages(RENDER_ATTACHMENT), format: Bgra8UnormSrgb, width: 1493, height: 840, present_mode: Fifo, desired_maximum_frame_latency: 2, alpha_mode: Auto, view_formats: [] }
2024-03-06T20:26:51.550953Z  WARN wgpu_hal::vulkan::conv: Unrecognized present mode 1000361000
2024-03-06T20:26:51.551007Z DEBUG wgpu_core::device::life: Active submission 229 is done
VUID-VkSwapchainCreateInfoKHR-pNext-07781(ERROR / SPEC): msgNum: 1284057537 - Validation Error: [ VUID-VkSwapchainCreateInfoKHR-pNext-07781 ] | MessageID = 0x4c8929c1 | vkCreateSwapchainKHR(): pCreateInfo->imageExtent (1493, 840), which is outside the bounds returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR(): currentExtent = (1477,826), minImageExtent = (1477,826), maxImageExtent = (1477,826). The Vulkan spec states: If a VkSwapchainPresentScalingCreateInfoEXT structure was not included in the pNext chain, or it is included and VkSwapchainPresentScalingCreateInfoEXT::scalingBehavior is zero then imageExtent must be between minImageExtent and maxImageExtent, inclusive, where minImageExtent and maxImageExtent are members of the VkSurfaceCapabilitiesKHR structure returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR for the surface (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkSwapchainCreateInfoKHR-pNext-07781)
    Objects: 0
2024-03-06T20:26:51.559037Z  INFO wgpu_hal::vulkan::instance: GENERAL [NVIDIA (0x4)]
        Requested image extent (1493x840) does not match surface (1477x826), marking swapchain out of date
2024-03-06T20:26:51.559068Z  INFO wgpu_hal::vulkan::instance:   objects: (type: SWAPCHAIN_KHR, hndl: 0x7e7f1801b060, name: ?)
thread 'Compute Task Pool (3)' panicked at crates/bevy_render/src/view/window/mod.rs:324:26:
Error reconfiguring surface: Outdated
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Encountered a panic in system `bevy_render::view::window::prepare_windows`!
thread 'Compute Task Pool (7)' panicked at crates/bevy_render/src/pipelined_rendering.rs:49:67:
called `Result::unwrap()` on an `Err` value: RecvError

I get this error when running with validation layers.

I did some more investigation and found that we call surface.get_current_texture() directly after WindowEvent::Resized, while wgpu examples only do it on WindowEvent::RedrawRequested. If I modify the wgpu examples to do that, they crash too.

surface.get_current_texture() is called in the render app, so it's mostly unrelated to the order Bevy receives events from winit

surface.get_current_texture() is called in the render app, so it's mostly unrelated to the order Bevy receives events from winit

I guess what I should have said is that we call both surface.configure and surface.get_current_texture at the same time in the render app after the window size has changed, while wgpu calls them in separate winit events (Resized and RedrawRequested). That maybe gives the driver enough time to finish processing and not error out, at least it doesn't crash. Though that might not be applicable in bevy architecture.

@eero-lehtinen could you try with this branch? https://github.com/mockersf/bevy/tree/nvidia-outdated
I'm not sure how that will behave, it may fix the issue or make it worse 😄

@eero-lehtinen could you try with this branch? https://github.com/mockersf/bevy/tree/nvidia-outdated

Looks like that just works :D. I think I also at some point tried just blindly returning but had bad results.
Though was that previous retrying behaviour needed on other platforms? wgpu examples do it too.

I ported the fix to my game and there are definitely still situations where it can crash. E.g. switching between fullscreen and windowed quickly at startup and resizing the window when it is one of the two windows tiled side by side. The error is the same.

It seems to break when there are resizes in consecutive frames, as the outdated error is ignored in only one code path of two. I made a version where the outdated error is always ignored, and that seems to work perfectly. https://github.com/eero-lehtinen/bevy/tree/v0.13.0-nvidia-fix

Under arch linux, using nvidia driver version 550.54.14-4, with Xwayland.
Testing winit 0.29.14 examples, no issues.
Testing with wgpu 0.19.3 boids example, issue was reproducible.
[2024-03-09T04:53:35Z INFO  winit::platform_impl::platform::x11::window] Guessed window scale factor: 1.5
[2024-03-09T04:53:35Z INFO  wgpu_examples::framework] Initializing wgpu...
[2024-03-09T04:53:35Z INFO  wgpu_core::instance] Adapter Vulkan AdapterInfo { name: "NVIDIA GeForce RTX 3060 Laptop GPU", vendor: 4318, device: 9504, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "550.54.14", backend: Vulkan }
[2024-03-09T04:53:35Z INFO  wgpu_examples::framework] Using NVIDIA GeForce RTX 3060 Laptop GPU (Vulkan)
[2024-03-09T04:53:35Z INFO  wgpu_examples::framework] Entering event loop...
[2024-03-09T04:53:35Z INFO  wgpu_examples::framework] Surface resume PhysicalSize { width: 800, height: 600 }
[2024-03-09T04:53:35Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 800, height: 600 }
[2024-03-09T04:53:35Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 624, height: 1137 }
[2024-03-09T04:53:36Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 800, height: 600 }
[2024-03-09T04:53:36Z INFO  wgpu_examples::framework] Frame time 6.05ms (165.4 FPS)
[2024-03-09T04:53:37Z INFO  wgpu_examples::framework] Frame time 6.06ms (165.0 FPS)
[2024-03-09T04:53:37Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 801, height: 600 }
[2024-03-09T04:53:37Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 802, height: 600 }
[2024-03-09T04:53:37Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 802, height: 602 }
[2024-03-09T04:53:37Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 806, height: 605 }
[2024-03-09T04:53:37Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 807, height: 605 }
[2024-03-09T04:53:37Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 808, height: 606 }
[2024-03-09T04:53:37Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 808, height: 607 }
[2024-03-09T04:53:37Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 815, height: 613 }
[2024-03-09T04:53:37Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 818, height: 615 }
[2024-03-09T04:53:37Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 829, height: 621 }
[2024-03-09T04:53:37Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 832, height: 622 }
[2024-03-09T04:53:37Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 844, height: 628 }
[2024-03-09T04:53:37Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 847, height: 630 }
[2024-03-09T04:53:37Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 855, height: 636 }
[2024-03-09T04:53:37Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 863, height: 640 }
[2024-03-09T04:53:37Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 879, height: 651 }
[2024-03-09T04:53:37Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 882, height: 654 }
[2024-03-09T04:53:37Z INFO  wgpu_examples::framework] Surface resize PhysicalSize { width: 885, height: 656 }
thread 'main' panicked at 'Failed to acquire next surface texture!: Outdated', examples/src/framework.rs:235:22
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

It seems to break when there are resizes in consecutive frames, as the outdated error is ignored only in the code path where there is no resize. I made a version where the outdated error is always ignored, and that seems to work perfectly. https://github.com/eero-lehtinen/bevy/tree/v0.13.0-nvidia-fix

Tried out your fix, works for me too in XWayland, nvidia drivers v550.54.14

It seems to break when there are resizes in consecutive frames, as the outdated error is ignored only in the code path where there is no resize. I made a version where the outdated error is always ignored, and that seems to work perfectly. https://github.com/eero-lehtinen/bevy/tree/v0.13.0-nvidia-fix

This appears to work for me too. Arch Linux, i3, X11, Nvidia 550.54.14.

authors: DissolveDZ StarArawn alice-i-cecile eero-lehtinen jake8655 mockersf notverymoe theHamsta zentasumu

repo: bevyengine/bevy