code 1.84.1
radeon RX 6600 (oss driver)
custom menubar
vscode --enable-features=WaylandWindowDecorations --disable-features=WaylandOverlayDelegation --ozone-platform-hint=auto
first instance working, second instance crashes both (segfault)

For me, after installing v1.84.1, I can now get "window.titleBarStyle": "native" to work on Wayland (including multiple windows maximised), if I also pass the flag --disable-gpu-sandbox.

GNOME users:: is it possible that the following silly workaround works for you?

Super + Left or Rigth Arrow (to send the second, freshly created window along the left / right side
Super + Up Arrow (to maxmize it)
?

I just tried with the latest visual-studio-code-bin 1.84.1-1 on Arch and the issue persists.
I am using a Ryzen 7k platform with an integrated GPU, quite a simple setup.
The configuration I tested:
--ozone-platform-hint=auto

--ozone-platform-hint=auto --disable-features=WaylandOverlayDelegation

--ozone-platform-hint=auto --disable-features=WaylandOverlayDelegation --disable-gpu-sandbox

All of them tested with native or custom window.titleBarStyle configuration.
All those permutations just fire the segfault.

I can confirm that the situation has somewhat improved on Arch Linux. Not sure if that happened after VSCode's or another package's upgrade.
When I open a second window and interact with it (i.e. Super + Left Arrow), VSCode instantly crashes.
But then when I launch VSCode again, two windows are opened, and I can use both windows just fine. From then on, there seems to be no more crash.
My ~/.config/code-flags.conf:
--enable-features=UseOzonePlatform,WaylandWindowDecorations
--ozone-platform=wayland

GNOME users:: is it possible that the following silly workaround works for you?
1. Super + Left or Right Arrow (to send the second, freshly created window along the left / right side

2. Super + Up Arrow (to maximize it)

gnome user here (Linux Mint, Radeon integrated GPU, 1.85.0-insider)
when I have two non-maximized windows open, or if I maximized / docked the first window and opened the second window as floating.
then Super+Left/Right immediately crashes vscode, same as maximize, same as using the mouse to drag + dock the window to the side (or maximized)
for the record, opening a workspace that is remembered as maximized will work fine on its own but crash if opened in the second window.

I've been looking at this issue periodically to try to figure out a good angle to attack it from. None of the workarounds do anything for me, and I think it would be best to just fix the issue.
I already knew what version VS Code stopped working correctly for me; it was 1.78.0, whereas I was previously running 1.77.3. I downgraded to 1.77.3 where I am now, but unfortunately this leaves some extensions, that would be nice to have, broken, as they are unwilling to start on this now-old version.
Unfortunately, this doesn't narrow things down much. VS Code 1.77.3 reports that it is running on "Electron 19.1.11", a version of Electron that doesn't even exist. Meanwhile,1.78.0 reports "Electron 22.4.8", a leap of several major versions. Can we go narrower?
It turns out that getting VS Code started enough to repro the issue doesn't require the native module NAPI versions to match, so it turns out it doesn't take that much effort to go narrower. But first, I wanted to know if I could definitively say that Electron was the issue here, and that the VS Code version didn't matter. I am using Nix/NixOS so I wrote a Nix flake that lets me test this. Indeed. If I ran vscode 1.77.3 in vscode 1.78.0's electron shell, suddenly, it started to break on new window creation. And if I ran vscode 1.78.0 in vscode 1.77.3's electron shell, it did not. Obviously, the app will not entirely work this way, for a variety of reasons, but it at least helps confirm this line of thinking.
Last night, I started working out how to narrow things down further. VSCode starts enough inside of a plain upstream Electron binary to allow us to repro the issue, so we can test using any of those. I extended my Nix flake and was able to narrow it down to having been broken between 21.4.4 and 22.0.0. (If anyone wants to follow along, you'll need the Nix package manager and this flake. Plop it in a new empty folder and run e.g. NIXPKGS_ALLOW_INSECURE=1 NIXPKGS_ALLOW_UNFREE=1 nix run --impure .\#vscode_1_77_3_in_electron_22_0_0.  But, I wasn't trying to make something elegant. After it starts, create enough new windows and it should explode.)
Unfortunately, being a major version gap, this does mean that there's probably quite a lot of changes to scale. However, it does give a potential basis for doing a proper bisect, since we can just run the compiled 1.77.3 on each Electron version. So tonight, I'm going to try to figure out if I can reasonably rig a setup for building Electron and see just how many bisect steps it would take to narrow it down to a specific commit. I'm expecting that it might just break on a Chromium upgrade, at which point it will wind up being a more complicated bisect, but hopefully we can get lucky and it's clearer than that.

For me, after installing v1.84.1, I can now get "window.titleBarStyle": "native" to work on Wayland (including multiple windows maximised), if I also pass the flag --disable-gpu-sandbox.

Ok, this fix above only seems to work with 100% scaling. It crashed when I had a multi-monitor setup with one screen set to 75% scaling.

Haven't been feeling 100% but bisecting Electron is mostly waiting so thankfully it worked out OK. And this ought to be the first commit that introduced this issue:
7a8346cc11c90766fb398dd58450d2cb2a08a1a4 is the first bad commit
commit 7a8346cc11c90766fb398dd58450d2cb2a08a1a4
Author: electron-roller[bot]<EMAIL_ADDRESS>Date:   Tue Nov 1 17:17:00 2022 -0400

    chore: bump chromium to 108.0.5359.22 (22-x-y) (#36163)

    * chore: bump chromium in DEPS to 108.0.5359.19

    * chore: update patches

    * 3859750: [linux/wayland] Added plumbing for the state of tiled edges.

    https://chromium-review.googlesource.com/c/chromium/src/+/3859750

    Also 3970920: [linux/wayland] Fixed the tiled edges for the GTK frame.

    https://chromium-review.googlesource.com/c/chromium/src/+/3970920
    (cherry picked from commit d3f0dbb68ac5f61074ab5f4383cb34bcc71acd7c)

    * chore: bump chromium in DEPS to 108.0.5359.22

    * chore: update patches

    Co-authored-by: electron-roller[bot]<EMAIL_ADDRESS>    Co-authored-by: PatchUp<EMAIL_ADDRESS>    Co-authored-by: John Kleinschmidt<EMAIL_ADDRESS>
 DEPS                                                   |  2 +-
 ...d_parameter_to_linuxui_getwindowframeprovider.patch | 14 +++++++-------
 patches/chromium/blink_local_frame.patch               |  2 +-
 ...ld_do_not_depend_on_packed_resource_integrity.patch | 14 +++++++-------
 patches/chromium/disable_color_correct_rendering.patch |  4 ++--
 patches/chromium/disable_hidden.patch                  | 12 ++++++------
 ...crash_loading_non-standard_schemes_in_iframes.patch |  4 ++--
 .../chromium/mas_disable_remote_accessibility.patch    |  2 +-
 patches/chromium/printing.patch                        |  4 ++--
 ...ose_cursor_changes_to_the_webcontentsobserver.patch |  4 ++--
 patches/chromium/render_widget_host_view_base.patch    |  2 +-
 patches/chromium/worker_context_will_destroy.patch     |  2 +-
 patches/v8/build_gn.patch                              |  6 +++---
 .../do_not_export_private_v8_symbols_on_windows.patch  |  4 ++--
 patches/v8/expose_mksnapshot.patch                     |  4 ++--
 .../ui/electron_desktop_window_tree_host_linux.cc      | 18 +++++++++++++++++-
 .../ui/electron_desktop_window_tree_host_linux.h       |  1 +
 shell/browser/ui/views/client_frame_view_linux.cc      |  2 +-
 shell/browser/ui/views/client_frame_view_linux.h       |  8 ++++++++
 19 files changed, 67 insertions(+), 42 deletions(-)

Recalling something I said earlier:

I'm expecting that it might just break on a Chromium upgrade, at which point it will wind up being a more complicated bisect, but hopefully we can get lucky and it's clearer than that.

No such luck. So now I am guessing I will need to figure out how to bisect the Chrome version as well.

Well, it was not related to Chromium version after all. The bug is right here:
https://github.com/electron/electron/commit/7a8346cc11c90766fb398dd58450d2cb2a08a1a4#diff-baefd46d1d673b2cccc672cedea58414f35f81123c394b24674fe675cca3d57b
But this is weird; this doesn't seem at all related to "rebuilding application menu". I wouldn't be too surprised if there are multiple bugs, but I am pretty sure this is the one that is affecting most people. And if I comment out the code in OnWindowTiledStateChanged, the bug disappears: I can create unlimited new windows, no crashing.
(Even weirder is that at electron main, there seems to be an entirely different bug where things crash when a window is closed, but I don't get crashes when new windows are opened, at least not that I noticed. So that might need some debugging too. But I'll ignore it for the moment...)
I want to understand more about why this code was added and what it fixes, so I can see if I can figure out what the actual underlying problem is and validate a fix for it. I am hoping that having figured out exactly the source of the problems, possibly someone with more knowledge can now help us out...

@jchv

I want to understand more about why this code was added and what it fixes

Following the links in your linked commits you end up on this https://bugs.chromium.org/p/chromium/issues/detail?id=1296836

@jchv thanks for taking the time to perform the bisect in the runtime, you are right there are multiple crashes in play. So far from the logs and repro I have seen,

Crash due to invalid layer being passed with point focus in the application, refs https://github.com/electron/electron/issues/39449#issuecomment-1744016027
Crash due to window title change
Crash when initializing/rebuilding the application menu
Crash on closing window with Electron >= 27

Even weirder is that at electron main, there seems to be an entirely different bug where things crash when a window is closed, but I don't get crashes when new windows are opened, at least not that I noticed. So that might need some debugging too. But I'll ignore it for the moment...

This is good to know, I had the same experience when setting up the repro against different Electron versions.
I was able to address 1), haven't looked at 2, 3 and 4 yet. All of them are also tracked in https://github.com/electron/electron/issues/39449. It would be great if you can share your findings in the upstream issue so that other Electron maintainers are also aware of it.

I'm now completely confused. That makes me suspect there really must be multiple bugs at play, and it's impossible to know how many people are being hit by this one and not the one in the OP.

@jchv You're definitely on the right track!  The crash in your stacktrace looks the same as the UpdateChildLayerBounds one here.  Based on the multiple stacktraces that I saw, it's likely that there are a few different paths that can cause a similar crash on startup under Wayland.  Given the probability of the bug triggering most of the time, but not always... I suspected that these might be race conditions also, so It's good to see you validating that hypothesis.  It's also likely that there are multiple threads at play during the crash, which can make things a bit more confusing.

Using insiders build (1.85.0-1700840594) with "window.titleBarStyle": "custom" and
--enable-features=UseOzonePlatform --ozone-platform=wayland everything seems to work. Stable build (1.84.2-1699528352) still crashes when opening a second maximised window.
Setting "window.titleBarStyle": "native" still crashes on startup in both builds. I'm using sway

It seems that it is more difficult to crash code while resizing windows.
code-insiders --enable-features=UseOzonePlatform --ozone-platform=wayland
Version: 1.85.0-insider
Commit: eb56719ae7653bff54989385818ef39e1cd73d29
Date: 2023-11-24T15:21:05.133Z
Electron: 25.9.4
ElectronBuildId: 25127168
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 6.5.12-300.fc39.x86_64

I am running NixOS 24.05 and for me VsCode crashes when I have more than one maximised window open with native wayland and "window.titleBarStyle": "custom".
On the other hand, I can open multiple maximised windows with "window.titleBarStyle": "native".

@deepak1556 Is anyone actively working on this? I would love to see some real progress here.

I am running NixOS 24.05 and for me VsCode crashes when I have more than one maximised window open with native wayland and "window.titleBarStyle": "custom".
On the other hand, I can open multiple maximised windows with "window.titleBarStyle": "native".

What flags are you using? Are you definitely running native wayland and not xwayland?

I am running NixOS 24.05 and for me VsCode crashes when I have more than one maximised window open with native wayland and "window.titleBarStyle": "custom".
On the other hand, I can open multiple maximised windows with "window.titleBarStyle": "native".

What flags are you using? Are you definitely running native wayland and not xwayland?

I am definitely running native wayland, I can confirm this by using the command nix run nixpkgs#xorg.xprop and then hovering over my Visual Studio Code window. If it was using xwayland, it would be a cross cursor. Here it is the default.
I also set the NIXOS_OZONE_WL environment variable to 1 in my configuration, which basically enables Ozone Wayland support in Chrome and some Electron applications.
I think the flags that the environment variable sets are the following
--enable-features=UseOzonePlatform --ozone-platform=wayland

@thiloho I tried --disable-gpu-sandbox and it worked, but stopped after about 30m of using multiple HiDPI monitors with different scaling, as @mirenradia mentioned.
I figure setting window.titleBarStyle to custom and the flag above would reduce operations just enough to avoid the race condition.
I don't want to try to make that work with Hyprland window rules though.

If I have the window.titleBarStyle set to custom and run more than one window using the code --disable-gpu-sandbox command, both vscode windows crash when the second window is maximised. So at least for me, it does not change anything.

Using --enable-features=UseOzonePlatform --ozone-platform=wayland --disable-gpu-sandbox with "window.titleBarStyle": "custom" on the Insiders build does appear to prevent the crash.
Stable build still crashes upon opening maximising the second window. So it looks like work has been done to address this

Just adding my log to the thread:
code-insiders --enable-features=UseOzonePlatform --ozone-platform=wayland --disable-gpu-sandbox --verbose
Warning: 'enable-features' is not in the list of known options, but still passed to Electron/Chromium.
Warning: 'ozone-platform' is not in the list of known options, but still passed to Electron/Chromium.
MESA-LOADER: failed to open iris: /usr/lib/dri/iris_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
failed to load driver: iris
MESA-LOADER: failed to open kms_swrast: /usr/lib/dri/kms_swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
failed to load driver: kms_swrast
MESA-LOADER: failed to open swrast: /usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
failed to load swrast driver
[1201/192836.682663:ERROR:file_io_posix.cc(152)] open /home/lxe/.config/Code - Insiders/Crashpad/pending/21d593bd-1ee2-458f-81d9-c5fc44fe27b5.lock: File exists (17)
[1201/192836.682697:ERROR:file_io_posix.cc(152)] open /home/lxe/.config/Code - Insiders/Crashpad/pending/fd7d92a8-1706-4bfd-8f43-0a2876d51f0f.lock: File exists (17)
[359026:1201/192836.683673:WARNING:wayland_object.cc(157)] Binding to gtk_shell1 version 4 but version 5 is available.
[359026:1201/192836.683703:WARNING:wayland_object.cc(157)] Binding to zwp_pointer_gestures_v1 version 1 but version 3 is available.
[359026:1201/192836.683717:WARNING:wayland_object.cc(157)] Binding to zwp_linux_dmabuf_v1 version 3 but version 4 is available.
(code-insiders:359026): GLib-GIO-ERROR **: 19:28:36.686: Settings schema 'org.gnome.settings-daemon.plugins.xsettings' does not contain a key named 'antialiasing'
[1201/192836.689077:ERROR:process_memory_range.cc(75)] read out of range
[1201/192836.689084:ERROR:process_memory_range.cc(75)] read out of range
...
[more like this, then silent crash]

❯ code-insiders --version
1.85.0-insider
94a3d7bac770b43ce97e9685715bef1a60d1a759
x64

❯ inxi --system --graphics
System:
  Host: lxe-ubuntu Kernel: 6.5.0-13-generic arch: x86_64 bits: 64
    Desktop: GNOME v: 45.1 Distro: Ubuntu 23.10 (Mantic Minotaur)
Graphics:
  Device-1: Intel AlderLake-S GT1 driver: i915 v: kernel
  Device-2: NVIDIA GA102 [GeForce RTX 3090] driver: nvidia v: 545.29.06
  Device-3: NVIDIA GA102 [GeForce RTX 3090] driver: nvidia v: 545.29.06
  Display: wayland server: X.Org v: 1.23.2 with: Xwayland v: 23.2.0
    compositor: gnome-shell driver: X: loaded: modesetting,nvidia
    unloaded: fbdev,nouveau,vesa dri: swrast gpu: nvidia,nvidia-nvswitch
    resolution: 1: 2560x1440~144Hz 2: 2560x1440~144Hz
  API: OpenGL v: 4.5 Mesa 23.2.1-1ubuntu3 renderer: llvmpipe (LLVM 15.0.7
    256 bits)

Using --enable-features=UseOzonePlatform --ozone-platform=wayland --disable-gpu-sandbox with "window.titleBarStyle": "custom" on the Insiders build does appear to prevent the crash.
Stable build still crashes upon maximising the second window. So it looks like work has been done to address this

I can confirm that it works. When using the Insiders build with the --disable-gpu-sandbox flag, it is possible to run multiple maximised native Wayland windows.

Stable build still crashes upon maximising the second window. So it looks like work has been done to address this

It's still possible to reproduce the crash when opening multiple windows on the insiders build:
https://github.com/microsoft/vscode/assets/433598/142677fd-c541-409c-afa7-d09e9f084394

Correction, using the insider build and the --disable-gpu-sandbox flag also causes crashes. Now when I open a second window, I get the info that vscode is not responding and therefore all instances are closing. So the only real solution for me to have multiple windows open without crashing is to use the window.titleBarStyle set to native and use the stable vscode build. This should also work with the insider build.

Using code-insiders --enable-features=UseOzonePlatform --ozone-platform=wayland --disable-gpu-sandbox disables any gpu rendering for me. Using an nvidia gpu
output of code-insiders --status:
Version:          Code - Insiders 1.86.0-insider (02b90714767f05c734ac29a64d0e5b4768f532d8, 2023-12-08T11:54:17.211Z)
OS Version:       Linux x64 6.1.65
CPUs:             AMD Ryzen 5 5600X 6-Core Processor (12 x 3814)
Memory (System):  15.56GB (12.28GB free)
Load (avg):       0, 0, 0
VM:               0%
Screen Reader:    no
Process Argv:     --disable-gpu-sandbox --enable-features=UseOzonePlatform --ozone-platform=wayland --crash-reporter-id 165f0398-763d-48e6-96d4-1d273aa104fe
GPU Status:       2d_canvas:                              unavailable_software
                  canvas_oop_rasterization:               disabled_off
                  direct_rendering_display_compositor:    disabled_off_ok
                  gpu_compositing:                        disabled_software
                  multiple_raster_threads:                enabled_on
                  opengl:                                 disabled_off
                  rasterization:                          disabled_software
                  raw_draw:                               disabled_off_ok
                  skia_graphite:                          disabled_off
                  video_decode:                           disabled_software
                  video_encode:                           disabled_software
                  vulkan:                                 disabled_off
                  webgl:                                  unavailable_software
                  webgl2:                                 unavailable_software
                  webgpu:                                 disabled_off

Somehow related to this proposal? -  Allow VS-code to respect native titlebar decorations configuration on GNOME/Linux

I know I've said this several times before in this issue but the latest insiders build seems to be working fine for me now with window.titleBarStyle: native, multiple windows maximised and non-integer display scaling (125%). Here's the version I'm using:
Version: 1.86.0-insider
Commit: 72cb92fdc5d08101d65d59e4b1c046d397896dd2
Date: 2023-12-12T05:36:27.172Z
Electron: 27.1.3
ElectronBuildId: 25612240
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 6.6.4-200.fc39.x86_64

and the output of code-insiders --status:
Version:          Code - Insiders 1.86.0-insider (72cb92fdc5d08101d65d59e4b1c046d397896dd2, 2023-12-12T05:36:27.172Z)
OS Version:       Linux x64 6.6.4-200.fc39.x86_64
CPUs:             12th Gen Intel(R) Core(TM) i7-1260P (16 x 2540)
Memory (System):  31.06GB (15.63GB free)
Load (avg):       1, 1, 1
VM:               0%
Screen Reader:    no
Process Argv:     --enable-features=UseOzonePlatform --ozone-platform=wayland --unity-launch --crash-reporter-id cfbead22-dce7-482e-8a79-ebdcc849cc1f
GPU Status:       2d_canvas:                              enabled
                  canvas_oop_rasterization:               disabled_off
                  direct_rendering_display_compositor:    disabled_off_ok
                  gpu_compositing:                        enabled
                  multiple_raster_threads:                enabled_on
                  opengl:                                 enabled_on
                  rasterization:                          enabled
                  raw_draw:                               disabled_off_ok
                  skia_graphite:                          disabled_off
                  video_decode:                           enabled
                  video_encode:                           disabled_software
                  vulkan:                                 disabled_off
                  webgl:                                  enabled
                  webgl2:                                 enabled
                  webgpu:                                 disabled_off

confirming the above [https://github.com/microsoft/vscode/issues/184124#issuecomment-1853602649]
with the same build & same config, vscode works fine for me (GNOME, AMD Ryzen 7 5800H with Radeon Graphics, 175% scaling on one screen and 100% on the other)

Adding a working data point here:
$ uname -a
Linux ackerleytng-computer 6.6.7-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 14 Dec 2023 03:45:42 +0000 x86_64 GNU/Linux

$ sway --version
sway version 1.8.1

$ codium --version
Warning: 'enable-features' is not in the list of known options, but still passed to Electron/Chromium.
Warning: 'ozone-platform-hint' is not in the list of known options, but still passed to Electron/Chromium.
1.85.1
08e6c15293922dd53a864bb041be381322fee401
x64

$ cat ~/.config/codium-flags.conf
--enable-features=UseOzonePlatform,WaylandWindowDecorations,WebRTCPipeWireCapturer
--ozone-platform-hint=auto

$ cat ~/.config/VSCodium/User/settings.json
{
    "window.titleBarStyle": "custom"
}

I had almost given up hope, but instead surprised and pleased to be able to add my own data point: Fedora 39, Sway 1.8.1, NVIDIA drivers 545.29.06, --enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland and "window.titleBarStyle": "custom".
Finally doesn't crash when opening a new window (and not sluggish at all, re https://github.com/microsoft/vscode/issues/169504).

The latest code insiders (with Electron 27) doesn't crash under Sway 1.8.1 even with native menu bar for me.

The latest code insiders (with Electron 27) doesn't crash under Sway 1.8.1 even with native menu bar for me. I also tested opening multiple windows and that works too.
are u using amd or nvidia?

I tested using Intel integrated GPU.

Latest insiders also working here with native title at under sway on intel

All I can say is that nothing has worked (consistently) on an AMD iGPU.

Latest vscode works on sway, with these settings:
window.titleBarStyle=custom
code --enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland

Latest vscode works on sway, with these settings:
window.titleBarStyle=custom code --enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland

Are you able to resize to fullscreen (with borders)?

Latest vscode works on sway, with these settings:
window.titleBarStyle=custom code --enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland

Are you able to resize to fullscreen (with borders)?

I wasn't asked, but I still can answer lol
Cause manually dragging and expanding each window border to the corresponding screen border seems to provide that fullscreen effect without crashing. The crash happens after pressing the fullscreen button in the upper right corner of the window. And when I say "fullscreen" I don't mean F11 fullscreen, I mean the one where gnome's header row with clocks and notifications is still visible

@alex-morgun It works for you. All of this "it works for me" is unhelpful and I wish it would stop. I'm following this issue via email notifications so that I know when it's closed, when the problem is actually fixed.

I'm following this issue too. My fixes include custom scripts and hotkeys to directly change the titlebar setting. I can turn my "fixes" which are more like hacks into a repository if it helps temporarily. It really is just a bandage for the problem, but it works.
On Tuesday, December 19th, 2023 at 11:26 PM, Jacob Birkett @.***> wrote:

@.***(https://github.com/alex-morgun) It works for you. All of this "it works for me" is unhelpful and I wish it would stop. I'm following this issue via email notifications so that I know when it's closed, when the problem is actually fixed.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

@alex-morgun It works for you. All of this "it works for me" is unhelpful and I wish it would stop. I'm following this issue via email notifications so that I know when it's closed, when the problem is actually fixed.

You can set your watch settings to notify only on status change.

Did anyone else have an electon25-flags.conf in their ~/.config
directory? I had it with:
--enable-features=WaylandWindowDecorations
--ozone-platform-hint=auto

Don't remember if I added that in myself, but I renamed it to something else. That was the culprit for me. I only got "is not in the list of known options, but still passed to Electron/Chromium." for both options if I started on the command-line with:
code --ozone-platform-hint=auto --enable-features=WaylandWindowDecorations

Did anyone else have an electron25-flags.conf in their ~/.config
directory? I had it with:
--enable-features=WaylandWindowDecorations
--ozone-platform-hint=auto

Don't remember if I added that in myself, but I renamed it to something else. That was the culprit for me. I only got "is not in the list of known options, but still passed to Electron/Chromium." for both options if I started on the command-line with:
code --ozone-platform-hint=auto --enable-features=WaylandWindowDecorations

Those are the flags to run X apps in Wayland.
By removing those you are running vscode on X, so of course you don't have the issues presented.
You'll probably have some.other issues like blurry text though.
Ps: Having this same issue on Hyprland

I found that running this works:

If I have tabbed windows and each code window takes whole screen
It does not work:
If windows opens side to side
code --enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland

By removing those you are running vscode on X, so of course you don't have the issues presented.

People want native wayland for scaling and good rendering. X may work in simple cases

@alex-morgun It works for you. All of this "it works for me" is unhelpful and I wish it would stop.

Chill bro, I said it have nothing with a GPU type. It's a bug in Electron.

The latest VS Code Insiders build has resolved the issue I was having with maximizing multiple windows, which was probably caused by this issue.
Options used: --ozone-platform-hint=auto --enable-features=WaylandWindowDecorations
Build Info:
Version: 1.86.0-insider
Commit: 9621add46007f7a1ab37d1fce9bcdcecca62aeb0
Date: 2023-12-20T05:36:34.875Z
Electron: 27.1.3
ElectronBuildId: 25612240
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 6.6.7-200.fc39.x86_64

System:
VS Code is running inside a Fedora Distrobox container, within a host system running Fedora Silverblue with Gnome and Wayland.

As I understand, the problem is a data race in electron. It will start working, and then stop working, because the data race is inherently unpredictable.

I'm increasingly confident Electron 27 (used by VSCode Insiders) fixed the crashes I was observing, and I was even able to use my reproducer automation (KWin Window Rules to force maximization states without manually interacting with an app) to make stable VSCode (on Electron 25) not crash.
For both versions of VSCode I was able to get working again, I can confirm fractional scaling support (crisp pixel-perfect font rendering only when a window is fully contained within one monitor, that becomes slightly fuzzy while transiting between monitors).
And I also tested closing/opening windows, and all of that with window.titleBarStyle set to both "native" and "custom" (I normally use "custom" but for my crashes I never saw it make a difference).
I wrote up all the details in a much longer comment on the Electron issue: https://github.com/electron/electron/issues/39449#issuecomment-1871357712

@spikespaz Were you able to observe a crash with VSCode Insiders (specifically a build new enough to have Electron 27 in Help -> About)?
Nevermind, that reaction was to https://github.com/microsoft/vscode/issues/184124#issuecomment-1863388815 claiming something about non-Insiders VSCode. In that case, I agree, I don't think the underlying problems are fixed in Electron 25 builds of VSCode (I am on 1.85.1 which uses Electron 25.9.7, and it was very easy to generate dozens of crashes, once I started using KWin Window Rules to automate maximization).
However, keep in mind most people are commenting about VSCode Insiders, which, AFAICT did fix it.
Now we just have to wait a few more weeks for it to make it into VSCode stable.

Almost a year since the issue was first reported and here we are still without a fix :1st_place_medal:

I have since moved to neovim. Not worth it using an editor where basic level of support is not there.

Almost a year since the issue was first reported and here we are still without a fix 🥇

@zylex-git you didn't fixed the issue for almost a year, you are so nasty /irony

Happy new year!
The same issue occurred in version 1.85.1. So, any progress?

Personally I'm on Hyprland with Nvidia (proprietary). I can at least confirm that moving to VS Insiders fixed the issue for me.

@Sewer56 You might want to go knock on some wood, very quickly.

@Sewer56 You might want to go knock on some wood, very quickly.

Oh don't worry, I didn't specify the whole IDE was working, I only said it didn't crash. For instance, in insiders, I can't rearrange the Activity Bar elements, or plop them to the right hand side of the window. Slightly annoying but not a showstopper, unlike crashes on new windows.

It seems as though this issue has been fixed with the update to electron 27 in the 1.86 release. Just tested on Debian 12 using KWin under both Intel integrated graphics and Nvidia's proprietary driver and experienced no crashes whatsoever.

It still crashes sometimes IME, but not nearly as often, so at least it's actually usable.

Haven't seen a crash on v1.86 in 3 days with native menus and various windows open - on Guix. Cool.
guix shell node gcc-toolchain rust rust:tools rust-analyzer openssl -- sh -c "CC=gcc OPENSSL_DIR=$(dirname $(dirname $(realpath $(which openssl)))) code --enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland"

Yeah, since release 1.86 I haven't noticed any dropouts either. Thank you, developers!

Same here. Seems to have been fixed. Thank you so much!

I still have issues with sometimes crashing on maximizing and opening new windows on Arch Linux and Plasma 5 with the Electron 27-backed version, but crashing seems to happen less often from what I remember.
Hoping that Electron 28(https://github.com/microsoft/vscode/issues/201935) will get rid of it, as more crashes seem to be fixed there, and by that time Plasma 6 should be out which fixes some issues with Chromium, namely at the very least this one about rendering at 60Hz max, so that might make things better too.

Just noticed that I'm on VSCode 1.86.1 which uses Electron/27.2.3 so I was able to turn off my anti-maximize hacks (https://github.com/microsoft/vscode/issues/184124#issuecomment-1871367629) and maximize my VSCode windows for the first time in months, and had no crashes yet!

Works for me 🎉
Thank you people who contributed to solution of this problem

With "window.titleBarStyle": "native," everything runs smoothly. However, with the "custom" title bar style, opening and maximizing new windows occasionally leads to crashes. It's not as frequent as before, but it's still annoyingly frequent.

@musakarimli Are you testing on 1.88?
It got an Electron 28 update which fixed further Wayland issues.

@C0rn3j Yes, after updating to version 1.88, I was hoping the new Electron version would resolve the issue, but unfortunately, it didn't. I wasn't aware of the non-mandatory flags, I'll definitely give them a try. Thanks for the tip!

I'm happy that many people don't experience the crashes anymore. However, it's known to be caused by some weird race condition, so while the frequency does vary between updates, the issue still does persist (at least one of its incarnations, if there are more).
(Im on arch&sway, running vscode under wayland, native titlebar, v1.88.0. The crashing has improved, but still happens when opening a new window.)

I am pretty sure there are multiple Wayland crashes being talked about in this thread (and many more in the thread that this one is extracted from), some of them fixed in the current 1.88.
If you still experience crashes, attaching debug logs and other information from 1.88 would probably be helpful to the developers.
I still have uncommon crashing issues, but it's no longer 100% reproducible.

Extracted from #181533 (comment)
Crash reason:  SIGSEGV /SEGV_MAPERR
Crash address: 0x1010101
Process uptime: 142 seconds

Thread 0 (crashed)
 0  code-insiders!views::View::UnregisterChildrenForVisibleBoundsNotification(views::View*) [view.cc : 2859 + 0x0]
 1  code-insiders!views::View::UnregisterChildrenForVisibleBoundsNotification(views::View*) [view.cc : 2860 + 0x5]
 2  code-insiders!views::View::DoRemoveChildView(views::View*, bool, bool, views::View*) [view.cc : 2702 + 0x8]
 3  code-insiders!views::View::RemoveAllChildViews() [view.cc : 340 + 0x12]
 4  code-insiders!electron::MenuBar::RebuildChildren() [menu_bar.cc : 234 + 0x5]
 5  code-insiders!electron::RootView::SetMenu(electron::ElectronMenuModel*) [root_view.cc : 71 + 0x8]
 6  code-insiders!electron::api::BaseWindow::SetMenu(v8::Isolate*, v8::Local<v8::Value>) [electron_api_base_window.cc : 0 + 0x8]
 7  code-insiders!gin_helper::Dispatcher<void (electron::api::BaseWindow*, v8::Isolate*, v8::Local<v8::Value>)>::DispatchToCallback(v8::FunctionCallbackInfo<v8::Value> const&) [callback.h : 267 + 0x3]
 8  code-insiders!v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) [api-arguments-inl.h : 146 + 0x3]

@Mithras can you provide the following details to help us repro the issue,

Are you using custom or native titlebar ?
Are you starting the application with --ozone-platform=wayland --enable-features=WaylandWindowDecorations ?
Where did you install insiders from ? Snap, deb or rpm ?
A video recording showing the exact repro steps will be helpful.

@C0rn3j Yes, after updating to version 1.88, I was hoping the new Electron version would resolve the issue, but unfortunately, it didn't. I wasn't aware of the env vars, I'll definitely give them a try. Thanks for the tip!
Ah, got it. So I had those features enabled: --enable-features=UseOzonePlatform,WaylandWindowDecorations. Now that I've disabled them, it seems to be more stable. I'll keep an eye on it for the next 2-3 days and update you accordingly.
Update: I haven't experienced any issues since removing the option --enable-features=UseOzonePlatform,WaylandWindowDecorations.

Electron 28 chooses to use Wayland without explicitly setting UseOzonePlatform and WaylandWindowDecorations? Are you sure it isn't using Xwayland? What WM/DE are you using?

Hi, I just changed the

"window.titleBarStyle": "native,"

to "custom", and it worked for me. my default was "native" and I had this problem. I tried everything. but when I saw your solution, I changed it to "custom".
by the way, since I had this problem with the snap version, I switched to apt version.

Interestingly, i've got titlebar style to "custom" for all profiles - and yet, it's the 2nd time this week that i'm seeing a crash of vscode.

I rarely have a vscode crash anymore, once a month max. I've got titlebar style custom. I used to see them quite often!

Still having constant system crash when having VS Code installed after trying everything in this thread, both on Arch and Kubuntu, since I had Wayland on both of them.


Update the API Guide with Code mapping template & instructions

Problem statement
We are adding an additional step to our onboarding process (Code mapping). The content is already developed and needs to be updated on the front-end.
What you need to know

Content updates doc: Use a source of truth for content changes.
Figma reference: Reference for components only (i.e. NOT content).

Acceptance criteria

[ ] New Map your codes section is added
[ ] Subsequent section numbers are updated
[ ] Create hash-links for each numbered section

To do

[ ] When making PR, tag @jillian-hammer as a reviewer

Spillover: Zenhub did not sync properly and did not add this to Sprint Backlog. Noticed today, so started on today. Should be deployed by Thursday.


CI: Run Terraform GitHub workflow on changes to the workflow

Terraform Format and Style 🖌success
Terraform Initialization ⚙success
Terraform Validation 🤖success
Validation Output

Success! The configuration is valid.

Terraform Plan 📖success
Show Plan

undefined

Pusher: @markgoddard, Action: pull_request, Working Directory: ``, Workflow: Terraform GitHub


Endless loop in the window for the generation of the OpenBazaar ID

Brief Description: I am hung at the personal keys and OpenBazaar id generation
Operating System (OS and version): Windows 10
OpenBazaar version (shown on About OpenBazaar page in menu): 1.1.7
Hardware: Desktop
Reproducible (Always / Almost Always / Sometimes / Rarely / Couldn't Reproduce): Always
Steps to reproduce:

Installing the OpenBazaar 1.1.7 for Windows 64 bits
The connection to the server works, i answer all questions, i accept the disclaimer
After that, i get to the moment when it tries to generate the personal keys and OpenBazaar Id, and then it stays forever in this window.

Observed Behavior: Here is what i have in the window:
Hang tight for a few...
Your personal keys and OpenBazaar ID are generating and should only take about 30 seconds to finish.  You'll be automatically connected to the network once the process is finished, so please hang tight.
Looking for something to do in the meantime? Read the OpenBazaar blog.
Expected Behavior:
Additional info (links, images, etc go here):

@faffner if you turn off the app, and start it again, does it take you through the onboarding process where you set up you language, country, etc. again?
If you press "control shift I" while one the "Hang tight for a few..." screen , to bring up the web developer panel, and look at the console tab, do you see any errors?

@jjeffryes  yes, it took me each time through the onboarding process - language, country, etc. up to the disclaimer.
 My OpenBazaar ID got generated.
So i will close this issue, hoping that once the ID has been generated, the problem will not happen again. I am sorry to not be able to provide you with more information about this problem.
Let me know if you would like me to perform some other verifications.


Will "Release notes for Microsoft Edge Stable Channel" be updated with 88.0.705.81?

I noticed that the "Microsoft Edge Stable Channel" page is not updated with the 88.0.705.81 version which was released last week. Will this page be further updated or has this info moved to another page?

@Jand66 Hi!  I believe there is currently an issue with documentation publishing.  The information will be updated once resolved!  The release notes have not moved.  Thanks for checking!

@Y-Kelly, thank you. Would there be any ETA on resolving the issue?

@Jand66 Should be updated now :) https://docs.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-channel#version-88070581-february-25

Thank you!
From: Kelly Yokote<EMAIL_ADDRESS>Sent: Wednesday, 3 March 2021 19:57
To: MicrosoftDocs/Edge-Enterprise<EMAIL_ADDRESS>Cc: Jand66<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/Edge-Enterprise] Will "Release notes for Microsoft Edge Stable Channel" be updated with 88.0.705.81? (#130)
@Jand66 https://github.com/Jand66  Should be updated now :) https://docs.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-channel#version-88070581-february-25
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/MicrosoftDocs/Edge-Enterprise/issues/130#issuecomment-789976595 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ANSIUXGNGIOFXUN7RNI2DALTB2BBTANCNFSM4YL3XXPA .  https://github.com/notifications/beacon/ANSIUXA4P6TTED2ENDKUPI3TB2BBTA5CNFSM4YL3XXPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOF4LBMEY.gif


Make header recording null safe

See https://discuss.elastic.co/t/unable-to-instrument-weblogic-server-with-apm-java-agent/143312

Codecov Report

Merging #158 into master will decrease coverage by 0.05%.
The diff coverage is 40%.

@@             Coverage Diff              @@
##             master     #158      +/-   ##
============================================
- Coverage     73.61%   73.56%   -0.06%
- Complexity     1006     1007       +1
============================================
  Files           111      111
  Lines          3748     3752       +4
  Branches        332      334       +2
============================================
+ Hits           2759     2760       +1
- Misses          824      825       +1
- Partials        165      167       +2

Impacted Files
Coverage Δ
Complexity Δ

.../java/co/elastic/apm/servlet/ServletApiAdvice.java
7.84% <0%> (-0.16%)
2 <0> (ø)

...main/java/co/elastic/apm/impl/context/Request.java
72.88% <100%> (+0.46%)
20 <2> (+1)
:arrow_up:

...lastic/apm/report/serialize/DslJsonSerializer.java
84.95% <66.66%> (+0.05%)
93 <0> (+1)
:arrow_up:

...stic/apm/report/IntakeV1ReportingEventHandler.java
73.33% <0%> (-4.45%)
12% <0%> (-1%)

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 6115388...e93a4b9. Read the comment docs.


CPU goes to +200%

Everytime I run npm start script, take some seconds for the fans to start moving. Activity monitor shows a cpu use of +200%. Is this normal at this moment of the project?

Haven't seen this myself. What is the process name that is taking 200%... assuming node?
Do you see the same thing with the default react-native packager?

no, the common react-native packager worked just well. But I wanna add that today I upgrade OSX to last version of Yosemite, and it's working great again. Not sure what happen!
Sorry for the inconvenience !

Interesting though. Thanks for the report, will keep an eye out for this.

Try disabling hot-reload. Reduced CPU usage at least 10 times :)

yes, I run npm run hot it takes about 140% cpu.


Refactor

[ ] Embrace Results
[ ] Embrace the ? syntax
[ ] Intermediate representation that is X_Ast_Node has:

[ ] a name,
[ ] an ast node and implements
[ ] a number of methods, such as to_act and get_dependent_types. This trait will be for all ast nodes that will guide you through how to implement any new high level things.

[ ] Implement this high level overview

[ ] 1) Global pass to get all of the canister method, external canisters, etc ast nodes,
[ ] 2) Call to_act on each of them that will return Results,
[ ] 3) if there are errors we grab all of them and present them to the user,
[ ] 4) if there are no errors we will deduplicate all of the act nodes and pass them into the ACT.

[ ] Make sure we use crate everywhere unless self make more sense
[ ] Take a look at the actable trait
[ ] Remove Act from all of the datatypes and make sure that we use data_type::Option etc
[ ] move all of these to GitHub as check-marks
[ ] Make sure all of the canister methods are options if we sometimes don't use them.

[ ] Init and post we will always need

[ ] Make the ACT nested to reflect the future folder structure

For data types:

[ ] Remove type ref as a concept
[ ] Add a type alias data type (it will be similar to typeref)

[ ] a type alias will have a name and a data type and that data type could be another type alias so it will be type alias all the way down.

[ ] Remove the LiteralOrTypeAlias
[ ] Remove hash and use parent node info to create a unique name.
[ ] Remove the global list of all types and just have the types be the leaf nodes of canister methods

[ ] Create readme

[ ] for users
[ ] for developers

[ ] Make sure all TODO are gone
[ ] Make sure all contexts that should be keyword_lists are name as such

[ ] Separate TokenStreams into all of the things that tokenstreams are supposed to represent

[ ] declarations
[ ] type annotations
[ ] just random groups of tokens
If it's just a random group of tokens then it shouldn't be treated like it might be a type annotation, and a type annotation certainly shouldn't be treated like a declaration. Let's make it more clear when we are create which

[ ] Make sure we are importing instead of qualifying
[ ] Make sure that all of the prefixes are consistent. I think the prefixes should only have to go back as far as the first parent with an actual name right?

[ ] I am not sur that Has Members is the right fit for Func. Investigate why we have it and if we can get away with out it

We need some way to recreate type annotations consistently. If we declare a type one way and then try to use it in a type annotation another way then our rust won't compile. When I initially designed this, I thought that the only times we were declaring types and using type annotations where when we were creating all of the node declarations, and at that point we do have all of the info, but that is not true. We are also doing it when we are making the async result handler for example, or the manual reply things, because we need to know the type so that we can try_from_vm_value correctly.
So the questions are:

Do we have enough context to recreate the type annotation for each data type when we are creating the async result handler match arms?
If so how do we ensure that we create it consistently?

[ ] Try to get rid of muts for maps

[ ] Move all check marks into first comment


Add version subcommand and CLI parser

What type of PR is this?
/kind feature
What this PR does / why we need it:
To be able to identify the seccomp operator build appropriately we now
provide a version,v command.
Which issue(s) this PR fixes:

None
Special notes for your reviewer:
None
Does this PR introduce a user-facing change?

- Added `version,v` subcommand and CLI parser (`--version` works too now)

@hasheddan @pjbgf please take a look :)


IGNITE-3023

Rename keyBackups to Backups for performance advices printed out of a node, due to the name of the property in the configuration file is Backups instead of keyBackups

https://issues.apache.org/jira/browse/IGNITE-3023 is closed


No support for require in node

> require('js-utility-belt/lib')
ReferenceError: document is not defined
    at Object.<anonymous> (/home/dimi/code_ascribe/kyber/drivers/javascript/node_modules/js-utility-b
elt/lib/feature_detection/drag_and_drop_available.js:16:43)
    at Module._compile (module.js:541:32)
    at Object.Module._extensions..js (module.js:550:10)
    at Module.load (module.js:458:32)
    at tryModuleLoad (module.js:417:12)
    at Function.Module._load (module.js:409:3)
    at Module.require (module.js:468:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/home/dimi/code_ascribe/kyber/drivers/javascript/node_modules/js-utility-b
elt/lib/feature_detection/index.js:8:32)
    at Module._compile (module.js:541:32)

@diminator In case you're still having trouble with this, this is directly related to https://github.com/bigchaindb/js-utility-belt/issues/14. The issue is that we're not omitting certain parts of this library that don't make sense for a node build (e.g. the drag and drop module).

Thanks @sohkai, currently we plucked only the necessary files and made them part of the js-driver


Add !del command to delete code pastes

The !del command would delete the last message A_AhkBot posted on behalf of the person who says "!del". I.e. to correct mistakes when highlighting code with !hl [code].
👋

Command has been added.


docs: fix build and deployment of doc site

Forgot to run npm install on the subdirectory.

Coverage decreased (-0.07%) to 88.415% when pulling 4eaf17d3acbe98bf5d911dbbec38ace52166ab12 on abutterworth/fix-deploy into 489f5223572412c9d06bb08029b63d0fb3f2b0d7 on master.

Coverage decreased (-0.07%) to 88.415% when pulling 4eaf17d3acbe98bf5d911dbbec38ace52166ab12 on abutterworth/fix-deploy into 489f5223572412c9d06bb08029b63d0fb3f2b0d7 on master.

:tada: This PR is included in version 4.3.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Plugin not building for objective-c based Flutter iOS projects

Plugin is building fine following the setup instructions for Swift based Flutter iOS code. But get "The “Swift Language Version” (SWIFT_VERSION) build setting must be set to a supported value for targets which use Swift. This setting can be set in the build settings editor." when adding the plugin to an objective-c based Flutter iOS code.  Please advise on how to use with objective-c based Flutter iOS code.

Some users already has this error and describe the way of get rid of it here https://github.com/kiwi-bop/flutter_crashlytics/issues/3


Add shopping cart

2nd PR for shopping cart

@sriking1783, this is real nice. I looked at the previous reviews and comments and it seems like a really nice upgrade.
LGTM


Remove support for layerClassAndSubclasses

As standard ECMAScript does not support retrieving all "subclasses" or derived prototypes from a given class/prototype, we cannot keep that functionality.

Done 64e86e2


Prepare for core C# change

When the core C# rewrite is approved, double check that things still work.
Known issues:

[ ] The <script runat="server"> blocks will need an additional embedded scope of meta.class.body.cs, and possibly also meta.method.body.cs.
One of those is, after all, an accurate description of their scope. According to ".NET Guy," each <script> block is compiled into a corresponding method in the generated class. I am suspicious, though. I think that the access levels indicate that <script> blocks are nested directly in the class.

Note that a lot of scope renaming is going to take place, so don't start working on it too soon.


The same paragraph - twice.

The next paragraph is repeated twice:
With exception of the leading byte and trailing byte flags, the remaining flags describing line drawing and reverse video (swap foreground and background colors) can be useful for other languages to emphasize portions of output.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 34ea4fba-5919-fff6-9941-f213a557c651
Version Independent ID: 5c22080b-6969-4721-5e5c-40c348680701
Content: SetConsoleMode function - Windows Console
Content Source: docs/setconsolemode.md
Product: console
GitHub Login: @bitcrazed
Microsoft Alias: richturn

OK. If you send a PR, I can merge it quick. Otherwise, I'll get this in the next docs pass.


workflow

pre-commit hook
https://appventure.me/2016/04/04/prevent-accidental-test-code-commits/

gitify

background music

// USING

Go2Shell https://itunes.apple.com/us/app/go2shell/id445770608?mt=12&uo=4&at=11l7mT
iTem2
Alfred 2 http://www.alfredapp.com/
Dash https://itunes.apple.com/us/app/dash-docs-snippets/id458034879?mt=12&uo=4&at=11l7mT
Found https://itunes.apple.com/app/found/id527134927?mt=12
DiffMerge https://sourcegear.com/diffmerge/
Navicat
SourceTree
OmniGraffle
Prepo http://wearemothership.com/work/prepo/
Reveal
Calendar
PaintCode
CodeBox
Kaleidoscope http://www.kaleidoscopeapp.com/
xScope https://itunes.apple.com/us/app/xscope/id447661441?mt=12&uo=4&at=11l7mT
Name Changer
Snippets http://www.snippetsapp.com/
Charles
FauxPas for Xcode *** http://fauxpasapp.com/
CodePilot https://github.com/macoscope/CodePilot
SQLiteStudio (much better then SQLite Database Browser)

// WILL USE

Versions http://versionsapp.com/
Objective C Clean https://itunes.apple.com/us/app/objective-clean/id713910413?ls=1&mt=12
QuartzCode http://www.quartzcodeapp.com/
Uberlayer http://twelvetwenty.nl/apps/uberlayer
CodeRunner
Tower
HockeyApp http://hockeyapp.net/releases/mac/

Ruby

https://github.com/rbenv/rbenv
https://github.com/bundler/bundler

iOS

https://github.com/CocoaPods/CocoaPods
https://github.com/Carthage/Carthage

Shell

https://github.com/fish-shell/fish-shell
https://github.com/oh-my-fish/oh-my-fish
https://github.com/fishery

Git client

Sourcetree

Document

Dash

Terminal

Iterm2

Automation

https://github.com/fastlane/fastlane

Take screenshot

Monosnap

Text editor

Sublime Text
Atom

Restful client

Paw


chore: aztec js circulars

This attempts to unpick aztec.js.
Unfortunately, there was some heavy spaghettification here. There was no clear separation between most of the modules, with a lot of circular references.
I've had to move things around to get the structure sound, but now there are things in places that are named unintuitively. One major example being Wallet now being in the account module.
I think simply renaming some things, or e.g. introducing another module with tighter scope is the next step.
I flattened aztec.js a bit to try and make some sense. I also introduced create_account as the highest level module.
This definitely is not "complete" in terms of fixing the names/comments etc, but if agreed it's a good first step we can merge and iterate.

Here are some notes I took as I picked apart. Each module and its dependencies:
account:

account_contract:
	account

contract:
	account

contract_deployer:
	contract

wallet:
	account
	account_contract
	contract

account_manager:
	contract
	contract_deployer
	wallet
	account
	account_contract

create_account:
	account_manager
	wallet

Benchmark results
Metrics with a significant change:

node_database_size_in_bytes (10): 5,812,977 (+36%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Values are compared against data from master at commit 84f4671f and shown if the difference exceeds 1%.
L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
128 txs

l1_rollup_calldata_size_in_bytes
45,444
179,588
716,132

l1_rollup_calldata_gas
223,020
867,740
3,449,408

l1_rollup_execution_gas
842,107
3,594,848
22,205,070

l2_block_processing_time_in_ms
1,333
5,096 (-4%)
21,077

note_successful_decrypting_time_in_ms
345
1,040 (-3%)
3,832

note_trial_decrypting_time_in_ms
55.5 (+4%)
39.9 (-7%)
140

l2_block_building_time_in_ms
13,576
54,621 (+2%)
217,385

l2_block_rollup_simulation_time_in_ms
10,027
40,422 (+2%)
161,004

l2_block_public_tx_process_time_in_ms
3,518
14,128 (+2%)
56,144

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
5 blocks
10 blocks

node_history_sync_time_in_ms
15,643
29,688 (+1%)

note_history_successful_decrypting_time_in_ms
2,760 (+10%)
5,214 (+2%)

note_history_trial_decrypting_time_in_ms
81.2 (-29%)
227 (+15%)

node_database_size_in_bytes
3,914,870
:warning: 5,812,977 (+36%)

pxe_database_size_in_bytes
29,940
59,499

Circuits stats
Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit
circuit_simulation_time_in_ms
circuit_input_size_in_bytes
circuit_output_size_in_bytes

private-kernel-init
200 (+1%)
43,109
20,441

private-kernel-ordering
114
25,833
9,689

base-rollup
2,063
244,144
881

root-rollup
85.5 (-3%)
4,088
889

private-kernel-inner
260
64,516
20,441

public-kernel-private-input
172 (+1%)
25,203
20,441

public-kernel-non-first-iteration
171 (+1%)
25,245
20,441

merge-rollup
11.3 (-3%)
2,608
881

Miscellaneous
Transaction sizes based on how many contracts are deployed in the tx.

Metric
0 deployed contracts
1 deployed contracts

tx_size_in_bytes
10,323
26,359

Looks good, I got a few questions before approving. Also, I'm curious if you spotted improvements on tsserver after this refactor, since it had been one of the main reasons for removing circular dependencies in other parts of the system.

(Firstly, apologies for the mess in this PR, I should have reviewed the diff more thoroughly before assigning. Will look into it shortly.)
I can't definitively say if there's a performance boost yet. I expect it will help. I also expect it can help with startup times, tree-shaking, etc.
However, to be clear, I don't think the above are the root reasons for getting rid of circular dependencies. Circular dependencies can lead to unclear responsibilities, bad interfaces, and convoluted unit tests. Our goal should be a well-structured codebase, where dependencies flow in one direction, creating a clean and understandable architecture. This applies at all levels of the stack, not just between projects, but also the code within. So it isn't just about performance; it's about good software design principles.
There is high level of cognitive overhead to understand circular code (I struggled to comprehend how things connected together). While this PR pulls some things apart and puts them in unintuitive places, I hope it's a step towards something more maintainable. Once you get rid of the circulars, and can actually see "how the code lies", it should be easier to say "oh, this thing actually just does this, and should be named as such" etc etc.
I think making circulars be errors and not warnings, could be a strategic move (once all resolved). It encourages deeper consideration of a code unit's role and dependencies, and could improve our code quality. I haven't enforced this in such a large team before however, so am happy to hear any thoughts.

(Firstly, apologies for the mess in this PR, I should have reviewed the diff more thoroughly before assigning. Will look into it shortly.)

We've all been guilty of this :-P

I think making circulars be errors and not warnings, could be a strategic move (once all resolved). It encourages deeper consideration of a code unit's role and dependencies, and could improve our code quality. I haven't enforced this in such a large team before however, so am happy to hear any thoughts.

I think there are legitimate uses for circular deps in code, especially when writing user-facing APIs, where a handful of objects can act as a facade to more complex code. Circular deps seems like an easy way to help us identify code spaghettis, but I'm not sure if consistently removing them is the best way to improve code clarity. That said, I'm fine giving it a shot.


OPC UA interface service in RTE does not automatically restart.

Problem description (tested on Ubuntu 16, 64bit):

Follow the instructions to start a server
Create the generic OPC UA Interface via web interface (Browser): http://localhost:7509/createObject?format=tcl&factory=/acplt/opcua/uaServer&path=/TechUnits/opcuaInterface
Explorer the server With uaExpert
Stop the server and restart it.

After restarting, OPC UA Service is not started. Is it not automatically restarted? How to make it automatically restart.

A restart is not available in that version. There is a workaround if you export your data to an FBD file before you shutdown the server and reload it.

It works, thanks a lot.


License?

Hello @arizonat. How is this software licensed?

To be honest I haven't thought much about it. I think I'd like this to be as open as possible. I think MIT seems suitable for that, what purposes are you interested in? I'll go ahead and make it as such unless you think it should be otherwise.

Hi! MIT sounds great.  I was thinking to use this for Antimony -> STL -> Embree.

Awesome, looks cool!
As a warning, I haven't really looked at this code in a long time, but would be happy to help out as needed. I'll mark this issue as closed though. Hope you find it useful :)

Thanks @arizonat!


Add WaitForGenericK8sObjects measurement

The new measurement lists all objects from given resource accesses 'status.conditions' field and compares it with list of expected conditions.

What type of PR is this?
/kind feature

What this PR does / why we need it:
Adds new measurement WaitForGenericK8sObjects, whicht:

Can access any object type, via dynamic client
Assumes the objects contain status.conditions field, which is of type []metav1.Condition
Periodically checks if enough objects have given conditions fulfilled, e.g. NodeReady=True (or failed e.g. PodFailed=True)
Finishes if there are enough objects fulfilling the requirements

Which issue(s) this PR fixes:
N/A
Special notes for your reviewer:

/assign
/ok-to-test

One more thing - could you provide a TL;DR of the measurement to ClusterLoader2's README in https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/README.md#measurement?

@tosi3k I've added the unit tests, PTAL

@tosi3k added entry to the README

@tosi3k PTAL

/lgtm


Add git and/or github to help menu

We want to add some instructions to new users, on how they can familiarize themselves with version control, Git, and Github.
Right now, the bot sends a welcome DM on Slack when a new user joins, and provides them some options on what they can learn for a language... Python, Ruby, etc.
We'd like to link them to some useful training on version control, so they can get started on self-taught courses right away. This can be as simple as pushing them to Github's current training offerings, as an MVP.

https://github.com/OperationCode/operationcode_bot/tree/master/views/help_menu and https://github.com/OperationCode/operationcode_bot/tree/master/lib are good places to start here.


IPAM enhancement

The PR is an improvement for IPAM module. It allows to efficiently use all possible pod subnets:
e.g.:
podNetworkCIDR: <IP_ADDRESS>/16
podNetworkPrefixLen: 24

nodeID
correspoinding podNetwork

1
<IP_ADDRESS>/24

2
<IP_ADDRESS>/24

...
...

255
10.1.255/24

256
<IP_ADDRESS>/24

Before the fix <IP_ADDRESS>/24 was not used.
In addition to the pod subnet usage, out of range checks were added for podsubnet, vxlanIP and nodeIP addresses.

Coverage decreased (-0.04%) to 76.452% when pulling 8a3eb284440912d71dc6ff34576593320325e5e6 on lukasmacko:master into 19f0398c50b39ab9d02d4ee93fbe48daa5264333 on contiv:master.


AsyncOperationStatus status strings mismatch

In the document page http://onedrive.github.io/resources/asyncJobStatus.htm,
the status strings are like "notStarted", but what is really returned can be "NotStarted" as in
{
'status': 'NotStarted',
'statusDescription': 'Completed 0/0 files; 0/0 bytes',
'percentageComplete': 0.0,
'operation': 'ItemCopy'
}

This may be a typo and better be corrected for consistency.
(BTW, I have been waiting for one hour for this ItemCopy thing to complete, but it hasn't even started...)

Fixing it now.

And it turns out the fact that the copy is stuck is another bug, so thanks for reporting that as well!

The casing issue with the "status" field should now be resolved.

Please reactivate if issue still exists for you.


Relative path not working for exclusion list

Hi Björn, let me start by saying I love your tool 😊
I'm using it (latest version, 2.0.1) in our repo and somehow the relative paths don't work for the exclusion list.
This is what I'm doing:
Find-Secret -Path C:\src\mycode\ -Excludelist C:\src\mycode\build\pipelines\.ignoreSecrets
The .ignoreSecrets file looks like this:
.\src\Webparts\myProject-myworkspaces\package-lock.json
.\src\Webparts\myProject-records\package-lock.json

and I'm getting failures:
PSSecretScanner Scan Results @ [ 17:44:57 - 17:45:08] 11.82s

   PatternName: Connection String

LineNumber Path
---------- ----
71955      C:\src\mycode\src\Webparts\myProject-records\package-lock.json
72027      C:\src\mycode\src\Webparts\myProject-records\package-lock.json
75279      C:\src\mycode\src\Webparts\myProject-records\package-lock.json

   PatternName: Google API Key

LineNumber Path
---------- ----
12754      C:\src\mycode\src\Webparts\myProject-myworkspaces\package-lock.json
48670      C:\src\mycode\src\Webparts\myProject-myworkspaces\package-lock.json

found 5 secrets!!!!!

If I add the full paths in the exclude list it works just fine:
C:\src\mycode\src\Webparts\myProject-myworkspaces\package-lock.json
C:\src\mycode\src\Webparts\myProject-records\package-lock.json

Incidentally they're a false positive, that's why I want to exclude them. For example, like 71955 looks like "version"<EMAIL_ADDRESS>and 12754 like "integrity": "sha512-LOOOONGSTRING==" (ok that's a hash that looks very much like a secret).

BTW I have a workaround as follows:
      $scanResults = Find-Secret -Path '$(System.DefaultWorkingDirectory)'
      $scanErrors = $scanResults.Results | Where-Object { $_.Filename -ne 'package-lock.json' }
      if ($scanErrors.Count -gt 0) {
        $scanErrors | Format-List
        throw "Secrets detected in $($scanErrors.Count) files"
      }

It's not great but it works.

Hello, and first of all, thank you for your kind words! It makes me super happy when people find my toys useful 🥰
Have been away for a conference, But I will look in to this as soon as I have the time.

Ok, I think I can see the issue. The exclude list is actually working as intended, but the docs does need an update.
Relative paths are always calculated using the .igoresecrets file as root source.
So, your file is C:\src\mycode\build\pipelines\.ignoreSecrets, and therefore, if you add a relative path such as .\src\Webparts\myProject-myworkspaces\package-lock.json the resolved path would be C:\src\mycode\build\pipelines\\src\Webparts\myProject-myworkspaces\package-lock.json
Basically, replace the . in your relative path with the full name of the folder that .ignorefiles is stored in.
I understand this can be confusing, but the reason for this decision is that it was the least confusing (and easiest to calculate) I could think of that worked whether we are in a git repo or not.
On sollution to your issue could be to add \..\ to your relative path so it becomes .\..\..\..\src\Webparts\myProject-myworkspaces\package-lock.json , although I do not really like this myself. It looks icky 😂
Other options would be either to store your .ignoresecrets file in the src folder, or use something like a build script to resolve paths before running it in the pipeline..
I am 100% open to any other options or ideas to make the ignoresecrets more flexible though..
As for right now I will clarify the docs on this. Hope this helps!

Oh I understand now. I can simply move the .ignoreSecrets file to the root. I'll give a try today and ping back. Many thanks!


Data from the future in the New Cases Per Day plot

Hello,
and thank you for this awesome service.
Today when I opened the english version of the page, I noticed that the default data range in New Cases Per Day plot is Feb26 2020 to Feb27 2021, with data from future dates showing non zero number of discharged from hospital. Perhaps some dates are handled as mere numbers instead of datetimes?

Hello,
Thank you for your report, the issue should be fixed now.
If there are any further issues, please let us know, otherwise feel free to close the issue.

Hello,
Thank you for your report, the issue should be fixed now.
If there are any further issues, please let us know, otherwise feel free to close the issue.


Apache configuration example is old

For newer apaches, it is necessary to change the permissions. It is needed to use:
AllowOverride All
Require all granted

Otherwise, apache just returns forbidden.
Full example here:
Listen 8080
#Debian path for wsgi
WSGISocketPrefix /var/run/apache2/wsgi

<VirtualHost *:8080>
        ServerName graphite
        DocumentRoot "/srv/graphite/webapp"
        ErrorLog /srv/graphite/storage/log/webapp/error.log
        CustomLog /srv/graphite/storage/log/webapp/access.log common
        # I've found that an equal number of processes & threads tends
        # to show the best performance for Graphite (ymmv).
        WSGIDaemonProcess graphite processes=5 threads=5 display-name='%{GROUP}' inactivity-timeout=120
        WSGIProcessGroup graphite
        WSGIApplicationGroup %{GLOBAL}
        WSGIImportScript /srv/graphite/conf/graphite.wsgi process-group=graphite application-group=%{GLOBAL}

        # XXX You will need to create this file! There is a graphite.wsgi.example
        # file in this directory that you can safely use, just copy it to graphite.wgsi
        WSGIScriptAlias / /srv/graphite/conf/graphite.wsgi

        Alias /content/ /srv/graphite/webapp/content/
        <Location "/content/">
                AllowOverride All
                Require all granted
        </Location>

        # XXX In order for the django admin site media to work you
        # must change @DJANGO_ROOT@ to be the path to your django
        # installation, which is probably something like:
        # /usr/lib/python2.6/site-packages/django
#        Alias /media/ "@DJANGO_ROOT@/contrib/admin/media/"
        <Location "/media/">
                AllowOverride All
                Require all granted
        </Location>
        # The graphite.wsgi file has to be accessible by apache. It won't
        # be visible to clients because of the DocumentRoot though.
        <Directory /srv/graphite/conf/>
                Options All
                AllowOverride All
                Require all granted
        </Directory>
</VirtualHost>

Two years later :smile:  Did you ever get to look at this @gwaldo?

@Ismael @ffMathy To clarify, was this actually in reference to the sample vhost? I assumed earlier this was a documentation issue but now I'm not so sure.

Looks like the sample vhost was updated back in https://github.com/graphite-project/graphite-web/pull/780 to address the newer access control syntax.

Yeah, I assume by your title that this was regarding the config example. That was indeed updated back in July 2014 (after your issue was opened).


linter: rule fixer improvements

I've been adding and repairing fixers to a lot of rules, but my ad-hoc approach
is not sustainable. This issue is a call for assistance, and tracks fixer
progress for each rule.
Prerequisites

[x] #4187
[ ] #4211
https://github.com/oxc-project/oxlint-ecosystem-ci/issues/19

Rules
For rules with an existing fixer:

If the rule has a fixer (using diagnostic_with_fix), ensure that there are
no cases where the fixer could create a syntax error or semantically different
code.
If the fix could be correct in some cases, but could produce semantically
differently different code in others, use diagnostic_with_fix_dangerous.
Link this issue to your PR updating the rule's fixer, and a maintainer will
update this table. If no changes are needed, leave a comment here and we'll
also update the table.

For rules without a fixer:

Check if a fixer could be safely added in some cases. If so, create a PR with
a fixer implementation that links to this issue.
If no fixer can (or should) be created for the rule, leave a comment below and
a maintainer will update the table.

Legend

: Not checked
✅ Has a working fixer
🚧 No fixer, but one could be added
🚫 No fixer, and one cannot be added

Correctness (159):

Code that is outright wrong or useless.

Rule name
Source
Status

no-await-in-loop
eslint

no-accumulating-spread
oxc

jsx-no-jsx-as-prop
react_perf

jsx-no-new-array-as-prop
react_perf

jsx-no-new-function-as-prop
react_perf

jsx-no-new-object-as-prop
react_perf

Restriction (49):

Lints which prevent the use of language and library features. Must not be enabled as a whole, should be considered on a case-by-case basis before enabling.

Rule name
Source
Status

default-case
eslint

no-bitwise
eslint

no-console
eslint

no-div-regex
eslint

no-empty
eslint

no-empty-function
eslint

no-eq-null
eslint

no-eval
eslint

no-iterator
eslint

no-proto
eslint

no-regex-spaces
eslint

no-restricted-globals
eslint

no-undefined
eslint

no-unsafe-optional-chaining
eslint

no-var
eslint

no-void
eslint

unicode-bom
eslint

no-amd
import

no-cycle
import

no-default-export
import

check-access
jsdoc

empty-tags
jsdoc

bad-bitwise-operator
oxc

no-async-await
oxc

no-barrel-file
oxc

no-const-enum
oxc

no-optional-chaining
oxc

no-rest-spread-properties
oxc

button-has-type
react

no-danger
react

no-unknown-property
react

explicit-function-return-type
typescript

no-dynamic-delete
typescript

no-explicit-any
typescript

no-import-type-side-effects
typescript

no-non-null-asserted-nullish-coalescing
typescript

no-non-null-assertion
typescript

no-var-requires
typescript

prefer-literal-enum-member
typescript

no-abusive-eslint-disable
unicorn

no-anonymous-default-export
unicorn

no-array-for-each
unicorn

no-array-reduce
unicorn

no-magic-array-flat-depth
unicorn

no-nested-ternary
unicorn

no-process-exit
unicorn

prefer-modern-math-apis
unicorn

prefer-node-protocol
unicorn

prefer-number-properties
unicorn

Suspicious (14):
code that is most likely wrong or useless.

Rule name
Source
Status

no-new
eslint

no-useless-concat
eslint

no-useless-constructor
eslint

no-duplicates
import

no-named-as-default
import

no-named-as-default-member
import

no-self-import
import

no-commented-out-tests
jest

approx-constant
oxc

misrefactored-assign-op
oxc

jsx-no-comment-textnodes
react

react-in-jsx-scope
react

no-unnecessary-type-constraint
typescript

prefer-add-event-listener
unicorn

Pedantic (66):

Lints which are rather strict or have occasional false positives.

Rule name
Source
Status

array-callback-return
eslint

eqeqeq
eslint

max-classes-per-file
eslint

max-lines
eslint

no-array-constructor
eslint

no-case-declarations
eslint

no-constructor-return
eslint

no-fallthrough
eslint

no-inner-declarations
eslint

no-new-wrappers
eslint

no-prototype-builtins
eslint

no-redeclare
eslint

no-self-compare
eslint

radix
eslint

require-await
eslint

symbol-description
eslint

max-dependencies
import

require-param
jsdoc

require-param-description
jsdoc

require-param-name
jsdoc

require-param-type
jsdoc

require-returns
jsdoc

require-returns-description
jsdoc

require-returns-type
jsdoc

checked-requires-onchange-or-readonly
react

jsx-no-useless-fragment
react

no-unescaped-entities
react

ban-ts-comment
typescript

ban-types
typescript

no-duplicate-enum-values
typescript

prefer-enum-initializers
typescript

prefer-ts-expect-error
typescript

escape-case
unicorn

explicit-length-check
unicorn

new-for-builtins
unicorn

no-hex-escape
unicorn

no-instanceof-array
unicorn

no-lonely-if
unicorn

no-negated-condition
unicorn

no-negation-in-equality-check
unicorn

no-new-buffer
unicorn

no-object-as-default-parameter
unicorn

no-static-only-class
unicorn

no-this-assignment
unicorn

no-typeof-undefined
unicorn

no-unreadable-iife
unicorn

no-useless-promise-resolve-reject
unicorn

no-useless-switch-case
unicorn

prefer-array-flat
unicorn

prefer-array-some
unicorn

prefer-blob-reading-methods
unicorn

prefer-code-point
unicorn

prefer-date-now
unicorn

prefer-dom-node-append
unicorn

prefer-dom-node-dataset
unicorn

prefer-dom-node-remove
unicorn

prefer-event-target
unicorn

prefer-math-trunc
unicorn

prefer-native-coercion-functions
unicorn

prefer-prototype-methods
unicorn

prefer-query-selector
unicorn

prefer-regexp-test
unicorn

prefer-string-replace-all
unicorn

prefer-string-slice
unicorn

prefer-type-error
unicorn

require-number-to-fixed-digits-argument
unicorn

Style (80):

Code that should be written in a more idiomatic way.

Rule name
Source
Status

default-case-last
eslint

default-param-last
eslint

guard-for-in
eslint

max-params
eslint

no-continue
eslint

no-multi-str
eslint

no-script-url
eslint

no-template-curly-in-string
eslint

no-ternary
eslint

prefer-exponentiation-operator
eslint

sort-imports
eslint

consistent-test-it
jest

max-expects
jest

max-nested-describe
jest

no-alias-methods
jest

no-confusing-set-timeout
jest

no-deprecated-functions
jest

no-done-callback
jest

no-duplicate-hooks
jest

no-hooks
jest

no-identical-title
jest

no-interpolation-in-snapshots
jest

no-jasmine-globals
jest

no-large-snapshots
jest

no-mocks-import
jest

no-restricted-jest-methods
jest

no-restricted-matchers
jest

no-test-prefixes
jest

no-test-return-statement
jest

no-untyped-mock-factory
jest

prefer-called-with
jest

prefer-comparison-matcher
jest

prefer-equality-matcher
jest

prefer-expect-resolves
jest

prefer-hooks-on-top
jest

prefer-jest-mocked
jest

prefer-lowercase-title
jest

prefer-mock-promise-shorthand
jest

prefer-spy-on
jest

prefer-strict-equal
jest

prefer-to-be
jest

prefer-to-contain
jest

prefer-to-have-length
jest

prefer-todo
jest

require-hook
jest

require-top-level-describe
jest

no-set-state
react

prefer-es-6-class
react

adjacent-overload-signatures
typescript

array-type
typescript

ban-tslint-comment
typescript

consistent-indexed-object-style
typescript

consistent-type-definitions
typescript

no-empty-interface
typescript

prefer-for-of
typescript

prefer-function-type
typescript

catch-error-name
unicorn

empty-brace-spaces
unicorn

error-message
unicorn

filename-case
unicorn

no-await-expression-member
unicorn

no-console-spaces
unicorn

no-null
unicorn

no-unreadable-array-destructuring
unicorn

no-zero-fractions
unicorn

number-literal-case
unicorn

numeric-separators-style
unicorn

prefer-array-flat-map
unicorn

prefer-dom-node-text-content
unicorn

prefer-includes
unicorn

prefer-logical-operator-over-ternary
unicorn

prefer-modern-dom-apis
unicorn

prefer-optional-catch-binding
unicorn

prefer-reflect-apply
unicorn

prefer-spread
unicorn

prefer-string-trim-start-end
unicorn

require-array-join-separator
unicorn

switch-case-braces
unicorn

text-encoding-identifier-case
unicorn

throw-new-error
unicorn

Nursery (9):

New lints that are still under development.

Rule name
Source
Status

constructor-super
eslint

getter-return
eslint

no-undef
eslint

no-unreachable
eslint

export
import

require-render-return
react

rules-of-hooks
react

no-side-effects-in-initialization
tree_shaking

consistent-type-imports
typescript

These tables were created by running oxlint --rules on commit ca0b4fa0.

no-const-assign cannot have a fixer because we cannot infer the inter of the user

Related to fixes, can oxlint's diagnostic also print that a fix is available. Ruff for example shows:
[jelle@natrium][~/projects/oxc]%ruff check foo.py
foo.py:2:8: F401 [*] `os` imported but unused
  |
1 | #/usr/bin/python
2 | import os
  |        ^^ F401
  |
  = help: Remove unused import: `os`

Found 1 error.
[*] 1 fixable with the `--fix` option.

oxlint prints no information at the moment:
[jelle@natrium][~/projects/oxc]%cargo run --bin oxlint --  -A all -D prefer-string-trim-start-end foo.js
   Compiling oxc_linter v0.6.0 (/home/jelle/projects/oxc/crates/oxc_linter)
   Compiling oxlint v0.6.0 (/home/jelle/projects/oxc/apps/oxlint)
    Finished `dev` profile [unoptimized] target(s) in 3.69s
     Running `target/debug/oxlint -A all -D prefer-string-trim-start-end foo.js`

  × eslint-plugin-unicorn(prefer-string-trim-start-end): Prefer `trimStart` over `trimLeft`
    ╭─[foo.js:34:5]
 33 │ const foo = "lol";
 34 │ foo.trimLeft();
    ·     ────────
    ╰────
  help: Replace with `trimStart`

Finished in 4ms on 1 file with 1 rules using 16 threads.
Found 0 warnings and 1 error.

@jelly check out my PR with suggestions; it does this.

@jelly check out my PR with suggestions; it does this.

#4223

I think another task should be added, rules with fixers without tests. Last night I discovered no-zero-fractions currently produces broken code. See the test cases https://github.com/oxc-project/oxc/commit/ff72fcd3ea03f57dfaf6ae21fa326d5981f68285
  × eslint-plugin-unicorn(no-zero-fractions): Don't use a dangling dot in the number.
   ╭─[bar.js:7:14]
 6 │ const foo4 = -1.e+10;
 7 │ const foo5 = 1.e10;
   ·              ─────
 8 │ const foo6 = .0;
   ╰────
  help: Replace the number literal with `110`

While:
> 1.e10
10000000000

I simply copied some of the failing test cases into a JS file, made a backup and ran eslint fix on it as unicorn sadly has no tests for the fixer it seems.

For eslint itself, some rules have fixers, while others do not.
For those eslint without fixers, is it not recommended to do it with oxc, or is it okay to add it as a unique feature of oxc?

For eslint itself, some rules have fixers, while others do not. For those eslint without fixers, is it not recommended to do it with oxc, or is it okay to add it as a unique feature of oxc?

I'm not sure if I'm getting it right or not, So feel free to correct me.

If you are talking about adding new fixers where there isn't one in eslint(or other linting solutions), It is completely welcomed here, We want backward compatibility with eslint as a drop-in replacement for most parts; But as long as we are adding(and not subtracting) features, It is allowed with no restrictions whatsoever.
Although for non-exiting fixers/linters, you'd have to write through tests - since there isn't any source to borrow the tests from - and it might need a more rigorous review process to make sure it is doing the intended behavior we have in mind and assess the risks for the fixer(in case it have to be a dangerous fix).
With that said if you ever think the change you have in mind might be controversial it'd be best to create an issue for it beforehand or ask for reviews early in the process to make sure there aren't any strong oppositions against it. The last thing we want is to allow contributors' time to go to waste.
Let me know if I didn't answer your question.

For  itself, some rules have fixers, while others do not. For those  without fixers, is it not recommended to do it with , or is it okay to add it as a unique feature of ?eslint``eslint``oxc``oxc

I'm not sure if I'm getting it right or not, So feel free to correct me.
If you are talking about adding new fixers where there isn't one in eslint(or other linting solutions), It is completely welcomed here, We want backward compatibility with eslint as a drop-in replacement for most parts; But as long as we are adding(and not subtracting) features, It is allowed with no restrictions whatsoever. As long as it makes sense and is useful.
Although for non-exiting fixers/linters, you'd have to write through tests - since there isn't any source to borrow the tests from - and it might need a more rigorous review process to make sure it is doing the intended behavior we have in mind and assess the risks for the fixer(in case it have to be a dangerous fix).
With that said if you ever think the change you have in mind might be controversial it'd be best to create an issue for it beforehand or ask for reviews early in the process to make sure there aren't any strong oppositions against it. The last thing we want is to allow contributors' time to go to waste.
Let me know if I didn't answer your question.

Yes, that's what I wanted to ask.
If we prioritize which one to do first, would it be recommended in Oxc's plan to start with existing fixers (such as in ESLint)?

@heygsc it depends. I'd recommend starting there if you're just getting your feet wet. Porting existing fixers is definitely easier than writing new ones.
In some cases, rules intentionally do not have auto fixes for DX reasons. For example, imagine an unused import getting deleted when your editor saves a file.  For those cases, we've added infrastructure for suggestions and "dangerous" fixes, which do not get applied when --fix is used, but instead get their own CLI flags.

@heygsc it depends. I'd recommend starting there if you're just getting your feet wet. Porting existing fixers is definitely easier than writing new ones.
In some cases, rules intentionally do not have auto fixes for DX reasons. For example, imagine an unused import getting deleted when your editor saves a file.  For those cases, we've added infrastructure for suggestions and "dangerous" fixes, which do not get applied when --fix is used, but instead get their own CLI flags.

What you said makes sense. Thank you.

Close as stale given no progress has been made, but feel free to implement fixers when needed.


Inviting A Successor/Maintainer To PyInquirer Future

Hi all,
I want to thank everyone who has taken their time to create Pull requests and Issues on PyInquirer and as well as this Repo hitting 1.2k.
When I started working on PyIquirer, I was working on a CLI project in Python that required us to ask the user prompt question to be able to make decisions. Blessings, blessed and python-inquirer are similar that seems to do half of what needs to be done and also have a lot of compatibility issues with Windows.
Most issues either with ncurses or something similar, I was able to find a project that has ncurses ports (prompt-toolkit) and fixed the Windows issue.
During the process, I enjoyed working on the project and was able to use it finally in the original project I was working on. I wrote about PyInquirer in most of my CLI articles and so on.
This was actually my first openly public open source project and a lot of people started using it as well. I was really new to open source and I had no idea how to manage it either.
The issue started when managing this with my normal daily work. From answering issues to PRs. This was becoming too tasking for me as I juggle between remote jobs and writing gigs.
Many times a lot of people reached out to me on the progress and way forward, I could be available for some time and caught up with work again. The cycle goes on and goes on again.
A lot of people including companies are using this in their project, software, and CLI packages and they heavily depend on this to ask their users for inputs. Definitely, a lot of people would like to contribute to what's missing,  report bugs, create issues and PRs.
However, due to my work schedule, these issues and PRs are usually left unattended to leaving people in circles and either fixing it locally or look for another option.
I would not want this project to be another dead project, so I would be accepting a successor/maintainer that would help move this project forward, maintain, and contribute to this project.
I am really sorry for the inconvenience this must have caused everyone using this package and I would be happy if this kicks off and back to its active state.
If you like this project and you would like to move this forward, send me a message on:
Email<EMAIL_ADDRESS>Twitter: twitter.com/@oyetoket
PS: You must be familiar with python and command-line applications. Thanks.
Btw, I am currently the lead engineer at https://bitpowr.com for blockchain payment and wallet solutions. You can also reach out to me if you have any inquiries on that.

Maybe you could try to upstream some parts of this as new prompt options in prompt_toolkit?

It's a shame but I'm also really grateful that you built and provided it at all, as it helped me in my learning of python. I made something that just about worked and was useful.

I could maintain it very well @CITGuru

Hi!
I'm a staff engineer for Freshbooks, and I've been working in the dev area for more than 15 years.
I'm using PyInquirer in an IDP tool I developed for my company.
I can join in maintaining the project, as it's in my interest, we are using new Python versions, and PyInquirer is incompatible. I can solve it by forking it and solving it for me, but it would be nice if I could help the community as well.
My company profile is: https://github.com/fbrodrigorezino

Any update on this? Seems like there were some volunteers to take over the project, but has there been any progress on this? @CITGuru

@CITGuru yo, we can see you are active on github :smirk:


each row should be a single string, with cells being offsets into it

why did i think this would be a good idea?


Bump EOF EEST tests to v1.1.1

Bump EOF suite to https://github.com/ethereum/execution-spec-tests/releases/tag/eip7692%40v1.1.1
Generated with evmone. Allows to mark revm as up to date in the testing readiness matrix, for both EEST and evmone I believe.
Fixtures can be checked against by running the command in the meta file

I think evemone suite has different tests, those too need to be imported?


errors for failed reconstruction jobs

@Magdoll
when Coding Genome Reconstruction jobs were runing,some jobs were failed. If the file in.fa in failed_job_job_directory was less than 100kb, i could add --nx_cycle_detection and tried bigger k to solve the problems.
however, if the file in.fa in failed_job_job_directory was bigger than 100kb, --nx_cycle_detection and bigger k didnt work. In this case, some directories were produced in failed_job_job_directory whose name begin with "split_". And then a CYCLE_DETECTED file  whose size was 0 would be produced in one of "split_n" directories. Finally, there were no new files produced though  Coding Genome Reconstruction jobs were runing. An example was given below:
a. cd ~/12495_0/  &  ls
hello.log
in.fa
in.weights
split_0
split_1
split_2
split_3
split_4
split_5
b. cd split_0  &  ls
CYCLE_DETECTED    #size is 0
in.fa
in.trimmed.fa
in.weights
c. cd ../split_1  &  ls
in.fa
in.weights    # split_2 - split_5 also only have in.fa and in.weights

Hi @qiuyixmm ,
This is a case where actually one of the splits (large inputs get split into sub-tasks and merged at the end) end up with a cycle. An empty outfile CYCLE_DETECTED is produced whenever cycles are detected and the job is aborted. I may be not dealing with failed jobs properly in split cases.
Would you be willing to share one example of a large (split-up) input that had a cycle in one of the splits?
If you provide an email, I can send a request to have you upload the file securely.
Thanks
--Liz

Hello@Magdoll
this is my email address<EMAIL_ADDRESS>

Hi @qiuyixmm ,
A request for file upload has been sent to the email.
I think it would be helpful to fix these failed jobs because these are the jobs that have a large number of input transcripts. Excluding them from your dataset means excluding results of (potentially) dominant transcripts.
--Liz

Hi @qiuyixmm ,
I looked at the input sequences. It is extremely repetitive, which is why it originally failed. I lifted the limit of kmer size (-k parameter) which used to be capped at 200. This input set is so repetitive that I was not able to complete it at -k 200, but I tried -k 300 and it was able to complete, however larger kmer sizes often means less reconstruction (hence, more sequences in the output file cogent2.fa).
I've committed a new version v3.7 to Cogent that allows you to use larger -k.
The result has been emailed to you.
--Liz

@Magdoll
Surprisingly, all my failed jobs have been completed thanks to your advic. Thanks!


[google_sign_in] Fix crash on iOS caused by null hostedDomain

Description
Fixes google_sign_in crash on iOS when calling signIn() when hostedDomain is null.
Related Issues
Fixes flutter/flutter#44564
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
[x] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See [Contributor Guide]).
[x] All existing and new tests are passing.
[x] I updated/added relevant documentation (doc comments with ///).
[x] The analyzer (flutter analyze) does not report any problems on my PR.
[x] I read and followed the [Flutter Style Guide].
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[x] I updated pubspec.yaml with an appropriate new version according to the [pub versioning philosophy].
[x] I updated CHANGELOG.md to add a description of the change.
[x] I signed the [CLA].
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
[x] No, this is not a breaking change.

Hi @Hixie ,
My PR address two causes for a crash on iOS, although there may be more potential causes that all seem to be going under the one umbrella.
The first change I made prevented the GoogleSignIn native code from crashing by ensuring hostedDomain was never null. But in the 4 months since I submitted this, it seems the underlying issue in the GoogleSignIn native code was fixed, thereby making my fix redundant. So I've reverted that change, and that also resolved a problem with the tests that I broke.
The second change was to delete this line:
        [e raise];

This will immediately crash the app and serves no useful purpose (any uncaught exception on the Objective C side will crash the whole app). The line immediately prior to this actually sends a FlutterError over the platform channel, which is a good idea, but this is all for naught if we crash the app immediately afterwards.
I don't think any specific new tests are required or possible for this one line change.
As for all the other potential causes of an iOS crash, I don't know if this will help, but it may be a good idea to wrap the entire handleMethodCall in a try/catch, and forward the details of the exception over the platform channel in a FlutterError, since any uncaught exceptions will cause the whole Flutter app to crash.
In any case, I will leave that for someone else to do because I wrote the original PR 4 months ago on a rented MacInCloud instance and it is not convenient for me to do so.

Perhaps some can help explain why lint_darwin_plugins failed and what I need to do if anything? I can't imagine that failed because of anything I did if you look at the diffs.
Note: I have heard that the hostedDomain check that I took out actually still is required. So I'll need to add that back into the PR. This time, I'll add it in the Objective C code rather than as a default parameter in Dart so that the tests don't need to be rewritten.

@Hixie can you check why the submit-queue CI check failed? It doesn't appear to be anything caused by my change:
The following packages have analyzer errors (see above):
 * e2e

Maybe this was caused by the previous PR before mine:
## 4.5.2

* Update package:e2e reference to use the local version in the flutter/plugins
  repository.

As for my PR, I have added the hostedDomain null check back into the PR, and moved it into the Objective C code. This PR doesn't introduce a material change to the API, and it works as before, only it guards against a couple of reasons for the iOS crash.

Hi @ryanheise. Do you plan to work on adding tests for this PR? :) https://github.com/flutter/plugins/pull/2599 has set up some unit tests for the plugin, maybe you can follow that pattern?

Hi @cyanglaz thanks for pointing to that. I was trying to learn how to do this from https://flutter.dev/docs/cookbook/testing but what you describe as unit testing sounds like it would only be possible in flutter with integration testing so that it can run on device. Maybe that is what e2e helps with, but is there a guide for this or another PR you can point me to that only adds a single test?
I'm also not sure how to test for the presence or absence of the GoogleService-Info.plist file, or presence and absence of a section in the Runner/Info.plist file. I can at least try to add a test for a null hostedDomain.

For the purpose of this PR, although it is great, it might not be necessary to test if [GIDSignIn sharedInstance].hostedDomain actually works. Because [GIDSignIn sharedInstance].hostedDomain is from the google sign in sdk and we can assume it works.
However, we do want to test that if call.arguments[@"hostedDomain"] will set the correct value in [GIDSignIn sharedInstance].hostedDomain. An unit test with mocks would be sufficient.

FWIW, if the bug was that the code crashed when doing X, the usual test is one that does X and verifies that the code doesn't crash. :-)

Adding to the backlog; this is something we should add tests for as time allows so that it can be landed (modulo the question about the redispatch to main).

@jmagman @cyanglaz Could someone from the iOS platform team adopt this? It's a fix for a known crasher that just needs to be cleaned up and tested, so it would be great to get over the line.

@stuartmorgan I'll take it. It could be some holiday chill hack for me :)

The same issue was fixed in https://github.com/flutter/plugins/pull/3805. I'm going to close this.


JS-API: expose TableQuery methods

This should also be documented well in the JS API, a sample should be provided, and a short post on the community should be created in this thread: https://community.datagrok.ai/t/javascript-api-updates/526


Update terraform-provision pipeline to use hardened images

Pipeline now uses hardened images
Replaced python image with the general-task image