Authentication failure after an hour using Google Cloud service account

          First off, thank you for the great work on the project.

I was in need of a Google Oauth2 method to use my older applications and found this would work perfectly for my needs.  I wanted to have an "auto-auth" method so I created the Service_Account on my Google Workspace and generated the JSON file.  Using the JSON file I generated the pre-generated keys for each user and It is working perfectly except after about an hour, it stops working and will no longer accept authentication.  It says "Accepting new connections..." but fails...  It is happening with all the services I have configured which is IMAP and POP with the same result.  The current resolution is to stop the program, remove the cache-store file and restart the program.
I have each service on a different physical box and the command to start the app and configurations are listed below:
Command:
python3 emailproxy.py --no-gui --config-file emailproxy.config --cache-store cache-store  --log-file emailproxy.log
PC A
[Server setup]

[IMAP-993]
server_address = imap.gmail.com
server_port = `993`
local_address = <ipaddr>

[Account setup]

<EMAIL_ADDRESS>token_url = https://oauth2.googleapis.com/token
oauth2_scope = https://mail.google.com/
oauth2_flow = service_account
redirect_uri = http://localhost
client_id = file
client_secret_encrypted = <secret>
token_salt = <salt>
token_iterations = 870000

[Advanced proxy configuration]

[emailproxy]
delete_account_token_on_password_error = False
encrypt_client_secret_on_first_use = True
allow_catch_all_accounts = False

PC B
[Server setup]

[POP-995]
server_address = pop.gmail.com
server_port = 995
local_address = <ipaddr>

[Account setup]

<EMAIL_ADDRESS>token_url = https://oauth2.googleapis.com/token
oauth2_scope = https://mail.google.com/
oauth2_flow = service_account
redirect_uri = http://localhost
client_id = file
client_secret_encrypted = <secret>
token_salt = <salt>
token_iterations = 870000

[Advanced proxy configuration]

[emailproxy]
delete_account_token_on_password_error = False
encrypt_client_secret_on_first_use = True
allow_catch_all_accounts = False

Please let me know if there is something I may be missing, doing wrong, or additional steps that may be required to help understand the issue and help to solve the problem.
Regards,
Johspa
Originally posted by @johspa933 in https://github.com/simonrob/email-oauth2-proxy/issues/212#issuecomment-1907292776

I don't understand what you mean by this bit:

Using the JSON file I generated the pre-generated keys for each user

As explained in the documentation, when using the proxy with a Google Cloud service account, you should set the client_secret value either to the full path to the service account JSON key file, or its entire contents. Which one of these is used is configured by the client_id parameter, and you're using client_id = file so should be providing a full file path.
As the response in #212 suggested, it sounds like you're adding an extra manual step that isn't required. What I'm actually surprised about here is that it works at all, so perhaps it's actually just slightly confusing wording in your explanation. Perhaps you actually mean that you are using the example script to pre-encrypt these values.
Please can you clarify?

I do apologize for the bad explanation so let me clarify.
I was initially using the client_id with the fileoption which contained the path to the Google JSON file.  However, I decided to try using the pre-encrypt script and the JSON file to generate the configurations.  Both methods have the same result for POP and IMAP Services/Applications.
For the IMAP
I have two applications that use it.  The first appears to create the initial TCP connection and keeps that open for about an hour then abruptly disconnects.  Any further authentication fails after that.  The other IMAP application appears to do standard TCP connections and completes normally with Client Disconnect followed by Server Disconnect messages.
After the hours time, they stop working but the first application authentication starts doing "standard" TCP connections which fail.  The second application continues to do standard TCP connections but they fail.  I need to do further Debugging to see the exact differences which I am doing now.
For the POP
I also have two applications but they behavior the same.  They make standard TCP connections followed by Client Disconnect followed by Server Disconnect messages.
After an hours time, the TCP connections appear to be the same but stop working.  However, I also need to gather further Debugging to see the exact differences.
Current Workaround
The workaround I have for now and it works every time is to delete the cache file and restart the application again once the applications start failing authentication.
Please let me know if there are questions, commands, or debug messages that may be needed to help troubleshoot.
Regards,
Johspa

Thanks – no problem. Does this still happen if you don't use the cache-store feature and just have one instance of the proxy running?

Per your questions:

Does this still happen if you don't use the cache-store feature

When I turn off the cache-store, same result

just have one instance of the proxy running

Yes, only one instance is running on each PC.
I just created an hour long DEBUG of the data so need to comb through it.
Regards,
Johspa

I went through the POP file data and found the following differences:
Here is the output from initial running of the EmailProxy (Difference in middle section):
2024-01-24 11:50:00: New incoming connection to POP server at <emailproxyIP>:995 (unsecured) proxying pop.gmail.com:995 (SSL/TLS)
2024-01-24 11:50:00: Accepting new connection from <clientIP>:55106 to POP server at <emailproxyIP>:995 (unsecured) proxying pop.gmail.com:995 (SSL/TLS)
2024-01-24 11:50:00: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995) --> [ Client connected ]
2024-01-24 11:50:01: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995) <-> [ Starting TLS handshake ]
2024-01-24 11:50:01: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995) <-> [ TLSv1.3 handshake complete ]
2024-01-24 11:50:01: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995)     <-- b'+OK Gpop ready for requests from <externalIP> n6mb44155743ywl\r\n'
2024-01-24 11:50:01: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995) <-- b'+OK Gpop ready for requests from <externalIP> n6mb44155743ywl\r\n'
2024-01-24 11:50:01: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995) --> b'USER<EMAIL_ADDRESS>2024-01-24 11:50:01: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995) <-- b'+OK\r\n'
2024-01-24 11:50:01: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995) --> b'PASS [[ Credentials removed from proxy log ]]\r\n'
2024-01-24 11:50:01: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995)     --> b'AUTH XOAUTH2\r\n'
2024-01-24 11:50:01: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995)     <-- b'+ \r\n'
2024-01-24 11:50:02: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995)     --> b'[[ Credentials removed from proxy log ]]\r\n'

2024-01-24 11:50:02: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS>    <-- b'+OK Welcome.\r\n'
2024-01-24 11:50:02: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS>[ Successfully authenticated POP connection - releasing session ]
2024-01-24 11:50:02: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS><-- b'+OK Welcome.\r\n'
2024-01-24 11:50:02: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS>--> b'STAT\r\n'
2024-01-24 11:50:03: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS><-- b'+OK 0 0\r\n'
2024-01-24 11:50:03: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS>--> b'CAPA\r\n'
2024-01-24 11:50:03: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS><-- b'+OK Capability list follows\r\nUSER\r\nRESP-CODES\r\nPIPELINING\r\nEXPIRE 0\r\nLOGIN-DELAY 300\r\nTOP\r\nUIDL\r\nX-GOOGLE-RICO\r\n.\r\n'
2024-01-24 11:50:03: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS>--> b'QUIT\r\n'

2024-01-24 11:50:03: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS>--> [ Client disconnected ]
2024-01-24 11:50:03: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995) <-- [ Server disconnected ]

Here is the output after an hour (Difference in the middle section):
2024-01-24 13:00:01: New incoming connection to POP server at <emailproxyIP>:995 (unsecured) proxying pop.gmail.com:995 (SSL/TLS)
2024-01-24 13:00:01: Accepting new connection from <clientIP>:55106 to POP server at <emailproxyIP>:995 (unsecured) proxying pop.gmail.com:995 (SSL/TLS)
2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995) --> [ Client connected ]
2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995) <-> [ Starting TLS handshake ]
2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995) <-> [ TLSv1.3 handshake complete ]
2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995)     <-- b'+OK Gpop ready for requests from <externalIP> f125mb40093004ywh\r\n'
2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995) <-- b'+OK Gpop ready for requests from <externalIP> f125mb40093004ywh\r\n'
2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995) --> b'USER<EMAIL_ADDRESS>2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995) <-- b'+OK\r\n'
2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995) --> b'PASS [[ Credentials removed from proxy log ]]\r\n'
2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995)     --> b'AUTH XOAUTH2\r\n'
2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995)     <-- b'+ \r\n'
2024-01-24 13:00:02: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995)     --> b'[[ Credentials removed from proxy log ]]\r\n'

2024-01-24 13:00:02: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS>    <-- b'+ <encrypted>\r\n'
2024-01-24 13:00:02: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS><-- b'+ <encrypted>\r\n'

2024-01-24 13:00:02: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995) <-- [ Server disconnected ]
2024-01-24 13:00:02: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS>--> [ Client disconnected ]

It appears the authentication changes from "+OK Welcome" to a "+ " statement. I hope this helps...
I am still working on the IMAP DEBUG logs to determine differences.
Regards,
Johspa

After going through the POP DEBUG logs the differences in the POP authentication from the starting of the application to after running for an hour are below.
Initial start of the EmailProxy app (Differences in the middle section):
2024-01-24 11:50:00: New incoming connection to POP server at <emailproxyIP>:995 (unsecured) proxying pop.gmail.com:995 (SSL/TLS)
2024-01-24 11:50:00: Accepting new connection from <clientIP>:55106 to POP server at <emailproxyIP>:995 (unsecured) proxying pop.gmail.com:995 (SSL/TLS)
2024-01-24 11:50:00: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995) --> [ Client connected ]
2024-01-24 11:50:01: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995) <-> [ Starting TLS handshake ]
2024-01-24 11:50:01: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995) <-> [ TLSv1.3 handshake complete ]
2024-01-24 11:50:01: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995)     <-- b'+OK Gpop ready for requests from <externalIP> n6mb44155743ywl\r\n'
2024-01-24 11:50:01: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995) <-- b'+OK Gpop ready for requests from <externalIP> n6mb44155743ywl\r\n'
2024-01-24 11:50:01: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995) --> b'USER<EMAIL_ADDRESS>2024-01-24 11:50:01: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995) <-- b'+OK\r\n'
2024-01-24 11:50:01: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995) --> b'PASS [[ Credentials removed from proxy log ]]\r\n'
2024-01-24 11:50:01: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995)     --> b'AUTH XOAUTH2\r\n'
2024-01-24 11:50:01: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995)     <-- b'+ \r\n'
2024-01-24 11:50:02: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995)     --> b'[[ Credentials removed from proxy log ]]\r\n'

2024-01-24 11:50:02: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS>    <-- b'+OK Welcome.\r\n'
2024-01-24 11:50:02: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS>[ Successfully authenticated POP connection - releasing session ]
2024-01-24 11:50:02: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS><-- b'+OK Welcome.\r\n'
2024-01-24 11:50:02: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS>--> b'STAT\r\n'
2024-01-24 11:50:03: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS><-- b'+OK 0 0\r\n'
2024-01-24 11:50:03: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS>--> b'CAPA\r\n'
2024-01-24 11:50:03: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS><-- b'+OK Capability list follows\r\nUSER\r\nRESP-CODES\r\nPIPELINING\r\nEXPIRE 0\r\nLOGIN-DELAY 300\r\nTOP\r\nUIDL\r\nX-GOOGLE-RICO\r\n.\r\n'
2024-01-24 11:50:03: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS>--> b'QUIT\r\n'

2024-01-24 11:50:03: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS>--> [ Client disconnected ]
2024-01-24 11:50:03: POP (<clientIP>:55106-{<emailproxyIP>:995}-pop.gmail.com:995) <-- [ Server disconnected ]

After an hour of the EmailProxy app running (Differences in the middle section):
2024-01-24 13:00:01: New incoming connection to POP server at <emailproxyIP>:995 (unsecured) proxying pop.gmail.com:995 (SSL/TLS)
2024-01-24 13:00:01: Accepting new connection from <clientIP>:55106 to POP server at <emailproxyIP>:995 (unsecured) proxying pop.gmail.com:995 (SSL/TLS)
2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995) --> [ Client connected ]
2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995) <-> [ Starting TLS handshake ]
2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995) <-> [ TLSv1.3 handshake complete ]
2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995)     <-- b'+OK Gpop ready for requests from <externalIP> f125mb40093004ywh\r\n'
2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995) <-- b'+OK Gpop ready for requests from <externalIP> f125mb40093004ywh\r\n'
2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995) --> b'USER<EMAIL_ADDRESS>2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995) <-- b'+OK\r\n'
2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995) --> b'PASS [[ Credentials removed from proxy log ]]\r\n'
2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995)     --> b'AUTH XOAUTH2\r\n'
2024-01-24 13:00:01: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995)     <-- b'+ \r\n'
2024-01-24 13:00:02: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995)     --> b'[[ Credentials removed from proxy log ]]\r\n'

2024-01-24 13:00:02: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS>    <-- b'+ <encrypted>\r\n'
2024-01-24 13:00:02: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS><-- b'+ <encrypted>\r\n'

2024-01-24 13:00:02: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995) <-- [ Server disconnected ]
2024-01-24 13:00:02: POP (<clientIP>:56010-{<emailproxyIP>:995}-pop.gmail.com:995<EMAIL_ADDRESS>--> [ Client disconnected ]

It appears the authentication changes from +OK Welcome to a + <encrypted> statement.  I hope this helps in the troubleshooting process.
I am still working on the IMAP DEBUG output so that be coming shortly.
Regards,
Johspa

After going through the IMAP DEBUG logs, I am seeing very similar behavior where a section of the authentication changes and causes the authentication to fail.  See just the differences for the IMAP-App-1 and IMAP-App-2 below.
IMAP-App-1
Initial start of the EmailProxy app difference only:
11:47:20 ~ 2024-01-24 11:47:20: IMAP (<clientIP>:57596-{<emailproxyIP>:993}-imap.gmail.com:993<EMAIL_ADDRESS>    <-- b'* CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ENABLE MOVE CONDSTORE ESEARCH UTF8=ACCEPT LIST-EXTENDED LIST-STATUS LITERAL- SPECIAL-USE APPENDLIMIT=35651584\r\n'
11:47:20 ~ 2024-01-24 11:47:20: IMAP (<clientIP>:57596-{<emailproxyIP>:993}-imap.gmail.com:993<EMAIL_ADDRESS><-- b'* CAPABILITY IMAP4rev1 AUTH=PLAIN SASL-IR UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ENABLE MOVE CONDSTORE ESEARCH UTF8=ACCEPT LIST-EXTENDED LIST-STATUS LITERAL- SPECIAL-USE APPENDLIMIT=35651584\r\n'
11:47:20 ~ 2024-01-24 11:47:20: IMAP (<clientIP>:57596-{<emailproxyIP>:993}-imap.gmail.com:993<EMAIL_ADDRESS>    <-- b'A00000 OK<EMAIL_ADDRESS>authenticated (Success)\r\n'
11:47:20 ~ 2024-01-24 11:47:20: IMAP (<clientIP>:57596-{<emailproxyIP>:993}-imap.gmail.com:993<EMAIL_ADDRESS>[ Successfully authenticated IMAP connection - releasing session ]
11:47:20 ~ 2024-01-24 11:47:20: IMAP (<clientIP>:57596-{<emailproxyIP>:993}-imap.gmail.com:993<EMAIL_ADDRESS><-- b'A00000 OK<EMAIL_ADDRESS>authenticated (Success)\r\n'

After an hour of the EmailProxy app running:
12:52:35 ~ 2024-01-24 12:52:35: IMAP (<clientIP>:34888-{<emailproxyIP>:993}-imap.gmail.com:993<EMAIL_ADDRESS>    <-- b'+ <encrypted>\r\n'
12:52:35 ~ 2024-01-24 12:52:35: IMAP (<clientIP>:34888-{<emailproxyIP>:993}-imap.gmail.com:993<EMAIL_ADDRESS><-- b'+ <encrypted>\r\n'
12:53:35 ~ 2024-01-24 12:53:35: IMAP (<clientIP>:34888-{<emailproxyIP>:993}-imap.gmail.com:993<EMAIL_ADDRESS>--> [ Client disconnected ]

IMAP-App-2
Initial start of the EmailProxy app difference only:
11:50:21 ~ 2024-01-24 11:50:21: IMAP (<clientIP>:55138-{<emailproxyIP>:993}-imap.gmail.com:993<EMAIL_ADDRESS>    <-- b'* CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ENABLE MOVE CONDSTORE ESEARCH UTF8=ACCEPT LIST-EXTENDED LIST-STATUS LITERAL- SPECIAL-USE APPENDLIMIT=35651584\r\n'
11:50:22 ~ 2024-01-24 11:50:21: IMAP (<clientIP>:55138-{<emailproxyIP>:993}-imap.gmail.com:993<EMAIL_ADDRESS><-- b'* CAPABILITY IMAP4rev1 AUTH=PLAIN SASL-IR UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ENABLE MOVE CONDSTORE ESEARCH UTF8=ACCEPT LIST-EXTENDED LIST-STATUS LITERAL- SPECIAL-USE APPENDLIMIT=35651584\r\n'
11:50:22 ~ 2024-01-24 11:50:21: IMAP (<clientIP>:55138-{<emailproxyIP>:993}-imap.gmail.com:993<EMAIL_ADDRESS>    <-- b'40 OK<EMAIL_ADDRESS>authenticated (Success)\r\n'
11:50:22 ~ 2024-01-24 11:50:21: IMAP (<clientIP>:55138-{<emailproxyIP>:993}-imap.gmail.com:993<EMAIL_ADDRESS>[ Successfully authenticated IMAP connection - releasing session ]

After an hour of the EmailProxy app running:
12:58:49 ~ 2024-01-24 12:58:49: IMAP (<clientIP>:55990-{<emailproxyIP>:993}-imap.gmail.com:993<EMAIL_ADDRESS>    <-- b'+ <encrypted>\r\n'
12:58:49 ~ 2024-01-24 12:58:49: IMAP (<clientIP>:55990-{<emailproxyIP>:993}-imap.gmail.com:993<EMAIL_ADDRESS><-- b'+ <encrypted>\r\n'
12:58:49 ~ 2024-01-24 12:58:49: IMAP (<clientIP>:55990-{<emailproxyIP>:993}-imap.gmail.com:993<EMAIL_ADDRESS>--> b'<encrypted>\r\n'
12:58:49 ~ 2024-01-24 12:58:49: IMAP (<clientIP>:55990-{<emailproxyIP>:993}-imap.gmail.com:993<EMAIL_ADDRESS>    --> b'<encrypted>\r\n'
12:58:49 ~ 2024-01-24 12:58:49: IMAP (<clientIP>:55990-{<emailproxyIP>:993}-imap.gmail.com:993<EMAIL_ADDRESS>    <-- b'90 NO [AUTHENTICATIONFAILED] Invalid credentials (Failure)\r\n'
12:58:49 ~ 2024-01-24 12:58:49: IMAP (<clientIP>:55990-{<emailproxyIP>:993}-imap.gmail.com:993<EMAIL_ADDRESS><-- b'90 NO [AUTHENTICATIONFAILED] Invalid credentials (Failure)\r\n'

It appears similar authentication changes are taking place from * CAPABILITY to a + <encrypted> statement. Once again, I hope this helps in the troubleshooting process.
Regards,
Johspa

Thanks for the update. Just to be clear, is the value actually + <encrypted>, or have you edited the value here?
If you've edited it, which I presume is the case, i'm afraid that's not much help – the +  at the start is equivalent to "please send the next bit of data", so I'll need to know what is actually being communicated here.
Feel free to share the unedited logs via email if you're more comfortable with that – my GitHub username at Gmail.

I edited the values so as not to provide anything I should not...  I will email the actual values via email for the POP and IMAP.
I should be able to send in the about an hour or so.
Regards,
Johnspa

Thanks for sharing the logs. Just to keep everything in one place, and for the benefit of anyone else encountering this, the value you replaced with <encrypted> in the logs above is:
eyJzdGF0dXMiOiI0MDAiLCJzY2hlbWVzIjoiQmVhcmVyIiwic2NvcGUiOiJodHRwczovL21haWwuZ29vZ2xlLmNvbS8ifQ==

The reason it is fine to post this here is that it's actually the Base64-encoded version of:
{"status":"400","schemes":"Bearer","scope":"https://mail.google.com/"}

So, given the reliable one-hour window between things working and then failing, the issue is probably that the token is not being renewed. I'm curious as to why this is happening, though.
With --cache-store still disabled, after you've authenticated your accounts, the config file should be updated with values for access_token and access_token_expiry. Please could you provide the access_token_expiry value?
Even more useful, could you compare it with the time you make the authentication request, and provide both times? You can use a website such as this one to convert the timestamp into a human-readable date.

Ok, I have restarted the EmailProxy app and noted the time I checked my email for the first time.  I then checked the access_token_expire value and here are the values:
Checked my email for the first time after the EmailProxy restart  = 05:18pm
The value for the access_token_expire =<PHONE_NUMBER> = 06:18:19PM
So, it appears the access_token_expire is set for 1 hour after the initial use.
Regards,
Johspa

Good – this is as expected. Once the expiry time is reached, the proxy should auto-renew the token. Just to be sure, I tested this again myself, and the token is correctly renewed by the proxy when it expires.
What happens if you do the following:

Authenticate with an account that is making use of the service account feature
Remove the token_salt, token_iterations, access_token and access_token_expiry values from the proxy's configuration file (before 1hr has elapsed)
Reload the configuration file in the proxy
Try to log in again

To answer your question:

Authenticate with an account that is making use of the service account feature
Remove the token_salt, token_iterations, access_token and access_token_expiry values from the proxy's configuration file (before 1hr has elapsed)
Reload the configuration file in the proxy
Try to log in again

That is already what I am doing with the cache-store file.  I can usually delete the cache-store file (which contains all the items you mention) and restart the app which works again regardless of doing BEFORE the token expires or AFTER it expires.
However, I have some new information...
I "consolidated" the services and users onto one VM since it was mostly working except for the authentication (I had the POP service/login on one VM and the IMAP service/login on another VM before).  So, I was running the single VM setup since late last evening while I waited for your next response.  When I checked it this morning, everything was working except one client app.  I closed that application, due the fact it is NOT important and I can probably do without it.
So, based on that maybe it was due to the services being on different VMs?  I am not sure if that is the case or if that even makes sense so I need to comb through the Logs and see what I can find but not sure I will get a chance today.  I will report back when I have more information.
Regards,
Johspa

I think that is the only real explanation here – something to do with the use of --cache-store.
When you say the two instances were on two different physical devices, were you using --cache-store to synchronise the cache file between them? If so, how were you achieving that?
If you weren't doing any synchronisation between devices, I can't think of anything that could cause this – you'd get a different independent token for each one.

Apologies for the delay but work got in the way...

When you say the two instances were on two different physical devices, were you using --cache-store to synchronise the cache file between them? If so, how were you achieving that?

No, they had different cache-store files and were NOT synced.  I would agree that would probably be a bad thing.
I have been running all services on a single VM for almost a week now and it has not failed once.  Also, I went through the logs for  the past several days now and I am not seeing any of the failures I saw in past.
So, all I can figure is having some kind of strange combination of VMs and Services was the cause of the issue.  Thank you so much for the support and greatly appreciate the support.  Keep up the great work.
Regards,
Johspa

Thanks for following up - I'm glad this was resolved.


Please Add HelpingAI to it

Feature request
Added HelpingAI model type in it
Motivation
It is one of the best 3B model
Your contribution
Sorry but I could not help by submitting pr

Hi @OE-LUCIFER, can you give me a reference for HelpingAI? I can not find it in Transformers.

This is that model https://huggingface.co/OEvortex/HelpingAI-3B


Tooltip doesn't work on iPhone

Describe the bug
@TGlide, hi!
It seems like the tooltip doesn't work on iPhone even on the melt-ui website.
Reproduction
It's reproducible even on the melt-ui website — https://melt-ui.com/docs/builders/tooltip.
https://github.com/melt-ui/melt-ui/assets/55146773/e6744ec6-b1e6-4f47-bfba-dc148956d33a
Logs
No response
System Info
System:
    OS: macOS 14.2.1
    CPU: (8) arm64 Apple M1 Pro
    Memory: 950.44 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.3.0 - ~/.nvm/versions/node/v20.3.0/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v20.3.0/bin/yarn
    npm: 9.6.7 - ~/.nvm/versions/node/v20.3.0/bin/npm
    bun: 1.0.7 - ~/.bun/bin/bun
  Browsers:
    Chrome: 120.0.6099.234
    Safari: 17.2.1
  npmPackages:
    @melt-ui/svelte: ^0.70.0 => 0.70.0
    @sveltejs/kit: ^1.20.4 => 1.30.3
    svelte: ^4.0.5 => 4.2.8

Severity
annoyance

This is expected behavior. See https://github.com/melt-ui/melt-ui/issues/196 for more info regarding this.

@huntabyte, hi! Thanks for the clarification. I'm learning more and more about accessibility thanks to melt-ui.
This behavior definitely should be specified in melt-ui docs. It's super unintuitive unless you're an accessibility geek.
Does setting closeOnPointerDown to false still work? It seems like not.

@huntabyte, hi! Thanks for the clarification. I'm learning more and more about accessibility thanks to melt-ui. This behavior definitely should be specified in melt-ui docs. It's super unintuitive unless you're an accessibility geek.
Does setting closeOnPointerDown to false still work? It seems like not.

We have this on the docs:

I was talking to Hunter though, and I thought it should work due to focus, and it does work on Android. But maybe iPhone just doesn't focus on the button for some reason, or it's a bug on our end. I'll reopen to investigate!
Nonetheless, you're probably better off using a popover on mobile, if you desperately need to show content on press

Oh, it's way down in the accessibility section. My bad, I've never scrolled this far. Just a personal opinion: I'd put this right in the features section.
Yep, maybe it's an iPhone-specific problem. Thanks for the investigation!
I got your point about a popover, thanks! I'll give it a try.

For future peeps (gonna send this issue now when it's brought up in the time between us documenting this):
As @TGlide mentioned, on certain devices it may focus, but that's only after a click has already occurred, meaning the potential context needed to know if you should even click this button isn't displayed until after a click (which is unexpected behavior IMO).
Tooltips are meant to provide additional, not necessary info about a given action (hence the "tip" in the name). If you find yourself needing a tooltip on mobile, you're likely using the wrong tool for the job, and should instead look at a Popover or include the contents of the tooltip somewhere else if that content is critical for the user to see.
Here's a great article from a much smarter individual than myself that goes into a bit more detail about this:
Tooltips in the time of WCAG 2.1

@TGlide, @huntabyte, btw, do you have a roadmap for the melt-ui? Or at least some overview of plans? I'm using the library in production, so it'd be nice to understand where the project is heading.

@TGlide, @huntabyte, btw, do you have a roadmap for the melt-ui? Or at least some sketchy plans? I'm using the library in production, so it'd be nice to understand where the project is heading.

Nothing super laid out. You'll find most of our plans here in issues, discussions, and sometimes in the Discord. RN the focus is getting 1.0 up and running. That means a focus on stability, fixes, testing, docs, etc.

@TGlide, got it, thanks! I love you project ❤

I tried using Popover on mobile and Tooltip on desktop. It 100% works but adds so much complexity to the code, affecting DX.
I'm not that into accessibility and don't know a lot of nuances, but from the info you provided, it's clear that tooltips should work on touch devices.

Tooltips should only ever contain non-essential content. The best approach to writing tooltip content is to always assume it may never be read.

I don't see any contradictions between the above statement and a functional tooltip on mobile. The content is non-essential anyway. It doesn't matter whether you're on a touch device or a desktop/laptop.
But maybe it's only my naive opinion.

I tried using Popover on mobile and Tooltip on desktop. It 100% works but adds so much complexity to the code, affecting DX.

Popover an Tooltip usage is not entirely interchangeable. A tooltip servers to provide a tip regarding a tool. So it should be used on an interactable element that does something else beside show that tooltip. A popover's trigger however, servers only to open the popover's contents, nothing else.
From MDN:

The tooltip is not the appropriate role for the more information "i" icon, ⓘ. A tooltip is directly associated with the owning element. The ⓘ isn't 'described by' detailed information; the tool or control is.

it's clear that tooltips should work on touch devices

How so? I only mentioned that when closeOnPointerDown is set to false, that clicking on the tooltip's trigger won't close it, which does make it work on mobile devices if they focus elements on click, which it seems iPhone does not do (something we need to investigate though).
It makes sense for tooltips to not work on mobile, however. If the only way you can access it on mobile, is by tapping, and that button serves another purpose besides showing the tooltip (which it should by my previous definitions), then once you're shown the information regarding the action, it's already too late, that action already executed!
You can see more of our thoughts here: https://github.com/melt-ui/melt-ui/issues/196

So it should be used on an interactable element that does something else beside show that tooltip. A popover's trigger however, servers only to open the popover's contents, nothing else.

Wow, I didn't know that at all! With this new info, I understand your points much better. I've been using tooltips wrong my entire life.
So, if I want to show non-critical info user hovers over an "i" icon, I should use Popover instead of Tooltip?

it's clear that tooltips should work on touch devices

I was wrong, sorry.

So, if I want to show non-critical info user hovers over an "i" icon, I should use Popover instead of Tooltip?

Yes, but it shouldn't be on hover, rather, on click. Some info here: https://inclusive-components.design/tooltips-toggletips/

I don't get why we are taking a hard stance on stuff like this just because someone once made a blog post about tooltips being bad on mobile.
UI design changes daily, and everyone's use case is different.
Simply said, There are legitimate use cases for tooltips working on mobile.
It's up to the developer to implement best practices or move away from them where needed.
There never is a one-size-fits-all solution.
That's also the whole point of shadcn/ui.
To give the developer more control.

I don't get why we are taking a hard stance on stuff like this just because someone once made a blog post about tooltips being bad on mobile.

@ivands If you've taken the time to read our discussions for this, such as what we mentioned on #196, you'd know that it's not just one blog post, we and several accessibility experts have done tons of research, and we do provide alternatives for making the tooltip work on mobile, otherwise this issue would have been closed already.
It may just be that this issue doesn't have a solution, in case iPhone does not focus items on click, in which case, I'll leave it as is. If you want to know why, take the time to read our previous explanations on the matter.

There are legitimate use cases for tooltips working on mobile

Give me one, and how you would like for the user to interact with said tooltip in said case, and we can discuss.

That's also the whole point of shadcn/ui.
To give the developer more control.

This is not shadcn/ui, it's Melt UI. The point of Melt UI is to give sensible, accessible defaults, while giving you the flexibility to override it however you want. Since we believe there is no sensible or accessible default for tooltips in mobile, we don't include it, but you have the flexibility to implement whatever behaviour you want. So in that sense, you do have control.

But I'm trying to build an admin panel with shadcn-svelte.
And I was redirected here after opening an issue about this in bits-ui.
https://github.com/huntabyte/bits-ui/issues/314
My issue was closed because "tooltips should only open on hover" apparently.
This might be the current recommendation from "several accessibility experts."
But why would that recommendation limit the functionality of the API?
It just makes sense to have tooltips work on mobile with a click event or something else.

Give me one, and how you would like for the user to interact with said tooltip in said case, and we can discuss.

I have hidden information inside the tooltip that is relevant on mobile.

This is not shadcn/ui, it's Melt UI. The point of Melt UI is to give sensible, accessible defaults, while giving you the flexibility to override it however you want. Since we believe there is no sensible or accessible default for tooltips in mobile, we don't include it, but you have the flexibility to implement whatever behaviour you want. So in that sense, you do have control.

Sorry, I might be in the wrong place.
Yeaaaa should probably be discussing this at bits-ui.

I'm trying to build an admin panel with shadcn-svelte. And I was redirected here after opening an issue about this in bits-ui.

Yes, I understand.

My issue was closed because "tooltips should only open on hover" apparently. This might be the current recommendation from "several accessibility experts." But why would that recommendation limit the functionality of the API?

Because we are working with accessibility in mind, it's the default. Mind you, the original shadcn/ui is even stricter than we are in terms of tooltips.

It just makes sense to have tooltips work on mobile with a click event or something else.

It does not. A tooltip describes a button's action, if you click the button, it'll do the action anyways, you no longer need that tip. Use a popover if you want it on click.

I have hidden information inside the tooltip that is relevant on mobile.

That does not bring up much for discussion. Why are you hiding it? Why can't you use a popover? How relevant is it? A lot of the times we need to force us to redesign our solutions to better meet users needs.

Sorry, I might be in the wrong place. Yeaaaa should probably be discussing this at bits-ui.

I mean, bits behaviour is largely defined by Melt. Unless @huntabyte wants to address adding extra behaviour on top of tooltip over in bits instead of doing it in Melt (which I doubt), this is the right place. In any case, I mentioned the distinction to share what my vision is for this project.

Sorry, let me be more descriptive about my use case:
I have a bar graph with multiple data points inside a single X-axis.
When you hover over a bar, you get a summary of all the data on that axis.
It makes sense to be still able to show the summary on mobile when you press the bar.
In my use case, the hover event is more desirable on desktop, and the click event is our only option on mobile.

Sorry, let me be more descriptive about my use case: I have a bar graph with multiple data points inside a single X-axis. When you hover over a bar, you get a summary of all the data on that axis. It makes sense to be still able to show the summary on mobile when you press the bar. In my use case, the hover event is more desirable on desktop, and the click event is our only option on mobile.

Probably not the best case for a tooltip. As the name says, a tooltip is a tip that describes a tool. Sorry to be nitpicky about naming, but it does matter, a lot of other considerations come into tooltips besides cursor, such as aria-roles, keyboard interactivity, etc. In your case, I'd probably use floating-ui directly for something more custom.

Yeah, I was using floating-ui before. I'm making V2 of our service right now. So I was hoping I don't have to make everything myself again. XD
Guess there is no way around it.

This has to be some meme or something. You start a project hoping there is a UI library that can fulfill your needs. But it always turns out you need some custom functionality, and now you have to make it yourself.

Such is life! But tbh it's okay if a UI library doesn't fill your needs 100%. That's what's nice about headless, take what you need and scrap the rest. It doesn't affect the rest of your app.

So what about the scenario where you want something to trigger on hover (mouse) OR click (touch)?
The shadcn-svelte documentation https://www.shadcn-svelte.com/docs/components/tooltip says:

Provides additional information or context when users hover over or interact with an element.

Last I checked clicking on something is interacting.

That does not bring up much for discussion. Why are you hiding it? Why can't you use a popover? How relevant is it? A lot of the times we need to force us to redesign our solutions to better meet users needs.

I understand the desire to make things accessible by default, but there's a reason everyone expects it to work this way.
I don't understand why using a component with a different name is considered the solution.
Is it because of the name? I pick a component based on the behaviour I want and expect. Is a popover magically more accessible than a Tooltip?
Additionally, tooltips do not have to be attached to buttons that perform an immediate action. It can be attached to any GUI element which could require more context. Triggering from hover on desktop and clicking on mobile (or long pressing) is the obvious and intuitive way to display this information.

So what about the scenario where you want something to trigger on hover (mouse) OR click (touch)?

Tooltip is not intended for this.

The shadcn-svelte documentation says

Sorry, but that's not relevant. Melt's documentation is the important bit here.

Is it because of the name? I pick a component based on the behaviour I want and expect.

Of course it's not because of the name. They have different behaviours, accessibility concerns, etc. E.g. a popover can have interactible content inside it, a tooltip cannot.

Is a popover magically more accessible than a Tooltip?

No such thing, it's just more suitable in certain situations.

is the obvious and intuitive way to display this information.

Obvious to whom? Will screen readers say that you should long press it? Is there a consensus to have tooltips on any button? You need to hover a button before clicking it, so a tooltip naturally appearing is a nice bonus. And tooltips generally work this way.
Long pressing does not necessarily bring tooltips in other places. It's not a standard in any shape or form.
Being a UI library, the choices we make greatly impact the web, specially as it grows. We can't be careless and assume, things need to be done with a lot of thought, evidence, and study.


[Project Enhancement]: Brain Stroke Prediction using Neural Networks

Pull Request for ML-Crate 💡
Brain Stroke Prediction using Neural Networks #605

Do the data analysis and cleaning of the given data and build a neural network with optimum accuracy for the same.
Armaan Jagirdar
<EMAIL_ADDRESS>Armaan457
Contributor at SSOC'24

Closes: #605
Added a new notebook (ipynb) containing the codes for data cleaning and analysis along with 5 neural networks build on TensorFlow with various layers, activations and regularisers
Type of change ☑
What sort of change have you made:

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested? ⚙
Describe how it has been tested: The accuracy of the models were measured to ensure no underfitting or overfitting occurs, the data was cleaned to ensure no null values interfere.
Checklist: ☑

[x] My code follows the guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly wherever it was hard to understand.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have added things that prove my fix is effective or that my feature works.
[x] Any dependent changes have been merged and published in downstream modules.

I'm sorry sir, I wasn't aware about this. What changes should I do now?

I'm sorry sir, I wasn't aware about this. What changes should I do now?

Put the existing files as it is and add your enhanced models/files along with the existing files.

Done Sir

Follow the README template and update the new README accordingly. Here is the template, https://github.com/abhisheks008/ML-Crate/blob/main/.github/readme_template.md
@Armaan457

Done sir, kindly review and suggest any changes needed.
The readme in in the Model folder inside the New folder


DRT-4934 Multi-day export ui

Adds a link to export multiple days for desks and queues.

New link on current/snapshot pages to do the exports
modal dialog to choose date range to export
new date picker component

totally sick man


Exceptions are platform specific

Platform/operating system (i.e. Raspberry Pi with Raspbian operating system,
Windows 32-bit, Windows 64-bit, Mac OSX 64-bit, etc.):  Ubuntu 18

Python version (run python -version or python3 -version):  3.5

Error message you are receiving, including any Python exception traces:  dbus.exceptions.DBusException not handled by library

List the steps to reproduce the problem below (if possible attach code or commands
to run):

adapter = ble.get_default_adapter()
adapter.power_on()
adapter.start_scan()
... find devices
adapter.stop_scan()   <--- Sometimes raises a dbus.exceptions.DBusException
dbus exceptions should not make it to the application interface as are platform (linux) specific right?  They should be converted to a library specific or generic exception type.  Now my application exception handling code needs to import and handle dbus exception types.
Thanks for the handly library, still the best option around IMO...

This library has been deprecated. Please update to use this new library:
https://github.com/adafruit/Adafruit_Blinka_bleio
If you continue to have this issue, please open a new issue in that repo.


Apachify the solr-operator helm chart

A part of: #183
The helm chart needs some updates now that the solr operator is a part of Apache.

The maintainers now start with the Solr Dev Community
Headers have been added to all possible files in the chart
A NOTICE file has been added for the chart as well.

Not sure if it's the right place to mention, but https://artifacthub.io/packages/helm/solr-operator/solr-operator also needs to be updated to point to the new chart location

Not sure if it's the right place to mention, but https://artifacthub.io/packages/helm/solr-operator/solr-operator also needs to be updated to point to the new chart location

I'll work on that as well @vladiceanu , but it is a separate issue. Thanks for bringing it up!

I'll work on that as well @vladiceanu , but it is a separate issue. Thanks for bringing it up!

@vladiceanu , there is a new entry in artifactHub for the Solr Operator (which is verified and official) https://artifacthub.io/packages/helm/apache-solr/solr-operator. It'll be hard to update the README documentation for previous helm chart releases, but at least the install button has the correct information.

@vladiceanu , there is a new entry in artifactHub for the Solr Operator (which is verified and official) https://artifacthub.io/packages/helm/apache-solr/solr-operator. It'll be hard to update the README documentation for previous helm chart releases, but at least the install button has the correct information.


chore: Move adopters page to community repo

deleting from here as adopters is not specific to V1 anymore and adding to community repo https://github.com/keptn/community/pull/243

@DavidPHirsch @thisthat
There is some orphaned x-refs since this PR in the keptn.github.io repo.
Namely, on the index page
and on the adopters page


Using the MultiGrid isScrolling is only true on the grid that scrolls

What is the current behavior?
Using the MultiGrid cellRenderer the isScrolling argument is only true on the grid that scrolls, the other grids will always report isScrolling as false.
The downside here is that optimizations to code based on the isScrolling argument can't be done. In my specific case, I get quite a bit of lag with the row headers dragging slower due to drag&drop, context menu and swipe logic in there. As none of that can actually happen when scrolling I want to use the isScrolling argument to render a simpler row header.
See https://codesandbox.io/s/z6921736wx for a working example. Scroll using the mouse wheel or slider bar and observe that only the grid that is scrolled updates the status in the cell.
What is the expected behavior?
I expect the isScrolling argument to be correct in each of the four connected Grid instances.
Which versions of React and react-virtualized, and which browser / OS are affected by this issue? Did this work in previous versions of react-virtualized?

Browser
Chrome/FireFox/Edge

OS
Windóws 10.1803

React
16.4.1

React DOM
16.4.1

react-virtualized
9.20.1

it's still there. "version": "9.21.0"

I am still experiencing this behavior on version 9.22.3, but I was able to ameliorate it pretty easily by storing the value dataGridIsScrolling in state and forcing one last update after we are done scrolling.
const [dataGridIsScrolling, setDataGridIsScrolling] = useState<boolean>(false);

useEffect(() => {
// This allows us to trigger rendering the tooltips once we have stopped scrolling.
// We do this because rendering the tooltips while scrolling causes the component to lag,
// and the tooltips are not useful while the grid is scrolling.
if (multiGridRef !== null && dataGridIsScrolling == false) {
	multiGridRef.forceUpdateGrids();
}
}, [dataGridIsScrolling])

I am still experiencing this behavior on version 9.22.3, but I was able to ameliorate it pretty easily by storing the value dataGridIsScrolling in state and forcing one last update after we are done scrolling.
const [dataGridIsScrolling, setDataGridIsScrolling] = useState<boolean>(false);

useEffect(() => {
// This allows us to trigger rendering the tooltips once we have stopped scrolling.
// We do this because rendering the tooltips while scrolling causes the component to lag,
// and the tooltips are not useful while the grid is scrolling.
if (multiGridRef !== null && dataGridIsScrolling == false) {
	multiGridRef.forceUpdateGrids();
}
}, [dataGridIsScrolling])


#2201 Fix gutter dom reference when measuring gutter width

Fixes #2201 #2200 issues.
Seen in https://jquense.github.io/react-big-calendar/examples/index.html?path=/story/addons-drag-and-drop--example-2 day/week views.

There were some minor issues with this, but it has now been resolved in 0.40.7


Update index.rst

Updated the corresponding hyperlinks.

[ ] I have added the tests to cover my changes.
[ ] I have updated the documentation, VERSION, and CHANGELOG accordingly.
[ ] I have read the CONTRIBUTING document.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@FyzHsn changes look ok, there is a Github action failing that is checking the CHANGELOG however. Do the VERSION and CHANGELOG need to be updated potentially as well?

@FyzHsn changes look ok, there is a Github action failing that is checking the CHANGELOG however. Do the VERSION and CHANGELOG need to be updated potentially as well?

@rachana-uniyal The VERSION and CHANGELOG files need to be updated.

@FyzHsn changes look ok, there is a Github action failing that is checking the CHANGELOG however. Do the VERSION and CHANGELOG need to be updated potentially as well?

@rachana-uniyal The VERSION and CHANGELOG files need to be updated.

I have updated the VERSION and CHANGELOG file.

@rachana-uniyal Good job, this is ready to be merged!


Disable pretty-printing and emojis by default

Got this feedback from @dmpetrov (typer pretty-printing and emojis) and @shcheklein (pretty-printing only).
Some considerations:

All Iterative CLI tools should behave the same. If we want to use this, let's use in all tools.
Sometimes pretty-printing fails (@shcheklein posted some example in Slack I believe)
Having emojis in output may make it harder to parse stdout/stderr.
This is not a usual pattern for CLI

IMHO: although I like emojis and pretty-printing, I don't see this as a big question that needs spending time on, so we can just disable those. Would be nice to get some thoughts from users: maybe they like it, then we can consider using this in all Iterative products.

reported by @madhur-tandon here:

I have replaced it with " ", but pip install $(mlem build requirements -m model) doesn't work because of the first line with the emoji i.e. ⏳ Loading model from sk-model.mlem.
Is there a way to ignore all this echo related stuff?

E.g. it looks like
$ mlem build model requirements
⏳ Loading model from model.mlem
scikit-learn==1.0.2
pandas==1.4.2
numpy==1.22.3

This actually relates to the discussion we had in GTO. There we decided that the output should be human-readable first, machine-readable second. That's why we implemented --plain and --json options to provide output in machine-readable format, when needed. Here I see few options:

by default, we make the output less verbose in all MLEM commands
we make the output less verbose in some commands (for now in the example above only) (don't like this option cause of non-consistency and ad-hoc fixing - we don't solve the problem holistically)
we add --plain (or another similar option) to skip the verbose output

WDYT guys? @madhur-tandon @shcheklein @mike0sv @skshetry

by default, we make the output less verbose in all MLEM commands

➕
Currently it makes it look kind of complicated, almost like Terraform or some complex orchestration tool.

Regarding verbosity.
I suggest to split this in three levels:

Verbose. Require -v/--verbose. Be as verbose, as possible, with a  Basically, this is what we have now.
Default.
Quiet. Require -q/--quiet. Nothing printed except for the command result, if there is one.

In DVC we have same arguments, though the pattern is a bit different. E.g. with -q NOTHING is printed, e.g. dvc list https://github.com/iterative/dataset-registry -q prints nothing instead of returning the list of datasets. And with -v DEBUG messages are printed (in our case DEBUG could appear with -vv like some tools have it).
@shcheklein, @jorgeorpinel maybe you can clarify why such a decision was made in the first place, maybe we don't consider some points here.
For now I'm suggesting this:

Verbose. Consider the current output as verbose.
Default. Trim the current output keeping (1) what explains long operations happening (mlem build docker), (2) what explains things that aren't that clear, (3) what can be used (URL of deployed model after mlem deploy).
Quiet. Don't print explanations, just print the result.

A couple of examples of what I'm suggesting:
Apply

mlem apply models/rf new_data.csv -i --it pandas[csv] -v
⏳ Importing object from new_data.csv
⏳ Loading model from models/rf.mlem
🍏 Applying `predict` method...
[[0.3, 0.3, 0.4]]

mlem apply models/rf new_data.csv -i --it pandas[csv]
[[0.3, 0.3, 0.4]]

mlem apply models/rf new_data.csv -i --it pandas[csv] -q
[[0.3, 0.3, 0.4]]

Deploy

$ mlem deployment run heroku app.mlem -v \
  --model models/rf \
  --app_name example-mlem-get-started-app
⏳ Loading model from models/rf.mlem
⏳ Loading deployment from app.mlem
🛠 Creating docker image for heroku
  🛠 Building MLEM wheel file...
  💼 Adding model files...
  🛠 Generating dockerfile...
  💼 Adding sources...
  💼 Generating requirements file...
  🛠 Building docker image registry.heroku.com/example-mlem-get-started-app/web...
  ✅  Built docker image registry.heroku.com/example-mlem-get-started-app/web
  🔼 Pushing image registry.heroku.com/example-mlem-get-started-app/web to registry.heroku.com
  ✅  Pushed image registry.heroku.com/example-mlem-get-started-app/web to registry.heroku.com
🛠 Releasing app example-mlem-get-started-app formation
✅  Service example-mlem-get-started-app is up. You can check it out at https://example-mlem-get-started-app.herokuapp.com/

$ mlem deployment run heroku app.mlem \
  --model models/rf \
  --app_name example-mlem-get-started-app
🛠 Building docker image registry.heroku.com/example-mlem-get-started-app/web...
🔼 Pushing image registry.heroku.com/example-mlem-get-started-app/web to registry.heroku.com
✅  Service example-mlem-get-started-app is up. You can check it out at https://example-mlem-get-started-app.herokuapp.com/

$ mlem deployment run heroku app.mlem \
  --model models/rf \
  --app_name example-mlem-get-started-app -q

Another alternative would be to do it just like DVC does, check out dvc list https://github.com/iterative/dataset-registry for example. It prints progress and operations in a single line, updating it. Finally, it updates the line with the command output.
Then:

Verbose. Consider the current output as verbose. Print it, it will take many lines (run dvc list https://github.com/iterative/dataset-registry --verbose as an example)
Default. Print the same as in Verbose, but keep updating a single line.
Quiet. Print nothing, not even the result.

@mike0sv @madhur-tandon WDYT?

Re the decisions - I think we were taking as an inspiration Git, Unix tools, some materials like this https://www.notion.so/iterative/Command-line-interface-7ef6fbc438f0419982e6d26a0c6de990
I don't think DVC does anything special that stands out.
E.g. on a quite mode. See this even to see what user expect and why - https://stackoverflow.com/questions/8943693/can-git-operate-in-silent-mode and Git and DVC do this properly to my mind.
Verbose or not, and how much by default - I would read some guidelines above. For me what is the most important is not to be silent (black screen with nothing) when something is happening at the moment (DVC has quite a few bugs like this). Besides that my initial feeling is that yes, in MLEM we can reduce the level, we don't need to do a backend logging style DEBGUG/TRACE level.
Emojis, pretty print - etc. To my taste it's a bit too fancy, to the level where it distract tbh (I'm not opposed to use some emojis for progress, checkmarks, etc, but not for every line). Also, it might complicate automation, can start breaking on SSH terminals, etc, etc. I would keep it simpler and boring.
Same with the CLI options - we've discussed how this fancy box around options is breaking apart when you split the screen, etc. Or how tail options do not work. That's why I would also prefer some boring agrparse that does everything UNIX style by default, but everything works.

First of all, if we change verbosity, it’s going to take some time to update all docs. Not that much, but can delay release. Both make breaking changes of some kind (e.g. you expected some output, maybe somehow filtered verbose output to work with MLEM, and now these changes can make your scripts fail).
Alternatives, to me:

if we are going to use DVC approach , this will be an even bigger breaking change in docs (since -q will output nothing, and we’ll need to change build reqs docs right after the release) - don’t like it. Better do it before release if we take this option.
if we are going to use my initial approach, we just need to implement just --quiet . But that differs from DVC, maybe we want to have a similar experience for the sake of ecosystem.

I'm ok with both options. The 2nd looks more "proven", so we can implement it. @mike0sv, WDYT?

dvc list -q prints nothing
with -v DEBUG messages are printed
shcheklein, @jorgeorpinel maybe you can clarify why

Wrt dvc list -q, it's probably some blanket implementation logic. It should print something in those cases IMO (cc @dberenbaum). Also good observation on dvc -v = DEBUG: but what's the purpose of verbosity if not to debug?

Default... (1) what explains long operations ... (2) things that aren't that clear, (3) what can be used

For (1) ephemeral progress bars are def. best IMO.
Wrt (2), ideally there should be no need to clarify things here, if the product design and UX are good.
So I'd focus on (3) + maybe some strategic tips (e.g. DVC tells you to git push after dvc push).

Quiet. just print the result.

Aren't results = what can be used? If so that's covered in the proposed default output. Quiet could be selective and keep the output when getting said output is the purpose of a command (e.g. -h, any lists).
So yeah, I vote DVC approach, basically 😬 not sure about release logistics but wouldn't worry much about doc updates being in sync (we have bigger fish to fry on that front).


Repeating message in log

All of a sudden my HABridge is slowing down and I'm getting this message over and over "The requested route [/(null)] has not been mapped in Spark for Accept: [null]".  Hundreds of these messages are listed in the log.  Any idea what's going on here? I'm using ver 5.1.0.  Here is a sample so you can see how often this message logs:

02-12-2018 03:19:06.502
INFO
The requested route [/(null)] has not been mapped in Spark for Accept: [null]
spark.http.matching.MatcherFilter

02-12-2018 03:19:06.508
INFO
The requested route [/(null)] has not been mapped in Spark for Accept: [null]
spark.http.matching.MatcherFilter

02-12-2018 03:19:26.928
INFO
The requested route [/(null)] has not been mapped in Spark for Accept: [null]
spark.http.matching.MatcherFilter

02-12-2018 03:19:26.928
INFO
The requested route [/(null)] has not been mapped in Spark for Accept: [null]
spark.http.matching.MatcherFilter

02-12-2018 03:19:47.000
INFO
The requested route [/(null)] has not been mapped in Spark for Accept: [null]
spark.http.matching.MatcherFilter

02-12-2018 03:19:47.000
INFO
The requested route [/(null)] has not been mapped in Spark for Accept: [null]
spark.http.matching.MatcherFilter

02-12-2018 03:20:08.004
INFO
The requested route [/(null)] has not been mapped in Spark for Accept: [null]
spark.http.matching.MatcherFilter

02-12-2018 03:20:08.010
INFO
The requested route [/(null)] has not been mapped in Spark for Accept: [null]
spark.http.matching.MatcherFilter

@lemrock This is a known issue
https://github.com/bwssytems/ha-bridge/issues/817


Update Windows dll metadata to add UWP platform support

WindowsStoreApps (UWP) platform support has been enabled on all of the Windows dll files. No editor or standalone support enabled on the ARM64 dll currently since this requires Unity 6, which is still in preview and not fully released.

Hey @BallistiX09, thank you very much for adding UWP support to the DLLs =D
Already said this in the comments, but I think the ARM64 DLL should be kept configured, there is no point in disabling it even if it requires Unity 6. Maybe it just works the way it is. I haven't tested, but until someone does, we don't know if it is broken or not and disabling it would make it actually harder for people to test it.

Hey @BallistiX09, thank you very much for adding UWP support to the DLLs =D
Already said this in the comments, but I think the ARM64 DLL should be kept configured, there is no point in disabling it even if it requires Unity 6. Maybe it just works the way it is. I haven't tested, but until someone does, we don't know if it is broken or not. Disabling this would actually make it harder for people to test it and report a broken build.

No problem at all! I've actually set the ARM64 DLL up so that (as far as I know), it should automatically work with future versions like you've mentioned.
The "Exclude Win" and "Standalone: Win" options are controlled by enabling/disabling Standalone as a platform option (allowing classic Windows builds along with UWP builds). Although I've enabled Standalone as a platform, I've disabled both the x86 and x64 CPU checkboxes, so it shouldn't try to use the ARM64 DLL on non-ARM CPUs. My thinking is that when upgrading to Unity 6, it'll automatically add the new ARM64 option to Standalone (since the platform is still enabled), while leaving the x86 and x64 CPUs disabled.
So currently, the ARM64 DLL is set up as:
- Any platform disabled
- Editor enabled, Windows OS, ARM64 CPU architecture (actually showing in-editor as Apple Silicon, but it's showing correctly in the meta file as ARM64)
- Standalone enabled, x86 and x64 CPU architectures disabled (in hopes ARM64 will automatically add down the line)
- WSAPlayer enabled, any SDK, ARM64 CPU architecture, any scripting backend, don't process disabled
- iOS/Android disabled
If you prefer, I could just go ahead and download the Unity 6 beta just now and set up the DLLs in there, I'm just not sure how that would affect backwards compatibility though (if at all).

I ended up just downloading Unity 6 anyway to test how it handles the upgrade, and it looks like it selects ARM64 as the editor option correctly, but it defaults to enabling x64 as the Standalone CPU option if none are selected originally, so that wouldn't upgrade nicely.
I also noticed in the x86_64 DLL, it selects Any CPU for Standalone instead of x64 which was originally selected, which is strange (though that might not actually cause issues though). All of the non-Windows meta files seem to be fine after the upgrade though, so it's just those two with issues.
I tried taking those meta files from Unity 6 and adding them back into my Unity 2022 project, and it completely removes the platform settings entirely for those DLLs (possibly because serializedVersion is v3 instead of v2 on those files), so pushing those meta files would leave users on older Unity versions wouldn't have platforms set up by default. Not too sure if you'd prefer to have standalone removed entirely, just let me know though and I can get those updated and pushed!

Hey @BallistiX09, thank you for the test in Unity 6 and all the explanation.
I totally forgot about it, but I actually had setup the ARM64 DLL in Unity 2023.2, which already supports building for Windows ARM.
I'm on a macOS with Apple Silicon, and the inspector for it looks like this:

As you mentioned, for the "editor" it says that the architecture is "Apple silicon", but it's "ARM64" in the .meta file. I guess Unity will do the right thing there, avoiding this DLL on a x86_64 editor and using it on Unity 6 editor on ARM64.
The "Win" platform is changed by the "x86" checkbox in the standalone configurations, which is disabled here.
Until someone tries this in the Unity 6 editor on an ARM64 Windows machine, I think we shouldn't upgrade the serializedVersion. It's possible that it will work in Unity 6 the way it is, and people using Unity 2023.1+ will still be able to export projects with SQLite-net to Windows ARM.
The diff I'd expect there is just like the other ones, just the addition of the WSAPlayer entry.
What do you think?

@gilzoide Sorry about the wait, got a little sidetracked on this! I've updated the ARM64 dll to remove the Windows standalone changes, so all that's been added is UWP support to match the X86 and X64 dlls. Hopefully that should be it all sorted!

Hey @BallistiX09. Don't worry about it, we are all busy with lots of things.
Thank you for the update! I think this is better, we have UWP support in all DLLs, the ARM likely works in Unity 2023.1+, success!
Thanks again for the upgrade, I really appreciate you taking some time to expand this package's support to other platforms.
Cheers \o/


Polishes in preparation of first post 1.0 feature

will rebase #339 after this

had too much in here, should be good now.


[common] common chart duplicated init container

Describe the bug
When at least one entry is made under initContainers when rendering a statefulSet from template, the initContainer is rendered as expected in the resulting helm release but is also doubled under the container section. I crated a couple of files to describe the issue. The files were all in yaml originaly but had to be stored with a .txt file extension because of a Github restriction.
Version of Helm and Kubernetes:
Helm Version:
version.BuildInfo{Version:"v3.10.1", GitCommit:"9f88ccb6aee40b9a0535fcc7efea6055e1ef72c9", GitTreeState:"clean", GoVersion:"go1.18.7"} **Kubernetes Version**:
Client Version: v1.28.3 Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3 Server Version: v1.23.6
Which chart:
[bedag/helm-charts/charts/common]
What happened:
I rendered a template using this minimal values file example-values.txt.
Pleace notice that init-container-1 exists twice in the resulting helm release resulting-helm-release.txt.
What you expected to happen:
I expected a helm release as an output, as I described in expected-helm-release.txt.
init-container-1 should exist in the initContainer section but not in the container section.
How to reproduce it (as minimally and precisely as possible):

Clone this repository
Change working dir to helm-charts/charts/common
Store a copy of example-values.txt to the working dir
render the template using the following command
helm template . -f example-values.txt
You can optionally pipe the result to a file

Anything else we need to know:
The version of the chart is 10.10.1

This issue also occures while rendering deployment templates.
How to reproduce it

Clone this repository
Change working dir to helm-charts/charts/common
Store a copy of example-values-deployment.txt to the working dir
render the template using the following command
helm template . -f example-values-deployment.txt
You can optionally pipe the result to a file


[backport v1.14] push ssf to thread privileged stack to complete stack frame

push ssf to thread privileged stack to complete stack frame
add more than 6 arguments syscall test case

Fixes: #29386.

@andrewboie @ioannisg ping...

@ioannisg please also review this PR, thanks.


install error

Could you tell me how to install libmolgrid into python? Thank you! it's not work when I use "python setup.py install" to install.
running install
running build
running build_py
error: package directory '${CMAKE_CURRENT_BINARY_DIR}/molgrid' does not exist

I have updated the README to include installation instructions.  You will need CUDA installed and the very latest version of openbabel.

Do you know why such a mistake occurs? When i use cmake to install molgrid. Thank you!
Performing C SOURCE FILE Test CMAKE_HAVE_LIBC_PTHREAD failed with the following output:
Change Dir: /home/pxl/localhome/libmolgrid/build/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/make cmTC_ab8c5/fast && /usr/bin/make -f CMakeFiles/cmTC_ab8c5.dir/build.make CMakeFiles/cmTC_ab8c5.dir/build
make[1]: Entering directory '/home/pxl/localhome/libmolgrid/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_ab8c5.dir/src.c.o
/usr/bin/cc   -fPIC -DCMAKE_HAVE_LIBC_PTHREAD   -o CMakeFiles/cmTC_ab8c5.dir/src.c.o   -c /home/pxl/localhome/libmolgrid/build/CMakeFiles/CMakeTmp/src.c
Linking C executable cmTC_ab8c5
/usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_ab8c5.dir/link.txt --verbose=1
/usr/bin/cc -fPIC -DCMAKE_HAVE_LIBC_PTHREAD    CMakeFiles/cmTC_ab8c5.dir/src.c.o  -o cmTC_ab8c5
CMakeFiles/cmTC_ab8c5.dir/src.c.o: In function main': src.c:(.text+0x3e): undefined reference to pthread_create'
src.c:(.text+0x4a): undefined reference to pthread_detach' src.c:(.text+0x5b): undefined reference to pthread_join'
src.c:(.text+0x6f): undefined reference to `pthread_atfork'
collect2: error: ld returned 1 exit status
CMakeFiles/cmTC_ab8c5.dir/build.make:86: recipe for target 'cmTC_ab8c5' failed
make[1]: *** [cmTC_ab8c5] Error 1
make[1]: Leaving directory '/home/pxl/localhome/libmolgrid/build/CMakeFiles/CMakeTmp'
Makefile:121: recipe for target 'cmTC_ab8c5/fast' failed
make: *** [cmTC_ab8c5/fast] Error 2
Source file was:
#include <pthread.h>
void* test_func(void* data)
{
return data;
}
int main(void)
{
pthread_t thread;
pthread_create(&thread, NULL, test_func, NULL);
pthread_detach(thread);
pthread_join(thread, NULL);
pthread_atfork(NULL, NULL, NULL);
pthread_exit(NULL);
return 0;
}
Determining if the function pthread_create exists in the pthreads failed with the following output:
Change Dir: /home/pxl/localhome/libmolgrid/build/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/make cmTC_201ca/fast && /usr/bin/make -f CMakeFiles/cmTC_201ca.dir/build.make CMakeFiles/cmTC_201ca.dir/build
make[1]: Entering directory '/home/pxl/localhome/libmolgrid/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_201ca.dir/CheckFunctionExists.c.o
/usr/bin/cc   -fPIC -DCHECK_FUNCTION_EXISTS=pthread_create   -o CMakeFiles/cmTC_201ca.dir/CheckFunctionExists.c.o   -c /usr/local/share/cmake-3.15/Modules/CheckFunctionExists.c
Linking C executable cmTC_201ca
/usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_201ca.dir/link.txt --verbose=1
/usr/bin/cc -fPIC -DCHECK_FUNCTION_EXISTS=pthread_create    CMakeFiles/cmTC_201ca.dir/CheckFunctionExists.c.o  -o cmTC_201ca -lpthreads
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
CMakeFiles/cmTC_201ca.dir/build.make:86: recipe for target 'cmTC_201ca' failed
make[1]: *** [cmTC_201ca] Error 1
make[1]: Leaving directory '/home/pxl/localhome/libmolgrid/build/CMakeFiles/CMakeTmp'
Makefile:121: recipe for target 'cmTC_201ca/fast' failed
make: *** [cmTC_201ca/fast] Error 2

Looks like it can't find pthreads. What operating system and cmake version are you using?

ubuntu 18.04 cmake version 3.15, and cmake installed by conda, Maybe the error occured by it

I updated the docker container to 18.04 and cmake 3.15 without getting these errors.  Perhaps you could compare to your install to see what is different?
https://hub.docker.com/r/dkoes/gnina


Analyzing the Impact of Auxiliary Loss on MSE in ETTh1: Key Observations from Table 11

I have read Table 11 many times but still don't understand. Without moe and auxiliary loss, the MSE of ETTh1 is 0.37, and without auxiliary loss, the MSE of ETTh1 is 0.368. It seems that the auxiliary loss has the greatest influence. I am confused. Could you help me point it?

Thank you for your interest in our work.
When the auxiliary loss is removed, the MoE layer tends to collapse into a smaller feed-forward network (FFN) due to an imbalance in expert load during training. As a result, the model becomes more akin to a dense model with a smaller FFN, leading to poorer performance compared to a standard dense model.
This phenomenon is explained in Section 4.3:

"We also removed the auxiliary loss from the objective function, retaining only the auto-regressive loss (w/o auxiliary loss) while still using the MoE architecture. This adjustment caused the expert layers to collapse into a smaller FFN during training, as the activation score of the most effective expert became disproportionately stronger without the load balance loss."

Please feel free to contact us if you have any questions.

Thank you very much.


Remove/de-emphasize Submit to OSM button

Discussed this with @mojodna and @willemarcel last week. Submit to OSM button is prominent at the top. Is this function used a lot?
Most users (from our discussions) download the data, clean and process the data offline, and then submit via JOSM. Having the button prominently at the top seems to run the risk of users accidentally selecting the button and pushing to OSM.
Do we want to reconsider this functionality or location of the button?
thoughts @danbjoseph?

I didn't even realize submitting to OSM was a current functionality? I thought POSM replay tool was more technical and required command line tools?

Well, we can't really tell if it actually works at the moment, not much feedback to pushing the button ;)

It was originally intended for pushing to POSM's OSM instance so that subsequent editing could be done against the (local) API. I don't think that workflow is used / useful though.


[NCL-6910] Fix cleanup generic non-hosted repos after promotion

Fix too much copy-pasting which caused that the remote generic-http repo was not accepted as a valid source.

retest this please


About the computation power of "Self-Adaptive Training: beyond Empirical Risk Minimization"

Hello,
Thanks for your sharing and your outstanding contributions for adversarial learning.
I wonder how much computation power is needed to run the default settings, e.g., batch_size=128.
I tried to reproduce your experiment on a server with 2080Ti and memories of 11G, then the server restarted.
Should I make the batch size smaller to reproduce it?
Could you list the corresponding GPU architectures which is able to run it? How many GPU memories are needed.
Thanks & Regards!
Momo

Hi,
Our experiments were conducted on a single 1080Ti GPU which also has 11GB memory.
Besides, the command, nvidia-smi, shows that the memory consumption is 10705MiB.

Thanks.
I think this issue can be closed.
Regards!
Momo


retry launch failures

Retries occur at two levels:

individual API requests, which will be retried in case of connection problems,
which is ~all current failures, I think.
retry the full launch process (new user, etc.) in case of actual failure

TODO:

[x] expose config in helm chart
[x] decide metric updates. Should the launch timing be the user-visible time (including all retries in one time measurement), or time each launch attempt, e.g. adding 'retry' status for failed launches that will be attempted again.

Right now, the launch time metric has:

status = success, retry (failed but will retry), failure (all attempts failed)
retries = number of retries (0 if success/failure on first attempt)
time = duration of latest attempt. Alternately, this could be the total time (i.e. time from first request to resolution), which may be desirable, as it's the time users actually experience.

Thanks. Giving rebase a try. I was able to run this locally.
I think this will help our success rate across hub restarts and occasional hiccups.

This is a clever idea, it looks good to me. One nitpick question about the default time but that shouldn't block on the PR. @minrk you think it is ready to do? I'll hold off to see if @willingc has any other thoughts!


No Ethernet ports

here are my nic info:
Device #1:
Device Type:      ConnectX4
Part Number:      MCX415A-CCA_Ax
Description:      ConnectX-4 EN network interface card; 100GbE single-port QSFP28; PCIe3.0 x16; ROHS R6
PSID:             MT_2140110033
PCI Device Name:  d8:00.0
Base GUID:        506b4b03000fb5c4
Base MAC:         506b4b0fb5c4
Versions:         Current        Available
FW             12.28.2006     12.28.2006
PXE            3.6.0102       3.6.0102
UEFI           14.21.0017     14.21.0017
Status:           Up to date
When i use it for switchml train， got errors like this：
EAL: Selected IOVA mode 'PA'
EAL: No available hugepages reported in hugepages-1048576kB
EAL: Probing VFIO support...
EAL: VFIO support initialized
EAL: WARNING! Base virtual address hint (0x100a94000 != 0x7fe4d3e00000) not respected!
EAL:    This may cause issues with mapping memory into secondary processes
EAL: WARNING! Base virtual address hint (0x1016f5000 != 0x7fe0d3c00000) not respected!
EAL:    This may cause issues with mapping memory into secondary processes
EAL: WARNING! Base virtual address hint (0x102356000 != 0x7fdcd3a00000) not respected!
EAL:    This may cause issues with mapping memory into secondary processes
EAL: WARNING! Base virtual address hint (0x102fb7000 != 0x7fd8d3800000) not respected!
EAL:    This may cause issues with mapping memory into secondary processes
EAL: WARNING! Base virtual address hint (0x103c18000 != 0x7fd4d3600000) not respected!
EAL:    This may cause issues with mapping memory into secondary processes
EAL: WARNING! Base virtual address hint (0x104879000 != 0x7fd0d3400000) not respected!
EAL:    This may cause issues with mapping memory into secondary processes
EAL: WARNING! Base virtual address hint (0x1054da000 != 0x7fccd3200000) not respected!
EAL:    This may cause issues with mapping memory into secondary processes
EAL: WARNING! Base virtual address hint (0x10613b000 != 0x7fc8d3000000) not respected!
EAL:    This may cause issues with mapping memory into secondary processes
F0707 03:14:46.742125 28820 dpdk_master_thread_utils.inc:190] No Ethernet ports
*** Check failure stack trace: ***
@     0x7fe93c7d40cd  google::LogMessage::Fail()
@     0x7fe93c7d5f33  google::LogMessage::SendToLog()
@     0x7fe93c7d3c28  google::LogMessage::Flush()
@     0x7fe93c7d6999  google::LogMessageFatal::~LogMessageFatal()
@     0x7fe94ebd8f01  switchml::InitPort()
@     0x7fe94ebda811  switchml::DpdkMasterThread::operator()()
@     0x7fe95b65dbf4  execute_native_thread_routine
@     0x7fe974ce36db  start_thread
@     0x7fe974a0c61f  clone
switchml cann't find Ethernet ports ，if it has requirements for network card type ？what can i do for this .
when i run switchml program，should i put nic into dpdk status manually ?
(base) root@work4:/p4app-switchML/dev_root/third_party/dpdk/usertools# ./dpdk-devbind.py -s
Network devices using DPDK-compatible driver
0000:86:00.0 'Ethernet Controller X710 for 10GbE backplane 1581' drv=igb_uio unused=i40e
0000:d8:00.0 'MT27700 Family [ConnectX-4] 1013' drv=igb_uio unused=mlx5_core

Hi,
if you want to use the ConnectX 4 NIC with DPDK, there is no need to bind the NIC to the igb_uio driver, as the Mellanox driver (mlx5_core) is already compatible.
You should bind the NIC back to the mlx5_core driver, and make sure that the extra_eal_options value in the configuration file has the correct PCIe identifier of your NIC, in your case:
extra_eal_options = -w 0000:d8:00.0
Let us know if this solves the issue.

thanks， i have solved this problem successfully。
i have already changed my network card and i'm using MLX5 now，just add arguement "MLX5=1" when i run "make"


error_types.hpp

The file should have been error_types.hpp since the namespace is error_types

Get this in please


Circular dependency warning despite dynamic import

Describe the bug
Suppose I have two files like these:
// one.mjs
console.log("Hello from one.mjs");

setTimeout(() => {
	import("./two.mjs");
}, 500);

// two.mjs
import "./one.mjs";

console.log("Hello from two.mjs");

When I ssrLoadModule("./one.mjs"), I get the following output:
Hello from one.mjs
Hello from one.mjs
Hello from two.mjs
Circular dependency: one.mjs -> /two.mjs -> /one.mjs -> /two.mjs

That is, one.mjs is evaluated twice before two.mjs is evaluated and I get a circular dependency warning. I'm aware of the limitations and I know there is a pull request to allow circular dependencies in SSR.
But in this case I think the evaluation of one.mjs should have been completed before two.mjs is imported due to the timeout. So this shouldn't count as a circular dependency but Vite disagrees.
Reproduction

Clone this repo
Install dependencies with npm ci
Run with npm start

System Info
System:
    OS: Linux 5.4 Linux Mint 20.2 (Uma)
    CPU: (8) x64 Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz
    Memory: 370.95 MB / 15.53 GB
    Container: Yes
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 12.22.1 - /usr/local/bin/node
    Yarn: 1.22.10 - ~/.npm-global/bin/yarn
    npm: 7.19.1 - ~/.npm-global/bin/npm
  Browsers:
    Chrome: 91.0.4472.164
    Firefox: 90.0
  npmPackages:
    vite: ^2.4.2 => 2.4.2

Used Package Manager
npm
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.

Bug confirmed. Not fixed by #3950

Workaround
Import one.mjs like this:
await server.ssrLoadModule("/one.mjs");

This is probably by design. Importing one.mjs is nonsensical. The URL argument of ssrLoadModule is not the same as path.resolve nor should you expect it to be.

The URL argument of ssrLoadModule is not the same as path.resolve or require nor should you expect it to be.

Thanks for pointing out, this probably deserves a line or two in the docs.
I can confirm that await server.ssrLoadModule("/one.mjs"); workaround solves one.mjs being evaluated twice but the circular dependency warning remains.

but the circular dependency warning remains

Fixed by #3950

closing as pr got merged and after test of reproduction it seems to be printing as expected according to conversation


Concurrency: Guard TG state with a mutex even with cooperative executor

SWIFT_STDLIB_SINGLE_THREADED_CONCURRENCY just means that the global executor is cooperative, but it doesn't mean that the target platform is always single-threaded. For example, on wasm32-unknown-wasip1-threads, the global executor is cooperative, but users can still set up their own TaskExecutor with multiple threads.
This patch guards the TaskGroup state with a mutex even with a cooperative executor by respecting threading package instead. This change effectively affects only wasm32-unknown-wasip1-threads.

@swift-ci smoke test

@swift-ci test WebAssembly

I added your comment in the PR as a source comment, keeping track of the "why" of those #if is very tricky so we need to document such in source IMHO, pending some other improved refactoring of the runtime that would make this less difficult to manage/understand.
LGTM though, merging

@kateinoigakukun do we want this on 6.0 as well? If so please prepare a PR and ping me :)

Thanks! Yes, we need this in 6.0 too

@swift-ci smoke test


Automatic Release generation and tagging

In gitlab by @sylvaingaudan on Apr 26, 2017, 12:16

In gitlab by @sylvaingaudan on Apr 26, 2017, 14:01
added ~1918909 label

In gitlab by @sylvaingaudan on Apr 28, 2017, 13:46
changed milestone to %4

In gitlab by @sfalquier on May 9, 2017, 09:13
added ~1918367 and removed ~1918909 labels

In gitlab by @sfalquier on May 12, 2017, 11:22
added ~1918368 and removed ~1918367 labels

In gitlab by @sfalquier on May 12, 2017, 11:22
assigned to @sfalquier

In gitlab by @sfalquier on May 15, 2017, 13:44
removed ~1918368 label

In gitlab by @sfalquier on May 15, 2017, 13:44
closed


Progress?

@gunnarmorling @jpechane  This looks like it could potentially solve our current requirement to connect Debezium with HyperSQL/HSQLDB. I see an open PR with some productive conversation, but nothing else. Will this be pursued further by the team, or is there another we can use Debezium with HyperSQL/HSQLDB?

@PrimeDominus Chris Cranford is now actively pursuing the connector implementation. You can get in touch with him via https://debezium.zulipchat.com/

Hi @PrimeDominus, you can see the first iteration of the connector in PR #3.


No Developer directory

I have Xcode installed but don't have the Developer directory:

$ ls ~/Library/Developer
ls: /Users/nicolas/Library/Developer: No such file or directory

Should I create it?
I'm running mojave.

Xcode needed to be started at least one time for the directory to be created.


Fix errors prototype

Will resolve #281

  Buttons for error prototype don't work now that we removed ability to render links as buttons


Make drone-exec entrypoint into an API

This PR enables other applications to use drone-exec as a library instead of shelling out to it. It takes most of the logic out of package main and puts it in package exec.
CI is failing due to an external dependency's API being updated. Happy to resolve that however is best (e.g., in a separate PR).

@sqs looks great. We may need to get https://github.com/drone/drone-exec/pull/5 merged first since it has a Docker fix that we'll need for a passing build. Hopefully that will be ready to merge tomorrow.
I've also setup a standard CLA for Drone's core projects. https://cla-assistant.io/drone/drone-exec

 You should sign our Contributor License Agreement in order to get your pull request merged.

@sqs you should use rebase instead of merge to update your feature branches :)

LGTM

@tboerger I usually use rebase, but I tried clicking the new GitHub "Update branch" button, which resulted in a merge. :) I will re-push.

@sqs just merged a couple of dependent pull requests to fix the failing build. There is a minor conflict that needs to be resolved and then I can merge this. Hope you don't mind, thanks!

Rebased on latest master and pushed. Thanks!

@sqs thanks for the patch


[QUESTION] Nothing happens after installation; there is no apparent way to configure the integration

Describe the bug
The documentation states:

Simply add a new "integration" and look for "SmartThinQ LGE Sensors" among the proposed ones and
follow setup worflow.
Important: use your country and language code: SmartThinQ accounts are associated with a specific locale,
so be sure to use the country and language you originally created your account with.
Reference for valid code:
Country code:
ISO 3166-1 alpha-2 code
Language code:
ISO 639-1 code

What does this mean? What "setup worflow [sic]" is it referring to? I searched for and installed the SmartThinQ LGE Sensors integration in HACS. But nothing then happened. The integration appears in the relevant pane of HCAS, but I was not presented with, nor do I see anywhere, a configuration panel where I can enter the country and language code. No LG sensor entities appear, but that is to be expected, since there is no way to configure the integration.
The documentation expressly says not to modify the configuration.yaml. For want of anything else to do, I nonetheless tried editing that file. These two lines appeared in the HA log file:

Integration configuration using configuration.yaml is not supported. Please configure integration from HA user interface
10:37:03 PM – SmartThinQ LGE Sensors (WARNING)
The 'smartthinq_sensors' option is deprecated, please remove it from your configuration
10:37:03 PM – SmartThinQ LGE Sensors (WARNING)

So I removed the lines
Expected behavior
If applicable, a clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment details:

Environment (HASSIO, Raspbian, etc): HassOS 4.12
Home Assistant version installed: 0.114.3
Component version installed: 0.5.5
Last know working version: n/a
LG device type and model with issue: n/a
LG devices connected (list): n/a

Output of HA logs
Paste the relavant output of the HA log here.
The only log entry is:

2020-08-21 22:17:28 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for smartthinq_sensors which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant.

Additional context
Add any other context about the problem here.

Clearing browser cache worked for me.

I close this issue, seems solved and outdated


github enterprise provider

This fixes github enterprise support originally added in #197 and closes #144 and #248

@jehiah I can confirm that this implementation resolves #248 , thanks!

@rremer 🎉  🎺  🎈  yay! thanks for the confirmation 💯 !


Extending with own components?

As I see from the heml-elements/index.js there is no mechanism for plugging in additional components. That limits usability and, I believe, prevents real world use in large projects.
I understand that SparkPost would be having trouble allowing custom JS to be run within parse or render phases on their servers, however adding extension mechanism would have grand effect on spread of HEML as open standard.

Hi @shokurov! Thanks for checking out HEML :) It turns out you can pass in your own elements in the options object you pass to the exported heml function:
const heml = require('heml')
heml(`<heml>...</heml>`, { elements: [ /* elements go here */ ] })

There isn't much documentation on custom elements yet (that will be coming soon I believe), but I they need to be created using the createElement function found in @heml/utils.  I would look at the elements in @heml/elements for which attributes are accepted.

Thanks for pointing out!
This definitely needs a bit more documentation..
Please, could you clarify couple more things:

do components have to utilise React or is it just convenience that you use JSX in internal components?
is there a description of

I'm not sure about the first question, I'll defer to @avigoldman on that. I imagine you do need to use React, though you don't need JSX.
For the Style element, you can find the docs here: https://heml.io/docs/elements/style/ You use it just like a regular HTML style tag.

For the Style element, you can find the docs here: https://heml.io/docs/elements/style/ You use it just like a regular HTML style tag.

Thank you. I think I mixed it up, looking at the code fragment utilising

Oh I'm sorry, you were looking for the programmatic interface. I misunderstood.


Alternate input sources YAML doesn't work when flag includes alternate name

Alternate names are described here: https://github.com/urfave/cli#alternate-names
Support for YAML is described here: https://github.com/urfave/cli#values-from-alternate-input-sources-yaml-toml-and-others
When any alternate source flag includes an alternate name, the alternate source input doesn't function as it should (i.e. it doesn't use the alternate input source data).
Code to reproduce:
package main

import (
    "fmt"
    "os"

    "github.com/urfave/cli/altsrc"
    "gopkg.in/urfave/cli.v1"
)

func main() {
    app := cli.NewApp()

    flags := []cli.Flag{
        /*
            // OK
            altsrc.NewIntFlag(cli.IntFlag{Name: "test", Value: -1}),
            altsrc.NewStringFlag(cli.StringFlag{Name: "flag", Value: "default"}),
        */

        // NG #1
        altsrc.NewIntFlag(cli.IntFlag{Name: "test, t", Value: -1}),
        altsrc.NewStringFlag(cli.StringFlag{Name: "flag", Value: "default"}),

        /*
            // NG #2
            altsrc.NewIntFlag(cli.IntFlag{Name: "test", Value: -1}),
            altsrc.NewStringFlag(cli.StringFlag{Name: "flag, f", Value: "default"}),

            // NG #3
            altsrc.NewIntFlag(cli.IntFlag{Name: "test, t", Value: -1}),
            altsrc.NewStringFlag(cli.StringFlag{Name: "flag, f", Value: "default"}),
        */

        cli.StringFlag{Name: "load, l"},
    }

    app.Action = func(c *cli.Context) error {
        fmt.Println("yaml ist rad")
        fmt.Printf("load: %s\n", c.String("load"))
        fmt.Printf("test: %d\n", c.Int("test"))
        fmt.Printf("flag: %s\n", c.String("flag"))
        return nil
    }

    app.Before = altsrc.InitInputSourceWithContext(flags, altsrc.NewYamlSourceFromFlagFunc("load"))
    app.Flags = flags

    app.Run(os.Args)
}

Test file contents:
iMac:buggy chris$ cat buggy.txt
test: 123
flag: excellent!
iMac:buggy chris$

Output:
iMac:buggy chris$ go run buggy.go --load buggy.txt
yaml ist rad
load: buggy.txt
test: -1
flag: excellent!
iMac:buggy chris$

Have not had a chance to debug this as of yet, but documenting it for now in case others encounter this problem.

Thanks for the detailed bug report @wcwynn ! It does look like there are a few places where altsrc assumes that the defined flags only have one "name" specified.

FYI: this also affects TOML.

Hiya! There's a known issue with the current implementation of the CLI, where altsrc is generally clunky and poorly documented. My current idea is that I'm going to move all of the altsrc functionality into the main package in some way, and that's how all of the "altsrc is weird and different???" issues people are having will get resolved. I'm tracking that work here => https://github.com/urfave/cli/issues/833


CLOUDP-184900: Updating required flags to match docs for atlas backup resttore start

CLOUDP-184900

[x] I have signed the MongoDB CLA
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added any necessary documentation in document requirements section listed in CONTRIBUTING.md (if appropriate)
[ ] I have addressed the @mongodb/docs-cloud-team comments (if appropriate)
[ ] I have updated test/README.md (if an e2e test has been added)
[ ] I have run make fmt and formatted my code

Further comments

@colm-quinn any update here?