Auto-indent in html mode is problematic

If a brew has some html container (e.g. <div> ... </div>) and a new line is entered (e.g. breaking a paragraph into two) then the a TAB character is added at the front of the line.
Unfortunately, this clashes with markdown processing of that content, with either the line now being rendered as within <code>...</code>, or unexpected indenting of bullet point lists.
This is fixable in editing of course — just delete the unnecessary TAB. Annoying and tedious, also not always obvious for the case of bullet lists.
Recommendation: turn off the auto-indent option for html mode.

I agree with this. :+1: Probably an easy PR if someone wants to find the relevant CodeMirror option.

This was the image we used to indicate a tabbed space.

It was not well received by the community. "Too much clutter".
It might work better as a 1 character wide arrow, with the rest of the width being transparent.
Would also be good to have some kind of toggle for "show invisibles" in the snippet bar, possibly as a toggle button adjacent to the undo/redo buttons. (We could later put other editor-ui-toggle widgets there too, e.g. something to invoke find/replace).

Previous PR that did this for reference: https://github.com/naturalcrit/homebrewery/pull/1819

I think this might be the line to change auto-indent (and any press of tab) to spaces: https://github.com/naturalcrit/homebrewery/blob/9a60d60b6dc21411dbf8fcd628516b5a12adefbc/shared/naturalcrit/codeEditor/codeEditor.jsx#L100

No, the behavour of the editor inserting a tabs when the TAB is pressed is not the issue.
It's the insertion of a TAB character when the ENTER key is pressed which is the problem.
A possible solution: https://discuss.codemirror.net/t/how-to-remove-indentation-on-newline/1538

Q: Does anyone know how to remove indentation on newline event?
A: Bind Enter to a command like cm => cm.replaceSelection("\n") rather than the default, the newlineAndIndent command.

This might also be relevant: https://github.com/codemirror/codemirror5/issues/988#issuecomment-14915679

Q: When using the "cm.replaceSelection"-solution, it is no longer possible to indent code by marking multiple lines and pressing "Tab". [Which is very handy for indenting a block of bullet points.] Is there a workaround or code sample that shows how to keep that (very useful) functionality, while still enabling insertion to be spaces instead of a tab?
A: > Sure there is! A bit of fiddling with the API:
function betterTab(cm) {
  if (cm.somethingSelected()) {
    cm.indentSelection("add");
  } else {
    cm.replaceSelection(cm.getOption("indentWithTabs")? "\t":
      Array(cm.getOption("indentUnit") + 1).join(" "), "end", "+input");
  }
}

CodeMirror.fromTextArea(document.getElementById("the-editor"), {
  extraKeys: { Tab: betterTab }
});

And this too, to handle Shift-TAB to effect un-indenting (when deconstructing deeply nested lists).

Perhaps instead of removing auto-indent completely, it might be worth just limiting it to auto-indent to match the previous-line indentation? Obviously in your example where it indents inside of the HTML divs is obnoxious, but I would still like to keep auto-indent for Markdown lists, for example. Is there a way we can do that?

No, the behavour of the editor inserting a tabs when the TAB key is pressed is not the issue.

I do think this still reveals a related issue though. The tab appears as wide as 2 spaces, but is being parsed as 4 for the purposes of Markdown, which is why the bulleted lists are showing up oddly in your example above. In addition to handling auto-indent, we could potentially replace tabs with spaces to address confusion for users ("why is this bulleted list turning into code but this one remains a list? The whitespace looks the same!")

Yes, matching previous line indentation works nicely, and inserting indents as spaces would also work (but insert a TAB if the TAB key is pressed and no text is currently selected)

press TAB with no text selected → insert a TAB character
press TAB while text is selected → indent the selected lines one level
press SHIFT-TAB while text is selected → un-indent the selected lines one level
press ENTER → insert \n, and indent to match the now previous line indentation

With (4), the indent should likely match the characters used to indent the previous line.
Or something like that. I'm sure I'm missing something.


Mobile friendly responsive design

Right now, if the browser is too narrow, the table gets a bit confused:

Currently, all non-critical UI fixes are on hold. The're likely to get fixed by #13, which is currently blocked by a missing feature in the vaadin-grid-flow upstream.

Vaadin flow grid correctly shows a scrollbar on small screens.


Open too many database connection

I install this plugin on my cluster(about ~200 instance) and got about 8000+ database connection. :-/

I'm hoping to be able to rewrite this plugin soon. Please reply to this issue if it continues to occur after.


tests: describe and implement tests suite

To get stabilization and reliability, we need tests.

We need to define and describe what we expect and what we support
We need to write tests scenario doing expected stuff

Better is to automate that with actions here.

I'd like to have at least a full integration test, looking a bit like this:

Set up everything: some 0-dbs (can be local), metastor, configs, monitor, and 0-db-fs

Limit the size of the zdbfs-data dir to 5GiB in the monitor config

Write 50 GiB worth of data on the filesystem

Monitor size of local 0-db data namespace, and check that it stays within the configured 5GiB limit
Untill this feature is implemented, size will become larger but should eventually settle below 5GiB

Wait for 15 or so minutes after everything is written (so 0-db can upload the dirty data file if there is one)
Simulate a node crash by killing the filesystem itself (0-db-fs), and removing the backing 0-db (the one used by 0-db-fs directly). Also kill the monitor
Set up the local 0-db again (simulate setup on a new node)
Start 0-db-fs, verify that it has a clean (i.e. fs is empty) state
Start monitor

Monitor should rebuild the index files of 0-db-fs, verify this

Verify that all files can be seen as expected
Verify that the content of the files is readable and correct (md5sum?)
Simulate a backend data storage loss (withing the limits of the configured redundancy) by killing one of the 0-db serving as storage backend
Start and add a new 0-db to the zstor config
Check and verify that data stored on the removed 0-db is being rebuild on live ones
Wait for rebuild to finish
Simulate more storage node loss, such that all data should still be readable according to the new zstor config after the rebuild, but not according to the old one. Example: if redundancy in zstor is set as 2 data 1 parity shards, the previous test will have removed 1 0-db and a new one is added. Now this test case will remove another one of the ORIGINAL 0-dbs. As a result, the data will be on 1 of the original and the new 0-db. This means there are 2 live shards, sufficient to have all the data readable, however, there is only 1 original 0-db left, so if the repair somehow failed the data will be lost.
Again verify that all data is still correct and reachable

The above should be able to test all essential features already, and reasonably isolated (i.e if there is an issue, we should easily be able to identify what is not working based on which part of the test fails). For data, about 50GiB should be suffcient to already get a good idea of performance and stability. It would also be interesting to see if the solution can handle different scenarios, such as:

a single 50 GiB file
a large amount of small files totalling 50GiB when summed (small being a couple KiB each)
Something like a postgress database using 50GiB of backing storage.

For writing, we know there is a potential issue in the current flow, in that 0-stor can be called multiple times concurrently which might lead to index corruption. We should test both slow writing (therefore removing this issue), and fast writing (so we can see the actual real impact of this issue).
The above should already provide a large amount of data regarding stability and performance, and if this manages to work bug free we have a solid foundation / first alpha version I'd say

Simulate a node crash by killing the filesystem itself (0-db-fs), and removing the backing 0-db (the one used by 0-db-fs directly). Also kill the monitor
Set up the local 0-db again (simulate setup on a new node)
Start 0-db-fs, verify that it has a clean (i.e. fs is empty) state
Start monitor

Monitor should rebuild the index files of 0-db-fs, verify this

Verify that all files can be seen as expected

In this workflow, do you expect to start the filesystem on a fresh 0-db then restore 0-db content from backup ?

Yeah, although the reverse (restore index with monitor first) should also work right? Need to identify which one is best.
And indeed, start filesystem on completely fresh 0-db

I'm doing some local test following scenarios, and first impression I get out:

Consistency seems good

0-db data stay at ~5 GB, file are deleted and restored correctly on demand
Size goes up to 7 GB before detection delete files
md5sum of files are consistent across multiple test

Performance:

Writing 8 GB file using dd at 53 MB/s
Reading the 8 GB file at ~35 MB/s (with mostly all parts fetched from backend)

In comparaison, disabling hooks, to keep everything locally without any zstor usage:

Writing:<PHONE_NUMBER> bytes (8.4 GB, 7.8 GiB) copied, 133.118 s, 63.0 MB/s
Reading (md5sum): 8000M in 22 sec (~ 363 MB/s)

Test made using distant zdb backend (same LAN, 1 Gbps link).

I've done quite a bit of non systematic testing of storing data, removing the zdb data files, and comparing checksums when the files are restored. My method for simulating node failure, in case it's helpful, is adding an iptables rule like follows, targeting the port number:
sudo iptables -I OUTPUT -p tcp -d [insert IP] -j REJECT --reject-with tcp-reset --dport [insert port]

Then remove it when done with -D instead of -I.
From what I've seen, zstor reliably rebuilds data files with only two of three of the used backend nodes available, using default redundancy settings. I've played a bit with tweaking the redundancy settings and results are as expected.
I also noticed in the latest version that zstor no longer waits on a timeout when a node it's trying to retrieve from is unreachable :slightly_smiling_face:


[Bug] Lack of requiring re-authentication causes domain lockouts (a "story")

TL;DR
Azure DevOps plugin does not popup a box to re-authenticate. My hunch is it silently fails BUT it continues to try, thus locking your domain account every X minutes.
I want to tell you a story about a week long adventure with the IT department trying to track down why my domain account kept getting locked every 30-60 minutes. The following is an attempt to write a bug ticket a different way (with an actual "story"). Note that I do like the plugin and am now using it more after this incident :).
Ladies and gentlemen: the story you are about to hear is true. The names have not been changed because my profile is public. And my middle name is actually Josh.
Note: This was just me breaking up the monotony of the day with a funny story that led to my discovery of this issue. If you have time to read it, I hope it brightens your day. If not the TL;DR and summary after the story should suffice for this ticket.
"User Error"

A couple of months ago, Josh tried out a plugin called Azure DevOps. "Cool" he thought to himself, "I don't have to login to TFS to attach ticket numbers to my commits anymore!" he said excitedly. But Josh soon fell back into his old habits of opening TFS and copying the ticket number / message. He forgot all about the plugin.
Fast forward two months, it's time for the dreaded 90 day rotating domain password change. He changed his password like a good employee. Little did Josh know what was coming - he tried to login to the VPN.
Locked out.
"Hey IT, I think my account is locked for some reason, can you unlock me?" He asked, mildly frustrated. "Sure thing, you're unlocked" they said. Josh went on with his coding.
An hour later he needs to check something in TFS, so he attempts to open it.
Locked out.
"Hey IT, sorry to bother you again but I can't login to TFS - keeps saying invalid username / password on Edge" (yes, I've converted to Edge b/c it rocks, good job guys!). They responded, "Huh, that's weird you are locked out again - did you forget your password?" they prodded.
"How dare they assume I forgot my password!" his ego exclaimed to Kingston the cat who was perched up in his cat castle sleeping. "Keep your ego in check Josh, they're just covering their bases" he thought to himself. Josh politely responded "I'm an elevated power user, I don't really forget my domain password. I've been confirming it is typed correctly just to make sure."
They unlocked him and he went on about his business.
An hour later, Josh leaves for lunch. When he comes back to try and login to his computer, he's locked out of the computer all together. "Hey IT, sorry to bother you again - I don't understand what is going on but I'm locked out again. I didn't even try to authenticate with anything - I've been gone to lunch" he queried. They unlock him and he goes about his business for a little while.
Fast forward 7 days. The madness of the "week of lockouts" has worn Josh out. It's been a constant battle with IT. Constant "unlock" messages. He thinks they need to fix their domain - it's obviously not his problem. He's checked his scripts. He's checked his code. Josh knows he would never write code that used his domain credentials for anything because that is a terribly bad practice.
It's Wednesday - Sprint Review. Josh has to get on a call with 30 others (including the CTO and director of IT) and show his work off for the week. "Josh, are you ready?" his co-worker says. "I'm on the phone today guys, sorry no video. Locked out of my computer again - I messaged the IT person but I think they are away" Josh says, defeated.
His co-worker messages him on private chat a few minutes later, "Lol, the CTO and director have personally requested to make sure your account gets unlocked / fixed". "Nice, maybe we can get this thing resolved once and for all" Josh said out loud, staring at his cat as if he could understand him.
So they get to work. IT remotes into his computer for the third time. They check stored passwords in Edge and noticed the TFS password is OLD. "This could be it guys, this has to be it" Josh exclaimed excitedly. He updates his password to the new password. He closes Edge, re-opens and low-and-behold.
Locked out.
"Damn't, I just don't understand" he says to IT. They respond "Are you sure you don't have any other apps or code that try to login?"
Then Josh remembers.
"The Azure DevOps plugin in Rider" he whispers manically, eyes widening as he realizes it was...
User Error

I updated my credentials by clicking the tiny button above the commit message.
So far I've been about 20 hours without a lockout. The longest time yet.
Kingston is still sitting in his cat castle not caring.
The day is beautiful. The birds are chirping.
Expected
When authentication fails, it should popup a box in rider to re-authenticate (not silently fail over and over again).
Actual
Madness. Hair loss. Constant domain locking. User errors :)
Azure DevOps version 1.161.1
TFS Version: 16.131.27701.1
Rider Version: 2021.1.2
Sanity: Questionable
Hair: Lost

Thanks a lot for your detailed explanation, and for the story.
This is really an issue that bothers many users, and we'll try to allocate some resources to fix it.

Also, how do you even change the authentication credentials in the plugin? I can't bring up the commit dialog, because no changes are detected, because I can't authenticate.

@ryantheleach at least on PyCharm 2021.2.3 and Azure DevOps plugin 1.162.0, you can go to Settings > Version Control > Azure DevOps Services / TFS and Change Credentials.
Still, a pop up or a clearer message on how to change/update credentials should show up. It still took me about 30 minutes and  some disable/enable and uninstall/reinstall until I remembered that configuration section in the Settings.
@jackjwilliams +1. I had similar issues in my organization although IT reached out to me directly to know why I was constantly failing to authenticate.

I just encountered the same issue. Took me several days to track down. Eventually I managed to trace it back to the Rider process.
Can confirm that there are numerous, repeated, silent failures in the idea.log that look like this, every 5 minutes on the second:
Log + Stacktrace

2024-01-23 11:59:10,341 [84020119]   INFO - com.microsoft.alm.plugin.events.ServerPollingManager - Timer fired
2024-01-23 11:59:10,341 [84020119]   INFO - com.microsoft.alm.plugin.events.ServerEventManager - triggering ALL events
2024-01-23 11:59:10,341 [84020119]   INFO - com.microsoft.alm.plugin.events.ServerEventManager - triggering event: BUILDS_CHANGED
2024-01-23 11:59:10,341 [84020119]   INFO - com.microsoft.alm.plugin.idea.common.utils.VcsHelper - getRepositoryContext: cache hit: C:/Users/<USER>/Repository/<REPO>
2024-01-23 11:59:10,341 [84020119]   INFO - com.microsoft.alm.plugin.operations.BuildStatusLookupOperation - BuildStatusLookupOperation created.
2024-01-23 11:59:10,341 [84020119]   INFO - com.microsoft.alm.plugin.events.ServerEventManager - triggering event: PULL_REQUESTS_CHANGED
2024-01-23 11:59:10,341 [84020119]   INFO - com.microsoft.alm.plugin.events.ServerEventManager - triggering event: WORK_ITEMS_CHANGED
2024-01-23 11:59:10,342 [84020120]   INFO - com.microsoft.alm.plugin.operations.BuildStatusLookupOperation - BuildStatusLookupOperation.doWork()
2024-01-23 11:59:10,342 [84020120]   INFO - com.microsoft.alm.plugin.operations.BuildStatusLookupOperation - getServerContext: url=https://<...>
2024-01-23 11:59:10,342 [84020120]   INFO - com.microsoft.alm.plugin.operations.BuildStatusLookupOperation - getServerContext: forcePrompt=false
2024-01-23 11:59:10,342 [84020120]   INFO - com.microsoft.alm.plugin.operations.BuildStatusLookupOperation - getServerContext: allowPrompt=false
2024-01-23 11:59:10,342 [84020120]   INFO - com.microsoft.alm.plugin.operations.BuildStatusLookupOperation - getServerContext: creating GIT context
2024-01-23 11:59:10,342 [84020120]   INFO - com.microsoft.alm.plugin.context.ServerContextManager - AuthenticatedInfo found for url https://<...>
2024-01-23 11:59:10,342 [84020120]   INFO - com.microsoft.alm.plugin.idea.common.services.HttpProxyServiceImpl - useHttpProxy: false
2024-01-23 11:59:10,381 [84020159]   WARN - org.apache.http.impl.auth.HttpAuthenticator - NEGOTIATE authentication error: No valid credentials provided (Mechanism level: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt))
2024-01-23 11:59:10,400 [84020178]   WARN - com.microsoft.alm.plugin.context.rest.VstsHttpClient - sendRequest error: 401 : Unauthorized
2024-01-23 11:59:10,400 [84020178]   WARN - com.microsoft.alm.plugin.context.ServerContextManager - validate: failed for Git remote url: https://<...>
2024-01-23 11:59:10,400 [84020178]   WARN - com.microsoft.alm.plugin.context.ServerContextManager - validate
com.microsoft.alm.plugin.context.rest.VstsHttpClient$VstsHttpClientException: Unauthorized
	at com.microsoft.alm.plugin.context.rest.VstsHttpClient.sendRequest(VstsHttpClient.java:38)
	at com.microsoft.alm.plugin.context.ServerContextManager$Validator.getVstsInfoForGit(ServerContextManager.java:769)
	at com.microsoft.alm.plugin.context.ServerContextManager$Validator.validateGitUrl(ServerContextManager.java:749)
	at com.microsoft.alm.plugin.context.ServerContextManager.validateServerConnection(ServerContextManager.java:203)
	at com.microsoft.alm.plugin.context.ServerContextManager.validateServerConnection(ServerContextManager.java:191)
	at com.microsoft.alm.plugin.context.ServerContextManager.createContextFromGitRemoteUrl(ServerContextManager.java:372)
	at com.microsoft.alm.plugin.operations.Operation.getServerContext(Operation.java:205)
	at com.microsoft.alm.plugin.operations.BuildStatusLookupOperation.doWork(BuildStatusLookupOperation.java:149)
	at com.microsoft.alm.plugin.operations.OperationExecutor$1.run(OperationExecutor.java:56)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:840)
2024-01-23 11:59:10,415 [84020193]   WARN - org.apache.http.impl.auth.HttpAuthenticator - NEGOTIATE authentication error: No valid credentials provided (Mechanism level: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt))
2024-01-23 11:59:10,428 [84020206] SEVERE - com.microsoft.alm.plugin.context.ServerContextManager - validate: failed for parseResult ServerUrl = https://<...> CollectionUrl = https://<...> CollectionName = tfs_maincollection ProjectName = <NAME> RepoName = <NAME> AccountName = <...>
2024-01-23 11:59:10,428 [84020206]   WARN - com.microsoft.alm.plugin.context.ServerContextManager - validate
com.microsoft.alm.client.model.VssResourceNotFoundException: API resource location 225f7195-f9c7-4d14-ab28-a83f7ff77e1f is not registered on https://<...>. HTTP 401 Unauthorized
	at com.microsoft.alm.client.AlmHttpClientBase.createTarget(AlmHttpClientBase.java:138)
	at com.microsoft.alm.client.AlmHttpClientBase.createRequest(AlmHttpClientBase.java:463)
	at com.microsoft.alm.client.AlmHttpClientBase.createRequest(AlmHttpClientBase.java:334)
	at com.microsoft.alm.sourcecontrol.webapi.GitHttpClientBase.getRepository(GitHttpClientBase.java:9184)
	at com.microsoft.alm.plugin.context.ServerContextManager$Validator.validate(ServerContextManager.java:938)
	at com.microsoft.alm.common.utils.UrlHelper$HttpGitUrlParser.tryParse(UrlHelper.java:593)
	at com.microsoft.alm.common.utils.UrlHelper.tryParse(UrlHelper.java:497)
	at com.microsoft.alm.plugin.context.ServerContextManager$Validator.validateGitUrl(ServerContextManager.java:753)
	at com.microsoft.alm.plugin.context.ServerContextManager.validateServerConnection(ServerContextManager.java:203)
	at com.microsoft.alm.plugin.context.ServerContextManager.validateServerConnection(ServerContextManager.java:191)
	at com.microsoft.alm.plugin.context.ServerContextManager.createContextFromGitRemoteUrl(ServerContextManager.java:372)
	at com.microsoft.alm.plugin.operations.Operation.getServerContext(Operation.java:205)
	at com.microsoft.alm.plugin.operations.BuildStatusLookupOperation.doWork(BuildStatusLookupOperation.java:149)
	at com.microsoft.alm.plugin.operations.OperationExecutor$1.run(OperationExecutor.java:56)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:840)
Caused by: javax.ws.rs.NotAuthorizedException: HTTP 401 Unauthorized
	at org.glassfish.jersey.client.JerseyInvocation.convertToException(JerseyInvocation.java:1056)
	at org.glassfish.jersey.client.JerseyInvocation.translate(JerseyInvocation.java:859)
	at org.glassfish.jersey.client.JerseyInvocation.access$500(JerseyInvocation.java:75)
	at org.glassfish.jersey.client.JerseyInvocation$2.completed(JerseyInvocation.java:816)
	at org.glassfish.jersey.client.ClientRuntime.processResponse(ClientRuntime.java:203)
	at org.glassfish.jersey.client.ClientRuntime.access$200(ClientRuntime.java:61)
	at org.glassfish.jersey.client.ClientRuntime$2.lambda$response$0(ClientRuntime.java:154)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:288)
	at org.glassfish.jersey.client.ClientRuntime$2.response(ClientRuntime.java:154)
	at org.glassfish.jersey.apache.connector.ApacheConnector.apply(ApacheConnector.java:480)
	at org.glassfish.jersey.client.ClientRuntime.lambda$null$3(ClientRuntime.java:163)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:288)
	at org.glassfish.jersey.client.ClientRuntime.lambda$createRunnableForAsyncProcessing$4(ClientRuntime.java:139)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	... 3 more
2024-01-23 11:59:10,448 [84020226]   WARN - org.apache.http.impl.auth.HttpAuthenticator - NEGOTIATE authentication error: No valid credentials provided (Mechanism level: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt))
2024-01-23 11:59:10,460 [84020238] SEVERE - com.microsoft.alm.plugin.context.ServerContextManager - validate: failed for parseResult ServerUrl = https://<...>/ CollectionUrl = https://<...>/tfs/ CollectionName = tfs ProjectName = tfs_maincollection RepoName = <...> AccountName = <...>
2024-01-23 11:59:10,460 [84020238]   WARN - com.microsoft.alm.plugin.context.ServerContextManager - validate
com.microsoft.alm.client.model.VssResourceNotFoundException: API resource location 225f7195-f9c7-4d14-ab28-a83f7ff77e1f is not registered on https://<...>/tfs/. HTTP 401 Unauthorized
	at com.microsoft.alm.client.AlmHttpClientBase.createTarget(AlmHttpClientBase.java:138)
	at com.microsoft.alm.client.AlmHttpClientBase.createRequest(AlmHttpClientBase.java:463)
	at com.microsoft.alm.client.AlmHttpClientBase.createRequest(AlmHttpClientBase.java:334)
	at com.microsoft.alm.sourcecontrol.webapi.GitHttpClientBase.getRepository(GitHttpClientBase.java:9184)
	at com.microsoft.alm.plugin.context.ServerContextManager$Validator.validate(ServerContextManager.java:938)
	at com.microsoft.alm.common.utils.UrlHelper$HttpGitUrlParser.tryParse(UrlHelper.java:600)
	at com.microsoft.alm.common.utils.UrlHelper.tryParse(UrlHelper.java:497)
	at com.microsoft.alm.plugin.context.ServerContextManager$Validator.validateGitUrl(ServerContextManager.java:753)
	at com.microsoft.alm.plugin.context.ServerContextManager.validateServerConnection(ServerContextManager.java:203)
	at com.microsoft.alm.plugin.context.ServerContextManager.validateServerConnection(ServerContextManager.java:191)
	at com.microsoft.alm.plugin.context.ServerContextManager.createContextFromGitRemoteUrl(ServerContextManager.java:372)
	at com.microsoft.alm.plugin.operations.Operation.getServerContext(Operation.java:205)
	at com.microsoft.alm.plugin.operations.BuildStatusLookupOperation.doWork(BuildStatusLookupOperation.java:149)
	at com.microsoft.alm.plugin.operations.OperationExecutor$1.run(OperationExecutor.java:56)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:840)
Caused by: javax.ws.rs.NotAuthorizedException: HTTP 401 Unauthorized
	at org.glassfish.jersey.client.JerseyInvocation.convertToException(JerseyInvocation.java:1056)
	at org.glassfish.jersey.client.JerseyInvocation.translate(JerseyInvocation.java:859)
	at org.glassfish.jersey.client.JerseyInvocation.access$500(JerseyInvocation.java:75)
	at org.glassfish.jersey.client.JerseyInvocation$2.completed(JerseyInvocation.java:816)
	at org.glassfish.jersey.client.ClientRuntime.processResponse(ClientRuntime.java:203)
	at org.glassfish.jersey.client.ClientRuntime.access$200(ClientRuntime.java:61)
	at org.glassfish.jersey.client.ClientRuntime$2.lambda$response$0(ClientRuntime.java:154)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:288)
	at org.glassfish.jersey.client.ClientRuntime$2.response(ClientRuntime.java:154)
	at org.glassfish.jersey.apache.connector.ApacheConnector.apply(ApacheConnector.java:480)
	at org.glassfish.jersey.client.ClientRuntime.lambda$null$3(ClientRuntime.java:163)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:288)
	at org.glassfish.jersey.client.ClientRuntime.lambda$createRunnableForAsyncProcessing$4(ClientRuntime.java:139)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	... 3 more
2024-01-23 11:59:10,461 [84020239]   INFO - com.microsoft.alm.plugin.context.ServerContextManager - validateGitUrl: failed to get Azure DevOps repo, project and collection info
2024-01-23 11:59:10,461 [84020239]   INFO - com.microsoft.alm.plugin.context.ServerContextManager - Validating a TFS server context with a server URI
2024-01-23 11:59:10,462 [84020240]   WARN - com.microsoft.alm.plugin.context.ServerContextManager - Invalid server connection was found:
com.microsoft.alm.plugin.exceptions.TeamServicesException: KEY_TFS_AUTH_FAILED
	at com.microsoft.alm.plugin.context.ServerContextManager.checkTfsVersionAndConnection(ServerContextManager.java:265)
	at com.microsoft.alm.plugin.context.ServerContextManager.validateServerConnection(ServerContextManager.java:232)
	at com.microsoft.alm.plugin.context.ServerContextManager.validateServerConnection(ServerContextManager.java:191)
	at com.microsoft.alm.plugin.context.ServerContextManager.createContextFromGitRemoteUrl(ServerContextManager.java:372)
	at com.microsoft.alm.plugin.operations.Operation.getServerContext(Operation.java:205)
	at com.microsoft.alm.plugin.operations.BuildStatusLookupOperation.doWork(BuildStatusLookupOperation.java:149)
	at com.microsoft.alm.plugin.operations.OperationExecutor$1.run(OperationExecutor.java:56)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:840)
2024-01-23 11:59:10,462 [84020240]   WARN - com.microsoft.alm.plugin.operations.BuildStatusLookupOperation - getServerContext: failed to get authenticated server context
2024-01-23 11:59:10,462 [84020240]   WARN - com.microsoft.alm.plugin.operations.BuildStatusLookupOperation - doWork: failed with an exception
javax.ws.rs.NotAuthorizedException: HTTP 401 Unauthorized
	at com.microsoft.alm.plugin.operations.Operation.getServerContext(Operation.java:215)
	at com.microsoft.alm.plugin.operations.BuildStatusLookupOperation.doWork(BuildStatusLookupOperation.java:149)
	at com.microsoft.alm.plugin.operations.OperationExecutor$1.run(OperationExecutor.java:56)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:840)
2024-01-23 11:59:10,462 [84020240]   INFO - com.microsoft.alm.plugin.operations.BuildStatusLookupOperation - Creating build status results.
2024-01-23 11:59:10,462 [84020240]   INFO - com.microsoft.alm.plugin.operations.BuildStatusLookupOperation -    builds = null


Remove VerKV deadcode

Feature Request
This is proposing to revert the versioned kv RFC and the already implemented codes. This feature has not been pushed forward since April 2020, and after deeper consideration, I think it can not achieve the goals described in the RFC. Further, coprocessor plugin, a better solution to the problems verkv trying to solve is working on master.
To remove the code, we may revert these PRs:

https://github.com/tikv/tikv/pull/7607
https://github.com/tikv/tikv/pull/7449
https://github.com/pingcap/kvproto/pull/591

cc @BusyJay @zhangjinpeng1987 @Connor1996 @overvenus

/cc @fredchenbj what do you think? Are they still in use?

There's a pattern matching in here that causes an error if the changes are reverted because we are iterating over enums provided by kvproto.
Do you want to handle it here (adding unimplemented or wrapper enum that maps A => A') or by removing those enums over there?

@hbina where is the code you mentioned?

This one https://github.com/tikv/tikv/blob/master/src/server/service/kv.rs#L1161

I've noticed that a lot of components are using kvproto. I assume they all have to be the same version. Shouldn't there be a kvproto component that simply reexports the same version? This way its easier to test it because you only need to change this one place instead of coordinating everything.

ASICS, I think the pattern match you mentions will not be a problem since the VerKV interface is never used. And for your concern on kvproto, I don't really mean to git revert it but to manually remove the item those PRs added.

@fredchenbj What do you think?

@BusyJay So... Let's move on?


Warm Coats

Edits a whole load of clothing items to provide warmth, so that being caught in a cold room, or a frigid wastes of Glacier is more barrable while decently clothed, and so that winter coats don't solve temperature entirely.

make an upstream PR for the changes to upstream prototypes


Chem.MolFromSmiles does not support % sign for ring closure digits

Configuration:

Using Python 3.9.10, with ipython through terminal

RDKit Version: 2021.09.2
Operating system: Mac/Linux
Python version (if relevant): 3.9.10
Are you using conda? No
If you are using conda, which channel did you install the rdkit from?
If you are not using conda: how did you install the RDKit?  pip install rdkit-pypi

Description:
 I am working with molecules that have more than 9 ring closure atoms, and need to use digits 10 and above. Following SMILES grammar rules, a '%' sign needs to be added before the large digit to indicate that the atom C%10 is connected to an atom ten and not atom one and an atom zero. I get a parsing error when using a '%' in my SMILES string that doesn't occur when the '%' is absent (see below).

In [1]: from rdkit import Chem

In [2]: mymolecule = 'C%1CCCCC%1'

In [3]: Chem.MolFromSmiles(mymolecule)
[09:26:52] SMILES Parse Error: syntax error while parsing: C%1CCCCC%1
[09:26:52] SMILES Parse Error: Failed parsing SMILES 'C%1CCCCC%1' for input: 'C%1CCCCC%1'

In [4]: mymolecule = 'C1CCCCC1'

In [5]: Chem.MolFromSmiles(mymolecule)
Out[5]: <rdkit.Chem.rdchem.Mol at 0x7fef986460a0>

From the daylight smiles page:
If necessary or desired, higher-numbered ring closures may be specified by prefacing a two-digit number with percent sign (%). For example, C2%13%24 is a carbon atom with a ring closures 2, 13, and 24 .

The smiles grammar expects more than one letter after a %.  This helps to parse C12 (two ring connections) versus C%12 (one ring connection) and C%123 (two ring connections).

Adding on to @bp-kelley's answer: it's als possible to specify the ring closures with 1-5 digits by putting them inside parentheses (this is a SMILES extension): C%(1)CC%(1)
This is documented here: https://rdkit.org/docs/RDKit_Book.html#ring-closures


Win precommit

Description of PR
How was this patch tested?
For code changes:

[ ] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[ ] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

_ Prechecks _

+1 :green_heart:
dupname
0m 00s

No case conflicting files found.

+0 :ok:
codespell
0m 00s

codespell was not available.

+0 :ok:
detsecrets
0m 01s

detect-secrets was not available.

+0 :ok:
shellcheck
0m 01s

Shellcheck was not available.

+0 :ok:
shelldocs
0m 01s

Shelldocs was not available.

+1 :green_heart:
@author
0m 00s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m 00s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
90m 03s

trunk passed

+1 :green_heart:
compile
18m 54s

trunk passed

+1 :green_heart:
mvnsite
19m 11s

trunk passed

+1 :green_heart:
shadedclient
256m 19s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
16m 52s

the patch passed

+1 :green_heart:
compile
16m 35s

the patch passed

+1 :green_heart:
cc
16m 36s

the patch passed

+1 :green_heart:
golang
16m 35s

the patch passed

+1 :green_heart:
javac
16m 35s

the patch passed

+1 :green_heart:
blanks
0m 01s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
16m 48s

the patch passed

+1 :green_heart:
shadedclient
140m 50s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
20m 17s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs-native-client.txt
hadoop-hdfs-native-client in the patch failed.

-1 :x:
asflicense
5m 08s
/results-asflicense.txt
The patch generated 1 ASF License warnings.

467m 12s

Reason
Tests

Failed CTEST tests
test_test_libhdfs_threaded_hdfs_static

Optional Tests
dupname asflicense codespell detsecrets shellcheck shelldocs compile cc mvnsite javac unit golang

uname
MINGW64_NT-10.0-17763 f1a8481cf9e7 3.4.9-be826601.x86_64 2023-09-07 12:36 UTC x86_64 Msys

Build tool
maven

Personality
/c/hadoop/dev-support/bin/hadoop.sh

git revision
trunk / 5107bb0ebcb61421c48d4de42d6edee6de755237

Default Java
Azul Systems, Inc.-1.8.0_332-b09

CTEST
/patch-hadoop-hdfs-project_hadoop-hdfs-native-client-ctest.txt

modules
C: hadoop-hdfs-project/hadoop-hdfs-native-client U: hadoop-hdfs-project/hadoop-hdfs-native-client

versions
git=2.43.0.windows.1

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

_ Prechecks _

+1 :green_heart:
dupname
0m 00s

No case conflicting files found.

+0 :ok:
codespell
0m 00s

codespell was not available.

+0 :ok:
detsecrets
0m 00s

detect-secrets was not available.

+0 :ok:
shellcheck
0m 00s

Shellcheck was not available.

+0 :ok:
shelldocs
0m 00s

Shelldocs was not available.

+1 :green_heart:
@author
0m 00s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m 00s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
98m 05s

trunk passed

+1 :green_heart:
compile
20m 11s

trunk passed

+1 :green_heart:
mvnsite
19m 43s

trunk passed

+1 :green_heart:
shadedclient
274m 43s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
18m 02s

the patch passed

+1 :green_heart:
compile
17m 32s

the patch passed

+1 :green_heart:
cc
17m 32s

the patch passed

+1 :green_heart:
golang
17m 32s

the patch passed

+1 :green_heart:
javac
17m 32s

the patch passed

+1 :green_heart:
blanks
0m 01s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
17m 21s

the patch passed

+1 :green_heart:
shadedclient
150m 54s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
21m 48s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs-native-client.txt
hadoop-hdfs-native-client in the patch failed.

-1 :x:
asflicense
6m 05s
/results-asflicense.txt
The patch generated 1 ASF License warnings.

501m 07s

Reason
Tests

Failed CTEST tests
test_test_libhdfs_threaded_hdfs_static

Optional Tests
dupname asflicense codespell detsecrets shellcheck shelldocs compile cc mvnsite javac unit golang

uname
MINGW64_NT-10.0-17763 96f59c93662f 3.4.9-be826601.x86_64 2023-09-07 12:36 UTC x86_64 Msys

Build tool
maven

Personality
/c/hadoop/dev-support/bin/hadoop.sh

git revision
trunk / 5107bb0ebcb61421c48d4de42d6edee6de755237

Default Java
Azul Systems, Inc.-1.8.0_332-b09

CTEST
/patch-hadoop-hdfs-project_hadoop-hdfs-native-client-ctest.txt

modules
C: hadoop-hdfs-project/hadoop-hdfs-native-client U: hadoop-hdfs-project/hadoop-hdfs-native-client

versions
git=2.43.0.windows.1

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

_ Prechecks _

+1 :green_heart:
dupname
0m 00s

No case conflicting files found.

+0 :ok:
codespell
0m 01s

codespell was not available.

+0 :ok:
detsecrets
0m 01s

detect-secrets was not available.

+0 :ok:
shellcheck
0m 01s

Shellcheck was not available.

+0 :ok:
shelldocs
0m 01s

Shelldocs was not available.

+1 :green_heart:
@author
0m 01s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m 00s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
104m 41s

trunk passed

+1 :green_heart:
compile
22m 23s

trunk passed

+1 :green_heart:
mvnsite
22m 40s

trunk passed

+1 :green_heart:
shadedclient
319m 26s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
21m 06s

the patch passed

+1 :green_heart:
compile
19m 46s

the patch passed

+1 :green_heart:
cc
19m 46s

the patch passed

+1 :green_heart:
golang
19m 46s

the patch passed

+1 :green_heart:
javac
19m 46s

the patch passed

+1 :green_heart:
blanks
0m 00s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
17m 58s

the patch passed

+1 :green_heart:
shadedclient
166m 52s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
23m 57s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs-native-client.txt
hadoop-hdfs-native-client in the patch failed.

-1 :x:
asflicense
6m 16s
/results-asflicense.txt
The patch generated 1 ASF License warnings.

570m 43s

Reason
Tests

Failed CTEST tests
test_test_libhdfs_threaded_hdfs_static

Optional Tests
dupname asflicense codespell detsecrets shellcheck shelldocs compile cc mvnsite javac unit golang

uname
MINGW64_NT-10.0-17763 1e5cf6af7f56 3.4.9-be826601.x86_64 2023-09-07 12:36 UTC x86_64 Msys

Build tool
maven

Personality
/c/hadoop/dev-support/bin/hadoop.sh

git revision
trunk / 0a78b30037d452c41ae5639fcf7b3e677fbe67c5

Default Java
Azul Systems, Inc.-1.8.0_332-b09

CTEST
/patch-hadoop-hdfs-project_hadoop-hdfs-native-client-ctest.txt

modules
C: hadoop-hdfs-project/hadoop-hdfs-native-client U: hadoop-hdfs-project/hadoop-hdfs-native-client

versions
git=2.43.0.windows.1

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

_ Prechecks _

+1 :green_heart:
dupname
0m 01s

No case conflicting files found.

+0 :ok:
codespell
0m 01s

codespell was not available.

+0 :ok:
detsecrets
0m 01s

detect-secrets was not available.

+0 :ok:
shellcheck
0m 01s

Shellcheck was not available.

+0 :ok:
shelldocs
0m 01s

Shelldocs was not available.

+1 :green_heart:
@author
0m 00s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m 00s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
87m 27s

trunk passed

+1 :green_heart:
compile
18m 54s

trunk passed

+1 :green_heart:
mvnsite
19m 06s

trunk passed

+1 :green_heart:
shadedclient
249m 45s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
16m 53s

the patch passed

+1 :green_heart:
compile
16m 36s

the patch passed

+1 :green_heart:
cc
16m 36s

the patch passed

+1 :green_heart:
golang
16m 36s

the patch passed

+1 :green_heart:
javac
16m 36s

the patch passed

+1 :green_heart:
blanks
0m 00s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
16m 55s

the patch passed

+1 :green_heart:
shadedclient
139m 08s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
20m 16s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs-native-client.txt
hadoop-hdfs-native-client in the patch failed.

-1 :x:
asflicense
5m 14s
/results-asflicense.txt
The patch generated 1 ASF License warnings.

459m 02s

Reason
Tests

Failed CTEST tests
test_test_libhdfs_threaded_hdfs_static

Optional Tests
dupname asflicense codespell detsecrets shellcheck shelldocs compile cc mvnsite javac unit golang

uname
MINGW64_NT-10.0-17763 0d6523873e5c 3.4.9-be826601.x86_64 2023-09-07 12:36 UTC x86_64 Msys

Build tool
maven

Personality
/c/hadoop/dev-support/bin/hadoop.sh

git revision
trunk / 7fb2222b86a32c89f4d289180fcb8ee3133f2d0f

Default Java
Azul Systems, Inc.-1.8.0_332-b09

CTEST
/patch-hadoop-hdfs-project_hadoop-hdfs-native-client-ctest.txt

modules
C: hadoop-hdfs-project/hadoop-hdfs-native-client U: hadoop-hdfs-project/hadoop-hdfs-native-client

versions
git=2.43.0.windows.1

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

_ Prechecks _

+1 :green_heart:
dupname
0m 01s

No case conflicting files found.

+0 :ok:
codespell
0m 01s

codespell was not available.

+0 :ok:
detsecrets
0m 01s

detect-secrets was not available.

+0 :ok:
shellcheck
0m 01s

Shellcheck was not available.

+0 :ok:
shelldocs
0m 01s

Shelldocs was not available.

+1 :green_heart:
@author
0m 00s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m 00s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
102m 15s

trunk passed

+1 :green_heart:
compile
23m 56s

trunk passed

+1 :green_heart:
mvnsite
23m 11s

trunk passed

+1 :green_heart:
shadedclient
322m 48s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
21m 41s

the patch passed

+1 :green_heart:
compile
20m 31s

the patch passed

+1 :green_heart:
cc
20m 31s

the patch passed

+1 :green_heart:
golang
20m 31s

the patch passed

+1 :green_heart:
javac
20m 31s

the patch passed

+1 :green_heart:
blanks
0m 01s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
21m 42s

the patch passed

+1 :green_heart:
shadedclient
178m 52s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
22m 27s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs-native-client.txt
hadoop-hdfs-native-client in the patch failed.

-1 :x:
asflicense
5m 50s
/results-asflicense.txt
The patch generated 1 ASF License warnings.

586m 54s

Reason
Tests

Failed CTEST tests
test_test_libhdfs_threaded_hdfs_static

uname
MINGW64_NT-10.0-17763 69f92ecf1f1f 3.4.9-be826601.x86_64 2023-09-07 12:36 UTC x86_64 Msys

Build tool
maven

Personality
/c/hadoop/dev-support/bin/hadoop.sh

git revision
trunk / 939b07ad796f2d0aa70092347e68968cfa3e8e72

Default Java
Azul Systems, Inc.-1.8.0_332-b09

CTEST
https://ci-hadoop.apache.org/job/hadoop-multibranch-windows-10/job/PR-2/8/artifact/out/patch-hadoop-hdfs-project_hadoop-hdfs-native-client-ctest.txt

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch-windows-10/job/PR-2/8/testReport/

modules
C: hadoop-hdfs-project/hadoop-hdfs-native-client U: hadoop-hdfs-project/hadoop-hdfs-native-client

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch-windows-10/job/PR-2/8/console

versions
git=2.43.0.windows.1

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.


allow fluid_contact.truncated according to schema

Solving #157
Ref #150 - truncated is a valid field for fluid_contact but fmu-dataio did not allow it. This PR allows it.

In the first comment it seems to solve itself (it says #157; should be #156). Also, could you elaborate when a "truncated fluid contact" is a use case? (a bit unclear for me...)

In the first comment it seems to solve itself (it says #157; should be #156).

✅

Also, could you elaborate when a "truncated fluid contact" is a use case? (a bit unclear for me...)

In some cases fluid contact surfaces are truncated to stratigraphic horizons prior to export, so that they are undefined where the contact is not defined (e.g. above the roof, below the floor, or in segments covered by the surface outline but where the fluid column is not actually present). In other cases they are defined as "full" surfaces (defined in all points). Latter is probably most used, while the former is technically "correct". A specific use case right now is REP which require truncated contact surfaces.
Can also add that truncated will probably lead to more metadata information being included in the future. E.g truncated to what. For now, this is only considered a way to separate the two in a consistent way.
An alternative could be to specify a separate content (e.g. truncated_fluid_contact) but that feels wrong and will most likely not be intuitive when consuming the data.
Requiring all fluid contact surfaces to be truncated is not a working solution either, as they are truncated to different things depending on. Sometimes, truncating to horizons from a realization is done, other times they are truncated to aggregated surfaces (e.g. mean).


Try out the guide and provide feedback!

OK all - I've got a prototype of a CLI ready for people to try out! There is now a CLI for managing myst-parser, myst-nb, sphinx, and some of our extensions! You can invoke it like so:
jupyter-book build path/to/mybook

I put together some documentation in this repository that is built with this tool (my god it's so much easier than with Jekyll). It copies over some of the content from jupyterbook.org and adopts it for our build system.
https://beta.jupyterbook.org/
In addition, there is a little guide that should help people get started:
https://beta.jupyterbook.org/guide/01_overview.html
It would be great if folks could give this a shot and see what breaks, what looks wrong, etc. There are many things to improve upon, I'm sure!
Things you could give feedback about:

Do the steps given in the documentation work?
Is the documentation clear?
Did anything unexpected happen?
What do you think of the "book structure" we expect? (_toc.yml, _config.yml and content files)
What do you think of the CLI? (note there are some extra things in here that aren't fully baked)
How does the output look?
How do the logs look? (we should probably find something cleaner than Sphinx logs to show people)
Any features in the build system that you wish existed?

There are also some things we know are not yet in the CLI, here is a short list:

Doesn't yet use jupyter-cache to grab outputs, so the outputs must be inside any notebooks that are read in
Doesn't do markdown -> notebook conversion, so markdown files are "just" parsed as markdown.
The theme still has a top nav-bar. Eventually this will be only a left sidebar.

It would be great if folks can start trying this out, opening issues, making PRs, etc!
cc @gregcaporaso @jstac, @mmcky, and @rossbar who mentioned they were interested in this

Thanks @choldgraf and @chrisjsewell.  Love your work.  Just wanted to say that before I start critiquing :-)

I finally had a chance to give the CLI a try - I think it's great! I really like the "book-level-toc" design that Jupyter-Book uses and it's nice to have that feature along with the new (at least compared to Jupyter-Book 1.*) MyST/Sphinx components from the EBP as well.
#29 contains some quick fixups/suggestions from my first runthrough. I also have some notes from the runthrough: https://hackmd.io/6YNG5gm3TEO2ZXs1VlNluw?edit. Right now they're fairly rough and not all of the notes map directly back to the CLI (some are probably more related to the jupyterbook-theme, etc.) so I'm hesitant about cluttering things up with a bunch of new issues. If you have a chance to glance those over and think there is anything in there you'd like entered in the issue tracker, I'm happy to do so.

Thanks very much for the feedback! I'm glad you thought it was a good first shot :-)
A few specific responses to your points:

I merged your PR - thanks!
re: the TOC, I imagined we could port over chunks of https://github.com/jupyter/jupyter-book/blob/master/jupyter_book/toc.py#L53 to have a jb toc path/to/book option. Would love to have a PR on that if you've got the time!
re: building to PDF, I totally agree. That's is more @mmcky and @AakashGfude 's expertise so I'm hoping they'll have time to make improvements on the latex/PDF side soon!
re: ghp-import I think there's some confusion there because those two steps are actually redundant. You can either directly upload your HTML as in the first step, or you can use ghp-import to do the upload. That should be clarified!
FAQ: it should be CLI issues for now
metadata: here is the latest convo: https://github.com/ExecutableBookProject/MyST-NB/issues/12
resizing: yeah we have a lot more work to do there :-)

gonna close this one as I think this round of feedback has now been incorporated


Standardize model file packaging

Refer to https://github.ibm.com/CODAIT/Production-Readiness/issues/4
This model does not package the model files into tar.gz like TensorFlow models.

This seems to have been resolved


Implement the 'help' function

argparse is your friend. https://docs.python.org/3/library/argparse.html

+1 I will look into that tonight. Thanks.


Mention deprecation of the existential type

From the Flow changelog:

Made * a deprecated type, under the deprecated-type strict flag.

https://github.com/facebook/flow/blob/master/Changelog.md#0720

Thank you @VaclavSir!


The puller --platform flag doesn't support platform variants

The --platform flag I added to the puller (#113) doesn't seem to work with some of the official images like busybox, since those manifests use platform variants for some architectures:
{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 527,
         "digest": "sha256:915f390a8912e16d4beb8689720a17348f3f6d1a7b659697df850ab625ea29d5",
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 527,
         "digest": "sha256:11a6b4baf996d8e52a332fbe7117aca1aae2b3068c7106f5b1065c16e8660895",
         "platform": {
            "architecture": "arm",
            "os": "linux",
            "variant": "v5"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 527,
         "digest": "sha256:d4ae670481a474fda03b2e026a111972a5f459b86e0c57af1ec72d6045f57a27",
         "platform": {
            "architecture": "arm",
            "os": "linux",
            "variant": "v6"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 527,
         "digest": "sha256:8777c62bb60d20e3b98216abe38ea1be721badd997f3840295eccd46f2281a2b",
         "platform": {
            "architecture": "arm",
            "os": "linux",
            "variant": "v7"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 527,
         "digest": "sha256:adeafb67bdeab6f8ab07a46bc7b789d9ae508aac3b0933fb165e3ceb1f36e3e2",
         "platform": {
            "architecture": "arm64",
            "os": "linux",
            "variant": "v8"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 527,
         "digest": "sha256:1ce7a47326ea36f5ba9bf7689cb1737cf79aef81577671d9774deb7378694e54",
         "platform": {
            "architecture": "386",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 528,
         "digest": "sha256:f7d5e9a7fa573052bbce9ad2d59b1c63b848f091a246a8c1e54ccc8178e1b794",
         "platform": {
            "architecture": "ppc64le",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 528,
         "digest": "sha256:d6d388d3ef21f3a75e49606dc0da5ec92da6f181bea347473b7f01904da09175",
         "platform": {
            "architecture": "s390x",
            "os": "linux"
         }
      }
   ]
}

If you try to pull with --platform=linux/amd, it fails, presumably since the platform doesn't match fully.
$ bazel-bin/puller --name index.docker.io/library/busybox:latest --directory /tmp/busybox --platform=linux/arm
F1119 19:28:06.679466   74570 fast_puller_.py:128] Error pulling and saving image index.docker.io/library/busybox:latest: Could not resolve manifest list to compatible manifest

Docker's cli somehow handles this, apparently downloading the v7 variant, but I don't know how it does that.
I can think of a few ways to address this:

Remove --platform, replacing it with --os, --architecture, and --variant. It's most explicit, and perhaps is what I should have done all along, but technically is a breaking change. (I'm not sure if anyone is using --platform yet though, since it's pretty new.)
Extend --platform to support variants somehow, either
a. with an optional /variant suffix (e.g. linux/arm/v7), or
b. by translating special values like those listed in https://github.com/docker-library/go-dockerlibrary/blob/master/architecture/oci-platform.go, e.g. arm32v7 -> {arm, v7}
Emulate whatever the docker cli is doing, though I don't like this one as much, since it doesn't seem to be documented, and I can't figure out how to make it download e.g. the arm v5 variant image.

I feel like the best options are either 1 or 2a. Thoughts?
(Note that the place I intend to use this, https://github.com/bazelbuild/rules_docker/pull/544, already separates out os and architecture, so I'll probably add a third attribute there, variant, or maybe even turn it into a dict.)
cc @KaylaNguyen @nlopezgi

Looking at the OCI spec (and what is implemented in client/v2_2/docker_image_list_.py) we may also need to support os.features, os.version, and probably features too. (The golang image uses os.version for the windows images, for example.)
I'm not sure what the cleanest way to do this is. I don't think we can really add all of those fields to --platform in a manageable way, though.

@ixdy afaik rules_docker is the main user of this repo, so breaking changes (as long as we follow up with PR in rules_docker) should be fine.

@ixdy if you want one flag to fit all of this in, you could change --platform to accept a json blob and just pass that through to resolve, though for interactive use that is probably more cumbersome than --os and --architecture flags (et al).


Correct latest 2.1 patch in version selector

This change is

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/f2bce0241bf52e70c37ed9954c9ce212702cf6f1/


Add support for Document Attachments

Problem statement :
Cannot create a SSM Document that can be used with AWS Distributor since attachments cannot be added to the definition.
See an example of what the SSM Document looks like for a Distributor package using Cloudformation:
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-document.html#aws-resource-ssm-document--examples--Create_a__Distributor_package
Solution:

Update lib to allow for an optional Attachments property at the Document level

Also will likely want to create AttachmentSource child object https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AttachmentsSource.html

Update lambda when create/update is called to pass the Attachments if they are defined

Happy to create a PR to implement this.

Happy to create a PR to implement this.

Sounds good! 👍🏼


can u show us the stress test result data ？

i saw this : “Stress testing shows that ProxyKit is approximately 8% slower than nginx for simple forwarding on linux”.
can u show the data about the stress testing ?

Yeah I need to back that up with some substance. I'll leave this open to follow up on. In the mean time I'm going to remove that statement until further proof because, on reflection, it shouldn't be there without it.

thanks for reply，and i will keep an eye on

Never got around to doing a formal benchmark and because of #230 I won't. However since Microsoft are building one in a similar fashion (kestrel -> middleware -> httpclient) for their Azure partners, it lends credence to the fact it'll be fast enough.


Build v 2.1.1:

Added two new patches needed for building.
Reset build number to 0.
Updated build section with patch.
Update host section with wheel.
Updated test section of the recipe.
Updated 'about' section with some additional info.
Added local cbc, although might be redundant.

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_10h7n4sgxc/clone/recipe/meta.yaml:41: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
WARNING: /tmp/abs_10h7n4sgxc/clone/recipe/meta.yaml:50: python_build_tool_in_run: The python build tool pybind11 is in run depends
Errors were found

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_a432ljkj2q/clone/recipe/meta.yaml:43: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
WARNING: /tmp/abs_a432ljkj2q/clone/recipe/meta.yaml:52: python_build_tool_in_run: The python build tool pybind11 is in run depends
Errors were found

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_1dkcdlf0yb/clone/recipe/meta.yaml:45: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
WARNING: /tmp/abs_1dkcdlf0yb/clone/recipe/meta.yaml:54: python_build_tool_in_run: The python build tool pybind11 is in run depends
Errors were found

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_00agxbgpmy/clone/recipe/meta.yaml:47: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
WARNING: /tmp/abs_00agxbgpmy/clone/recipe/meta.yaml:56: python_build_tool_in_run: The python build tool pybind11 is in run depends
Errors were found

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_77733ltmoz/clone/recipe/meta.yaml:47: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
WARNING: /tmp/abs_77733ltmoz/clone/recipe/meta.yaml:56: python_build_tool_in_run: The python build tool pybind11 is in run depends
Errors were found

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_ef162hihjm/clone/recipe/meta.yaml:47: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
WARNING: /tmp/abs_ef162hihjm/clone/recipe/meta.yaml:56: python_build_tool_in_run: The python build tool pybind11 is in run depends
Errors were found

If you review this, can you please suggest on the following:
It seems like psutil is only used in tests, but the upstream specifies it as a required package for build and run.
https://github.com/search?q=repo%3Anmslib%2Fnmslib+psutil&type=code
It seems like pybind11 is only required for build but the upstream also lists it as a runtime dependency.
https://github.com/search?q=repo%3Anmslib%2Fnmslib+pybind&type=code
testKnnQueryBatch seems to randomly fail on ppc64l. I have deactivated it.

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_f1cpiimtk7/clone/recipe/meta.yaml:46: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
WARNING: /tmp/abs_f1cpiimtk7/clone/recipe/meta.yaml:55: python_build_tool_in_run: The python build tool pybind11 is in run depends
Errors were found

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_6bp25k1iyw/clone/recipe/meta.yaml:46: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
WARNING: /tmp/abs_6bp25k1iyw/clone/recipe/meta.yaml:55: python_build_tool_in_run: The python build tool pybind11 is in run depends
Errors were found

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_00iecoxgkn/clone/recipe/meta.yaml:46: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
WARNING: /tmp/abs_00iecoxgkn/clone/recipe/meta.yaml:55: python_build_tool_in_run: The python build tool pybind11 is in run depends
Errors were found


Implement read_dir function and test

Implement a gdal::vsi::read_dir function and test.

[x] I agree to follow the project's code of conduct.
[x] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

:+1:
Can someone, e.g. @jdroenner, activate the CI?

I just realized that the test should be in vsi.rs. Fixing....

Could you please activate CI again for this branch?

We can't activate it directly, it's disabled for PRs in the workflow, and some convincing might be required to change that.
But at least we can
bors try

CC #266

Hmm, CI works now.

Hmm, CI works now.

We'll need your change for it to not fail though.

Can you rebase?

I was having trouble rebasing, so I merged. Should be good though.

Oof, sorry, I missed your comment. Can you resolve the conflict, then maybe squash? It's fine if you don't, though.

Hopefully I did that correctly.

bors r+

Hopefully I did that correctly.

Almost, except the commit message :sweat_smile:.

:(

bors r-

Sorry, I missed this, @ChristianBeilschmidt had a good question up there.

Which comment? AFAIK, everything was resolved.

The return type, which has String instead of PathBuf.

I'm sorry if I blocked this. I guess my comments were resolved.
@lnicola has a comment open and can resolve this then.

bors r+


NuGet package enforcing unwanted code analysis rules to the consuming project

Describe the bug
The NuGet package installs Microsoft.VisualStudio.Threading.Analyzers, which can fail the build of a project if the code is not compliant with their set of rules. In some cases, a project may not wish to enforce these rules. One example that it is enforcing on my project is "VSTHRD200: Use "Async" suffix in names of methods that return an awaitable type", but there are several others as well.
To Reproduce

Use a sample project with this library
Add an async method without the "Async" suffix.
Try to build the project and it will fail.

Expected behaviour
No unwanted code analysis rules being applied to the consuming project.

Will take a look in nearest time. thanks

Hey @nharren
I've just checked in Visual Studio. I've removed the Analyzers package from my sample project, added the following method and the build works without any problems.

Would you be able to share you test project?

Hello, the analyzers are still on the package, ive faced the same issue they force me to follow certain rules.
Are you planing to remove it from the package any soon ?

@MehdiRifi yeah, let me do that in the next few days.

much appreciated!

Fixed in 1.0.3 https://www.nuget.org/packages/VaultSharp.Extensions.Configuration/1.0.3


Use cookies instead of localstorage to allows server JWT calculation

I'm submitting a ...  (check one with "x")
[ ] bug report => check the README and search github for a similar issue or PR before submitting
[ ] support request => check the README and search github for a similar issue or PR before submitting
[x] feature request

Hi,
This feature would work with the help of @ngx-universal/cache.
My issue is that for every http request for a logged in user I'm passing his JWT token in the headers.
The thing is that with localstorage, the angular universal server has no way to know what JWT token is attached to the user, so every request is invalidated and remade by the client.
I could surely help if you tell me what you think about this.

@theomathieubhvr actually I'll need more or less a similar feature for the authentication module that I developed for Angular. Nowadays, it's really busy with things related to ElasticSearch/MongoDB for the server side. However, I suppose in a week or two I'll already have been deployed the authentication project for Angular and we'll have a better chance to figure things out.
And for sure, your contributions are always welcome, and awesome 👍

by the way, the authentication project has been deployed on https://github.com/fulls1z3/ngx-auth, have a look at it when you have time 👍


exported all flags as .svg for better usage in web - fixes #2

Hi there,
I saw this flagpack coming from iconjar and was a bit disappointed that there was neither an .iconjar, nor a package of SVGs. Although I use OSX and Sketch heavily, I could imagine that this would hurt a bit for non OSX or non Sketch users.
Therefore I just went straight ahead and exported them all for easier usage.
This also fixes the #2 issue, which was basically exactly this.

Added new svg's for better compability and added an iconjar container with full country names for easier management within iconjar app

We have now released FlagKit 2.0 which contains SVG assets 🎉


OpenLayers Raster Example doesn't work

OpenLayers Raster Source Example (editing version using codepen) doesn't work, maybe it has something wrong.. can you please check it
http://openlayers.org/en/latest/examples/raster.html

This is because the api key of the Bing layer needs to be set in the js panel of codepen.


TensorFlow Lite Implementation and TPU offloading

My thought is to begin integrating a Raspberry Pi equipped with Tensor Processing Units (TPUs) (e.g., Google Coral USB Accelerator) into our robot’s system. This addition would offload computationally intensive tasks, such as running custom TensorFlow Lite models for vision processing or machine learning (ML), allowing the REV Control Hub to focus on core robot control and communication with the Field Management System (FMS).
Connect the Raspberry Pi to the REV Control Hub via USB or UART.

Attach TPUs (e.g., Google Coral USB Accelerator) to the Raspberry Pi for model inference.
Power the Pi and TPU using the robot’s power distribution system.

Software Integration:

Raspberry Pi:
Set up TFLite runtime with TPU support.
Load and run ML models, sending inference results back to the Control Hub via USB or UART.
FTC Control Hub:
Implement a communication handler in the FTC app to request model inference and process results.

Data Flow:

The FTC app sends raw data (e.g., camera frames or commands) to the Raspberry Pi.
The Raspberry Pi runs the ML model on the TPU and returns processed results (e.g., detected object coordinates).

You could integrate a method to  handle request to the raspberry pi,
import java.io.InputStream;
import java.io.OutputStream;
import android.hardware.usb.UsbManager;
import android.hardware.usb.UsbDeviceConnection;
import android.hardware.usb.UsbDevice;

public class RaspberryPiHandler {
    private UsbDeviceConnection connection;
    private OutputStream outStream;
    private InputStream inStream;

    public RaspberryPiHandler(UsbManager usbManager, UsbDevice device) {
        connection = usbManager.openDevice(device);
        if (connection != null) {
            outStream = connection.getFileDescriptor();
            inStream = connection.getFileDescriptor();
        }
    }

    // Send inference request to the Pi
    public void sendInferenceRequest() throws IOException {
        if (outStream != null) {
            outStream.write("INFER\n".getBytes());
        }
    }

    // Read inference result from the Pi
    public String getInferenceResult() throws IOException {
        byte[] buffer = new byte[1024];
        int bytesRead = inStream.read(buffer);
        return new String(buffer, 0, bytesRead).trim();
    }
}

And integration with teleop (or likely auto) like this,
import com.qualcomm.robotcore.eventloop.opmode.OpMode;

@TeleOp(name = "PiIntegrationExample", group = "TeleOp")
public class PiIntegrationExample extends OpMode {
    private RaspberryPiHandler piHandler;

    @Override
    public void init() {
        UsbManager usbManager = (UsbManager) hardwareMap.appContext.getSystemService(Context.USB_SERVICE);
        UsbDevice device = findRaspberryPiDevice(usbManager); // Implement device discovery logic
        if (device != null) {
            piHandler = new RaspberryPiHandler(usbManager, device);
            telemetry.addData("Status", "Raspberry Pi connected");
        } else {
            telemetry.addData("Status", "Raspberry Pi not found");
        }
    }

    @Override
    public void loop() {
        try {
            if (piHandler != null) {
                // Request inference
                piHandler.sendInferenceRequest();

                // Get and process the inference result
                String result = piHandler.getInferenceResult();
                telemetry.addData("Inference Result", result);

                // Example: Use result for robot decision-making
                String[] parts = result.split(" ");
                double x = Double.parseDouble(parts[0]);
                double y = Double.parseDouble(parts[1]);
                if (x < 100) {
                    // Move left
                } else if (x > 200) {
                    // Move right
                }
            }
        } catch (Exception e) {
            telemetry.addData("Error", e.getMessage());
        }

        telemetry.update();
    }

    private UsbDevice findRaspberryPiDevice(UsbManager usbManager) {
        for (UsbDevice device : usbManager.getDeviceList().values()) {
            // Add logic to match the Pi's USB Vendor and Product IDs
            return device;
        }
        return null;
    }
}

We are not allowed to use rasberry pi but we can use the camera that is allowed for tensorflow lite


clickhouse-client cannot deal with comments at the end of input

If input ends with anything but space characters or a semicolon, clickhouse-client is unhappy and produces weird errors:
$ cat wtf.sql
CREATE DATABASE IF NOT EXISTS open; -- foo

$ cat wtf.sql | clickhouse-client -n
Code: 62. DB::Exception: Syntax error: failed at end of query.
Expected OPTIMIZE

$ cat wtf.sql
CREATE DATABASE IF NOT EXISTS open;
-- foo

$ cat wtf.sql | clickhouse-client -n
Code: 62. DB::Exception: Syntax error: failed at end of query.
Expected OPTIMIZE

Confirmed.
(This is because clickhouse-client does not support empty statements with just comments.)


[Figma] Card – pictogram v2 updates for border and hover

Updated design specs
We need to update the Figma design kit with the changes coming to card – pictogram in v2:

Like the rest of card, there is an added border to align with Carbon's v11 tile enhancement. There will also be an icon in the lower right to match the other card components.
The hover reveal when using body copy is being removed. Instead, card – pictogram will have required heading and optional body copy that is displayed all in one view. If only heading is included, the dimensions of the card are locked, but if body copy is added, the card's height will expand to accommodate the added copy.
Note that the pictogram should be bottom-aligned by default, with the option to swap to top-aligned. See #10195

In Figma!


Make lowercase and uppercase steps more straightforward

If a column is selected before clicking on lowercase or uppercase
operations, the step is applied directly without opening the form
Closes https://github.com/ToucanToco/vue-query-builder/issues/341

Codecov Report

Merging #342 into master will increase coverage by 0.03%.
The diff coverage is 95.23%.

@@            Coverage Diff             @@
##           master     #342      +/-   ##
==========================================
+ Coverage   96.95%   96.98%   +0.03%
==========================================
  Files          85       85
  Lines        1936     1956      +20
  Branches      289      291       +2
==========================================
+ Hits         1877     1897      +20
  Misses         59       59

Impacted Files
Coverage Δ

src/components/ActionToolbarButton.vue
84.44% <95.23%> (+12.44%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ddd3d05...607d0fc. Read the comment docs.


Gradlew Not Working

when i try to use the ./gradlew genSources command it throw an error

when i try to use the ./gradlew genSources command it throw an error

@RIFTdevv What error did it give?
Also, I got an error, all I had to do was restart IntelliJ.
If this issue is solved please close it.

I just did gradle task to stop all daemons, and re-ran the genSources task, and that worked for me.


Override configuration

What problem are you trying to solve?
I would like to override the environment variables passed to a service.
What solution would you like?
It would be nice if there was an easy way to override the configuration locally, without modifying the base configuration file directly. For example, docker-compose allows overriding values in docker-compose.yml by creating an override file docker-compose.override.yml
Alternatives you've considered
I have tried passing --env-file .env.devbox to devbox generate direnv and it looks like the environment variables defined in direnv shell are not used by process-compose.

I'm in search for a feature like that. I like to convince more projects and repositories to use a strong and shared toolchain specification. Devbox is great for that. But additionally I like to use Devbox for my local development environment setup for these projects. Like adding a language server for example or have a hook that sets-up shell completion for my very own shell. These are things I don't wanna or simply can't put into the shared Devbox configuration. Especially when you also use Devbox for your pipeline too.


NSMenu missing init call

We currently only call NSMenu::alloc() but i think we also need to call init(title: String), which is NSMenu's only constructor.
Cacao calls msg_send![alloc, initWithTitle:&*title].
Not sure how to solve this since Menu::new()does not have a title.
Originally posted by @kud1ing in https://github.com/linebender/druid/issues/1307#issuecomment-832937084
Regardless of anything else discussed, we should be calling init, and not just alloc.

Can be closed.

Thanks!

Nah. Thank @terhechte and you!


Clone command should use git@github as the remote origin

Currently it creates something like
remote.origin.url=https://github.com/abc/dotfiles.git

when cloned using $HOME/.homesick/repos/homeshick/bin/homeshick clone abc/dotfiles
which forces me to enter github username and password every time. Don't want to. Already have my ssh keys there.
Meaning I ll have to manually modify the auto generated git config file to
<EMAIL_ADDRESS>
A bit painful to do so on every machine. Can't this be a parameter of the clone command?

Do you have your dotfiles in a private repo?
In my experience with public repos, the opposite is true; when cloning or pulling, I only get prompted for a username/password if I use the SSH URL.

The github shorthand is meant for cloning public repos, like e.g. robbyrussell/oh-my-zsh where you don't need push access. If you need to clone a private repo use homeshick clone<EMAIL_ADDRESS>

@haraldkoch yes my dotfiles are in a private repo
do you think you can add this to the readme that the homeshick clone<EMAIL_ADDRESS>syntax is possible too for private repos?

Done.


Replace instances of self.lightning_module.trainer with trainer directly in ddp_spawn and tpu_spawn

What does this PR do?
In ddp_spawn.py and tpu_spawn.py:

For several functions, pass the trainer as an argument rather than calling self.lightning_module.trainer inside the function

Also:

Make transfer_distrib_spawn_state_on_fit_end a private function
Add typing to functions that were changed

Before submitting

[ ] Was this discussed/approved via a GitHub issue? (not for typos and docs)
[x] Did you read the contributor guideline, Pull Request section?
[ ] Did you make sure your PR does only one thing, instead of bundling different changes together?
[x] Did you make sure to update the documentation with your changes? (if necessary)
[x] Did you write any new necessary tests? (not for typos and docs)
[ ] Did you verify new and existing tests pass locally with your changes?
[ ] Did you list all the breaking changes introduced by this pull request?
[ ] Did you update the CHANGELOG? (not for typos, docs, test updates, or internal minor changes/refactorings)

PR review
Anyone in the community is welcome to review the PR.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:

[ ] Is this pull request ready for review? (if not, please submit in draft mode)
[ ] Check that all items from Before submitting are resolved
[ ] Make sure the title is self-explanatory and the description concisely explains the PR
[ ] Add labels and milestones (and optionally projects) to the PR so it can be classified

Did you have fun?
Make sure you had fun coding 🙃

Thanks for the review, ready to be merged!


Added performance improve to dataframe.py insert to use iloc and …

Enhancement: Rewriting insert to use apply_func_to_select_indices instead of apply_func_to_select_indices_along_full_axis #670
…pd.concat instead of query compiler
Signed-off-by: DayneSorvisto<EMAIL_ADDRESS>
What do these changes do?

[ ] commit message follows format outlined here
[ ] passes flake8 modin
[ ] passes black --check modin
[ ] signed commit with git commit -s
[ ] Resolves #?
[ ] tests added and passing

Closing PR for now to clean up open PRs. Please feel free to reopen and to continue the development!


proposal: cmd/go: option to disable caching for specific packages

When embedding large amounts of data with embed, the data is then stored in the Go build cache.
This can cause the Go build cache to grow quite rapidly in size.
This proposal is to add a variable similar to GOPRIVATE like GONOCACHE which would disable the Go build cache for a specific list of Go packages (or package patterns).
We want to cache compiling most packages, but some, which carry large "embed" data, should not be cached.

CC @bcmills @matloob

I think that might be a difficult change.  We started requiring the build cache in 1.12; see https://go.dev/doc/go1.11#gocache.  But I'm not entirely sure.

@paralin just how big are your embedded files? I wonder, if they're too big for your build cache, aren't they too big for your binaries too? Or is it because you end up with multiple copies in the build cache due to different builds?
Perhaps related: the test cache already uses file attributes like modified time to avoid using the entire file contents in case files are large; see https://github.com/golang/go/issues/58571#issuecomment-1434476284. I assume this case is slightly different, because an embedded file is not just part of the cache key hash, it's part of the resulting compiled package. But we could still consider storing an absolute path to the original embedded file if the file is too large, and considering the cache entry invalid if said path no longer exists.

@mvdan as part of a release process I'm embedding a large file into the binary to pack everything to one binary.
The binary is of acceptable size (~200Mb) for downloading and running natively. But the file changes between builds, so as you mentioned the build cache grows very fast.

But we could still consider storing an absolute path to the original embedded file if the file is too large, and considering the cache entry invalid if said path no longer exists.

That seems like it would work to me.
I don't mind not having a knob to control this, as long as the build cache no longer grows rapidly and unbounded

When embedding large amounts of data with embed, the data is then stored in the Go build cache.

I am surprised that embed data is stored in the cache at all. I would expect it not to be, since the contents of any given file to be embedded should not vary based on the build configuration: we shouldn't be linking in the embed data until we link the final program, and at that point we should be able to link it directly from the source tree (bypassing the build cache entirely).
I would much rather we do that than add a cmd/go configuration knob.
I wonder if this should be considered as linker deficiency rather than a cmd/go proposal.

Just a note that if we don't store the content of the embedded file in the build cache, the build hash gets trickier because it depends on files that aren't in the build cache.  This seems like a solvable problem but it does seem to break one of our current invariants.

The build hash already depends on files that aren't in the build cache: namely, the .go source files themselves. (It probably does change an invariant of the link action in particular, but not of the build cache in general.)


Closes #36 - SF MongoDB bind was attempted even during udpate

DBManager initiates connection to DB by getting the DB co-orindates
from the property stored on deployment. Once db bind info is retrieved
it is then stored locally & on any future ocassions which requires
db connections to be reset again, the same bind info is used.
However during start if BOSH is down, then db bind info is not
fetched & during an update request after it completes successfully
if bind info is not found in cache its assumed that its a creation
flow and tries creating the bind once again which errors as reported.
To fix this couple of things have been done:

During start if unexpected errors occur then initialize of DB
manager is retried till it succeeds (with a delay)
Post create/update operation before creating the binding first
a check is done to see if binding already exists and only then
creation of binding is done.
Retry is introduced even for erros occuring during polling of
create/update task status.
If bind info cannot be retrieved post update/create bosh errors
even in such scenarios retry happens till it succeeds.

Hopefully with all the retries in place it must certainly fix the
DBManager failures due to BOSH errors.
Fixes #36

Overall looks good, only few findings mentioned above!

@jagadish-kb : Will merge this PR . Since it is on master it will not be part of 9A . Hence request you to raise a PR on 9A rel branch too , else let this fix go as part of 9B ?!


The test_reference is not right

Dear developer:
We found the website(https://locityper.vercel.app/test_dataset) reference genome unsuitable for the test analysis.
I think this is caused by the wrong chromosome number, which is very difficult for researchers who study non-human species because I don't know if the chromosome matches the serial number, so hopefully we can fix this part.
The second question is when we did the first step"docker run -v /home/test/Software/test_data:/workdir eichlerlab/locityper:0.15.2 locityper add -d db -v /workdir/hprc.vcf.gz -r /workdir/genome.fa -j /workdir/counts.jf -L /workdir/loci.bed"
The screen showed that:
[00:09:24 DEBUG] locityper add -d db -v /workdir/hprc.vcf.gz -r /workdir/genome.fa -g human -j /workdir/counts.jf -L /workdir/loci.bed
[00:09:24 DEBUG] locityper v0.15.2 @ 2024-06-18 00:09:24
[00:09:24  INFO] VCF file contains 90 haplotypes
[00:09:24  INFO] Detected jellyfish k-mer size: 25
[00:09:24  INFO] Analyzing MUC6 (chr11:1012824-1036718)
[00:09:24  INFO]     Extending locus by 2133 bp left and 48167 bp right -> chr11:1010691-1084885
[00:09:24  INFO]     Discarded 10 duplicate haplotypes
[00:09:25  INFO]     Calculating sequence divergence for 80 alleles
[00:09:25  INFO]     Counting k-mers
[00:09:31  INFO] Analyzing MUC16 (chr19:8848845-8981342)
[00:09:31 ERROR] Error while analyzing locus MUC16 (chr19:8848845-8981342):
Runtime error: Cannot expand locus MUC16 to the left due to a long variant overlapping boundary.
Try increasing -e/--expand parameter or manually modifying region boundaries.
[00:09:31  WARN] Successfully added 1 loci, failed to add 1 loci
[00:09:31  INFO] Total time: 0:00:07.420
this command not produce locus haplotypes!
Can you help me and tell me what happened?
Best!

Hi there!
Thank you for noticing, the link to the reference genome I had in the docs is indeed incompatible. I now updated the link, and you can download an appropriate reference genome here.
As for the second problem: you only ran the first step (target locus database), you need to run two other steps, WGS preprocessing and genotyping. In addition, you had a partial error during database construction (this seems to be related to the incorrect reference, can you rerun it with the new reference file?).
Best regards,
Timofey

Dear Timofey:
I used the new reference genome and all the test data was fine, which is great and helps you understand the software.
I also have a new problem, we had a graphical pan-genome built in Minigraph-Cactus trying to do population typing for the second generation, but we didn't understand what the advantage was over Pangenie.
Because Pangenie's speed is also very fast, it takes about 2 hours to complete an analysis on our server. As we all know, building the system is relatively difficult and of course it is exciting to have your help, if you can please tell me the aspects so that everyone can understand.
Best
Dong

Dear Dong,
Pangenie and Locityper complement each other: Pangenie runs across the whole genome and outputs variant calls, while Locityper is a targeted method, and it predicts larger-scale genotypes. Locityper genotype corresponds to the two closest haplotypes, and, while the results can be converted into VCF format, individual short variants may be less correct, than for Pangenie. However, by finding full-locus haplotypes, Locityper-predicted variants are phased by construction. Additionally, by using full reads/read pairs, Locityper better saves long-scale correspondence between variants than Pangenie, which only uses k-mer counts. Of note, Locityper-predicted haplotypes can be used by themselves, without converting into individual variants, but that obviously depends on what you want to achieve.
In general, Locityper seems to perform better at complex regions and on a longer scales, and Pangenie is slower and may have higher accuracy at slightly easier regions and on individual variants. But it is actually quite nice that Pangenie runs so fast on your data.
In any case, we did not try Locityper on non-human genomes, so hard to say what will happen to Locityper-Pangenie comparison there. Please write me if you have any other questions or concerns!

Dear Timofey:
My work is on the pig genome, so software designed for humans generally works very well in pigs.
As we all know, pigs are not only an important domestic animal, but also one of the hot animals in human organ transplantation.
I will test Locityper with our pan-genome and see how it is used in real work.
Best
Dong


Add AlphaWallet to apkure

https://apkpure.com/

@colourfreak do you have any info about this site? I tried to upload AW Android on to it, it uploaded, but when I added it to the developer console it said 'This application has existed on Google Play". I have contacted their developer support, see what they say.

Does that mean someone else uploaded this in our name? Can we take over it?

Does that mean someone else uploaded this in our name? Can we take over it?

I don't think it works like that ... there is no 'ownership' it's kind of weird. I was able to upload the latest APK just by supplying the binary. However I don't know how we can update the page, their support was very fast to contact me back though. I'll ask.

@hboon Shall we transfer this issue to AlphaWallet-web3-provider repo?

@colourfreak no, it's good here. https://github.com/AlphaWallet/AlphaWallet-web3-provider is for the code that we inject into the dapp browser to support dapps.

@seabornlee @justindg Can you take care of this issue?

@colourfreak Ok, I will take care of this.

The latest version is uploaded, I have no idea who did it. Maybe their operation team?

The latest version is uploaded, I have no idea who did it. Maybe their operation team?

Can you please reupload with updated graphics + icon?

The latest version is uploaded, I have no idea who did it. Maybe their operation team?

Can you please reupload with updated graphics + icon?

Haven't applied the new playstore graphics (I will work on it), the new icons however are already updated, but #2443 needs to be merged first :)

Out of phase 1


chef-client 12.16 automatic data collector connections fail when using a chef-server URL including an organization

Description
Chef Client 12.16 added the feature to automatically forward an Automate Data Collector via the Chef Server with zero configuration.  It attempts to use the chef server URL as specified in client.rb, so no additional configuration is needed.  However if the Chef server URL contains an organization, i.e. https://chef.server.com/organizations/myorg, the chef server will try to redirect the post, resulting in a client failure.
This can be worked-around by adding the data_collector.server_url = "https://chef.server.com/data-collector/v0/" directly to client.rb, but believe this violates the intent of the enhancement added to client v 12.16 - that data collection can be enabled with zero config.
Concern is that this has caused clients to spontaneously start failing, and since it fails before even getting into ohai or cookbook execution, changes can't be reverted via policy.  Our solution was to stop rollout of 12.16 - then via client 12.12, add a key-value pair for data_collector.server_url via chef-client cookbook, and then re-launch rollout of 12.16 across the enterprise..
Chef Version
chef-client 12.16
Platform Version
RHEL 6
Replication Case
Enable Automate data collection on the chef server.
Bootstrap a node with the chef-server URL specifying an organization, I.E.:
knife bootstrap <IP_ADDRESS> --ssh-user bob --sudo --identity-file
~/.ssh/bob-key.pem --node-name mynode.org.com --run-list role
[myorg-generic-dev] --server-url https://chef.org.com/organizations/myorg
Client Output
<IP_ADDRESS> Chef Client failed. 0 resources updated in 24 seconds
<IP_ADDRESS> [2016-11-30T18:28:06+00:00] ERROR: POST request was redirected
from
https://chef.org.com/organizations/myorg/data-collector to
https://chef.org.com/data-collector/v0/. Only GET and HEAD support
redirects.
<IP_ADDRESS> [2016-11-30T18:28:06+00:00] FATAL:
Chef::Exceptions::ChildConvergeError: Chef run process exited
unsuccessfully (exit code 1)
Stacktrace
N/A

cc @danielsdeleo @adamleff @srenatus

Pinged internal team that worked on this.

The main problem here is the Chef Server sending a redirect. Can you share your chef-server.rb, and also look in the nginx logs to see if there's any additional info about why it's sending this redirect? On the client-side, maybe we could have Chef Client rescue this error and disable the data collector, but I'm not sure if that's what we really want.

Hmm.. Our chef-server.rb is pretty vanilla.. As below:
I was curious that the redirect was happening as well, but thought that it was since the data collector appeared to work from the base url of the chef server, vs the one with /organizations/ attached.
We wouldn't want the data collector to be disabled, optimally I'd think the chef-client could determine the proper base url to use for the collector.
api_fqdn "chef.prod.sys.dom"
ldap['host'] = 'ad01.prod.sys.dom'
ldap['port'] = 389
ldap['ssl_enabled'] = false
ldap['base_dn'] = 'dc=prod,dc=sys,dc=dom'
ldap['bind_dn'] = 'CN=chef-svc,OU=service,OU=accounts,OU=prod,DC=prod,DC=sys,DC=dom'
ldap['login_attribute'] = 'sAMAccountName'
ldap['bind_password'] = 'bindpassword'
license['nodes'] = 1200

oc_id['applications'] = {
  'supermarket' => {
    'redirect_uri' => 'https://supermarket.prod.sys.dom/auth/chef_oauth2/callback'
  }
}

data_collector['root_url'] = 'https://automate.prod.sys.dom/data-collector/v0'
data_collector['token'] = '93a49a4f2482c64126f7b6015e6b0f30284287ee4054ff8807fb63d9cbd1c506'

The only thing I see in the nginx logs is that it's sending a 301 when trying to hit the data collector with the relative /organizations/<org> in the chef_server_url, bug no reasoning as to why:
<IP_ADDRESS> - - [30/Nov/2016:12:03:10 +0000]  "POST /organizations/infrastructure/data-collector HTTP/1.1" 301 "0.016" 178 "-" "Chef Client/12.16.42 (ruby-2.3.1-p112; ohai-8.21.0; x86_64-linux; +https://chef.io)" "<IP_ADDRESS>:443" "301" "0.001" "12.16.42" "algorithm=sha1;version=1.1;" "SDdEa-aDEMO01.dev.sys.dom" "2016-11-30T12:03:10Z" "SF2UluZ9+uyf9J5OImhCOcsdrag=" 96766
I don't see anything else pertaining to this request in the other nginx logs (error) or in the erchef logs themselves.   Its problem is the missing trailing slash here:
data_collector['root_url'] = 'https://automate.prod.sys.dom/data-collector/v0'

Without the slash, Automate's nginx will try to be clever and redirect you to data-collector/v0/ -- breaking your POST. 💥
This has been fixed yesterday (making Automate accept stuff on the root_url without the trailing slash), but for getting unstuck, please try again with adding it to your data_collector['root_url'].

Closing this since the proper fix has been merged (in Automate, which is private so I can't link to the change) and there is a workaround for now. If anyone is of the opinion that the data collector should disable itself when encountering invalid redirects, please file a new issue (or create a PR) and we can talk about it.

@danielsdeleo there is a data_collector.raise_on_failure config parameter that we initially honored for this. If it was false, and we failed to send the run_start message, we'd disable. We should probably continue to honor that even with the automagic config, no?