Shadow with blending: transparent / fade

Using the sample code from #390, I see the following effect.
https://photos.app.goo.gl/VirWcNSyD8egTtw28
(sorry, uploading the screenshots didn't work)
As you can see, the shadow (and the surface dots, already reported, never fixed) is showing through the model. It has this custom material:
material {
    name: "Custom material",
    requires: [
        "position",
        "uv0"
    ],
    blending : "fade"
}

fragment {
    void material(inout MaterialInputs material) {
        prepareMaterial(material);

        material.baseColor.rgba = vec4(1.0, 1.0, 1.0, 1.0);
    }
}

Since alpha is set to 1.0, my expectation is, that the shadow (and of course the dots) should not be showing through.
Also, the shape of the shadow seems kinda strange to me. I'd expect it to stay flat on this flat surface.

The shadow is correct, it looks like this because your model intersects with the shadow plane. The problem here is not that the shadow is showing through the object but that the plane is drawn after your object.

Here we go again. Not starting a discussion this time. I just voiced my observations.

The problem here is not that the shadow is showing through the object but that the plane is drawn after your object

Are you saying there is something wrong with my code? I'm always kinda irritated with your answers.
I personally don't care what's wrong, I just want it fixed.

Michael, I'm sorry my answers irritated you, it was definitely not my intention. I don't know whether the issue is in your code or not at this point (I'd be surprised if it is), I am just adding information to help with the debugging and fixing of this issue by the Sceneform team.

I'm sorry my answers irritated you, it was definitely not my intention.

Yes, I know, of course. Good to know that you are adding information to the Sceneform team with your answers.

@romainguy
Can you ping the sceneform team in some way? More than 2 weeks now without a reaction.
There is definitely something basic wrong with the rendering, that should be worth to fix.


Look Into Appending /nexus and /jenkins to Service Hosting URLs

Checklist

[X] I have verified this is the correct repository for opening this issue.
[X] I have verified no other issues exist related to my request.

Is Your Feature Request Related To A Problem? Please describe.
Look into appending /nexus onto the nexus URL endpoint and adding a /jenkins to the jenkins URL.
Describe The Solution. Why is it needed?
Currently the Azure enviornment uses this approach. Adding /nexus to the context path in the the nexus default properties file locally. They also add a --prefix=/jenkins into the arguments section of the jenkins.xml file.
Considering doing the same change on QSG to bring them more in line with each other as enviornment solutions.
Additional Context
The difference between them would still be that QSG would run CCM, Jenkins, and Nexus over 3 different ports. Where as the C4BAE routes them all through the app gateway as 443 traffic. Effectively using the app gateway like a reverse proxy & load balancer.
Related Issues
No response

@JPRuskin @steviecoaster @imm0rtalsupp0rt Feel free to chime in on opinions to this proposed change.


Add default search path for missing #includes in D3D shader edit/replace

In RenderDoc 0.29 when you select 'edit and replace' of a shader (either HLSL or GLSL, doesn't matter) if that shader has a #include directive that line is ignored, leading to build errors. Those build errors can be fixed by manually processing the #include - that is, by cut-and-pasting the #included file's contents into the edit window. Given that RenderDoc creates tabs for every #included file, displaying their contents, can the editor window implement the those #include directives eliminating this need to cut-and-paste? Thanks!

Actually, it appears this should be a bug report, not a feature request - the problem is that there's a #included file missing from the tab list. The missing file contains a set of #defines necessary for compilation. This could result from the use of nested #include files - the missing #include is the first #include in the top-level #include - that is, the file structure looks like this:
shader.psh:
#include "StdPSInclude.psh"
main() { ... }
StdPSInclude.psh:
#include "StdMacros.psh"
#include "StdConstants.psh"
#include "StdFunctions.psh"
// and other #includes...
Tabs are created in the edit-and-replace window for shader.psh and all #includes except for StdPSInclude.psh and StdMacros.psh. Since StdPSInclude is just a container for other #includes, its omission is not fatal, but the omission of StdMacros.psh creates build errors.
I'll send you a capture demonstrating the problem via email if you want.

Yes in general #include files are supported but unfortunately this is a limitation that comes from the D3D compiler, there's not much I can do directly to fix it. I mention it in the docs here.
When the D3D compiler embeds source files in the PDB data, it only embeds files that contain code that was compiled. Presumably this is because it's only intended for looking up the source lines that correspond to assembly statements, not for recompiling the shader later.
Possibly I could add a fallback search path so that if an include file is completely missing, it searches some configurable folders on disk in order to try and locate it? It's not perfect but maybe better than nothing.

Looking at this again, I believe the new SPDB debug info format used by modern fxc includes all files that were used in compilation regardless of their contents, even if it doesn't contain any code or only has comments or macro definitions.
The SPDB format is fully supported now, so there should no longer be any cases where files are missing that need a search path to locate them.


Instructions to enable nib

I had a difficult time tracking down the instructions to use nib. Figured it would be good to explicitly include in the readme.

Thanks!


Refine open loop controller

Refine open loop controller with better end effector trajectories and gains for better open loop walking.

Is this still going to happen, or has it served its purpose? We can close the issue if we no longer need it.

Is this still going to happen, or has it served its purpose? We can close the issue if we no longer need it.

This should still happen, although I don't have a timetable for doing it

This should still happen, although I don't have a timetable for doing it

Okay we can leave open, I'm labeling as good first issue because presumably it will be done by whoever needs it working first.

Okay we can leave open, I'm labeling as good first issue because presumably it will be done by whoever needs it working first.

Not needed any more, can reopen if that changes.


docs: quickstart fixes

Documentation fixes related to https://github.com/zerotier/zerotier-systemd-manager/pull/12

I assume you want this merged after zerotier-systemd-manager's merge is complete?

Yes, indeed

I'm going to update this after we release 0.1.7, just fair warning, but am merging this now.


Timeout occurring before connecting string timeout settings

PyMongo connection string includes the following timeout settings:
serverSelectionTimeoutMS=49500
connectTimeoutMS=49500
socketTimeoutMS=49500
Repro steps:

Connect to a Mongo DB with the above timeout settings in the connection string
Execute an aggregate query that project 3 fields and then groups to get counts per group, with allowDiskUse: true

Action: cosmosDB.executeMongoCommand
Error type: string
Error Message: Timed out executing MongoDB command "db.mongoCollection.aggregate([{"$project":{"_id":0,"first_field":1,"second_field":1,"date_time":1}},{"$group":{"_id":{"first_field":"$first_field","second_field":"$second_field","date_time":"$date_time"},"ct":{"$sum":1}}}],{"allowDiskUse":true})"
Version: 0.10.2
OS: darwin
Product: Visual Studio Code
Product Version: 1.37.1
Language: en

Does this work if you run it directly in the Mongo shell?

With this kind of query, we send it directly to the Mongo shell.  I executed the following without problem:
db.test.insert([{
title: 'MongoDB Overview',
description: 'MongoDB is no sql database',
by_user: 'tutorials point',
url: 'http://www.tutorialspoint.com',
tags: ['mongodb', 'database', 'NoSQL'],
likes: 100
},
{
title: 'NoSQL Overview',
description: 'No sql database is very fast',
by_user: 'tutorials point',
url: 'http://www.tutorialspoint.com',
tags: ['mongodb', 'database', 'NoSQL'],
likes: 10
},
{
title: 'Neo4j Overview',
description: 'Neo4j is no sql database',
by_user: 'Neo4j',
url: 'http://www.neo4j.com',
tags: ['neo4j', 'database', 'NoSQL'],
likes: 750
}]);
db.test.aggregate(
[
{ $project: {title:1, by_user: 1, description:1, date_time: 1}},
{"$group": {
"_id":{"title":"$title","description":"$description","date_time":"$date_time"},"ct":{"$sum":1}}
}
],
{"allowDiskUse":true}
)

This has started working.  Closing for now, as seems like it may've been network-related.  If it re-occurs, I'll confirm via mongo shell and post both results.

Thanks for letting us know!


next bug occurs. Now every other players have default skin

after u inject it to the game, after you die u will still have selected skin on but now every other player in the game's skin changes to the default one

is it fixed yet?

@Shraim64 all hopes are in @hydy100 . The fact that a few hours after the LoL update, hydy also tried to update the skin changer as well is respect. We just have to wait.


add missing static keyworkd in Update 040_setup.rst

LGTM and thanks again.
Lmk if you have any questions about the library or setting it up.


feat(abci): move timeout_commit into FinalizeBlockResponse

as next_block_delay
ADR-115: https://github.com/cometbft/cometbft/pull/2966
Closes #2655

PR checklist

[ ] Tests written/updated
[x] Changelog entry added in .changelog (we use unclog to manage our changelog)
[x] Updated relevant documentation (docs/ or spec/) and code comments
[x] Title follows the Conventional Commits spec

@cason please review once you're back 🙏

What I maybe miss, from a documentation point of view, is to make it clear that is the commit_time that is considered to "start" the configured delay. Not when FinalizeBlock is called. Although the time difference should not be that relevant.

@cason thanks for triple-checking. Regarding your last comment? If you create a PR with the improved doc, I can take a look and approve

Where do we set the next_block_delay? Is it done in the application and returned to cometBFT?

Where do we set the next_block_delay? Is it done in the application and returned to cometBFT?

Remember, it's not in v1 nor v0.38. It's currently on main. From v1.1 it will be in FinalizeBlockResponse https://docs.cometbft.com/v1.0/spec/abci/abci++_methods#finalizeblock

Thanks @melekes for your quick reply. I am trying to cherry pick these changes as I want const block time. Btw is it safe to do so as I can see there is no consensus breaking change. My question is who set the next_block_delay in FinalizeBlockResponse?


Missing starting segments for icecast input source

I am using standalone.json config (bundled with code) to run streammachine (default test stream)
Then, an app captures pcm voice, encodes (mp3) and sends stream machine as icecast input source.
Server prints log incoming ice source info and initializes  rewindbuffer. Till now, everything is fine
When I request running HLS stream from browser as /test.m3u8 I have to wait for a while (prints "No data" when request) and can not get  first segments.
Sample M3U is:
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:2
#EXT-X-DISCONTINUITY-SEQUENCE:0
#EXT-X-INDEPENDENT-SEGMENTS
#EXTINF:10.08,
#EXT-X-PROGRAM-DATE-TIME:2015-10-21T18:42:41.132+00:00
/test/ts/2.mp3?session_id=3f067e38-0c07-4800-8ccb-7f5f80a4d55d
What could be reason for missing segments ?

This is actually part of the implementation of a feature, but I'd be glad to hear more about your use case and see if we can make the two work.
Basically we don't list the two segments in the very front of the buffer in the index, so that they don't fall out of the index and become unavailable at the same time. Imagine a client downloads an index right as a segment is being expired, leaving it listed in the index but not available for download.
The missing segments don't matter for our radio use case, where you have an infinite stream that you're always going to be truncating somewhere.
Are you actually hoping to use the HLS more as an event broadcast, where a client would start at the beginning and move forward rather than playing from the "live" position?

Thanks for quick prompt. As you said , it is not going to be a problem for an infinite stream.
I wanted to broadcast variable length (from seconds to hours) but complete live streams and clients would always play live position. I am not sure streammachine is the rigth middleware for dynamically create and delete such live streams on the fly. I also tested rest APIs and worked fine in basic test.

There's nothing inherently unsupportable about that use case, but you're right that streammachine might not be the best tool for it.
You would need to tweak the index logic you hit (not hard), and then basically turn off the code that handles capping the max length of the rewind buffer. And then our code is also more tuned for a small number of long-lived stable streams, so I haven't tested large numbers of dynamic streams.
I do eventually like the use case of supporting live events rather than just continuous broadcasts (we do a decent number of events as a station), but I couldn't say when or if that would be something I would get to work on.

I will work on that. Thanks for quick support again.

:+1: I'm going to close this issue, but feel free to comment here or email if you end up working on it and have questions.

I can now run short index file starting from 0 and indexer works fine. But first segment "0.mp3" always returns empty content (zero byte) while "1" and further segments don't. (Not a 'No data' case)
Any idea ?


Add arrow-up-down icon

There is already an arrow-left-right icon but not an arrow-up-down icon (this icon has just been turned around). You could use it as a reorder icon or as a mobile data icon.

Nice icon, I wasn't quite sure about the name; to me this should be arrow-down-up, but then again, I also think the horizontal version should be arrow-right-left, so I guess yours should be fine.
I've made a few suggestions to the formatting in line with JSON and SVG code styles.

Thank you @karsa-mistmere.
I think we could change the name later on if necessary, or we could add the other name as a tag.

Or maybe as an alias once we have support for those. :)
Can you please also add reorder and move as tags to arrow-left-right?


Did someone forget to push 4.4.0 to npm?

I see it in the releases: https://github.com/ReactTraining/react-router/releases/tag/v4.4.0
But I don't see it in npm: https://www.npmjs.com/package/react-router
4.4.0-beta.8 is the latest in npm

https://reacttraining.com/blog/react-router-v5/#why-the-major-version-bump


Can not fetch the correct page after login with cookies

Hi, thanks for the convenient library and detailed documentation,
I followed carefully with the Login part in troubleshooting, I could get the login success response, but I cannot fetch the page as login user, i.e. the fetched page still display the information without login.
What happened (Observed behaviour)
The code I use is
var Crawler = require("simplecrawler"),
    request = require("request");

var crawler = new Crawler("https://example.com/");

request.post("https://example.com/login", {
    form: {
        username: "iamauser",
        password: "supersecurepw"
    }
    jar: true,                //according to request library, jar is needed for getting the cookies
    encoding : null,     //for decoding chracters
}, function (error, response, body) {
    crawler.cookies.addFromHeaders(response.headers["set-cookie"]);
    console.log("cookies are", response.headers["set-cookie"])//showing later
    crawler.start();
});

crawler.on("fetchcomplete", function (queueItem, responseBuffer, response) {
    console.log("Fetched", queueItem.url);
});

Here is the cookies from the console:
[ 'kMpW_2132_saltkey=o2Jc63jR; expires=Sat, 24-Sep-2016 16:01:57 GMT; path=/; httponly',
  'kMpW_2132_lastvisit=1472137317; expires=Sat, 24-Sep-2016 16:01:57 GMT; path=/',
  'kMpW_2132_sid=jiyEIy; expires=Fri, 26-Aug-2016 16:01:57 GMT; path=/',
  'kMpW_2132_lastact=1472140917%09member.php%09logging; expires=Fri, 26-Aug-2016 16:01:57 GMT; path=/',
  'kMpW_2132_ulastactivity=865eVM8Jzjc4AQzmvzUoaSnRndbjY%2BU%2BKYneWnsr8m%2Bw0Sxaedzm; expires=Fri, 25-Aug-2017 16:01:57 GMT; path=/',
  'kMpW_2132_sid=jiyEIy; expires=Fri, 26-Aug-2016 16:01:57 GMT; path=/',
  'kMpW_2132_auth=750eMJtdXXHVqFrT85nxcfQ2MTuLzpTMrixIq4r0PcH4MwOmcarEs9qU3tHoVP7UDIpmEIDLNhuZiaWzTWz8BPemxME; path=/; httponly',
  'kMpW_2132_loginuser=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/',
  'kMpW_2132_activationauth=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/',
  'kMpW_2132_pmnum=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/',
  'kMpW_2132_lastcheckfeed=234353%7C1472140917; expires=Fri, 25-Aug-2017 16:01:57 GMT; path=/',
  'kMpW_2132_checkfollow=1; expires=Thu, 25-Aug-2016 16:02:27 GMT; path=/',
  'kMpW_2132_lip=<IP_ADDRESS>%2C1472140695; path=/',
  'kMpW_2132_myrepeat_rr=R0; expires=Fri, 26-Aug-2016 16:01:57 GMT; path=/' ]

I already spent one day in this problem, and I also check the source code of simplecrawler, please help!
What should happen (Expected behaviour)
Should be able to fetch the pages after login, as I state before.
Steps to reproduce the problem (include code examples)
Post URL is here (with a post-form) :
"http://dolc.de/member.php?mod=logging&action=login&loginsubmit=yes&infloat=yes&lssubmit=yes&inajax=1"

Hmm, it does look like the example doesn't work as expected. I'll have a look at this tomorrow!

Alright, so different sites handle login sessions a bit differently, but one potential pitfall is CSRF tokens.
I assume you're trying to crawl http://dolc.de? Since the site appears to be in Chinese (or at least that's what Chrome tells me), I can't tell for sure what the different inputs in the login form do, but after a bit of experimenting, I came up with a solution that helped me when I tried to crawl a different site that required a login just now.
Let me know if this fixed your problem!
var Crawler = require("simplecrawler"),
    cheerio = require("cheerio"),
    request = require("request");

var crawler = new Crawler("https://example.com/");

request("https://example.com/login", {
    // The jar option isn't necessary for simplecrawler integration, but it's
    // the easiest way to have request remember the session cookie between this
    // request and the next
    jar: true
}, function (error, response, body) {
    // Start by saving the cookies. We'll likely be assigned a session cookie
    // straight off the bat, and then the server will remember the fact that
    // this session is logged in as user "iamauser" after we've successfully
    // logged in
    crawler.cookies.addFromHeaders(response.headers["set-cookie"]);

    // We want to get the names and values of all relevant inputs on the page,
    // so that any CSRF tokens or similar things are included in the POST
    // request
    var $ = cheerio.load(body),
        formDefaults = {},
        // You should adapt this selector so that it only targets inputs from
        // the login form
        loginInputs = $("input");

    // We loop over the input elements and extract their names and values so
    // that we can include them in the login POST request
    loginInputs.each(function(i, input) {
        var inputName = $(input).attr("name"),
            inputValue = $(input).val();

        formDefaults[inputName] = inputValue;
    });

    // Time for the login request!
    request.post("https://example.com/login", {
        // We can't be sure that all of the input fields have a correct default
        // value. Maybe the user has to tick a checkbox or something similar in
        // order to log in. This is something you have to find this out manually
        // by logging in to the site in your browser and inspecting in the
        // network panel of your favorite dev tools what parameters are included
        // in the request.
        form: Object.assign(formDefaults, {
            username: "iamauser",
            password: "supersecretpw"
        }),
        // We want to include the saved cookies from the last request in this
        // one as well
        jar: true
    }, function (error, response, body) {
        // That should do it! We're now ready to start the crawler
        crawler.start();
    });
});

crawler.on("fetchcomplete", function (queueItem, responseBuffer, response) {
    console.log("Fetched", queueItem.url, responseBuffer.toString());
});

Thanks @fredrikekelund,  it's very detailed.
I understand the idea now, is it pretend to be a web user with cookies before post the login form?
And I tried the origin code and integrate to my code, it seems it did not work, I am not sure it is the problem of CSRF. I noticed that addFromHeaders  is only called once here after first request, is that right? Anyway I also tried use it in other steps, and it failed either.
I share you my repository with some login information, main entry is index.js maybe you can have a try with command node index 1, it's almost the plain code from you and the simplecrawler's example.

Yep, that's the idea! We need to emulate the way a browser behaves with cookies when logging in. I've updated the login example in the README to the code I submitted in my previous comment. Hopefully that will help people who bump into similar problems in the future.
I might have one extra look to make sure that the problems you're having isn't a result of some bug in simplecrawler, but I'll go ahead and close this issue after that. Let us know if you have any more problems related directly to simplecrawler!

I have checked the cookie jar in the repository, it seems update the cookies all correctly, but I am not sure if it should update the cookie according to the path source here.
Now I use request, which integrate a global cookie jar with tough cookie, it works for me now when I create my simple crawler with request.
I have not go into the detail of this repository, because I am not so familiar with cookies, but I will continuing watch this issue, and you may use my repository as a test.

We ended up figuring out that this was due to the fact that we made different requests both over HTTP and HTTPS to the site, right? Feel free to re-open this otherwise @hanwencheng


Rich terminal : Better text visualisation

The code rely heavily on terminal print for better understanding.
The following functions has been identified as important to do so :

[ ] pgm.get_available_fields
[ ] pgm.get_available_functions
[ ] pgm.get_available_models
[ ] pgm.get_available_solvers
[ ] pgm.hub (when loading)
[ ] hub.get_summary
[ ] hub.equations_description

We want them to be  more readable !
To do so, we use the library Rich Terminal https://github.com/Textualize/rich
It can be seen through this tutorial
https://www.youtube.com/watch?v=4zbehnz-8QU

Hello @DaluS! Thanks for opening this PR.

In the file doc/Lotofmodels.py:

Line 29:98: W605 invalid escape sequence '\d'
Line 29:101: E501 line too long (161 > 100 characters)
Line 29:105: W605 invalid escape sequence '\p'
Line 29:117: W605 invalid escape sequence '\p'
Line 29:132: W605 invalid escape sequence '\P'
Line 29:137: W605 invalid escape sequence '\l'
Line 29:146: W605 invalid escape sequence '\p'
Line 29:154: W605 invalid escape sequence '\p'
Line 100:101: E501 line too long (101 > 100 characters)

In the file doc/Tutorial.py:

Line 92:101: E501 line too long (107 > 100 characters)

In the file pygemmes/_articles/GoodwinKeen-CES/_article.py:

Line 131:101: E501 line too long (129 > 100 characters)

In the file pygemmes/_core.py:

Line 1007:21: E231 missing whitespace after ','

In the file pygemmes/_models/_Model_LogisticCons.py:

Line 48:1: E303 too many blank lines (3)

In the file pygemmes/_models/_def_fields.py:

Line 254:19: E241 multiple spaces after ':'
Line 261:19: E241 multiple spaces after ':'
Line 266:101: E501 line too long (106 > 100 characters)
Line 565:20: E231 missing whitespace after ':'
Line 565:22: E203 whitespace before ','
Line 568:12: E203 whitespace before ':'
Line 572:12: E203 whitespace before ':'
Line 665:21: E241 multiple spaces after ':'
Line 670:21: E241 multiple spaces after ':'

In the file pygemmes/_models/_def_functions.py:

Line 15:101: E501 line too long (108 > 100 characters)
Line 35:101: E501 line too long (111 > 100 characters)
Line 41:44: W605 invalid escape sequence '\l'
Line 51:101: E501 line too long (111 > 100 characters)
Line 82:101: E501 line too long (102 > 100 characters)
Line 101:9: E266 too many leading '#' for block comment
Line 130:101: E501 line too long (125 > 100 characters)
Line 134:101: E501 line too long (130 > 100 characters)
Line 172:101: E501 line too long (118 > 100 characters)
Line 182:101: E501 line too long (114 > 100 characters)
Line 183:101: E501 line too long (102 > 100 characters)
Line 187:101: E501 line too long (104 > 100 characters)
Line 192:101: E501 line too long (110 > 100 characters)
Line 196:101: E501 line too long (124 > 100 characters)
Line 227:101: E501 line too long (160 > 100 characters)
Line 236:101: E501 line too long (138 > 100 characters)
Line 329:31: E231 missing whitespace after ','
Line 329:37: E203 whitespace before ':'
Line 333:33: E231 missing whitespace after ','
Line 333:37: E203 whitespace before ':'
Line 335:13: E123 closing bracket does not match indentation of opening bracket's line
Line 337:36: E203 whitespace before ':'
Line 339:22: E231 missing whitespace after ':'
Line 340:13: E123 closing bracket does not match indentation of opening bracket's line
Line 358:101: E501 line too long (133 > 100 characters)
Line 362:101: E501 line too long (163 > 100 characters)
Line 366:101: E501 line too long (110 > 100 characters)
Line 370:101: E501 line too long (142 > 100 characters)
Line 374:101: E501 line too long (105 > 100 characters)

In the file pygemmes/_models/_model_CamilleFull.py:

Line 49:101: E501 line too long (115 > 100 characters)

In the file pygemmes/_models/_model_CamilleMine.py:

Line 39:101: E501 line too long (111 > 100 characters)

In the file pygemmes/_models/_model_Climate3Layers.py:

Line 5:101: E501 line too long (115 > 100 characters)
Line 45:101: E501 line too long (109 > 100 characters)

In the file pygemmes/_models/_model_G-Kaldoorn.py:

Line 7:6: W605 invalid escape sequence '\d'
Line 7:13: W605 invalid escape sequence '\p'
Line 7:25: W605 invalid escape sequence '\p'

In the file pygemmes/_models/_model_G-PiInPhi-Kaldoorn.py:

Line 9:7: W605 invalid escape sequence '\d'
Line 9:14: W605 invalid escape sequence '\p'
Line 9:26: W605 invalid escape sequence '\p'
Line 9:41: W605 invalid escape sequence '\P'
Line 9:46: W605 invalid escape sequence '\l'
Line 9:55: W605 invalid escape sequence '\p'
Line 9:63: W605 invalid escape sequence '\p'
Line 10:6: W605 invalid escape sequence '\d'
Line 10:13: W605 invalid escape sequence '\p'
Line 10:25: W605 invalid escape sequence '\p'

In the file pygemmes/_models/_model_G-PiInPhi.py:

Line 8:7: W605 invalid escape sequence '\d'
Line 8:14: W605 invalid escape sequence '\p'
Line 8:26: W605 invalid escape sequence '\p'
Line 8:41: W605 invalid escape sequence '\P'
Line 8:46: W605 invalid escape sequence '\l'
Line 8:55: W605 invalid escape sequence '\p'
Line 8:63: W605 invalid escape sequence '\p'

In the file pygemmes/_models/_model_G.py:

Line 7:101: E501 line too long (115 > 100 characters)

In the file pygemmes/_models/_model_G2.py:

Line 7:101: E501 line too long (115 > 100 characters)

In the file pygemmes/_models/_model_GEMMES.py:

Line 3:101: E501 line too long (127 > 100 characters)
Line 5:101: E501 line too long (1202 > 100 characters)
Line 76:101: E501 line too long (109 > 100 characters)
Line 86:101: E501 line too long (124 > 100 characters)
Line 90:101: E501 line too long (164 > 100 characters)
Line 158:15: E241 multiple spaces after ':'
Line 159:15: E241 multiple spaces after ':'
Line 160:17: E241 multiple spaces after ':'

In the file pygemmes/_models/_model_GK-Kaldoorn.py:

Line 7:6: W605 invalid escape sequence '\d'
Line 7:13: W605 invalid escape sequence '\p'
Line 7:25: W605 invalid escape sequence '\p'

In the file pygemmes/_models/_model_GK.py:

Line 3:101: E501 line too long (107 > 100 characters)

In the file pygemmes/_models/_model_GKTowardInventory.py:

Line 46:12: E203 whitespace before ':'

In the file pygemmes/_models/_model_GMinePaul.py:

Line 3:101: E501 line too long (108 > 100 characters)
Line 4:101: E501 line too long (133 > 100 characters)
Line 46:59: E241 multiple spaces after ':'

In the file pygemmes/_models/_model_MinePaul.py:

Line 61:21: E241 multiple spaces after ':'

In the file pygemmes/_models/_model_MonoGEM.py:

Line 22:46: E241 multiple spaces after ':'
Line 25:45: E241 multiple spaces after ':'
Line 31:101: E501 line too long (107 > 100 characters)
Line 36:52: E241 multiple spaces after ':'
Line 42:35: E241 multiple spaces after ':'
Line 45:50: E241 multiple spaces after ':'
Line 58:43: E241 multiple spaces after ':'
Line 61:37: E241 multiple spaces after ':'
Line 68:37: E241 multiple spaces after ':'
Line 87:47: E241 multiple spaces after ':'
Line 90:51: E241 multiple spaces after ':'
Line 95:101: E501 line too long (104 > 100 characters)

In the file pygemmes/_toolbox.py:

Line 31:40: E231 missing whitespace after ','
Line 361:101: E501 line too long (103 > 100 characters)

In the file pygemmes/_utilities/_Network.py:

Line 11:1: E302 expected 2 blank lines, found 1
Line 17:101: E501 line too long (102 > 100 characters)
Line 111:19: E231 missing whitespace after ':'
Line 111:19: E701 multiple statements on one line (colon)
Line 111:31: E225 missing whitespace around operator

In the file pygemmes/_utilities/_class_checks.py:

Line 1163:4: E114 indentation is not a multiple of four (comment)

Do see the Hitchhiker's guide to code style


Limit Download Rate per Pull Request

I use library/registry:2 of Docker Hub to deploy a private image registry. I want to limit download rate per pull request.
Can I do this by modifying the configuration file？
Thanks！

I use library/registry:2 of Docker Hub to deploy a private image registry. I want to limit download rate per IP.
Can I do this by modifying the configuration file？
Thanks！

@qi0523 Did you find your answer somewhere? I'm trying to do the opposite. I'd like to remove the limit but haven't found a way to do so


disable_occ=True?

Hi @edz-o et al.,
Thx for ur exellent work. May I ask it seems the occ model is never activated for all given configs, no? If I understood correctly, a Bernoulli is used to model occ? Any clarification would help! Thx in advance & best,
https://github.com/edz-o/3DNBF/blob/c0e2cdb991b64b852ea8c583d5bda47444d8ae04/mmhuman3d/models/losses/likelihood_loss.py#L93
As stated in the paper:

but note that we are using a robust likelihood during inference. (Sec. 3.2)

Thanks for your interest in our work! You are right the disable_occ should be set to False. I've updated the configs.


chore(deps): update k8s to v0.32.0

This PR contains the following updates:

Package
Type
Update
Change

k8s.io/apimachinery
require
minor
v0.31.4 -> v0.32.0

k8s.io/code-generator/cmd/deepcopy-gen

minor
v0.31.4 -> v0.32.0

Release Notes

kubernetes/apimachinery (k8s.io/apimachinery)
v0.32.0
Compare Source

kubernetes/code-generator (k8s.io/code-generator/cmd/deepcopy-gen)
v0.32.0
Compare Source

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

ℹ Artifact update notice
File name: go.mod
In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

3 additional dependencies were updated

Details:

Package
Change

k8s.io/utils
v0.0.0-20240711033017-18e509b52bc8 -> v0.0.0-20241104100929-3ea5e8cea738

sigs.k8s.io/json
v0.0.0-20221116044647-bc3834ca7abd -> v0.0.0-20241010143419-9aa6b5e7a4b3

sigs.k8s.io/structured-merge-diff/v4
v4.4.1 -> v4.4.2

Pull Request Test Coverage Report for Build<PHONE_NUMBER>6
Details

0 of 0   changed or added relevant lines in 0 files are covered.
4 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.2%) to 63.056%

Files with Coverage Reduction
New Missed Lines
%

pkg/config/env.go
4
79.65%

Totals

Change from base Build<PHONE_NUMBER>0:
-0.2%

Covered Lines:
1234

Relevant Lines:
1957

💛  - Coveralls


yield() crashes with two local variales

There seems something fishy with yield() and local variables. I have the simplest scene, with a button and AnimationPlayer. Animation starts when then button is pressed:
func _on_Button_pressed():
    var anim = get_node("AnimationPlayer")
    #var foo = 1

    anim.play("slide")
    print("started")
    yield(Object(anim), "finished")
    print("finished")

This works as expected, godot prints "started", plays the animation and then prints "finished". Now, when I uncomment var foo = 1, it crashes with sigsegv (sorry, no stack trace... all I see is "started" and no "finished").
To me it seems yield() does not like more than one local variable. But keeping local variables is the foundantion block of coroutines!
Tested on godot 1.0, win64.

I think a bug on it was fixed recently, are you using github version?
On Jan 31, 2015 12:13 PM, "jan-safranek"<EMAIL_ADDRESS>wrote:

There seems something fishy with yield() and local variables. I have the
simplest scene, with a button and AnimationPlayer. Animation starts when
then button is pressed:
func _on_Button_pressed():
var anim = get_node("AnimationPlayer")
#var foo = 1
anim.play("slide")
print("started")
yield(Object(anim), "finished")
print("finished")

This works as expected, godot prints "started", plays the animation and
then prints "finished". Now, when I uncomment var foo = 1, it crashes
with sigsegv (sorry, no stack trace... all I see is "started" and no
"finished").
To me it seems yield() does not like more than one local variable. But
keeping local variables is the foundantion block of coroutines!
Tested on godot 1.0, win64.
—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1324.

Nope, are there some nightly builds?

the best think you can do, is to build them on your own - it's damn easy and fast. But:
http://sourceforge.net/projects/godotengine/files/Builds/

I confirm, godot-win32-debug-vs2010-2015-01-24 from http://sourceforge.net/projects/godotengine/files/Builds/official/ does not crash.


v0.6.0

:robot: I have created a release beep boop
0.6.0 (2024-12-22)
Documentation

update diagram (#14) (60df376)
update README to include features section (b0b58ab)

Maintenance

update quality checks & deps (10c3d97)

Refactors

decouple initialization modules (d6f52da)

Tests

add LogBuffer (c6df67b)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v0.6.0
:sunflower:


Reduce the number of goroutines in create history stream

Merging but this will have to be revisited when implementing EBTs.


Revert "fix jdkDate parser"

Reverts adoptium/aqa-test-tools#406

It breaks the test output page and Grid view.


fix(LayoutMenu):overflow

Overview

PR Checklist

[ ] Related to designs:
[ ] Related to JIRA ticket: ABC-123
[ ] I have run this code to verify it works
[ ] This PR includes unit tests for the code change

🚀 Styleguide deploy preview ready!https://61f19aa02d8d550e2167e04d--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-kit@0.6.47-alpha.563f3a.0@codecademy/gamut-labs@29.0.2-alpha.563f3a.0<EMAIL_ADDRESS>
📬Published Alpha Packages:@codecademy/gamut-kit@0.6.51-alpha.4fccd4.0@codecademy/gamut-labs@29.2.2-alpha.4fccd4.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61f8028c0a0a9fe964e64676--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-kit@0.6.51-alpha.c9c07f.0@codecademy/gamut-labs@29.2.2-alpha.c9c07f.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61fac11b3a1a7c0ab3d690ca--gamut-preview.netlify.appDeploy Logs

🚀 Styleguide deploy preview ready!https://61fadc20ad7b060fea489aa5--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-kit@0.6.56-alpha.161ea6.0@codecademy/gamut-labs@29.2.7-alpha.161ea6.0<EMAIL_ADDRESS>
📬Published Alpha Packages:@codecademy/gamut-kit@0.6.56-alpha.0aeb74.0@codecademy/gamut-labs@29.2.7-alpha.0aeb74.0<EMAIL_ADDRESS>
📬Published Alpha Packages:@codecademy/gamut-kit@0.6.56-alpha.cdf171.0@codecademy/gamut-labs@29.2.7-alpha.cdf171.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61fc47ae0504dc1337dbb76a--gamut-preview.netlify.appDeploy Logs

🚀 Styleguide deploy preview ready!https://61fc47ba15ba081148b9ca9b--gamut-preview.netlify.appDeploy Logs

🚀 Styleguide deploy preview ready!https://61fc480b85ceea12d5f6b021--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-kit@0.6.56-alpha.d74bcf.0@codecademy/gamut-labs@29.2.7-alpha.d74bcf.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61fc4aea09a86812cb8cbc84--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-kit@0.6.56-alpha.1e64f0.0@codecademy/gamut-labs@29.2.7-alpha.1e64f0.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61fc532985ceea25b7f6ad2f--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-kit@0.6.56-alpha.eadb12.0@codecademy/gamut-labs@29.2.7-alpha.eadb12.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://620c36bf6b11df2af262ef70--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-kit@0.6.56-alpha.a05189.0@codecademy/gamut-labs@29.2.7-alpha.a05189.0<EMAIL_ADDRESS>
📬Published Alpha Packages:@codecademy/gamut-kit@0.6.56-alpha.a2ce05.0@codecademy/gamut-labs@29.2.7-alpha.a2ce05.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://620d4c5d01bad85f77797ea4--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-kit@0.6.63-alpha.df726d.0@codecademy/gamut-labs@29.3.4-alpha.df726d.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://620d52afc51380673ae4f93d--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-kit@0.6.64-alpha.f60ccd.0@codecademy/gamut-labs@29.3.5-alpha.f60ccd.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://621561c074da3e330d4fa909--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-kit@0.6.68-alpha.c563b1.0@codecademy/gamut-labs@29.3.9-alpha.c563b1.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://621e4278990d8e4944cef5ac--gamut-preview.netlify.appDeploy Logs

🚀 Styleguide deploy preview ready!https://6227c4ef164a8a0d0fc9d069--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-kit@0.6.73-alpha.510fc1.0@codecademy/gamut-labs@30.1.2-alpha.510fc1.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://6227ca62164a8a0ba9c9ea9a--gamut-preview.netlify.appDeploy Logs


Implementation plan  for security baseline SIG onboarding

Detailed implementation plan for onboarding security baseline SIG.

While reading I noted some spelling nits (see above), but really, this looks fine.
This is for simply onboarding / creating the infrastructure for the SIG (mainly its repo) itself, and that's fine. Its README will need to make it clear who the leaders are, and that it's part of the Best Practices WG. The WG should also point to this, once it's set up.
An alternative would be to house this within the best practices WG. The WG already has a setup to create pretty web pages, while if you want to do that in this SIG, there may be an extra step. However, because there are a number of other foundations involved, I think the approach (as proposed) is the better way anyway.
We may eventually want to create materials that will implement the baseline. That work might be part of this repo, or a separate repo. I would suggest putting it all in this repo if that makes sense, and if we discover it doesn't, we'll have a rationale for creating another repo.
Thanks for doing this!


surface-ui.org seems outdated

This is more a question than a bug report, I could not find where I could ask a question.
https://surface-ui.org/ seems outdated. I wonder if the plan is to drop the site in favor of hexdocs.pm or to get it updated sometimes.
For example, I could not find Dynamic components there.
Also I could not find the Sample UI Components in Surface v0.7.4 nor in V0.7.5
Anyway, I'm having great fun using Surface.
About Dynamic components, I found the feature by chance, I just tried
  <Component<EMAIL_ADDRESS>{=@displayed_data} {=@display_style} /> and it worked !
Cheers
Jean-yves :)

Thanks for reporting this.
Fixed in e8058cd5fa4d5c684743325f7e8a850437bd571f.

I wonder if the plan is to drop the site in favor of hexdocs.pm or to get it updated sometimes.

We'll simplify the site and improve the other documentation sources: https://github.com/surface-ui/surface/issues/643#issuecomment-1234202221


Compatibility changes for the pre-1.0.0 version of the client

Nothing else than stringify_unsupported seems to be needed here.

What do you mean by stringify_unsupported here @kshitij12345 ?


Add tests for fully qualified classes/interfaces/traits/functions names

As of now, we use \PhpParser\NodeVisitor\NameResolver to resolve the full name (namespace + name) of classes/interfaces/traits/functions names.
While moving from my old branch of php-parser to the latest one (1.3.0), the NameResolver seems to have changed for functions and thus the name of the outputted functions did not match the previous output.
Adding some tests should alert us if any dependencies ends up changing enough for the output to change/break.

Should be covered by 002f3e1a66359055e76f39beb64e39d404f1be11.


List.last returns the first element when the element is const

final List<Widget> children;

  Widget body(BuildContext context) {
    List<Widget> rows = [];
    for (var i in children) {
      rows.add(i);
      rows.add(const SizedBox(height: 8,));
    }
    rows.remove(rows.last);
    return Column(children: rows);
  }

Expected results: a gap should appear between widgets, and the last gap should be removed
Actual results: the first gap is removed , not the lat in the list
if i add the sizedbox whitout const the gap appears as expected, and the last gap is removed from list
log example:
MobilePage.body : [PageCard, PageCard, PageVerticalGap, PageCard, PageVerticalGap]

expected:
MobilePage.body : [PageCard, PageVerticalGap, PageCard, PageVerticalGap, PageCard]

<!-- Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 3.0.1, on Microsoft Windows [Version 10.0.19043.1826], locale hu-HU)
[√] Android toolchain - develop for Android devices (Android SDK version 32.0.0)
[√] Chrome - develop for the web
[√] Visual Studio - develop for Windows (Visual Studio Community 2022 17.0.0)
[√] Android Studio (version 2020.3)
[√] VS Code (version 1.62.0)
[√] VS Code, 32-bit edition (version 1.32.3)
[√] Connected device (4 available)
[√] HTTP Host Availability

• No issues found!
 -->

without const, expected result:

The behaviour is correct, check https://medium.com/flutter-community/the-flutter-const-keyword-demystified-c8d2a2609a80, all the const SizedBox are the same instance, so it removes the first one found.

Hi @visign3d
As @BrianCraig provided the article above explains the root cause of the issue, please try using list.removeLast() for your case.
I also try using the method and this is the result:

Closing the issue as solved. If you disagree, please write in the comments and I will reopen it.


Add installation instruction for MuJoCo

Types of changes

[ ] Docs change / refactoring / dependency upgrade
[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Motivation and Context / Related issue
Since MuJoCo is now open source, this test if it is installed and adds installation instructions.

How Has This Been Tested (if it applies)

Checklist

[x] The documentation is up-to-date with the changes I made.
[x] I have read the CONTRIBUTING document and completed the CLA (see CLA).
[x] All tests passed, and additional code has been covered with new tests.

Thanks, feel free to "Squash & Merge" ;)


Feature: Automatically find and download a NONG song for a level

The main idea
The idea is when a user opens a level, the mod will automatically look in the level for a NONG song to download if the level needs one.
This way levels with NONG songs will automatically prompt to the user that they need a NONG song and the user will be able to easily download it by pressing "download" on the prompt.
It is also possible to show multiple NONG songs to download and apply in case it finds more than one.
Where to search the NONG song
So to make that happen we somehow need to know which NONG song a particular level wants.
1. In the Level description
One idea I had is to make creators add a small note like that to the level description:
nong:yt:dQw4w9WgXcQ
the syntax is nong:<platform>:<arg 0>:<arg 1>:<arg ...>
Then jukebox will be able to read that when a user opens a level and know it needs to download dQw4w9WgXcQ from youtube.com. This will require yt-dlp in PATH.
Pros:

Level creators can easily add that(no need to reverify a level)
Not dependent on any external services like GD Song File Hub

Cons:

Only the level creator can do that for a level.
Doesn't look good when viewing the description
There's a character limit in description. So might not be possible to add too many NONG songs.

Maybe we can put it somewhere else instead of description? Maybe look for comments on the level made by the creator and look for that string there? This will solve con 2 and 3
2. Use GD Song File Hub
Pros:

Anyone can add a NONG song to a level. (You do this through their discord server)
Add how many NONG songs you want to a level

Cons:

Dependent on GD Song File Hub. If for any reason they close it down this mod will no longer work and their centralized database with all the NONG songs will likely be gone.

I can code it myself and PR it. I'm writing this issue to get opinions on the idea.
If this is out of scope for this mod I can make my own mod.

rejected


[WIP]intercom support

I present... the most complicated PR ever conceived.
To be merged after the other settings.

Bravo.


add enabled option - let wrap always return the data resolver

So basically, it would be great if we had an enabled option for node-cache-manager and incase it's set to false, the .wrap() function should return the resolver.

That sounds good.  Do you want to try implementing this?

+1 for this


[WIP]1.0.2

Description
Update session management.

[x] Setup redis
[x] Implement session management
[x] Remove jwt
[x] POST /signin
[x] POST /signout
[ ] GET /csrf
[x] Tuning db and sql
[x] Update docs
[x] Use a golem as a logger
[ ] Update a README

[memo]
Fix later
gobel-api        | [14:26:43][GOBEL-API] : [mysql] 2020/07/08 23:26:43 packets.go:122: closing bad idle connection: EOF


Reports don't work for Python 3.10 because of datetime

Hello all,
If I follow the tutorial on the readme, I run into the following issue:
Trying to use
qs.reports.metrics(mode='basic|full", ...)
qs.reports.basic(...)
qs.reports.full(...)
qs.reports.html(...)
doesn't work as there is apparently an issue with pandas.datetime and the regular python datetime:

TypeError: Invalid comparison between dtype=datetime64[ns, America/New_York] and datetime

My system runs on Ubuntu 22.04.1 LTS, uses python 3.10.6 and the following versions of the libraries:

pandas (1.4.2)
numpy (1.22.3)
scipy (1.8.0)
matplotlib (3.5.1)
seaborn (0.12.0)
tabulate (0.9.0)
yfinance (0.1.77)
plotly (5.10.0)

Maybe it would be best to use pd.datetime everywhere.
Kind regards!
PS: Also stock = qs.utils.download_returns('FB') should be replaced with a different stock, as FB changed its name and cannot be found in this way anymore.

Hello. I think this problem is related to the time zone. So I solved it in the following way.
stock = qs.utils.download_returns("AAPL")
stock.index = stock.index.tz_convert(None)
qs.reports.metrics(stock, mode="basic")
thx.

I am having this issue also, particularly when trying to compare against a benchmark in html.

Hey,
I was able to compare against a benchmark by downloading the benchmark data and doing the same tz-naive trick described above.
stock = qs.utils.download_returns("META")
bench = qs.utils.download_returns("SPY")
stock.index = stock.index.tz_convert(None)
bench.index = bench.index.tz_convert(None)
qs.reports.html(stock, mode='full', benchmark=bench)
In case this helps.
Best,

Thanks for this response.
On top of this, do you know how to resolve this when making an index? I have tried;
portfolio.index = portfolio.index.tz_convert(None)
portfolio = qs.utils.make_index(tickers)
like above but it doesn't seem to work.
TIA.

I am not familiar with the function but are you trying to do something like this?
portfolio = qs.utils.make_index({"TSLA": 0.5, "META": 0.5})
portfolio.index = portfolio.index.tz_convert(None)
qs.reports.html(portfolio, benchmark=bench, mode="full")

Thanks for the help all - I was seeing the same issue too


Update hitting.py to fix unexpected keyword errors

Why
Running this code with 'gameLog', which is a valid stat input was giving an unexpected keyword summary exception:
    stats = ['gameLog']
    groups = ['hitting']
    params = {'season': 2024}
    all_game_stats = mlb.get_player_stats(664034, stats, groups, **params)

What
Changes were made to ignore unexpected keywords instead of throwing an error
Tests
Tested with original library code calls and now it is working

@sharmaakhil100 thank you for giving it a go at trying to resolve the issue but to fix the error by just ignoring it is not in the best interest of the repo. We would prefer we handle it so that as the MLB api grows and adapts so does our wrapper and not just ignoring and limiting access to new variables. Im going to close this and submit a new PR showing how we would like the library to handle things like this, I suggest giving that a look over and applying it next time. I would love to approve your work in the future!

@KCNilssen completely understand! Thank you for closing it and and going with this approach, helps me learn as a newer developer and get a working library :D


Unable to find settings.toml

I extracted .zip file from Releases and there's no settings.toml file. The extracted folder looks like this:

Where is settings.toml located?

Thanks for this issue report :)
See https://github.com/akiyosi/goneovim/wiki/Usage#configuration

You need to create path and file.


Cudnn of two different GPU cards

My computer has two different GPU cards. The GFX-1060 supports Cudnn and NVS 290 does not. I will only use the 1060 to run MXNET. Is there any problem, if I keep both cards and make the installation with Cudnn supported?

If nvidia supports that mxnet will

This issue is closed due to lack of activity in the last 90 days. Feel free to reopen if this is still an active issue. Thanks!


Feature Request: consider storing image references in profile as a relative path

This would allow people to share their streamdeck profiles without the recipient having to re-link all of the image assets. The path should be relative to the profile file.
Another option would be to have a collect and export function where all the assets were collected together and a portable version of the profile was generated and delivered to the user as a zip or similar bundle.

@jdahlblom I believe this is relevant to this request.
I was getting a weird crash after upgrading from version 4.015 to 4.0.18 when switching layers using a navigation button. When switching layers using the UI the following was written to the log.
22.04.2020 07:46:12  version : <IP_ADDRESS>50
20135444 Custom message = []
System.ArgumentException
Parameter is not valid.
   at System.Drawing.Bitmap..ctor(String filename)
   at NonVisuals.StreamDeck.FaceTypeImage.Show()
   at NonVisuals.StreamDeck.FaceTypeBase.set_IsVisible(Boolean value)
   at NonVisuals.StreamDeck.StreamDeckLayerHandler.SetActiveLayer(String layerName)
   at NonVisuals.StreamDeck.StreamDeckLayerHandler.set_ActiveLayer(String value)
   at DCSFlightpanels.PanelUserControls.StreamDeckUserControl.ComboBoxLayers_OnDropDownClosed(Object sender, EventArgs e)

After a bit of playing around I realised it was because the layer I was switching to had a Go Home button configured which referenced a png in the 4.0.15 folder that I had just deleted. The following change fixed my profile.
        "$values": [
          {
            "$type": "NonVisuals.StreamDeck.StreamDeckButton, NonVisuals",
            "StreamDeckButtonName": 1,
            "Face": {
              "$type": "NonVisuals.StreamDeck.FaceTypeImage, NonVisuals",
              "FaceType": 2,
-              "ImageFile": "D:\\DCS Tools\\DCSFlightpanels_x64_4.0.15_alpha\\\\StreamDeckGallery\\Symbols\\home_white.png",
+              "ImageFile": "D:\\DCS Tools\\DCSFlightpanels_x64_4.0.18_alpha\\\\StreamDeckGallery\\Symbols\\home_white.png",
              "StreamDeckButtonName": 1,
              "StreamDeckInstanceId": "\\\\?\\hid#vid_0fd9&pid_006c#6&27db50b8&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}",
              "OffsetX": 0,
              "OffsetY": 0
            },
            "ActionForPress": {
              "$type": "NonVisuals.StreamDeck.ActionTypeLayer, NonVisuals",

True, I will switch to relative path for next relase. Coming weekend.

I feel like there will need to be some kind of re-linking process or default png to fall back to if there is not an image file at the location in the profile too.

Will do, a default "file not found" image of some sort.

Check latest alpha.

Fixed. Can you close if OK?

For me it still saves a fully qualified path in 4.0.22. Are there any caveats e.g. the image needs to be in the same path tree as the file?
{
  "$type": "System.Collections.Generic.List`1[[NonVisuals.StreamDeck.StreamDeckLayer, NonVisuals]], mscorlib",
  "$values": [
    {
      "$type": "NonVisuals.StreamDeck.StreamDeckLayer, NonVisuals",
      "Name": "Home",
      "StreamDeckButtons": {
        "$type": "System.Collections.Generic.List`1[[NonVisuals.StreamDeck.StreamDeckButton, NonVisuals]], mscorlib",
        "$values": [
          {
            "$type": "NonVisuals.StreamDeck.StreamDeckButton, NonVisuals",
            "StreamDeckButtonName": 22,
            "Face": {
              "$type": "NonVisuals.StreamDeck.FaceTypeImage, NonVisuals",
              "FaceType": 2,
              "ConfigurationOK": true,
              "TextFont": "Consolas, 12pt",
              "FontColor": "Black",
              "BackgroundColor": "Black",
              "ImageFile": "C:\\Users\\cahil\\OneDrive\\Documents\\Git\\dcs\\f16\\ufc\\0.png",
              "StreamDeckButtonName": 22,
              "StreamDeckInstanceId": "\\\\?\\hid#vid_0fd9&pid_006c#6&27db50b8&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}",
              "OffsetX": 0,
              "OffsetY": 0
            },
            "ActionForPress": null,
            "ActionForRelease": null,
            "HasConfig": true,
            "ActionType": 0,
            "FaceType": 2
          }
        ]
      },
      "IsVisible": true,
      "StreamDeckInstanceId": "\\\\?\\hid#vid_0fd9&pid_006c#6&27db50b8&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}"
    }
  ]
}

ah I see. If it is a sub path of the application it is written out as relative.
If this is to help with sharing profiles it need to apply when relative to the saved profile .bindings file.
{
  "$type": "System.Collections.Generic.List`1[[NonVisuals.StreamDeck.StreamDeckLayer, NonVisuals]], mscorlib",
  "$values": [
    {
      "$type": "NonVisuals.StreamDeck.StreamDeckLayer, NonVisuals",
      "Name": "Home",
      "StreamDeckButtons": {
        "$type": "System.Collections.Generic.List`1[[NonVisuals.StreamDeck.StreamDeckButton, NonVisuals]], mscorlib",
        "$values": [
          {
            "$type": "NonVisuals.StreamDeck.StreamDeckButton, NonVisuals",
            "StreamDeckButtonName": 22,
            "Face": {
              "$type": "NonVisuals.StreamDeck.FaceTypeImage, NonVisuals",
              "FaceType": 2,
              "ConfigurationOK": true,
              "TextFont": "Consolas, 12pt",
              "FontColor": "Black",
              "BackgroundColor": "Black",
              "ImageFile": "C:\\Users\\cahil\\OneDrive\\Documents\\Git\\dcs\\f16\\ufc\\0.png",
              "StreamDeckButtonName": 22,
              "StreamDeckInstanceId": "\\\\?\\hid#vid_0fd9&pid_006c#6&27db50b8&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}",
              "OffsetX": 0,
              "OffsetY": 0
            },
            "ActionForPress": null,
            "ActionForRelease": null,
            "HasConfig": true,
            "ActionType": 0,
            "FaceType": 2
          },
          {
            "$type": "NonVisuals.StreamDeck.StreamDeckButton, NonVisuals",
            "StreamDeckButtonName": 21,
            "Face": {
              "$type": "NonVisuals.StreamDeck.FaceTypeImage, NonVisuals",
              "FaceType": 2,
              "ConfigurationOK": true,
              "TextFont": "Consolas, 12pt",
              "FontColor": "Black",
              "BackgroundColor": "Black",
              "ImageFile": "C:\\Users\\cahil\\Saved Games\\DCS.openbeta\\DCSFlightPanels\\testbouton.png",
              "StreamDeckButtonName": 21,
              "StreamDeckInstanceId": "\\\\?\\hid#vid_0fd9&pid_006c#6&27db50b8&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}",
              "OffsetX": 0,
              "OffsetY": 0
            },
            "ActionForPress": null,
            "ActionForRelease": null,
            "HasConfig": true,
            "ActionType": 0,
            "FaceType": 2
          },
          {
            "$type": "NonVisuals.StreamDeck.StreamDeckButton, NonVisuals",
            "StreamDeckButtonName": 23,
            "Face": {
              "$type": "NonVisuals.StreamDeck.FaceTypeImage, NonVisuals",
              "FaceType": 2,
              "ConfigurationOK": true,
              "TextFont": "Consolas, 12pt",
              "FontColor": "Black",
              "BackgroundColor": "Black",
              "ImageFile": ".\\testbouton.png",
              "StreamDeckButtonName": 23,
              "StreamDeckInstanceId": "\\\\?\\hid#vid_0fd9&pid_006c#6&27db50b8&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}",
              "OffsetX": 0,
              "OffsetY": 0
            },
            "ActionForPress": null,
            "ActionForRelease": null,
            "HasConfig": true,
            "ActionType": 0,
            "FaceType": 2
          }
        ]
      },
      "IsVisible": true,
      "StreamDeckInstanceId": "\\\\?\\hid#vid_0fd9&pid_006c#6&27db50b8&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}"
    }
  ]
}

the file not found part works perfectly though

Do you execute DCSFP from other drive than where the image files where? If so the absolute path will be given.

I suppose then when sharing you could tell people to only unzip in a folder next to your DCSFP install folder and then ..\\my_cool_profile\\image.png would work.
I think it's going to be super complicated to have it relative to the save file isn't it?

Slight regression in 4.0.52 where the "Home" and "Back" navigation images are saved in the profile as fully qualified paths again.
e.g.
"ImageFile": "D:\\DCSTools\\DCSFlightpanels_x64_4.0.52_alpha\\\\StreamDeckGallery\\Symbols\\home_white.png",

ok this is resolved again in 4.0.59


support the bitwidth calculation of decimal number scoped enumeration

Hi, I need to transfer some scoped enumeration, but I noticed that connectal currently only supports calculating the bitwidth of unscoped enumeration. I added some code to support the bitwidth calculation of decimal number scoped enumeration, which should be sufficient because bsv does not yet support scoped enumeration other than decimal numbers.
For example, the scoped enum type we use is:
typedef enum {
    IBV_QP_STATE               = 1,       // 1 << 0
    IBV_QP_CUR_STATE           = 2,       // 1 << 1
		···
    IBV_QP_RATE_LIMIT          = 33554432 // 1 << 25
} QpAttrMask deriving(Bits, Eq, FShow);

Modify the typeBitWidth function in cppgen.py:
# from
if item.get('type') == 'Enum':
        return int(math.ceil(math.log(len(item['elements']), 2)))

# to
if item.get('type') == 'Enum':
        enum_width = int(math.ceil(math.log(len(item['elements']), 2)))
        # determines that the element is a scoped enum
        if len(item['elements'][0]) == 2 and item['elements'][0][1] != None:
            # calculate the maximum bit width among all enum items
            enum_width = max([int(math.ceil(math.log(int(element[1]) + 1, 2))) for element in item['elements']])
        return enum_width

But I encountered a type conversion issue, which is a warning and treated as an error. I tried using static_cast<QpAttrMask> to convert the type, but the warning still remains. However, there is no warning when the symbol is = instead of |=.
connectal/bluesim/jni/CntrlRequest.c:70:46: warning: invalid conversion from 'int' to 'QpAttrMask' [-fpermissive]
   70 |         tempdata.host2Cntrl.reqQp.qpAttrMask |= (QpAttrMask)(((tmp>>23)&0x1fful));
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                              |
      |                                              int

Do you have any suggestions for this? If the issue is resolved, I would like to make a pull request. Thank you!

Please make a PR. Your change works for the case that the method has a single param which is an enum. The failure you are seeing is due to how the generated code reconstructs enum values that cross a word boundary.
Instead of using '|=' it should use '=' and '|':
``
tempdata.host2Cntrl.reqQp.qpAttrMask = (QpAttrMask)((int)tempdata.host2Cntrl.reqQp.qpAttrMask |  (((tmp>>23)&0x1fful)));

I have a fix for the second problem

Pushed a change to master so your PR should work now


Not add ChannelHandler to ChannelPipeline once the pipeline was destr…

…oyed.
Motivation:
ChannelPipeline will happily add a handler to a closed Channel's pipeline and will call handlerAdded(...) but will not call handlerRemoved(...).
Modifications:
Check if pipeline was destroyed and if so not add the handler at all but propergate an exception.
Result:
Fixes [#6768]

@rkapsi PTAL

@scottmitch I am a bit on a fence here as throwing an exception is a bit of a backward incompatible change. We could argue that this is a bug and so its ok but I am not sure. @trustin WDYT ?

LGTM
Maybe if you're worried about unexpected side effects then add a system property that will by default log ERROR/WARN and throw only if the flag is explicitly enabled. I'd be happy to play guinea pig.

@Scottmitch @rkapsi @trustin PTAL again

@normanmaurer - I think we should either:

Change behavior and throw. Note that the API permits for unchecked exceptions so it could be argued the API allows for this and our implementation just didn't take advantage.
Make sure if handlerAdded is called that handlerRemoved is also called.

I don't have a strong preference between the two approaches.

@Scottmitch yeah I just ended up throwing.

Cherry-picked into 4.1 (4aa800259674bab303edd9427802574fcb4a3131) and 4.0 (4cc98134da611562b7433aa4fb9937ab24d553fb)

@mosesn I would like to pick your brain on this as a consumer of netty. What do you think about this change ?

@normanmaurer I think this seems like a useful change.  It does seem potentially racy, but since you'll throw an exception if you race, then it's easy for implementors to handle the race, although they have to figure out that it's something that could happen first, which might not be easy to discover.  We might have to fix some code, but it doesn't look like it will be that painful.
My major concern is that it looks like it's possible that there is a valid reason for adding a new handler after a destroy has been triggered.  Maybe it makes more sense to prevent adding a new handler after the destroy has finished?

@mosesn thats actually a good point. We should most likely just ensure we can during destroy but not after its complete. Gimme a few minutes to do a followup and a testcase

@mosesn I just wonder if we may miss some cases if we allow to add handlers during destroy. Mainly because a user may add a handler infront or after the current handler so it may be possible that we not traverse the just added handler anymore while doing the destroy operation. Thoughts ?

@normanmaurer it's possible, but that's just a technical difficulty.  you could imagine adding a state machine where we set the state to be Destroying and if a handler gets added while it's in the Destroying state we add it to a data structure of things to double check were destroyed later.  Then after we finish destroying new entrants, then we can mark it Destroyed.

@mosesn yeah but this could also lead to have some kind of endless loop when the user add new handlers during removal all the time. Need to think a bit about it.
@mosesn just to clarify, you are not concerned about throwing exceptions like we do after this PR, correct ?

Yes, that's right.  I think it should be OK.

@mosesn we could also just call handlerRemoved directly after handlerAdded in this case but I think this would even be more weird . Agree ?

@normanmaurer agree.

@mosesn @rkapsi after thinking more and more I am tempted to just revert this fix for now and cut the release. I would prefer to give it a few more thoughts and I think its not super urgent to be fixed as it exists forever anyway. Agree ?

@normanmaurer I think you're right, that's the prudent thing to do.

@normanmaurer - yea totally fine. #6768 was the result of me trying to find what ended up being the APR pointer leak. I was basically looking into the possibility of how SslContext or rather SslEngines could leak. I haven't seen it actually happen on our end and consider it just a possibility.

@normanmaurer, I took a quick look, and it looks good to me. That said, I agree with your decision to not rush it into the release: it can wait.

done 4.1 (80aa5dcdcc870b9bd82cae4b0be2d7c9bc893491) and 4.0 (01ab204ae5a55fe627d248a6961cfd53f5ebc8df)

+1 for re-open the issue and fix after the release seeing as this issue has existing for a while


DatePicker value incorrect when TZ of the selected date is different from the initial date

If the initial date and the selected date are not in the same timezone (e.g. summer time vs standard time) the value of the DatePicker will be incorrect. DatePicker value is either the day before the date selected at 23:00, or, the correct day but with time set to 01:00.

Environment

Tech
Version

@material-ui/pickers
3.2.7

material-ui
4.5.1

React
16.10.2

Browser
N/A

Peer library
N/A but tested with Moment and DateFns

Steps to reproduce

Be in a locale with a different timezone for some period of the year, i.e. a summer time that is 1 hour later than standard. e.g. Australia - standard +10 daylight +11
Initialise a DatePicker with a date in the "summer" timezone.
Change the date to a date in the "standard" timezone

Expected behavior

Date selected to be provided to onChange
Date's time to be set to midnight

Actual behavior

Date provided is the day before the day selected
Date has time set to 23:00

Live example
codesandbox
Sorry, I've not had time to look and see if I can fix this myself. I will do that but I've spent all the time I can today making the repro sandbox and figuring out what was going on. I will look into it if no-one else does over the weekend. My guess would be that the picker change code is just setting the date part and leaving the time part that was set by initialising the picker to midnight UTC on the initial date. I would also guess that to fix it one could just set the date to midnight UTC on the selected date as well and that should account for whatever timezone that new date happens to be in. Thanks! :)

hi,  any update on this?
I noticed that the component is always returning the wrong date unless initialized with current date-time or with a date contructed with Date.UTC.
see this codesandbox
const [value, handleDateChange] = useState(new Date());
// ok current date and current time

const [value, handleDateChange] = useState(new Date(2019, 0, 1));
// value is 2018-12-31T23:00:00:000Z

const [value, handleDateChange] = useState(new Date(Date.UTC(2019,0,1)));
// value is correct 2019-01-01T00:00:000Z

Am i missing something very simple in the configuration of the component?

I just noticed that when trying a simple plain JS Date the behaviour is similar - but only when date is Jsonified...
const d = new Date(2019,0,1)  d.toString()   //  07:46:11.769 Tue Jan 01 2019 00:00:00 GMT+0100 (Central European Standard Time)
while
const d = new Date(2019,0,1)  d.toJSON() // 2018-12-31T23:00:00.000Z
did not notice before - and attributed the issue to the component because I did not notice that in the sample sandbox provided in the docs the date is toJson.
( I still have to find a solution to my problem because I cannot simply use Date.UTC  because the component is being used through a couple of other react libraries and i have no direct access to it - but I believe this is not an issue of this lib)

I, too, ran into this issue. I built a nonsense MuiDateUtilsProvider value to work around it.
To solve the underlying problem, DatePicker and TimePicker value fields must be passed as ISO8601-encoded String, instead of JavaScript Date. (This will require a major version bump.)
JavaScript Date objects are timestamps -- coordinates along Earth's temporal axis. The human concepts of "date" and "time" do not represent coordinates along Earth's temporal axis. JavaScript Date objects are not designed to encode the human concepts of "date" and "time".
To a human, a "date" is related to Earth's temporal axis, but it means something different depending on context (and geography). A person in England and a person in Canada can share a notion of "May 13, 2020" but they won't agree on the exact moments that it occurred. A Date object can mean two different "dates" to two different humans.
To a human, a "time" is actually an infinite set of points along the temporal axis. It also means something different depending on context (and geography ... and Daylight Savings time). A person in England and a person in Canada can share a notion of "7 a.m.", but they won't agree on when it occurred.
Unlike JavaScript Date objects, ISO8601 Strings were designed to encode the notions of "date" and "time". The values 2020-05-13 and 07:00 encode the exact concepts that a Canadian and a Brit can agree on. https://en.wikipedia.org/wiki/ISO_8601.
(The Date value type is correct in the case of DateTimePicker, because the human is picking a moment in time with it.)

It would depend on what you were using the date for. If you are building an international meeting planner, the date picker is picking a point in time that is the exact same point on the "temporal axis" as you put it, which should be converted between timezones for people when reading it. But if you are building a birthdate selector then you will be wanting the "notion of May 13" as someone's birthday is not considered to change with timezones.
You can't solve the problem by arbitrarily supporting one interpretation over the other, it would have to be an option or something, and it's just not something that the javascript date object is build to handle. (i.e. like you said, you'd probably be best doing it with something like ISO8601, leaving off the optional timezone part to get the "notion of 7am" version")

@kitfit-dave If you're building an international meeting planner, use DateTimePicker. @material-ui/pickers already provides it. DateTimePicker correctly chooses a JavaScript Date.
This bug (and my comment above) is about DatePicker. It incorrectly accepts and picks JavaScript Dates. It ought to be picking ISO8601 Strings.
When a user types <DatePicker ...>, we already know that they do not want a timestamp. If they wanted to select a timestamp, they would have used <DateTimePicker ...>.

Quite right. I’d forgotten that there were two separate components.

Do you guys have a reproduction on the correct and incorrect behavior? As far as I can tell, the logic is correct. It sounds like a duplicate of #1562, which is about better documenting the timezone behavior.

Yeah, I put a codesandbox up there: https://codesandbox.io/s/material-ui-pickers-usage-demo-hc189

I don't think this is (just) a documentation issue, the behaviour in that code sandbox just seems wrong. The time should never anything other than midnight for the DatePicker, right? And the wrong date value is returned (i.e. not the date the person clicked on at all)

The time should never anything other than midnight for the DatePicker, right

It depends, as far as I have follow the problem, the date picker should change the year, month and day of the provided date, keeping the same time and timezone. So you can very well have a non midnight value, depending on how you format the string, say in UTC or your current timezone.
In the case of when the date is retrieved from the textbox or the date is initially empty, I would assume it takes the browser time and timezone.
@dmtrKovalenko is this description accurate?

@oliviertassinari Yes, thank you it is the vest description :)

@oliviertassinari Thanks for weighing in!

The time should never anything other than midnight for the DatePicker, right

@kitfit-dave It depends, as far as I have follow the problem, the date picker should change the year, month and day of the provided date, keeping the same time and timezone. So you can very well have a non midnight value, depending on how you format the string, say in UTC or your current timezone.

I'm lost. Are you suggesting that a developer may want to let the user change the date of a timestamp using DatePicker? As in, there would be no way for the user to change the time, but <DatePicker> is intending to change the date? This seems bizarre, because the same date in two different time zones is two different dates. (If the developer wants to compose a timestamp selector using <DatePicker>, then the developer should want <DatePicker> to select an ISO8601 String.)
The problem is more fundamental: <DatePicker> picks a timestamp when it should pick a date. But most timestamps have two dates. One of the (many) user-visible problems that arises: <DatePicker value={value}> displays a different date depending on the user's timezone.

@adamhooper The incentive is to leave flexibility to the developers to set the time and timestand they need. The mention of the timestamp is interesting, it's one representation possible of the value of the date picker, it represents the time in the timezone of the user.

For a new section of the documentation around the timezone management, I think that it would be great to have, at least, these sections:

Explain the different concepts, what contains a date object, what's a timezone, etc.
How does the date picker behave? We have a first draft in my previous message. Maybe explain why this behavior.
Add a couple of practical use cases that might require special care (as would not behave correctly without a few more line of code).

This isn't about documentation. DatePicker is doing a conversion most users don't want, and it's hard for users to undo it.
All users of DatePicker are forced to:
A) get a timestamp when they expect a Date; or
B) support a single time zone; or
C) write convoluted workarounds (see https://github.com/mui-org/material-ui-pickers/issues/1526#issuecomment-628237301) for an example; or
D) experience bugs (such as this one).
And in my experience, most developers don't realize that the fundamental problem is, a JavaScript Date does not represent a date! The DatePicker API should help people do the right thing. Native <input type="date"> does.
It doesn't make sense to me that users must read a section about timezone management when they're picking a date. Most users don't want timezones in their dates. Why force them to read the docs for something they don't want?

I wholeheartedly agree with @adamhooper here, and if I recall correctly, it is pretty much why I chose the image above to summarise my surprise at finding a timezone all up in my date picker...
If you want to decide to maintain whatever time setting the user may have somehow initialised the date picker with then that is up to you, I think it’s hard to justify with a user story though, but also certainly the current behaviour when that time setting DOES change (input of midnight becomes 2300), and the case where the wrong date entirely (the day before) ends up as the value, would seem to need to be resolved as bugs anyway.

If you want to know how exactly I found this issue (ie why would I have initialised the date to some other timezone)  here is what I recall:
We are using the date picker to have the user enter their birthdate. We were getting reports of users being unable to set their birthdate. I narrowed it down to a few months of the year that did not work. IIRC we were currently in summer time, and the user’s birth date was in standard time. So when they on boarded we set the date picker to today, and they then selected their birthday in April (a different timezone) and hence the problem.

@dmtrKovalenko Actually, I start to wonder if we shouldn't change the tradeoff. For what I understand, you have explained the "why" behind the current tradeoff in

The multiple picker use case

What if I need to build a datetime picker? Google approach is to have 2 separate controls – it will be painful if datepicker will always reset local time.

The reset path

Because if we are changing time it is the behavior user cannot control. He can easily control annulation time manually (moreover we are requiring using date library, so the user will not need to do date.setHours(0).setMinutes(0).setSeconds(0)).

However, it seems that in its current form, the tradeoff leads to fairly frequent bugs? that are hard to identify: with a long feedback loop.

I don't think the "current tradeoffs" even work properly actually. For instance, in the multi-picker case, the user has set the time to say 10am, but then changes the date to a different TZ and the time will become 9am or 11 am. So that is contrary to the stated design goal of "not changing the time"
I think either "do not change the time" or "reset the time to midnight" would work for the original case in this ticket, it does not seem that important which one is chosen, just that whichever one is chosen is implemented correctly and the time either ends up the same or equal to midnight.
Resetting to midnight seems like it prevents some uses of the component. Leaving the time alone seems like it works for all cases, as the user can set the time to midnight themselves if that is what they want - I assume that is why it looks like the code is trying to do that, it's just failing in the "different timezone" case. The only scenario where "leave the time alone" seems to cause problems is where people are assuming that the picker does not deal with time, and get confused when the picker's time is set to the current time - that one can be improved by documentation.

Leaving the time alone seems like it works for all cases

That's impossible: some times don't exist on some dates in some timezones.
Choosing between "do not change the time" or "reset the time to midnight" guarantees that developers will see undefined behavior, because no developer would consider or expect either piece of logic. (Plus, almost everywhere -- even in England during the summer -- there are two sensible definitions of "midnight".)
I urge this project to mimic <input type="date">, for:
Ease of understanding: Everyone understands what <input type="date"> picks. A tiny, tiny fraction of @material-ui/pickers users understand what <DatePicker> picks. (I would argue that nobody really understands what <DatePicker> picks -- hence this bug, other bugs, a whole section of documentation about timezones, etc.)
Ease of composition: The <DatePicker> docs suggest using Moment.js or other libraries' "start-of-day" function to compose dates. With <input type="date"> dates (ISO8601 Strings), that's already done. So if a developers wants to generate a JavaScript Date using a value the <DatePicker> picked, that developer will have an easier time generating a Date from a String than from a Date! Consider:
// If `<DatePicker>` returns an ISO8601 String:
function buildFullDateInLocalTime(dateString, timeString) {
    const [hour, minute] = timeString.split(":").map(parseFloat)
    return moment(dateString).hours(hour).minutes(minute)
}

// If `<DatePicker>` returns a Date:
function buildFullDateInLocalTime(dateObject, timeString) {
    const [hour, minute] = timeString.split(":").map(parseFloat)
    return moment(dateObject).hours(hour).minutes(minute)
        .startOf("minute") // gotcha! Nobody expected to need this
}

(Also, for those of us who despise moment.js, the String still leads to pleasant code):
// If `<DatePicker>` returns an ISO8601 String:
function buildFullDateInLocalTime(dateString, timeString) {
    const [year, monthPlusOne, day] = dateString.split("-").map(parseFloat)
    const [hour, minute] = timeString.split(":").map(parseFloat)
    return new Date(year, monthPlusOne - 1, day, hour, minute)
}

// If `<DatePicker>` returns a Date:
function buildFullDateInLocalTime(dateObject, timeString) {
    const [hour, minute] = timeString.split(":").map(parseFloat)
    return new Date(dateObject.getFullYear(), dateObject.getMonth(), dateObject.getDate(), hour, minute)
}

Ease of testing: If <DatePicker> picks times-of-day, then callers should test what their user experiences are when the <DatePicker> returns a time-of-day. With <input type="date">, they don't need to.

You are quite right, about keeping the date, I hadn’t considered that fully. And the best thing to do would certainly be to use ISO strings (it’s how I’ve fixed our implementation to maintain the correct values). But I was trying to suggest something that was likely to be implemented that would solve most of the problems. I just don’t see anyone agreeing to change this control to having a different value type now, would be happy to be proved wrong though.
I’m not sure I see why going with returning a date set to start of day (which is what I meant with reset to midnight) for whatever date it picked would not work. I can’t think of that you mean by two sensible definitions of midnight. Are there two definitions of start of day? I mean, the function itself must return one value for any day, this lib would be saying “that is the value you get for the time”.  It would be expected, because the docs could literally say that. I am pretty sure midnight always exists (dst changes happen between 1am and 3am I think everywhere?) and only exist once (leap seconds are added just before at 23:60 I think).
The problem of most people not knowing what the picker returns stems from the fact that most people don’t understand what a JavaScript date really is, and is probably out of scope for this project.

The problem of most people not knowing what the picker returns stems from the fact that most people don’t understand what a JavaScript date really is, and is probably out of scope for this project.

(Sorry, coming back here when documenting my code, and I can't help but reply!)
We agree a JavaScript date is really a timestamp, not a date.
We agree that most users of DatePicker and TimePicker don't understand this.
We agree that teaching the nuances of JavaScript Date really is is outside the scope of this project.
But I disagree about what this means for this project. If this project doesn't mean to teach the nuances of JavaScript Date, it shouldn't accept and return JavaScript Dates in DatePicker and TimePicker. It should tell users, "Use ISO8601 Strings for DatePicker and TimePicker." Curious developers can learn about JavaScript Date (and why it's inappropriate) on their own time.
I've seen DatePicker in three codebases by three authors. In all these places, Date led to mad, buggy spaghetti code. These three developers didn't know they didn't want JavaScript Dates. They tried manipulating the dates, leading to buggy spaghetti code.
Surely the best practice is to mimic <input type="date"> or <input type="time">? Then developers would have a wealth more resources on the Web to learn at their own pace.

Hey, I'm on team ISO 100%. If I were writing this I would have done it that way (mostly because I've tried and failed to do it with Date many times over the years). But I also understand team "don't change the component interface" and could see why a large percentage of program managers would be hard to convince to make this change. That said, it IS pretty broken as is, but I think you and I know that, but others maybe are not quite convinced. Still, were there a poll for changing over to ISO strings it would have my +1 for sure (maybe it's not too late).

We are not using Date objects at all. We are using special date-ui library that is working as abstraction.
If you wish you could write your own date-io adapter that will work through the pure string and use it.

I understand the root of issue and will try to think how we can fix it in pickers.

@dmtrKovalenko What would be the downside for value and onChange only manipulating plain strings, using the same format at the native input?

to only accept/return plain strings

Nevermind, bad idea, react-day-picker, react-datepicker, react-dates.

@dmtrKovalenko Using a date-io library doesn't address the root problem. The date-io libraries are all designed to abstract JavaScript Dates.

Moment.js: "Parse, validate, manipulate, and display dates and times in JavaScript"
date-fns: "the most comprehensive, yet simple and consistent toolset for manipulating JavaScript dates"
Luxon: "powerful, modern, and friendly wrapper for Javascript dates and times" ("DateTime, Duration, and Interval types")
dayjs: "immutable date library alternative to Moment.js with the same modern API"

I feel like there's lots of confusing information or misinformation in this issue's discussion -- and in #1526. Many developers seem to think DatePicker should not ... uh ... modify the time-of-day. That's downright bizarre. DatePicker should not be aware of the time-of-day.

We are not talking about to use Date objects or not to use. It is a kind of standard in javascript and we cannot remove support of it. If you don't want to use date object you can use any library for free and lock timezone globally.
The nature of Date object is that it is always in user local timezone. If you understand that – you should not have any problem.
I am going to lock this discussion.

Lock away, but I think you have not understood this discussion at all if you think it’s not something to be resolved. Adam is right. “You should not have any problem” is untrue, have you taken the time to look at the repro I provided right at the start? Tell me again how that is the correct behaviour, or one that can be avoided by “understanding” something.
Saying that you only have to worry about time zones for “international” projects is incorrect and the root of the issue. Have a look at the repro. The picker fails to work completely.
If you don’t like the discussion, lock it. Seems a bit adversarial to me but I guess I can go and use another library right? I just like this one and was trying to help make it better.

No, I am saying that date-fns is a bad choice and you need to try Luxon or moment-timezone.

Ok I will try to make a fix with Luxon

Because date-fns is bad decision for international projects. (probably we can mention it in docs)

@dmtrKovalenko From what I understand, the issue we are talking about isn't related to internationalization but daylight saving. Let's take the initial codesandbox and set the starting day to 2020-03-2T00:00:00.000Z. I'm in France, I'm in the winter timezone. Now, let's select June 1st. It's in the summer timezone. Both moment and date-fns returns
2020-05-31T23:00:00.000Z as the ISO string. Because the daylight saving switches the timezone, the ISO day is one month and one day behind.
I think that, in the use case of the birthday, people decide to use the ISO format as most common but they don't realize that this timezone shift can occur, moving the day one day behind. This makes ISO the wrong abstraction. We don't ask people when they are born in the ISO format, we ask a day & time relative to a city of birth.
There is no issue of this nature with the string returned format of the native input as the time is stripped:
<input type="date" />

I've read through this and am maybe facing a similar issue. We have physical locations (testing sites for COVID-19). We have staff that need to configure appointments for these. The staff can be anywhere. They need to select a date.
For example, they want to select "June 6th". That June 6th is June 6th in a known time zone (the testing site's) but whatever "start of day June 6th" is in the user's local timezone might not be "June 6th" when converted to UTC or the testing site's timezone.
Basically, they want to pick a date.
I can't seem to get this to work. Setting disablePast causes (depending on the difference between the local timezone and the one passed in (the one of the testing site)) the date to be pre-filled as invalid.
I'm quite at a loss and would appreciate any advice

Yeah, sounds the same. The “quick fix” for us - which is probably wrong in some cases, but has worked so far - was to set to startofday then pick the date, then if the time was wrong, remove it and adjust the day returned. Your situation might be different also as we were handling date of birth selection.

I've read through this and am maybe facing a similar issue. We have physical locations (testing sites for COVID-19). We have staff that need to configure appointments for these. The staff can be anywhere. They need to select a date.
For example, they want to select "June 6th". That June 6th is June 6th in a known time zone (the testing site's) but whatever "start of day June 6th" is in the user's local timezone might not be "June 6th" when converted to UTC or the testing site's timezone.
Basically, they want to pick a date.

@tyre if they're setting up appointments, then don't they want to pick a datetime? Are you maybe trying to use <DatePicker> and then a separate time picker?
(It looks like a useful feature would be for <DateTimePicker> to support a timezone prop. If that would solve your problem, you should file a separate bug report for that.)
Anyway, the most urgent info for you is an absolute-rule datetime primer: always, always, always store datetimes (e.g., scheduled appointment times) in the UTC timezone. If your staff is in India and selects the time, "June 3, 2020, at 3:00 p.m.", then store the time as 9:30 a.m. -- 2020-06-03T09:30:00.000Z<PHONE_NUMBER>000 in milliseconds) in your database. Your web server should accept and serve all times as UTC (in JSON, use ISO8601 format). The parts of your system that touch end-users directly (e.g., JavaScript-powered web page) must know the timezone the user expects, and only those parts of your system should convert into whatever timezone is appropriate.
Rephrased, for clarity:

When passing a date over the wire, it must be in UTC.
When displaying a (always-UTC) date to a user, determine the correct timezone and then convert the date into that timezone. (Usually, the user's timezone is the one set in the operating system -- that's the one <DateTimePicker> assumes [and <DatePicker> assumes, in my opinion incorrectly], because JavaScript Date functions implicitly use the user's operating-system timezone. It sounds like in your case, you may want a different timezone.)

... anyway. You have indeed stumbled upon a problem that is straightforward to solve with <input type="date"> and hard to solve with <DatePicker>. You can contribute to this issue by describing exactly what you're trying to do and what you've tried so far.
In the meantime ... if you want to deal with more urgent matters than this bug, just use <input type="date"> and maybe <input type="time">. If you're trying to schedule appointments when the user is in a different timezone than the appointment, use a library to help convert. (Avoid date-fns-tz: it doesn't actually store "UTC-date-plus-timezone", so it has unfixable bugs.)
Here's an example using Luxon (untested):
import React from 'react'
import PropTypes from 'prop-types'
import DateTime from 'luxon/src/datetime.js'

const tz = 'Asia/Kolkata'
const isoTimeFormattingOptions = {
  suppressMilliseconds: true,
  suppressSeconds: true,
  includeOffset: false,
}

function iso8601DatetimeToDateAndTimeStrings(str) {
  // Luxon DateTime holds two pieces of information:
  // 1. UTC timestamp (as passed in `str`)
  // 2. Timezone (as passed in `tz`)
  const dt = DateTime.fromISO(str).setZone(tz);
  return {
    dateStr: dt.toISODate(),
    timeStr: dt.toISOTime(isoTimeFormattingOptions),
  }
}

function dateAndTimeValuesToIso8601Datetime(dateStr, timeStr) {
  // Assume the user gave these date and time strings in `tz` timezone
  const dt = DateTime.fromISO(`${dateStr}T${timeStr}`, { zone: tz });
  if (!dt.isValid) {
    return null // e.g., the time doesn't exist on that date
  }
  return dt.toUTC().toISO();
}

/**
 * Pick an ISO8601 time in India's timezone.
 *
 * The output time will always be in UTC -- that is, ending with "Z".
 */
export default function IndiaDateTimePicker({ iso8601Value, onChange }) {
  const { dateStr, timeStr } = iso8601DatetimeToDateAndTimeStrings(iso8601Value)
  const handleDateChange = (ev) => {
    if (ev.target.value) {
      const newValue = dateAndTimeValuesToIso8601Datetime(ev.target.value, timeStr)
      if (newValue !== null) {
        onChange(newValue)
      }
    }
  }
  const handleTimeChange = (ev) => {
    if (ev.target.value) {
      const newValue = dateAndTimeValuesToIso8601Datetime(dateStr, ev.target.value)
      if (newValue !== null) {
        onChange(newValue)
      }
    }
  }
  return (
    <>
      <input type="date" value={dateStr} onChange={handleDateChange} />
      <input type="time" value={timeStr} onChange={handleTimeChange} />
    </>
  )
}
IndiaDateTimePicker.propTypes = {
  /** ISO8601 String. Must be non-empty -- maybe use a default value? */
  iso8601Value: PropTypes.string.isRequired,
  onChange: PropTypes.func.isRequired, // func(iso8601String) => undefined
};

@adamhooper thank you!
we do want them to pick a date and a time, but DateTimePicker is not intuitive. They don't know what they're looking at (plurality of users > 50 years old, in government jobs that are well behind technologically.) So it makes sense to them to pick a day and then pick the range of times (we do that with a simple drop down since they can only happen on half-hour marks.)
All of our dates are served and stored in UTC. The issue is at the time of choosing these dates, we need to use javascript dates. We need the picker to display a range of dates that are those still valid (today -> future) in the testing site's timezone. So we need to display those, which is the issue I'm having here. Because disablePast doesn't seem to work when the user's local timezone differs from that of the testing site, even when the date passed in is helpfully converted to the start of the day in that timezone.
It does seem that timezones are not supported by this library and I will have to do something else instead.

The issue is at the time of choosing these dates, we need to use javascript dates. We need the picker to display a range of dates that are those still valid (today -> future) in the testing site's timezone.

Why do you "need" to use JavaScript Dates? (It seems to me they're the problem, not the solution.)

I'm closing for #1526, I think that we are discussing the same problem

why it is dirfferent, when using mui date-picker, it shows GMT-8, but chrome console shows GMT-9

@adamhooper got it, very appreciate you!

The error could happen both on the client's local machine if they have a different time zone, so when selecting a date, the system automatically picks a "translated date to UTC," which is incorrect if their time zone is not GMT+00.
Similarly, on a hosted client server, if the server's time zone differs from the user's, the selected date will be correct locally, but when sent to the server, it will be converted to UTC. This can result in a date that is one day earlier (23:00:00Z) for users in GMT+01 time zones.
The solution that works for me in both scenarios is:
setDate(moment(date).utc(true).toDate());

I am still wondering why the mui devs put the keepLocalTime of utc function to false, and we need each time to specify it is true, because by default users want their date to be universal, and just few app usecases that need to keepLocalTime, like games dates based .. so I think it's a bad move,
Another potential solution for the second scenario is:
setDate(moment(date).utc().set({ hours: 12, minutes: 0, seconds: 0, milliseconds: 0 }).toDate());