[win] Debugging/running on VSCode on Windows doesn't work #8851

COLAMAroro · 2024-02-11T12:04:49Z

What version of Bun is running?

1.0.26-canary.51+2264bb3d0

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64

What steps can reproduce the bug?

Install the official Bun VSCode Extension.

Configure the recommended .vscode/launch.json file

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "bun",
      "request": "launch",
      "name": "Debug Bun",

      // The path to a JavaScript or TypeScript file to run.
      "program": "${file}",

      // The arguments to pass to the program, if any.
      "args": [],

      // The working directory of the program.
      "cwd": "${workspaceFolder}",

      // The environment variables to pass to the program.
      "env": {},

      // If the environment variables should not be inherited from the parent process.
      "strictEnv": false,

      // If the program should be run in watch mode.
      // This is equivalent to passing `--watch` to the `bun` executable.
      // You can also set this to "hot" to enable hot reloading using `--hot`.
      "watchMode": false,

      // If the debugger should stop on the first line of the program.
      "stopOnEntry": false,

      // If the debugger should be disabled. (for example, breakpoints will not be hit)
      "noDebug": false,

      // The path to the `bun` executable, defaults to your `PATH` environment variable.
      "runtime": "bun",

      // The arguments to pass to the `bun` executable, if any.
      // Unlike `args`, these are passed to the executable itself, not the program.
      "runtimeArgs": [],
    },
    {
      "type": "bun",
      "request": "attach",
      "name": "Attach to Bun",

      // The URL of the WebSocket inspector to attach to.
      // This value can be retrieved by using `bun --inspect`.
      "url": "ws://localhost:6499/",
    }
  ]
}

Create a JS or TS file, and either run "Run File" or "Debug File"

What is the expected behavior?

It should be possible to run or debug the script inside VSCode

What do you see instead?

The debugging/running immediately stops, with this error appearing in the debug console:

Failed to start inspector:
 40 |     },
41 |     close: () => {
42 |       writer.close(), pendingMessages.length = 0;
43 |     }
44 |   };
45 | }, parseUrl = function(input) {
                                                 ^
TypeError: "ws+unix://C:\Users\[REDACTED]\AppData\Local\Temp\8e3aij0xu7f.sock?wait=1" cannot be parsed as a URL.
      at internal:debugger:45:45
      at new Debugger (internal:debugger:124:27)
      at internal:debugger:100:25

Additional information

Bun extension version: v0.0.12

VSCode "about" window:

Version : 1.86.1 (system setup)
Validation : 31c37ee8f63491495ac49e43b8544550fbae4533
Date : 2024-02-07T09:08:20.941Z
Electron : 27.2.3
ElectronBuildId : 26495564
Chromium : 118.0.5993.159
Node.js : 18.17.1
V8 : 11.8.172.18-electron.0
Système d’exploitation : Windows_NT x64 10.0.22631

The text was updated successfully, but these errors were encountered:

Electroid · 2024-02-11T16:35:30Z

Yea, Windows doesn't support UNIX sockets. We'll have to fix this in the VSCode extension

COLAMAroro · 2024-02-13T15:35:09Z

I've tried, Bun has no issues with UNIX sockets on Windows (which have supported them since around 2017).

The following code runs fine on my Windows machine

import * as net from "net"
import { userInfo } from "os";

let responded = false;

var server = net.createServer(function (socket) {
    socket.on("data", function (data) {
        let message = data.toString();
        console.log("Message received from client: " + message);
        socket.write("Hello " + message + " !");
        responded = true;
    })
})
server.listen("./test.sock");

let client = net.connect("./test.sock").
    on('data', (data) => {
        let message = data.toString();
        console.log("Message received from server: " + message);
    })

client.write(userInfo().username);

while (!responded) {
    await Bun.sleep(10);
}

client.destroy();
server.close();

Unless the websocket debugger falls into one of the unsupported type of socket, I think the root cause is elsewhere.

Also of note, Bun supports UNIX Sockets on Windows, while NodeJS doesn't even bother :D

tonka3000 · 2024-04-01T18:29:38Z

This issue still exist with the 1.1 stable version on Windows.

webdevrr · 2024-04-02T13:41:11Z

Same issue here for 1.1 on Windows

otavio-silva · 2024-04-02T22:49:18Z

Having the same exact issue on 1.1.0, any news on this?

YuziO2 · 2024-04-09T06:40:02Z

1.1.3 the same

MusiCode1 · 2024-04-25T20:24:36Z

The problem is still here.

Maybe you should write that the extension does not work in Windows?
Is there any bypass in the meantime?

haingo87 · 2024-05-04T04:14:03Z

Having the same issue. Hope this issue gets priority.

GuiLin0773 · 2024-05-19T03:28:53Z

try half a day,and finally get here.hope to solve the bug

Forgifted · 2024-05-22T18:45:06Z

Bug reproduced in 1.1.9.

fesieg · 2024-05-24T12:00:55Z

having this issue in 1.1.9 too

Jarred-Sumner · 2024-05-26T11:29:16Z

Confirming this does not work. We haven't had time to address this yet.

The strange thing is we do support unix domain sockets on Windows.

So it's something most likely to do with the VSCode extension.

If a contributor wants to investigate this:

VSCode extension code

Debugger is initialized here:

bun/src/bun.js/javascript.zig

Lines 1217 to 1235 in af4e844

    
           fn start(other_vm: *VirtualMachine) void { 
        
               JSC.markBinding(@src()); 
        
               var this = VirtualMachine.get(); 
        
               const debugger = other_vm.debugger.?; 
        
               if (debugger.unix.len > 0) { 
        
                   var url = bun.String.createUTF8(debugger.unix); 
        
                   Bun__startJSDebuggerThread(this.global, debugger.script_execution_context_id, &url); 
        
               } 
        
               if (debugger.path_or_port) |path_or_port| { 
        
                   var url = bun.String.createUTF8(path_or_port); 
        
                   Bun__startJSDebuggerThread(this.global, debugger.script_execution_context_id, &url); 
        
               } 
        
               this.global.handleRejectedPromises();

The debugger thread's JS is here:

bun/src/js/internal/debugger.ts

Lines 266 to 296 in af4e844

    
           function parseUrl(input: string): URL { 
        
             if (input.startsWith("ws://") || input.startsWith("ws+unix://") || input.startsWith("unix://")) { 
        
               return new URL(input); 
        
             } 
        
             const url = new URL(`ws://${defaultHostname}:${defaultPort}/${randomId()}`); 
        
             for (const part of input.split(/(\[[a-z0-9:]+\])|:/).filter(Boolean)) { 
        
               if (/^\d+$/.test(part)) { 
        
                 url.port = part; 
        
                 continue; 
        
               } 
        
               if (part.startsWith("[")) { 
        
                 url.hostname = part; 
        
                 continue; 
        
               } 
        
               if (part.startsWith("/")) { 
        
                 url.pathname = part; 
        
                 continue; 
        
               } 
        
               const [hostname, ...pathnames] = part.split("/"); 
        
               if (/^\d+$/.test(hostname)) { 
        
                 url.port = hostname; 
        
               } else { 
        
                 url.hostname = hostname; 
        
               } 
        
               if (pathnames.length) { 
        
                 url.pathname = `/${pathnames.join("/")}`; 
        
               } 
        
             } 
        
             return url; 
        
           }

It's expecting an environment variable named BUN_INSPECT:

bun/src/bun.js/javascript.zig

Lines 1578 to 1580 in af4e844

    
           fn configureDebugger(this: *VirtualMachine, debugger: bun.CLI.Command.Debugger) void { 
        
               const unix = bun.getenvZ("BUN_INSPECT") orelse ""; 
        
               const set_breakpoint_on_first_line = unix.len > 0 and strings.endsWith(unix, "?break=1");

LightQuanta · 2024-05-26T18:17:27Z

This problem appears to be related to URL parsing on Windows.
When tested on Node Cli, new URL() does not parse some URLs with Windows file paths.

For example, ws+unix://C:\\some\\folder is not considered a valid URL:

> new URL('ws+unix://C:\\test\\folder')
Uncaught TypeError: Invalid URL
    at new URL (node:internal/url:797:36) {
  code: 'ERR_INVALID_URL',
  input: 'ws+unix://C:\\test\\folder'
}

Node treats all backslashs in URLs as invalid(except for certain protocols like file:/// and ws://). This can be solved by using slashs instead of backslashes:

> new URL('ws+unix://C:/test/folder')
URL {
  href: 'ws+unix://C/test/folder',
  protocol: 'ws+unix:',
  host: 'C',
  hostname: 'C',
  pathname: '/test/folder',
  ...
}

However this introduces a new problem: the driver letter C: and the pathname are parsed incorrectly. This can be fixed by using ws+unix:/// instead of ws+unix://:

> new URL('ws+unix:///C:/test/folder')
URL {
  href: 'ws+unix:///C:/test/folder',
  protocol: 'ws+unix:',
  pathname: '/C:/test/folder',
  ...
}

There's still an extra slash before the pathname, causing packages/bun-vscode/scripts/test.mjs and packages/bun-vscode/scripts/build.mjs not working on Windows. By removing the extra slash, this can be solved too.

These are the issues I attempted to fix in the PR, but I'm uncertain if the changes in src/js/internal/debugger.ts can work correctly since I cannot build bun for windows successfully. Also I'm not sure if (require("node:os")?.type() ?? "") === "Windows_NT" is the correct way to detect the operating system. Is there a better way to do this?

Code-Quake · 2024-06-10T17:08:34Z

Any update on a fix for this? I am having the same problem.

Swarz · 2024-06-15T08:56:43Z

Hurry up, please

itseramin · 2024-07-05T14:25:35Z

Let's go guys!

softestpoly · 2024-07-05T22:28:50Z

I'm having the same problem

Failed to start inspector:
40 |       }
41 |     },
42 |     close: () => {
43 |       writer.close(), pendingMessages.length = 0;
44 |     }
45 | }, parseUrl = function(input) {
                           ^
TypeError: "ws+unix://C:\Users\Poly\AppData\Local\Temp\7h38vq7qrji.sock?wait=1" cannot be parsed as a URL.
      at internal:debugger:45:23
      at new Debugger (internal:debugger:124:14)
      at internal:debugger:100:13

amir141592 · 2024-07-18T13:44:15Z

I still have this issue

dayblox · 2024-07-21T13:12:56Z

Still the case on 1.1.21-canary.1+738947bde

zs782306174 · 2024-07-22T05:42:31Z

Brother, hasn't this problem been solved yet? If it's resolved, you should update the new version immediately

elemental-mind · 2024-07-28T09:36:48Z

Reposting here from the other issue:

You can attach with the following config in launch.json:

        {
            "name": "Attach to bun",
            "type": "bun",
            "request": "attach",
            "url": "ws://127.0.0.1:5000/test",
            "internalConsoleOptions": "openOnSessionStart"
        }

...and then running bun --inspect-brk=127.0.0.1:5000/test test.ts and then launching the debugger.

But once attached there is no output in the debugger console and breakpoints do not get hit. Stepping through the code with F10 evaluates the code line by line, though, but without giving any visual feedback or variables in the debug panel of VSCode.

So there are a lot more issues to be fixed beyond the initial connection problem.

But maybe it works for someone else?

nick4814 · 2024-07-29T02:30:10Z

Hopefully this gets sorted out soon. I closed a duplicate issue of this today. I did not see this issue when I created the duplicate. Closed duplicate issue #12735.

Node is getting typescript first class as well. Surely Bun supports this before Node JS officially does.
Node JS adds experimental TS support

nick4814 · 2024-07-29T02:37:06Z

I've tried, Bun has no issues with UNIX sockets on Windows (which have supported them since around 2017).

The following code runs fine on my Windows machine

import * as net from "net"
import { userInfo } from "os";

let responded = false;

var server = net.createServer(function (socket) {
    socket.on("data", function (data) {
        let message = data.toString();
        console.log("Message received from client: " + message);
        socket.write("Hello " + message + " !");
        responded = true;
    })
})
server.listen("./test.sock");

let client = net.connect("./test.sock").
    on('data', (data) => {
        let message = data.toString();
        console.log("Message received from server: " + message);
    })

client.write(userInfo().username);

while (!responded) {
    await Bun.sleep(10);
}

client.destroy();
server.close();

Unless the websocket debugger falls into one of the unsupported type of socket, I think the root cause is elsewhere.

Also of note, Bun supports UNIX Sockets on Windows, while NodeJS doesn't even bother :D

I assume you are using WSL? Debugging any TS doesn't work for me. Can you provide information on your setup/OS/etc?

COLAMAroro · 2024-07-29T07:25:40Z

I assume you are using WSL? Debugging any TS doesn't work for me. Can you provide information on your setup/OS/etc?

No I confirm, it was running natively on Windows, not via WSL. Setup is still in the OP 🙂

tonka3000 · 2024-08-01T05:00:10Z

@Jarred-Sumner I replaced the \\ with / (in adapter.ts, debug.ts and signal.ts) and URL parse error is gone e.g. instead of ws+unix://C:\\Users\\myusername it is now ws+unix://C:/Users/myusername.

The only problem which I'm not stuck is no permission error. It seems that the sock files get created, but no write/read permissions.

rejected promise not handled within 1 second: Error: listen EACCES: permission denied C:/Users/myusername/b/mysock_dyswppiw3gt.sock
extensionHostProcess.js:148
stack trace: Error: listen EACCES: permission denied C:/Users/myusername/b/mysock_dyswppiw3gt.sock
    at Server.setupListenHandle [as _listen2] (node:net:1855:21)
    at listenInCluster (node:net:1920:12)
    at Server.listen (node:net:2019:5)
    at new UnixSignal (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\signal.ts:41:18)
    at DebugAdapter.#launch (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:493:20)
    at DebugAdapter.launch (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:439:18)
    at DebugAdapter.Adapter.request (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:350:21)
    at DebugAdapter.emit (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:297:26)
    at FileDebugSession.handleMessage (c:\sandbox\bun\packages\bun-vscode\src\features\debug.ts:195:20)

Note to the stack trace: I hardcoded the prefix C:/Users/myusername/b to make sure that I have write/read permission on disk.

Any idea?

EDIT: Now I saw the #11378 seems to already try to fix it. It seems that unix socket do not really work on Windows (no WSL).

nick4814 · 2024-08-02T04:54:11Z

I assume you are using WSL? Debugging any TS doesn't work for me. Can you provide information on your setup/OS/etc?

No I confirm, it was running natively on Windows, not via WSL. Setup is still in the OP 🙂

I assumed you were talking about debugging, as that's the issue that is actually still present 🙂.
TS files run fine on windows already, see this fixed issue

nick4814 · 2024-08-02T05:18:22Z

@Jarred-Sumner I replaced the \\ with / (in adapter.ts, debug.ts and signal.ts) and URL parse error is gone e.g. instead of ws+unix://C:\\Users\\myusername it is now ws+unix://C:/Users/myusername.

The only problem which I'm not stuck is no permission error. It seems that the sock files get created, but no write/read permissions.
rejected promise not handled within 1 second: Error: listen EACCES: permission denied C:/Users/myusername/b/mysock_dyswppiw3gt.sock
extensionHostProcess.js:148
stack trace: Error: listen EACCES: permission denied C:/Users/myusername/b/mysock_dyswppiw3gt.sock
    at Server.setupListenHandle [as _listen2] (node:net:1855:21)
    at listenInCluster (node:net:1920:12)
    at Server.listen (node:net:2019:5)
    at new UnixSignal (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\signal.ts:41:18)
    at DebugAdapter.#launch (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:493:20)
    at DebugAdapter.launch (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:439:18)
    at DebugAdapter.Adapter.request (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:350:21)
    at DebugAdapter.emit (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:297:26)
    at FileDebugSession.handleMessage (c:\sandbox\bun\packages\bun-vscode\src\features\debug.ts:195:20)
Note to the stack trace: I hardcoded the prefix C:/Users/myusername/b to make sure that I have write/read permission on disk.

Any idea?

EDIT: Now I saw the #11378 seems to already try to fix it. It seems that unix socket do not really work on Windows (no WSL).

Why not use standard ws:// for windows instead of ws+unix://?

Then update signal.ts to match this change? And possibly rename UnixSignal to SocketSignal or other to indicate it supports other systems, not just Unix.

I am not familiar with all the project code so this is may not be possible, but thought to mention.
I mentioned this on the broken PR.

I also mentioned something similar when I accidentally duplicated this issue.

Update

Looks like this implementation is currently being tried thanks to @mikeseese

maxime-aubry · 2024-08-02T06:40:22Z

I Have the same issue.
Unable to start debugger with Bun and NestJS.

mikeseese · 2024-08-02T06:45:31Z

Yall can 👍 the original post of this issue to show your desire to get this fixed/add that you are experiencing the issue. Not to be that guy, but if you're trying to use Bun on Windows without WSL given any combination of JS frameworks/etc, the VSCode extension debugger will not work for you (and won't work until this issue gets closed or otherwise mentioned). Let's keep people's inboxes reserved for productive discussion on the issue. Thanks!

LightQuanta · 2024-08-02T09:27:44Z

@Jarred-Sumner I replaced the \\ with / (in adapter.ts, debug.ts and signal.ts) and URL parse error is gone e.g. instead of ws+unix://C:\\Users\\myusername it is now ws+unix://C:/Users/myusername.

The only problem which I'm not stuck is no permission error. It seems that the sock files get created, but no write/read permissions.
rejected promise not handled within 1 second: Error: listen EACCES: permission denied C:/Users/myusername/b/mysock_dyswppiw3gt.sock
extensionHostProcess.js:148
stack trace: Error: listen EACCES: permission denied C:/Users/myusername/b/mysock_dyswppiw3gt.sock
    at Server.setupListenHandle [as _listen2] (node:net:1855:21)
    at listenInCluster (node:net:1920:12)
    at Server.listen (node:net:2019:5)
    at new UnixSignal (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\signal.ts:41:18)
    at DebugAdapter.#launch (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:493:20)
    at DebugAdapter.launch (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:439:18)
    at DebugAdapter.Adapter.request (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:350:21)
    at DebugAdapter.emit (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:297:26)
    at FileDebugSession.handleMessage (c:\sandbox\bun\packages\bun-vscode\src\features\debug.ts:195:20)
Note to the stack trace: I hardcoded the prefix C:/Users/myusername/b to make sure that I have write/read permission on disk.

Any idea?

EDIT: Now I saw the #11378 seems to already try to fix it. It seems that unix socket do not really work on Windows (no WSL).

I've tried ws://127.0.0.1:22222, and it still says EACCES: permission denied

stack trace: Error: listen EACCES: permission denied 127.0.0.1:22222
	at Server.setupListenHandle [as _listen2] (node:net:1855:21)
	at listenInCluster (node:net:1920:12)
	at Server.listen (node:net:2019:5)
	at new UnixSignal (f:\bunvscextfix\bun\packages\bun-vscode\dist\extension.js:7328:18)
	at #launch (f:\bunvscextfix\bun\packages\bun-vscode\dist\extension.js:7700:20)
	at DebugAdapter.launch (f:\bunvscextfix\bun\packages\bun-vscode\dist\extension.js:7652:25)
	at Adapter.request (f:\bunvscextfix\bun\packages\bun-vscode\dist\extension.js:7579:22)
	at DebugAdapter.emit (f:\bunvscextfix\bun\packages\bun-vscode\dist\extension.js:7534:27)
	at FileDebugSession.handleMessage (f:\bunvscextfix\bun\packages\bun-vscode\dist\extension.js:9458:20)
	at D.sendMessage (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:163:706)
	at o.$sendDAMessage (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:162:12042)
	at S (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:151:5986)
	at S.Q (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:151:5752)
	at S.M (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:151:4778)
	at S.L (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:151:3605)
	at n.value (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:151:2297)
	at r.B (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:83:737)
	at r.fire (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:83:954)
	at o.fire (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:108:14502)
	at n.value (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:177:8639)
	at r.B (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:83:737)
	at r.fire (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:83:954)
	at o.fire (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:108:14502)
	at MessagePortMain.<anonymous> (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:177:6765)
	at MessagePortMain.emit (node:events:514:28)
	at MessagePortMain.emit (node:domain:488:12)
	at MessagePortMain._internalPort.emit (node:electron/js2c/utility_init:2:2285)
	at Object.topLevelDomainCallback (node:domain:160:15)
	at Object.callbackTrampoline (node:internal/async_hooks:128:24)

mikeseese · 2024-08-03T07:26:09Z

I've gotten a WebSocket-only protocol to work with Windows with this branch: https://github.com/mikeseese/bun/tree/feat/win-debugger, but it requires stopOnEntry: true in the launch config. Stepping through the code seems to be working as expected:

20240803_002646.mp4

Stack frames, variable inspection, and breakpoints don't seem to be working yet. I will probably take a break for several days/couple weeks on this if someone wants to pick up where I left off. Let me know if you start working on it so I don't duplicate effort. You will need to be able build Bun for windows and use the updated bun-debug.exe for the launch config runtime

liudonghua123 · 2024-08-22T09:19:40Z

I tried to make the vscode debugger works on windows recently. But

To fix TypeError: "ws+unix://C:\test\folder" cannot be parsed as a URL. of new URL('ws+unix://C:\\test\\folder'). I modified the following code.

To make the prefixed slash path of pathname works for Unix domain sockets, I update the following code.

After the above changes, now the vscode debugger run without errors. But it's also couldn't stop at the breakpoints, it seems just no response.

[win] Debugging/running on VSCode on Windows doesn't work #8851

[win] Debugging/running on VSCode on Windows doesn't work #8851

Comments

COLAMAroro commented Feb 11, 2024

What version of Bun is running?

What platform is your computer?

What steps can reproduce the bug?

What is the expected behavior?

What do you see instead?

Additional information

Electroid commented Feb 11, 2024

COLAMAroro commented Feb 13, 2024

tonka3000 commented Apr 1, 2024

webdevrr commented Apr 2, 2024

otavio-silva commented Apr 2, 2024

YuziO2 commented Apr 9, 2024

MusiCode1 commented Apr 25, 2024

haingo87 commented May 4, 2024

GuiLin0773 commented May 19, 2024

Forgifted commented May 22, 2024

fesieg commented May 24, 2024

Jarred-Sumner commented May 26, 2024

LightQuanta commented May 26, 2024

Code-Quake commented Jun 10, 2024

Swarz commented Jun 15, 2024

itseramin commented Jul 5, 2024

softestpoly commented Jul 5, 2024 • edited Loading

amir141592 commented Jul 18, 2024

dayblox commented Jul 21, 2024

zs782306174 commented Jul 22, 2024

elemental-mind commented Jul 28, 2024 • edited Loading

nick4814 commented Jul 29, 2024 • edited Loading

nick4814 commented Jul 29, 2024

COLAMAroro commented Jul 29, 2024

tonka3000 commented Aug 1, 2024

nick4814 commented Aug 2, 2024

nick4814 commented Aug 2, 2024 • edited Loading

Update

maxime-aubry commented Aug 2, 2024

mikeseese commented Aug 2, 2024 • edited Loading

LightQuanta commented Aug 2, 2024

mikeseese commented Aug 3, 2024 • edited Loading

liudonghua123 commented Aug 22, 2024

gemue-parndt commented Aug 30, 2024

mikeseese commented Aug 30, 2024

smultar commented Sep 7, 2024

christophe-hall commented Sep 7, 2024

MusiCode1 commented Sep 21, 2024

someramsey commented Sep 21, 2024 • edited Loading

one0410 commented Sep 22, 2024

softestpoly commented Jul 5, 2024 •

edited

Loading

elemental-mind commented Jul 28, 2024 •

edited

Loading

nick4814 commented Jul 29, 2024 •

edited

Loading

nick4814 commented Aug 2, 2024 •

edited

Loading

mikeseese commented Aug 2, 2024 •

edited

Loading

mikeseese commented Aug 3, 2024 •

edited

Loading

someramsey commented Sep 21, 2024 •

edited

Loading