jiebi/CodeConvo huggingface dataset:
Code change:
import { IPagedRenderer } from 'vs/base/browser/ui/list/listPaging'; import { Event } from 'vs/base/common/event'; import { IExtension, ExtensionContainers, ExtensionState, IExtensionsWorkbenchService } from 'vs/workbench/contrib/extensions/common/extensions'; <del> import { UpdateAction, ManageExtensionAction, ReloadAction, ExtensionStatusLabelAction, RemoteInstallAction, ExtensionStatusAction, LocalInstallAction, ActionWithDropDownAction, InstallDropdownAction, InstallingLabelAction, ExtensionActionWithDropdownActionViewItem, ExtensionDropDownAction, WebInstallAction, SwitchToPreReleaseVersionAction, SwitchToReleasedVersionAction, MigrateDeprecatedExtensionAction, SetLanguageAction } from 'vs/workbench/contrib/extensions/browser/extensionsActions'; </del> <ins> import { UpdateAction, ManageExtensionAction, ReloadAction, ExtensionStatusLabelAction, RemoteInstallAction, ExtensionStatusAction, LocalInstallAction, ActionWithDropDownAction, InstallDropdownAction, InstallingLabelAction, ExtensionActionWithDropdownActionViewItem, ExtensionDropDownAction, WebInstallAction, SwitchToPreReleaseVersionAction, SwitchToReleasedVersionAction, MigrateDeprecatedExtensionAction, SetLanguageAction, ClearLanguageAction } from 'vs/workbench/contrib/extensions/browser/extensionsActions'; </ins> import { areSameExtensions } from 'vs/platform/extensionManagement/common/extensionManagementUtil'; import { RatingsWidget, InstallCountWidget, RecommendationWidget, RemoteBadgeWidget, ExtensionPackCountWidget as ExtensionPackBadgeWidget, SyncIgnoredWidget, ExtensionHoverWidget, ExtensionActivationStatusWidget, PreReleaseBookmarkWidget, extensionVerifiedPublisherIconColor } from 'vs/workbench/contrib/extensions/browser/extensionsWidgets'; import { IExtensionService, toExtension } from 'vs/workbench/services/extensions/common/extensions';

Related discussion:
text: Testing Just like I can set the display language in the compact presentation of the extension view, I'd have expected to be able to reset the display language there in addition to the details page of the extension. <img width="1118" alt="image" src="https://user-"
Code change:
optionalDependencies: "@vscode/windows-ca-certs" "^0.3.1" <del> "@vscode/ripgrep@^1.15.4": version "1.15.4" resolved "https://registry.yarnpkg.com/@vscode/ripgrep/-/ripgrep-1.15.4.tgz#ca8946b5580bbea1e706ed8d3b1eed5f0d551ab6" integrity sha512-+EPIS2aoD95MFLrgGHd/D2fck42aMRV2cBrT7BiNvKBeSyCTybSaTJ+PGQf6zV/95AhaXHHYqYPVRk3DZoGU9w== </del> <ins> "@vscode/ripgrep@^1.15.5": version "1.15.5" resolved "https://registry.yarnpkg.com/@vscode/ripgrep/-/ripgrep-1.15.5.tgz#26025884bbc3a8b40dfc29f5bda4b87b47bd7356" integrity sha512-PVvKNEmtnlek3i4MJMaB910dz46CKQqcIY2gKR3PSlfz/ZPlSYuSuyQMS7iK20KL4hGUdSbWt964B5S5EIojqw== </ins> dependencies: https-proxy-agent "^5.0.0" proxy-from-env "^1.1.0"

Related discussion:
text: From Probably a regression from making aarch64-linux ripgrep build statically compiled to fix We might need to dynamically compile ripgrep instead of using musl, and find a container to compile it in. related // cc
Looks like jemalloc just needs to be configured with to support 16K page size. This can be achieved by setting the environment variable: (16K page size) Or to support 64K page size as well: (64K page size) In either case, it'd still work for 4K/16K(/64K) page sizes.
Do we have any good news on this? I found the similar thing happened before on other application like , probably we can use the same approach to solve this one?
Any update on this issue ?
Temporary Workaround: To address the issue until it is fixed, follow these steps: Install ripgrep and obtain its path. For Rocky Linux or any RHEL-based Linux distribution, run the following command with root privileges: For Ubuntu, use the following command: Alternatively, you can install ripgrep using Cargo: Verify the installation and retrieve the path by running: Replace the broken rg with a symlink by executing the following script. Please note that you should remove the echo commands to commit the changes: This workaround should help resolve the issue temporarily.
This should be fixed in tomorrow's VS Code Insiders. Please try it out and let me know if it works for you!
I tried but it seems not fixed or not included the fix. execute from the remote server(aarch64) and got <jemalloc: Unsupported system page size <jemalloc: Unsupported system page size memory allocation of 5 bytes failed find: ‘.vscode-server-insiders/bin//nodemodules/ terminated by signal 6 (after resetting the remote environment by deleting .vscode-server-insiders folder on the remote, and vscode reloaded. - 'Developer: Reload Window')
Are you running 16K page size or 64K?
I got $ getconf PAGESIZE on the aarch64 remote (Rocky Linux 8, aws r7g instance/Graviton3 processors).
Code change:
optionalDependencies: "@vscode/windows-ca-certs" "^0.3.1" <del> "@vscode/ripgrep@^1.15.4": version "1.15.4" resolved "https://registry.yarnpkg.com/@vscode/ripgrep/-/ripgrep-1.15.4.tgz#ca8946b5580bbea1e706ed8d3b1eed5f0d551ab6" integrity sha512-+EPIS2aoD95MFLrgGHd/D2fck42aMRV2cBrT7BiNvKBeSyCTybSaTJ+PGQf6zV/95AhaXHHYqYPVRk3DZoGU9w== </del> <ins> "@vscode/ripgrep@^1.15.5": version "1.15.5" resolved "https://registry.yarnpkg.com/@vscode/ripgrep/-/ripgrep-1.15.5.tgz#26025884bbc3a8b40dfc29f5bda4b87b47bd7356" integrity sha512-PVvKNEmtnlek3i4MJMaB910dz46CKQqcIY2gKR3PSlfz/ZPlSYuSuyQMS7iK20KL4hGUdSbWt964B5S5EIojqw== </ins> dependencies: https-proxy-agent "^5.0.0" proxy-from-env "^1.1.0"

Related discussion:
text: Meanwhile, executing the same command above on x86-64 remote, I got the normal rg help print out as like error: The following required arguments were not provided: and correcting the hand typed typo above of vscode insider version info Version: 1.79.0-insider (user setup) Commit: Date: 2023-05-19T20:39:14.598Z Electron: 22.5.2 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: WindowsNT x64 10.0.
Hmm ok. I tried setting the env variable to increase max page size for jemalloc, but it seems to not be working. I'll try another approach.
If you let me know what you are attempting, I can also try out some stuff. Page size here is
Is this fixed in the latest release version of VScode? I just check on my arm64 container but it seems not working. VScode Version: 1.79.0 (Universal)
Same with Switched to newest insider build. . Problem not solved. Went to server, killed and deleted . Tried again to bootstrap. Problem is still NOT resolved. Search is still limited to open files.
!
Here is some useful link detailing what I think is the problem. Not sure if it is resolved by now. But if info from the discussion is current, I think you will have to either compile on the target system, or ship different precompiled versions of binary and select the correct one depending on the system specs (see ).
We do cross-compile for different systems for ripgrep I'll have to take another look.
So, my interpretation is, that the page-size is hard-coded into jemalloc. When the system page size at runtime differs from the one it is compiled for, it will fail. In other words, the one shipped right now fails out of the box: From your linked repo, I understand that you now focus on 16k page size. That would also not help me (if my suspicion is right), as my system's page size is: 64k
: Temporary fix. Bootstrap on target ARM system. You should have a directory called now. That is where the vscode server lives.
Code change:
optionalDependencies: "@vscode/windows-ca-certs" "^0.3.1" <del> "@vscode/ripgrep@^1.15.4": version "1.15.4" resolved "https://registry.yarnpkg.com/@vscode/ripgrep/-/ripgrep-1.15.4.tgz#ca8946b5580bbea1e706ed8d3b1eed5f0d551ab6" integrity sha512-+EPIS2aoD95MFLrgGHd/D2fck42aMRV2cBrT7BiNvKBeSyCTybSaTJ+PGQf6zV/95AhaXHHYqYPVRk3DZoGU9w== </del> <ins> "@vscode/ripgrep@^1.15.5": version "1.15.5" resolved "https://registry.yarnpkg.com/@vscode/ripgrep/-/ripgrep-1.15.5.tgz#26025884bbc3a8b40dfc29f5bda4b87b47bd7356" integrity sha512-PVvKNEmtnlek3i4MJMaB910dz46CKQqcIY2gKR3PSlfz/ZPlSYuSuyQMS7iK20KL4hGUdSbWt964B5S5EIojqw== </ins> dependencies: https-proxy-agent "^5.0.0" proxy-from-env "^1.1.0"

Related discussion:
text: Download and compile : Replace binary deployed by with custom compiled version. Now search should work as expected.
can you check if the following runs fine on your aarch64 setup ? The build is generated from to use 64k for jemalloc.
Thanks built from source works for me!
can any of you verify this:
I untar-ed the file and the binary 'rg' is working good with remote search. (I sym-linked it with vscode 1.79)
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
I can confirm it is fixed with the vscode insider downloaded a minute ago of (assume the commit hash changed since)
thanks so much for checking!
Code change:
this._register(this.workingCopyService.onDidChangeDirty(workingCopy => this.dirtyWorkingCopiesContext.set(workingCopy.isDirty() || this.workingCopyService.hasDirty))); } <ins> private updateVisiblePanesContextKeys(): void { const visibleEditorPanes = this.editorService.visibleEditorPanes; if (visibleEditorPanes.length > 0) { this.editorsVisibleContext.set(true); } else { this.editorsVisibleContext.reset(); } } private updateEditorGroupContextKeys(): void { if (!this.editorService.activeEditor) { this.activeEditorGroupEmpty.set(true); } else { this.activeEditorGroupEmpty.reset(); } this.updateEditorGroupsContextKeys(); } private updateEditorGroupsContextKeys(): void { const groupCount = this.editorGroupService.count; if (groupCount > 1) { this.multipleEditorGroupsContext.set(true); } else { this.multipleEditorGroupsContext.reset(); } const activeGroup = this.editorGroupService.activeGroup; this.activeEditorGroupIndex.set(activeGroup.index + 1); // not zero-indexed this.activeEditorGroupLast.set(activeGroup.index === groupCount - 1); this.activeEditorGroupLocked.set(activeGroup.isLocked); } </ins> private updateEditorAreaContextKeys(): void { this.editorTabsVisibleContext.set(this.editorGroupService.partOptions.showTabs === 'multiple'); }

Related discussion:
text: Reproduced on OSS, Mac Steps to Reproduce: Code OSS a file cmd+w Closes the window Bisect points to this commit -
I can reproduce and this is likely context keys not being set properly because conditionally closes the window if no active editor. !
There are context keys that are now loose, for example
Follow up work
Code change:
id: MenuId.EditorTitle, when: ctxIsMergeEditor, group: 'navigation', <ins> order: 2 </ins> }, ], f1: true,

Related discussion:
text: Same as when opening a diff editor, a merge editor should offer a way to open the regular file (not in 3 way merge mode). Same as diff editor it could use an action in the editor title area !
Let's move this to July
To verify: open a merge editor verify its title bar has a command to open the result file
I wonder if "Open Changes" button should go back to the merge editor then? !
Code change:
this._commentThreadDisposables.push(this._commentThread.onDidChangeCollapsibleState(state => { if (state === languages.CommentThreadCollapsibleState.Expanded && !this._isExpanded) { this.show(this.arrowPosition(this._commentThread.range), 2); <ins> this._commentThreadWidget.ensureFocusIntoNewEditingComment(); </ins> return; }

Related discussion:
text: !
Caused by I caused when I fixed an issue when there are multiple text editors open with the same uri with comments. When I tried to fix I made it so when extensions call and pass in for the comments, we always expand the reply editor, resulting in the bad behavior above. I took a quick look, and it seems very common for extensions to pass in for the comments and then immediately set them.
To verify: Check out PR with comments that you left Reload to make sure there's not state left over from when you left the comments Open the file with the comments and click on the comment icon in the comment bar to expand a comment that you left Verify that the reply input button is collapsed and isn't a big empty rectangle.
Works great -verified.
<!-- UNABLETOLOCATECOMMITMESSAGE repo --Issue marked as unreleased but unable to locate closing commit in repo history. If this was closed in a separate repo you can add the label directly, or comment .
<!-- UNABLETOLOCATECOMMITMESSAGE --Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting , or directly add the label if you know this has already been releaased
Code change:
.monaco-action-bar .action-item.disabled .action-label.extension-action.uninstall:not(.uninstalling), .monaco-action-bar .action-item.disabled .action-label.extension-action.hide-when-disabled, .monaco-action-bar .action-item.disabled .action-label.extension-action.update, <ins> .monaco-action-bar .action-item.disabled .action-label.extension-action.migrate, </ins> .monaco-action-bar .action-item.disabled .action-label.extension-action.theme, .monaco-action-bar .action-item.disabled .action-label.extension-action.extension-sync, .monaco-action-bar .action-item.action-dropdown-item.disabled,

Related discussion:
text: Code, search for "bracket pair colorizer" how it is nicely rendered as deprecated on install -notice dialog The dialog should offer a third button to configure built-in settings instead. Same if an extension had an alternative extension. Example: ! fyi
I assume you want the extra button to replicate this link in the hover tip, right? ! As an aside, any doc yet about how an extension gets tagged as deprecated?
yes, a button that will replicate that behaviour correct. No docs yet written. I plan to add them soon. The process is to write an email to us or to ping us on GitHub. In the future we will have a more straightforward approach when MP adds UI.
I feel, the third option would be a general options like More Information... clicking on this shall open the extension editor. This will be consistent and useful so that user will get enough info before taking an action
"More Information..." might work, but in order to have one less hop we could render: "Install EXTENSION_NAME Instead" "Enable Native Settings Instead" That would just do the action right straight away. I am not sure if those button names are too long. So just a suggestion. Whatever you prefer...
Yah I see your point, but going to extension editor gives user more information and an opportunity to look at the alternative extension before installing. And also I do not like that this button changes with extension. More Information... would be consistent.
That's fair. We can start with your proposal and see how it goes. My only concern with "More Information" is that the user might think it is more information about the deprecation. While we actually want to guide the user to a solution. So it is something like "More about the alternative". I am not sure if there is a good button label to represent this.
<img width="308" alt="image (1)" src="https://user-"
Changed the second button as follows ! !
Awesome!!
Code change:
return computeLinks(target); } <del> function extractLinks(text: string): string { const keep: boolean[] = []; const links = myComputeLinks([text]); for (const link of links) { const startChar = link.range.startColumn - 1; const endChar = link.range.endColumn - 1; for (let char = startChar; char < endChar; char++) { keep[char] = true; </del> <ins> function assertLink(text: string, extractedLink: string): void { let startColumn = 0, endColumn = 0, chr: string, i = 0; for (i = 0; i < extractedLink.length; i++) { chr = extractedLink.charAt(i); if (chr !== ' ' && chr !== 't') { startColumn = i + 1; break; </ins> } } <del> const result: string[] = []; for (let i = 0; i < text.length; i++) { if (keep[i]) { result.push(text.charAt(i)); } else { result.push(' '); </del> <ins> for (i = extractedLink.length - 1; i >= 0; i--) { chr = extractedLink.charAt(i); if (chr !== ' ' && chr !== 't') { endColumn = i + 2; break; </ins> } } <del> return result.join(''); } function assertLink(text: string, expectedLinks: string): void { assert.deepStrictEqual(extractLinks(text), expectedLinks); </del> <ins> const r = myComputeLinks([text]); assert.deepStrictEqual(r, [{ range: { startLineNumber: 1, startColumn: startColumn, endLineNumber: 1, endColumn: endColumn }, url: extractedLink.substring(startColumn - 1, endColumn - 1) }]); </ins> } suite('Editor Modes - Link Computer', () => {

Related discussion:
text: VS Code Version: 1.75.1 OS Version: Windows 10 Steps to reproduce: a file and paste the following code into it: an file and paste the following url into it: . both cases the link detection wrongly terminates at the so the link cannot be easily clicked to open it.
:+1: I'm OK to revert.
Code change:
$ErrorActionPreference = "Stop" exec { node build/azure-pipelines/common/listNodeModules.js .build/node_modules_list.txt } exec { mkdir -Force .build/node_modules_cache } <del> exec { 7z.exe a .build/node_modules_cache/cache.7z -mx3 -bb `@.build/node_modules_list.txt } </del> <ins> exec { 7z.exe a .build/node_modules_cache/cache.7z -mx3 `@.build/node_modules_list.txt } </ins> condition: and(succeeded(), ne(variables.NODE_MODULES_RESTORED, 'true')) displayName: Create node_modules archive

Related discussion:
text: A similar error has appeared for other Azure Pipelines tasks
Odd: one is about extracting first one shows no error at all (copy paste mistake?) second one is about creating a zip
This might actually be a bug on AZDO:
And we might be hitting it due to logging every single file. Let's stop doing that.
I reran the failure for the first one which is why it no longer shows an error here's the precise link to the failure
Thanks!
Code change:
resolved "https://registry.yarnpkg.com/wrappy/-/wrappy-1.0.2.tgz#b5243d8f3ec1aa35f1364605bc0d1036e30ab69f" integrity sha1-tSQ9jz7BqjXxNkYFvA0QNuMKtp8= <del> xterm-addon-search@0.9.0-beta.21: version "0.9.0-beta.21" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.21.tgz#5348fe25676cdd89ce3be52ae62a316b6f266176" integrity sha512-jh6kfRCpWRvZZkV9QghFYesSYHjybaLNEyYAD6uilZYfNHoGLa0zPgUkLOqoECL7K6rhBmSYOkKbc9MG4wNFMQ== </del> <ins> xterm-addon-search@0.9.0-beta.22: version "0.9.0-beta.22" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.22.tgz#18f2eabda82709cdd64dee003879b586869e28a3" integrity sha512-1I8W0bwjg6bUoNaESKHSkS9BN3Z9Xe44/zbUb6Un+pbb5Nun4LQvFwSLkAIdRrslxcbcHYIU/2Q7F1wCOWLbaA== </ins> xterm-addon-serialize@0.7.0-beta.12: version "0.7.0-beta.12"

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.67.0-insiders OS Version: macOS 12.3.1 Steps to Reproduce: the terminal scrollback to 30'000 for With version 1.65.0 this was not a problem, but there was no highlighting. It would be enough if I can disable the highlighting or disable the highlighting automatically if the history is longer than x lines. https://user-
That doesn't look or feel slow to me - can you elaborate on what the issue you're dealing with is?
Is it Upstream or VSCode Core.
Happens for me too, when you search then type abs quickly and it takes ~5-10 seconds for the letters to appear, same goes with erasing letters.
Search is fast now but matches info is not being shown -
Code change:
} } <ins> ensureFocusIntoNewEditingComment() { this._body.ensureFocusIntoNewEditingComment(); } </ins> focusCommentEditor() { this._commentReply?.expandReplyAreaAndFocusCommentEditor(); }

Related discussion:
text: !
Caused by I caused when I fixed an issue when there are multiple text editors open with the same uri with comments. When I tried to fix I made it so when extensions call and pass in for the comments, we always expand the reply editor, resulting in the bad behavior above. I took a quick look, and it seems very common for extensions to pass in for the comments and then immediately set them.
To verify: Check out PR with comments that you left Reload to make sure there's not state left over from when you left the comments Open the file with the comments and click on the comment icon in the comment bar to expand a comment that you left Verify that the reply input button is collapsed and isn't a big empty rectangle.
Works great -verified.
<!-- UNABLETOLOCATECOMMITMESSAGE repo --Issue marked as unreleased but unable to locate closing commit in repo history. If this was closed in a separate repo you can add the label directly, or comment .
<!-- UNABLETOLOCATECOMMITMESSAGE --Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting , or directly add the label if you know this has already been releaased
Code change:
*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <del> import { ExtensionContext, OutputChannel, window, workspace, l10n } from 'vscode'; </del> <ins> import { ExtensionContext, OutputChannel, window, workspace, l10n, env } from 'vscode'; </ins> import { startClient, LanguageClientConstructor, SchemaRequestService, languageServerDescription } from '../jsonClient'; import { ServerOptions, TransportKind, LanguageClientOptions, LanguageClient, BaseLanguageClient } from 'vscode-languageclient/node';

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.79.2 OS Version: Darwin x64 22.5.0 Steps to Reproduce: a webserver at serving a single schema at containing (the precise contents don't really matter) a file , and paste in: the cursor between the quotes just after the trailing slash , and look at the webserver logs, observing no user agent was sent
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.80.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
I suggest to verify this in code: