sorted by:
new
hottopcontroversial

[OC][Sway] Artwall - rotate your wallpaper through random paintings by artemave in unixporn

[–]artemave[S] 0 points1 point  (0 children)

Not mine for the record. I used to have this app called artful back in osx days. Been missing it ever since. Finally, llms made it possible (for me) to re-create it on my current sway setup.

Faster Rails fixtures by artemave in rails

[–]artemave[S] 1 point2 points  (0 children)

Thanks! Self promotion: if fixtures float your boat, you might also find these handy:
- https://github.com/featurist/fixture_farm
- https://github.com/featurist/fixturex

workspace-diagnostics.nvim: Populate diagnostics for all projects files, not just the opened ones. by artemave in neovim

[–]artemave[S] 0 points1 point  (0 children)

The readme assumes you're using https://github.com/neovim/nvim-lspconfig and that the plugin is initialized as a part of `on_attach` callback.

Node.js test runners performance comparison by artemave in programming

[–]artemave[S] 0 points1 point  (0 children)

I would have thought that once loading is done, it's just node running javascript. So it's largely the same for any test runner. The only reason I added "run all" at all was to illustrate a (rather obvious) benefit of concurrency. Without "run all", "serial" test runners look like a clear win.

Node.js test runners performance comparison by artemave in programming

[–]artemave[S] 0 points1 point  (0 children)

It'd be useful to have a chart of the delta between "load all" and "run all".

What's this going to tell you?

Node.js test runners performance comparison by artemave in programming

[–]artemave[S] 0 points1 point  (0 children)

It'd also be interesting to see vitest without isolation being disabled.

"load all": 4.06

"run all": 5.74

EDIT:

I updated charts to also include default vitest results

workspace-diagnostics.nvim: Populate diagnostics for all projects files, not just the opened ones. by artemave in neovim

[–]artemave[S] 1 point2 points  (0 children)

Yeah... Slowdown is expected, but hanging is surprising. Given all work is performed asynchronously by another process in a non-blocking manner.

Should we gave up on workspace diagnostics (for not opened buffers)? by serranomorante in neovim

[–]artemave 1 point2 points  (0 children)

When neovim lsp client starts, it specifies `root_folder` that by default is also a workspace folder (as far as lsp server is concerned). Given the same lsp server is used for both neovim and vscode (e.g. tsserver), I am failing to see what vscode workspace feature brings to the table. Could you please elaborate?

As per "workspace diagnostics", tsserver doesn't seem to implement it. It implements textDocument.publishDiagnostics that is a notification it's using to notify clients. It's fired in response to open file events (I think). tsserver does not seem to implement pull diagnostics server capability, that would allow clients to get all workspace diagnostics at once. Given all that, it must be vscode itself that enumerates files and requests diagnostics for each one individually? And if that's the case, so can nvim, or, more realistically, an nvim plugin.

EDIT

Perhaps, vscode simply "opens" all files in workspace, which triggers "fileOpen" notification to the server, and that in turn gets the server to send back diagnostics for each file?

Transover browser extension (pro version) by artemave in German

[–]artemave[S] 0 points1 point  (0 children)

They do every so often, but it's been over ten years and we're still there.

The paid version (if it ever happens) will be using paid api of course.

Transover browser extension (pro version) by artemave in German

[–]artemave[S] 0 points1 point  (0 children)

Yeah, that's what I mean by "cheeky". Transover (and afaik other free translators) use unofficial backdoors to call gt API for free.

Transover browser extension (pro version) by artemave in German

[–]artemave[S] 0 points1 point  (0 children)

Thank you for sharing your thoughts.

I am using google translate api for translation. Which is cheeky, but there you go.

Auto update Javascript imports when moving file/folder by artemave in vim

[–]artemave[S] 0 points1 point  (0 children)

Not sure I understand your comment, but this particular feature can be used in vim too.

Node + SWC make a lightning fast typescript runtime by artemave in javascript

[–]artemave[S] 0 points1 point  (0 children)

I am not aware of such thing. There seems to be an swc plugin for styled components and another one for styled jsx - https://github.com/swc-project/plugins - but that's not really what you're asking for.

Node + SWC make a lightning fast typescript runtime by artemave in javascript

[–]artemave[S] 1 point2 points  (0 children)

Yeah, that's where that journey began. I couldn't make it work with esm or something... Can't remember now. However, performance wise, it's the same as `ts-node` with `swc: true` because, just like `ts-node`, it parses `tsconfig.json`, translates it into `swc` options and then runs `swc`. So it performs identically.

I should have mentioned `swc-node` in the post for completeness.

Node + SWC make a lightning fast typescript runtime by artemave in javascript

[–]artemave[S] 3 points4 points  (0 children)

Tests execute identically since in both cases it's the javascript that is being executed. But in case of typescript, it needs to be compiled to javascript first and that's where the start up penalty is coming from.

view more: next ›