Add links to resourcemanager / jobhistory

Add links to the approrpriate hadoop UIs, in case users want to dive deep
Added two optional cmdline args: public-resource-manager-url and public-history-server-url because we don't have a single URL that's both publicly accessible + works with our internal servers.
r? @tchow-stripe @dug-stripe

Since there's css here, could you add a screenshot or two?

ah i actually took the screenshot and forgot to attach it!

lgtm

The placement of the link is peculiar since it's hanging out in space by itself as the only right-aligned text. The spacing and it being the only link-colored item draws the eye and makes it stand out more than is appropriate. Can you put it next to the job id without link coloring and in a smaller font?

Hmmm I get where you're coming from. This feedback is consistent with the way the rest of the page is designed.
I'm actually down with making the job id itself the link to RM / JH, but I really don't want to get rid of the coloring even tho that's the status quo. I think it massively hurts the discoverability of the page. Users don't randomly hover their mouse over normal black text, and it's only by coincidence / explicit teaching that they learn about the links (e.g. previous duration links to previous job)
What do you think?

You could try underlines or one of those ↗icons for external links instead of having a different color, something that suggests it's a link without sticking out so much.

Is the concern with the color that users will get distracted by it and it'll make their lives harder? I'm not sure if I buy that
I don't really know what the right design is, and it very well might be what you're suggesting. but this feels to me like a micro-optimization on a thing we're not measuring, which feels wasteful. I feel like if we actually care about the design of jobtracker that much we'd actually involve a designer. But since we don't i'll assume that this isn't important enough, and my hunch is to punt on it.
Do you have any concerns about that?

The concern is trying to fit in with the overall design to maintain readability. Similar to how we try to write code in the same style as the surrounding file, we should try to add this link in a way that makes sense for the rest of the page. Having one blue link on the page doesn't match the style of the surrounding page.
I have concerns if we punt here because a designer is not involved. We can still strive to do a good job and apply design principles without metrics or a designer.

that's fair, we probably should be consistent.
I'm more comfortable turning all the links blue than turning this new link black. would that be better?

Can you make it look like this (making Configuration and Counters blue links and putting all the links on the same line)?


Is there a way to automatically crop the result?

Like place the detection over a transparent/white background

I found a demo of this segmenter on HuggingFace: https://huggingface.co/spaces/hysts/Yet-Another-Anime-Segmenter
In the app.py file, the construction of the images is handled in the predict function. You can add an alpha channel to masked like so:
    # Copy image and add alpha channel.
    masked = image.copy()[:, :, ::-1]
    alpha = np.full(masked.shape[:-1], 255)
    masked = np.dstack((masked, alpha))

    # Mark blank areas.
    mask = instances.pred_masks.cpu().numpy().astype(int).max(axis=0)
    masked[mask == 0] = [0, 0, 0, 0]

Note that the colours of the resultant image look a bit weird (more faded than the original; not sure why this happens):

but it should be easy to copy the pixels from the original image using the alpha channel as a mask.


DEX-decimals issue

If you try to SWAP from (doesn't matter the coin/token) with the value 0.0012/0.0013, it crashes with:
Error: [number-to-bn] while converting number "0x0.004189374bc6a7f" to BN.js instance, error: invalid number value. Value must be an integer, hex string, BN or BigNumber instance. Note, decimals are not supported. Given value: "0x0.004189374bc6a7f"

Hey @beyondthecode-bc
Could you tell me what value Moralis.Utils.Token returns?
Because it can not be "0.0012/0.0013". That amount has to an integer.
Please also let me know what values are in params object?

Please find the live test of the Swap issue:
https://we.tl/t-YElP7CMiVO
I understand what you are trying to say but, if I try values like 0.00012, it works. Only 0.0012 and so on.. crashes the DEX. Not sure what can cause this issue

Sorry, @beyondthecode-bc I deleted your comment because of the link. It's not secure

I don't see any problems

make sure you are running the latest build

@Y0moo select a Token first of all.. most important :)
I understand, hope that you've saw the issue replicating. If you have a different website where I can upload it... let me know

@BanalitoRaulito I was able to reproduce the issue


make check does not work - treats multiple files as one file it appears

The end of the make -d check output:
Updating goal targets....
Considering target file 'test-suite.log'.

   Looking for an implicit rule for 'tests/link.log
tests/link-2.log
tests/nomode.log
tests/objectlist.log
tests/quote.log
tests/sh.log
tests/suffix.log
tests/tagtrace.log
tests/cdemo-static.log
tests/cdemo-static-make.log
tests/cdemo-static-exec.log
tests/demo-static.log
tests/demo-static-make.log
tests/demo-static-exec.log
tests/demo-static-inst.log
tests/demo-static-unst.log
tests/depdemo-static.log
tests/depdemo-static-make.log
tests/depdemo-static-exec.log
tests/depdemo-static-inst.log
tests/depdemo-static-unst.log
tests/mdemo-static.log
tests/mdemo-static-make.log
tests/mdemo-static-exec.log
tests/mdemo-static-inst.log
tests/mdemo-static-unst.log
tests/cdemo-conf.log
tests/cdemo-make.log
tests/cdemo-exec.log
tests/demo-conf.log
tests/demo-make.log
tests/demo-exec.log
tests/demo-inst.log
tests/demo-unst.log
tests/demo-deplibs.log
tests/depdemo-conf.log
tests/depdemo-make.log
tests/depdemo-exec.log
tests/depdemo-inst.log
tests/depdemo-unst.log
tests/mdemo-conf.log
tests/mdemo-make.log
tests/mdemo-exec.log
tests/mdemo-inst.log
tests/mdemo-unst.log
tests/mdemo-dryrun.log
tests/mdemo2-conf.log
tests/mdemo2-make.log
tests/mdemo2-exec.log
tests/pdemo-conf.log
tests/pdemo-make.log
tests/pdemo-exec.log
tests/pdemo-inst.log
tests/demo-nofast.log
tests/demo-nofast-make.log
tests/demo-nofast-exec.log
tests/demo-nofast-inst.log
tests/demo-nofast-unst.log
tests/depdemo-nofast.log
tests/depdemo-nofast-make.log
tests/depdemo-nofast-exec.log
tests/depdemo-nofast-inst.log
tests/depdemo-nofast-unst.log
tests/demo-pic.log
tests/demo-pic-make.log
tests/demo-pic-exec.log
tests/demo-nopic.log
tests/demo-nopic-make.log
tests/demo-nopic-exec.log
tests/cdemo-shared.log
tests/cdemo-shared-make.log
tests/cdemo-shared-exec.log
tests/mdemo-shared.log
tests/mdemo-shared-make.log
tests/mdemo-shared-exec.log
tests/mdemo-shared-inst.log
tests/mdemo-shared-unst.log
tests/cdemo-undef.log
tests/cdemo-undef-make.log
tests/cdemo-undef-exec.log
tests/tagdemo-static.log
tests/tagdemo-static-make.log
tests/tagdemo-static-exec.log
tests/tagdemo-conf.log
tests/tagdemo-make.log
tests/tagdemo-exec.log
tests/tagdemo-shared.log
tests/tagdemo-shared-make.log
tests/tagdemo-shared-exec.log
tests/tagdemo-undef.log
tests/tagdemo-undef-make.log
tests/tagdemo-undef-exec.log
tests/demo-shared.log
tests/demo-shared-make.log
tests/demo-shared-exec.log
tests/demo-shared-inst.log
tests/demo-hardcode.log
tests/demo-relink.log
tests/demo-noinst-link.log
tests/demo-shared-unst.log
tests/depdemo-shared.log
tests/depdemo-shared-make.log
tests/depdemo-shared-exec.log
tests/depdemo-shared-inst.log
tests/depdemo-relink.log
tests/depdemo-shared-unst.log'.

   No implicit rule found for 'tests/link.log
tests/link-2.log
tests/nomode.log
tests/objectlist.log
tests/quote.log
tests/sh.log
tests/suffix.log
tests/tagtrace.log
tests/cdemo-static.log
tests/cdemo-static-make.log
tests/cdemo-static-exec.log
tests/demo-static.log
tests/demo-static-make.log
tests/demo-static-exec.log
tests/demo-static-inst.log
tests/demo-static-unst.log
tests/depdemo-static.log
tests/depdemo-static-make.log
tests/depdemo-static-exec.log
tests/depdemo-static-inst.log
tests/depdemo-static-unst.log
tests/mdemo-static.log
tests/mdemo-static-make.log
tests/mdemo-static-exec.log
tests/mdemo-static-inst.log
tests/mdemo-static-unst.log
tests/cdemo-conf.log
tests/cdemo-make.log
tests/cdemo-exec.log
tests/demo-conf.log
tests/demo-make.log
tests/demo-exec.log
tests/demo-inst.log
tests/demo-unst.log
tests/demo-deplibs.log
tests/depdemo-conf.log
tests/depdemo-make.log
tests/depdemo-exec.log
tests/depdemo-inst.log
tests/depdemo-unst.log
tests/mdemo-conf.log
tests/mdemo-make.log
tests/mdemo-exec.log
tests/mdemo-inst.log
tests/mdemo-unst.log
tests/mdemo-dryrun.log
tests/mdemo2-conf.log
tests/mdemo2-make.log
tests/mdemo2-exec.log
tests/pdemo-conf.log
tests/pdemo-make.log
tests/pdemo-exec.log
tests/pdemo-inst.log
tests/demo-nofast.log
tests/demo-nofast-make.log
tests/demo-nofast-exec.log
tests/demo-nofast-inst.log
tests/demo-nofast-unst.log
tests/depdemo-nofast.log
tests/depdemo-nofast-make.log
tests/depdemo-nofast-exec.log
tests/depdemo-nofast-inst.log
tests/depdemo-nofast-unst.log
tests/demo-pic.log
tests/demo-pic-make.log
tests/demo-pic-exec.log
tests/demo-nopic.log
tests/demo-nopic-make.log
tests/demo-nopic-exec.log
tests/cdemo-shared.log
tests/cdemo-shared-make.log
tests/cdemo-shared-exec.log
tests/mdemo-shared.log
tests/mdemo-shared-make.log
tests/mdemo-shared-exec.log
tests/mdemo-shared-inst.log
tests/mdemo-shared-unst.log
tests/cdemo-undef.log
tests/cdemo-undef-make.log
tests/cdemo-undef-exec.log
tests/tagdemo-static.log
tests/tagdemo-static-make.log
tests/tagdemo-static-exec.log
tests/tagdemo-conf.log
tests/tagdemo-make.log
tests/tagdemo-exec.log
tests/tagdemo-shared.log
tests/tagdemo-shared-make.log
tests/tagdemo-shared-exec.log
tests/tagdemo-undef.log
tests/tagdemo-undef-make.log
tests/tagdemo-undef-exec.log
tests/demo-shared.log
tests/demo-shared-make.log
tests/demo-shared-exec.log
tests/demo-shared-inst.log
tests/demo-hardcode.log
tests/demo-relink.log
tests/demo-noinst-link.log
tests/demo-shared-unst.log
tests/depdemo-shared.log
tests/depdemo-shared-make.log
tests/depdemo-shared-exec.log
tests/depdemo-shared-inst.log
tests/depdemo-relink.log
tests/depdemo-shared-unst.log'.
   Finished prerequisites of target file 'tests/link.log
tests/link-2.log
tests/nomode.log
tests/objectlist.log
tests/quote.log
tests/sh.log
tests/suffix.log
tests/tagtrace.log
tests/cdemo-static.log
tests/cdemo-static-make.log
tests/cdemo-static-exec.log
tests/demo-static.log
tests/demo-static-make.log
tests/demo-static-exec.log
tests/demo-static-inst.log
tests/demo-static-unst.log
tests/depdemo-static.log
tests/depdemo-static-make.log
tests/depdemo-static-exec.log
tests/depdemo-static-inst.log
tests/depdemo-static-unst.log
tests/mdemo-static.log
tests/mdemo-static-make.log
tests/mdemo-static-exec.log
tests/mdemo-static-inst.log
tests/mdemo-static-unst.log
tests/cdemo-conf.log
tests/cdemo-make.log
tests/cdemo-exec.log
tests/demo-conf.log
tests/demo-make.log
tests/demo-exec.log
tests/demo-inst.log
tests/demo-unst.log
tests/demo-deplibs.log
tests/depdemo-conf.log
tests/depdemo-make.log
tests/depdemo-exec.log
tests/depdemo-inst.log
tests/depdemo-unst.log
tests/mdemo-conf.log
tests/mdemo-make.log
tests/mdemo-exec.log
tests/mdemo-inst.log
tests/mdemo-unst.log
tests/mdemo-dryrun.log
tests/mdemo2-conf.log
tests/mdemo2-make.log
tests/mdemo2-exec.log
tests/pdemo-conf.log
tests/pdemo-make.log
tests/pdemo-exec.log
tests/pdemo-inst.log
tests/demo-nofast.log
tests/demo-nofast-make.log
tests/demo-nofast-exec.log
tests/demo-nofast-inst.log
tests/demo-nofast-unst.log
tests/depdemo-nofast.log
tests/depdemo-nofast-make.log
tests/depdemo-nofast-exec.log
tests/depdemo-nofast-inst.log
tests/depdemo-nofast-unst.log
tests/demo-pic.log
tests/demo-pic-make.log
tests/demo-pic-exec.log
tests/demo-nopic.log
tests/demo-nopic-make.log
tests/demo-nopic-exec.log
tests/cdemo-shared.log
tests/cdemo-shared-make.log
tests/cdemo-shared-exec.log
tests/mdemo-shared.log
tests/mdemo-shared-make.log
tests/mdemo-shared-exec.log
tests/mdemo-shared-inst.log
tests/mdemo-shared-unst.log
tests/cdemo-undef.log
tests/cdemo-undef-make.log
tests/cdemo-undef-exec.log
tests/tagdemo-static.log
tests/tagdemo-static-make.log
tests/tagdemo-static-exec.log
tests/tagdemo-conf.log
tests/tagdemo-make.log
tests/tagdemo-exec.log
tests/tagdemo-shared.log
tests/tagdemo-shared-make.log
tests/tagdemo-shared-exec.log
tests/tagdemo-undef.log
tests/tagdemo-undef-make.log
tests/tagdemo-undef-exec.log
tests/demo-shared.log
tests/demo-shared-make.log
tests/demo-shared-exec.log
tests/demo-shared-inst.log
tests/demo-hardcode.log
tests/demo-relink.log
tests/demo-noinst-link.log
tests/demo-shared-unst.log
tests/depdemo-shared.log
tests/depdemo-shared-make.log
tests/depdemo-shared-exec.log
tests/depdemo-shared-inst.log
tests/depdemo-relink.log
tests/depdemo-shared-unst.log'.

The fix provided above to retain "tr" has fixed the issue on ZOSCAN2B machine and also, on the jenkins build machine. For some reason this issue occurring again on ZOSCAN2B machine. So, we are not closing this issue yet, until we figure the reason for issue on ZOSCAN2B machine.


Overload more operators in R for ndarray

cc @thirdwing

Both method is OK.
As I remembr, +.Rcpp_MXDArray is for S3 and S4, setMethods is only for S4.

Rcpp_MXNDArray is  S4 object

That is why I said both are OK. We can follow this method.
PS: You won't see warnings below using +.Rcpp_MXDArray.
** R
** demo
** inst
** preparing package for lazy loading
in method for ‘+’ with signature ‘e1="Rcpp_MXNDArray",e2="numeric"’: no definition for class “Rcpp_MXNDArray”
in method for ‘+’ with signature ‘e1="Rcpp_MXNDArray",e2="Rcpp_MXNDArray"’: no definition for class “Rcpp_MXNDArray”
in method for ‘+’ with signature ‘e1="numeric",e2="Rcpp_MXNDArray"’: no definition for class “Rcpp_MXNDArray”
in method for ‘-’ with signature ‘e1="Rcpp_MXNDArray",e2="numeric"’: no definition for class “Rcpp_MXNDArray”
in method for ‘-’ with signature ‘e1="Rcpp_MXNDArray",e2="Rcpp_MXNDArray"’: no definition for class “Rcpp_MXNDArray”
in method for ‘-’ with signature ‘e1="numeric",e2="Rcpp_MXNDArray"’: no definition for class “Rcpp_MXNDArray”
in method for ‘*’ with signature ‘e1="Rcpp_MXNDArray",e2="numeric"’: no definition for class “Rcpp_MXNDArray”
in method for ‘*’ with signature ‘e1="Rcpp_MXNDArray",e2="Rcpp_MXNDArray"’: no definition for class “Rcpp_MXNDArray”
in method for ‘*’ with signature ‘e1="numeric",e2="Rcpp_MXNDArray"’: no definition for class “Rcpp_MXNDArray”
in method for ‘/’ with signature ‘e1="Rcpp_MXNDArray",e2="numeric"’: no definition for class “Rcpp_MXNDArray”
in method for ‘/’ with signature ‘e1="Rcpp_MXNDArray",e2="Rcpp_MXNDArray"’: no definition for class “Rcpp_MXNDArray”
in method for ‘/’ with signature ‘e1="numeric",e2="Rcpp_MXNDArray"’: no definition for class “Rcpp_MXNDArray”

I thought the warning will not happen if the setmethods are in https://github.com/dmlc/mxnet/blob/master/R-package/R/ndarray.R#L4 ? It did not happen on my side

Because init.nd.array is called in onLoad after the library loading

Defining a init.ndarray.methods and calling it during startup is not a "common" strategy, but it is OK.
I removed it and saw warnings.

I see, this was really due to our tricky requirement of handling the loading orders.. I thought we can go for the S4 way as it is consider more advanced?
We can think of a more formal way later. But I am afraid we do need a init function solution, due to library loading order problem


ui: translations update from weblate

Translations update from Hosted Weblate for InvokeAI/Web UI.
Current translation status:

Somebody's started on a hungarian translation but not added any actual translations yet. Lets not merge this until that happens. Also, this will require us adding a hu.json file.

@psychedelicious think we can merge this now

Oh, it's added the hu.json file for us. Huh, seem to recall some weirdness where manual action was required in the past - but that doesn't really make sense. Cool.


Kodi can't import .nfo files for Ash vs. Evil Dead

What TMM version are you using?
<IP_ADDRESS>
release, pre-release, nightly, or directly from GitHub/branch?
release
What is the actual behaviour?
tmm creates tvshow.nfo and .nfo files for all season 1 episodes, except for episode 1.  Kodi reports "WARNING: No information found for item '/DWMedia/DWMyth/VideosMetadata/TV/Ash_vs_Evil_Dead/', it won't be added to the library." when I update its library.
(Normally, I'd suspect Kodi, if it weren't that the metadata for episode 1 is not created.)
What is the expected behaviour?
.nfo files are created for all episodes, and Kodi can import them.
Steps to reproduce:
Update sources, scrape metadata, and write the .nfo files.  I've attached an ls -l of the source directory with the generated .nfo files.
Ash-source.txt
Additional
Have you attached the Logfile from the day it happened?
tmm_logs.zip
Your Operating system? (win/mac/linux? version?)
Linux - openSUSE Leap 42.1

I've done some more investigation...  Referring to Ash-source.txt, you can see that Ash_vs_Evil_Dead_s1e1.nfo is not created.  What's interesting is that the  for episode 1 has been written into Ash_vs_Evil_Dead_s1e10, along with the  for episode 10.  Also, when looking at the Media Files tab for episode 1, you see both Ash_vs_Evil_Dead_s1e1.iso and Ash_vs_Evil_Dead_s1e10.iso listed.  All other episodes show only their episode's .iso file.
You'll note that I use symbolic links to handle .iso files that hold multiple episodes.  Perhaps this has something to do with this?

when did you import these episodes into the database? IIRC we fixed some episode detection bugs with the last release - maybe you stumbled across some of this bugs (detecting s1e1 and s1e10 as multi file episodes..)
could you try to remove these episodes from tmm and let tmm re-import them (to be sure everything works as expected, please also remove the NFO files)

Actually, I removed the episodes and re-imported them just before my post last night.  I'm currently on <IP_ADDRESS>; I think that's the version I was on when I first ran into this issue.

did you delete the nfo too? otherwise the season/epsiode number is read from the nfo rather than from the file name

I just deleted and reloaded everything again to make sure.  Sorry, the result was the same.

Finally I was able to reproduce the issue - a fix will follow soon

this should be fixed in the next nightly/release

Thanks, Manuel!
On 09/20/2016 03:47 AM, Manuel Laggner wrote:

this should be fixed in the next nightly/release
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/tinyMediaManager/tinyMediaManager/issues/78#issuecomment-248267054,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGIh2lXrxTX7oNjssRgbpnlHuthYD9TFks5qr7nEgaJpZM4J0YDB.


[PE-D][Tester C] Customer display only shows customer id 1.

Even when customer 7 was pressed, the display shows customer 1.

Every other tab like vehicles also has similar problem.
Edit: after reading further, I think the viewing should be done through view command, I think the view command should be added in front as it might be confusing for user

Labels: type.DocumentationBug severity.Low
original: zm-l/ped#6

Need to clarify in UG that clicking does not change selected object in view details panel
Move View command instructions up in UG(?)

also fixed in pr #151


Arow keys not accepted

v6.0.3 (6035) on macOS 12.0.1
when clicking in the middle column, the whole list gets a blue highlight border but arrow keys no longer work. instead of selecting the item and loading it, the arrow key moves the highlight (blue fill) over the selected item but the item can't be selected, i.e. loaded in the right-most pane.
An app restart does not clear the bug.

@shoantel Do you have voice over or any navigation assisted technologies enabled?

Not that I'm aware of.  How would I know of things I didn't knowingly enable?

Ah. For some unknown reason 'full keyboard control had been enabled (not idea by what). Disabling this seemed to fix the issue, so sorry for well-intentioned—but false—alert.

I'm glad you got it figured out!


Virtual MIDI ports, inputs and outputs are swapped

When I list my virtual MIDI ports, input ports and output ports are swapped.
Virtual input ports are listed as output ports and vice versa.
To Reproduce
Steps to reproduce the behavior:

I create my ports:
let midi = MIDI()

midi.createVirtualInputPorts(numberOfPort: 1, [Int32(1000000)], names: ["MIDI Test Input Port"])
midi.createVirtualOutputPorts(numberOfPort: 1, [Int32(2000000)], names: ["MIDI Test Output Port"])

I list them, using:
midi.inputNames
and
midi.destinationNames

I see, that
midi.inputNames includes "MIDI Test Output Port"
midi.destinationNames includes "MIDI Test Input Port"

Expected behavior
I would expect that my input port is listed in midi.inputNames, and output in outputNames.
Screenshots

Details (please complete the following information):

Type: Mac
OS: Big Sur 11.2.3
AudioKit Version 5

Additional context
StackOverflow user "Eggsalat" suggested:
In MIDI+VirtualPorts.swift, createVirtualInputPorts calls MIDIDestinationCreateWithBlock, and createVirtualOutputPorts calls MIDISourceCreate. Maybe that's where the issue is?

Bad commit message, but this should be addressed here c7438568b468eeefcda855d8ddce1e3b9ac4f239
Let me know if that works as expected.

I do like 'count' rather than 'numberOfPort'.
I also like that we got rid of an unwanted whitespace in front of port names.
However, on core functionality, I now have two issues that relates to ports being swapped.

In the application that I send FROM (Logic Pro), the destination port now shows up as "MIDI Test Output Port".
I would expect the INPUT port to show up.

I can create only one port, either input or output. Only the last port created show up.

If I:
midi.createVirtualInputPorts(count: 1, uniqueIDs: [Int32(1200000)], names: ["MIDI Test Input Port"])
midi.createVirtualOutputPorts(count: 1, uniqueIDs: [Int32(1500000)], names: ["MIDI Test Output Port"])
Only the Output port is available
If I:
    midi.createVirtualOutputPorts(count: 1, uniqueIDs: [Int32(1500000)], names: ["MIDI Test Output Port"])
    midi.createVirtualInputPorts(count: 1, uniqueIDs: [Int32(1200000)], names: ["MIDI Test Input Port"])

Only the Input port is available.
Seems that the destroyInputPort and destroyVirtualOutput port destroy the wrong ports?
This might dig deeper, and perhaps it drills down to a bug in CoreMIDI?

Aure, I have done a small demonstration project for this issue. It's a MIDI monitor that lists the inputs and outputs with their PortIDs. It tracks incoming MIDI messages with their PortIds.
As I'm a newbie on this, I have no idea how to share it on GitHub, so I've simply zipped it an put it on DropBox:
https://www.dropbox.com/s/szeaiqjo7na015r/MIDI Port Test.zip?dl=0
Use it if you will. If not, it was fun to do anyway :-)

This is great, sample projects help us a lot.

@ShowtimeSoft Can you give @emurray2 's solution a shot. You can either copy the file that he changed, or upgrade to develop. There have been other change for 5.2 though, so you might have some migration headaches. 5.2 is not ready for release yet.

Thanks, guys!
@emurray2, I'd very much like to see your example project, as I can still not quite make it work as expected.
Fixed: I can now create both an input and an output port.
Still, to address a specific port ID, I need to swap the portUIDs, using an input ports uid for destination.
I do have a confession here. Perhaps I have totally misunderstood the concept of virtual ports. I'd like to hear what you think.
My understanding was that I was creating virtual input and destination ports of my app.
In that, I would expect the virtual destinations to be listed as destinations.
But the more I think of it, it seems that the virtual ports conceptually live outside the app, as stand alone objects.
In that thinking, it makes sense that the input of the virtual port is listed in the destination list of my app.
I've tried to make a diagram for this.

Is that correctly understood?
Still, no matter if I use main or develop, I do need to swap the uids, using the inputport uid as destination port uid if I want to target a specific port.
Finally, I'm experiencing that I can't use both virtual ports and physical ports at the same time.
If I call midi.openOutput(), messages are sent out on the physical ports, but the virtual ports doesn't work anymore.
@aure, should I file this as a separate issue?

 I would love to share a Cookbook example I have of sending/receiving MIDI to an external receiver. The way your diagram is set up is how the virtual ports are set up right now. For example, creating virtual input ports actually creates a destination input port for the receiver. I'll do some more tests and see if I can make the openOutput() more clear. I believe that is the default function for opening a virtual output port with no parameters provided.

That sounds fantastic!
Not sure about openOutput(). I think it is for opening the physical outputs.
At least, that seems to be the case with regards to inputs.
If I midi.openInput(), I do receive messages from my physical device. If not, I don't.
If I do midi.openOutput(), I can send to my physical device, but then it seems that the virtual port is disabled.

Interesting... I'll do some tests in the next couple of days and try it out. For now, here's a zip project demonstrating what I've done so far. The develop branch seems to be able to handle multiple virtual inputs and outputs at the same time without destroying them this time.
MIDI Debug.zip

@emurray2 I tried to run your example, but could not get it to work. As far as I understand, it can't find AudioKit.

I tried to link to AudioKit as a package dependency. It worked, but naturally, the develop branch did not include the changes you made.

@emurray2 In case it can be of any help, I have attached my Test App.
Compiled (MacOS Big Sur)
MIDI Port Test.zip
Source Code:
MIDI Port Test Source.zip

Oh awesome! I have been using it, and it's a big help! The ports don't show up correctly yet when a MIDI message is received, but that's what I'm going to work on today. It's not anything wrong with the app (but I need to make sure I have everything organized in the MIDI API itself).
For the package, I think I included a local one on my system. That was my mistake and probably why it's not showing up.
Try this one instead:
MIDI Debug.zip
Also, if it ever gets out of sync, just delete and re-add the package or right click on the package itself and select "Update."


Docs to include via CDN are wrong

script tags must have a closing tag. Like this
<script src="//cdnjs.cloudflare.com/ajax/libs/list.js/1.1.1/list.min.js"></script>

Ouch, fix'd! Thx!


Merge ramenctl config into ramenctl deploy

We never deploy without config, and unconfiguring basically undeploy ramen on the managed clusters so after ramenctl unconfig you must deploy again.
Removing the config step makes deploying ramen 2 times easier and looks better in demos.
We can keep the command in case we need it, but call the same code from deploy.

Increasing priority as people report issues when they use ramenctl incorrectly. Merging deploy and config will make these issues impossible.


Add support for SHA3

TODO:

[x] Panic-section of docs that says N bits of data
[ ] Should the SHA3 structs be named Sha3_size? seems that this is kind of how it is referred to elsewhere

Answering out of thread here, because I think there may be more to this. I hadn't thought about _ prefix  also indicating dead-code warnings, this is of course not optimal, because all methods named so here are definitely intended to be used.
The way this was set up was to keep it consistent with the SHA2 implementation. This morning I was thinking, that this may not be the best approach after all. For SHA2, there's different logic between the variants, where the only thing changing for the variants in SHA3 is the rate.
Perhaps it would make sense to use an approach like that for BLAKE2b instead. We'd have one Sha3 struct, that takes in the rate as const-parameter, where we could make type definitions for those so users pass in Sha3::<SHA3_256>new() instead of having separate structs. Then the Digest could cover the range of possible output sizes, like with BLAKE2b. Lastly, we could provide a similar enum, as BLAKE2b, if that makes sense for faster initialization. It don't think an enum would make things simpler here though.
So deleting the individual structs and simply keeping one Sha3. Would do you think about this @vlmutolo ?

As far as I can tell, the _* are all internal. Is that correct?
If they're all internal, maybe we just move forward with this PR and discuss changing the API in a separate commit? If there are differences between the various hashing APIs, I think that's a good opportunity for improvement.

I have to take a deeper look at why there are API differences in the first place. My hope would be that there's a way to unify all three, but there's probably something I don't understand yet that makes it hard to unify all of them. But that should probably be in a separate PR anyway.

@vlmutolo I have started a discussion about the differences which hopefully clarifies them: https://github.com/orion-rs/orion/discussions/329

It seems most other libraries I've glanced at take the naming of Sha3_variant for these functions. I'll change these to this and then merge.


⚠ Mitsubishi has degraded performance

In 69814a6, Mitsubishi (https://mitsubishimotorsid-mobileapp.com/app/login) experienced degraded performance:

HTTP code: 200
Response time: 8242 ms

Resolved: Mitsubishi performance has improved in 6824b18 after 16 minutes.


VSCode’s renderer helper process using 100% of CPU

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version:1.66.2
OS Version: Darwin arm64 21.4.0

提交: dfd34e8260c270da74b5c2d86d61aee4b6d56977
日期: 2022-04-11T07:47:29.396Z
Electron: 17.2.0
Chromium: 98.0.4758.109
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0

The vscode Code Helper (Renderer) process consumes a lot of cpu and causes a very high processor temperature, closing vscode and disabling all extensions will not solve the problem.
After a clean reinstall the problem persisted. The way to reproduce is to open vscode and use the search function will appear, and vscode's own process manager does not show this abnormal process, you need to manually go to apple's process manager to end the task.

My Computer.
MacBook Air 2020 M1
16G RAM + 512G ROM
If there's any other information you need, I'd be happy to provide it.

Having the same issue on MacBook Pro 2020 M1 16GB RAM
it took 30% of my CPU for no reason while VS Code was closed.
Feel free to ask for information / logs if needed.

Can you attach a process sample from the activity monitor of the Code Helper (Renderer) process that shows high cpu usage.

您能否从Code Helper (Renderer)显示高 cpu 使用率的进程的活动监视器中附加一个进程示例。
This process is not visible in vscode's process manager. And this process will not be closed after closing vscode. There is no way to know which task is the host of this process.

您可以从Code Helper (Renderer)高 cpu 使用率进程的活动中显示附加进程的一个示例。

The problem is also not that it takes up 100% of one core usage, but because this process causes the MacBook to heat up abnormally. Normally, the MacBook's cpu temperature is around 40 degrees Celsius, and once this abnormal process is in place, the MacBook's cpu temperature will soar to 80 degrees Celsius.

I also hit this issue on my MacBook Pro (15-inch, 2018) even after I exit VS Code completely.

I have the same issue on a brand new M1 Mac with no other software installed after purchase. No source code has ever been opened. No extensions have been added. I had a similar issue on my 2012 MacBook Pro Retina, and purchased the M1 yesterday to make the issue tolerable.
Yesterday I purchased the machine, and installed VSCode. I opened it once to see that it operated, and then closed it. Not long after, I closed the machine.
This morning, I opened the machine. It got warm quickly, and these processes were hogging cores. NB, VSCode is NOT running, and no extensions have been added.
Rogue processes:

Process information:

Macbook information:

Here is the VSCode version information:
Version: 1.67.1 (Universal)
Commit: da15b6fd3ef856477bf6f4fb29ba1b7af717770d
Date: 2022-05-06T12:37:16.526Z
Electron: 17.4.1
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0
OS: Darwin arm64 21.3.0

Both my new and old MacBooks are always running hot due to these processes, which is more desirable during the winter, but it's May 🤣

Upon opening a new instance of VSCode, these processes do not appear in process explorer.

Same Issue here with M1 Pro.
Note that, in my case, I installed VS Code 1 day ago and not used it at all, I just opened the program once to verify the installation.

rigr@Riccardos-MacBook-Pro ~ % ps aux | grep 5009 rigr              5009 397.1  0.1 456362256  10848   ??  R    10:48AM 1050:07.39 /private/var/folders/rx/l1_q8xhj5fl14ktr8m0gtb_40000gn/T/AppTranslocation/6FDA13BD-289C-4EB1-AA92-6A8898E39F87/d/Visual Studio Code.app/Contents/Frameworks/Code Helper (Renderer).app/Contents/MacOS/Code Helper (Renderer) --type=renderer --user-data-dir=/Users/rigr/Library/Application Support/Code --standard-schemes=vscode-webview,vscode-file --secure-schemes=vscode-webview,vscode-file --bypasscsp-schemes --cors-schemes=vscode-webview,vscode-file --fetch-schemes=vscode-webview,vscode-file --service-worker-schemes=vscode-webview --streaming-schemes --app-path=/private/var/folders/rx/l1_q8xhj5fl14ktr8m0gtb_40000gn/T/AppTranslocation/6FDA13BD-289C-4EB1-AA92-6A8898E39F87/d/Visual Studio Code.app/Contents/Resources/app --no-sandbox --no-zygote --node-integration-in-worker --disable-color-correct-rendering --lang=en-GB --num-raster-threads=4 --enable-zero-copy --enable-gpu-memory-buffer-compositor-resources --enable-main-frame-before-activation --renderer-client-id=5 --launch-time-ticks=4271716250 --shared-files --field-trial-handle=1718379636,2816795883407190807,8334812983944564800,131072 --disable-features=PlzServiceWorker,SpareRendererForSitePerProcess --vscode-window-config=vscode:d720a6ce-fc59-491c-a368-442cff9e3aa8 --vscode-window-kind=shared-process rigr             26504   0.0  0.0 407963472    464 s001  R+    8:33AM   0:00.00 grep 5009

Update: I force killed the process Code Helper (Renderer) from activity monitor and restarted VS Code.
The process Code Helper (Renderer) now looks stable and it's not eating any CPU.
I am not sure, it could a first-run issue that gets solved automatically.

Could you please fix the bug as soon as possible, it makes the Vscode unusable.

Hi
On macOS each (re)starting of VSCode triggers this Code Helper (Renderer/GPU) to consume over 80% of CPU with no observable/obvious reason even if vscode is running in the background (literally doesn't show via WindowsServer)
Version: 1.68.1
Commit: 30d9c6cd9483b2cc586687151bcbcd635f373630
Date: 2022-06-14T12:52:13.188Z
Electron: 17.4.7
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 19.6.0
even if ~/.vscode/settings.json has
"files.exclude": {
"/.git": true,
"/.svn": true,
"/.hg": true,
"/CVS": true,
"/.DS_Store": true,
"/tmp": true,
"/node_modules": true,
"/bower_components": true,
"/dist": true
},
"files.watcherExclude": {
"/.git/objects/": true,
"/.git/subtree-cache/": true,
"/node_modules/": true,
"/tmp/": true,
"/bower_components/": true,
"/dist/**": true
}
please let me know how can i help you to collect the necessary logs to engage and resolve this annoying behavior.

Same issue in here.

I confirmed that the settings-sync extension was causing the problem, and it was resolved by turning off the extension.

High extenstionHost CPU usage when Settings Sync is enabled shanalikhan/code-settings-sync#1361

this is offtopic, actually. I have no such extension which you mentioned, and the problem still exists on
Version: 1.69.1
Commit: b06ae3b2d2dbfe28bca3134cc6be65935cdfea6a
Date: 2022-07-12T08:21:51.333Z
Electron: 18.3.5
Chromium: 100.0.4896.160
Node.js: 16.13.2
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 19.6.0
and it doesn't matter if my extensions are turned ON or OFF (i even tried to temporarily rename the extensions directory in ~/.vscode and restart vscode. it didn't help.
$ ls -1 ~/.vscode/extensions/
bierner.markdown-mermaid-1.14.2
cheshirekow.cmake-format-0.6.11
go2sh.cmake-integration-vscode-0.7.1
ibm.output-colorizer-0.1.2
llvm-vs-code-extensions.vscode-clangd-0.1.21
mhutchie.git-graph-1.30.0
ms-python.python-2022.10.1
ms-python.vscode-pylance-2022.7.30
ms-python.vscode-pylance-2022.7.40
ms-vscode-remote.remote-containers-0.241.3
ms-vscode-remote.remote-ssh-0.84.0
ms-vscode-remote.remote-ssh-edit-0.80.0
ms-vscode.cmake-tools-1.11.26
ms-vscode.cpptools-1.11.2-darwin-x64
ms-vscode.cpptools-1.11.3-darwin-x64
ms-vscode.cpptools-1.11.4-darwin-x64
nickdemayo.vscode-json-editor-0.3.0
twxs.cmake-0.0.17
Hello @deepak1556, i hope you are doing well
Could you please specify which information you need to push this current ticket forward, and how to get this info for you?

@deepak1556 I took a process sample from OS X's activity monitor when this happened right now on my M1 Macbook Pro. Is there any other information you need someone to capture the next time this happens?
Full process sample text (too large for a single GitHub comment): https://controlc.com/e3f959c0c

This problem is also happening to me I am a beginner and do not know what to do. Can someone help?

macOS Monterey v12.2.1 new installation of vscode. Opened code then closed. Code Helper caused overheating to 90 C until force quit.

@deepak1556 I took a process sample from OS X's activity monitor when this happened right now on my M1 Macbook Pro. Is there any other information you need someone to capture the next time this happens?
Full process sample text (too large for a single GitHub comment): https://controlc.com/e3f959c0c

Dear @CodingCanuck, @bpasero and all, I don't think that @deepak1556 has time for this issue according to his commitment history since April (current issue started in April as well)
Dear @bpasero could you please share how developers are assigned per issue and how progress is tracked?
Dear @deepak1556  could you please share your ETA, your assumptions about the possible reason, and missing info in this thread to resolve/push this issue?
steps to reproduce:

open few cpp/python projects/folders in code

edit some files

killall code via Terminal at one command
ps waux| grep -i "Visual Studio Code.app"|grep -v grep|awk '{print $2}'|wc -l
51
ps waux| grep -i "Visual Studio Code.app"|awk '{print $2}'|xargs -I{} kill -9 {}
ps waux| grep -i "Visual Studio Code.app"|grep -v grep|awk '{print $2}'|wc -l
0

start code
code

after 3-5 minutes the load by the renderer is decreasing

perhaps some changes could be just reverted until their performance stability aren't well designed?

macOS Monterey v12.2.1 new installation of vscode from https://code.visualstudio.com/Download. Opened code then closed. Code Helper caused overheating to 90 C until force quit. Edit: installation from Homebrew does not have overheating issue so far.

Dear @amecreate i've just tried vscode from brew.
sudo mv /Applications/Visual\ Studio\ Code.app /Applications/Visual Studio Code.app
sudo mv /usr/local/bin/code /usr/local/bin/code_ms
brew install visual-studio-code
running=brew install visual-studio-code
==> Downloading https://update.code.visualstudio.com/1.69.2/darwin/stable
Already downloaded: /Users/master/Library/Caches/Homebrew/downloads/04932cff610f2130de44f54ea565bb893de9f948a9e43e992abae1a6b3f10fe3--VSCode-darwin.zip
==> Installing Cask visual-studio-code
==> Moving App 'Visual Studio Code.app' to '/Applications/Visual Studio Code.app'
==> Linking Binary 'code' to '/usr/local/bin/code'
🍺  visual-studio-code was successfully installed!
And it didn't help:
After I started the code tens of Renderer processes continued consuming CPU for 3-5 minutes.

My workflow:

Open Terminal
In Terminal, navigate to the directory using cd command
Type code . to open vscode in the desired directory

I noticed that double clicking to open vscode will make it go haywire, at least in my case

macOS Monterey v12.2.1 new installation of vscode from https://code.visualstudio.com/Download. Opened code then closed. Code Helper caused overheating to 90 C until force quit. Edit: installation from Homebrew does not have overheating issue so far.

Dear @amecreate i've just tried vscode from brew.
sudo mv /Applications/Visual\ Studio\ Code.app /Applications/Visual\ Studio\ Code_MS.app sudo mv /usr/local/bin/code /usr/local/bin/code_ms brew install visual-studio-code running=brew install visual-studio-code ==> Downloading https://update.code.visualstudio.com/1.69.2/darwin/stable Already downloaded: /Users/master/Library/Caches/Homebrew/downloads/04932cff610f2130de44f54ea565bb893de9f948a9e43e992abae1a6b3f10fe3--VSCode-darwin.zip ==> Installing Cask visual-studio-code ==> Moving App 'Visual Studio Code.app' to '/Applications/Visual Studio Code.app' ==> Linking Binary 'code' to '/usr/local/bin/code' 🍺 visual-studio-code was successfully installed!
And it didn't help: as I already showed above tens of Code Helper Renderer processes continued consuming the CPU for 3-5 minutes just straight after I started the code

My workflow:

Open Terminal
In Terminal, navigate to the directory using cd command
Type code . to open vscode in the desired directory

I noticed that double-clicking to open vscode will make it go haywire, at least in my case

In my case, I'm starting code always from the terminal but not as code . but just code because I have at least two projects always to work with in parallel: some cpp lib and python project which depends on it. So It is not my option to start code only in one place.
@amecreate could you please share ls -1 ~/.vscode/extensions  to compare with my list?

@CodingCanuck thanks for the process sample, the sample currently lacks VSCode version information. Can you provide the output of the menu Code > About Visual Studio Code. Thanks!
@M00N-MAN can you provide the process sample of the affected ones showing high cpu usage ? In https://github.com/microsoft/vscode/issues/148226#issuecomment-1197145765 I see the main process launched by executable /Applications/Visual Studio Code.app/Contents/MacOS/Electron also showing a high CPU usage. Also include this process when collecting the sample.
Also, can users in this thread check if the issue happens with our exploration build that is built with a newer version of the runtime to rule out any runtime related issues.

@CodingCanuck thanks for the process sample, the sample currently lacks VSCode version information. Can you provide the output of the menu Code > About Visual Studio Code. Thanks!

Version: 1.69.2 (Universal)
Commit: 3b889b090b5ad5793f524b5d1d39fda662b96a2a
Date: 2022-07-18T16:12:57.074Z
Electron: 18.3.5
Chromium: 100.0.4896.160
Node.js: 16.13.2
V8: <IP_ADDRESS>-electron.0
OS: Darwin arm64 21.5.0

Also, can users in this thread check if the issue happens with our exploration build that is built with a newer version of the runtime to rule out any runtime related issues.

I don't know if this is related, but I was experiencing the same issue for months now until I just had the message "The TypeScript language service died unexpectedly 5 times in the last 5 Minutes." without even having a TypeScript project open.
So I searched and found that issue: https://github.com/microsoft/vscode/issues/88163
@mjbvz suggests to install the extension ms-vscode.vscode-typescript-next in order to let VSCode use the latest TypeScript internally (does not affect workspace settings).
And voilà after restarting VSCode the Code Helper process spiked for 5 seconds and then dropped to normal. Hopefully this lasts and might help someone else.

FWIW I am also experiencing the issue of Code Helper (Renderer) active using CPU when VS Code has been quit. Unfortunately I am having trouble reproducing it.
Version:
Version: 1.70.0 (Universal)
Commit: da76f93349a72022ca4670c1b84860304616aaa2
Date: 2022-08-04T04:38:55.829Z
Electron: 18.3.5
Chromium: 100.0.4896.160
Node.js: 16.13.2
V8: <IP_ADDRESS>-electron.0
OS: Darwin arm64 21.6.0

Extensions:
$ ls -1 ~/.vscode/extensions/
rust-lang.rust-analyzer-0.3.1148-darwin-arm64

I confirmed that the settings-sync extension was causing the problem, and it was resolved by turning off the extension.

High extenstionHost CPU usage when Settings Sync is enabled shanalikhan/code-settings-sync#1361

same problem here.
In my case, disabled code-settings-sync extension solved the problem.

I confirmed that the settings-sync extension was causing the problem, and it was resolved by turning off the extension.

High extenstionHost CPU usage when Settings Sync is enabled shanalikhan/code-settings-sync#1361

same problem here. In my case, the disabled code-settings-sync extension solved the problem.

fortunately or unfortunately it is off by default on my side. so it doesn't seem to be the root cause or trigger of it

I haven't seen anyone post about this elsewhere, so here's a block of text about what happened to me and what fixed it. I've seen the renderer process eat up a pretty constantly high CPU, getting worse the longer VSCode is open until it eventually freezes the entire program indefinitely (let it sit 30+ minutes).
For me, VSCode would only start getting worse while the "Problems" panel was open. It would get bad enough that trying to type a word in the editor would freeze for a second or two after every letter. Switching to another panel like "Terminal" and back would entirely freeze VSCode for multiple seconds, but even just sitting there, not touching anything with the window hidden, would cause high CPU when "Problems" was open.
I'm running the latest insiders build on a multi-thousand file TypeScript project (plus dependencies) with a tsc --watch running from a VSCode task with a problem matcher set up. I profiled extensions, tsserver, etc so many times and removed some things causing slowdowns. This improved editor performance, sometimes notably, but I continued my descent into the madness of a laggy editor.
I profiled the window from "JavaScript profiler" in the VSCode devtools today and triggered a handful of lag spikes. I saw 1 specific function (in workbench.desktop.main.js, named _) that seemed to be taking up to 5 seconds to run in the flame graph. In minified form, I could only tell it was something regex related. Hit it with a breakpoint and figured out it was the filter bar in the "Problems" panel. Removing the filter text seems to have fixed my issues. I don't think the filter I had was crazy, just filtering out a few files, but seems it checks as often as the problems panel updates, which can be every keystroke. Not sure if it's been getting slower in VSCode's side, but we've added a bunch of new ESLint rules and other things that show up in the "Problems" panel to our project recently. For the record, the filter text looked like this: !**/FileName1.scss,!**/FileName2.js,!**/angular.js,!**/FileName3.tsx[],!**/?/settings.json,!**/build/**,!**/?/workspaceSettings.json,!**/FileName5.jsp
It's probably not the exact same issue as OP, but hopefully this helps someone!

Same Issue here with my MacBook Air M2 :-/

Same problem for months...
It doesn't ALWAYS drain the battery but OFTEN.
Sometimes I restarts VSCode the problem will be resolved but after a few hours or another day, the problem could happened again.

Version: 1.70.2 (Universal)
Commit: e4503b30fc78200f846c62cf8091b76ff5547662
Date: 2022-08-16T05:36:37.829Z
Electron: 18.3.5
Chromium: 100.0.4896.160
Node.js: 16.13.2
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 21.6.0

I'm having a slightly different but I suspect related problem. Fully loaded MacBook Pro 16" M1 Max.   I'm coding away and every few seconds VSCode stops responding to clicks and keystrokes (but no beachball).  Then a few seconds later all clicks and keystrokes I did while it was unresponsive then happen in order.
Running Activity Monitor next to it so I can see at a glance what might be happening, every time this happens I see Code Helper (Renderer) process eating 96+% of CPU.  Then a few seconds later, that process in Activity Monitor drops to near zero, at the same moment VSCode becomes responsive again.
Unlike others above, it's happening while I'm coding, not with VSCode quit, and it's only happening momentarily, although I think more frequently and for a little longer each time, I think.
If this should be a separate issue, let me know and I'll post it as such.

I also was having this issue, Removing the app from the applications folder did not help. I ran -rm commands on folders I found it to install from google searches, that improved the heat a lot but my laptop was still hotter and lasting 6h instead of the usual 12-15h (browsing) so I finally found that force quitting Code Helper from Visual studio code in activity monitor helped me fix the issue, I wonder if it'll pop back

I don't know if this is related, but I was experiencing the same issue for months now until I just had the message "The TypeScript language service died unexpectedly 5 times in the last 5 Minutes." without even having a TypeScript project open.
So I searched and found that issue: #88163
@mjbvz suggests to install the extension ms-vscode.vscode-typescript-next in order to let VSCode use the latest TypeScript internally (does not affect workspace settings).
And voilà after restarting VSCode the Code Helper process spiked for 5 seconds and then dropped to normal. Hopefully this lasts and might help someone else.

This helps me!!!

@CodingCanuck thanks for the process sample, the sample currently lacks VSCode version information. Can you provide the output of the menu Code > About Visual Studio Code. Thanks!
@M00N-MAN can you provide the process sample of the affected ones showing high cpu usage ? In #148226 (comment) I see the main process launched by executable /Applications/Visual Studio Code.app/Contents/MacOS/Electron also showing a high CPU usage. Also include this process when collecting the sample.
Also, can users in this thread check if the issue happens with our exploration build that is built with a newer version of the runtime to rule out any runtime related issues.
Hi @deepak1556
Please let me know if this is enough or not
Sample of Code Helper2.txt
Spindump2.txt
Spindump.txt
Sample of Code Helper.txt

I haven't seen anyone post about this elsewhere, so here's a block of text about what happened to me and what fixed it. I've seen the renderer process eat up a pretty constantly high CPU, getting worse the longer VSCode is open until it eventually freezes the entire program indefinitely (let it sit 30+ minutes).
For me, VSCode would only start getting worse while the "Problems" panel was open. It would get bad enough that trying to type a word in the editor would freeze for a second or two after every letter. Switching to another panel like "Terminal" and back would entirely freeze VSCode for multiple seconds, but even just sitting there, not touching anything with the window hidden, would cause high CPU when "Problems" was open.
I'm running the latest insiders build on a multi-thousand file TypeScript project (plus dependencies) with a tsc --watch running from a VSCode task with a problem matcher set up. I profiled extensions, tsserver, etc so many times and removed some things causing slowdowns. This improved editor performance, sometimes notably, but I continued my descent into the madness of a laggy editor.
I profiled the window from "JavaScript profiler" in the VSCode devtools today and triggered a handful of lag spikes. I saw 1 specific function (in workbench.desktop.main.js, named _) that seemed to be taking up to 5 seconds to run in the flame graph. In minified form, I could only tell it was something regex related. Hit it with a breakpoint and figured out it was the filter bar in the "Problems" panel. Removing the filter text seems to have fixed my issues. I don't think the filter I had was crazy, just filtering out a few files, but seems it checks as often as the problems panel updates, which can be every keystroke. Not sure if it's been getting slower in VSCode's side, but we've added a bunch of new ESLint rules and other things that show up in the "Problems" panel to our project recently. For the record, the filter text looked like this: !**/FileName1.scss,!**/FileName2.js,!**/angular.js,!**/FileName3.tsx[],!**/?/settings.json,!**/build/**,!**/?/workspaceSettings.json,!**/FileName5.jsp
It's probably not the exact same issue as OP, but hopefully this helps someone!
Hi @zachhardesty7

your story looks pretty good, but I can't confirm it is close to the root cause because in my case I have only:

a few opened vscode windows with folders or files (some are in not saved state),
only c++ or python
"problems" windows have something from clangd or pylance
all vscode windows with all Problems nor other tabs/windows have empty filters
I don't have any ts code/project/files. :(

I don't know if this is related, but I was experiencing the same issue for months now until I just had the message "The TypeScript language service died unexpectedly 5 times in the last 5 Minutes." without even having a TypeScript project open.
So I searched and found that issue: #88163
@mjbvz suggests to install the extension ms-vscode.vscode-typescript-next in order to let VSCode use the latest TypeScript internally (does not affect workspace settings).
And voilà after restarting VSCode the Code Helper process spiked for 5 seconds and then dropped to normal. Hopefully this lasts and might help someone else.

This helps me!!! (M1 pro macOS Monterey v12.4) In my case, disabled ms-vscode.vscode-typescript-next extension solved the problem.

Hi @JasonJayKim
so obviously this is not vscode issue and offtopic in this thread

Closed vscode...
Code helper still in progress

Spindump4.txt
Spindump3.txt
Sample of Code Helper4.txt
Sample of Code Helper3.txt
it has something about pylance in it's command line, but this is different from what I had recently. turning off pylance and restarting to see the result

I too am running into an issue where I am running into high CPU, though the process explorer seems to have a granularity issue, meaning it is hard to identify the real culprit:

Here we see "shared-process" at 66% CPU, yet nothing below show any CPU usage. Using top -u on the CLI confirms the 66% CPU usage of "Code Helper".
Copying the output of the process explorer, to get processes:
shared-process
  ptyHost
  fileWatcher
window (OpeningsService.ts — scarlet-staff-server)

extensionHost

/Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper --ms-enable-electron-run-as-node --max-old-space-size=3072 /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/node_modules/typescript/lib/tsserver.js --serverMode partialSemantic --useInferredProjectPerProjectRoot --disableAutomaticTypingAcquisition --cancellationPipeName /var/folders/sj/j454ybpx3tbbngp006kmm5f00000gn/T/vscode-typescript501/577e1bf040b11523300c/tscancellation-1a8a4434617b7e04b648.tmp* --globalPlugins @vsintellicode/typescript-intellicode-plugin,ms-vsintellicode-typescript --pluginProbeLocations /Users/ajmas/.vscode/extensions/visualstudioexptteam.vscodeintellicode-1.2.28,/Users/ajmas/.vscode/extensions/visualstudioexptteam.vscodeintellicode-1.2.28 --locale en --noGetErrOnBackgroundUpdate --validateDefaultNpmLocation --useNodeIpc
/Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper --ms-enable-electron-run-as-node --max-old-space-size=3072 /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/node_modules/typescript/lib/tsserver.js --useInferredProjectPerProjectRoot --enableTelemetry --cancellationPipeName /var/folders/sj/j454ybpx3tbbngp006kmm5f00000gn/T/vscode-typescript501/577e1bf040b11523300c/tscancellation-463b1cb45c1a5ecc682b.tmp* --globalPlugins @vsintellicode/typescript-intellicode-plugin,ms-vsintellicode-typescript --pluginProbeLocations /Users/ajmas/.vscode/extensions/visualstudioexptteam.vscodeintellicode-1.2.28,/Users/ajmas/.vscode/extensions/visualstudioexptteam.vscodeintellicode-1.2.28 --locale en --noGetErrOnBackgroundUpdate --validateDefaultNpmLocation --useNodeIpc
  /Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper --ms-enable-electron-run-as-node /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/node_modules/typescript/lib/typingsInstaller.js --globalTypingsCacheLocation /Users/ajmas/Library/Caches/typescript/4.8 --enableTelemetry --typesMapLocation /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/node_modules/typescript/lib/typesMap.json --validateDefaultNpmLocation
/Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper --ms-enable-electron-run-as-node /Users/ajmas/.vscode/extensions/shinnn.stylelint-0.51.0/server.js --stdio --clientProcessId=59829
/Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper --ms-enable-electron-run-as-node /Users/ajmas/.vscode/extensions/formulahendry.auto-rename-tag-0.1.10/packages/server/dist/serverMain.js --node-ipc --clientProcessId=59829
/Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper --ms-enable-electron-run-as-node /Users/ajmas/.vscode/extensions/kisstkondoros.vscode-gutter-preview-0.30.0/dist/server.js --node-ipc --clientProcessId=59829
/Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper --ms-enable-electron-run-as-node /Users/ajmas/.vscode/extensions/visualstudioexptteam.intellicode-api-usage-examples-0.2.4/dist/server/server.js --node-ipc --clientProcessId=59829
/Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper --ms-enable-electron-run-as-node /Users/ajmas/.vscode/extensions/dbaeumer.vscode-eslint-2.2.6/server/out/eslintServer.js --node-ipc --clientProcessId=59829
/Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper --ms-enable-electron-run-as-node /Users/ajmas/.vscode/extensions/vue.volar-0.40.13-darwin-x64/server --node-ipc --clientProcessId=59829
/Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper --ms-enable-electron-run-as-node /Users/ajmas/.vscode/extensions/vue.volar-0.40.13-darwin-x64/server --node-ipc --clientProcessId=59829
/Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper --ms-enable-electron-run-as-node /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/json-language-features/server/dist/node/jsonServerMain --node-ipc --clientProcessId=59829

Environment:

Intel based MacBook Pro (16-inch, 2019)
VS Code 1.71.2
macOS 12.15.1

Hi @deepak1556,
Could you please share which tool you use for analysis of performance issues with the given spindump/samples of vscode in this thread? (maybe some link to the guide about it)
When we can receive any info/update/workaround for the current issue from your side?
How else can we help you in resolving this issue?
with best regards

I just didn't get it, can you reproduce it or not

The issue also occurs with

VS Code Version:

code --version
1.72.2
d045a5eda657f4d7b676dedbfa7aab8207f8a075
x64
electron 19.0.17

OS Version:

sw_vers
ProductName:	macOS
ProductVersion:	12.6.1
BuildVersion:	21G217

Steps to Reproduce:
ps aux <PID>
<USER>  <PID> 100,0  2,8 71937192 471344   ??
Once I open the git-graph plugin, vscode will freeze.

mhutchie/vscode-git-graph#712

Same issue.
Once I open the git-graph plugin, vscode will freeze.

Hi, I don't confirm it.
Rather I say the opposite:
mhutchie.git-graph isn't impacting that topic at all from my side.
Turning off the git graph extension and restarting the vscode: the same problem with CPU load in the beginning
Turning on the git graph extension doesn't make any additional load, nor before nor after the restart of the vscode.
Thanks for the idea, nice try)

The issue also occurs with

VS Code Version:

code --version
1.72.2
d045a5eda657f4d7b676dedbfa7aab8207f8a075
x64
electron 19.0.17

OS Version:

sw_vers
ProductName:	macOS
ProductVersion:	12.6.1
BuildVersion:	21G217

Steps to Reproduce:
ps aux <PID>
<USER>  <PID> 100,0  2,8 71937192 471344   ??  R    10:51am   9:25.75 /Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper --ms-enable-electron-run-as-node /Users/<USER>/.vscode/extensions/ms-python.vscode-pylance-2022.10.40/dist/server.bundle.js --canc

Probably Related:

Issue: VSCode’s renderer helper process using 100% of CPU #148226
Issue: Code Helper uses 180% CPU #161494
Issue: VSCode becomes laggy after using it for some time (macOS Ventura) #165016
Issue: Code Helper process take 100% of my CPU #160098
Issue: Bug: Battery drain even when app off! #147707
Plugin Pylance:: https://github.com/microsoft/pylance-release

Already in settings:
"files.exclude": {
    "**/__pycache__": true,
    "**/.pytest_cache": true,
    "**/.git": true,
    "**/.DS_Store": true,
    "**/tmp": true
},

"files.watcherExclude": {
    "**/.git/objects/**": true,
    "**/.git/subtree-cache/**": true,
    "**/node_modules/**": true,
    "**/tmp/**": true,
},

Hi, I've tried to turn off any pylance-related extensions. A clean start with turned-off extension (pylance) doesn't make any difference to the renderer: its instances still are consuming a lot of CPU during the first 5-10 minutes.
Thanks

Hi @hediet, Could you please share your opinion about why this topic doesn't have any valuable updates for so long time?

Hi @deepak1556, Could you please share your opinion about why this topic doesn't have any valuable updates for so long time?
How could attendees of this topic help you to push it forward?

1

I think the record is mine.

@aka-vm Thanks for suggestion. I didn't see improvement when I turn off extension. (Since as I mentioned the only extension I use is prettier)

@ozgurrgul
hmmm! Try using 1. by combing 2.
Today I was having this problem, it was fixed after I did that.
I hope you find a solution soon. Else switching to an older version of vscode and other things could also work.

mhutchie/vscode-git-graph#712
gitkraken/vscode-gitlens#2389

Same issue.
Once I open the git-graph plugin, vscode will freeze.

same here

Same problem also. Very sad that I don't see any solution yet

I am pretty disappointed that this CPU bug has gone unfixed, and meanwhile Atom has sunsetted. I always preferred Atom as my MacOS source editor, not because it was better than VS Code, but because it didn't spike my CPU to 100% every time I opened it.

same problem :(
killed process that was ~100% cpu, and another started in few seconds with already ~220% cpu

I also have this issue, using 440%+ of my cpu

I also have this issue, using 440%+ of my cpu

I am no a dev on the project, but providing more info, such as OS, VSCode version and any extensions could be useful. By itself the comment doesn't add much for the devs to base their investigation on, if they decide to do so.

I also have this process
/Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper (Plugin).app/Contents/MacOS/Code Helper (Plugin) --type=utility --utility-sub-type=node.mojom.NodeService --lang=en-US --service-sandbox-type=none --inspect-port=0 --user-data-dir=/Users/lucasarruda/Library/Application Support/Code --standard-schemes=vscode-webview,vscode-file --secure-schemes=vscode-webview,vscode-file --bypasscsp-schemes --cors-schemes=vscode-webview,vscode-file --fetch-schemes=vscode-webview,vscode-file --service-worker-schemes=vscode-webview --streaming-schemes --shared-files --field-trial-handle=1718379636,r,11794770712285918391,468314003805687192,131072 --disable-features=CalculateNativeWinOcclusion,SpareRendererForSitePerProcess
And it takes like 50~80% CPU basically forever.
I wonder if that's like VSCode itself.

Same issue with for m2 mac pro it takes 70-80% CPU ,
/Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper (Plugin).app/Contents/MacOS/Code Helper (Plugin)

I found out that it looks like that most of this seems to come from CoPilot? Or maybe the main process that supports extensions, and upon killing the process, Github CoPilot is one of the processes that gets killed (it goes away and the comes back in the lower VSCode bar).
So, maybe it's all due to CoPilot processing our codebases?
Do you have it also, @sangit0 ?

I've seen some supporting evidence of this issue occurring before (though they state, in some tickets, it's been fixed)
https://github.com/orgs/community/discussions/8861
https://github.com/community/community/discussions/7889
https://github.com/microsoft/vscode/issues/147188
I don't want to disable it, though, because I use it a lot. It just can be a bummer if I keep the editor open when idle and it keeps with that 60% constant CPU usage.

Known causes so far on macOS Ventura (M1 or M2)

Setting Sync extension: https://marketplace.visualstudio.com/items?itemName=Shan.code-settings-sync

Disable it. See #147707

CMake Tools: https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools

Disable it. See #145387. Reported at upstream microsoft/vscode-cmake-tools/issues/2967

ESLint extension: https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint

Disable it. Go to #171691

(❗THIS THREAD❗) Renderer process hits 100% of CPU

One of causes is Git Lens, Git Graph, and other extensions which heavily uses canvas elements on WebView. Disable them.
(❗new❗) Minimap might be the cause. Disable Minimap. See https://github.com/microsoft/vscode/issues/169775#issuecomment-1422919512

Pro tips for trouble shooting:

Use the built-in Process Explorer instead of Activity Monitor by Apple. Process names are more helpful.
If extension-host process hits 100% of CPU, one of extensions is the cause. Find it with bisect.
If main, shared-process, or window (...) process hits 100% of CPU, it might be a issue on VS Code's side. Open a new issue. VS Code members will determine whether it is a duplicate.

Same issue here.
This is the process:
ps aux | grep 35428
username   35428 200.0  0.8 72010812 137084   ??  R     3:49PM  36:56.23 /Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper --ms-enable-electron-run-as-node /Users/username/.vscode/extensions/ms-python.vscode-pylance-2023.2.20/dist/server.bundle.js --cancellationReceive=file:787703fe46c8fcfe746a022668193a1bdb8ca7d483 --node-ipc --clientProcessId=35305

@sergei3000
No, it isn't the same issue. You should report to https://github.com/microsoft/pylance-release/issues

There are clearly many different ways VS Code could get into a situation where it runs high on CPU. Is there a way to find which Extension is using the CPU? Turning them on and off is not an easy way to find the issue if it's intermittent, it would be much better to be able to print which extensions are taking what part of the Code Helper process load.

I found out that it looks like that most of this seems to come from CoPilot? Or maybe the main process that supports extensions, and upon killing the process, Github CoPilot is one of the processes that gets killed (it goes away and the comes back in the lower VSCode bar).
So, maybe it's all due to CoPilot processing our codebases?
Do you have it also, @sangit0 ?

For me it was the code spell checker and setting sync plugin, both were taking so much CPU. I disabled them and got significant improvement over the CPU usages.

@sangit0 @LucasArruda
Issues you are seeing are not related to this thread. Please report to the repositories of the extensions causing your issues.

This is still happening as of today.. VSCode was closed, and CodeHelper was using 100% of my CPU. What's going on here?

New M2 airbook, clean vscode install w/ no extensions. Same issue after install, opened to see if it was working but remained hot after. Used to edit two text files. Saw it was using around 75% cpu consistently.

I just quit vscode on my mac and am still having two Code Helper processes each of which is running at 200% CPU

This is ridiculous. vscode should not work like this even if some extension is failing. When I quit vscode all of its processes should stop, obviously.

@sergei3000 It could happen. For example, see #175713.
Anyway, you had better open a new issue. It is not sure if your issue is the same one as this thread.

Same here.

@jung-han
Your issue is not different one. It is about Code Helper (Plugin). This thread is about Code Helper (Renderer).
You had better open a new issue.

I don't know if this is related, but I had some issues with VSCode using up high loads. Then, it eventually occurred to me that I was working off an nfs share drive (network drive). Moved my work over to a local drive and haven't encountered significant high load issues since..
As a side note, it might be interesting to see how much VSCode performance is impacted when working off an nfs or samba network drive.. There should be ways to maintain good performance even in these cases..

Disabling setting sync worked for me

@ginobean
Your issue seems different. You had better open a new issue, which would help the improvement of VS Code.

it eventually occurred to me that I was working off an nfs share drive (network drive).

That's a good point. I think I mentioned the problem I encountered because it's possible that some other people, who were having
load/performance issues re: VSCode, might be encountering the same issue. Personally, I had forgotten that I was working off an nfs share drive and was a bit mystified as to why some operations seemed to take so long, with high loads. It was only until later, that I realized it was likely due to working off an nfs share..

Now, VS Code Insiders 1.78 has updated Electron to v22.4.3. It would be worth checking to see if this update fixes the issue.

https://code.visualstudio.com/insiders/
#177600

Version: 1.78.0-insider solved this problem.  (Electron: 22.4.3)
Looking forward to the release of the stable version.

Originally posted by @jqtmviyu in https://github.com/microsoft/vscode/issues/178934#issuecomment-1500138160

Happened to me today, clean install on M1 Pro macOS: 13.3.1 (22E261). Opened one Python file, installed Python extension. an hour later I realized my battery is dying fast, so I quit VSCode, but the battery kept draining fast and I found 2 Code Helper (renderer) processes eating 250% CPU.

Hi @deepak1556 @LucasArruda
Do you have any plans/ideas about current report/thread?

Happened to me today, clean install on M1 Pro macOS: 13.3.1 (22E261). Opened one Python file, installed Python extension. an hour later I realized my battery is dying fast, so I quit VSCode, but the battery kept draining fast and I found 2 Code Helper (renderer) processes eating 250% CPU.

Hi
could you please share your list of extensions active for that time/such case?
how about to check
for mem cosumers
watch -n1 -d "ps -wweo pid,pcpu,pmem,rss,vsz,args -m |grep -v 'watch'"
or for cpu consumers
watch -n1 -d "ps -wweo pid,pcpu,pmem,rss,vsz,args -r |grep -v 'watch'"

Now, VS Code Insiders 1.78 has updated Electron to v22.4.3. It would be worth checking to see if this update fixes the issue.

https://code.visualstudio.com/insiders/
chore: update to Electron 22 #177600

currently i don't see this issue
on macos 13.3 mac m1 pro max
with
Version: 1.77.3 (Universal)
Commit: 704ed70d4fd1c6bd6342c436f1ede30d1cff4710
Date: 2023-04-12T09:19:37.325Z
Electron: 19.1.11
Chromium: 102.0.5005.196
Node.js: 16.14.2
V8: <IP_ADDRESS>-electron.0
OS: Darwin arm64 22.4.0
Sandboxed: No
but latest version (different arch?) has same topic issue as i've shown along time ago above

I got a new MacBook Pro and when I installed vscode and started doing dev work I was losing battery fast and my laptop was warm. I was kinda confused because I thought this laptop was supposed to be efficient. Took a look in my task manager today and vscode is there hogging 600% cpu even when it was closed. Damn.

I'm also getting this on a MacBook Pro 2017 running MacOS 13.4 (22F66) and VSCode 1.78.2 (Universal) with a single extension (yzhang.markdown-all-in-one). This issue happens even when VSCode is not open.

@M00N-MAN my problem, apparently, went away with recent updates.
I had one last remaining process that was taking too much CPU and I was able to determine it was not vscode, not github copilot, but a ruby server (solargraph).
Upon the last vscode updates and by removing solargraph, I now have sane usage and a cool M1 (which was getting hot – which is not so easy to pull on an M1/M1 Pro).

Any updates on this? The only pattern I can see from the people posting and my own issue is that We are (mostly) using the same older version of MacOs namely some version of Monterey

Here's a screenshot of the process what when it's running/spinning out of control, the TS intellisense stops working or becomes incredibly slow. Could this be related to some tsconfig issue? I'm in an NX monorepo with not that many apps/libraries, but this makes VS code unusable... :(

@andefred
Your issue is different from this thread. Your issue is about Code Helper (Plugin). This thread is about Code Helper (Renderer).
You had better open a new issue.
See also https://github.com/microsoft/vscode/issues/148226#issuecomment-1426483095

@M00N-MAN my problem, apparently, went away with recent updates.
I had one last remaining process that was taking too much CPU and I was able to determine it was not vscode, not github copilot, but a ruby server (solargraph).
Upon the last vscode updates and by removing solargraph, I now have sane usage and a cool M1 (which was getting hot – which is not so easy to pull on an M1/M1 Pro).

happy for you, but i didn't and don't have/use any solargraph or ruby.
cheers

@sergei3000
No, it isn't the same issue. You should report to https://github.com/microsoft/pylance-release/issues

@tamuratak i dunno why you/github decided that i can't mention you:)
but Code Render (originally in current case https://github.com/microsoft/vscode/issues/148226) has 100% issue no matter if i have pylance or not. i've checked that. So in my subjective point of view you can't just subdivide someones report only because it contains the pylance because this pylance extension can't be executed separately/outside of Code Helper which is part of complain/report in current case.
Could you please at least how to start vscode with full logging to get more info about it? Thanks for 0 answers btw for such long period after all info had been shared as you asked above

Having the same issue on my M2 Macbook Air with macOS Ventura 13.3, and the vscode version is 1.80.1, stable build.
Reboot my computer solve the problem, but it's kind of disturbing.

I have the same Problem.
Even debugging the Vscode with no extension installed, the high power consumption persists.
We need a solution for that.
This will be a big blow from Microsoft against AppleX_X?

Not sure if this is the exact same but symptoms seems similar.
I am on a MacBook Pro (Intel).  Our project has a directory named output that is added to the .gitignore.  We run scripts inside the project directory that generate thousands of files into the output directory.  For the most part, everything seems to be just fine.
... UNTIL ... we run rm -rf output/* in a terminal (in VSCode or outside of VSCode).  Then VSCode seems to go to 100%, top shows that it is CodeHelper running hard, and VSCode becomes quite unresponsive (not fully unresponsive...but many things don't seem to respond to keystrokes or mouse clicks properly).  Also, the Source Control tab shows a clock icon that does not go away.
Moving that output directory to be outside of the VSCode project seems to have reduced (eliminated??) the problem.

For me, the issue turned out to be files that needed to be excluded.  I only recently switched to VScode and it was searching my SQL files.
Searching "asdf" ended up crashing VS code once 32 gigs of RAM became occupied by the search editor.

I launched VS code from the terminal and disabled the sync feature:
code --disable-extensions --verbose --sync off

Then I opened the command palette (command shift p on mac), typed "Show synced data" and restored a UI state from before I had the issue. After this, I relaunched VS code normally (not from Terminal) and the issue was gone, no more renderer process eating up my CPU and making VS Code totally unusable.
I hope this helps someone else.

So What's Solution? do you install a old version to confirm

I confirm issue is still present in latest version of VS Code: Version: 1.82.2 (Universal) Commit: abd2f3d Date: 2023-09-14T05:59:47.790Z Electron: 25.8.1 ElectronBuildId: 23779380 Chromium: 114.0.5735.289 Node.js: 18.15.0 V8: <IP_ADDRESS>-electron.0 OS: Darwin x64 22.6.0

this ext install ms-vscode.vscode-typescript-next fixed it for me.

I have the same issue with Code Helper. It used a lot of CPU on Mac M1. It's better after I kill it.

Fresh VSCode install, only extension is GitHub Pull Requests.  Upon starting VSC, the Code Helper (Renderer) pegs at exactly 283% and stays there until the Mac is rebooted.

+1, same problem here — makes using the Application rather impossible for me :/

+1 on an M3 Pro machine.

+1 on a Mac M1

I had high CPU usage, which my case was caused by the extension Pylance. Downgrading did not fix it but disabling it did. See https://github.com/microsoft/pylance-release/issues/4885 and https://github.com/microsoft/pylance-release/issues/201.

Any updates on this issue?

I'm having the same issues on a Macbook Pro 2023 M2 24 GB ram, running Sonoma 14.2.1 (23C71).
VSCode singlehandedly maxes out at least 2 CPUs and brings the laptop to unusable temperature.
I'm only running Rust Analyzer and a custom theme.

Likewise, just started today. No change in settings or extensions.

This is still happening to me runaway code helper processes that keep respawning after being killed

Here I am about to take my mac mini m1 into Apple and this thread appears.
Running MacOS 14.4.1 and just started happening to me 4-5 days ago.

I’d suspect in many cases it is an extension acting up, but unfortunately given the current task manager UI, it is hard knowing which one.
I’m going to check the task manager to see if that is still the case (not at my computer right now).

I’d suspect in many cases it is an extension acting up, but unfortunately given the current task manager UI, it is hard knowing which one.
I’m going to check the task manager to see if that is still the case (not at my computer right now).

I don't boot to MacOS much, but mine only had github pull requests installed, and it wasn't active.

I’d suspect in many cases it is an extension acting up, but unfortunately given the current task manager UI, it is hard knowing which one.
I’m going to check the task manager to see if that is still the case (not at my computer right now).

This was a fresh install of MacOS/VSCode. Nothing was changed, no extensions, nothing.
What concerned me the most was the machine potentially running for 8hrs while I slept with this process at 200% cpu usage/baking my mac.

for me this problem always happened after asyncio run with some urls to visit with httpx.client.... it's time to change this editor. microsoft as always....

I'm having the same issues on a Macbook Pro 2023 M2 w/ 24 GB RAM, running Sonoma 14.2.1 (23C71). VSCode singlehandedly maxes out at least 3 cores and brings the laptop to unusable temperature. I'm only running Rust Analyzer and a custom theme, no python extensions or settings sync.

After a couple of months, I found two solutions for my case:

https://www.gnu.org/software/emacs/
https://zed.dev/

What's happening to VS Code lately? It seems to become more and more useless with every update. Unfortunately, updates now occur almost daily, making me wonder if the developers know what they're doing. It now spawns ten different Clang processes, each consuming 100% CPU. This seems to be related to Intellisense, as the entire editor freezes whenever I start typing.  Invested so much time in VSCode now have to seek another editor.

What's happening to VS Code lately? [...] updates now occur almost daily [...]

How did you come to that conclusion?  Are you on some experimental install or something because I am seeing updates about once per month as documented here

I had high CPU usage, which my case was caused by the extension Pylance. Downgrading did not fix it but disabling it did. See microsoft/pylance-release#4885 and microsoft/pylance-release#201.

could you please read the content of this thread?
there are few reports that pylance wasn't installed.
Thank you in advance :)

v1.91.1 on Kubuntu 24.04 -- still happening. Right after starting one process just fries a CPU core, sometimes for a few minutes, sometimes for hours, sometimes for days.

Update: I force killed the process Code Helper (Renderer) from activity monitor and restarted VS Code. The process Code Helper (Renderer) now looks stable and it's not eating any CPU.
I am not sure, it could be a first-run issue that gets solved automatically.

in this case, m3 pro, macOS Sonoma 14.5, with no sync-plugin. it was solved following this (by now)!

in this case, m3 pro, macOS Sonoma 14.5, with no sync-plugin. it was solved following this (by now)!

This doesn't solve the problem....it just makes it go away for a while.

So, No final solution yet?

in this case, m3 pro, macOS Sonoma 14.5, with no sync-plugin. it was solved following this (by now)!

This doesn't solve the problem....it just makes it go away for a while.

It just happened to me. I'm using Linux Pop!_OS. I disabled the built-in settings sync, and the problem stopped.
Version: 1.92.0
Commit: b1c0a14de1414fcdaa400695b4db1c0799bc3124
Date: 2024-07-31T23:26:45.634Z
Electron: 30.1.2
ElectronBuildId: 9870757
Chromium: 124.0.6367.243
Node.js: 20.14.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 6.9.3-76060903-generic

Happened to me, fresh install, no extensions, no projects open. Just the VS Code main program with Welcome tab.
macOS Sequoia 15.0.1 on M3 MacBook Pro
VS Code 1.94.2 (Universal)
After quitting VS Code itself to resolve the issue, the following processes still stuck around:
Code Helper (Renderer) 292.1% CPU, CPU Time 34:17:35.98
Code Helper (Plugin) 197.0% CPU, CPU Time 23:02:03.48
Are there any guides on how to get started with troubleshooting/debugging this issue?

I just started having the same issues, similar setup

Same issue with my Macbook Air M1, 2020 Sequoia: VScode becomes unacceptable due to this. The MB get too hot.


Refactor coordinates and add support for 4-Vectors

Fixes #517

Things to do:

[x] Write tests for refactor
[x] Update examples, metric, Example Notebooks (wherever coordinates were removed in #512).
[ ] Update CHANGELOG

Mini-Changelog:

einsteinpy.coordinates:

Renamed coordinates.velocity to coordinates.differential
Added 4-Vector support to core and differential (formerly, velocity)
Added support for calculation of time-like component of 4-Velocity

einsteinpy.metric:

Added support for einsteinpy.coordinates.differential
Added support for astropy.units
Refactored metric.Schwarzschild and metric.KerrNewman
Partially fixed #523:

Update 1: Schwarzschild is error-free now. Metric definitions in Kerr and KerrNewman are error-free too. Remaining methods (_christoffels, _dg_dx, f_vec) are yet to be altered.
Update 2: Schwarzschild and Kerr are error-free now.  KerrNewman is yet to be altered.
Update 3: KerrNewman's f_vec needs to be cross-checked. Remaining methods have been corrected.

einsteinpy.geodesic:

Added support for einsteinpy.coordinates.differential
Added support for astropy.units
Moved old code to Geodesic class, while Time-like geodesic calculation is now through TimelikeGeodesic class (which derives from Geodesic)
Added state class variable, that stores the initial state of the particle.

einsteinpy.units:

Added a primitive() function, that helps in obtaining float values out of astropy.units.quantity.Quantity objects.
Removed astro_dist & astro_sec (These are just scaling factors and these are not being used anywhere at the moment - Removed to get better codecov diff score)

einsteinpy.bodies:

Refactored bodies to remove a (Fixes #517) and some minor changes.

Fixed #517, #524, partially fixed #523

Added new tests and refactored old tests, wherever applicable

Refactored example notebooks

Hello @JeS24! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file src/einsteinpy/bodies.py:

Line 73:121: E501 line too long (174 > 120 characters)
Line 76:121: E501 line too long (174 > 120 characters)

In the file tests/test_bodies.py:

Line 88:121: E501 line too long (158 > 120 characters)
Line 96:121: E501 line too long (158 > 120 characters)

@shreyasbapat Is CodeClimate supposed to check tests/?

MyPy needs to be less aggressive with type checking.

The tests would fail most probably. @shreyasbapat There were the issues, I was talking about. However, I am attempting a minor fix/refactor, which may fix these, without removing astropy.units.

@shreyasbapat PR is ready for review now.

I will review in a while. I am very busy for a couple of days. You can start working on other things for now.

@shreyasbapat Yeah, I am currently working on Null Geodesics, working out the equations and all.


fix: add closeByOutsideClick, not handle button click if action.group…

add closeByOutsideClick
not handle button click if action.groups not specified in framework7-vue

Looks good, but why there is a if (actions.groups) { condition added?

In framework7-vue, not given the parameter groups to actions component.

<f7-actions ref="actionsOneGroup">
      <f7-actions-group>
        <f7-actions-label>Do something</f7-actions-label>
        <f7-actions-button bold>Button 1</f7-actions-button>
        <f7-actions-button>Button 2</f7-actions-button>
        <f7-actions-button color="red">Cancel</f7-actions-button>
      </f7-actions-group>
    </f7-actions>

While, in framework7, actions-class.js handle events of buttons.

actions.$el.find('.actions-button').each((groupIndex, buttonEl) => {
    **$(buttonEl).on('click', buttonOnClick);**
});

Then,the variable 'groups' in buttonOnClick will be undefined.

function buttonOnClick(e) {
      const buttonEl = this;
      let buttonIndex;
      let groupIndex;
      if ($(buttonEl).hasClass('item-link')) {
        buttonIndex = $(buttonEl).parents('li').index();
        groupIndex = $(buttonEl).parents('.list').index();
      } else {
        buttonIndex = $(buttonEl).index();
        groupIndex = $(buttonEl).parents('.actions-group').index();
      }
      **const button = groups[groupIndex][buttonIndex];**
      if (button.onClick) button.onClick(actions, e);
      if (actions.params.onClick) actions.params.onClick(actions, e);
      if (button.close !== false) actions.close();
}

I see, the we need it only around lines 125-134, because the same condition for popoverOpened and popoverClosed events doesn't make sense, because it is for conversion to popover which won't happen anyway if we don't pass buttons/groups parameter. Can you remove it there and i will merge it?

Thanks, merged!

With pleasure!


[BETA] Multi edit runtime editor needed for touch screens

We need an editor for multi-edit runtime items such as large-number, text, date, time, and IP-address.
Although we can look into better editors over time, initially this is for a menu item dialog with an analog slider representing the range. It will have a next and back button. Depends on #87

Hi Dave.
I pulled down the library and it fails to build because ResistiveTouchScreen.h doesn't appear to be checked in. Can you add it?
Thanks,
Brandon

Hi there the beta version needs the latest IoAbstraction 1.7.2. Can you check IoAbstraction and TaskManagerIO are up to date.

IoAbstraction 1.7.2 and TaskManagerIO 1.1.2. But don’t forget you’ll need to switch streams to beta in the designer UI too if you want to use the beta version. You can also use the beta 2.0 designer with 1.7 libraries.

Hi there the beta version needs the latest IoAbstraction 1.7.2. Can you check IoAbstraction and TaskManagerIO are up to date.

Ahh. I missed the IoAbstraction update. Thanks!
Is this stuff in addition to your day job?

Just for the sake of others, tcMenu Designer 2.0 BETA can happily work with the 1.7 libraries, you have no need to switch stream yet, the designer is pretty much ready, the libraries are not yet ready for wide usage.