Feature request: thread-sharing in Nylas Mail

Requested via https://nylas.zendesk.com/agent/tickets/9822

@hallamoore would you kindly post your request (and details here)?

Nylas N1 had a thread-sharing feature, but that feature is no longer present in Nylas mail. Can we have it back?


benches: Only use perfcnt on x86

Fixes ARM build.
Signed-off-by: Brian Anderson<EMAIL_ADDRESS>
What problem does this PR solve?
Issue Number: close https://github.com/tikv/tikv/issues/6639
Problem Summary:
Build is currently broken due to use of the perfcnt crate (and criterion-perf-events), which does not build on arm. These crates are used in a single benchmark.
What is changed and how it works?
What's Changed:
Only use these crates on x86.
Related changes
Check List
Release note
No release note.

/lgtm

/merge


Integrated Terminal Lags Intermittently

VSCode Version: 1.48.2(macOS Stable)
OS Version: macOS Big Sur 11.0 Beta (20A5354i) (Public Beta Release 2)

Steps to Reproduce:

Open Terminal
Spam random keys until lag is experienced Press enter, then continuously type (anything) for about 2 seconds.
Experience a very long stutter

Does this issue occur when all extensions are disabled?: Yes
This occurs on a public beta build of macOS 11. I've confirmed the same issue on two different MacBook Pro's on the same OS version, and same VS Code version.
Attached is a performance profile. You can see the spike in the integrated terminal response time at around 23000ms - 24000ms

Profile-20200826T124154.json.zip

It seems like https://github.com/microsoft/vscode/blob/f74e473238aca7b79c08be761d99a0232838ca4c/src/vs/workbench/contrib/terminal/node/terminalProcess.ts#L276
is taking a long time.

Benchmarking this call, it takes on average 800ms. It doesn't make sense, but this seems to be a Node.js x macOS beta type of issue.

I have been having this issue as well with the insiders build of vscode

@deepak1556 do you know why an exec call would be blocking the thread?

Some further notes for reference:
Monkey patching
https://github.com/microsoft/vscode/blob/a4befc3d68695645063a257493eec7957d4f7064/src/vs/workbench/contrib/terminal/browser/terminalInstance.ts#L1194
to be
async() => { this._updateProcessCwd(); }

Seems to fix the terminal from being blocked. It's still a bandaid over the underlying problem, which is child_process.exec() taking a long time to execute on macOS Big Sur Beta.

I have this issue either. +1

+1
I have this issue either and it happened after updating to macOS 11 (Big Sur) beta. I am currently on beta 9 and the issue still exists.
Version: 1.50.0
Commit: 93c2f0fbf16c5a4b10e4d5f89737d9c2c25488a3
Date: 2020-10-07T06:00:00.397Z (6 days ago)
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 20.1.0

It also occurred with me after updating to Big Sur Beta, I think it is about the beta.

Some further insights:
I have done some debugging with lldb, and have narrowed it down to fork() being the bottleneck here.

@davidzech Don't you think this might be a bug from the macOS kernel then?

+1 for having this issue; only remember seeing this issue after upgrading to Big Sur. Happy to run some debugging if anyone has any ideas.
Thanks.

@Adam2Marsh Have you built locally? To my surprise, I ran my tests on master and tag 1.50.1 and I do not experience this lag at all, yet is persistent in both Stable and Insider public releases.
An useful bisection perhaps.

@davidzech
+1 Agree, I built Code-OSS[master branch] with macOS 11.0.1[build = 20B5012d]
and I see no problem with input-lag with integrated terminal. Only for local build.
Public version of vscode still has that problem tho.

Thanks for narrowing down the issue @davidzech , we do use a custom electron build for the stable and insiders while we use https://electronjs.org/ releases for the OSS build. But I don't see any patches around the child_process code path.
Can you run the test on following electron builds, you can extract and run the electron binary, toggle developer tools from the View menu

Custom electron build v9.3.3
OSS electron build v9.3.3

@deepak1556
I've done some quick-test, by swapping Electron binaries on latest stable release vscode, both custom electron | oss electron. The issue still remains.
Also I bulit vscode-darwin[oss package] and swapped electron binaries with custom electron version, there is no issue at all.
Which might indicates it is not the problem of electron[perhaps?]

Also I bulit vscode-darwin[oss package] and swapped electron binaries with custom electron version, there is no issue at all.
Which might indicates it is not the problem of electron[perhaps?]

Interesting, then this might indicate the problem is with a packaged app vs running out of sources. @davidzech are you aware of any entitlement changes that would impact this ?

@deepak1556 I am not aware of anything intentional, but I can confirm that stripping code signature from Code Helper (Renderer) makes the problem go away.
So unfortunately, it looks like my guess from https://github.com/microsoft/vscode/issues/107103#issuecomment-696454728 looks to be accurate.

I don't think there is much to debug on electron or vscode end, would like to report this issue to apple. What is best way to do it ?

Last os update resolves the issue for me
OS: macOS Big Sur 11.0.1 20B5022a x86_64
Kernel: 20.1.0
VSCode: 1.51

I cannot confirm this, installed the latest beta yesterday. The termial had been laggish until I stripped the signature.

The issue persists with the latest macOS 11.0.1 RC2 released today. Stripping the signature helped though.

This looks similar to a problem we found: https://github.com/electron/electron/issues/26143
It seems to an Electron bug since it's reproducible when using child_process.spawn in the renderer process but not in main

This may be an Electron bug since we had these problems on Big Sur when on release.

Having the same issue on VSCode as well. Upgraded to Big Sur from Catalina last night and started having the freezing issue instantly.

@jaikens19 Same issue here.

@paulfsheridan @davidzech suggested running this in terminal: codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app
it ended up fixing the issue for me.

Same issue, thought there was something wrong with my laptop. On top of the delay in the terminal, i'm experiencing delay while typing and backspacing continuously both in terminal and while working on any files.

I am experiencing the same

@jaikens19, unfortunately, had no luck with this. Thanks though.

@paulfsheridan @davidzech suggested running this in terminal: codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app
it ended up fixing the issue for me.

This worked for me.

@paulfsheridan @davidzech suggested running this in terminal: codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app
it ended up fixing the issue for me.

I can confirm this worked for me as well!

@paulfsheridan @davidzech suggested running this in terminal: codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app
it ended up fixing the issue for me.

This also worked for me, thanks!

Above fix works for me as well. Don't forget to relaunch vscode.

@paulfsheridan @davidzech suggested running this in terminal: codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app
it ended up fixing the issue for me.

This fix seems to work for me as well.

@paulfsheridan @davidzech suggested running this in terminal: codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app
it ended up fixing the issue for me.

This workaround worked for me too ;)

Has anybody checked if this is related to Apple's recent usage of OSCP to check the validity of developer certificates when launching an executable? According to that blog post, this should only happen once for each executable, so I guess this is something else. Also, maybe I'm mixing up signatures and certificates here?

@lenaschimmel: yea, I looked at that, and it appears to be unrelated. it happens even if wifi/ethernet are off, and it's only reproducible in the electron renderer process, not the main process

Are there any drawbacks to removing the signature as suggested? Perhaps related to future updates?

You’re just removing the signature from the original app. Signatures are meant to prove the app came from a certain developer. If you know that this app you downloaded is legit, then there is no danger in removing the signature. I GUESS ⚠⚠⚠⚠.

I'm having this issue in Big Sur and removing signature as suggested above "fixes" it.

Affected also by this

I tried ran the command codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app and am still experiencing lagging in terminal. On macOs 11.0.1.

I ran the command codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app and am still experiencing lagging in terminal. On macOs 11.0.1.

Did you relaunch VS Code?

Did you relaunch VS Code?

I did, when I tried this out. It also didn't seem to do anything.

I ran the command codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app and am still experiencing lagging in terminal. On macOs 11.0.1.

Did you relaunch VS Code?

Don't hurt me but it worked after I relaunched lol.

I ran the command codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app and am still experiencing lagging in terminal. On macOs 11.0.1.

It's lagging as it was, and now Little Snitch tells me that VSCode is not signed and it's probably a malware.
Could you share with me how can is sign it again? Re-Installing the app didn't change much.

On macOS 11.0.1, fork() seems to physically copy all JIT memory regions (no-copy-on-write). On previous OS, these regions weren't accessible at all in the forked process, sort of explaining the "regression".
You can test by making a lot of mmap() calls with MAP_JIT, and then calling fork() in a playground project. (make sure you have com.apple.security.cs.allow-jit entitlement)
It would be nice if libuv used posix_spawn instead.

Aha that would also explain why the issue is not seen for child processes forked from browser process as reported by @marcello3d in the electron issue. The reason being until recently https://github.com/electron/electron/pull/26331 we have been using a different memory allocator on the browser process that doesn't MAP_JIT regions allocated, hence fork didn't have JIT regions to copy over. If this is true, @marcello3d you should see this issue in browser process with nightly release of electron https://www.electronjs.org/releases/nightly, can you confirm ?

It would be nice if libuv used posix_spawn instead.

@davidzech there seems to be an active issue about using posix_spawn for a different scenario on all platforms https://github.com/libuv/libuv/issues/2133 , lets make this suggestion in the electron thread so that the team can drive the effort to make the change atleast on macOS to circumvent this issue.

@deepak1556  Yes, I just confirmed that the problem exists in the browser process (electron "main") with the latest nightly.

thanks for confirming!

This started happening for me when I upgraded to macOS Big Sur 11.0.1. Here's the vscode version info.
Version: 1.51.1
Commit: e5a624b788d92b8d34d1392e4c4d9789406efe8f
Date: 2020-11-11T01:11:34.018Z (1 wk ago)
Electron: 9.3.3
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 20.1.0

@paulfsheridan @davidzech suggested running this in terminal: codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app
+1  thanks.

Pls stop posting "it works"/"it helped me" comments, use 👍

Since we have narrowed down the root cause and the next step is to get a fix up in libuv. I am going to lock this thread to reduce noise, will reopen once fix is available to verify. Thanks all!

@deepak1556 I wasn't able to test it, but I've disable this lsof call on Big Sur+, here's the workaround that we will want to remove when the fix lands in Electron:
https://github.com/microsoft/vscode/commit/d964664da291f28372a02d3d7ce82d650a98c890
All this should do is disable current working directory-based links, so relative links will only work from the initial directory. This won't work for example:
cd src
echo './somefile'

@deepak1556 I wasn't able to test it, but I've disable this lsof call on Big Sur+, here's the workaround that we will want to remove when the fix lands in Electron:
https://github.com/microsoft/vscode/commit/d964664da291f28372a02d3d7ce82d650a98c890
All this should do is disable current working directory-based links, so relative links will only work from the initial directory. This won't work for example:
cd src
echo './somefile'

Thanks @Tyriar , I am opening the issue for users to verify the temporary fix.

Thanks @Tyriar , I am opening the issue for users to verify the temporary fix.

This issue is still persisting for me. In general I'm noticing a small lag in typing even when using Slack but definitely the most lag is with VScode terminal where it freezes for a whole second or so every now and then.

This issue is still persisting for me. In general I'm noticing a small lag in typing even when using Slack but definitely the most lag is with VScode terminal where it freezes for a whole second or so every now and then.

@deepak1556 Has the fix been shipped? Because I've noticed things have gone back to normal but I don't know if it's related to me removing the code signature from all VSCode Helper apps or if it's thanks to this.

@deepak1556 Has the fix been shipped? Because I've noticed things have gone back to normal but I don't know if it's related to me removing the code signature from all VSCode Helper apps or if it's thanks to this.

I don't think so @richardsimko , unless it's in the insiders build?

I don't think so @richardsimko , unless it's in the insiders build?

Insiders build is still laggy for me

Insiders build is still laggy for me

it helped me https://shageevan.medium.com/vs-codes-in-built-terminal-is-slow-or-laggy-on-macos-big-sur-d5867a7d9771

it helped me https://shageevan.medium.com/vs-codes-in-built-terminal-is-slow-or-laggy-on-macos-big-sur-d5867a7d9771

Unfortunately it doesn't work for me, but I have a question – is removing this signature a good choice in terms of security measures?

Unfortunately it doesn't work for me, but I have a question – is removing this signature a good choice in terms of security measures?

completely restarted the application?

completely restarted the application?

Unfortunately it doesn't work for me, but I have a question – is removing this signature a good choice in terms of security measures?

completely restarted the application?

Unfortunately it doesn't work for me, but I have a question – is removing this signature a good choice in terms of security measures?

completely restarted the application?

Unfortunately it doesn't work for me, but I have a question – is removing this signature a good choice in terms of security measures?

completely restarted the application?

I've restarted the app & the mac. The app is still laggy.

Unfortunately it doesn't work for me, but I have a question – is removing this signature a good choice in terms of security measures?

completely restarted the application?

I've restarted the app & the mac. The app is still laggy.

The command codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app worked for me, but each time after restart I need to execute it again.

The command codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app worked for me, but each time after restart I need to execute it again.

Thanks for the reports, we will soon have a fix from electron and libuv for this issue, will report back once the fix has been released.

Thanks for the reports, we will soon have a fix from electron and libuv for this issue, will report back once the fix has been released.

Had the same issue and signature removal worked for me. Just wanted to add that the same issue was present when performing a file search, or doing a search and replace, and this was also fixed by the command.

Had the same issue and signature removal worked for me. Just wanted to add that the same issue was present when performing a file search, or doing a search and replace, and this was also fixed by the command.

Just my two cents: the command listed above helped, I don't have the lag anymore, but it broke some of my VSCode configuration, like fonts, terminal... so be careful if you execute it!

Just my two cents: the command listed above helped, I don't have the lag anymore, but it broke some of my VSCode configuration, like fonts, terminal... so be careful if you execute it!

The call to lsof could be replaced with a simple C program:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <libproc.h>

// Works on macOS using libproc.

int main(int argc, char *argv[])
{
  int ret;
  pid_t pid;
  char pathbuf[PROC_PIDPATHINFO_MAXSIZE];
  struct proc_vnodepathinfo vpi;

  if (argc == 2)
  {
    pid = (pid_t)atoi(argv[1]);
    ret = proc_pidinfo(pid, PROC_PIDVNODEPATHINFO, 0, &vpi, PROC_PIDVNODEPATHINFO_SIZE);
    if (ret <= 0)
    {
      fprintf(stderr, "%s\n", strerror(errno));
      return 1;
    }
    printf("%s\n", vpi.pvi_cdir.vip_path);
  }
  else
  {
    printf("Usage: %s <pid>\n\n", argv[0]);
    printf("Print the current working directory for <pid> to stdout.\n");
  }

  return 0;
}

The call to lsof could be replaced with a simple C program:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <libproc.h>

// Works on macOS using libproc.

int main(int argc, char *argv[])
{
  int ret;
  pid_t pid;
  char pathbuf[PROC_PIDPATHINFO_MAXSIZE];
  struct proc_vnodepathinfo vpi;

  if (argc == 2)
  {
    pid = (pid_t)atoi(argv[1]);
    ret = proc_pidinfo(pid, PROC_PIDVNODEPATHINFO, 0, &vpi, PROC_PIDVNODEPATHINFO_SIZE);
    if (ret <= 0)
    {
      fprintf(stderr, "%s\n", strerror(errno));
      return 1;
    }
    printf("%s\n", vpi.pvi_cdir.vip_path);
  }
  else
  {
    printf("Usage: %s <pid>\n\n", argv[0]);
    printf("Print the current working directory for <pid> to stdout.\n");
  }

  return 0;
}

I don't think its a good idea to remove the signature.
Instead do the following:

Open terminal in VS code
Open to-right dropdown in terminal and select Configure Terminal Settings
In first option check Terminal: Explorer Kind and select external

Problem solved, will update here if I find any lag issue (currently not at all), just try this out

I don't think its a good idea to remove the signature.
Instead do the following:

Open terminal in VS code
Open to-right dropdown in terminal and select Configure Terminal Settings
In first option check Terminal: Explorer Kind and select external

Problem solved, will update here if I find any lag issue (currently not at all), just try this out

I don't think its a good idea to remove the signature.
Instead do the following:

Open terminal in VS code
Open to-right dropdown in terminal and select Select Default Shell
Here select sh /bin/sh

Problem solved, will update here if I find any lag issue (currently not at all), just try this out

I don't think its a good idea to remove the signature.
Instead do the following:

Open terminal in VS code
Open to-right dropdown in terminal and select Select Default Shell
Here select sh /bin/sh

Problem solved, will update here if I find any lag issue (currently not at all), just try this out

I don't think removing the signature can cause any harm, its main purpose is to secure software distribution and verifying the original executable. Once you have downloaded the verified executable and removed the signature, this shouldn't open up any security holes, unless your system is already infected.
I might be wrong though - would be nice to learn if there is a possible attack vector here.

I don't think removing the signature can cause any harm, its main purpose is to secure software distribution and verifying the original executable. Once you have downloaded the verified executable and removed the signature, this shouldn't open up any security holes, unless your system is already infected.
I might be wrong though - would be nice to learn if there is a possible attack vector here.

I don't think its a good idea to remove the signature.
Instead do the following:

Open terminal in VS code
Open to-right dropdown in terminal and select Select Default Shell
Here select sh /bin/sh

Problem solved, will update here if I find any lag issue (currently not at all), just try this out

Many users will want to use bash or zsh for example (myself included). So this is not an appropriate solution in those cases.

I don't think its a good idea to remove the signature.
Instead do the following:

Open terminal in VS code
Open to-right dropdown in terminal and select Select Default Shell
Here select sh /bin/sh

Problem solved, will update here if I find any lag issue (currently not at all), just try this out

Many users will want to use bash or zsh for example (myself included). So this is not an appropriate solution in those cases.

I think this may be a system-wide issue, rather than one specific to VSCode or even Electron. (I could speculate that VSCode in particular and Electron in general do something that causes them to be severely impacted.)
I recently switched to a 2019 16" MBP running Big Sur (from a 2014 15" running Catalina), and immediately noticed inconsistent keyboard lag in practically all apps. (Caveat: I'm a fairly quick touch typist.)
The lag is particularly noticeable when working in the shell under Terminal.app. Try this: Simply hit ls<enter> a number of times, waiting after each invocation to see what happens. Within the first ~20 invocations, one should encounter an instance where it takes ~8 seconds for the output of ls to appear. (That seems to be consistent with the delay measured in electron/electron/issues/26143.)
Bizarrely, the issue disappears entirely if one forces the use of the discrete GPU by disabling automatic graphics switching, as referenced in #110683.
I tried to see if @davidzech's suggestion of disabling code signing seems to be applicable to the system-wide problem, and it does seem to be. I installed an (unsigned) zsh binary from Homebrew. When using this instead of the (signed) /bin/zsh, it becomes nearly impossible to replicate the issue as long as one invokes only other unsigned binaries (e.g. a manually built GNU ls instead of the signed /bin/ls.)

I think this may be a system-wide issue, rather than one specific to VSCode or even Electron. (I could speculate that VSCode in particular and Electron in general do something that causes them to be severely impacted.)
I recently switched to a 2019 16" MBP running Big Sur (from a 2014 15" running Catalina), and immediately noticed inconsistent keyboard lag in practically all apps. (Caveat: I'm a fairly quick touch typist.)
The lag is particularly noticeable when working in the shell under Terminal.app. Try this: Simply hit ls<enter> a number of times, waiting after each invocation to see what happens. Within the first ~20 invocations, one should encounter an instance where it takes ~8 seconds for the output of ls to appear. (That seems to be consistent with the delay measured in electron/electron/issues/26143.)
Bizarrely, the issue disappears entirely if one forces the use of the discrete GPU by disabling automatic graphics switching, as referenced in #110683.
I tried to see if @davidzech's suggestion of disabling code signing seems to be applicable to the system-wide problem, and it does seem to be. I installed an (unsigned) zsh binary from Homebrew. When using this instead of the (signed) /bin/zsh, it becomes nearly impossible to replicate the issue as long as one invokes only other unsigned binaries (e.g. a manually built GNU ls instead of the signed /bin/ls.)

@wjv I typed ls<enter> more than 20 times and couldn’t reproduce what you described.

@wjv I typed ls<enter> more than 20 times and couldn’t reproduce what you described.

I couldn't reproduce typing ls<enter> multiple times.
On Sat, Jan 23, 2021 at 6:01 PM Leandro Facchinetti <
<EMAIL_ADDRESS>wrote:

@wjv https://github.com/wjv I typed ls more than 20 times and
couldn’t reproduce what you described.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/105446#issuecomment-766141286,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADKG2SXFERBOKPBJUIWG4RTS3L6FBANCNFSM4QMGKECA
.

I couldn't reproduce typing ls<enter> multiple times.
On Sat, Jan 23, 2021 at 6:01 PM Leandro Facchinetti <
<EMAIL_ADDRESS>wrote:

@wjv https://github.com/wjv I typed ls more than 20 times and
couldn’t reproduce what you described.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/105446#issuecomment-766141286,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADKG2SXFERBOKPBJUIWG4RTS3L6FBANCNFSM4QMGKECA
.

I think this may be a system-wide issue, rather than one specific to VSCode or even Electron. (I could speculate that VSCode in particular and Electron in general do something that causes them to be severely impacted.)
I recently switched to a 2019 16" MBP running Big Sur (from a 2014 15" running Catalina), and immediately noticed inconsistent keyboard lag in practically all apps. (Caveat: I'm a fairly quick touch typist.)
The lag is particularly noticeable when working in the shell under Terminal.app. Try this: Simply hit ls<enter> a number of times, waiting after each invocation to see what happens. Within the first ~20 invocations, one should encounter an instance where it takes ~8 seconds for the output of ls to appear. (That seems to be consistent with the delay measured in electron/electron/issues/26143.)
Bizarrely, the issue disappears entirely if one forces the use of the discrete GPU by disabling automatic graphics switching, as referenced in #110683.
I tried to see if @davidzech's suggestion of disabling code signing seems to be applicable to the system-wide problem, and it does seem to be. I installed an (unsigned) zsh binary from Homebrew. When using this instead of the (signed) /bin/zsh, it becomes nearly impossible to replicate the issue as long as one invokes only other unsigned binaries (e.g. a manually built GNU ls instead of the signed /bin/ls.)

I've been experiencing this since upgrading to Big Sur (16 inch, 2019 Mac). It's driving me crazy.

I think this may be a system-wide issue, rather than one specific to VSCode or even Electron. (I could speculate that VSCode in particular and Electron in general do something that causes them to be severely impacted.)
I recently switched to a 2019 16" MBP running Big Sur (from a 2014 15" running Catalina), and immediately noticed inconsistent keyboard lag in practically all apps. (Caveat: I'm a fairly quick touch typist.)
The lag is particularly noticeable when working in the shell under Terminal.app. Try this: Simply hit ls<enter> a number of times, waiting after each invocation to see what happens. Within the first ~20 invocations, one should encounter an instance where it takes ~8 seconds for the output of ls to appear. (That seems to be consistent with the delay measured in electron/electron/issues/26143.)
Bizarrely, the issue disappears entirely if one forces the use of the discrete GPU by disabling automatic graphics switching, as referenced in #110683.
I tried to see if @davidzech's suggestion of disabling code signing seems to be applicable to the system-wide problem, and it does seem to be. I installed an (unsigned) zsh binary from Homebrew. When using this instead of the (signed) /bin/zsh, it becomes nearly impossible to replicate the issue as long as one invokes only other unsigned binaries (e.g. a manually built GNU ls instead of the signed /bin/ls.)

I've been experiencing this since upgrading to Big Sur (16 inch, 2019 Mac). It's driving me crazy.

@leafac and @clouedoc, thanks for testing that. Are you saying that you are observing the VSCode behaviour that’s the subject of this Issue, but not seeing the problem in Terminal (or elsewhere)? Also, are you sure that you’re currently using the integrated Intel GPU?
The fact that this isn’t much more widely reported makes me think it only affects certain hardware configurations. But if you’re definitely seeing the VSCode issue and at the same time no keyboard lag anywhere else — especially not at the shell in Terminal — then my guess could be wrong and these issues are not connected. (But that would seem odd, since both issues seem to be addressed by using non-signed code.)
@itstrueimryan, sounds like you’re seeing the same thing I am, on a very similar hardware config. Does forcing the use of the discrete GPU (by disabling automatic graphics switching) make it better?

@leafac and @clouedoc, thanks for testing that. Are you saying that you are observing the VSCode behaviour that’s the subject of this Issue, but not seeing the problem in Terminal (or elsewhere)? Also, are you sure that you’re currently using the integrated Intel GPU?
The fact that this isn’t much more widely reported makes me think it only affects certain hardware configurations. But if you’re definitely seeing the VSCode issue and at the same time no keyboard lag anywhere else — especially not at the shell in Terminal — then my guess could be wrong and these issues are not connected. (But that would seem odd, since both issues seem to be addressed by using non-signed code.)
@itstrueimryan, sounds like you’re seeing the same thing I am, on a very similar hardware config. Does forcing the use of the discrete GPU (by disabling automatic graphics switching) make it better?

Are you saying that you are observing the VSCode behaviour that’s the subject of this Issue, but not seeing the problem in Terminal (or elsewhere)?

👍 Exactly.
What fixed the issue for me was running codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app. I tested Terminal.app after having ran this (but it shouldn’t matter, because Terminal.app has nothing to do with Code Helper (Renderer).app).

Also, are you sure that you’re currently using the integrated Intel GPU?

I suppose I am because that’d be the only option:

How do I check?

Are you saying that you are observing the VSCode behaviour that’s the subject of this Issue, but not seeing the problem in Terminal (or elsewhere)?

👍 Exactly.
What fixed the issue for me was running codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app. I tested Terminal.app after having ran this (but it shouldn’t matter, because Terminal.app has nothing to do with Code Helper (Renderer).app).

Also, are you sure that you’re currently using the integrated Intel GPU?

I suppose I am because that’d be the only option:

How do I check?

I thought that my Mac was defective too. It's a 16" 2020 I've got with a
discount on Amazon.
I'm using integrated graphics
I can't reproduce the issue either on Terminal.app or vscode anymore.
The issue also happened in other apps, such as Chrome when typing in the
address bar.
The issue also happened while typing code in the editor window.
I used the temporary codesign fix and it worked fine. It has been driving
me crazy too. I even contacted Amazon for an exchange (which they refused
unless I sent my mac + password to their repair center...)
I don't really experience the issue anymore, even after updating VSCode and
restarting my device.
What changed:

Now, I mainly use my mac unplugged -> it uses the integrated graphics card
Mac OS X updated itself

Forcing usage of the dedicated graphics cards using gfxCardStatus has no
effect. So all good on my end.
[image: image.png]
On Sat, Jan 23, 2021 at 9:25 PM Leandro Facchinetti <
<EMAIL_ADDRESS>wrote:

Are you saying that you are observing the VSCode behaviour that’s the
subject of this Issue, but not seeing the problem in Terminal (or
elsewhere)?
👍 Exactly.
What fixed the issue for me was running codesign --remove-signature
/Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper
(Renderer).app. I tested Terminal.app after having ran this (but it
shouldn’t matter, because Terminal.app has nothing to do with Code Helper
(Renderer).app).
Also, are you sure that you’re currently using the integrated Intel GPU?
I suppose I am because that’d be the only option:
[image: Screen Shot 2021-01-23 at 20 23 53]
https://user-images.githubusercontent.com/586813/105613191-16ee9700-5db9-11eb-8b79-79a357e06598.png
How do I check?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/105446#issuecomment-766174061,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADKG2SQRXU6RBCY4MS3H7PTS3MWFFANCNFSM4QMGKECA
.

I thought that my Mac was defective too. It's a 16" 2020 I've got with a
discount on Amazon.
I'm using integrated graphics
I can't reproduce the issue either on Terminal.app or vscode anymore.
The issue also happened in other apps, such as Chrome when typing in the
address bar.
The issue also happened while typing code in the editor window.
I used the temporary codesign fix and it worked fine. It has been driving
me crazy too. I even contacted Amazon for an exchange (which they refused
unless I sent my mac + password to their repair center...)
I don't really experience the issue anymore, even after updating VSCode and
restarting my device.
What changed:

Now, I mainly use my mac unplugged -> it uses the integrated graphics card
Mac OS X updated itself

Forcing usage of the dedicated graphics cards using gfxCardStatus has no
effect. So all good on my end.
[image: image.png]
On Sat, Jan 23, 2021 at 9:25 PM Leandro Facchinetti <
<EMAIL_ADDRESS>wrote:

Are you saying that you are observing the VSCode behaviour that’s the
subject of this Issue, but not seeing the problem in Terminal (or
elsewhere)?
👍 Exactly.
What fixed the issue for me was running codesign --remove-signature
/Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper
(Renderer).app. I tested Terminal.app after having ran this (but it
shouldn’t matter, because Terminal.app has nothing to do with Code Helper
(Renderer).app).
Also, are you sure that you’re currently using the integrated Intel GPU?
I suppose I am because that’d be the only option:
[image: Screen Shot 2021-01-23 at 20 23 53]
https://user-images.githubusercontent.com/586813/105613191-16ee9700-5db9-11eb-8b79-79a357e06598.png
How do I check?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/105446#issuecomment-766174061,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADKG2SQRXU6RBCY4MS3H7PTS3MWFFANCNFSM4QMGKECA
.

I've also been experiencing lags using VS Code integrated terminal or Spotlight since I updated my Macbook Air (Early 2014) to Big Sur. Removing VS Code signature seemed to work for a while but that's no longer the case...

I've also been experiencing lags using VS Code integrated terminal or Spotlight since I updated my Macbook Air (Early 2014) to Big Sur. Removing VS Code signature seemed to work for a while but that's no longer the case...

Re possible system-wide issue brought up by @wjv :
Since upgrading to Big Sure, I am experiencing a terrible lag during login with a MacMini most recent Magic Keyboard combo.  Even characters are dropped when entering my password, so I have to type characters at least 1 second (sometimes longer) apart to make sure each of them gets registered. Note that FileVault is turned on, so the login is preceding any actual system startup activity. (My password is needed to unlock the system files as well, AFAIK.)

Re possible system-wide issue brought up by @wjv :
Since upgrading to Big Sure, I am experiencing a terrible lag during login with a MacMini most recent Magic Keyboard combo.  Even characters are dropped when entering my password, so I have to type characters at least 1 second (sometimes longer) apart to make sure each of them gets registered. Note that FileVault is turned on, so the login is preceding any actual system startup activity. (My password is needed to unlock the system files as well, AFAIK.)

What fixed the issue for me was running codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app.

this helped me with lags and slow terminal open

What fixed the issue for me was running codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app.

this helped me with lags and slow terminal open

I think this may be a system-wide issue, rather than one specific to VSCode or even Electron. (I could speculate that VSCode in particular and Electron in general do something that causes them to be severely impacted.)
I recently switched to a 2019 16" MBP running Big Sur (from a 2014 15" running Catalina), and immediately noticed inconsistent keyboard lag in practically all apps. (Caveat: I'm a fairly quick touch typist.)
The lag is particularly noticeable when working in the shell under Terminal.app. Try this: Simply hit ls<enter> a number of times, waiting after each invocation to see what happens. Within the first ~20 invocations, one should encounter an instance where it takes ~8 seconds for the output of ls to appear. (That seems to be consistent with the delay measured in electron/electron/issues/26143.)
Bizarrely, the issue disappears entirely if one forces the use of the discrete GPU by disabling automatic graphics switching, as referenced in #110683.
I tried to see if @davidzech's suggestion of disabling code signing seems to be applicable to the system-wide problem, and it does seem to be. I installed an (unsigned) zsh binary from Homebrew. When using this instead of the (signed) /bin/zsh, it becomes nearly impossible to replicate the issue as long as one invokes only other unsigned binaries (e.g. a manually built GNU ls instead of the signed /bin/ls.)

+1 on this being a system-wide issue affecting the 2019 MBP; I experience identical behavior in both VSCode as well as iTerm and Terminal.app since updating to Big Sur on my 2019 16" MacBook Pro as well.
Issue has been reproducible across all public and beta releases from 11.0 to 11.2 and forcing discrete GPU usage by disabling automatic graphics switching prevents the issue from happening.

I think this may be a system-wide issue, rather than one specific to VSCode or even Electron. (I could speculate that VSCode in particular and Electron in general do something that causes them to be severely impacted.)
I recently switched to a 2019 16" MBP running Big Sur (from a 2014 15" running Catalina), and immediately noticed inconsistent keyboard lag in practically all apps. (Caveat: I'm a fairly quick touch typist.)
The lag is particularly noticeable when working in the shell under Terminal.app. Try this: Simply hit ls<enter> a number of times, waiting after each invocation to see what happens. Within the first ~20 invocations, one should encounter an instance where it takes ~8 seconds for the output of ls to appear. (That seems to be consistent with the delay measured in electron/electron/issues/26143.)
Bizarrely, the issue disappears entirely if one forces the use of the discrete GPU by disabling automatic graphics switching, as referenced in #110683.
I tried to see if @davidzech's suggestion of disabling code signing seems to be applicable to the system-wide problem, and it does seem to be. I installed an (unsigned) zsh binary from Homebrew. When using this instead of the (signed) /bin/zsh, it becomes nearly impossible to replicate the issue as long as one invokes only other unsigned binaries (e.g. a manually built GNU ls instead of the signed /bin/ls.)

+1 on this being a system-wide issue affecting the 2019 MBP; I experience identical behavior in both VSCode as well as iTerm and Terminal.app since updating to Big Sur on my 2019 16" MacBook Pro as well.
Issue has been reproducible across all public and beta releases from 11.0 to 11.2 and forcing discrete GPU usage by disabling automatic graphics switching prevents the issue from happening.

How do you disable this?
On Jan 25, 2021, 9:35 PM -0800, Nash Kaminski<EMAIL_ADDRESS>wrote:

I think this may be a system-wide issue, rather than one specific to VSCode or even Electron. (I could speculate that VSCode in particular and Electron in general do something that causes them to be severely impacted.)
I recently switched to a 2019 16" MBP running Big Sur (from a 2014 15" running Catalina), and immediately noticed inconsistent keyboard lag in practically all apps. (Caveat: I'm a fairly quick touch typist.)
The lag is particularly noticeable when working in the shell under Terminal.app. Try this: Simply hit ls a number of times, waiting after each invocation to see what happens. Within the first ~20 invocations, one should encounter an instance where it takes ~8 seconds for the output of ls to appear. (That seems to be consistent with the delay measured in electron/electron/issues/26143.)
Bizarrely, the issue disappears entirely if one forces the use of the discrete GPU by disabling automatic graphics switching, as referenced in #110683.
I tried to see if @davidzech's suggestion of disabling code signing seems to be applicable to the system-wide problem, and it does seem to be. I installed an (unsigned) zsh binary from Homebrew. When using this instead of the (signed) /bin/zsh, it becomes nearly impossible to replicate the issue as long as one invokes only other unsigned binaries (e.g. a manually built GNU ls instead of the signed /bin/ls.)
+1 on this being a system-wide issue affecting the 2019 MBP; I experience identical behavior in both VSCode as well as iTerm and Terminal.app since updating to Big Sur on my 2019 16" MacBook Pro as well.
Issue has been reproducible across all public and beta releases from 11.0 to 11.2 and forcing discrete GPU usage by disabling automatic graphics switching prevents the issue from happening.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

How do you disable this?
On Jan 25, 2021, 9:35 PM -0800, Nash Kaminski<EMAIL_ADDRESS>wrote:

I think this may be a system-wide issue, rather than one specific to VSCode or even Electron. (I could speculate that VSCode in particular and Electron in general do something that causes them to be severely impacted.)
I recently switched to a 2019 16" MBP running Big Sur (from a 2014 15" running Catalina), and immediately noticed inconsistent keyboard lag in practically all apps. (Caveat: I'm a fairly quick touch typist.)
The lag is particularly noticeable when working in the shell under Terminal.app. Try this: Simply hit ls a number of times, waiting after each invocation to see what happens. Within the first ~20 invocations, one should encounter an instance where it takes ~8 seconds for the output of ls to appear. (That seems to be consistent with the delay measured in electron/electron/issues/26143.)
Bizarrely, the issue disappears entirely if one forces the use of the discrete GPU by disabling automatic graphics switching, as referenced in #110683.
I tried to see if @davidzech's suggestion of disabling code signing seems to be applicable to the system-wide problem, and it does seem to be. I installed an (unsigned) zsh binary from Homebrew. When using this instead of the (signed) /bin/zsh, it becomes nearly impossible to replicate the issue as long as one invokes only other unsigned binaries (e.g. a manually built GNU ls instead of the signed /bin/ls.)
+1 on this being a system-wide issue affecting the 2019 MBP; I experience identical behavior in both VSCode as well as iTerm and Terminal.app since updating to Big Sur on my 2019 16" MacBook Pro as well.
Issue has been reproducible across all public and beta releases from 11.0 to 11.2 and forcing discrete GPU usage by disabling automatic graphics switching prevents the issue from happening.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

I also see the issue 'system wide', VSCode is simply the place I see it most, most notably in the integrated terminal. GPU usage is likely a placebo / red herring, I use two 4K monitors over usb-c with my MacBook Pro, which forces discrete graphics at all times, and I have the issue.
Removing the signature did appear to help for a while, but VSCode updated itself and I haven't run the command again since then.

I also see the issue 'system wide', VSCode is simply the place I see it most, most notably in the integrated terminal. GPU usage is likely a placebo / red herring, I use two 4K monitors over usb-c with my MacBook Pro, which forces discrete graphics at all times, and I have the issue.
Removing the signature did appear to help for a while, but VSCode updated itself and I haven't run the command again since then.

I have experienced the problem too.

vscode Version: 1.52.1 (and in older versions for a half of the year)
macOs Big Sur 11.1 (20C69)
MacBook Pro (16-inch, 2019)

Steps to reproduce:

open integrated terminal in vscode
press any letter continuously
after ~10 repetitions of letter there will be a hang for a second. THe hang does not repeat while on the same line.
press enter and try again. There will be hang again.

Tried with "terminal.integrated.shell.osx": "/bin/zsh" and "/bin/bash". Hang appears in both.
Command codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app solved an issue for me. Maybe until next vscode udate.

I have experienced the problem too.

vscode Version: 1.52.1 (and in older versions for a half of the year)
macOs Big Sur 11.1 (20C69)
MacBook Pro (16-inch, 2019)

Steps to reproduce:

open integrated terminal in vscode
press any letter continuously
after ~10 repetitions of letter there will be a hang for a second. THe hang does not repeat while on the same line.
press enter and try again. There will be hang again.

Tried with "terminal.integrated.shell.osx": "/bin/zsh" and "/bin/bash". Hang appears in both.
Command codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app solved an issue for me. Maybe until next vscode udate.

@ujwal-setlur
To turn off automatic graphics switching, go to system preferences > Battery > Automatic Graphics Switching and uncheck the box.
Be aware that this results in a ~30%

@ujwal-setlur
To turn off automatic graphics switching, go to system preferences > Battery > Automatic Graphics Switching and uncheck the box.
Be aware that this results in a ~30%

+1 on this being a system-wide issue affecting the 2019 MBP; I experience identical behavior in both VSCode as well as iTerm and Terminal.app since updating to Big Sur on my 2019 16" MacBook Pro as well.
Issue has been reproducible across all public and beta releases from 11.0 to 11.2 and forcing discrete GPU usage by disabling automatic graphics switching prevents the issue from happening.

Sorry to add a layer of complication to this, but I have discrete graphics switching disabled (2018 mbp) for battery and power adaptor (pre-update). This term lag issue exists for me in vscode since Big Sur, but not in iterm - though I do subscribe to the beta channel of iterm and have a variety of custom settings 🤷
codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app did the trick as others have suggested.

+1 on this being a system-wide issue affecting the 2019 MBP; I experience identical behavior in both VSCode as well as iTerm and Terminal.app since updating to Big Sur on my 2019 16" MacBook Pro as well.
Issue has been reproducible across all public and beta releases from 11.0 to 11.2 and forcing discrete GPU usage by disabling automatic graphics switching prevents the issue from happening.

Sorry to add a layer of complication to this, but I have discrete graphics switching disabled (2018 mbp) for battery and power adaptor (pre-update). This term lag issue exists for me in vscode since Big Sur, but not in iterm - though I do subscribe to the beta channel of iterm and have a variety of custom settings 🤷
codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app did the trick as others have suggested.

On MacBook Pro Retina 15" (Mid 2015), I can confirm this is not system-wide, only on VSCode.
iTerm2 is as smooth as ever. However, I had to use the codesign command mentioned throughout the issue to make the VSCode's built-in terminal usable again, otherwise it was a very unpleasant experience.

On MacBook Pro Retina 15" (Mid 2015), I can confirm this is not system-wide, only on VSCode.
iTerm2 is as smooth as ever. However, I had to use the codesign command mentioned throughout the issue to make the VSCode's built-in terminal usable again, otherwise it was a very unpleasant experience.

Does anyone have a theory for why removing the signature "fixes" the problem that we can test?

Does anyone have a theory for why removing the signature "fixes" the problem that we can test?

@docwhat perhaps every executed process is being validated by macOs trustd service?

@docwhat perhaps every executed process is being validated by macOs trustd service?

How could we test that?

How could we test that?

FYI the root cause has already been tracked down and being fixed in libuv/electron, see:

https://github.com/microsoft/vscode/issues/105446#issuecomment-730342806 (a comment on this issue)
https://github.com/electron/electron/pull/27026
https://github.com/libuv/libuv/pull/3064

FYI the root cause has already been tracked down and being fixed in libuv/electron, see:

https://github.com/microsoft/vscode/issues/105446#issuecomment-730342806 (a comment on this issue)
https://github.com/electron/electron/pull/27026
https://github.com/libuv/libuv/pull/3064

To piggyback on what @marcello3d said, this was affecting our own Electron app, so we built a custom version of Electron using that libuv patch and it solved the issue for us. Hopefully this will be merged upstream soon, but in the meantime, other developers can try building Electron with that patch.

To piggyback on what @marcello3d said, this was affecting our own Electron app, so we built a custom version of Electron using that libuv patch and it solved the issue for us. Hopefully this will be merged upstream soon, but in the meantime, other developers can try building Electron with that patch.

Thanks @marcello3d @pdesantis for the work on fix.
Just to update, whenever upstream releases a new version with the patch vscode will update to it. Also we didn't build the patch internally because it was too late in the current January iteration to get enough testing before stable release 1.53 that will happen next week. We will get this fix in to our internal builds next February iteration for early testing if there is no release from upstream.
I see that the issue is getting side tracked again, will lock until further updates.

Thanks @marcello3d @pdesantis for the work on fix.
Just to update, whenever upstream releases a new version with the patch vscode will update to it. Also we didn't build the patch internally because it was too late in the current January iteration to get enough testing before stable release 1.53 that will happen next week. We will get this fix in to our internal builds next February iteration for early testing if there is no release from upstream.
I see that the issue is getting side tracked again, will lock until further updates.

The libuv fix has been backported internally and is available in latest insiders, please verify if this issue is fixed. Thanks!

\closedWith ff85144fdd3244ffe4a5da08354667c7e57e45ef

/verified
Insiders Build 52838cf6799cc448e738677ec37e86cf62a5bd89:

Current Stable Build 8490d3dde47c57ba65ec40dd192d014fd2113496:

I got an update of the non-insiders today, and it seems to be fixed there also?!

oh thank God this was driving me crazy, thank you for fixing 🙏🏻

so, what's the correct way of undoing codesign --remove-signature /Applications/Visual\ Studio\ Code.app/Contents/Frameworks/Code\ Helper\ \(Renderer\).app.
Guess we need to sign the app again. But with which key?

@ay0o the update should have installed a new signed binary

is this distributed to everyone or just in a beta channel?

I've received the update today and I can feel the improvement !
Thank you ! You rocks ! 💪

I’m running version 1.53.2 and I still see a significant lag when opening new terminal panes. I ran the codesign command and it fixed the issue (I’ve been doing that for every new version…).
I think the issue hasn’t been solved for me. Am I doing something wrong?

@leafac the fix is available in the insiders builds only as of now. Switch to insiders builds or stick to the codesign workaround for the time being.

@flash-gordon: Ah, I had misunderstood the previous comments and I thought the fix was generally available. Thanks for the clarification 👍

Heads up, the fix was reverted upstream: https://github.com/libuv/libuv/issues/3050#issuecomment-778495429
I'm not sure what that means for VSCode or if this issue should be reopened?

FYI, the fix is reverted in electron but I have added workarounds for the failing test cases mentioned in the libuv repo while it is being investigated, so I have not reverted the fix internally for vscode.


Use hadoop 2.6 profile and zookeeper 3.4.5 which comes with CDH

Update the hadoop options to use the new hadoop-2.6 profile. But it upgrades zookeeper and curator, so I'm locking those at the cloudera versions.
@airhorns @dklassen @damnMeddlingKid

This is for Shopify/data-disruptions#107


"Failed to start elasticsearch within time-out" when running within Jenkins

I'm have a pretty simple build that starts up an embedded instance, which works fine both through IDEA and gradle CLI. However, when I run the job in Jenkins, I get this error when starting the embedded server:
pl.allegro.tech.embeddedelasticsearch.EmbeddedElasticsearchStartupException: Failed to start elasticsearch within time-out

I've spoken with the Jenkins folks, and they see no reason this should not work. I therefore wonder if this is a bug, or some other known issue, or if there are some recommended way to use embedded-elasticsearch with Jenkins.
The code I'm running is simply
val client = EmbeddedElastic.builder()
      .withElasticVersion("2.3.1")
      .withSetting(PopularProperties.TRANSPORT_TCP_PORT, 9300)
      .withSetting(PopularProperties.CLUSTER_NAME, "elastic-test")
      .withSetting("http.cors.allow-origin", "*")
      .withSetting("http.cors.enabled", true)
      .withIndex("foo", IndexSettings.builder()
        .withType("bar", "template.json")
        .build())
      .build()

client.start() // this crashes

Other

ES version: 2.3.1
Scala: 2.11.8
Java: 1.8_101
Jenkins: 2.33
OS: Debian 8

Hi,
First thing: try increasing timeout (method withStartTimeout on builder). It defaults to 15 secs which is quite a lot, but maybe workers used by your Jenkins are so slow/overloaded that it's not enough for them. BTW I had to do such thing in embedded-elasticsearch tests: https://github.com/allegro/embedded-elasticsearch/blob/master/es50-test/src/test/groovy/pl/allegro/tech/embeddedelasticsearch/EmbeddedElasticSpec.groovy because travis had timeouts

Sorry, I ended up just setting up a persistent local server on my Jenkins server. I totally forgot about this issue. As this is no longer a real issue for me, you can just close it if you want.

I have the same problem, I'm increasing the timeout but it is launching the error.
What I noticed is If I launch the application from unit test it breaks, Im using it in the application and seems to work fine.

I am also having this issue. :/

Resolved this issue by expanding the heap memory for the slave.  It required more memory than jenkins was providing.

I am having this problem.... my tests wont run on jenkins using embedded-elasticsearch library. I am just getting the generic exception - EmbeddedElasticsearchStartupException
Kimberly-els - how do you change the heap memory for slave? Is it a Jenkins configuration option?

I didn't personally expand it, it was done by the part of my company that runs the jenkins server.

@rdooley-sc Make sure that your embedded elastic is getting torn down each time too, if you leave it running, another copy will not be able to start up.

Thanks


Overlay neon-cli with new "kubectl" commands

I just realized that it's very possible for neon-cli to implement new kubectl commands like:
neon config set-namespace foo

which is much nicer than
neon config set-context --current --namespace neon-system

This would be super easy to do but we'd want to somehow get this into the kubectl help.  One idea would be to duplicate the kubectl help to better integrate this into neon-cli which we'll track here:
#1345

DONE


Helper functions for using Leonardo for brightness control

Description

Current demo shows possible implementation for Leonardo as a brightness control, however it uses a foundational function createScale that is intended to be a utility wrapper of d3 scale creation, with multiple possible uses. The current implementation using createScale for brightness is unfocused and could be improved.
Proposed enhancement: incorporate a function that will output an array of color values tailored for brightness control.
Why do you need this feature?

To make it easier to incorporate brightness control using Leonardo.
Additional context

Solved by #34


Document file extensions of GDScript, CSharpScript, and Shader

https://github.com/godotengine/godot/pull/78562#discussion_r1238720069
Changed a few other things in the Shader documentation, please take a look.

Thanks!


Geoblocking ADR draft

Description
Changes proposed in this pull request:

...

Pre-Merge Checklist

[ ] As a PR reviewer, verify code coverage and evaluate if it is acceptable.

Related issues

Please use single file for drawio diagrams. The recommended approach is to use {name}.drawio.svg - it contain diagram sources and SVG representation in the single file.

Thank you, it is much simpler :) I've just renamed the svg files and removed drawio ones.


Fix/kubernetes fixes and performance

add caching
add /ready-endpoint
fix wrong names in k8s-template

Ended up creating my own models, as adding examples to the geojson-pydantic-models was not trivial, and they did not show up correctly in the OpenAPI-spec.
Also ended up exposing and documenting some additional query-parameters


Fix #172 -  RegistryPolicies: Error when Key or ValueName parameters contain bracket "()"

Pull Request
Pull Request (PR) description
Fix #172 -  RegistryPolicies: Error when Key or ValueName parameters contain bracket "()"
Fixed

fix #172

Task list

[X] The PR represents a single logical change. i.e. Cosmetic updates should go in different PRs.
[X] Added an entry under the Unreleased section of in the CHANGELOG.md as per format.
[ ] Local clean build passes without issue or fail tests (build.ps1 -ResolveDependency).
[X] Resource documentation added/updated in README.md.
[ ] Resource parameter descriptions added/updated in README.md, schema.mof
and comment-based help.
[ ] Comment-based help added/updated.
[ ] Localization strings added/updated in all localization files as appropriate.
[ ] Examples appropriately added/updated.
[ ] Unit tests added/updated. See DSC Resource Testing Guidelines.
[ ] Integration tests added/updated (where possible). See DSC Resource Testing Guidelines.
[ ] New/changed code adheres to DSC Resource Style Guidelines and Best Practices.

This change is

Thanks, @stehlih!


A11y_VSCode_SidebarBarOptions_AccessingTheExtensionbaroptions_ScreenReader: On activating any of the extension under “Popular” and “Recommended” the content in the main content get updated but the same is not notified to the screen reader users.

Environment Details:
VSCode Version : 1.35.6 (user setup)
OS Version : Win10
Additional Details:
MAS Violated : MAS 4.1.2
ScreenReader Versions : NVDA2019.1.1, JAWS 2019
Repro Steps:

Open Visual studio code editor.
Using "Ctrl+Shift+X" key navigate to the extension side view bar option.
Using "Tab" key navigate to extension side bar options.
Start screen reader.
Navigate to the available extensions under “Popular” and “Recommended” and activate any one of them.
Content in the main content get updated listen if it is announced to the screen reader users.

Actual:
When screen reader users navigate and activate the extensions some content in the main content get updated but the same is not notified to the screen reader users.
Expected:
The screen reader user should be notified about the updated content on activating any of the extension.
Recommendations:
Refer below link which is repository of bug fixes code snippets:
https://microsoft.sharepoint.com/teams/msenable/mas/pages/browse-fixes.aspx
User Impact:
If the screen reader user are not notified about the updated content then the user might not understand what actually happened on activating the extension.
MAS Reference:
MAS 1.3.1 - https://microsoft.sharepoint.com/:w:/r/teams/msenable/_layouts/15/WopiFrame.aspx?sourcedoc={54f28d1f-a2d1-4dcd-84e1-5c9b87e8aba4}
Attachment for Reference:
VSCode_SidebarBarOptions_AccessingTheExtensionbaroptions_ScreenReader No notification for extension content update.pptx

Duplicate of https://github.com/microsoft/vscode/issues/77062


rh-python35 on RHEL 7 machine

Package centos-release-scl is available only on CentOS machine, not applicable on RHEL.

That's good point. Such check would not hurt.


Unexpected value 'TranslateModule' imported by the module 'DynamicTestModule' Karma

Hello,
I have an angular app those tests runs very fine but when I push the code to gitlab  I get the following error in pipeline

this my tests for NotFoundComponent in Karma
`import { ComponentFixture, TestBed } from '@angular/core/testing';
import { TranslateModule } from '@ngx-translate/core';
import { NotFoundComponent } from './not-found.component';
import { AppModule } from '../app.module';
describe('NotFoundComponent', () => {
let component: NotFoundComponent;
let fixture: ComponentFixture;
beforeEach(async () => {
await TestBed.configureTestingModule({
imports: [ I18nModule TranslateModule.forRoot() , AppModule ],
declarations: [ NotFoundComponent ]
})
.compileComponents();
});
beforeEach(() => {
fixture = TestBed.createComponent(NotFoundComponent);
component = fixture.componentInstance;
fixture.detectChanges();
});
it('should create', () => {
expect(component).toBeTruthy();
});
});
`
Please give some suggestions ?

Add ...DEFAULT_IMPORT to your imports.

@DmitriiCr did you able to fix this? I am getting similar error in jest tests.


RoS from from version 6.43 will change initial login authorization

RoS from from version 6.43 will change login authorization, and it seems in 6.42.4 authorization no longer works.
Link to WIKI: https://wiki.mikrotik.com/wiki/Manual:API#Initial_login
Old and new algo for auth:
Login method pre-v6.43:
First, clients sends /login command.
Reply contains =ret=challenge argument.
Client sends second /login command, with =name=username and =response=response.
In case of error, reply contains =ret=error message.
In case of successful login client can start to issue commands.
Login method post-v6.43:
Now client sends username and password in first message.
Password is sent in plain text.
in case of error, reply contains =message=error message.
In case of successful login client can start to issue commands.

https://forum.mikrotik.com/viewtopic.php?f=21&t=133420&start=250#p665728

Send /login with username and password in plain text
if response is with challenge then fall back to old login method
otherwise check status if login is successful

@rpv-tomsk i know the auth algorithm

fwiw: similar change in "python's" librouteros:
https://github.com/luqasz/librouteros/commit/5b685f355fdd9023e15abb6daeb6e46476f02303

Their ways is a bit smarter than just sent password in first attempt )

@manio
Mariusz, have you an equipment to make tests of the new auth scheme?
I have no.
Also, I'm going to implement PR 2852 @ collectd, please look, maybe you might be interested.

Currently 6.43 is only in rc versions, but I think I would have one RB where i can install it... I'll try to code this... I assume there will be no problem to also merge this in collectd by you?
I can see that you have some release plan for all of this librouteros and collectd stuff :)
Great news!

I assume there will be no problem to also merge this in collectd by you?

As I understand, new auth scheme will not require librouteros API/ABI changes at all.
Will you simply send real login+password in first try, or will use fake one like "python's" librouteros?
I think 'smart' algo has no much sense, because if anybody is able to snif API data, then they can do MITM and force library to send plain password.

@rpv-tomsk
You're right, I've done it as suggested by mikrotik guy on forum.
I've tested it on old and new RouterOS versions and in both cases it is working OK :)
It defaults to new algo (less request-responses) but in case when it encounter the ret challenge, it is falling back to old method.

Propose to put this into Changelog right now. (after #8 merge to avoid rebase).

Done, thank you :)


Phone Book api

Closing, as this has now been merged into my WIP social search work on community-gardens


Add RequestNotificationService.WaitForResourceAsync

Background and Motivation
When writing tests with Aspire.Hosting.Testing against AppHost projects, it's beneficial to have a programmatic way to wait on a resource to transition to a known state from within a test, so that tests don't needlessly attempt to connect to a resource when it's known to be in a state where that attempt will fail, e.g. before it transitions to the "Running" state as shown in the dashboard, or reported by RequestNotificationService.
Proposed API
We should consider adding a new method Aspire.Hosting.ApplicationModel.RequestNotificationService.WaitForResourceAsync to aid in these scenarios, along with adding more common states to Aspire.Hosting.ApplicationModel.KnownResourceStates.
namespace Aspire.Hosting.ApplicationModel;

public class RequestNotificationService
{
    public ResourceNotificationService(ILogger<ResourceNotificationService> logger);
+   public ResourceNotificationService(ILogger<ResourceNotificationService> logger, IHostApplicationLifetime hostApplicationLifetime);
+   public Task WaitForResourceAsync(string resourceName, string targetState = "Running", CancellationToken? cancellationToken = null)
}

public static class KnownResourceStates
{
    public static readonly string Hidden = "Hidden";
+   public static readonly string Starting = "Starting";
+   public static readonly string Running = "Running";
+   public static readonly string FailedToStart = "FailedToStart";
+   public static readonly string Stopping = "Stopping";
+   public static readonly string Exited = "Exited";
+   public static readonly string Finished = "Finished";
}

Usage Examples
[Fact]
public async Task GetWebResourceRootReturnsOkStatusCode()
{
    // Arrange
    var appHost = await DistributedApplicationTestingBuilder.CreateAsync<Projects.MyAspireApp_AppHost>();
    appHost.Services.ConfigureHttpClientDefaults(client =>
    {
        client.AddStandardResilienceHandler();
    });

    await using var app = await appHost.BuildAsync();
    var resourceNotification = app.Services.GetRequiredService<ResourceNotificationService>();
    await app.StartAsync();

    // Act
    await resourceNotification.WaitForResourceAsync("webfrontend", KnownResourceStates.Running);
    var httpClient = app.CreateHttpClient("webfrontend");
    var response = await httpClient.GetAsync("/");

    // Assert
    Assert.Equal(HttpStatusCode.OK, response.StatusCode);
}

Alternative Designs
We initially thought about adding a new public type in Aspire.Hosting.Testing that could be resolved from DI manually and have the WaitForResourceAsync method on that but given the target state is aligned with the state text reported by RequestNotificationService it seems appropriate to add it directly there.
Perhaps WaitForResourceAsync could just be WaitForAsync given it's already on the RequestNotificationService.
Risks
The resource states are just string values and aren't enforced anywhere, or even used to set states by Aspire.Hosting, as the states generally come from DCP. It seems reasonable that we should have a set of common known states though.
The overload WaitForResource("myresource") where the targetState parameter is defaulted could be something we'd prefer to map to a different behavior in the future, e.g. once health checks are added it could wait for health checks to be healthy before returning rather than just status update text matching.

Did mean ResourceNotificationService in the issue title?
Funnily enough, I happened to implement a version of WaitForResource(state) yesterday in my AppHost project, so +1 for being in the core of aspire rather than being a test extension.  (Context of why I was doing this I was refactoring some of https://github.com/davidfowl/WaitForDependenciesAspire/ make it play better with non Executable / Container resources).
One problem I have found with that implementation is that it does wait forever if the resource terminates/fails before reaching the expected state.  (e.g. if you wait for Running but resource goes to FailedToStart).  This actually works quite nicely for my use case, but in tests, I'd imagine you want your tests to fail fast rather than wait for a default timeout).  Ideally not only would WaitForResourceAsync wait for the resource to reach the expected state, but it should also fail fast once the resource reaches a point where it can never get into the desired state.
That said, I have found the status changes APIs a bit awkward to use as a whole:

It's hard to know what the states are, and there are lots of different status that effectively meant he same thing.  (e.g. Exited, Finished and FailedToStart are really all different forms of terminating state).  Adding more well known status helps with part of this, but it doesn't help with non well known states
If waiting for a specific state, it's hard to know whether that state is still possible.  (e.g. if I'm waiting for a Healthy status, but the resource terminates, there's not much point continuing to wait for the Healthy state)
I've also not found the separate Starting vs Started states particularly helpful as you're not able to use them to block progression to the next state, so most of the time by the time you react to the starting events, the resource has transitioned to the started event  (This is probably a broader issue around Resource Lifecycles rather than ResourceNotificationService, but I'm mentioning it for completeness.)

The text status works really well for the purpose of displaying on a dashboard and human readability, but it seems like it could do with some additional more structured / strongly typed properties in the underlying API to provide for some machine readability of the state.  e.g. Starting, Running, Terminated.  With addition of health checks, potentially Healthy and Degraded (although perhaps resource health status should be separate.)  WaitForResourceAsync could then be built on top of that more strongly typed model which I think would help mitigate some of the risks identified
For completeness, the implementation I ended up with was (haven't solved the infinite waiting problem as that doesn't' matter in my use case,)
async Task WaitForState()
{
    logger.LogInformation("Waiting for {Resource} to be in state {States}", waitOn.Resource.Name, waitOn.States);
    await foreach (var resourceEvent in resourceNotificationService.WatchAsync(_cts.Token))
    {
        if (resourceEvent.Resource == waitOn.Resource
            && waitOn.States.Contains(resourceEvent.Snapshot.State?.Text))
        {
            logger.LogInformation("{Resource} is {State}", waitOn.Resource.Name, resourceEvent.Snapshot.State?.Text);
            return;
        }
    }
}

Would this proposal also be a solution for our use-case?
We have a Yarn monorepo containing multiple frontend apps, that cannot boot nonsequentially: dependency installation cannot be performed concurrently, as they will race to update the state in node_modules, leading to a broken state.

@wuhkuh Take look at https://github.com/davidfowl/WaitForDependenciesAspire/ - that should cover what you're after.

@afscrome yes indeed, thanks!
To be clear, this isn't intended to be the full WaitFor experience that integrates with health checks, etc. that will enable controlling the order of resource startup during the dev inner loop. Integrating @davidfowl's WaitForDependencies example will take longer than we're planning for 8.1 and we wanted to improve the experience in test projects using Aspire.Hosting.Testing, so this design is simply about adding a higher-level API on ResourceNotificationService without introducing any new concepts or constructs. This includes introducing more semantics around resource states beyond the simple text states we have right now, as again that's a bigger work item. We think this is a reasonable building block to add for now that adds utility without introducing more complex concepts.
With this new method, a test can easily wait for one or more states to be reach with a Task.WhenAny, e.g.:
[Fact]
public async Task GetWebResourceRootReturnsOkStatusCode()
{
    // Arrange
    var appHost = await DistributedApplicationTestingBuilder.CreateAsync<Projects.MyAspireApp_AppHost>();
    appHost.Services.ConfigureHttpClientDefaults(client =>
    {
        client.AddStandardResilienceHandler();
    });

    await using var app = await appHost.BuildAsync();
    var resourceNotification = app.Services.GetRequiredService<ResourceNotificationService>();
    await app.StartAsync();

    // Act
    await Task.WhenAny(
        await resourceNotification.WaitForResourceAsync("webfrontend", KnownResourceStates.Running),
        await resourceNotification.WaitForResourceAsync("webfrontend", KnownResourceStates.FailedToStart)
    );
    var httpClient = app.CreateHttpClient("webfrontend");
    var response = await httpClient.GetAsync("/");

    // Assert
    Assert.Equal(HttpStatusCode.OK, response.StatusCode);
}

That said, it makes we wonder if we shouldn't add an overload that accepts an IEnumerable<string> of states to wait on to make this even more ergonomic (and efficient), e.g.:
public Task WaitForResourceAsync(string resourceName, IEnumerable<string> targetStates, CancellationToken? cancellationToken = null)

For the return type of WaitForResourceAsync, do you think it's worth returning the whole snapshot rather than just the text of the matching state?  In particular, I'm thinking about waiting on completion / termination as you may well want to differentiate between completed successfully and completing unsuccessfully.  (e.g. by checking the Exit Code).
Alternatively, maybe it would make sense to add a WaitForCompletion / WaitForSuccessfulCompletion method that handles this.


RoaringBitmapAggregator needs input/output annotations

Currently the RoaringBitmapAggregator doesn't have the input/output annotations and so is unusable

Merged into develop.


Progressive Web App

Requirement:

Make the app PWA-compatible
Add an install button in the Nav drawer. The app should get installed on the user's device when user clicks on it.
The app should be accessible offline. (open the app, turn off the internet. The user should be able to navigate to different screens. Only the data fetching should be paused. The user should be notified that there is network outage, therefore it's not possible to perform that action)
Lighthouse PWA score should be decent (>80 minimum, 100 bestcase)

Reference:
https://nextjs.org/docs/app/building-your-application/configuring/progressive-web-apps

PWA setup done. App can now be installed on mobile.
Push notifications setup is still pending.


fix: Property setter jsonrpc should follow set{Prop} pattern

:tada: This PR is included in version 1.4.1-next.1 :tada:
The release is available on:

npm package (@next dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Configuring system parameters for Siddhi Extensions has not been documented

Description:
Way to configure System parameters of a Siddhi extension in the deployment.yaml file is not documented.
eg:
For configuring host & port system parameters of tcp extension, the following has to be added in SPHOME/conf/worker/deployment.yaml
siddhi:
  extensions:
    - extension:
        name: tcp
        namespace: source
        properties:
          host: <IP_ADDRESS>
          port: 5511

Suggested Labels:
Documentation
Suggested Assignees:
@RukshiW
Related Issues:
https://github.com/wso2-extensions/siddhi-store-rdbms/issues/43

@RukshiW A kind reminder on this.

Please check [1] and let me know if any further corrections are needed.
[1] https://docs.wso2.com/display/SP420/Overriding+System+Parameter+Values+of+an+Extension

@RukshiW Please do the following corrections.

Step3 should be changed as,

siddhi:
    extensions:
        - extension:

(The - in front of extension is missing)

Step 4 says "The archetypes of extensions supported are execution, io, map, script and store". source and sink are also supported (Usage of source is shown in Example 1).

Example 2 should be changed as,

siddhi:
  extensions:
    - extension:
        name: rdbms
        namespace: store
        properties:
          mysql.batchEnable: true
          mysql.batchSize: 1000
          mysql.indexCreateQuery: "CREATE INDEX {{TABLE_NAME}}_INDEX ON {{TABLE_NAME}} ({{INDEX_COLUMNS}})"
          mysql.recordDeleteQuery: "DELETE FROM {{TABLE_NAME}} {{CONDITION}}"
          mysql.recordExistsQuery: "SELECT 1 FROM {{TABLE_NAME}} {{CONDITION}} LIMIT 1"

(extension should be mentioned with a - in front; and the name and namespace have to be swapped)

Did the corrections mentioned in the previous comment by senthuran16.

@RukshiW Please re-indent Example 2 as:
siddhi:
  extensions:
    - extension:
        name: rdbms
        namespace: store
        properties:
          mysql.batchEnable: true
          mysql.batchSize: 1000
          mysql.indexCreateQuery: "CREATE INDEX {{TABLE_NAME}}_INDEX ON {{TABLE_NAME}} ({{INDEX_COLUMNS}})"
          mysql.recordDeleteQuery: "DELETE FROM {{TABLE_NAME}} {{CONDITION}}"
          mysql.recordExistsQuery: "SELECT 1 FROM {{TABLE_NAME}} {{CONDITION}} LIMIT 1"

@RukshiW I have done the changes @senthuran16 mentioned for all doc spaces except 400(Not enough access). Could we migrate the latest change for the specific doc version and close this issue?

Did the same changes in the SP 4.0.0 space.

Closed as per the above comment.
The document can be found at Configuring System Parameters for Siddhi Extensions


[BUG] Invalid workspace

Description/Screenshot
All of a sudden all the api calls to azure insights started giving me Invalid workspace error.
I've made sure the connection strings are correct so I don't know why this could be happening
{
  "itemsReceived": 8,
  "itemsAccepted": 0,
  "errors": [
    {
      "index": 0,
      "statusCode": 400,
      "message": "Invalid workspace"
    },
    {
      "index": 1,
      "statusCode": 400,
      "message": "Invalid workspace"
    },
    {
      "index": 2,
      "statusCode": 400,
      "message": "Invalid workspace"
    },
    {
      "index": 3,
      "statusCode": 400,
      "message": "Invalid workspace"
    },
    {
      "index": 4,
      "statusCode": 400,
      "message": "Invalid workspace"
    },
    {
      "index": 5,
      "statusCode": 400,
      "message": "Invalid workspace"
    },
    {
      "index": 6,
      "statusCode": 400,
      "message": "Invalid workspace"
    },
    {
      "index": 7,
      "statusCode": 400,
      "message": "Invalid workspace"
    }
  ]
}

Steps to Reproduce

OS/Browser: Version 107.0.5304.107 (Official Build) (64-bit)
SDK Version [e.g. 22]: 2.8.9
How you initialized the SDK:

Using version 2.8.9
 this.appInsights = this._zone.runOutsideAngular(() => new ApplicationInsights({
      config: {
        connectionString: environment.appInsightsConnectionKey
      },
    }));

    this._zone.runOutsideAngular(() => {
      this.appInsights.loadAppInsights();
      this.appInsights.context.application.ver = version;
    });

Expected behavior
Should work with the correct connection string.
Additional context
Is it possible that this has something to do when creating the resource between Classic and Workspace based?

I understood that the insights resource only had one connection string no? Either way I also tried it with another insights resource and it gives me the same error.

@DavidMarquezF you can create multiple application insights under one workspace.  So what's the access level of your workspace? (reference link on how to assign proper roles)

I just recreated the resources and now it works again. Thanks tho!


Keep a parallel version of "refactored" executors in executors repos

In preparation for the transition to the microservices refactor, a parallel "services" version of each executor plugin should be placed and  maintained in the develop branch.

Pull requests for this issue are in their respective executor repos:

[ ] Custom template: https://github.com/AgnostiqHQ/covalent-executor-template/pull/8
[ ] SSH: https://github.com/AgnostiqHQ/covalent-ssh-plugin/pull/3
[ ] Slurm: https://github.com/AgnostiqHQ/covalent-slurm-plugin/pull/7

Refactored executors will simply have their own branch.


Moonwell rewards seem too high

rewardTokenEmissions seem to be too high. Emissions are supposed to be normalized to a day, looks like it is normalized to a year.

See visualizer graph here

Seems to look right and is fixed in the pending version: https://subgraphs.messari.io/subgraph?endpoint=https://api.thegraph.com/subgraphs/id/QmXYwnpaLAo5d5XSHHnuguFY13QsXoviEKeM2hnjiQKzL3&tab=poolOverview


An error occurred streaming completion from Ollama API: Request failed with status code 405

Hi,
i have an error after Transcript, someone can help me?
log below:
Transcript:
 Hi, how are you?
Request failed with status code 405
Traceback (most recent call last):
  File "C:\Users\simo1\Desktop\AlwaysReddy-main\llm_apis\ollama_client.py", line 57, in stream_completion
    raise RuntimeError(f"Request failed with status code {response.status_code}")
RuntimeError: Request failed with status code 405
Traceback (most recent call last):
  File "C:\Users\simo1\Desktop\AlwaysReddy-main\llm_apis\ollama_client.py", line 57, in stream_completion
    raise RuntimeError(f"Request failed with status code {response.status_code}")
RuntimeError: Request failed with status code 405

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\simo1\Desktop\AlwaysReddy-main\actions\always_reddy_voice_assistant\main.py", line 62, in handle_default_assistant_response
    response = self.AR.completion_client.process_text_stream(stream,
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\simo1\Desktop\AlwaysReddy-main\completion_manager.py", line 166, in process_text_stream
    for chunk in text_stream:
                 ^^^^^^^^^^^
  File "C:\Users\simo1\Desktop\AlwaysReddy-main\llm_apis\ollama_client.py", line 64, in stream_completion
    raise RuntimeError(f"An error occurred streaming completion from Ollama API: {e}")
RuntimeError: An error occurred streaming completion from Ollama API: Request failed with status code `405```

config.py:
## MAKE A COPY OF THIS CALLED config.py
VERBOSE = True
USE_GPU = False  # Set to True to use GPU acceleration. Refer to the README for instructions on installing PyTorch with CUDA support.

### HOTKEY BINDINGS ###
# Hotkeys can be set to None to disable them
# On Mac/Linux, a hotkey cannot overlap another (e.g. cmd+e and cmd+shift+e)
CANCEL_HOTKEY = 'alt+ctrl+e'
NEW_CHAT_HOTKEY = 'alt+ctrl+w'
RECORD_HOTKEY = 'alt+ctrl+r' # Press to start, press again to stop, or hold and release. Double tap to include clipboard
READ_FROM_CLIPBOARD = "ctrl+alt+c"
TRANSCRIBE_RECORDING = "ctrl+alt+t"

### COMPLETIONS API SETTINGS  ###
# Just uncomment the ONE api you want to use

### LOCAL OPTIONS ###

## OLLAMA COMPLETIONS API EXAMPLE ##
COMPLETIONS_API = "ollama"
COMPLETION_MODEL = "llama3.2"
OLLAMA_API_BASE_URL = "http://localhost:3000" #This should be the defualt
OLLAMA_KEEP_ALIVE = "-1" # The duration that models stay loaded in memory. Examples: "20m", "24h". Set to "-1" to keep models loaded indefinitely

## LM Studio COMPLETIONS API EXAMPLE ##
# COMPLETIONS_API = "lm_studio"
# COMPLETION_MODEL = "local-model" # You dont need to update this
# LM_STUDIO_API_BASE_URL = "http://localhost:1234/v1" #This should be the defualt

# TabbyAPI COMPLETIONS API EXAMPLE ##
# COMPLETIONS_API = "tabby_api"
# COMPLETION_MODEL = "llama3-7b-instruct-4.0bpw-exl2"
# TABBY_API_BASE_URL = "http://localhost:5000/v1"

### Hosted APIS ###

## ANTHROPIC COMPLETIONS API EXAMPLE ##
# COMPLETIONS_API = "anthropic"
# COMPLETION_MODEL = "claude-3-5-sonnet-20240620"

## TOGETHER COMPLETIONS API EXAMPLE ##
# COMPLETIONS_API = "together"
# COMPLETION_MODEL = "meta-llama/Llama-3-8b-chat-hf"

## OPENAI COMPLETIONS API EXAMPLE ##
# COMPLETIONS_API = "openai"
# COMPLETION_MODEL = "gpt-4o"

## PERPLEXITY COMPLETIONS API EXAMPLE ##
# COMPLETIONS_API = "perplexity"
# COMPLETION_MODEL = "llama-3-sonar-small-32k-online"

## OPENROUTER COMPLETIONS API EXAMPLE ##
# COMPLETIONS_API = "openrouter"
# COMPLETION_MODEL = "openai/gpt-3.5-turbo"

## GROQ COMPLETIONS API EXAMPLE ##
# COMPLETIONS_API = "groq"
# COMPLETION_MODEL = "llama3-70b-8192"

### COMPLETIONS API PARAMETERS ###
# Allows you to override the default parameters for the completions API
# The available parameters depend on which completions API you are using, so should be looked up in the API documentation online
COMPLETION_PARAMS = {"temperature": 0.7, "max_tokens": 2048}

### TRANSCRIPTION API SETTINGS ###

## Faster Whisper local transcription ###
TRANSCRIPTION_API = "FasterWhisper" # this will use the local whisper model
WHISPER_MODEL = "tiny.en" # If you prefer not to use english set it to "tiny", if the transcription quality is too low then set it to "base" but this will be a little slower
BEAM_SIZE = 5

## Transformers Whisper local transcription ###
# TRANSCRIPTION_API = "TransformersWhisper"
# WHISPER_MODEL = "openai/whisper-tiny.en"

## OPENAI Hosted Transcription ###
# TRANSCRIPTION_API = "openai" # this will use the hosted openai api

### Piper TTS SETTINGS ###
TTS_ENGINE="piper"
PIPER_VOICE = "default_female_voice" # You can add more voices to the piper_tts/voices folder
PIPER_VOICE_INDEX = 0 # For multi-voice models, select the index of the voice you want to use
PIPER_VOICE_SPEED = 1.0 # Speed of the TTS, 1.0 is normal speed, 2.0 is double speed, 0.5 is half speed

### OPENAI TTS SETTINGS ###
# TTS_ENGINE="openai"
# OPENAI_VOICE = "nova"

### PROMPTS ###
# Options: "default_prompt", "chat_prompt"
# - "default_prompt": Straight to the point assistant that can write to your clipboard when requested.
# - "chat_prompt": Simple prompt for a friendly back-and-forth chat. Does NOT support writing to clipboard.
# - None: No system prompt, for the raw out-of-the-box model behavior.
# Or create your own prompt in the "system_prompts" folder, then put the name of the file here.
ACTIVE_PROMPT = "default_prompt"

### MISC ###
AUDIO_FILE_DIR = "audio_files"
MAX_TOKENS = 8000 #Max tokens allowed in memory at once
CLIPBOARD_TEXT_START_SEQ = "[CLIPSTART]" #the model is instructed to place any text for the clipboard between the start and end seq
CLIPBOARD_TEXT_END_SEQ = "[CLIPEND]" #the model is instructed to place any text for the clipboard between the start and end seq
TIMESTAMP_MESSAGES = True # If this is true a timestamp will be added to the end of each of your messages

DOUBLE_TAP_THRESHOLD = 0.4 # The time window in which a second press must occur to be considered a double tap
SUPPRESS_NATIVE_HOTKEYS = True # Suppress the native system functionality of the defined hotkeys above (Windows only)
ALWAYS_INCLUDE_CLIPBOARD = False # Always include the clipboard content without having to double tap the record hotkey

### AUDIO SETTINGS ###
BASE_VOLUME = 1
START_SOUND_VOLUME = 0.05
END_SOUND_VOLUME = 0.05
CANCEL_SOUND_VOLUME = 0.09
MAX_RECORDING_DURATION= 600 # If you record for more than 10 minutes, the recording will stop automatically

OLLAMA_API_BASE_URL = "http://localhost:3000"

I see you're using a different port than the default. What method did you use to install Ollama? What OS are you on?

COMPLETION_MODEL = "llama3.2"

Make sure Ollama has llama3.2 downloaded before you try to use it in AlwaysReddy. You can do this by running ollama run llama3.2 in the terminal.

Also try updating your Ollama if you haven't in a while.

OLLAMA_API_BASE_URL = "http://localhost:3000"

I see you're using a different port than the default. What method did you use to install Ollama? What OS are you on?

cause i run Ollama in docker with URL= http://localhost:3000/
i try to run on windows11

COMPLETION_MODEL = "llama3.2"

Make sure Ollama has llama3.2 downloaded before you try to use it in AlwaysReddy. You can do this by running ollama run llama3.2 in the terminal.

it works:
PS C:\Users\simo1\Desktop\AlwaysReddy-main> ollama run llama3.2
>>> hi
Hello! How can I assist you today?
>>> Send a message (/? for help)

Also try updating your Ollama if you haven't in a while.

just updated

sorry, now it's work! i closed ollama with docker and run it in cmd with ollama serve, and of course using default port.
thank you for your support!


Please tag version 3 - it's blocking new projects from installing this library :)

Hi!
My apologies for the intrusion 🙂 . I was wondering if you have a timeline for releasing doctrine extensions 3? We're noticing users having increased problems installing doctrine extensions, because new projects tend to have doctrine/common 2 and doctrine/persistence 2 installed. So when they try to install doctrine-extensions, it fails. This is fixable by downgrading doctrine/common and persistence, but it's not obvious. Once you release doctrine-extensions 3, I can get Stof to merge https://github.com/stof/StofDoctrineExtensionsBundle/pull/415 and tag... and the world will be saved! Well, ok, the world will be a teeny bit better :).
Thanks!

I too, am very appreciative of the work done by @AkenRoberts and co. to modernize the library. Next, I agree with @weaverryan on this. I've been holding off on migrating some projects from Eloquent because I'm still waiting for a 3.0 stable release. Could we have a roadmap for this?

Tagged: https://github.com/Atlantic18/DoctrineExtensions/releases/tag/v3.0.0 🥳

Thank you!

I too, am very appreciative of the work done by @AkenRoberts and co. to modernize the library

💯


Want to add security policy

Is your feature request related to a problem? Please describe.
Want to add security policy to protect the website against the harms
**
Please assign me the issue

Please assign me this issue
@TherkuTech


Ensure appropriate safety checks and bookkeeping within DataStore.delete()

as far as safety checks the query interface allows for nearly any delete scenario. For example, a constrained delete on a single index when there are multiple indicies should throw some form of exception (or simply retunrn false?) because it would result in inconsistent data across indices - that is unless the query is meant to just represent what data to delete and then its deleted in every index, but then there'd have to be a different mechanism to entire delete an index.
for bookkeeping, if all the data for an adapter is deleted it'd be nice to delete appropriate metadata, such as the adapter, the stats, the internal adapter, the adapter index mapping. Likewise if all the data in an index is deleted, similar metadata updates should occur and the table/index should be dropped.

complete


LIKA-244: Add do not track attributes to twitter embeds and require cookie consent before loading templates with third party cookies

Refactored translations and ckan javascript files.


Need help with icons on mac

I've read the readme, but I don't how to embed a customized notifier. Help.

found in docs, thanks

👍🏽

If anyone finds this -- here is the link.


Fix PointerOffset.offset implementation

Close #70

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 25.04%.  Consider uploading reports for the commit e0c56fb to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #71      +/-   ##
==========================================
+ Coverage   24.39%   25.04%   +0.64%
==========================================
  Files          50       50
  Lines        1238     1238
==========================================
+ Hits          302      310       +8
+ Misses        936      928       -8

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Get rid of website.connect_tokens

Closes #715.

Tests pass locally and UI appears to work. Reading the code ...

When I add an account that's linked to a different Gratipay account, I end up on /on/confirm.html with no querystring. From reading the code, I expect to end up on /on/confirm.html?id=2345678. I put a set_trace right before the redirect and that code is being run. If I hit back in Chrome I get back to an URL with the querystring. What's going on? Is this some weird Chrome behavior?

Oh! Okay ... same behavior in Firefox. What I'm seeing is the Facebook landing cleanup.

https://github.com/gratipay/gratipay.com/blob/1804/templates/base.html#L108-L114

Probably the pushState there should include the querystring (and maybe be replaceState instead).

Querystring clobbering reticketed as #3252.


Don't assume local repo with cedar-policy

Don't assume local repo with cedar-policy
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@andrewmwells-amazon I think we want to leave this as-is. I updated it in #43 since the main branch requires the latest version of cedar-policy -- not the version on crates.io. We definitely want the crates.io version in the release/x.x.x branches though.

@andrewmwells-amazon I think we want to leave this as-is. I updated it in https://github.com/cedar-policy/cedar-java/pull/43 since the main branch requires the latest version of cedar-policy -- not the version on crates.io. We definitely want the crates.io version in the release/x.x.x branches though.

I see. Not ideal, but probably ok for now. It breaks cedar-java-hello-world, but I think it's reasonable for that to depend on a release instead of main. Added a comment and we can fix it after the next cedar-policy release.

I see. Not ideal, but probably ok for now. It breaks cedar-java-hello-world, but I think it's reasonable for that to depend on a release instead of main. Added a comment and we can fix it after the next cedar-policy release.

We may run into this situation again in the future (un-released breaking changes on the main branch in cedar) so there may not be a great fix. I think we just want to redirect all users to the release branches (and the released version on Maven, once available).
But this is a bit of a foot gun currently: should we switch to using release/2.3.x as the default branch, and rename main to experimental?


feat(home-manager): init rio module

Added a module for the terminal Rio.

sorry, but it looks like this needs to be rebased

all good, rebased


How to copy the selection into system clipboard?

Is there a way to yank the text into the system clipboard?
I saw the system clipboard setting in
set-x-clipboard() {
    if which pbcopy >/dev/null 2>&1; then
        clipcopy='pbcopy'
    elif which xsel >/dev/null 2>&1; then
        clipcopy='xsel --clipboard --input'
    else
        return 1
    fi

    (( ! $+DISPLAY )) ||
        print -rn -- "$1" | eval "$clipcopy"
}

But I have no idea about how to enable it.

I have fixed to support this feature. Update this plugin and try it out again.

I just tried it, but it is still not working :(. Could you provide a step-by-step guide?

@haifengkao Hmm, sorry... Is the DISPLAY variable set?

No, how to set it?

Probably this is the cause. I have tried to make it work even if the DISPLAY variable is not set.

ref: https://github.com/b4b4r07/zsh-vimode-visual/commit/18273051dc2de614794f185e9c97d351f96c4660

I saw in the commit that you either use xsel or pbcopy as copying wasn't working for me and I realized that I am using xcip. Maybe say it in the docs that for the copy to work one of the above 2 tools need to be installed.


prefilling check boxes and radio not working

I am providing the existed data to the Pdf form. All the text data is being nicely populated with the pdf filler but when going for the checkboxes or radio nothing is working out. Creating the data as below:
data = {
"NAME":"Test",
"Test CheckBox1":"Yes",
"Test CheckBox2":true,
"Test CheckBox3"":1,
"Test CheckBox4 ":"On"
}
Not any of the provided options/value for the checkbox is working . Kindly suggest the checkbox or radio is being shown as selected by providing prefilled data

have you checked if the Export-Value of the checkbox is indeed one of the values you set? it might differ. check with adobe acrobat -> right click on the checkbox -> properties -> options -> export value.

Yes there was difference in the values. thanks @maximilianschmidt


Login error - Sequence contains no elements

Please, attach the CareLinkErrorReport(en-US)xx.txt locate on c:\users\youruser\documents

@mattimart @nfontan I need the error report to look at this.

Just from looking at the error, it looks like server is returning no data for some of the fields and I don't guard against it. If I had error report, I could verify it.

CareLink<IP_ADDRESS>x64.zip
Try this. these errors are caused by CareLink server or frontend down.

@mattimart @nfontan Fixed in CareLink<IP_ADDRESS>x64. Close if you agree.