jiebi/CodeConvo huggingface dataset:
Code change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.48.2- -1.49.0- OS Version: Ubuntu 20.04.1 LTS Steps to Reproduce: -dev not installed and install code1.48.2- --VSCode works apt update; apt-upgrade VSCode to 1.49.0- --VSCode fails with: /usr/share/code/bin/../code: error while loading shared libraries: cannot open shared object file: No such file or directory install libgbm-dev --VSCode works Expected: upgrade checks for dependency and installs missing library
new Electron 9 dep needs to be declared here?
I didn't know about this dependency configuration in the codebase, yes adding should be sufficient. It is a new dependency for chromium 83 to use memory buffers in gpu code path.
This bug has been fixed in to the latest release of ! you can help us out by confirming things are working as expected in the latest Insiders release. If things look good, please leave a comment with the text to let us know. If not, please ensure you're on version of Insiders (today's or later - you can use in the command pallete to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Tested this by upgrading from 1.48.2 to 1.50.1

Related discussion:
text: Package: @@NAME@@ Version: @@VERSION@@ Section: devel <del> Depends: libnss3 (>= 2:3.26), gnupg, apt, libxkbfile1, libsecret-1-0, libgtk-3-0 (>= 3.10.0), libxss1 </del> <ins> Depends: libnss3 (>= 2:3.26), gnupg, apt, libxkbfile1, libsecret-1-0, libgtk-3-0 (>= 3.10.0), libxss1, libgbm1 </ins> Priority: optional Architecture: @@ARCHITECTURE@@ Maintainer: Microsoft Corporation <vscode-linux@microsoft.com>
Code change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.48.2- -1.49.0- OS Version: Ubuntu 20.04.1 LTS Steps to Reproduce: -dev not installed and install code1.48.2- --VSCode works apt update; apt-upgrade VSCode to 1.49.0- --VSCode fails with: /usr/share/code/bin/../code: error while loading shared libraries: cannot open shared object file: No such file or directory install libgbm-dev --VSCode works Expected: upgrade checks for dependency and installs missing library
new Electron 9 dep needs to be declared here?
I didn't know about this dependency configuration in the codebase, yes adding should be sufficient. It is a new dependency for chromium 83 to use memory buffers in gpu code path.
This bug has been fixed in to the latest release of ! you can help us out by confirming things are working as expected in the latest Insiders release. If things look good, please leave a comment with the text to let us know. If not, please ensure you're on version of Insiders (today's or later - you can use in the command pallete to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Tested this by upgrading from 1.48.2 to 1.50.1

Related discussion:
text: "libc.so.6(GLIBC_2.9)(64bit)", "libxcb.so.1()(64bit)", "libxkbfile.so.1()(64bit)", <del> "libsecret-1.so.0()(64bit)" </del> <ins> "libsecret-1.so.0()(64bit)", "libgbm.so.1()(64bit)" </ins> ], "aarch64": [ "libpthread.so.0()(aarch64)",
Code change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.48.2- -1.49.0- OS Version: Ubuntu 20.04.1 LTS Steps to Reproduce: -dev not installed and install code1.48.2- --VSCode works apt update; apt-upgrade VSCode to 1.49.0- --VSCode fails with: /usr/share/code/bin/../code: error while loading shared libraries: cannot open shared object file: No such file or directory install libgbm-dev --VSCode works Expected: upgrade checks for dependency and installs missing library
new Electron 9 dep needs to be declared here?
I didn't know about this dependency configuration in the codebase, yes adding should be sufficient. It is a new dependency for chromium 83 to use memory buffers in gpu code path.
This bug has been fixed in to the latest release of ! you can help us out by confirming things are working as expected in the latest Insiders release. If things look good, please leave a comment with the text to let us know. If not, please ensure you're on version of Insiders (today's or later - you can use in the command pallete to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Tested this by upgrading from 1.48.2 to 1.50.1

Related discussion:
text: - libgconf-2-4 - libglib2.0-bin - libgnome-keyring0 <ins> - libgbm1 </ins> - libgtk-3-0 - libnotify4 - libnspr4
Code change:
It does fire for folder on move and delete. According to the reason lies here: The code goes directly to the file service. Since we correctly report move and delete for folders I think we should report create as well.
Some background: I want to adopt this in LSP but specing that this only works for move and delete of folders sounds a little silly. So I want to make sure that there is either a very compelling reason or there is some ack. that we will fix it in the future.
We currently have no related method such as for folders that the explorer could use here: If we support this, I guess one question in terms of API breakage is wether it is fine to let and emit events for folders too while they currently only emit for files. If we think this is fine, then I think this would be a relatively simple change to make.
I don't consider that breakage, it's a bug fix esp. given that move and delete already fire events for both
Verification: write an extension that registers to and and verify you see both events when you right click into the explorer and create a new folder.
Thanks for fixing!

Related discussion:
text: const editorService = accessor.get(IEditorService); const viewsService = accessor.get(IViewsService); const notificationService = accessor.get(INotificationService); <ins> const workingCopyFileService = accessor.get(IWorkingCopyFileService); </ins> await viewsService.openView(VIEW_ID, true);
Code change:
It does fire for folder on move and delete. According to the reason lies here: The code goes directly to the file service. Since we correctly report move and delete for folders I think we should report create as well.
Some background: I want to adopt this in LSP but specing that this only works for move and delete of folders sounds a little silly. So I want to make sure that there is either a very compelling reason or there is some ack. that we will fix it in the future.
We currently have no related method such as for folders that the explorer could use here: If we support this, I guess one question in terms of API breakage is wether it is fine to let and emit events for folders too while they currently only emit for files. If we think this is fine, then I think this would be a relatively simple change to make.
I don't consider that breakage, it's a bug fix esp. given that move and delete already fire events for both
Verification: write an extension that registers to and and verify you see both events when you right click into the explorer and create a new folder.
Thanks for fixing!

Related discussion:
text: const onSuccess = async (value: string): Promise<void> => { try { <del> const created = isFolder ? await fileService.createFolder(resources.joinPath(folder.resource, value)) : await textFileService.create(resources.joinPath(folder.resource, value)); </del> <ins> const created = isFolder ? await workingCopyFileService.createFolder(resources.joinPath(folder.resource, value)) : await textFileService.create(resources.joinPath(folder.resource, value)); </ins> await refreshIfSeparator(value, explorerService); isFolder ?
Code change:
It does fire for folder on move and delete. According to the reason lies here: The code goes directly to the file service. Since we correctly report move and delete for folders I think we should report create as well.
Some background: I want to adopt this in LSP but specing that this only works for move and delete of folders sounds a little silly. So I want to make sure that there is either a very compelling reason or there is some ack. that we will fix it in the future.
We currently have no related method such as for folders that the explorer could use here: If we support this, I guess one question in terms of API breakage is wether it is fine to let and emit events for folders too while they currently only emit for files. If we think this is fine, then I think this would be a relatively simple change to make.
I don't consider that breakage, it's a bug fix esp. given that move and delete already fire events for both
Verification: write an extension that registers to and and verify you see both events when you right click into the explorer and create a new folder.
Thanks for fixing!

Related discussion:
text: create(resource: URI, contents?: VSBuffer | VSBufferReadable | VSBufferReadableStream, options?: { overwrite?: boolean }): Promise<IFileStatWithMetadata>; /** <ins> * Will create a folder and any parent folder that needs to be created. * * Working copy owners can listen to the `onWillRunWorkingCopyFileOperation` and * `onDidRunWorkingCopyFileOperation` events to participate. * * Note: events will only be emitted for the provided resource, but not any * parent folders that are being created as part of the operation. */ createFolder(resource: URI): Promise<IFileStatWithMetadata>; /** </ins> * Will move working copies matching the provided resources and corresponding children * to the target resources using the associated file service for those resources. *
Code change:
It does fire for folder on move and delete. According to the reason lies here: The code goes directly to the file service. Since we correctly report move and delete for folders I think we should report create as well.
Some background: I want to adopt this in LSP but specing that this only works for move and delete of folders sounds a little silly. So I want to make sure that there is either a very compelling reason or there is some ack. that we will fix it in the future.
We currently have no related method such as for folders that the explorer could use here: If we support this, I guess one question in terms of API breakage is wether it is fine to let and emit events for folders too while they currently only emit for files. If we think this is fine, then I think this would be a relatively simple change to make.
I don't consider that breakage, it's a bug fix esp. given that move and delete already fire events for both
Verification: write an extension that registers to and and verify you see both events when you right click into the explorer and create a new folder.
Thanks for fixing!

Related discussion:
text: //#region File operations <del> async create(resource: URI, contents?: VSBuffer | VSBufferReadable | VSBufferReadableStream, options?: { overwrite?: boolean }): Promise<IFileStatWithMetadata> { </del> <ins> create(resource: URI, contents?: VSBuffer | VSBufferReadable | VSBufferReadableStream, options?: { overwrite?: boolean }): Promise<IFileStatWithMetadata> { return this.doCreateFileOrFolder(resource, true, contents, options); } createFolder(resource: URI, options?: { overwrite?: boolean }): Promise<IFileStatWithMetadata> { return this.doCreateFileOrFolder(resource, false); } async doCreateFileOrFolder(resource: URI, isFile: boolean, contents?: VSBuffer | VSBufferReadable | VSBufferReadableStream, options?: { overwrite?: boolean }): Promise<IFileStatWithMetadata> { </ins> // validate create operation before starting <del> const validateCreate = await this.fileService.canCreateFile(resource, options); if (validateCreate instanceof Error) { throw validateCreate; </del> <ins> if (isFile) { const validateCreate = await this.fileService.canCreateFile(resource, options); if (validateCreate instanceof Error) { throw validateCreate; } </ins> } // file operation participant
Code change:
It does fire for folder on move and delete. According to the reason lies here: The code goes directly to the file service. Since we correctly report move and delete for folders I think we should report create as well.
Some background: I want to adopt this in LSP but specing that this only works for move and delete of folders sounds a little silly. So I want to make sure that there is either a very compelling reason or there is some ack. that we will fix it in the future.
We currently have no related method such as for folders that the explorer could use here: If we support this, I guess one question in terms of API breakage is wether it is fine to let and emit events for folders too while they currently only emit for files. If we think this is fine, then I think this would be a relatively simple change to make.
I don't consider that breakage, it's a bug fix esp. given that move and delete already fire events for both
Verification: write an extension that registers to and and verify you see both events when you right click into the explorer and create a new folder.
Thanks for fixing!

Related discussion:
text: // now actually create on disk let stat: IFileStatWithMetadata; try { <del> stat = await this.fileService.createFile(resource, contents, { overwrite: options?.overwrite }); </del> <ins> if (isFile) { stat = await this.fileService.createFile(resource, contents, { overwrite: options?.overwrite }); } else { stat = await this.fileService.createFolder(resource); } </ins> } catch (error) { // error event
Code change:
It does fire for folder on move and delete. According to the reason lies here: The code goes directly to the file service. Since we correctly report move and delete for folders I think we should report create as well.
Some background: I want to adopt this in LSP but specing that this only works for move and delete of folders sounds a little silly. So I want to make sure that there is either a very compelling reason or there is some ack. that we will fix it in the future.
We currently have no related method such as for folders that the explorer could use here: If we support this, I guess one question in terms of API breakage is wether it is fine to let and emit events for folders too while they currently only emit for files. If we think this is fine, then I think this would be a relatively simple change to make.
I don't consider that breakage, it's a bug fix esp. given that move and delete already fire events for both
Verification: write an extension that registers to and and verify you see both events when you right click into the explorer and create a new folder.
Thanks for fixing!

Related discussion:
text: model1.dispose(); }); <ins> test('createFolder', async function () { let eventCounter = 0; let correlationId: number | undefined = undefined; const resource = toResource.call(this, '/path/folder'); const participant = accessor.workingCopyFileService.addFileOperationParticipant({ participate: async (files, operation) => { assert.equal(files.length, 1); const file = files[0]; assert.equal(file.target.toString(), resource.toString()); assert.equal(operation, FileOperation.CREATE); eventCounter++; } }); const listener1 = accessor.workingCopyFileService.onWillRunWorkingCopyFileOperation(e => { assert.equal(e.files.length, 1); const file = e.files[0]; assert.equal(file.target.toString(), resource.toString()); assert.equal(e.operation, FileOperation.CREATE); correlationId = e.correlationId; eventCounter++; }); const listener2 = accessor.workingCopyFileService.onDidRunWorkingCopyFileOperation(e => { assert.equal(e.files.length, 1); const file = e.files[0]; assert.equal(file.target.toString(), resource.toString()); assert.equal(e.operation, FileOperation.CREATE); assert.equal(e.correlationId, correlationId); eventCounter++; }); await accessor.workingCopyFileService.createFolder(resource); assert.equal(eventCounter, 3); participant.dispose(); listener1.dispose(); listener2.dispose(); }); </ins> async function testEventsMoveOrCopy(files: { source: URI, target: URI }[], move?: boolean): Promise<number> { let eventCounter = 0;
Code change:
It does fire for folder on move and delete. According to the reason lies here: The code goes directly to the file service. Since we correctly report move and delete for folders I think we should report create as well.
Some background: I want to adopt this in LSP but specing that this only works for move and delete of folders sounds a little silly. So I want to make sure that there is either a very compelling reason or there is some ack. that we will fix it in the future.
We currently have no related method such as for folders that the explorer could use here: If we support this, I guess one question in terms of API breakage is wether it is fine to let and emit events for folders too while they currently only emit for files. If we think this is fine, then I think this would be a relatively simple change to make.
I don't consider that breakage, it's a bug fix esp. given that move and delete already fire events for both
Verification: write an extension that registers to and and verify you see both events when you right click into the explorer and create a new folder.
Thanks for fixing!

Related discussion:
text: move(_source: URI, _target: URI, _overwrite?: boolean): Promise<IFileStatWithMetadata> { return Promise.resolve(null!); } copy(_source: URI, _target: URI, _overwrite?: boolean): Promise<IFileStatWithMetadata> { return Promise.resolve(null!); } createFile(_resource: URI, _content?: VSBuffer | VSBufferReadable, _options?: ICreateFileOptions): Promise<IFileStatWithMetadata> { return Promise.resolve(null!); } <del> createFolder(_resource: URI): Promise<IFileStatWithMetadata> { throw new Error('not implemented'); } </del> <ins> createFolder(_resource: URI): Promise<IFileStatWithMetadata> { return Promise.resolve(null!); } </ins> onDidChangeFileSystemProviderRegistrations = Event.None;
Code change:
It does fire for folder on move and delete. According to the reason lies here: The code goes directly to the file service. Since we correctly report move and delete for folders I think we should report create as well.
Some background: I want to adopt this in LSP but specing that this only works for move and delete of folders sounds a little silly. So I want to make sure that there is either a very compelling reason or there is some ack. that we will fix it in the future.
We currently have no related method such as for folders that the explorer could use here: If we support this, I guess one question in terms of API breakage is wether it is fine to let and emit events for folders too while they currently only emit for files. If we think this is fine, then I think this would be a relatively simple change to make.
I don't consider that breakage, it's a bug fix esp. given that move and delete already fire events for both
Verification: write an extension that registers to and and verify you see both events when you right click into the explorer and create a new folder.
Thanks for fixing!

Related discussion:
text: getDirty(resource: URI): IWorkingCopy[] { return []; } create(resource: URI, contents?: VSBuffer | VSBufferReadable | VSBufferReadableStream, options?: { overwrite?: boolean | undefined; } | undefined): Promise<IFileStatWithMetadata> { throw new Error('Method not implemented.'); } <ins> createFolder(resource: URI): Promise<IFileStatWithMetadata> { throw new Error('Method not implemented.'); } </ins> move(files: { source: URI; target: URI; }[], options?: { overwrite?: boolean }): Promise<IFileStatWithMetadata[]> { throw new Error('Method not implemented.'); }
Code change:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --This would prevent needing to convert the to a string only for it to be parsed back into a later on, and is friendlier to developers.
proposed or finalized?

Related discussion:
text: * @param pattern A file glob pattern like `*.{ts,js}` that will be matched on file paths * relative to the base path. */ <del> constructor(base: WorkspaceFolder | string, pattern: string) </del> <ins> constructor(base: Uri | WorkspaceFolder | string, pattern: string) </ins> } /**
Code change:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --This would prevent needing to convert the to a string only for it to be parsed back into a later on, and is friendlier to developers.
proposed or finalized?

Related discussion:
text: pattern: string; <del> constructor(base: vscode.WorkspaceFolder | string, pattern: string) { </del> <ins> constructor(base: URI | vscode.WorkspaceFolder | string, pattern: string) { </ins> if (typeof base !== 'string') { <del> if (!base || !URI.isUri(base.uri)) { </del> <ins> if (!base || !URI.isUri(base) && !URI.isUri(base.uri)) { </ins> throw illegalArgument('base'); } }
Code change:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --This would prevent needing to convert the to a string only for it to be parsed back into a later on, and is friendlier to developers.
proposed or finalized?

Related discussion:
text: if (typeof base === 'string') { this.base = base; <ins> } else if (URI.isUri(base)) { this.baseFolder = base; this.base = base.fsPath; </ins> } else { this.baseFolder = base.uri; this.base = base.uri.fsPath;
Code change:
Update: reproduces in web + desktop Steps to Reproduce: a Codespace until it is loaded various activity bar items that open menus (gear menu, accounts, main menu, home indicator) = somehow the accounts menu only opens for me after a delay, as if something was resolved when clicking? !
This still reproduces
does this still repro? maybe its imperceptible to me?
Yeah still seems slightly delayed to me, can we not check the code and see if a longer running promise prevents the menu from showing?
looks like we fetch session info every time, so this probably adds some delay. maybe this can be cached and updated separately
Yeah that seems like a reasonable ask since it goes to the extension host and back, today.
This issue has existed since 2 years! But only recently have I encountered this.

Related discussion:
text: import { IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; import { createAndFillInActionBarActions } from 'vs/platform/actions/browser/menuEntryActionViewItem'; import { getCurrentAuthenticationSessionInfo } from 'vs/workbench/services/authentication/browser/authenticationService'; <del> import { AuthenticationSession, IAuthenticationService } from 'vs/workbench/services/authentication/common/authentication'; </del> <ins> import { AuthenticationSessionAccount, IAuthenticationService } from 'vs/workbench/services/authentication/common/authentication'; </ins> import { IWorkbenchEnvironmentService } from 'vs/workbench/services/environment/common/environmentService'; import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; import { IProductService } from 'vs/platform/product/common/productService';