Extract the integrated terminal

"Feature" request.
The integrated terminal grows in functionality, to the point that it could soon become very useful standalone, as its own app. I'm only a casual VScode user (using vim most of the time), but I would definitely be interested in a well-behaved, consistent, reactively-configurable, multi-platform terminal not tied to the editor.
Obviously if such a situation were to unfold, the shared component (not entirely dissimilar to VTE) should be jointly developed and shared with VScode. Both could be able to leverage a common configuration so that whether a terminal leveraging such a theoretical common component is spawned within VScode or standalone, they behave the same.

Edit from @Tyriar:
There is some confusion about the scope of this issue, here is the clarification as the thread is long:

This issue is tracking making the terminal "stand alone", ie. being able to launch code --term for example (see https://github.com/microsoft/vscode/issues/34442#issuecomment-901959244 for details)
#10121 tracks being able to pull the terminal view/panel out of the window
#10546 tracks adding tabs to the terminal, combined with #10121 this would ideally allow terminal tabs to be pulled into a separate window

Hint, hint, call the thing VSterm?

This is an idea I've thrown around a bit, I doubt we'll get time to work on it any time soon. The first steps for this would be more flexible movement of the panel inside the workbench and pulling it into its own window.

You should check out https://hyper.is/, also Electron based and extensible.

@auchenberg I definitely know about Hyper ;) yet Code's implementation is currently much more solid though, and given each one's track record in stability and performance I'd rather bet on Code. Also having the external terminal and Code's integrated one behave in exactly the same way is a non-negligible feature.

@lloeki Hyper is migrating to xterm.js build by @Tyriar, which means that Hyper most likely will be similar to the VS Code console. I can't speak on behalf of @Tyriar, but to me it sounds like most of the concerns are addressed by this migration. https://github.com/zeit/hyper/issues/1275

Yes Hyper is planning on moving to xterm.js for v2. There will be some differences such as configuration and some things are handled differently (clear in Hyper may not work on Windows for example), overall it will be very close to VS Code though.

I can't speak for v2 but the last time I tried Hyper at was really slow & buggy, especially under Windows.
VSCode's terminal implementation worked so good that I don't use cmd.exe anymore.
I understand it's not the priority but if I was to try to extract VSCode's terminal and make it run without VSCode where should I start?

@warpdesign what I was thinking was to be able to launch the terminal by itself using code --term or something similar, this would involve:

Create the "terminal window" which has access to the services used internally by the regular VS Code window (this part would be particularly tricky)
Modifying the CLI to support this
Figure out how keybindings and other user settings interact with this special window

Before starting any of this it would probably be wise to get buy in from the team though (and it's not a priority yet so I wouldn't do this yet).

@Tyriar Ok. I'll won't do anything yet then.

@Tyriar Ok. I'll wait then.

I'm glad this is being worked on. The integrated terminal in VS Code is the best terminal on windows and I would love to be able to use it as a standalone app.

+1

I find that Hyper isn't well supported on Windows.  The integrated term in VS Code is the best implementation that I have found and it would be great to be able to use the same terminal everyone that I use a command line.  Of course, Windows 10 needs a feature to allow the built in terminal to be replaced by a custom terminal.

This is a little higher priority for terminal users now that Sets was pulled from Fast Ring Windows 10 builds.
Sets clearly has a long way to go - starting a new tab was a slow process of opening the new tab, waiting for edge to start (if it didn't crash) and then searching for the app you wanted to start (another powershell, duh). So right now, tabbed terminals is: wait for a bunch of bugs to be fixed, wait for builds to inclode those fixes, wait till you can install a build with those fixes.
Having a VSTerm would give us something we know works. 👍🏼

#40829 has been marked as a duplicate, but I think they are 2 different concerns.

This issue, where people want a VSTerm app or kind of (if I understand well)
Issue #40829 where the VSCode integrated terminal panel could be "detached" from the main window.

The benefit of the #2 is clear when using dual-screen: tests can be run on another screen while keeping the code with another small terminal in the bottom, WITHOUT loosing the ability to CMD-click on failing tests' paths in the detached terminal running the tests, to directly open their editor in the main VSCode window. I think #40829 should be re-opened as it makes sense it's a different issue from this one.

@huafu I'm trying to keep the issue count down, there are several issues relating to this and this is how I see them:

https://github.com/Microsoft/vscode/issues/10121 Pull tabs out into floating windows - This is a blocker to what you're after
https://github.com/Microsoft/vscode/issues/10546 Tabs for terminal - This would likely be needed to pull individual terminals out, not the whole panel (not sure if there's an issue for pulling the panel out or not)

Once both of those are implemented you would naturally get the functionality you're after for free.

VSTerminal as a standalone app would be excellent
I've used Hyper.Js and Terminus, both on windows, specially Hyper has a lot of bugs, it didn't work properly for me and it was slow,  VS Terminal works like charm, very configurable , is fast, and packed with some of the Hyper feature
Current Features:

Open Multiple Terminal in "tab/dropdown"
Open Different Terminal (cmd, powershell, bash, etc)
Split functionality
Set Custom terminal from settings (terminal, arguments, font, fontsize), just to name a few, i was able to set Cmdr
Fast!

and more
my duplicated ticket #55861

no terminal was better than vscode-terminal

Hi guys,
I am hacking vscode to make the integrated terminal a standalone app. Check my preliminary work out: https://github.com/LujunWeng/vscterm. Also, there is an installer for win32-x64: https://github.com/LujunWeng/vscterm/releases.
What I have done:

Removed other UI components and only the terminal left. Figuring out ways to remove those UI components' services.
I also removed builtin extensions to reduce the whole volume of the repo.

Cheers...

@LujunWeng 34,000 commits... did you fork vscode itself? would suggest making a lighter repo for it starting out.

@paralin yes. Basically, I want to keep the history, but it must take long time to clone the whole repo. Yeah. Thank you. It should be a lighter repo.

 If you don't care about history, you can wipe it with a rebase.
Another approach might be to develop as you have for your example app (the extracted terminal) and slowly migrate the terminal code out into another library.

@paralin Thank you for suggestion. I did rebase.

VScode Terminal as a stand-alone app would be great to have but I can see the architectural difficulties it may present and vscode team may be hesitant to it.
Being able to undock the terminal panel as it’s own maximizable window and switch from dropdown to tabs should allievate a lot of pain.
In multiple monitor mode, it’s nice to have terminal separately on it’s own screen.

@nojvek that's definitely on the list of things I want to do in the near future.

Being able to undock the terminal panel as it’s own maximizable window and switch from dropdown to tabs should allievate a lot of pain.

Agreed. In particular I think that solving #10546 would minimally solve a lot of asks simultaneously in a generic way. For example, moving the terminal to a separate window could be just a second regular Code window with a terminal tab in it.

I have 2 monitors and I want to dock out the terminal, output and etc which dock on the bottom of the editor to be in my another monitor with its own window which give me clearly space to work. When do I get this feature in Visual Studio Studio Code?

I have 2 monitors and I want to dock out the terminal, output and etc which dock on the bottom of the editor to be in my another monitor with its own window which give me clearly space to work. When do I get this feature in Visual Studio Studio Code?

Exactly what I'm looking for!

When do I get this feature in Visual Studio Studio Code?

When you send the pull request? 😉

This feature would be amazing. The only terminal I can stand to use is Hyper, and I feel that everyday something about it goes wrong, the text disappears, random errors, or weird margins. I will sometimes open a VScode terminal fullscreen just to use it alone.

@matt`hewcash I like Hyper and vscode too, but if you want a stable feature filled Windows shell try Terminus. It works (including important things like readline), has iterm themes, defaults to Powershell core, and all the customisability of Hyper.

@mikemaccana FYI Hyper, vscode and Terminus all use the backing technology that I help maintain for vscode (xterm.js and node-pty), so the core terminal experience should be pretty similar across each.

When you send the pull request? 😉

Unfortunately this issue is far too large to get externally so I recommend against anyone trying to make a PR.

Create new folder in your project(for example folder name - terminal)
Open folder "terminal" in new window
Open new terminal there
Run command cd ../
Resize terminal on full window
Close terminal in your project
Work!

Is simple and cheap. :)

@Tyriar most of the bugs at a higher level than node-pty - I run practical tests of most of the Windows terminals each month with links to any big issues that stop powershell working. https://github.com/mikemaccana/powershell-profile#prerequisities-for-any-nix-user-who-wants-to-use-powershell

@Tyriar,
In your opinion, the terminal panel to be toggle-able as a separate
electron window/main workbench is also far too reached to be a PR?
I feel that is an incremental baby step delivers 80% of value with 20%
effort.
On Tue, Feb 26, 2019 at 2:56 AM Mike MacCana<EMAIL_ADDRESS>wrote:

@Tyriar https://github.com/Tyriar most of the bugs at a higher level
than node-pty - I run practical tests of most of the Windows terminals each
month with links to any big issues that stop powershell working.
https://github.com/mikemaccana/powershell-profile#prerequisities-for-any-nix-user-who-wants-to-use-powershell
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/34442#issuecomment-467393255,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-JVPR9L56wloj1X2Hbbq9ywwE9w4zOks5vRRLNgaJpZM4PYvHw
.

@nojvek yes that will be very involved. Our top 👍 voted issue is actually "floating window" support which is essentially that and is on the roadmap so someone will probably investigate this within the next 12 months https://github.com/Microsoft/vscode/wiki/Roadmap#workbench

Is not it better to open another vscode window with the file you want or terminal cmd?

I'm not sure why this keeps getting turned into "this is part of turning panels into floating panels". The terminal is special enough that it doesn't need to wait for panels in general to made floating because unlike every other panel, the terminal does not communicate with anything else.
Unlike every other panel, what users do inside the terminal has literally no bearing on VS Code outside of what "running a terminal outside of VS Code" does (e.g. files popping into existence or disappearing). While the work to make panels in general is a heck of a lot of crazy re-architecting, making just the terminal something we can pop out is way easier because there is no data exchange that needs to happen in terms of what's in the terminal.
This is something that someone with a week of time and enthusiasm could probably do (with guidance, of course), and is extremely worth not treating as "part of the floating panels" work. It expressly is not. It's way easier.

@Pomax

it doesn't need to wait for panels in general to made floating because unlike every other panel, the terminal does not need to tie into, or communicate with, anything else (unlike problems, or output, or debug).

This is not true, it touches a lot of components and a lot of components touch it.

This is something that someone with a week of time and enthusiasm could probably do (with guidance, of course)

It could certainly be hacked together by someone with enthusiasm, but it's not as simple of a change as you might think to do right. AFAIK the plan is to use the terminal as the starting place for pulling a part of a VS Code window into another window.
I bet I'm more keen to see this done than you are, but we need to wait until it gets on the plan. The best thing you can do it :+1: the issue as that's one of the indicators that feeds into our prioritization process.

I see this issue basically also just being able to send code to an external terminal in a more robust fashion.
Could we note take advantage of the new  https://github.com/microsoft/terminal to make the "sending code to an external terminal" more functional?

Since issues that ask for a "detach terminal" feature are getting closed in favour of this (even though it looks like a separate request), I'd like to know that that's something I would very much like to have.

@SHxKM for detaching see https://github.com/microsoft/vscode/issues/10121 and https://github.com/microsoft/vscode/issues/10546

Detach is different request, i actually want an standalone app of the vscode terminal, this is terminal is one of the best out there tbh,  with nice feature like customization, shell selection, split, tabs
and i would like to be able to use outside vscode

@hgouveia what you're describing is what I consider this issue to be.

i actually want an standalone app of the vscode terminal,

Me, too. Would also be nice if it could have its completely own extension ecosystem and maybe create a foundation for sharing certain things (e.g. extension handling) so other apps could use that as well. (There seems to be at least "some" interest in this.)

The way I see this issue playing out is not having it completely standalone, but allow creating a terminal through CLI args code --term to launch just a terminal not associated with any workspace.

Would also be nice if it could have its completely own extension ecosystem

xterm.js the underlying component for the terminal is just finalizing it's "addon" system in v4, that is the extensions for the terminal itself such that you can build on top of it without putting everything into the core https://github.com/xtermjs/xterm.js/releases/tag/3.14.0. Being able to plug in xterm.js addons through VS Code is not really a direction that I'd want it to go because xterm.js addons run on the renderer, not the extension host (which protects the renderer process/DOM from naughty extensions). They do let you write functionality that could be used in multiple terminals though.
As for VS Code's "base" as a platform, there was a discussion about this very early on and everyone was pretty against it as it means we would lose agility due to having low-level APIs we can't break. Things like new tree view that boosts perf would be much more difficult in such a world.

code --term would be super nice. I do wonder how much RAM it will end up using. If I have both code and code --term open at the same time in different windows. Does that make two instances of electron with at-least 150MB of RAM/window ?
iTerm uses 164MB for the base and about ~5MB per tab so may be it's comparable.
I know VSCode and especially you care a great deal about memory/cpu/UI lag a lot, unlike slack which ends up using multi gigabytes of RAM.
So excited for code --term when it ships.

The memory usage would likely be much smaller than 150mb as we could avoid creating most of the services. I think the memory per tab would be around 5-15mb, but it depends on what your scrollback is set to as we init arrays for the full buffer ahead of time.

Looking forward to this!

Any updates?

Would love this!!!  Currently I am using a second instance of VSCode to run my terminal but I loose the ability to link to my current code in the errors.

It would be great to see the arrow keys working in term much like RStudio and PowerShell ISE.

Looking forward to this. VScode terminal is the best one I used in windows.

Would love this.

This would be great!

This would be awesome!

Popping out the terminal to a separate window (and even editors etc) for dual screen support is a must have imho. For me, it is the main drawback compared to Visual Studio and other IDEs

I really want to use terminal in vscode by emacs.... 😃  Terminal in vscode is best terminal I see which is in one editor.

In the interim, before a true extracted terminal, would it perhaps be possible to add an option to configure VSCode as the "external" terminal?
Sounds contradictory, but it would work like this: when you open an external terminal, it's actually a new instance of VSCode with the terminal maximized.  It could even have all non-terminal extensions off, for the sake of efficiency.

@ultraGentle that might be something when can do when we allow the terminal to be pulled out of the main window, chances are it wouldn't use the external terminal commands to do so though. https://github.com/microsoft/vscode/issues/10121

@Tyriar thanks for the response.  Just to clarify, I meant that since some folks are already creating a new instance of VSCode just to use the terminal in a separate window, there could be a shortcut for that behavior to mock the effect of an extracted terminal.
It's not a big deal, since that's already easy to do with a few commands in a row (Cmd+N  --> Ctrl+` --> Toggle Maximize Panel).  Just an idea to fold that process into a single command.
Anyway, no worries, and cheers!

When you use development containers, but would love to have your vscode terminal on a different screen, you're all out of luck.
You'd either need a "detach" option for the terminal of the current vscode instance or close the terminal and docker exec yourself into the development container from hyper.

Would love to see VSCode integrated terminal detachable and/or able to start it as a standalone app.
Windows Terminal? Before it has some degree of integration with VSCode, I will say: Thanks. But no, thanks. BTW, WT doesn't support bold font which I love about VSCode Terminal.

I know most of you are hyped about the terminal but Windows is GUI. There's plenty of terminal apps out there if one wants to use it. The main objective of this issue, as I take it and feel it and the reason why I stumbled upon this issue, too, is that it's really tiresome to be resizing the terminal window (or hitting a hotkey) everytime I make a build and need to see a full-screen terminal to view debug output as my current app requires the terminal to display stuff and can't use the debug console (don't ask, it's just like that).
So, the main concern should be detaching the terminal from the VSCode window so I can at least open it in a secondary monitor (I've got 4, go figure) to view terminal output with more real estate to avoid resizing the panel back & forth. I have to expand the terminal to view debug, then resize back to edit, then expand to view my changes, then resize to edit... man, it's horrible.
Windows Terminal, HyperTerm, iTerm, whatever, are all cool, but I think they're outside of the scope of the real issue here.

I second that. It would be especially useful when having multiple monitors with different sizes and debugging anything on VSCode.
For the quick and dirty way, I wonder if it's possible to write a plugin that just mirrors output from terminal to the other terminal process

I really want to use terminal in vscode by emacs.... 😃 Terminal in vscode is best terminal I see which is in one editor.

open a terminal
emacs -nw
I had to fix lots of keybindings to make sure the keybindings in vscode doesn't interfere with emacs.
Just try to use emacs key bindings if anything doesn't work figure out what keybinding is interfering then change the (where binding) condition for that keychord to add && !terminalFocus.

The way I see this issue playing out is not having it completely standalone, but allow creating a terminal through CLI args code --term to launch just a terminal not associated with any workspace.

Sounds good, except maybe for one UX point: if I'm not mistaken, any update of VS Code would kill the terminals as well. But I'm all for it if it makes the ball move forward.

So, the main concern should be detaching the terminal from the VSCode window so I can at least open it in a secondary monitor (I've got 4, go figure) to view terminal output with more real estate to avoid resizing the panel back & forth

This use case is definitely part of the discussion (and possibly part of the plan IIUC), but such a terminal is bound to a workspace. This issue right here also covers the use case of having a terminal untied to any workspace (and maybe as a separate program). This workspace-less state kind of exists when you start a new window (which starts a blank, empty workspace which can have terminals started in that state).

I know most of you are hyped about the terminal but Windows is GUI

So is macOS, having a decent terminal is a significant boost. Having consistent, well-behaved terminals throughout the OS is a definite boost day to day.

I have to expand the terminal to view debug, then resize back to edit, then expand to view my changes, then resize to edit... man, it's horrible.

My current workaround is to use ^`  or ⌘J to quickly toggle the bottom panel back and forth (after having resized it to a good enough size) Quake-console-style.

Would love this!!! Currently I am using a second instance of VSCode to run my terminal but I loose the ability to link to my current code in the errors.

Relating errors / warning messages to code currently worked on in the editor is also the same use case for me. Right now I work around the terminal limitation by spanning one VS Code window over two monitors, select "Move Panel Right" from the terminal's context menu, and move the panel boundary such that the editor/source tree window is on the left screen, and the terminal on the right screen. That's a ugly workaround that requires both monitors having the same resolution, messes up the window title split between screens, and is not possible in full screen mode - but it's way better than having just the small terminal panel at the bottom.

This would be amazing, especially with the latest terminal improvements. VSCode terminal feels snappier than PuTTY !

Separate terminal on second screen would definitely be useful.

+1

Here is another ugly work around using Tmux:
https://qhyun.medium.com/functional-external-vscode-terminal-using-tmux-485962384f56

Here is another ugly work around using Tmux:
https://qhyun.medium.com/functional-external-vscode-terminal-using-tmux-485962384f56

Would love to see this happen. Being able to maximize the code on one screen while viewing the results (Terminal) on my second screen.
Make it so.
It is the way.

Would love to see this happen. Being able to maximize the code on one screen while viewing the results (Terminal) on my second screen.
Make it so.
It is the way.

While readding the comments here, i notice that there are two feature requests that are different but still lives on the same issue:

Begin able to use the Vscode terminal standalone
Alowing the vscode terminal, still attached to the vscode session, to be poped-out as an independant window, mainly to put it on another screen to fully use screen real estate.

These two features are clearly different. Since I only want the second one, which looks easier to implement (but might not be, i'm not aware of vscode internals), maybe we should split the issue in two ?
Furthermore, feature requests asking for only one of the two are systematically closed as duplicates of this one.
I think we should split.

While readding the comments here, i notice that there are two feature requests that are different but still lives on the same issue:

Begin able to use the Vscode terminal standalone
Alowing the vscode terminal, still attached to the vscode session, to be poped-out as an independant window, mainly to put it on another screen to fully use screen real estate.

These two features are clearly different. Since I only want the second one, which looks easier to implement (but might not be, i'm not aware of vscode internals), maybe we should split the issue in two ?
Furthermore, feature requests asking for only one of the two are systematically closed as duplicates of this one.
I think we should split.

@lrnv I really don't want to repeat once more (https://github.com/microsoft/vscode/issues/34442#issuecomment-508214479, https://github.com/microsoft/vscode/issues/34442#issuecomment-403465154) and send another spam email to all subscribers, but...
For detaching panels/views to separate windows we already have #10121, but it's very difficult, if not impossible, to implement.
So basically, the idea now is extracting the terminal part to a standalone executable, or allow an instance of Code to run in "terminal mode" (https://github.com/microsoft/vscode/issues/34442#issuecomment-508834722) so we can have both standalone terminal app AND detachable terminal at once.

@lrnv I really don't want to repeat once more (https://github.com/microsoft/vscode/issues/34442#issuecomment-508214479, https://github.com/microsoft/vscode/issues/34442#issuecomment-403465154) and send another spam email to all subscribers, but...
For detaching panels/views to separate windows we already have #10121, but it's very difficult, if not impossible, to implement.
So basically, the idea now is extracting the terminal part to a standalone executable, or allow an instance of Code to run in "terminal mode" (https://github.com/microsoft/vscode/issues/34442#issuecomment-508834722) so we can have both standalone terminal app AND detachable terminal at once.

@lrnv yes I'm aware of the confusion and while I have been tracking "Begin able to use the Vscode terminal standalone", I know that the upvote count is definitely misleading.
As @yume-chan calls out, https://github.com/microsoft/vscode/issues/10121 is the item for being able to pull the terminal view out. There's another piece of this in https://github.com/microsoft/vscode/issues/10546 which would hopefully allow terminal tabs to be pulled out as well. I might update the OP's comment since GitHub doesn't support pinned comments (in issues anyway).

@lrnv yes I'm aware of the confusion and while I have been tracking "Begin able to use the Vscode terminal standalone", I know that the upvote count is definitely misleading.
As @yume-chan calls out, https://github.com/microsoft/vscode/issues/10121 is the item for being able to pull the terminal view out. There's another piece of this in https://github.com/microsoft/vscode/issues/10546 which would hopefully allow terminal tabs to be pulled out as well. I might update the OP's comment since GitHub doesn't support pinned comments (in issues anyway).

@Tyriar Thanks a lot for the clarification in the OP.

@Tyriar Thanks a lot for the clarification in the OP.

4 years have passed and the feature has not been implemented

please implement this!

If Microsoft Terminal is installed, it is also equally useful to add open this current tab or window in MSFT Terminal option in the right click context menu in VS Code

@ridhwaans I created a small extension to give some context menu options for Windows Terminal recently: https://marketplace.visualstudio.com/items?itemName=Tyriar.windows-terminal

@ridhwaans I created a small extension to give some context menu options for Windows Terminal recently: https://marketplace.visualstudio.com/items?itemName=Tyriar.windows-terminal

Could one run a code selection from the VSC script pane on the Windows Terminal using F8?

@Ayanmullick the extension doesn't do it right now, but if you can tell WT to run a command (by launching a new tab?) then it should be possible. The might be complications around getting it to work properly with the format of the command though (eg. the pwsh command looks different to the bash command).

It seems like a better solution to the "extract integrated terminal" problem is to instead utilize the Windows terminal and create a communication protocol to send data to and from. As far as my needs are concerned this would solve what I really want from the core of this issue.

This is my workaround (for gcc compiler messages): https://github.com/patrislav1/vmake

@Ayanmullick the extension doesn't do it right now, but if you can tell WT to run a command (by launching a new tab?) then it should be possible. The might be complications around getting it to work properly with the format of the command though (eg. the pwsh command looks different to the bash command).

WT runs the user's PowerShell profile when launching a new PowerShell tab. What should one add in the profile to enable that communication between the VSC script pane and the WT?

It would be awesome if running "code ." would just augment the current terminal session with the rest of VSCode.

I just wanna add that I would love for "quake mode" to be a part of this :)
It seems folks liked the idea over in the Windows Terminal space: https://github.com/microsoft/terminal/issues/653

The integrated terminal should merely be Windows Terminal hosted as a toolbox window.

@BEEDELLROKEJULIANLOCKHART this has been suggested before but it's not possible as it wouldn't work in many of the places where VS Code runs: Linux, macOS, Codespaces (Browser, Android, iPad, etc.). Besides it would be quite the undertaking to do that adaption just for Windows and we would actually regress in a lot of areas. That's without considering the potential downsides of hosting such a toolbox window inside a toolbox app which I'm sure there are plenty.

The integrated terminal should merely be Windows Terminal hosted as a toolbox window.

I think the opposite – that Windows Terminal should be just wrapped VSCode's terminal 😄.

The issue in question here is making it possible to run the vscode terminal in a standalone window. What's that got to do with Windows Terminal? I doubt Windows Terminal wants to ship all of vscode just for a terminal, and conversely vscode doesn't need Windows Terminal because the integrated terminal is way more integrated into the vscode experience.
They should just stay separate things and people can use what they prefer. A little competition never hurt any application anyway.

http://github.com/microsoft/vscode/issues/34442#issuecomment-901921248, I have never observed compettition within one legal entity to be benficial for products that must be paid for. http://web.telegram.org/z/ and http://web.telegram.org/k/ are rather good examples of this because much has been wasted by designing two almost-identical websites, and thus 2 code-bases.

https://github.com/microsoft/vscode/issues/34442#issuecomment-901850776, indeed, naively I did not consider whether Windows Terminal is supported by Microsoft for operating-systems other than Windows, irrespective of its obviously-denotive name.
If theoretical utilisation of Windows Terminal would be functionally regressive, surely as what was stated at http://github.com/microsoft/vscode/issues/34442#issuecomment-901916458 would be better for Microsoft.

Years ago i was supporting this ticket and asking for this feature, but since Windows Terminal  was released, i am not longer feel the need to this feature, since is a fantastic substitute and does all i want, i would vote to close this , and instead use this time to improve more Windows Terminal  making it faster and better and better

I also vote to close this. Windows Terminal is good enough and it works with VSCode fine.
I'd vote for the Quake Mode but that feels like a different feature request to be filed.

I agree, but please follow @Tyriar precision and do NOT close #10121 as duplicate of this in the future... #10121 needs to stay open, even if we cannot talk in it anymore.

There are plenty of people that still want this so I'm not closing it, but I think things have changed a little since WT came out as the need for a solid conpty-backed terminal on Windows is now covered. Here's what I feel this issue now encapsulates:

Being able to have a lightweight VS Code window with a fullscreen terminal in it, lightweight meaning minimal memory. This is more than https://github.com/microsoft/vscode/issues/10121 which would just be allowing dragging the panel of an existing window out.
These lightweight terminals could be launched with something like code --term or via a command.
The window could be "upgraded" by running code -r <folder> which would open a folder in that window and reconnect the terminals that were previously there.
Potentially bringing quake mode in which would use one of these lightweight terminals.

I disagree with the decision of closing this issue and also thinking that Windows Terminal is a drop-in replacement for this feature. Windows Terminal may be good and all, but it is NOT what we're looking for (at least the ones interested in seeing this issue come to light):
As for @Tyriar 's points, the first three do encapsulate what we want but the last one IMO is just fancyness (and personally I've always disliked those quake-like terminals).
Windows Terminal is a good app but it feels heavy and bloated as heck, unlike VSCode. Considering there are other similar (but not as lightweight or preferred as VSCode's) like Tabby (which is Electron-based) one does wonder why is it so hard for the VSCode team to implement a feature with a small click menu that says "Detach terminal" and just opens VSCode in "terminal mode"? The ones that are asking for this feature only want a good terminal (like the VSCode team has achieved with it so far) that's lightweight and feels familiar.
Therefore, I disagree completely on closing this issue or duplicates and marking this as a wontfix, because it feels as if MS doesn't want to listen to its community and is what actually creates more forks, more disappointment, more fragmentation and more unhappy users along the way.

one does wonder why is it so hard for the VSCode team to implement a feature with a small click menu that says "Detach terminal" and just opens VSCode in "terminal mode"?

@darkguy2008 the slowness is a combination of resources, other priorities (I have almost 500 issues assigned atm 😅) and other things that it's blocked on. For example #10121 poses architectural problems since VS Code's terminal integrates with so many internal services, the naive approach would be to initialize all these services but that would mean a lot of extra memory and cpu which doesn't really meet the quality bar we're aiming for.
We have been smashing through some major features in the terminal recently though (tabs, profiles, terminals in editor area, process reconnect/detach), so this doesn't seem so far off anymore 🤞

A VSCode with only integrated terminal sounds more bloated than Windows Terminal or any terminal on other platforms (rxvt, konsole, Mac term, etc.) even it is more lightweight than a VSCode with all extensions enabled.
Behind the scene VSCode is built using electron.js, with a Chromeium based rendering process and a number of nodejs based backend processes. Even the code main can consume at least ~90MB:

A VSCode with only integrated terminal sounds more bloated than Windows Terminal or any terminal on other platforms (rxvt, konsole, Mac term, etc.) even it is more lightweight than a VSCode with all extensions enabled.
Behind the scene VSCode is built using electron.js, with a Chromeium based rendering process and a number of nodejs based backend processes. Even the code main can consume at least ~90MB:

Well, another point for me: https://github.com/microsoft/terminal/issues/3843 it seems that even in the same Windows platform, Windows Terminal isn't compatible. It's too bad that to download it requires the Microsoft Store (so this excludes a lot of users that don't want or don't have the store - unlike VSCode) and also it's uncompatible with Windows LTSC, which is the enterprise version that some companies do use. For instance, my work laptop uses LTSC (and I love it too, considering it isn't bloated as heck) and I'm unable to use the WT for this same reason, just like other users who would be excluded due to this reason, not to mention the lack of cross-platform of Windows Terminal.
It's a good app, but again, not a drop-in replacement.
I'm not very concerned about the memory usage (RAM is pretty cheap nowadays) but more about the UX, the speed/snappyness of it that I've yet to find in any other standalone Electron-based terminal emulator.
Plus, with the session persistence feature that currently VSCode has in place, I had expected that detaching the session, creating a new window and reloading the session there with just the terminal wasn't too much of a hassle now.
Thankfully, there's people like @Tyriar who actually has a point and now sees this feature as a possible one in a near future (hopefully), so thanks for taking us into account!

@tigerinus right, I would expect the eventual memory usage of a terminal window to be similar to the process explorer window which is sitting at 82mb in your screenshot, plus the memory xterm.js takes for its buffer. What we would not want it something closer to a normal window like the 163mb one in your screenshot.
Clearly WT is capable of being faster since it's closer to the metal, but beyond the overhead of Electron, the xterm.js is a very good citizen wrt memory and CPU.

I don't think we need to get into a philosophical debate on "lightweightedness" and whether WT or VS Code is better. A lot of people get notifications for this issue and that doesn't feel productive.

Windows Terminal is a good app but it feels heavy and bloated as heck

I'm not sure what gives you that impression. Windows Terminal will probably forever be lighter and more efficient than VSCode's terminal, because the former is written in C++ without any extra layers on top, while VSCode depends on Electron.

one does wonder why is it so hard (and has taken way too long... 4 years, seriously?) for the VSCode team to implement a feature with a small click menu that says "Detach terminal" and just opens VSCode in "terminal mode"?

Software doesn't work like that. It's easy to add a menu that says "Detach terminal", but it is hard to make clicking that menu item actually do what you ask. Like @Tyriar mentioned, having a detached terminal window goes against the entire VSCode architecture as it stands and likely requires significant work to be able to disentangle the integrated terminal codebase from the context of a VSCode workspace window.
And speaking from experience as a maintainer of my own software, complaining about timelines is unlikely to be a motivator to deliver the feature you want any quicker.

Well, I still think this issue should not be closed and the feature request is pretty valid and has some good points (i.e. cross-platform, IDE integration) plus other features that WT can't serve because it basically falls out of scope and it excludes a lot of users that VS is actually taking.
Again, I'm not concerned about RAM usage... If an user can run VSCode, it's more than safe to assume that it has plenty of RAM to support an external, detached terminal if it wants to (also, knowingly it'll take RAM). I don't really see why this is a problem here.

@Tyriar - I've opened a different feature request at https://github.com/microsoft/vscode/issues/131188 regarding launching external terminal and attach a VSCode terminal session to it.
Thanks for all the hard work!

This is just a workaround I'm using and it's only for unix-like systems and just for the terminal panel, but you can open a new terminal outside vscode, and get its device path with who am i.
Suppose it's /dev/ttys001.
Then in the vscode terminal you run your process, let's say npm run start:dev &> /dev/ttys001, then you get the terminal output in a separate window.
You could just run the task in that terminal directly, but for tasks that attach to the debugger, this can only be done from vscode integrated terminal.
Hope this helps someone.

When we run
$ code .
then Ctrl+Shift+P > Terminal: Create New Terminal in Editor Area, it looks like:

Great Work!
Now if we can run code . and then Terminal: Create New Terminal in Editor Area in one go, then we sort of got a terminal.

I think the opposite – that Windows Terminal should be just wrapped VSCode's terminal 😄.

Quoting what @borekb said, I think this is actually something to be considered. I don't think Windows Terminal should be abandoned, though.
Regarding performance, it's reasonable to say that a good performance can be achieved by using asynchronous operations with rendering optimizations. I'm actually skeptical that Windows Terminal would be too superior in user-perceived responsiveness when compared to such a program. A browser engine like V8 can be viewed as an optimization engine that when used right can perform very well.
The main advantage of this approach is having an official cross-platform terminal that is highly customizable and integrates well with vscode.

I think the opposite – that Windows Terminal should be just wrapped VSCode's terminal 😄.

I actually suggested this to the WT team when it was in the early stages but that ideal ultimately fell apart since the team wasn't that familiar with web tech and they didn't believe the sort of performance/overhead they would need to get it shipped within Windows (which happened with W11) would be possible.

and they didn't believe the sort of performance/overhead they would need to get it shipped within Windows (which happened with W11) would be possible.

I shouldn't say this, but ironically it's most probably possible to make a web terminal that's 10x faster than WT.

Don't laugh, but I find regular cmd.exe on Windows my best terminal (for running npm dev processed like npm run start, etc). But I'd really to have it on my second monitor when working in codespaces.

@alvipeo Absolutely.  I do the same thing.  And for me, invariably the regular command prompt is faster anyway.  I often have to wait for characters to appear on the VS Code terminal, depending on what's going on at that moment.  Pretty wild on a beefy machine this day and age.

Just to be clear - it's not just merely performance of it for me, it the second monitor. I can have the whole screen with terminal output, not that small area at the bottom of VS Code.

CodeTerminal here, now we can use Terminal from vscode as a standalone app!
https://github.com/xcodebuild/CodeTerminal

🚀 Feel free to try it out.

CodeTerminal here, now we can use Terminal from vscode as a standalone app!
https://github.com/xcodebuild/CodeTerminal
🚀 Feel free to try it out.

Okay so while this isn't exactly the original request (detaching the existing terminal window into a separate one to put it on another monitor), this is AWESOME! The VSCode terminal in itself, in its own standalone form, is pretty good and solid. This looks like an amazing project to follow, thanks for sharing! I just gave it a try and it worked pretty well! :)

It's a bit too slow/laggy on Linux but I'd love to see this too

I'd love to be able to drag the vscode terminal out in a new window, so that i can take advantage of my second monitor. It doesn't need to be a standalone app tho.

It become more necessary since history of VSCode integrated terminal use different file from other terminal apps.

@Tyriar should it be using the same history file?
Originally posted by @meganrogge in https://github.com/microsoft/vscode/issues/145296#issuecomment-1112671691

@iFwu reopened that issue to get clarity there, it should be using the same file.

Well, you can do something like this:
https://user-images.githubusercontent.com/29582865/178532158-e4131237-e7c3-449f-b772-9281c88fb072.mp4
It isn't exactly seamless though.

I'd love to be able to drag the vscode terminal out in a new window, so that i can take advantage of my second monitor. It doesn't need to be a standalone app tho.

you can use Schnell Console alongside!

CodeTerminal here, now we can use Terminal from vscode as a standalone app!
https://github.com/xcodebuild/CodeTerminal

🚀 Feel free to try it out.

Darn, that just got archived

One thing people can do to get the VS Code terminal as a "standalone" terminal is as follows:

Open a new VS Code window
Open the terminal
Move Terminal into Editor Area
View > Appearance > Zen Mode
View > Appearance > Centered Layout (uncheck)

Note 1: Zen Mode makes the window full screen, but if you exit full screen, you should still get the right view.
Note 2: I only tested this on macOS, but I imagine it would be a similar behavior for Windows and Linux.

One thing people can do to get the VS Code terminal as a "standalone" terminal is as follows:

Open a new VS Code window
Open the terminal
Move Terminal into Editor Area
View > Appearance > Zen Mode
View > Appearance > Centered Layout (uncheck)

Note 1: Zen Mode makes the window full screen, but if you exit full screen, you should still get the right view. Note 2: I only tested this on macOS, but I imagine it would be a similar behavior for Windows and Linux.

I feel like this is the answer to getting to a "Pop-out" terminal. It's essentially VSCode with all the other features hidden. Probably not as optimal performance-wise but are we splitting hairs here?
On Mac I prefer to have my terminal on the desktop layout (I know, like a fiend) so I customized the layout and disabled visibility of the "Activity Bar" and "Status Bar".

Would also like a simple button on vscode to pop out the terminal into a new window. Cheers.

@TrentDevelopsMS we wouldn't want to ship a sub-par version that needs to load the entire workbench as we'll inevitably get complaints about memory usage. Plus, you can essentially do that already by creating a new workspace and maximizing the panel, it's just a little less convenient.

Any news? Is this issue on any roadmap? That's how much I love the VS Code terminal, and I think I'm not alone.

@philparisot this is the official roadmap which will probably get an update soon. It's not there yet but I expect it will be within the next 1-2 years. Intellisense in the terminal (https://github.com/microsoft/vscode/pull/171648) and leveraging shell integration smarts in other ways is current big focus for the terminal right now.

By the way, I think something like a new CLI flag would be more than enough:
code --only-terminal

Which opens the VS Code window with the terminal maximized, and panels collapsed.

@felipecrs, I'd make it code --terminal for simplicity.

I think the main draw of extracting the integrated terminal (over using a standalone terminal application, even on which shares a codebase with VSCode) is the ability to preserve long-running operations when switching workspaces. If I start a script in one workspace then want to switch workspaces, it closes that terminal. I'd like to be able to pop-out the attached terminal and change workspaces without stopping that shell.

@jasondamour FYI you can run the detach session command and attach session in the other window, or just drag it over before closing the old window https://code.visualstudio.com/docs/terminal/advanced#_moving-terminals-between-windows

Related on Stack Overflow: Is it possible to open integrated terminals from VS Code in a separate window?

Scan phone number

Scan

This would be amazing. I sometimes want to run a terminal without running vscode. I really like the vscode terminal.

Request to close this issue. It mixes up two completely separate concerns:
(a) using vscode's integrated terminal as a replacement for the poor native terminal implementations in Windows.
(b) detaching panels so they can be placed e.g. on a secondary monitor
Out of these, (a) is really not vscode's concern, which is why this issue never moves forward. OTOH, (b) is a much-needed feature that never gets discussed, because all feature requests that mention it are marked as a duplicate of this issue and closed (e.g. #188682).

@zocky this (a) has been on my short list of things I'd really like to do for a while. B is tracked in the highest voted issue on the repo.
If we closed this, a new issue would come up and it would take years to get the votes again...? There's clarification as to what this issue it in the top comment.

@Tyriar  감사합니다 잘하셨어요 ㅋㅋ

@sunglim 오랜만이에요! 👋

Y

O

We can now open a terminal as an edutor tab, and move editors into floating windows.

We can now open a terminal as an edutor tab, and move editors into floating windows.

yep. already wrote this up in my answer to the linked Stack Overflow question along with keyboard shortcuts to help with it.

`


Address CI warnings from precommit

This should fix all warnings found by the precommit CI step and bring the package largely in line with LEGEND's python policy. There are quite a few changes but are pretty straightforward:

Line/periods for single line docstrings
Use of snake_case for variable, function names
Replacement of raw print in package with logging module

As print() use is valid in the example/developer scripts, the flake8 configuration is updated to ignore that warning for the files under scripts/ only.

Codecov Report
Base: 0.80% // Head: 1.33% // Increases project coverage by +0.53% :tada:

Coverage data is based on head (520d758) compared to base (cbc1bd2).
Patch coverage: 1.47% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff            @@
##            main      #8      +/-   ##
========================================
+ Coverage   0.80%   1.33%   +0.53%
========================================
  Files          8       8
  Lines        373     374       +1
========================================
+ Hits           3       5       +2
+ Misses       370     369       -1

Impacted Files
Coverage Δ

...LegendBaseline/L1000Baseline/L1000CompleteSetup.py
0.00% <0.00%> (ø)

...om/LegendBaseline/L1000Baseline/LInfrastructure.py
0.00% <0.00%> (ø)

...endgeom/LegendBaseline/L1000Baseline/LMaterials.py
0.00% <0.00%> (ø)

...egendgeom/LegendBaseline/L1000Baseline/__init__.py
0.00% <ø> (ø)

src/pylegendgeom/LegendBaseline/__init__.py
0.00% <ø> (ø)

...endgeom/LegendBaseline/coaxialTemplate/__init__.py
0.00% <ø> (ø)

...ylegendgeom/LegendBaseline/coaxialTemplate/icpc.py
0.00% <0.00%> (ø)

src/pylegendgeom/__init__.py
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Importing from Chrome fails with "One or more errors occurred"

When attempting to import from Chrome I get an error message "One or more errors occurred", no further description available.

This happens regardless of Chrome being open or not. (I've checked running processes, no "chrome.exe" is present.)

Same issue here.
Is there any difference whether Chrome is synced with google's cloud storage or not?
Mine is synced tot Google.

Mine are synced too encrypted with a passphrase, but that only applies to cloud storage.
There is no encryption locally. You can even view them as plain text with ChromePassView without any prompt to decrypt.

When I ran into the same error (Win 11 21H1, Firefox 92.0) I checked my profiles (about:profiles). KPBI had not pre-selected the active profile. When I switched to that, KPBI could do its job - although very slowly. About 1 entry per second! (Even though I had unchecked web page titles and icons to avoid web accesses.)


TestItemRunner should skip child directories that have their own Project.toml that define a package

VSCode test running follows this simple rule: for each @testitem we look in the folder, then in the parent folder etc until we find a Project.toml that defines a package, and then the @testitem is part of that package.
The TestItemRunner.jl implementation doesn't follow that philosophy fully, I think what is missing there is that we should by default skip any child folder that has a new Project.toml in it that defines a new package. So in @NHDaly's tree, if someone runs test/runtests.jl, then that should actually not run the @testitems of the sub packages, right?
Originally posted by @davidanthoff in https://github.com/julia-vscode/TestItemRunner.jl/issues/39#issuecomment-1382638956

I second this. In the past I had several locally developed package dependencies (using ]develop --local xxx). The code and runtests of those packages will also be picked up by the @run_package_tests and tried to be tested. However these tests fail almost always because they have a different environment defined by their Project.toml.
This is a show stopper and interferes more than I thought with the development process.


net: LookupIP("My Local Node.local") doesn't work with Go 1.6

https://github.com/golang/go/commit/bb8c2e19a7fe2ca2283eca44dba2047c9f4307fe introduces "unicast DNS name validation" into Lookup APIs and drops support for mDNS that was available in Go 1.5 and below on some platforms that have mDNS-capable stub resolver library in C such as OS X, Linux, FreeBSD.

Reverted that change.


Wrong Carousel behavior

Version
0.7.0-beta.3
Environment
macOS 10.13.3、Chrome<EMAIL_ADDRESS>Reproduction link
https://stackblitz.com/edit/ng-zorro-antd-setup-tpsmmo
Steps to reproduce

Copy code from official docs: https://ng.ant.design/version/0.7.x/components/carousel/zh
Set nzAutoPlay, nzVertical  property

What is expected?
Autoplay
What is actually happening?
Can't autoplay, and live demo have some weird behavior.
demo: https://stackblitz.com/edit/ng-zorro-antd-setup-tpsmmo
Other?

自动轮播，从最后一条滚到到第一条，目前是直接从最后一条往上滚动到第一条，希望能支持直接往下滚动至第一条

@shhdgit https://stackblitz.com/edit/ng-zorro-antd-setup-1jw6mk?file=app/app.component.html works fine now.

@vthinkxie Thanks.


Poetry Lock seems to have some git merging artifacts which makes it unreadable.

https://github.com/NeuroBench/neurobench/blob/375e67cbfa7a7ccae919d2cd8e86b85645a555c9/poetry.lock#L2729C1-L2749C12

Additionally, poetry.toml references README.md instead of the current README.rst, which create the following issue:
The current project could not be installed: [Errno 2] No such file or directory: '...\\neurobench\\README.md'
(https://github.com/NeuroBench/neurobench/blob/375e67cbfa7a7ccae919d2cd8e86b85645a555c9/pyproject.toml#L6C1-L6C21)

Looks like the README issue is fixed but there is still the merge artifacts which mess up the poetry.lock, not cleared yet

Fixed e275f5c299cdb2ffd9f96c8d97565be816970615


Renamed "Mac OS X" to "macOS" in docs.

Apples operating system has been rebranded to macOS since Sierra; the Django documentation identified it as Mac OS X, OS X or even Mac OSX. This trivial PR harmonizes that and uses macOS everywhere.
See also https://meta.stackoverflow.com/questions/348077/rename-osx-to-macos?cb=1

I applied your suggestions!


SA1201 code fix needs to be executed multiple times

Sample Code / Steps to reproduce
Consider the following example:
namespace ClassLibrary1
{
    public class Class1
    {
        public void Method1()
        {
        }

        public static string Property1 { get; }

        public string Property2 { get; }

        public void Method2()
        {
        }

        public string Property3 { get; }
    }
}

This yields:

Warning	SA1201	A property should not follow a method.

for Property1 and Property3, no warning is generated for Property2.
First application of the code fix
When attempting to apply the Fix Element Order code fix for the entire document, the code is fixed as such:
namespace ClassLibrary1
{
    public class Class1
    {
        public static string Property1 { get; }

        public void Method1()
        {
        }

        public string Property2 { get; }

        public string Property3 { get; }

        public void Method2()
        {
        }
    }
}

This is not a complete fix, as Property2 and Property3 are out of order. StyleCop still generates the following warning:

Warning	SA1201	A property should not follow a method.

Second application of the code fix
When attempting to apply the Fix Element Order code fix for the entire document for a second time, the code is fixed as such:
namespace ClassLibrary1
{
    public class Class1
    {
        public static string Property1 { get; }

        public string Property2 { get; }

        public void Method1()
        {
        }

        public string Property3 { get; }

        public void Method2()
        {
        }
    }
}

This is not a complete fix, as Property3 is still out of order. StyleCop still generates the following warning:

Warning	SA1201	A property should not follow a method.

Third application of the code fix
Applying the code fix one more time finally fixes the code:
namespace ClassLibrary1
{
    public class Class1
    {
        public static string Property1 { get; }

        public string Property2 { get; }

        public string Property3 { get; }

        public void Method1()
        {
        }

        public void Method2()
        {
        }
    }
}

Impact
I'm taking ownership of an existing code base and attempting to get it StyleCop compliant. There's a large number of SA1201 warnings. If you apply the SA1201 code fix, but the number of StyleCop warnings does not decrease, it looks like the fix did not work.
Because this fix moves code from one region of the source file to another, it's also more difficult to ensure the fix worked correctly -- so getting feedback in the result of a warning decrease would be more efficient.
Classic StyleCop
PS: Classic StyleCop generates different warnings in this case; classic StyleCop would generate warnings for Method1 and Method2:

Warning		SA1201 : CSharp.Ordering : All methods must be placed after all properties.

This is really annoying. I think we should fix that before rc1.

@pdelvo RC 1 is Monday and I'm not planning to work on this myself, but if someone else fixes it and it's code reviewed in time then we could include it.

Oh wow. This really just got raised and forgotten about for 8 years. Is this even still a problem?
If it is still a problem it should be possible to reorder the whole class if a problem is found. Instead of reordering only the single occurrence of the problem the code fix provider should treat the whole file as "dirty" and reorder it


Downloads directory internationalization

What version of WebTorrent Desktop? (See the 'About WebTorrent' menu)
0.3.3
What operating system and version?
Ubuntu 14.04 LTS
I'm italian and with italian settings the default directory to downloads files is "Scaricati" and not "Downloads".
If you want to start download in a default directory I think that you have to support internationalization...

This issue was fixed in #382, will be included in the next release.


Always respect private cache dir, and refactor some var names

Respect private cache dir. Add checking when reuse cache data. The rule is: when the cached dataset located inside the specified private cache dir, then reuse it, otherwise do not reuse it, instead, materialized dataframe again to the specified private cache dir.

Refactor some var names

add two util method _normalize_dir_url and _is_same_or_sub_url, and do some refactor.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@be4bba5). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master      #15   +/-   ##
=========================================
  Coverage          ?   85.95%
=========================================
  Files             ?       80
  Lines             ?     4287
  Branches          ?      675
=========================================
  Hits              ?     3685
  Misses            ?      497
  Partials          ?      105

Impacted Files
Coverage Δ

petastorm/spark/spark_dataset_converter.py
93.75% <100%> (ø)

Continue to review full report at Codecov.

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


Option to disable the @sveltejs/package warning about import.meta.env in the code

Describe the problem
I'm using Vite + Svelte + @sveltejs/package to package Svelte components for my Svelte apps. One of the components needs to access window and therefore needs to check !import.meta.env.SSR to verify it is running on browser.
I'm not using SvelteKit because I don't need SSR.
The problem is, each time @sveltejs/package packages the component, it shows the warning:
Avoid usage of `import.meta.env` in your code. It requires a bundler to work. Consider using packages like `esm-env` instead which provide cross-bundler-compatible environment variables.
Even though I'm actually using Vite as the bundler, and my Svelte apps are also using Vite. i.e. I would always use Vite for Svelte projects.
I noticed the warning was introduced in https://github.com/sveltejs/kit/pull/8922.
Describe the proposed solution
Allow disabling the warning by adding comment above the line that uses import.meta.env.SSR.
For example,
// @sveltejs/package-disable-warning
const isBrowser = !import.meta.env.SSR;

Alternatives considered
Before I realized I don't need SSR and SvelteKit, the component library actually used SvelteKit and $app/environment to check if it is running on browser. But I noticed the packaged component kept $app/environment and therefore would limit my app that uses the component to also use SvelteKit.
I have also tried using Vite's build command with its library mode but failed to figure out how to build Svelte components. I would be pleased if anyone could enlighten me to build Svelte component without @sveltejs/package.
Importance
nice to have
Additional Information
No response

I guess we could remove this only when you have private: true set in your package.json. Though even then I'm not entirely sure we should because we can't know if an internally created package might be consumed by other bundlers. Why don't you just use esm-env as the warning suggests?

I also noticed that the warning isn't quite accurate. I sent a PR to update it: https://github.com/sveltejs/kit/pull/11440

I guess we could remove this only when you have private: true set in your package.json. Though even then I'm not entirely sure we should because we can't know if an internally created package might be consumed by other bundlers. Is there a reason you don't just use esm-env as the warning suggests?

The idea of making it an option is to let package creators decide whether the warning is necessary. In my case, I am sure my packages will be consumed by Vite, because I only publish it in our internal registry for our Vite projects. Therefore I would like to disable the warning in my packages.
I don't use esm-env mainly because I don't know how it works. Installing another package for the same purpose that Vite already provides seems overkill to me. Or if you can explain to me that it doesn't increase build size and affect runtime performance, I will consider that.

Adding options is always a last resort, and it would be particularly unfortunate to add an option for this.

Or if you can explain to me that it doesn't increase build size and affect runtime performance, I will consider that.

Use the source — it will not increase build size, nor will it affect runtime performance. It will work in every project setup, and autocompletes more easily than import.meta.env. It's better in every respect.


Translate README in Italian

Add the README file in Italian language

/assign @fabriziopandini

/language it
/uncc
(I don't speak Italian!)

@Fale do you have someone from the Italian localization team who can give this formal / informal approval?

Hi @sftim, thanks.
Fabrizio told me to assign this ticket to him so that he can do the validation for the language.

I'll also
/cc @fabriziopandini

Hi @fabriziopandini
thanks a lot for your comments. I think I closed all of them except one which is not clear what is suggestion.
As for the style guide, I do agree that we need to write one so that all translations are homogeneous.

/assign @jimangel

Approved by @fabriziopandini as Italian reviewer/approver
/approve
/unassign @jimangel


"Save" button cannot be clicked

In the panel that opens when the toolbar icon is clicked, the button to save the strictness level cannot be clicked, however it can be navigated to with the keyboard. Any idea why?

Getting this as well. The option panel when in chrome://extensions is totally unresponsive too.

Thanks for reporting!

This has been fixed in the v0.0.2 update, you should see it pushed to your browser within the next hour.


Please invite me to the GitHub Community Organization

Please invite me to the GitHub Community Organisation.

Name: Oreoluwa James

Discord Username(if exists):

Additional Context:

I saw Eddie's video for FreeCodeCamp and I'm hoping to get into Open Source actively.
:nerd_face:

Invitation sent for the GitHub Organisation. Welcome to the community 🎉
Don't forget after accepting to make it public so it appears on your GitHub profile for everyone else to see, you can do this by finding your name in the GitHub organisation list and change the dropdown to public https://github.com/orgs/EddieJaoudeCommunity/people
Tips for practising:
Customise your GitHub profile, here is a live stream on it https://www.youtube.com/watch?v=cT6GXCuS0Zo
Practice repo, instructions on how to add your name to the README in the README https://github.com/EddieJaoudeCommunity/hacktoberfest-practice
Remember contributing to open source is not just about code, its about collaboration, communication and adding value
I hope that helps

Invitation sent for the GitHub Organisation. Welcome to the community 🎉
Don't forget after accepting to make it public so it appears on your GitHub profile for everyone else to see, you can do this by finding your name in the GitHub organisation list and change the dropdown to public https://github.com/orgs/EddieJaoudeCommunity/people
Tips for practising:
Customise your GitHub profile, here is a live stream on it https://www.youtube.com/watch?v=cT6GXCuS0Zo
Practice repo, instructions on how to add your name to the README in the README https://github.com/EddieJaoudeCommunity/hacktoberfest-practice
Remember contributing to open source is not just about code, its about collaboration, communication and adding value
I hope that helps


Incentives: Storing/ serving heartbeat transactions, synthetic transactions for payouts

Summary
Add support for storing and serving heartbeat transaction types. Generate a synthetic payout transaction (in underlying indexer txn table) to make inclusion of payouts in balances trackable by external users.
Test Plan
New tests were added for heartbeats as well as the synthetic payout.

It seems ok now. But I suppose you will wait to get the new HeartbeatTxnFields in? Or do that separately?

I'm leaving as draft until your branch gets merged to master, will add the new fields once the crypto PR merges.


handle different kinds of releases

currently only supporting minor updates. Need to also support:

patch releases
major releases
as well as minor releases.

Will need to change:

Branch name: https://github.com/cguertin14/k3supdater/blob/main/pkg/updater/operations.go#L165
PR title: https://github.com/cguertin14/k3supdater/blob/main/pkg/updater/operations.go#L224


Possible mem leak in tf.random.categorical

Please make sure that this is a bug. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:bug_template
System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):Ubuntu 16.04
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:No
TensorFlow installed from (source or binary):binary
TensorFlow version (use command below):2.0.0
Python version:3.6.9
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version:10.0.130
GPU model and memory:1060  6G

You can collect some of this information using our environment capture
script
You can also obtain the TensorFlow version with: 1. TF 1.0: python -c "import tensorflow as tf; print(tf.GIT_VERSION, tf.VERSION)" 2. TF 2.0: python -c "import tensorflow as tf; print(tf.version.GIT_VERSION, tf.version.VERSION)"
Describe the current behavior
If I set seed, the memory keeps increasing between loops.But if I remove seed, the memory will remains the same.
Describe the expected behavior
Whether I set random seed or not，the memory will remains the same.
Code to reproduce the issue
Provide a reproducible test case that is the bare minimum necessary to generate the problem.
import tensorflow as tf
import numpy as np
import tensorflow_probability as tfp
import psutil
import os

if __name__ == '__main__':
    act_dim = 8

    model = tf.keras.Sequential([tf.keras.layers.Input(500, ),
                                 tf.keras.layers.Dense(500, activation="relu"),
                                 tf.keras.layers.Dense(act_dim, activation="softmax")])

    tf.random.set_seed(0)
    print("memory used:", psutil.Process(os.getpid()).memory_info().rss)

    for j in range(100):
        for i in range(1000):
            x = np.random.rand(500, 500)
            prob = model(x)

            dist = tfp.distributions.Categorical(probs=prob)
            a = dist.sample()
        print("memory used:", psutil.Process(os.getpid()).memory_info().rss)

Other info / logs
Include any logs or source code that would be helpful to diagnose the problem. If including tracebacks, please include the full traceback. Large logs and files should be attached.

I'm having a similar issue for some Reinforcement Learning code where the issue is more pronounced. If I set a seed and then train an agent which samples actions randomly at each time step the memory leak becomes very pronounced.
ystem information
Have I written custom code (as opposed to using a stock example script provided in TensorFlow):Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):Ubuntu 18.04
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:No
TensorFlow installed from (source or binary):binary
TensorFlow version (use command below):2.0.0 (also verified on 2.1.0)
Python version:3.7.5
Bazel version (if compiling from source): N/A
GCC/Compiler version (if compiling from source): N/A
CUDA/cuDNN version: N/A
GPU model and memory: N/A

I believe this may be caused by caching which convert_to_eager_tensor performs. Notably look at https://github.com/tensorflow/tensorflow/blob/7072568ed6b735e347fb87bc84a2b83daf806e3f/tensorflow/python/framework/constant_op.py#L68-L72 which mentions that some values can be cached.
In the C++ code, https://github.com/tensorflow/tensorflow/blob/7072568ed6b735e347fb87bc84a2b83daf806e3f/tensorflow/python/eager/pywrap_tensor.cc#L307-L313 performs the caching -- currently for Python scalars only.
When a seed is set, it causes operation seeds to be generated by random.Random generator, which are probably then converted to eager tensors -- and the problem arises.

@feidieufo ,
Can you please take a look at this comment and try in latest stable version v2.7 and let us know if the issue still persists.Thanks


Rebuild 4.9.2

I'm running into version conflicts with the current package with is 3 years old now, and predates current versions of Python.
Also I see the 4.9.3 pull request failed with make being missing.

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found some lint.
Here's what I've got...
For recipe/meta.yaml:

❌ This recipe is using a compiler, which now requires adding a build dependence on {{ stdlib("c") }} as well. Note that this rule applies to each output of the recipe using a compiler. For further details, please see https://github.com/conda-forge/conda-forge.github.io/issues/2102.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

Something is messed up, nothing provides requested c_linux-64 and nothing provides requested c_osx-64

It was missing a re-render! :)

Progress,
/bin/sh ../libtool --silent  --tag=CC   --mode=compile x86_64-apple-darwin13.4.0-clang -DHAVE_CONFIG_H -I.   -D_FORTIFY_SOURCE=2 -isystem $PREFIX/include -mmacosx-version-min=10.13 -mmacosx-version-min=10.13  -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fstack-protector-strong -O2 -pipe -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/lftp-4.9.2 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix -I$PREFIX/include -Wall -c -o basename-lgpl.lo basename-lgpl.c
In file included from basename-lgpl.c:19:
./config.h:2540:11: fatal error: 'trio.h' file not found
In file included from  2540 | # include "trio.h"
      |           ^~~~~~~~
argmatch.c:22:
./config.h:2540:11: fatal error: 'trio.h' file not found
 2540 | # include "trio.h"
      |           ^~~~~~~~
1 error generated.
make[4]: *** [Makefile:2326: basename-lgpl.lo] Error 1

Closed in favour of #22.


Add regex for docker version 1.10 image format

This PR is a fix for issue #85
Now it should work with older and newer docker version.
@keis also suggested this.

Can confirm this PR fixed issue #85
Tested and works on:
acehege@acehege:/tmp$ sudo docker --version
Docker version 1.11.2-cs3, build c81a77d

thanks!


Express version 5 minimum Node version

Hi Expres Team 👋
I was checking the code on the branch v5.0 and for my surprise, I saw that the minimum version is >= 4, is there any reason for not getting something major?
Is there a plan to reach the community (a survey maybe?) asking for feedback about some crucial not only about what should be the focus next but also things like "Target the minimum Node version" to something newer which will potentially remove lots of code?
I know that everything can be improved but we shouldn't seek perfection to enable everyone to update their apps without major breaking changes, but I guess some tweaks here and there will be a nice touch.
Honestly, I can't wait for the next big release, so I'm just playing around with side projects and waiting for it.
Keep up the fantastic job.
Cheers.

Hello, and thanks for opening this issue 😀 . Yes, we already gathered community feedback in the currently open issue regarding this and the plan is the min Node.js version will be set to whatever the Node.js LTS is at the time. I hope this helps! I'm just closing it mainly to just close out duplicates is all. You're welcome to add anything else or if you feel that is not a good solution, we can continue to conversation.


Crashes Refactor

i might have messed up rebase

oh hey i didnt mess it up nice

Well that's stupid, if I change the source branch's name it counts it as deleted...


Retry without stored setup if auth fails with config.matrixServer

Fixes #1456
Short description
Even if config.matrixServer is passed (currently done in dApp in testenv001), and stored server setup (auth) matches passed config, append a 2nd server option with same server but without setup to retry auth if stored one fails.
Steps to manually test the change (dApp)

Try connecting on testenv setup in a dApp with an auth error

The linked issue contains a very specific state, which I don't understand how it happened, where stored auth info would cause http errors. This PR solves it by ensuring even with specified config.matrixServer, the auth is retried once without stored setup if it fails, which will re-login and fix that issue.
The test steps are as descriptive as I could: if you see that issue, test it there.


issue with android 7.0

since android 7.0, file:// scheme is now not allowed to be attached with Intent on targetSdkVersion 24 (Android Nougat). so we should send the URI through content:// scheme instead which is the URI scheme for Content Provider. how can we obtain file uri from the content:// uri and pass to cropImage Activity Builder???

I'm not sure what doesn't work.
Uri.fromFile API is not deprecated and running find in an emulator...
I just tested the library sample and quick-start on 7.1.1 emulator and everything works fine...

When i try to pass the content:// uri to cropImage.activity(uri) nothing happens(CropActivity is not launching).I can log the uri in onActivityResult(), i don't know what the issue is.

can you provide code snippet so I can reproduce the issue?

private Uri mImageCaptureUri;
private static final int PICK_FROM_CAMERA = 1;

// function to open camera application
 if (Build.VERSION.SDK_INT >= 24) {
      File file=newFile(Environment.getExternalStorageDirectory(),""+String.valueOf(System.currentTimeMillis()) + ".jpg");             mImageCaptureUri=FileProvider.getUriForFile(this,BuildConfig.APPLICATION_ID+".provider", file);
                    intent.putExtra(android.provider.MediaStore.EXTRA_OUTPUT, mImageCaptureUri);
                    try {
                        startActivityForResult(intent, PICK_FROM_CAMERA);
                    } catch (ActivityNotFoundException e) {
                        e.printStackTrace();
                    }
                }

//onActivityResult
@Override
    protected void onActivityResult(int reqCode, int resultCode, Intent data) {
        super.onActivityResult(reqCode, resultCode, data);
        switch (reqCode) {
case PICK_FROM_CAMERA:
                    if (resultCode == RESULT_OK) {
                    if (Build.VERSION.SDK_INT >= 24) {
                        CropImage.activity(Uri.parse(mCurrentPhotoPath))
                                .setGuidelines(CropImageView.Guidelines.ON)
                                .setActivityTitle("Crop Image")
                                .setFixAspectRatio(true)
                                .setBorderLineThickness(2.0f)
                                .setBorderLineColor(getResources().getColor(R.color.colorPrimary))
                                .start(this);
                    }

                }
                break;

}

The Crop Image Activity is not launcing as expected. it was working fine below android N.

Looks like you are passing mCurrentPhotoPath to CropImage.activity but I don't see how you create it.
Seems like you should use mImageCaptureUri that is used for the camera intent.
Do you check if you get an error result?

Nevermind it's working now, it seems like  i misconfigured the File Provider Path.


Load comments immediately for a given game.

http://lifein19x19.com/forum/viewtopic.php?p=202978#p202978
From UberDude:
So the reason I couldn't see comments is because I followed the link, and then held down my right arrow key to whiz through the game and no comments appeared as the stones appeared on the board. That's because the comments are loaded asynchronously by ajax and take a long time to appear, by which time you've moved on to the next move (so you get loads of js errors). I suggest the developer stores a list of the moves with comments on first load (edit: it already has this as on move 0 it lists the moves with comments) so that when you whiz through it knows to display a "Loading comment" message on relevant moves (and not to issue the ajax request for comments immediately on moves the cache suggests have no comments (but have a small chance to have been commented since initial page load)), but wait a short time to reduce the request spam which is presumably why it is a lot slower to load comments after whizzing through moves that if you directly navigate to one with a fresh page request.
My thoughts:
Can provide the most recent comment hash, and if it doesn't match the server, the server can return an updated list of comments, otherwise, no need to send any additional data back and forth from the initial load?

It's definitely possible to load all the comments in advance, and I think I'm going to do that in an upcoming refactor. The reason I didn't initially is that it's simpler from an architectural perspective not to have a copy of all the comments on a game maintained in the browser that then needs to get updated whenever another user adds comments to the game elsewhere. Every move is its own thread; just fetch that thread when needed. It also helped keep AJAX calls quick even when games had a lot of comments.
But UberDude's suggestion of just keeping track of which moves have comments so that it can display an obvious loading message is a good way of dealing with that issue.
Anyway -- this will be something I try to address in the future.

this seems to converge with issue #120 , maybe only one needs to be up. I think it's a very important feature, I currently miss many comments (or otherwise force myself to browse the games very slowly) when browsing games due to this.

I'd like to bump this. :)
Loading all the comments in bulk when opening a game shouldn't pose any performance issues and should make comments to display instantaneously, I think?

I'm afraid that development on GoKibitz is effectively pinned right now. Dependencies are so out of date that it's pretty much impossible to make changes.


Remove leading line character from export file

Same as #41 from Salomon for Linux.

This issue has become obsolete as the code regarding the leading line character has been revised with #15.

This issue has become obsolete as the code regarding the leading line character has been revised with #15.

Fixed in version 1.18.2.

Fixed in version 1.18.2.


fixing doc example so it passes tests on ubuntu

There isn't a CI test for ubuntu, but they should pass locally.
It failed on compile, so the no_run wasn't doing anything helpful.
Just added a main as suggested by the rust docs:
https://doc.rust-lang.org/stable/rustdoc/write-documentation/documentation-tests.html#using--in-doc-tests
And added "use" for missing dependencies.

@complexspaces

Hey there, thanks for the PR and my apologies for taking so long to respond.
While I think that its great to make the doctest compile successfully, we need to keep the no_run annotation. This is because the clipboard is a global resource on every OS: Any instance of arboard::Clipboard can mess with another. If it was removed, the other tests in the crate would be able to encounter a race condition with this test (depending on when they are run). The other unit tests in arboard carefully serialize everything to avoid the problem.


📝 Document the new default for autoversion.create_tags

Fixes #56.
See also fd072540fc where this default was updated.

ping @athompson-r7 and @jmanero-r7

Sorry @erran. Looks good 👍

Can you rebase this back up to master?

@jmanero-r7 sure!

Can you rebase this back up to master?

@jmanero-r7 Pushed with 5a2ad26.


Add support for using tmux panes for focusing rather than windows

Autoswap to tmux pane with the file open. (works for any window/pane in the same tmux session)
I haven't tested it on OSX nor with gvim, but tmux 1.9 with vim 7.4.273 works great.
Might need to make AS_DetectActiveWindow_Tmux a little clearer and AS_RunningTmux a bit more robust. But works for me.

As far as multiple tmux sessions in different terminals, it's definitely possible but not in my workflow. I will take a crack at it a bit later this week. Just want to make sure I am on the right track (this is my first real foray into vimscript).
I broke the subshells into different variables as suggested, definitely makes it a bit more readable. Thanks for the suggestion -- unfortunately it was hard to strip the trailing newline from the system return values, if you have thoughts on that front I would appreciate it. (http://vi.stackexchange.com/questions/2867/how-do-you-chomp-a-string-in-vim has one of the methods I went with -- although it seems it may not work cleanly on osx/windows).

Hi @lutostag, I have merged your PR and added an additional configuration option in the lutostag-tmux branch, could you please try it out and see if it works fine in your tmux setup?

Works for me, with one extra change (also check that the g:autoswap_detect_tmux is set to one before switching windows -- although may be a bit cleaner to have that check in AS_RunningTmux instead, up to you). Change in https://github.com/lutostag/vim-autoswap/tree/lutostag-tmux. Thanks for being an awesome maintainer. Love it!


RedactedKeys don't apply to stringified POST body

Describe the bug
The redactedKeys array doesn't get applied to the body in the event metaData when the body is a stringified JSON object.
Steps to reproduce
This is going to be largely determined by the project implementation.

use the default redactedKeys ( which includes "password" ) for the bugsnag implementation
add all event metaData to the bugsnag event on the notify call.: event.addMetadata("additional info", metaData);
trigger a server-side POST error that contains a post body that includes a redacted key.
console.log out the event before Bugsnag.notify is called.
ensure POST body data in the metaData is being stringified
check corresponding event in bugsnag to see the POST data not being filtered.

Environment

Bugsnag version: 7.10.1
Browser framework version (if any): React
Server framework version (if any): Express
Browser version (e.g. chrome, safari): Chrome
Device (e.g. iphonex): Desktop browser

Example code snippet
const { error, errorCode, message, metaData } = errorData;
console.log("🚀 ~ file: clientLogger.tsx ~ line 98 ~ errorData", errorData);
Bugsnag.notify(error, event => {
       if (metaData) { event.addMetadata("additional info", metaData); }
});

The console.log above is the raw data being sent through the bugsnag PRIOR to any filtering. As you can see though the body in the metaData is a stringified object.
The equivalent bugsnag event is below:

My assumption here is that the redactedKeys isn't getting applied / matched because the POST body is a stringified object.
I believe that bugsnag should first try to JSON.parse the body and then try to apply its filtering.

For some more context, our client side app has an API middleware that catches 5xx HTTP response codes from the API server. If the server responds with an error, we capture this and log an error to bugsnag.

Hi @tims-j,
If the metadata is added as a JSON string Bugsnag will not find any matching keys for redaction. You would need to add this as a JSON object.

I believe that bugsnag should first try to JSON.parse the body and then try to apply its filtering.

This would effectively require a call to JSON.parse for every string metadata property in an event in order to check if it is valid JSON, which would have a serious performance impact.
If you know that your metadata is likely to contain sensitive information we'd recommend calling JSON.parse before adding it to an event.
I'm closing this issue out but please feel free to write in to us at<EMAIL_ADDRESS>if you have any specific questions.


Fix NameError when unsupported UUID type is passed to primitive factory

Hi,
This is just a small bug, so I've not raised an issue for it - hope that's ok. This change fixes the error shown in the stack trace below so that the correct exception is raised.
Fix is just to use the correct variable name, and  I added a test to verify the fix.
  File "C:\Program Files (x86)\Python 3.5\lib\site-packages\pyswagger\primitives\comm.py", line 40, in _2nd_pass_obj
    return ret.apply_with(obj, val, ctx)
  File "C:\Program Files (x86)\Python 3.5\lib\site-packages\pyswagger\primitives\_uuid.py", line 33, in apply_with
    raise ValueError('Unrecognized type for UUID: ' + str(type(v)))
NameError: name 'v' is not defined

Changes Unknown when pulling 4a3c523a1d0035630197609600a0d8e940fe184e on olipratt:uuiderror into ** on mission-liao:master**.

Thanks for this PR, :). I'll find some time to compose another build for it.

Great - thanks. No hurry for a new build from me - this was just something I hit by accident and isn't causing me any problems now.


Return early in _nvapi_disable_threaded_optimization to avoid crash after renderdoc attach

A workaround, should fix #84880 when nvidia_disable_threaded_optimization is disabled in project setting ( although the root cause is still not solved ) . And this change should probably be there at the first place, it will sightly increase start up time if the user did not want to disable nv's optimization, it's a double win anyway.
cc @EIREXE You might want to take a look.

I'd suggest doing the change from #85012 in this commit, so we reduce the PR backlog a bit.

Is it crashing in the NvAPI_DRS_CreateSession, or NvAPI_DRS_CreateSession is overridden by RenderDoc and is null? Maybe it's enough to add check if NVAPI function pointers are valid.

Is it crashing in the NvAPI_DRS_CreateSession, or NvAPI_DRS_CreateSession is overridden by RenderDoc and is null?

I will test and try.

lgtmi

Thanks!

Cherry-picked for 4.1.4.


[Bug] [Docker] Standardalone overwrite the env variables partionally

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
docker run with an .env file
docker run -it  --env-file .env apache/dolphinscheduler-standalone-server

and my .env:
DATABASE=postgresql
SPRING_DATASOURCE_URL=jdbc:postgresql://<IP_ADDRESS>:5432/dolphinscheduler
SPRING_DATASOURCE_USERNAME=dolphinscheduler
SPRING_DATASOURCE_PASSWORD=dolphinscheduler
SPRING_JACKSON_TIME_ZONE=UTC

but faild end:
java.lang.RuntimeException: Driver org.h2.Driver claims to not accept jdbcUrl, jdbc:postgresql://<IP_ADDRESS>:5432/dolphinscheduler
	at com.zaxxer.hikari.util.DriverDataSource.<init>(DriverDataSource.java:110)
	at com.zaxxer.hikari.pool.PoolBase.initializeDataSource(PoolBase.java:331)
	at com.zaxxer.hikari.pool.PoolBase.<init>(PoolBase.java:114)

rolling from the front log and find this line:
[WI-0][TI-0] - 2024-10-13 06:50:11.569 INFO  [main] o.a.d.StandaloneServer:[640] - The following 1 profile is active: "h2"

from the code application.yaml  line 18:
spring:
  profiles:
    active: h2
  jackson:
    time-zone: UTC
    date-format: "yyyy-MM-dd HH:mm:ss"
  banner:
    charset: UTF-8
    location: classpath:standalone-banner.txt
  sql:
    init:
      schema-locations: classpath:sql/dolphinscheduler_h2.sql
  datasource:
      driver-class-name: org.h2.Driver
      url: jdbc:h2:mem:dolphinscheduler;MODE=MySQL;DB_CLOSE_DELAY=-1;DATABASE_TO_LOWER=true
      username: sa
      password: ""

seems that profile still use h2 but some how the url, username and password had been replaced by my .env file.
What you expected to happen
the active profile should be replace by postgresql as the environment variable DATABSE=postgresql, or say,
# Override by profile
---
spring:
  config:
    activate:
      on-profile: postgresql
  quartz:
    properties:
      org.quartz.jobStore.driverDelegateClass: org.quartz.impl.jdbcjobstore.PostgreSQLDelegate
  datasource:
    driver-class-name: org.postgresql.Driver
    url: jdbc:postgresql://<IP_ADDRESS>:5432/dolphinscheduler
    username: root
    password: root

also in application.yaml line 293.
How to reproduce
as my description.
Anything else
and I've tested that if I just replaced
  profiles:
    active: h2
    .....

into:
  profiles:
    active: postgresql
    ......

from dolhpinscheuler-master/src.../application.yml
everything going well. no error! :)

by the way, why I do this because I just want  want to do some test but each time I modified something and re-run the docker the flows, users and datasources are gone.  My request is just need a standalone version and mount out the volumes, storage persistence, but I had never used h2.  Well I don't know Java neither.
Version
3.2.x
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

You should add SPRING_PROFILES_ACTIVE=postgresql to env.


Update sync_org.sh to provide commands to dump the org.

Add greynutw, yuzisun, and joeliedtke. THey were already added to the
org but not the YAML file.

This change is

/assign @abhi-g

/lgtm
/approve


docs: args don't seem to show up properly

E.g. see https://docs.dask.org/en/latest/dataframe-api.html#dask.dataframe.read_parquet
You see things like pathstring or list. Believe it should be path: string or list

Thanks for raising this @raybellwaves .
This came up before I think, and was maybe resolved by tweaking which numpydoc version we used?  cc @gforsyth , who maybe helped us to resolve this last time?

Got it.  Fixes incoming

Well, corporate proxy is blocking image uploads, but I have the colons restored via a fix to the dask-sphinx-theme and PRs in to pull in that change once the fix PR is merged and a new release is cut.

Yep. Thanks

Woot. Thanks everyone!

Am I right that is happening again?
https://docs.dask.org/en/stable/dataframe-api.html#dask.dataframe.read_parquet

Am I right that is happening again?

Yep.  Curses

Closing this, since it's currently fixed.


All operators should be parameterized for more general cases.

Current approach are not suitable for more general algebras:

Lattice consists of two semigroups, their operators have very similiar properties to each other and should not be assumed as additive-like nor multiplicative-like.

Tensor product of modules consists of several different product-like operators, so I think all operators should be parameterized rather than be concrete instances.

A better approach might be letting all operators be parameterized through generics.
For example:
pub trait Ring<Additive:Op, Multiplicative:Op>
    : RingApprox<Additive, Multiplicative>
    + GroupAbelian<Additive>
+ Monoid<Multiplicative>

instead of
pub trait Ring
    : RingApprox
    + GroupAbelian<Additive>
+ Monoid<Multiplicative>

Hmm.. Yeah that makes sense. I am not actually sure how much this library will be developed as https://github.com/sebcrozet/alga has been developed more.
As you might have noticed development of both has been pretty slow...

For what it's worth,the approach proposed here is actually the one implemented on alga!


documentation functions are static functions but when i use it raises error can't use as static

when i write :
use PragmaRX\Tracker\Tracker;
$visitor = Tracker::currentSession();
raises error: Non-static method PragmaRX\Tracker\Tracker::currentSession() should not be called statically, assuming $this from incompatible context
how can i use it ?

I have the exact same problem.. Searched no whole internet but with no result. Can someone please help with this?

You have imported the class here:
use PragmaRX\Tracker\Tracker;
while, you need to import the facade like:
use PragmaRX\Tracker\Vendor\Laravel\Facade as Tracker;


bug：Catching exceptions and printing exception information

handle method of sqlTask.java class, suggest try module to catch exceptions, print exception log. Otherwise, the cause of the exception is unknown. For example, the database driver jar does not exist.

Codecov Report

Merging #1457 into dev will decrease coverage by <.01%.
The diff coverage is 0%.

@@           Coverage Diff            @@
##             dev   #1457      +/-   ##
========================================
- Coverage   0.22%   0.22%   -0.01%
========================================
  Files        271     271
  Lines      13591   13594       +3
  Branches    2158    2158
========================================
  Hits          31      31
- Misses     13550   13553       +3
  Partials      10      10

Impacted Files
Coverage Δ

...lphinscheduler/server/worker/task/sql/SqlTask.java
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

the last commit was to fix getting the project name bug