Critical Error Loading Sia and Syncing Wallet (Siad)

I received the following error message while transferring coins to wallet;
Loading...
(0/6) Loading siad...
(1/6) Loading gateway...
(2/6) Loading consensus...
(3/6) Loading transaction pool...
(4/6) Loading wallet...
(5/6) Loading host...
(6/6) Loading renter...
Finished loading in 0.84217434 seconds
Wallet: scanned to height 119790...
Wallet: scanned to height 119850...
Wallet: scanned to height 119900...
Wallet: scanned to height 119936...
Wallet: scanned to height 119985...
Wallet: scanned to height 120053...
Wallet: scanned to height 120122...
Wallet: scanned to height 120196...
Wallet: scanned to height 120252...
Wallet: scanned to height 120310...
Wallet: scanned to height 120356...
Wallet: scanned to height 120416...
Wallet: scanned to height 120467...
Wallet: scanned to height 120500...
Wallet: scanned to height 120571...
Wallet: scanned to height 120631...
Wallet: scanned to height 120701...
Wallet: scanned to height 120777...
Wallet: scanned to height 120854...
Wallet: scanned to height 120931...
Wallet: scanned to height 121007...
Wallet: scanned to height 121082...
Wallet: scanned to height 121138...
Wallet: scanned to height 121193...
Wallet: scanned to height 121277...
Wallet: scanned to height 121356...
Wallet: scanned to height 121435...
Wallet: scanned to height 121515...
Wallet: scanned to height 121598...
Wallet: scanned to height 121691...
Wallet: scanned to height 121724...
Wallet: scanned to height 121758...
Wallet: scanned to height 121823...
Wallet: scanned to height 121891...
Wallet: scanned to height 121978...
Wallet: scanned to height 122057...
Wallet: scanned to height 122150...
Wallet: scanned to height 122227...
Wallet: scanned to height 122319...
Wallet: scanned to height 122413...
Wallet: scanned to height 122498...
Wallet: scanned to height 122589...
Wallet: scanned to height 122665...
Wallet: scanned to height 122745...
Wallet: scanned to height 122825...
Wallet: scanned to height 122916...
Wallet: scanned to height 123000...
Wallet: scanned to height 123085...
Wallet: scanned to height 123164...
Wallet: scanned to height 123245...
Wallet: scanned to height 123322...
Wallet: scanned to height 123386...
Wallet: scanned to height 123419...
Wallet: scanned to height 123471...
Wallet: scanned to height 123523...
Wallet: scanned to height 123567...
Wallet: scanned to height 123616...
Wallet: scanned to height 123679...
Wallet: scanned to height 123735...
Wallet: scanned to height 123803...
Wallet: scanned to height 123851...
Wallet: scanned to height 123907...
Wallet: scanned to height 123960...
Wallet: scanned to height 124031...
Wallet: scanned to height 124093...
Wallet: scanned to height 124158...
Wallet: scanned to height 124227...
Wallet: scanned to height 124296...
Wallet: scanned to height 124357...
Wallet: scanned to height 124420...
Wallet: scanned to height 124479...
Wallet: scanned to height 124536...
Wallet: scanned to height 124592...
Wallet: scanned to height 124644...
Wallet: scanned to height 124706...
Wallet: scanned to height 124766...
Wallet: scanned to height 124827...
Wallet: scanned to height 124895...
Wallet: scanned to height 124960...
Wallet: scanned to height 125022...
Wallet: scanned to height 125090...
Wallet: scanned to height 125155...
Wallet: scanned to height 125207...
Wallet: scanned to height 125268...
Wallet: scanned to height 125337...
Wallet: scanned to height 125405...
Wallet: scanned to height 125480...
Wallet: scanned to height 125551...
Wallet: scanned to height 125617...
Wallet: scanned to height 125683...
Wallet: scanned to height 125750...
Wallet: scanned to height 125822...
Wallet: scanned to height 125881...
Wallet: scanned to height 125953...
Wallet: scanned to height 126024...
Wallet: scanned to height 126092...
Wallet: scanned to height 126145...
Wallet: scanned to height 126207...
Wallet: scanned to height 126278...
Wallet: scanned to height 126341...
Wallet: scanned to height 126404...
Wallet: scanned to height 126462...
Wallet: scanned to height 126513...
Wallet: scanned to height 126576...
Wallet: scanned to height 126628...
Wallet: scanned to height 126680...
Wallet: scanned to height 126730...
Wallet: scanned to height 126790...
Wallet: scanned to height 126855...
Wallet: scanned to height 126923...
Wallet: scanned to height 126985...
Wallet: scanned to height 127059...
Wallet: scanned to height 127121...
Wallet: scanned to height 127200...
Wallet: scanned to height 127268...
Wallet: scanned to height 127327...
Wallet: scanned to height 127387...
Wallet: scanned to height 127421...
Wallet: scanned to height 127466...
Wallet: scanned to height 127533...
Wallet: scanned to height 127585...
Wallet: scanned to height 127650...
Wallet: scanned to height 127682...
Wallet: scanned to height 127741...
Wallet: scanned to height 127809...
Wallet: scanned to height 127873...
Wallet: scanned to height 127941...
Wallet: scanned to height 128009...
Wallet: scanned to height 128080...
Wallet: scanned to height 128147...
Wallet: scanned to height 128218...
Wallet: scanned to height 128274...
Wallet: scanned to height 128316...
Wallet: scanned to height 128373...
Wallet: scanned to height 128430...
Wallet: scanned to height 128488...
Wallet: scanned to height 128539...
Wallet: scanned to height 128578...
Wallet: scanned to height 128631...
Wallet: scanned to height 128687...
Wallet: scanned to height 128745...
Wallet: scanned to height 128802...
Wallet: scanned to height 128840...
Wallet: scanned to height 128881...
Wallet: scanned to height 128920...
Wallet: scanned to height 128977...
Wallet: scanned to height 129030...
Wallet: scanned to height 129084...
Wallet: scanned to height 129141...
Wallet: scanned to height 129198...
Wallet: scanned to height 129241...
Wallet: scanned to height 129294...
Wallet: scanned to height 129324...
Wallet: scanned to height 129373...
Wallet: scanned to height 129431...
Wallet: scanned to height 129486...
Wallet: scanned to height 129536...
Wallet: scanned to height 129588...
Wallet: scanned to height 129646...
Wallet: scanned to height 129711...
Wallet: scanned to height 129773...
Wallet: scanned to height 129830...
Wallet: scanned to height 129874...
Wallet: scanned to height 129928...
Wallet: scanned to height 129983...
Wallet: scanned to height 130034...
Wallet: scanned to height 130090...
Wallet: scanned to height 130147...
Wallet: scanned to height 130205...
Wallet: scanned to height 130266...
Wallet: scanned to height 130308...
Wallet: scanned to height 130360...
Wallet: scanned to height 130409...
Wallet: scanned to height 130462...
Wallet: scanned to height 130521...
Wallet: scanned to height 130556...
Wallet: scanned to height 130612...
Wallet: scanned to height 130643...
Wallet: scanned to height 130689...
Wallet: scanned to height 130743...
Wallet: scanned to height 130786...
Wallet: scanned to height 130836...
Wallet: scanned to height 130872...
Wallet: scanned to height 130915...
Wallet: scanned to height 130966...
Wallet: scanned to height 131010...
Wallet: scanned to height 131061...
Wallet: scanned to height 131099...
Wallet: scanned to height 131124...
Wallet: scanned to height 131185...
Wallet: scanned to height 131240...
Wallet: scanned to height 131288...
Wallet: scanned to height 131319...
Wallet: scanned to height 131346...
Wallet: scanned to height 131396...
Wallet: scanned to height 131459...
Wallet: scanned to height 131511...
Wallet: scanned to height 131581...
Wallet: scanned to height 131639...
Wallet: scanned to height 131695...
Wallet: scanned to height 131753...
Wallet: scanned to height 131818...
Wallet: scanned to height 131861...
Wallet: scanned to height 131920...
Wallet: scanned to height 131980...
Wallet: scanned to height 132046...
Wallet: scanned to height 132103...
Wallet: scanned to height 132157...
Wallet: scanned to height 132220...
Wallet: scanned to height 132278...
Wallet: scanned to height 132336...
Wallet: scanned to height 132401...
Wallet: scanned to height 132453...
Wallet: scanned to height 132513...
Wallet: scanned to height 132569...
Wallet: scanned to height 132626...
Wallet: scanned to height 132682...
Wallet: scanned to height 132730...
Wallet: scanned to height 132775...
Wallet: scanned to height 132832...
Wallet: scanned to height 132887...
Wallet: scanned to height 132942...
Wallet: scanned to height 132989...
Wallet: scanned to height 133036...
Wallet: scanned to height 133094...
Wallet: scanned to height 133153...
Wallet: scanned to height 133215...
Wallet: scanned to height 133275...
Wallet: scanned to height 133329...
Wallet: scanned to height 133386...
Wallet: scanned to height 133448...
Wallet: scanned to height 133510...
Wallet: scanned to height 133555...
Wallet: scanned to height 133616...
Wallet: scanned to height 133661...
Wallet: scanned to height 133716...
Wallet: scanned to height 133775...
Wallet: scanned to height 133827...
Wallet: scanned to height 133884...
Wallet: scanned to height 133944...
Wallet: scanned to height 133991...
Wallet: scanned to height 134040...
Wallet: scanned to height 134074...
Wallet: scanned to height 134129...
Wallet: scanned to height 134171...
Wallet: scanned to height 134234...
Wallet: scanned to height 134288...
Wallet: scanned to height 134350...
Wallet: scanned to height 134398...
Wallet: scanned to height 134455...
Wallet: scanned to height 134516...
Wallet: scanned to height 134574...
Wallet: scanned to height 134615...
Wallet: scanned to height 134670...
Wallet: scanned to height 134725...
Wallet: scanned to height 134775...
Wallet: scanned to height 134829...
Wallet: scanned to height 134884...
Wallet: scanned to height 134929...
Wallet: scanned to height 134986...
Wallet: scanned to height 135035...
Wallet: scanned to height 135098...
Wallet: scanned to height 135137...
Wallet: scanned to height 135202...
Wallet: scanned to height 135264...
Wallet: scanned to height 135321...
Wallet: scanned to height 135382...
Wallet: scanned to height 135452...
Wallet: scanned to height 135508...
Wallet: scanned to height 135568...
Wallet: scanned to height 135638...
Wallet: scanned to height 135715...
Wallet: scanned to height 135773...
Wallet: scanned to height 135846...
Wallet: scanned to height 135934...
Wallet: scanned to height 136018...
Wallet: scanned to height 136114...
Wallet: scanned to height 136205...
Wallet: scanned to height 136277...
Wallet: scanned to height 136345...
Wallet: scanned to height 136407...
Wallet: scanned to height 136473...
Wallet: scanned to height 136527...
Wallet: scanned to height 136589...
Wallet: scanned to height 136645...
Wallet: scanned to height 136713...
Wallet: scanned to height 136774...
Wallet: scanned to height 136832...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Wallet: scanned to height 136852...
Done!
Bug Report
Check to see if a bug report already exists.  If you still want to create a new issue please include the information below.
Stack Trace or error message
Environment

Sia version:
OS:

Any useful logs
Feature Request
Check to see if the feature is on the roadmap.  If it is not on the roadmap then clearly describe your feature request and why it would benefit Sia.
Sia roadmap

All the the attached output is normal output.  If you have additional logs or information please reopen this issue and attache the additional information.
Read this document to find your logs: https://gist.github.com/tbenz9/8066d74853ab28c23bd7bc1d3c7cdeda


Readme updated

Ok, I am new to Github and Pull Requests.
With time I will learn how to use this properly.


Throw original error when rejection reason instance of Error

Fix for #93

Coverage remained the same at 100.0% when pulling bb15ee1a881a0bdfa68025d053ab3cc6aa608ac5 on umidbekkarimov:93 into 83fb3b69f1b784a8c21430a1a0f7659f920c3348 on pburtchaell:master.

Thanks! This is released as<EMAIL_ADDRESS>


How do I re-use the database connection pool that I already closed?

Hello,
I have an issue with the following operation, and I cannot seem to find anything related to this issue on online documentation anywhere.
Would you guys mind pointing me to the right direction?
Environment details

OS: Mac OS high sierra
Node.js version: v7.9.0
npm version: v4.2.0
@google-cloud/spanner version: v0.8.1

Steps to reproduce

Execute a select query
Close database by database.close()
Create new database by instance.database('myDatabase')
Execute another select query with the new database object
Error: pool is draining and cannot accept work

@voltrue2 we have since swapped out pooling libraries and refactored a few other items. If possible, could you try upgrading to 1.0.x to see if that resolves your issue?

@callmehiphop Any update on this question?
Cheers

@voltrue2 I actually haven't been able to reproduce this, even when using your example. I have a hunch why and made a branch with a possible fix. Could you test against it to see if it resolves your issue?

@callmehiphop
OK I understand. Let me try and see if this makes any difference.
Cheers!

@callmehiphop I am still in the process of testing the new branch. (My apologies for taking long...)
I have a question, though.
What would be the best practice to manage the connections?
Should I be making the database object per database on starting of the process and re-use them?
// we do this ONCE on starting of the process
const spanner = Spanner({ projectId: projectId });
const instance = spanner.instance(instanceId);
const databases = {};
databases.myDb = instance.database('myDb');
databases.hisDb = instance.database('hisDb');
databases.herDb = instance.database('herDb');
// we re-use these and close them on exit of the process...
function onExitProcess() {
  databases.myDb.close();
  databases.hisDb.close();
  databases.herDb.close();
}

Or should I be making the database instance every time we need a connection and close it when we are done?
This is much slower for obvious reason of course...
function readFromMyDb() {
  var spanner = Spanner({ projectId: projectId });
  var instance = spanner.instance(instanceId);
  var db = instance.database('myDb');
  db.run({ sql: 'xxxx', params: {...} })
  .then(() => {
   // close the connection
    db.close();
   })
  .catch(...);
}

Cheers!

You should make the database object just once per database and reuse. That
will be much more peeformant.
On Wed, Feb 21, 2018, 9:06 PM Nobuyori Takahashi<EMAIL_ADDRESS>wrote:

@callmehiphop https://github.com/callmehiphop I am still in the process
of testing the new branch. (My apologies for taking long...)
I have a question, though.
What would be the best practice to manage the connections?
Should I be making the database object per database on starting of the
process and re-use them?
// we do this ONCE on starting of the processconst spanner = Spanner({ projectId: projectId });const instance = spanner.instance(instanceId);const databases = {};databases.myDb = instance.database('myDb');databases.hisDb = instance.database('hisDb');databases.herDb = instance.database('herDb');// we re-use these and close them on exit of the process...function onExitProcess() {
databases.myDb.close();
databases.hisDb.close();
databases.herDb.close();
}
Or should I be making the database instance every time we need a
connection and close it when we are done?
This is much slower for obvious reason of course...
function readFromMyDb() {
var spanner = Spanner({ projectId: projectId });
var instance = spanner.instance(instanceId);
var db = instance.database('myDb');
db.run({ sql: 'xxxx', params: {...} })
.then(() => {
// close the connection
db.close();
})
.catch(...);
}
Cheers!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/googleapis/nodejs-spanner/issues/117#issuecomment-367568879,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATdef4OKyayILhOZSBTORtOleWWArQ4Kks5tXPXugaJpZM4R_r_9
.

@vkedia
Thank you! Got it.
By the way, I was able to solve the issue that I initially had with the new branch @callmehiphop gave me.
But now I have this 1 session leak(s) found. error when I terminate the application process while reading and/or writing rapidly.
What I do on termination of the process is to call .close(...) on all database objects and wait for callbacks, and then terminate the process.
I was wondering if this is how you terminate all connections to Spanner properly?
Cheers

@voltrue2 that error will have a messages attribute containing a call stack for each leak found. Usually it means a transaction was started but never finished. I would use the call stack to find the transaction in question to make sure that end() is being called for read only transactions and commit() is being called for read/write transactions.

@callmehiphop Great! thank you for the pointer. I will look at my code once again to see where I have missed the end of transaction(s).
Cheers!


On first boot, LXD installation may take a long time. Show progress instead of infinite spinner.

Some background:

We're using fabric and invoke to make remote calls.
The main entrypoint is yurt.lxc.util.initialize_lxd.
Low level utilities are defined in yurt.util. The interesting ones for this issue are:

yurt.util._get_ssh_connection
yurt.util._run_in_vm
yurt.util.run_in_vm

No longer an issue. No installation step in 20.04.


Build process stuck in testing phase

I'm building a nodejs project , my unit tests are written with mocha and invoked using gulp-mocha during the test phase. When my test fails it accurately fails the build. When I comment out my test completely the build turns green. But when my tests run and they pass, it says tests success test completed, but the build keeps spinning and never turns green.

Could you share some more details? How are your tests invoked? npm test? Can you see if some process is still running? Will it timeout at some point? Maybe even a screenshot of the build output?

In the custom script plugin in the test phase I run gulp test, which just
runs gulp-mocha. Tests run perfectly but the build just keeps spinning
after they finish. Im out right now but will post screenshots and code
snippets when I get home. Thanks for taking a look in the meantime
On Jun 28, 2016 1:39 PM, "Oliver Salzburg"<EMAIL_ADDRESS>wrote:

Could you share some more details? How are your tests invoked? npm test?
Can you see if some process is still running? Will it timeout at some
point? Maybe even a screenshot of the build output?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Strider-CD/strider/issues/949#issuecomment-229124654,
or mute the thread
https://github.com/notifications/unsubscribe/ADEBQ2CuZaQj4Am_490krFuq9Z65oafRks5qQVxYgaJpZM4JAVX4
.

If possible, I'd also love to see the log of strider itself. Maybe there are some errors. I've personally never used the custom plugin to run the tests. I just put my test command in the scripts section of my package.json.
Maybe there is some bug in the strider-custom plugin... Hard to say. Would love more input :)

When you run the test locally, does it return to the console input? Or do you have to use ctrl+c?

Now that you mention it, I believe it stays open and I had to end it with
ctrl+c. This might be a gulp issue and not strider issue. I will verify
when I'm home and if so will close this issue. Thanks for your help
On Jun 28, 2016 2:03 PM, "Ilya Radchenko"<EMAIL_ADDRESS>wrote:

When you run the test locally, does it return to the console input? Or do
you have to use ctrl+c?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Strider-CD/strider/issues/949#issuecomment-229131754,
or mute the thread
https://github.com/notifications/unsubscribe/ADEBQ-E-j0OLypNc6nH9Tb7DbL79KdgDks5qQWH3gaJpZM4JAVX4
.

@knownasilya @oliversalzburg Looks like this was a gulp-mocha issue associated with supertest. Here is the related issue. https://github.com/sindresorhus/gulp-mocha/issues/28
I fixed this by implementing gulp-exit. Thanks again for the quick responses & help.


Error when trying to add a new param number

GOOD DAY. WHEN I TRY TO ADD ANOTHER ITEM, THIS ERROR POPS UP. WHAT ABOUT IT?

Thanks for reporting this.
I have tried to reproduce this issue, but adding another item by number just works without errors popping up in my system.
Could you please:

Describe the steps you took to get to the situation where this error occurred.
Tell what version of the integration you use, and if you have a 120V or 240V system
See if the logs provide more detailed information: go to Settings->System->Logs then press the three dots at the right top and choose 'show full logs' or press the down arrow at the right top to download the logs and add them to this issue.

Thanks

I DID EVERYTHING ACCORDING TO THE INSTRUCTIONS. AFTER ENTERING THE
ADDITION BY THE NUMBER 7003 OR ANY OTHER, THIS ERROR POPS UP. OTHERWISE, THE
APPLICATION WORKS WITHOUT PROBLEMS, I JUST CANNOT ADD OTHER PARAMETERS.
2. 2024.11.33. ANNEX---------- Původní e-mail ----------
Od: Anko Hanse @.>
Komu: ankohanse/hass-studer-xcom @.>
Kopie: ferdicek @.>, Author @.
github.com>
Datum: 25. 11. 2024 20:51:49
Předmět: Re: [ankohanse/hass-studer-xcom] ERRORS (Issue #11)
"

Thanks for reporting this.
I have tried to reproduce this issue, but adding another item by number just
works without errors popping up in my system.
Could you please:

Describe the steps you took to get to the situation where this error
occurred.
Tell what version of the integration you use, and if you have a 120V
or 240V system
See if the logs provide more detailed information: go to Settings->
System->Logs then press the three dots at the right top and choose 'show
full logs' or press the down arrow at the right top to download the logs
and add them to this issue.

Thanks
—
Reply to this email directly, view it on GitHub
(https://github.com/ankohanse/hass-studer-xcom/issues/11#issuecomment-2498901812)
, or unsubscribe
(https://github.com/notifications/unsubscribe-auth/AESILUIASWGSRFU6KMXNK2T2CN5VFAVCNFSM6AAAAABSOX2IKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJYHEYDCOBRGI)
.
You are receiving this because you authored the thread. Message ID: <
@.***>
"

While I am searching for the cause of this issue, could you try if you can add a params or info via the menu structure:

IT SEEMS THAT IT WORKS THROUGH THE ADD ITEM VIA MENU BUT MY PC LOCKED UP.
AFTER RESTARTING THE PC, EVERYTHING STARTED OK.
---------- Původní e-mail ----------
Od: Anko Hanse @.>
Komu: ankohanse/hass-studer-xcom <hass-studer-xcom @noreply.github.com>
Kopie: ferdicek @.>, Autor @.***
github.com>
Datum: 25. 11. 2024 23:09:56
Předmět: Re: [ankohanse/hass-studer-xcom] Chyba při pokusu o přidání nového
čísla parametru (vydání #11)
"
Zatímco hledám příčinu tohoto problému, můžete zkusit, zda můžete přidat
parametry nebo informace prostřednictvím struktury nabídky:
—
Odpovězte přímo na tento e-mail, zobrazte jej na GitHubu
(https://github.com/ankohanse/hass-studer-xcom/issues/11#issuecomment-2499138427)
nebo se odhlaste z odběru
(https://github.com/notifications/unsubscribe-auth/AESILUNHZYWN4QYGAHMIYRL2CON3DAVCNFSM6AAAAABSOX2IKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJZGEZTQNBSG4)
.
Dostáváte to, protože jste autorem vlákna. ID zprávy: <ankohanse/hass-studer
-xcom/issues/11/2499138427 @ github . com>
"

Not able to reproduce this issue, and to little information provided for me to work with.

When inserting the parameter via add item via menu, everything is OK. Thank
you.
---------- Původní e-mail ----------
Od: Anko Hanse @.>
Komu: ankohanse/hass-studer-xcom @.>
Kopie: ferdicek @.>, Author @.
github.com>
Datum: 21. 12. 2024 5:03:09
Předmět: Re: [ankohanse/hass-studer-xcom] Error when trying to add a new
param number (Issue #11)
"
Closed #11(https://github.com/ankohanse/hass-studer-xcom/issues/11) as not
planned.
—
Reply to this email directly, view it on GitHub
(https://github.com/ankohanse/hass-studer-xcom/issues/11#event-15738672468),
or unsubscribe
(https://github.com/notifications/unsubscribe-auth/AESILUPXRGJQZ6VETUROY732GTR7PAVCNFSM6AAAAABSOX2IKCVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJVG4ZTQNRXGI2DMOA)
.
You are receiving this because you authored the thread. Message ID: <
@.***>
"

Reopening as I just managed to reproduce this while testing another issue.
Error only occurs after following steps:

Delete Studer-Innotec integration if it was already installed
Add Studer Innotec integration.

Configure Voltage and Port
Immediately choose 'Add param by number', and choose a device and a number. Error will show
Remove number and press submit to go back to overview
Choose 'Add param by menu', choose a device and user-level and add a number.
Again choose 'Add param by number' and choose a device and number. Error no longer shows.

Error occurs because it tries to inspect a user-level that has not yet been set, but only is set after the 'Add param by menu'. That user level is not needed for 'Add param by number', but code still passes a line where it is looked at

Fix will be included in v2025.01.1, which will be released in the first few days of 2025

OK. Thank you.
---------- Původní e-mail ----------
Od: Anko Hanse @.>
Komu: ankohanse/hass-studer-xcom @.>
Kopie: ferdicek @.>, Author @.
github.com>
Datum: 28. 12. 2024 8:34:13
Předmět: Re: [ankohanse/hass-studer-xcom] Error when trying to add a new
param number (Issue #11)
"
Fix will be included in v2025.01.1, which will be released in the first few
days of 2025
—
Reply to this email directly, view it on GitHub
(https://github.com/ankohanse/hass-studer-xcom/issues/11#issuecomment-2564246971)
, or unsubscribe
(https://github.com/notifications/unsubscribe-auth/AESILUJVAIGQN7MQ7WZKLML2HZH7BAVCNFSM6AAAAABSOX2IKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRUGI2DMOJXGE)
.
You are receiving this because you authored the thread. Message ID: <
@.***>
"


ERROR

└─# twint -u canalN_                                                                                1 ⨯
Traceback (most recent call last):
File "/usr/local/bin/twint", line 5, in
from twint.cli import run_as_command
File "/root/.local/lib/python3.9/site-packages/twint/init.py", line 14, in
from . import run
File "/root/.local/lib/python3.9/site-packages/twint/run.py", line 4, in
from . import datelock, feed, get, output, verbose, storage
File "/root/.local/lib/python3.9/site-packages/twint/get.py", line 12, in
from aiohttp_socks import ProxyConnector, ProxyType
File "/usr/local/lib/python3.9/dist-packages/aiohttp_socks/init.py", line 5, in
from .connector import (
File "/usr/local/lib/python3.9/dist-packages/aiohttp_socks/connector.py", line 8, in
from aiohttp.helpers import CeilTimeout  # noqa
ImportError: cannot import name 'CeilTimeout' from 'aiohttp.helpers' (/usr/lib/python3/dist-packages/aiohttp/helpers.py)

You opened two issues based on the same error see reply to your original? https://github.com/twintproject/twint/issues/1332

Also if you used the search and search for keyword like CeilTimeout you find the fix https://github.com/twintproject/twint/issues/1297#issuecomment-958105596


enhancement: add vimeo support

pretty much what the title says. i would love to be able to scrape vimeo comments to csv/json as well.

Maybe someday, but it wouldn't be part of the Youtube Comment Scraper :wink:


Report bug and suggest feture

both lead to google form, but cant fill out form

Hello!
I'm not quite sure what you mean.
If the google form page is not letting you type anything, I'm not sure there's much that can be done.
Otherwise, if the google form page is telling you that you don't have access then google form, then it probably thinks you aren't logged into your Harker account (since I restricted it the form to only be open to Harker students).

K
Thx
On Sat, Nov 11, 2017 at 5:20 PM, rianadon<EMAIL_ADDRESS>wrote:

Hello!
I'm not quite sure what you mean.
If the google form page is not letting you type anything, I'm not sure
there's much that can be done.
Otherwise, if the google form page is telling you that you don't have
access then google form, then it probably thinks you aren't logged into
your Harker account (since I restricted it the form to only be open to
Harker students).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/rianadon/CheckPCR/issues/15#issuecomment-343706612,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYUQvmjvZp2FXP4ORSrxAbPLb-jJCiq5ks5s1kfFgaJpZM4QXd1d
.

Did that help fix the problem or is the form still not working for you?


Add token auth

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@07af86e). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master       #7   +/-   ##
=========================================
  Coverage          ?   87.81%
=========================================
  Files             ?        7
  Lines             ?      320
  Branches          ?        0
=========================================
  Hits              ?      281
  Misses            ?       39
  Partials          ?        0

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


Use path library for path manipulation

Fix #259.
Currently, this action relies heavily on string manipulation techniques to compose paths. This approach is prone to error, particularly in the context of Windows and inconsistent use of native path delimiters. This PR uses the standard Node path library to manipulate paths.

Link to test run that replicates #259, using the install directory / and test runner windows-latest: https://github.com/ddalcino/install-qt-action/actions/runs/11786060831/job/32828603078#step:9:1
Note the broken environment variables:IQTA_TOOLS: \\Qt\Tools\
QT_ROOT_DIR: D:\Qt\6.7.0\msvc2019_64\bin\qmake.exe
QT_PLUGIN_PATH: D:\Qt\6.7.0\msvc2019_64\bin\qmake.exe\plugins
QML2_IMPORT_PATH: D:\Qt\6.7.0\msvc2019_64\bin\qmake.exe\qml

Link to failing test run that explicitly checks the QT_ROOT_DIR variable: https://github.com/ddalcino/install-qt-action/actions/runs/11786135722/job/32828835488#step:8:1
Link to passing test run, with environment identical to the failing runs, after the fix is applied: https://github.com/ddalcino/install-qt-action/actions/runs/11786675815/job/32830453747#step:8:1
Note the fixed environment variables:IQTA_TOOLS: \Qt\Tools
QT_ROOT_DIR: D:\Qt\6.7.0\msvc2019_64
QT_PLUGIN_PATH: D:\Qt\6.7.0\msvc2019_64\plugins
QML2_IMPORT_PATH: D:\Qt\6.7.0\msvc2019_64\qml

This is definitely a big improvement and the right path. But I can't help but point out that passing output of path.join to nativePath aka path.normalize is pretty redundant now, since the output of path.join is already normalized. Note that this is not the same as path.resolve for example, but that one is not used...
Btw if poking at paths already, I think that this: const nativePath = process.platform === "win32" ? path.win32.normalize : path.normalize; is also redundant. Afaik Path API is gonna already behave with win32 behavior on win32 platform, I think this path.win32 implementations are explicitly only exposed if win32-specific behavior is desired for example during tests, otherwise it's kinda unnecessary, while making it a bit more cryptic what "nativePath" is, compared to just using path.normalize directly...

If there's still value in unit testing feel free to pull in the jurplel/fix-qt-root-dir changes. It looks like it is covered in CI now, though.
Is the test that failed just flakiness?

If there's still value in unit testing feel free to pull in the jurplel/fix-qt-root-dir changes. It looks like it is covered in CI now, though.

I think unit testing is a really good idea, but I'd like to keep that separate from this PR for now.

Looks like the failed test is just flakiness?

The failed test does not appear related to the changes in this PR. Relevant code:
https://github.com/jurplel/install-qt-action/blob/09d1e7966eaadf665fefd47f817694db0a21a339/.github/workflows/test.yml#L138-L144
The failed runs indicate that on some MacOS test runners, /Applications/Xcode_14.3.1.app does not exist:
xcode-select: error: invalid developer directory '/Applications/Xcode_14.3.1.app'

Maybe we could get around it with a glob star, like sudo xcode-select --switch /Applications/Xcode_14.*.app? That could get messy if it picks the wrong one, or the glob star returns multiple apps.
According to the bug report, this was fixed in Qt 6.5.3, so maybe the fix is no longer needed?

That Xcode failure is related to https://github.com/actions/runner-images/issues/10703 and I don't think it's possible to build with Qt < 6.5.3 on GitHub Actions with the newer runners (macOS 14/15) anymore; only macOS 13 and the soon-to-be-retired macOS 12 runners.


Potential problem in TIMG0 as embassy-time source

I discovered today when debugging a strange timing issue that sometimes I get very large and inconsistent GPIO interrupt latencies:
2024-02-20T17:48:15.207831Z DEBUG magic_loc_central: IMU interval: 1007 us
2024-02-20T17:48:15.208901Z DEBUG magic_loc_central: Decoded packet from 0: ImuReport { tag_addr: 1, system_ts: 18962370, accel: [64808, 4233, 4502], gyro: [9, 65530, 15] }
2024-02-20T17:48:15.208935Z DEBUG magic_loc_central: IMU interval: 994 us
2024-02-20T17:48:15.210035Z DEBUG magic_loc_central: Decoded packet from 0: ImuReport { tag_addr: 1, system_ts: 18964365, accel: [64845, 4229, 4490], gyro: [10, 65530, 15] }
2024-02-20T17:48:15.210070Z DEBUG magic_loc_central: IMU interval: 1995 us
2024-02-20T17:48:15.210077Z ERROR magic_loc_central: IMU interval too large: 1995 us
2024-02-20T17:48:15.211301Z DEBUG magic_loc_central: Decoded packet from 0: ImuReport { tag_addr: 1, system_ts: 18965652, accel: [64808, 4236, 4501], gyro: [9, 65532, 13] }
2024-02-20T17:48:15.211335Z DEBUG magic_loc_central: IMU interval: 1287 us
2024-02-20T17:48:15.212597Z DEBUG magic_loc_central: Decoded packet from 0: ImuReport { tag_addr: 1, system_ts: 18966404, accel: [64827, 4238, 4495], gyro: [10, 65530, 15] }
2024-02-20T17:48:15.212631Z DEBUG magic_loc_central: IMU interval: 752 us
2024-02-20T17:48:15.213671Z DEBUG magic_loc_central: Decoded packet from 0: ImuReport { tag_addr: 1, system_ts: 18967405, accel: [64825, 4212, 4519], gyro: [10, 65530, 14] }
2024-02-20T17:48:15.213705Z DEBUG magic_loc_central: IMU interval: 1001 us
2024-02-20T17:48:15.215003Z DEBUG magic_loc_central: Decoded packet from 0: ImuReport { tag_addr: 1, system_ts: 18968349, accel: [64823, 4239, 4508], gyro: [9, 65531, 14] }
2024-02-20T17:48:15.215038Z DEBUG magic_loc_central: IMU interval: 944 us
2024-02-20T17:48:15.215965Z DEBUG magic_loc_central: Decoded packet from 0: ImuReport { tag_addr: 1, system_ts: 18969229, accel: [64823, 4225, 4503], gyro: [10, 65530, 16] }
2024-02-20T17:48:15.215988Z DEBUG magic_loc_central: IMU interval: 880 us
2024-02-20T17:48:15.217289Z DEBUG magic_loc_central: Decoded packet from 0: ImuReport { tag_addr: 1, system_ts: 18970425, accel: [64816, 4211, 4488], gyro: [10, 65530, 15] }
2024-02-20T17:48:15.217311Z DEBUG magic_loc_central: IMU interval: 1196 us
2024-02-20T17:48:15.218465Z DEBUG magic_loc_central: Decoded packet from 0: ImuReport { tag_addr: 1, system_ts: 18972498, accel: [64808, 4249, 4506], gyro: [10, 65529, 14] }

It turns out everything works no problem when I change one line:
    // let timer_group0 = hal::timer::TimerGroup::new(peripherals.TIMG0, &clocks);
    let systick = hal::systimer::SystemTimer::new(peripherals.SYSTIMER);
    embassy::init(&clocks, systick);

    spawner.must_spawn(startup_task(clocks));

Since the time values sum to 1 second scale I am guessing that the TIMG0 interrupt is fired for too many times and eats CPU cycles, just a guess though

Out of curiosity, could you try the using the generic-queue features of embassy-time, instead of the integrated timers?

Out of curiosity, could you try the using the generic-queue features of embassy-time, instead of the integrated timers?

I am using "generic-queue-8" already

Do bigger queue values help?

Is it possible to create a minimal-repro of this behavior?

Thinking about this, but recently I am too cramped with conference deadlines...

Is it possible to create a minimal-repro of this behavior?

Do bigger queue values help?

I can test in a few days

Hey @ProfFan, did you get around to digging into this a bit more?

@MabezDev Sorry not yet, got too many deadlines on hand now...

I'm going to close this for now, @ProfFan please re open when you find out more details :)


756 ABM benchmark

Changes and Information
Added a benchmark for the ABM, currently to be run manually, will be added to CI in the future.
Please confirm that the benchmark covers all features, locations, infections, etc, I may have missed some.
Partial solution for #756, not closed yet.
Merge Request - Guideline Checklist
Please check our git workflow. Use the draft feature if the Pull Request is not yet ready to review.
Checks by code author

[x] Every addressed issue is linked (use the "Closes #ISSUE" keyword below)
[x] New code adheres to coding guidelines
[x] No large data files have been added (files should in sum not exceed 100 KB, avoid PDFs, Word docs, etc.)
[x] Tests are added for new functionality and a local test run was successful
[x] Appropriate documentation for new functionality has been added (Doxygen in the code and Markdown files if necessary)
[x] Proper attention to licenses, especially no new third-party software with conflicting license has been added

Checks by code reviewer(s)

[x] Corresponding issue(s) is/are linked and addressed
[x] Code is clean of development artifacts (no deactivated or commented code lines, no debugging printouts, etc.)
[x] Appropriate unit tests have been added, CI passes and code coverage is acceptable (did not decrease)
[x] No large data files added in the whole history of commits(files should in sum not exceed 100 KB, avoid PDFs, Word docs, etc.)

feel free to add a reviewer if you feel someone else can better judge this.

lockdown_rules are not included, I don't know if dampings make a difference, but could be
locations can have npi's active, e.g. masks, for that to be tested it needs to be activated, that could lead to performance decreases
trips are not measured

I wouldn't expect adding dampings to make a difference, unless you are adding dampings dynamically during the simulation. I'll check.
Masks probably should be included.
Trips are not included intentionally, I feel they aren't really used or developed right now. They also aren't parallelized yet. So I didn't add that. Also, for trips we need a second benchmark anyway, I don't think this works in the same benchmark. We can add that later.

Created Issue #835 to add the benchmark to CI


How to use jaeger's UI to read data from the elasticsearch written by zipkin.

We currently use zipkin to collect data (jaeger does not support Dubbo). ES stores zipkin data. I know that zipkin and jaeger have different data formats. Maybe I need to set up a query service and then go to ES to query. (I don't know how to build it)
I would like to know if jaeger provides such tools for data conversion between zipkin and jaeger.
I am a beginner, thank you very much！！！

Jaeger can integrate with Zipkin instrumentation at the collection API, i.e. jaeger-collector can accept spans in Zipkin format (json, thrift, and proto). But it does not integrate with implementation details of Zipkin such as storage formats (or even query service API) because of the difference in the data models.

Jaeger can integrate with Zipkin instrumentation at the collection API, i.e. jaeger-collector can accept spans in Zipkin format (json, thrift, and proto). But it does not integrate with implementation details of Zipkin such as storage formats (or even query service API) because of the difference in the data models.

You mean Jaeger collector can collect the data reported by Zipkin, but their data model is different.
Now, I use Zipkin client to send data to Kafka (HTTP is not allowed by the company), consume Kafka data through Jaeger server, and then store it in ES. Finally, use the Jaeger UI to show it. Is this solution OK?
Is there another better solution? Thank you very much.

I'm going to close this issue here as the ask is now outside the scope of the Zipkin ecosystem.
Zipkin provides a propagation format (B3) and a data model (API v2: https://zipkin.io/zipkin-api/).  These models are open and for everyone to integrate with.
If you are dead set on using the Jaeger UI instead of the Zipkin Lens UI while using Zipkin instrumentation you will have to find or write a Jaeger specific collector that listens on Kafka and understands Zipkin data model payloads.


added def recursive_search, def non_recursive_search and def is_hidden_file_or_dir

changelog:

For allow to choose inclusion or exclusion of hidden files/directories:

Added def recursive_search, def non_recursive_search and def is_hidden_file_or_dir to utils/file_handlers.py

Added tests for new functions, new test dataset for Windows and Linux (with hidden filles)
Added platform_name = sys.platform in main.py
if not include_hidden and is_hidden_file_or_dir(platform_name, location):
print(f'\nNot counting any files, because {loc_text[2:]} is hidden.') moved to top
TODO:
adapt for Pythonista/iOS and test.
add checking for hidden folder in Windows to skip it.
check the speed of processing large folders for def recursive_search, def non_recursive_search (Windows and Linux)
Note: Integration tests are falling due to unresolved reference 'unicode' in def _has_hidden_attribute (utils/file_handlers.py)

Updated. tests are still falling with:
attrs = ctypes.windll.kernel32.GetFileAttributesW(filepath)
ctypes.ArgumentError: argument 1: <class 'TypeError'>: Don't know how to convert parameter 1


CustomCollectionFieldType.dropdown doesn't open on focus

Category

[X] Enhancement
[X] Bug
[ ] Question

Version
1.14.0
Expected / Desired Behavior / Question
When tabbing across a row, the dropdown field type should open automatically to indicate it is a dropdown option.
Observed Behavior
When tabbing across a row, the dropdown field type doesn't open the list options automatically.
Steps to Reproduce
Create a collection data with two columns of text field and add a dropdown with a few options. Then try to enter data and use tab to move to next column to enter data. The dropdown field column will just focus, but not open the dropdown options until clicked. Using the up/down arrows does however toggle through the options, but it never opens.

Hi @malcom1120,
Standard behaviors for focused dropdowns is just show the focus.
key down is usually used to either open the list of options or iterate through the options.
We're using the behavior of Fluent UI Dropdown


Delete Kokoro directory

We no longer use Kokoro for CI. There are still some references to it
throughout the repo, but no references to these paths. I'll clean up
the other references separately.
Part of https://github.com/iree-org/iree/issues/9855

I thought we might have had some references to build_tools/kokoro/ in old buildkite pipelines or other scripts, but it looks like we don't (anymore?).

Nothing in the repository. I think I fixed some of them at some point. I'm also not super sympathetic if someone hardcoded a path to a Kokoro directory from something other than Kokoro and not checked into source control...


suport foundationdb for meta engine

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.yfeng seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Codecov Report

Merging #2581 (045999e) into main (07aa229) will increase coverage by 0.00%.
The diff coverage is 77.33%.

:exclamation: Current head 045999e differs from pull request most recent head a918e14. Consider uploading reports for the commit a918e14 to get more accurate results

@@           Coverage Diff            @@
##             main    #2581    +/-   ##
========================================
  Coverage   59.75%   59.75%
========================================
  Files         138      139     +1
  Lines       23740    23556   -184
========================================
- Hits        14186    14077   -109
+ Misses       7712     7654    -58
+ Partials     1842     1825    -17

Impacted Files
Coverage Δ

pkg/meta/tkv_fdb.go
77.33% <77.33%> (ø)

pkg/vfs/vfs_unix.go
76.23% <0.00%> (-15.21%)
:arrow_down:

pkg/utils/utils.go
70.37% <0.00%> (-3.71%)
:arrow_down:

pkg/object/minio.go
61.29% <0.00%> (-3.42%)
:arrow_down:

pkg/fuse/fuse.go
76.64% <0.00%> (-2.92%)
:arrow_down:

pkg/object/sql.go
51.00% <0.00%> (-2.64%)
:arrow_down:

cmd/fsck.go
63.82% <0.00%> (-2.25%)
:arrow_down:

cmd/dump.go
76.92% <0.00%> (-2.15%)
:arrow_down:

pkg/utils/logger.go
62.26% <0.00%> (-1.68%)
:arrow_down:

cmd/mount.go
59.15% <0.00%> (-1.34%)
:arrow_down:

... and 20 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Improve names of binary operators in json

This MR improves the names of the conditional binary operators.
if flag(pkg-config) && !impl(ghcjs) && !os(ghcjs)
    -- NB: pkg-config is available on windows as well when using msys2
    pkgconfig-depends: zlib

Now results in
{
  "cond_and_1": {
    "cond_and_1": {
      "variable": {
        "flag": "pkg-config"
      }
    },
    "cond_and_2": {
      "cond_not": {
        "variable": {
          "compiler": "GHCJS",
          "version": "-any"
        }
      }
    }
  },
  "cond_and_2": {
    "cond_not": {
      "variable": {
        "os": "Ghcjs"
      }
    }
  }
}

That looks much more workable than before. In case I till run into trouble, I'll just let you know ;)


iOS beforeSave issue

The beforeSave trigger seems to be giving an issue when I update the table it from iOS, it is working perfectly in Android (java). The code is show below. What could be the issue?
<EMAIL_ADDRESS>obj[@"userId"] = [DataHolder DataHolderSharedInstance].userObject;
obj[@"yakId"] = self.objPost;
obj[@"likes"] = [NSArray array];
obj[@"dislikes"] = [NSArray array];
obj[@"imageId"] = [NSNumber numberWithInt:-1];
__block DetailsViewController *weakSelf = self;
[obj saveInBackgroundWithBlock:^(BOOL succeeded, NSError *error) {
}];
==================================================================
Parse.Cloud.beforeSave("comment", function (request, response) {
var imageId = request.object.get("imageId");

if (imageId <= 0)        //image id set to max
{
    //do some processing
     request.object.set("imageId", newid + 1);
     response.success();
}
else
{
    response.success();
}

}
======= Log Entry ================================================
I2015-09-23T10:22:15.255Z]v10 before_save triggered for comment for user TIS8ZZWw13:
Input: {"original":null,"update":{"ACL":{"*":{"read":true,"write":true},"TIS8ZZWw13":{"read":true,"write":true}},"commentText":"test comment from ipad","dislikes":[],"imageId":-1,"likes":[],"userId":{"__type":"Pointer","className":"user","objectId":"IUdeepHERj"},"yakId":{"__type":"Pointer","className":"yak","objectId":"MRV35i24Bc"}}}
Result: Update changed to {}

I started getting this issue if I updated past JS SDK 1.5.0... What version are you using?

Using the latest version

Hey guys, try using previous version of the JS SDK aka 1.5, and let us know if it works for you.
We are tracking few of these across the board, and I am not sure we have a problem in iOS/OSX SDK, since we didn't change any logic that might be related to beforeSave hooks.

1.5.0 is working for me… I tried every version after and it would create a new empty object instead of updating the original.

Will try 1.5.0. Not sure why such an issue would slip through so many
versions.
On Fri, Sep 25, 2015 at 11:31 PM, Sam Warfield<EMAIL_ADDRESS>wrote:

1.5.0 is working for me… I tried every version after and it would create a
new empty object instead of updating the original.
—
Reply to this email directly or view it on GitHub
https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/issues/311#issuecomment-143307790
.

@avagarwal, did 1.5 work good for it?
Since JS SDK is open source and the issue seems to be not on iOS specifically - I would suggest filing an issue on the Parse JS SDK repo here
Let me know if there is anything I can help you with though.


reworks how threads work again

there can now be only one rayon task spawn running at all times
makes it so SSair must pause when threads are running with condvars
threads are now started by a message across a flume channel

gotta clean up that history

i can just squash merge

the condvar is completely unnecessary when It’s paused on the entire thread like this I realized

unless I make it just pause on katmos


Command failed with exit code 3

Describe the bug
Hi, I tried many times to re-install npm, udacimak, etc , fix that''Unhandled Promise Rejection Error'', and i got this new error message:
Screenshots

Desktop (please complete the following information):

OS: [windows10 1909]
Node version: (12.13.0)
npm version: (6.12.0)
Udacimak Version: (1.4.5)
Browser [chrome]

Course Information

Nanodegree or Course name: [Android Basic Nanodegree]
Version: [1.0.0]
Locale: [zh-cn]

@Hanson7300
Hi, I also face same error in windows via github, but u use which s/w ? Is ur's json downloaded file in Android folder or in Hanson?
in Github I use  udacimak _json\Name of folder where json file located (I dont knew this is correct way to call json file)
Plz reply

@rupeshvins
The json file is in the Android folder.The auto generate folder name contains Chinese character,I rename it just for convenience.And what do you mean by s/w?
On windows 10 I useudacimak render C:\Users\Hanson\Android -t C:\Users\Hanson\Desktop and some index html files renders correctly(see the picture above),so i guess that's correct. I think the render priority is the same,so if your index html downloaded correctly,then your command is correct.

@Hanson7300 Are you rendering from China? Could you try using a VPN?

@Hanson7300 Please email me the JSON files so I can try rendering the course -<EMAIL_ADDRESS>


Diagnostic unit tests: SA1009 (ClosingParenthesisMustBeSpacedCorrectly)

Implement unit tests for #15.

I'll make a start on this one.


Error message not pointing to problem

I have this case: https://travis-ci.org/gammapy/gammapy/builds/230082206?utm_source=github_status&utm_medium=notification
saying

The log message was: Build config file had a parse error: did not find expected '-' indicator while parsing a block collection at line 158 column 5.

But really there's no problem on that line and it's a SyntaxError further down on line 175, no?
$ python -m yamllint .travis.yml
.travis.yml
  9:1       warning  missing document start "---"  (document-start)
  18:3      error    wrong indentation: expected 4 but found 2  (indentation)
  19:5      error    wrong indentation: expected 6 but found 4  (indentation)
  20:7      error    wrong indentation: expected 8 but found 6  (indentation)
  30:81     error    line too long (158 > 80 characters)  (line-length)
  31:81     error    line too long (150 > 80 characters)  (line-length)
  32:81     error    line too long (149 > 80 characters)  (line-length)
  33:81     error    line too long (178 > 80 characters)  (line-length)
  34:81     error    line too long (169 > 80 characters)  (line-length)
  35:81     error    line too long (181 > 80 characters)  (line-length)
  36:81     error    line too long (184 > 80 characters)  (line-length)
  92:81     error    line too long (90 > 80 characters)  (line-length)
  107:1     warning  comment not indented like content  (comments-indentation)
  123:10    warning  missing starting space in comment  (comments)
  126:81    error    line too long (99 > 80 characters)  (line-length)
  147:5     warning  comment not indented like content  (comments-indentation)
  147:81    error    line too long (81 > 80 characters)  (line-length)
  151:81    error    line too long (81 > 80 characters)  (line-length)
  162:81    error    line too long (85 > 80 characters)  (line-length)
  174:81    error    line too long (99 > 80 characters)  (line-length)
  175:11    error    syntax error: expected <block end>, but found '<scalar>'

Can you make travis-yaml give a better message here pointing to the actual line with the issue?
Test file is here: https://github.com/bsipocz/gammapy/blob/41e3a3e184ef799346051b7758fee5627f309518/.travis.yml
and copy here: https://gist.github.com/cdeil/59ae0750fa1a26378e9ed10271b50162

The error on the line 175 alters the parser's expectation of the data structure that starts on line 158.
Unfortunately, our Ruby parser stops parsing the file upon the first error.
http://yaml-online-parser.appspot.com/, which uses the pyyaml, shows the same error, and also the one on line 175. I am not familiar with yamllint, but https://pypi.python.org/pypi/yamllint says that it is not a validator.

Thanks for the quick reply! I just thought I'd mention it. Feel free to close if there's nothing you can do here with reasonable effort.


CP4BA AirGap support

Implement AirGap for Cp4BA role including collateral

Dehelmization or local helmchart clone
Nexus plain deployment instead of operator which doesn't support fixed version
Can create task in Roles for airgap  preparation to share image versions ansible vars


Static Assets in Reusable Razor class libraries

"When the app is published, the companion assets from all referenced projects and packages are copied into the wwwroot folder of the published app under _content/{LIBRARY NAME}/."
I think The static assets should be part of the demo app... It doesn't seem to work at all. I have followed the steps and get nothing published into wwwroot folder

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

ID: 9fd019c7-ceb7-6ef3-26ba-6b44341b6fc5
Version Independent ID: fd116d00-0dc7-efaf-c714-34d77b345a05
Content: Reusable Razor UI in class libraries with ASP.NET Core
Content Source: aspnetcore/razor-pages/ui-class.md
Product: aspnet-core
Technology: aspnetcore-razorpages
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

@guardrex  didn't you just test this?

@Rick-Anderson thx - I am using .net core 2.2 web app to consume the RCL. The RCL is very basic with one View in it and one css file in the wwwroot directory. The view works fine and is used in the consuming app but the css doesn't.
based on the comments on this issue: https://github.com/aspnet/AspNetCore.Docs/issues/7662 it seems like a lot more work is required than this help section suggests. They may be outdated comments though or perhaps I am just doing something very hastily on a friday afternoon!

@nacoleman You need to be on 3.0 Preview 6. It won't work on 2.2.
I'll check the versioning in the topic to see if we have it set up correctly.

It's versioning. I'll fix it. Thanks for reporting this @nacoleman. Sorry for the error.

@guardrex Ah ok that explains everything! Thanks for getting back to me so fast. Spent a few hours trying to figure it out but learnt a few things in the process so no harm done.

Sorry about that. We were a bit up in the air on how to host the content because static assets apply to both RCL with and without Blazor. We figured out that we wanted to put the content here and then link to it from the Blazor topic on Razor component class libraries. Getting that all figured out, we didn't get the correct versioning tags on the content. It's a simple fix (#13039). Thanks again for reporting it.

I'm a Blazor newbie and I might be missing something, but this appears to be broken again as far as I can tell. The styles.css file located in wwwroot of a referenced razor component does not get picked up by the consuming Blazor app. I'm using ASP.NET Core 3.0 and the razor component is targeting .NET Standard 2.1.


[Android] Consider configuring network access on a per-test basis

https://flutter-review.googlesource.com/c/recipes/+/61660 will add back the --enable-network flag that gives Android virutal devices access to the network when they run tests in CI. This is needed to run tests like this one in video player that access resources hosted by Flutter on the web.
We should consider enabling network access on a per-test basis instead of globally allowing it.

cc @reidbaker as there may be missing context


request help: add ingress but always status Initializing

Issue description
set annotation:   kubernetes.io/ingress.class: apisix
in apisix dashboard I can see the auto-create route and upstream, but visiting the ingress domain can not success
Environment

apache/apisix-ingress-controller:1.4.1
installed by apisix helm  v0.11.0

you need to provide more information


Updated readme with instructions for running the project locally.

(Can come in handy for developers)

Hi Vasvi, thank you for your effort! Can you change the bulleted points into numbers, since they are sequential lists. Thank you.

Thanks for adding screenshots in the description, it's good to add individual screenshots when you are modifying some part of the documentation, but if you are writing the documentation from scratch or modifying > 75% of the documentation I will prefer one single full-page screenshot.
Another thing I feel is, we probably don't need too many images in the readme. I feel that images associated with git commit, and push are redundant, they probably won't help the reader much. What do you suggest @proudofsimin ? I will go with her views, as she is the one spearheading documentation style and structure : )

Hi Vasvi, thank you for your effort! Can you change the bulleted points into numbers, since they are sequential lists. Thank you.

@proudofsimin  Done

Week 1

[x]  Get familiar with the project
[x]  Finalized and submitted the team project proposal
[x]  Removed the About bot section and added Deploy with Heroku & Deploy with Docker in How-to Guide
[x]  Add a README file to GitHub to help future contributors understand how to contribute to the How-to-guide page

Thank you @huan for your feedback,
For clear understanding, We do have both the part for our how-to guide section

For the index file, we do have the overview.mdx file that can be viewed on the website where we will have the short link to all the sections under how-to-guide.
For the readme.md that can be viewed from GitHub, we were planned to add how to contribute and run it locally to this file.

and we will surely be taking care of the format and the files that are to be kept under different sections.

I request @huan, @Rohitesh-Kumar-Jain & @proudofsimin to please have a look at the changes. and give us the feedback for the same :)

@proudofsimin  @Rohitesh-Kumar-Jain all changes have been made. Kindly review the pull request and merge it.

this PR is the root cause of all the evil 🤦🏼
I realized now that this PR is being pushed directly from the master branch of vavsi-sood. (This doesn't cause a problem if you are working on a solo project).
This is the PR from all the refactoring should start : )
Surprisingly I ignored it the first time I reviewed this, and @proudofsimin and @nibble0101 also approved this 😅
I am not a git expert but that's what I believe is happening here.
So in short you need to close all the 4 PRs you have raised in the GSoD so far.
You don't need to close them yourself actually, the below manoeuvre will automatically close PRs and reset everything.
fix your current master branch
First of all, check out to your master branch, and then checkout to a new PR branch based on that.
git switch master
git switch -c new-branch

Then push the new branch to your fork and create a new PR based on that branch (the PR will be identical to this one with the exception of the branch). When you've done that, we can reset your master branch.
git switch master
git fetch upstream master # fetch upstream/master without merging into local master
git reset --hard upstream/master # reset local master to upstream/master's state
git push --force origin master # force-update your fork's master to reflect upstream

I hope I am doing right @huan and not being harsh on the How-to-guides team ?

@abhishek-iiit start from this PR, first make sure that your master branch is even with the upstream master.
Remember this rule: Your local master should be never ahead of upstream your other branches can be ahead of upstream master.

We will surely make the necesaary changes. And submit the work again in the next 2-3 days.


Clicking a file in the directory list doesn't do anything

Clicking on small_input.xlsx in the right hand column doesn't do anything.
Technical
It appears that the file is a link to a non-existent page.
Here are 3 possible fixes:

Create a new page for the details. The downside is the state of the tree will be lost when the user hits the back button.
Create a popup when the user clicks on the file showing the file details.
Update the interface so that clicking on the file travels up the component tree and sets that file as active. It's not clear that there would be an easy way to navigate back to the directory listing without the user clicking in the left hand panel directory tree.

Went with option 2. There was already existing support for a modal dialog.


Automatic1111

Hello,
How to install it on Automatic1111 ?
Thank you

I am A1111 ControlNet + AnimateDiff dev. I will probably do this, but understand that implementing this repo into ControlNet + AnimateDiff extension could be VERY challenging because I need to refactor the whole reference only implementation inside ControlNet extension and I doute if it worth my time. If animate anyone comes out before that happen, I may not support this repo.

also this paper just dropped - https://github.com/vvictoryuki/AnimateZero/blob/main/AnimateZero.pdf

also this paper just dropped - https://github.com/vvictoryuki/AnimateZero/blob/main/AnimateZero.pdf

looks like another cherry picked paper

I know this paper, but I don't like the samples. I also don't like official samples in this repo. I like samples by animate anyone.

animate anyone

I feel animate anyone will be also like this repo but we will see if they release

Almost all plug-in based video generators are cherry picked models including those close-source ones. I'm not sure about SVD though. If animate anyone is actually good at making anime girls dance, I would be excited to have it in A1111. This repo cannot do any anime.

I am A1111 ControlNet + AnimateDiff dev. I will probably do this, but understand that implementing this repo into ControlNet + AnimateDiff extension could be VERY challenging because I need to refactor the whole reference only implementation inside ControlNet extension and I doute if it worth my time. If animate anyone comes out before that happen, I may not support this repo.

Almost all plug-in based video generators are cherry picked models including those close-source ones. I'm not sure about SVD though. If animate anyone is actually good at making anime girls dance, I would be excited to have it in A1111. This repo cannot do any anime.

Alternatively, without altering the original mechanism of animatediff, would it be better to just use densepose?


Provide helper text for Creation/Retention Period units.

Rancher server version - v2.1.2-rc8
It would be helpful to have sone helper text for Creation/Retention Period fields about the allowed units that can be set.

Resolved in rancher/rancher:v2.1.2-rc9

Tested with v2.1.2-rc9
@westlywright We have the following helper text for Snapshot Creation Period - "acceptable units: s, m, h, d, w, m, y" which is incorrect .only h,m,s is supported ( format like - 2h10m3)
Reopening this issue to fix the text.

available in master and 2.1.13

rancher/rancher:v2.1.2-rc10 will have UI 2.1.13. It is currently being built

@sangeethah - Is this what you wanted this text to say?  If so can you close.

With v2.1.2-rc10 , we see the following helper text acceptable duration units: h, m, s.


Fix - hardlink issue in integrate Hero

Brief description
Disk must be NTFS format or it will throw "[WinError 1", which matches to EINVAL. Still raise different errors.
Description
Occured on disk formatted by exFAT.
Testing notes:

publish Hero version

We should maybe normalize destination path (as first step) to fix possible issues with double slashes.

Regarding those doubled slashes, small note it seems it doesnt caused any issues in the end. At least from the maya host user perspective....


App.tsx rerenders each time useQueryStates's setParams is called

Context
What's your version of nuqs?
"nuqs": "^2.2.3",

What framework are you using?

✅ Next.js (pages router)

Which version of your framework are you using?
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.6.0: Thu Sep 12 23:36:55 PDT 2024; root:xnu-10<IP_ADDRESS>1.1~1/RELEASE_ARM64_T8112
  Available memory (MB): 8192
  Available CPU cores: 8
Binaries:
  Node: 20.12.2
  npm: 10.5.0
  Yarn: 1.22.22
  pnpm: 9.12.2
Relevant Packages:
  next: 14.2.16 // An outdated version detected (latest is 15.1.0), upgrade is highly recommended!
  eslint-config-next: 15.0.2
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.5.4
Next.js Config:
  output: N/A
 ⚠ An outdated version detected (latest is 15.1.0), upgrade is highly recommended!
   Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue

Description
I'm using nuqs to store applied filters in the url as query params. As I'm typing the search param in the url is changing but I've realised the App.tsx file itself is rerendering each time. I'm not sure if its expected
Reproduction
I'm using the basic usage example
My app.tsx
import<EMAIL_ADDRESS>import type { AppProps } from "next/app";
import { NuqsAdapter } from 'nuqs/adapters/next/pages'

export default function App({ Component, pageProps }: AppProps) {
  console.log('hello app.tsx')
  return <NuqsAdapter><Component {...pageProps} /></NuqsAdapter>;
}

export function Demo() {
  const [name, setName] = useQueryState('name')
  return (
    <>
      <input value={name || ''} onChange={e => setName(e.target.value)} />
      <button onClick={() => setName(null)}>Clear</button>

Hello, {name || 'anonymous visitor'}!

    </>
  )
}

Each time url updates I see a new hello app.tsx in the console
-->
Is this expected?

Unfortunately, this is a behaviour from Next.js itself, you can see it without using nuqs, by calling the Next.js router directly:
https://github.com/franky47/nuqs-repro-803


Restructure of metadata model around DigitalIdentifier

Based on first curation feedback and revising the usage of DigitalIdentifier schemas within the metadata model, it was proposed to restructure the metadata model around DigitalIdentifier schemas. Presented proposal:

change DigitalIdentifier into a concept schema
introduce dedicated schemas for different digital identifier types that extend the DigitalIdentifier schema;

first types:

DOI
ORCID
GRID
ISBN
ROR
RRID

"identifier" property with regex pattern where applicable

correct in schemas that reference digital identifier the corresponding linkedTypes to the most fitting digital identifier type(s)

@apdavison & @bweyers hope this is fitting also your needs. Please let me know if additional Digital Identifier Types are needed for models and/or software.

@olinux I think PR #192 needs to go in first for avoiding conflicts.

@lzehl in future, we might start using https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html

@apdavison thanks! I'll try to add it. Do you know by any chance the RegEx pattern already for the SWHIDs?

@apdavison found it :smile: and add the schema already.

@olinux this one should be ready to go now. note: I have to make another PR on SANDS to fit these changes.

Note: Conflicts come from the merge of PR #192 (where it is still "digitalIdentifier"). @lzehl, you will have to update this here (sorry :P).

@UlrikeS91 since I anyway need to solve the conflicts, do you think we should make the digital Identifier RP specific? A Dataset/DatasetVersion will not use the SWHID...

Note: Conflicts come from the merge of PR #192 (where it is still "digitalIdentifier"). @lzehl, you will have to update this here (sorry :P).

That happens :wink: don't worry

@UlrikeS91 since I anyway need to solve the conflicts, do you think we should make the digital Identifier RP specific? A Dataset/DatasetVersion will not use the SWHID...

You could, but if this is the only one where it's not really applicable, I don't think it's actually necessary. Especially, if it's truely not possible to use SWHID for datasets (but I don't know enough about it to know if this is the case).

Also: @lzehl remember to do the same updates in the SANDS schemas. For your convenience:
brainAtlasVersion, digitalIdentifier: https://github.com/HumanBrainProject/openMINDS_SANDS/blob/v1/schemas/brainAtlasVersion.schema.tpl.json
coordinateSpace, digitalIdentifier:
https://github.com/HumanBrainProject/openMINDS_SANDS/blob/v1/schemas/coordinateSpace.schema.tpl.json

@UlrikeS91 thanks for the reminder for SANDS (I had a note somewhere about this on my desk); From what I understood the SWHID are definitely not for datasets, but only for models and software @apdavison is this correct?

@UlrikeS91 should be ready to merge


Add GUI-generated JSON reform file to static output page

Implementing #859. I kept the layout as it was, though there could be a case for placing the generated reform file below the result tables rather than above them.

Hmmm it looks like there is an issue where the current Tax-Calculator version is being compared to version '0.13.0':

This is unrelated to the changes in this PR and in PR #902. I'm going to look into this.

@lucassz this looks good. Can you format the JSON output with tabs, new lines, etc? json.dumps would work.

@hdoupe Done. Another idea would be to label the reform/assumption files separately.

Nice, thanks. That looks much better.

Another idea would be to label the reform/assumption files separately.

Good idea. "Reform" and "Assumptions" should work.

@lucassz Can you post a screen shot of how things would look once you add the labels?

Updated, and here are the screenshots.

@lucassz The screenshot looks good. @Abraham-Leventhal, @andersonfrailey Do you have any thoughts on this layout?

For UI reasons, maybe it would be more elegant to have a collapsible box to contain the code so it's not immediately visible to nontechnical users.

@hdoupe
I am in agreement with @lucassz on this point. I think a collapsible box or link that opens the code in a new window would be an improvement.

@lucassz There are a couple stages of backwards compatibility that we could try to cover:

data before 1.4.0
data between 1.4.0 and 1.6.1

Starting in 1.4.0 the raw input data is stored in the model attribute raw_input_fields and the input data after it was parsed into the Python types (like int, float, bool) is stored in the model attribute input_fields. The JSON reform can be created from the input_fields attribute via param_formatters.to_json_reform(start_year, input_fields). So, you could do something like:
elif model.input_fields is not None:
    reform_file_contents = param_formatters.to_json_reform(start_year, model.input_fields)
    assump_file_contents = '' # assumptions were not specified because this is from the static GUI page

Don't worry about the data before 1.4.0. Backwards compatibility for the outputs was broken in 1.5.0.
Does that make sense?

@hdoupe Yes, thank you, that does make sense! I implemented your suggestion pretty much verbatim and it works well.

Nice, this is looking sharp. One more thing: can you apply this to the behavioral outputs page? The dynamic behavioral sim uses the same taxbrain/results.html page. You just have to update dyanamic.views.behavior_results.
You can find the TaxSaveInputs model class from the static run at the micro_sim attribute on the DynamicBehaviorSaveInputs model class.

@hdoupe Should that display the (few) additional parameters for the dynamic configuration, or just the ones for the initial microsimulation?

@lucassz That should show the parameters from the initial simulation and from the dynamic simulation.

The new commit implements that and also gets rid of a bunch of hardcoding of the OSPC hostname. Is there any particular reason it was in there?

Alright, looks good. Nope it was there when I started working on this project. Thanks for cleaning that up.
I think this is ready to be merged once you fix the merge conflicts.

@lucassz This looks good to me. Thanks for implementing this feature. This will be very helpful in allowing our users to see how their inputs are transformed and submitted to Tax-Calculator. This will help us find more bugs and make the file upload capabilities more accessible.
@Abraham-Leventhal @lucassz I like the idea of moving the JSON into something like a collapsible box. The outputs page is about to be re-designed. I encourage you to advocate for a feature like this once we begin the re-design and implementation discussions.


.Net Core 3.1 fails unless HttpClient SocketsHttpHandler is disabled

NEST/Elasticsearch.Net version:
7.11.1
Elasticsearch version:
7.10.0
When I upgrade from .net core 2 to 3.1, connection fails with error further down. This error goes away if I switch back to the old Httphandler by uncommenting (in my sample code)...
AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false);
If I upgrade to .net5.0, it doesn't work at all, even if I switch to System.Net.Http.WinHttpHandler as described in https://devblogs.microsoft.com/dotnet/net-5-new-networking-improvements/
Steps to reproduce:

using System;
using System.Threading.Tasks;
using Elasticsearch.Net;
using Nest;

namespace TestElastic
{
    class Program
    {
        static void Main(string[] args)
        {
            MainAsync(args).GetAwaiter().GetResult();
        }

        static async Task MainAsync(string[] args)
        {
            await Test();
        }

        public static async Task Test()
        {
            //AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false);

            var connectionPool = new SingleNodeConnectionPool(new Uri("https://<NODE>:9200"));

            var settings = new ConnectionSettings(connectionPool)
                .DefaultMappingFor<Person>(m => m.IndexName("ssl-person"))
                .BasicAuthentication("My username ", "pwd")
                .EnableDebugMode()
                .ServerCertificateValidationCallback(CertificateValidations.AllowAll);

            var client = new ElasticClient(settings);

            var person = new Person
            {
                Id = 1,
                FirstName = "Martijn",
                LastName = "Laarman"
            };

            var resp = await client.IndexDocumentAsync(person);

            Console.WriteLine(resp.DebugInformation);
        }

        public class Person
        {
            public int Id { get; set; }
            public string FirstName { get; set; }
            public string LastName { get; set; }
        }
    }
}

Provide DebugInformation (if relevant):
BadRequest: Node: https://node:9200/ Took: 00:00:00.5999414
OriginalException: System.Net.Http.HttpRequestException: An error occurred while sending the request.
---> System.IO.IOException: The response ended prematurely.
at System.Net.Http.HttpConnection.FillAsync()
at System.Net.Http.HttpConnection.ReadNextResponseHeaderLineAsync(Boolean foldedHeadersAllowed)
at System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
--- End of inner exception stack trace ---
at System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.SendWithNtConnectionAuthAsync(HttpConnection connection, HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.EstablishProxyTunnel(HttpRequestHeaders headers, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean allowHttp2, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.GetHttpConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpClient.FinishSendAsyncUnbuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
at Elasticsearch.Net.HttpConnection.RequestAsync[TResponse](RequestData requestData, CancellationToken cancellationToken)

@wandrar Based on your stack trace, the message "The response ended prematurely" indicates that the connection was closed by the server before HttpClient could read the expected bytes.
I've tested the repro code and I'm unable to reproduce the issue which leads me to suspect configuration in the app or on the server. I don't believe this is a client bug based on the information so far, but let's see if we can get you up and running.

Are you able to share your project (csproj) file used in your repro? I'd like to confirm how that's configured.
Which OS platform are you running this on?
It's worth verifying if you can make an SSL HTTP call to a public website, via HttpClient on your system?
Are you able to reach your server at the same URL using CURL or via the browser from the device where you are running this sample?

Hi, I'll assume it's my environment then. Save wasting your time I'll close for now and investigate network drops etc
Thanks for looking
Project file below.
OS = windows.
Httpclieint to public website (https) works.
Yes can reach server via website.
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
	  <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
	<PackageReference Include="NEST" Version="7.11.1" />
  </ItemGroup>
</Project>

That all looks standard, thanks @wandrar. It's possible a proxy is perhaps modifying the response in some way and SocketsHttpHandler is less forgiving. It might be worth running Fiddler in between to see what the responses look like. Additionally, it's worth running Elasticsearch locally using Docker to validate locally? That may help narrow down where the issue is.

Thanks Steve. Definitely proxy - have recreated with HttpClient outside of Elastic - I think possibly different behaviour auto-discovering proxy in core 3.1 vs 2.2 - just on my machine. Nothing to do with Elastic anyway and I can use the various settings to disable it so all good now thanks.

From: Steve Gordon<EMAIL_ADDRESS>Sent: 25 February 2021 06:15
To: elastic/elasticsearch-net<EMAIL_ADDRESS>Cc: wandrar<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [elastic/elasticsearch-net] .Net Core 3.1 fails unless HttpClient SocketsHttpHandler is disabled (#5339)
That all looks standard, thanks @wandrarhttps://github.com/wandrar. It's possible a proxy is perhaps modifying the response in some way and SocketsHttpHandler is less forgiving. It might be worth running Fiddler in between to see what the responses look like. Additionally, it's worth running Elasticsearch locally using Docker to validate locally? That may help narrow down where the issue is.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/elastic/elasticsearch-net/issues/5339#issuecomment-785644316, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AMK2UW4OYYM6O3DMEBXCKADTAXTGNANCNFSM4YB7N5OQ.


Unable to install via pip

The packages setup.py imports __version__ from django_distill/__init__.py which imports url from django.conf.urls.
This is problematic if Django is not installed, e.g. when using pip to install all the packages in a requirements.txt and pip decides to install django-distill before it is installing Django.
Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-build-pr2k64s3/django-distill/setup.py", line 6, in <module>
        from django_distill import __version__ as version
      File "/tmp/pip-build-pr2k64s3/django-distill/django_distill/__init__.py", line 4, in <module>
        from django_distill.distill import distill_url
      File "/tmp/pip-build-pr2k64s3/django-distill/django_distill/distill.py", line 4, in <module>
        from django.conf.urls import url
    ModuleNotFoundError: No module named 'django'

Ah, yes, well spotted thanks. That was rather silly. I'll push a fix for that shortly.

Pushed v0.7 which just removes the problem import, tested and pip install works without having Django installed first now. Cheers for finding it.

Thanks 👍


i3lock: color is invalid, it must be given in 3-byte hexadecimal format: rrggbb

Is there an existing issue for this?

[X] I have searched the existing issues

Operating system
Fedora 35
Installation method
Manual (please specify in the description!)
Betterlockscreen & Dependency-Versions
- Betterlockscreen: version: v4.0.3 (dunst: true, feh: true)
- i3lock-color: 2.12.c-1.fc34.x86_64
- ImageMagick: 2.12.c-1.fc34.x86_64
- dunst (if used): 1.8.0-1.fc35.x86_64
- feh (if used): 3.8-1.fc35.x86_64

Bug description
When trying to run betterlockscreen -l, this happened:
[th1nhhdk@fedora ~]$ betterlockscreen -l
[B] Betterlockscreen
[*] Running prelock...
[*] Locking screen...
i3lock: color is invalid, it must be given in 3-byte hexadecimal format: rrggbb

[*] Running postlock...

Steps to reproduce

In Fedora 35

dnf copr enable jstanek/ports
dnf install i3lock-color ImageMagick xdpyinfo xrandr feh

Get the [.tar.gz](https://github.com/betterlockscreen/betterlockscreen/archive/refs/tags/v4.0.3.tar.gz) from releases
tar -axvf v4.0.3.tar.gz

chmod u+x betterlockscreen
cp betterlockscreen /usr/local/bin/
cp<EMAIL_ADDRESS>/usr/lib/systemd/system/
systemctl enable betterlockscreen@th1nhhdk

Relevant log output
No response

That error looks like you're using the wrong i3lock. What is the output of command -v i3lock and i3lock -v?

[th1nhhdk@fedora ~]$ command -v i3lock
/usr/bin/i3lock
[th1nhhdk@fedora ~]$ i3lock -v
i3lock: version 2.12.c-non-git © 2010 Michael Stapelberg, © 2015 Cassandra Fox

That looks like it's probably stock i3lock, which will not work. You need to use i3lock-color >= 2.13.c.3.

@th1nhhdk Did this help you to fix your issue? Or can we help further?

yeah it works now, i forgot to close the issue 😅


Doesn't work in UK

Latest version of everything in HA, but card doesn't show any details

You need to tell it what entities to use. The card can't just guess that.

not exactly obvious how one actually goes about doing that,....

So use the editor and its pretty straightforward

Sorry, but none of you are very helpfull - Neither me, nor quiggles knows what "entities to use" or where to "use the editor".
My guess: Somewhere in the "Global Options" there would be a Service to use - Here I would put weather.home

Thanks oz9els - exactly this! What entities and where!

Sorry, but none of you are very helpfull - Neither me, nor quiggles knows what "entities to use" or where to "use the editor".
My guess: Somewhere in the "Global Options" there would be a Service to use - Here I would put weather.home

Yup - my point exactly.

The card configuration options (all behind the pencil icons) allow you to specify the entities. The documentation is a work in progress but honestly it's not rocket science and very intuitive if you work through the configuration screens (behind the pencil icons). See the readme.md on the code page for some limited examples. Many people have worked this out with less informayion...

"Many people have worked this out with less informayion..."

So you never provided any information about your config what weather integration you are using or anything else useful. There is no chance of us providing any assistance if the only things you say is  'Doesn't work in UK'.


Media button prio.

I would appreciate if the media buttons would not cancel the other programs, means if i open / focus itunes the media buttons does not work anymore. If you take spotify in comparision it works just like i would expect from this app. Would be a nice to have.

Unfortunately this is how Electron's global shortcuts work, I've been annoyed by this as well but the reality is that Cumulus doesn't control this behaviour.


[Scala] Allow customizing reference tracking

Is your feature request related to a problem? Please describe.
Disabling reference tracking gives much better performance, but it is a bit dangerous with some types.
What we do currently using Kryo is to make a custom ReferenceResolver where we implement our own public boolean useReferences (Class type) method. That way, we dynamically disable reference tracking on all our "known" safe types, but we still use it for other "unknown" types that may be circular (for example, Throwable can be circular because of cause).
Describe the solution you'd like
A way to customize reference tracking.
Additional context
For reference our current benchmarks:
[info] Benchmark                         Mode  Cnt   Score    Error  Units
[info] KryoBenchmarks.baseKryo          thrpt    5   2.567 ±  0.181  ops/s
[info] KryoBenchmarks.customKryo        thrpt    5  11.826 ±  0.348  ops/s
[info] KryoBenchmarks.noTrackingKryo    thrpt    5  13.822 ±  0.376  ops/s
[info] KryoBenchmarks.baseFury          thrpt    5   5.254 ±  0.414  ops/s
[info] KryoBenchmarks.noTrackingFury    thrpt    5  21.651 ± 10.453  ops/s

Fury without tracking is almost 2x faster than Kryo without tracking. So we have good hope that with customized tracking we would achieve a better performance than customized Kryo.

Another method is provide a method in Fury such as trackingRef(Class, bool), you can invoke it to control which classes will be serialized by ref.
Or Fury provides an annotation to let you mark your classes or fields with trackingRef, this is mentioned in #1148 too.


Fix typos and run gofmt

Noticed some easy fixes on https://goreportcard.com/report/github.com/helm/helm so I addressed most of them:

guranteed -> guaranteed
gofmt -w -s search/search_test.go
Add missing comments, or fix golint comment format "methodName ..."
Address golint unnecessary type validation

Thanks @jtescher !


Genes do not work with archotech organs.

Install "Insect breeder" and "Very much cum" genes.

Commit a vaginal intercourse with a female pawn.
Commit a vaginal intercourse with a female pawn with an implanted insect egg.

Expected result:
Cum output is increased. Insect egg is fertilised.
Actual result:
Cum output stays the same. Insect egg is not fertilised.
Analysis:
One can argue that genes should not affect artificial bodyparts. However, in this particular case I say that as "fast runner" genes still make a pawn move faster even with non-natural legs - "more cum" should still provide more cum even for a non-natural genitals. And genital implants do not alter genetic payloads of sperm (children still inherit just the genes of their parents - they do not become some "half-archotech"), therefore "Insect breeder" should still work with any fertile penis regardless of its nature as per description.

Good morning,
Thanks for your report!
This is somewhat expected behavior. The much-cum gene is applied when the gene is added, and changes the stat of the penis. So, any changes later to the penis (from any source) will remove the effect of the gene.
I hope that with the next bigger RJW update I have some time to make the archotech-penis more configurable in terms of cum-amount and other features.
For the implanted egg, I am a bit confused but I also think it happens upstream because the archotech-penis is considered "artificial". So we filter for it when we check for fertile penises. I will have a look into that.
I will definetely update documentation around that :)

Dynamically adding flags to the archotech-penis would also be nice =)


ValueError: Requested crop size (512, 512) is larger than the image size (384, 384)

Traceback (most recent call last):
File "./train_sup_change.py", line 48, in
blob = trainer.run(after_construct_launcher_callbacks=[register_evaluate_fn])
File "/home/yujianzhi/anaconda3/envs/CStar/lib/python3.7/site-packages/ever/api/trainer/th_amp_ddp_trainer.py", line 117, in run
test_data_loader=kw_dataloader['testdata_loader'])
File "/home/yujianzhi/anaconda3/envs/CStar/lib/python3.7/site-packages/ever/core/launcher.py", line 232, in train_by_config
signal_loss_dict = self.train_iters(train_data_loader, test_data_loader=test_data_loader, **config)
File "/home/yujianzhi/anaconda3/envs/CStar/lib/python3.7/site-packages/ever/core/launcher.py", line 174, in train_iters
is_master=self._master)
File "/home/yujianzhi/anaconda3/envs/CStar/lib/python3.7/site-packages/ever/core/iterator.py", line 30, in next
data = next(self._iterator)
File "/home/yujianzhi/anaconda3/envs/CStar/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 435, in next
data = self._next_data()
File "/home/yujianzhi/anaconda3/envs/CStar/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 475, in _next_data
data = self._dataset_fetcher.fetch(index)  # may raise StopIteration
File "/home/yujianzhi/anaconda3/envs/CStar/lib/python3.7/site-packages/torch/utils/data/_utils/fetch.py", line 44, in fetch
data = [self.dataset[idx] for idx in possibly_batched_index]
File "/home/yujianzhi/anaconda3/envs/CStar/lib/python3.7/site-packages/torch/utils/data/_utils/fetch.py", line 44, in
data = [self.dataset[idx] for idx in possibly_batched_index]
File "/home/yujianzhi/anaconda3/envs/CStar/lib/python3.7/site-packages/torch/utils/data/dataset.py", line 218, in getitem
return self.datasets[dataset_idx][sample_idx]
File "/home/yujianzhi/tem/ChangeStar-master/data/levir_cd/dataset.py", line 30, in getitem
blob = self.transforms(**dict(image=imgs, mask=gt))
File "/home/yujianzhi/anaconda3/envs/CStar/lib/python3.7/site-packages/albumentations/core/composition.py", line 191, in call
data = t(force_apply=force_apply, **data)
File "/home/yujianzhi/anaconda3/envs/CStar/lib/python3.7/site-packages/albumentations/core/transforms_interface.py", line 90, in call
return self.apply_with_params(params, **kwargs)
File "/home/yujianzhi/anaconda3/envs/CStar/lib/python3.7/site-packages/albumentations/core/transforms_interface.py", line 103, in apply_with_params
res[key] = target_function(arg, **dict(params, **target_dependencies))
File "/home/yujianzhi/anaconda3/envs/CStar/lib/python3.7/site-packages/albumentations/augmentations/crops/transforms.py", line 48, in apply
return F.random_crop(img, self.height, self.width, h_start, w_start)
File "/home/yujianzhi/anaconda3/envs/CStar/lib/python3.7/site-packages/albumentations/augmentations/crops/functional.py", line 28, in random_crop
crop_height=crop_height, crop_width=crop_width, height=height, width=width
ValueError: Requested crop size (512, 512) is larger than the image size (384, 384)
Traceback (most recent call last):
File "/home/yujianzhi/anaconda3/envs/CStar/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"main", mod_spec)
File "/home/yujianzhi/anaconda3/envs/CStar/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/home/yujianzhi/anaconda3/envs/CStar/lib/python3.7/site-packages/torch/distributed/launch.py", line 260, in
main()
File "/home/yujianzhi/anaconda3/envs/CStar/lib/python3.7/site-packages/torch/distributed/launch.py", line 256, in main
cmd=cmd)
subprocess.CalledProcessError: Command '['/home/yujianzhi/anaconda3/envs/CStar/bin/python', '-u', './train_sup_change.py', '--local_rank=0', '--config_path=levircd.r50_farseg_changestar_bisup', '--model_dir=./log/bisup-LEVIRCD/r50_farseg_changestar']' returned non-zero exit status 1.
it says：  ValueError: Requested crop size (512, 512) is larger than the image size (384, 384)
but my img is 512*512 exactly.

This error is caused by the image of size (384, 384).
It means that there is a 384x384 image in your dataset.
Maybe you can check it.

i have checked my dataset
it remains to show the size of imgs are 512*512

Becasue there are RandomDiscreteScale before the RandomCrop,it will change the picture to 384*384

i have checked my dataset it remains to show the size of imgs are 512*512

Becasue there are RandomDiscreteScale before the RandomCrop,it will change the picture to 384*384