101010.pl is one of the many independent Mastodon servers you can use to participate in the fediverse.
101010.pl czyli najstarszy polski serwer Mastodon. Posiadamy wpisy do 2048 znaków.

Server stats:

574
active users

#issue

2 posts2 participants0 posts today
Continued thread

So it does look like the TypeScript language server has a limit of 4MB source size where it disables type checking (and actually shows an erroneous error stating that exports that exist in the file do not exist) for files that are imported but not open in the current workspace/session.

Still not sure if this is documented anywhere or not (haven’t been able to find it, if it is).

99.99999% of the time, unless you’re doing niche stuff like I am, you won’t run into this.

Workaround: should you have such a large file, e.g., with a large generated object, try and refactor to split it up into multiple files and rejoin it a separate file. The actual object size/memory usage isn’t the issue, it’s the file size.

github.com/typescript-language

I ran into an issue while creating and exporting a constant object that holds component versions of the ~1,500 icons in the Phorsphor icons library and I’ve created the simple reproduction below: D...
GitHubServer fails on import when exported object constant has too many entries/is too large · Issue #951 · typescript-language-server/typescript-language-serverBy aral
#TypeScript#max#lines

"pipelined request failed: detected chunk with wrong digest."

Two days ago some problems started with one of our backup workflows on a specific proxmox node.

"I Love Free Software Day" is over but I love it today as well!
So, many thanks to memtest.org/ for finding the faulty ram!

"backup successful"

Memtest86+Memtest86+ | The Open-Source Memory Testing ToolMemtest86+ is an advanced, free, open-source, stand-alone memory tester for 32- and 64-bit computers (UEFI & BIOS supported)

#python #poetry #dependency resolution #issue...

Went to upgrade a dependency in a poetry-managed project today, and it's failing resolution with what looks like nonsense as reasons. Tried with 1.8.x, then tried with the just-released 2.0. Both fail for what look like the same reasons.

My project has the Python version and another dep declared:

python = ">=3.10"
yacv-server = "*"

When resolving, it produces this error:

The current project's supported Python range (>=3.10) is not compatible with some of the required
packages Python requirement:
- yacv-server requires Python <3.13,>=3.9, so it will not be satisfied for Python >=3.13
- yacv-server requires Python <4.0,>=3.9, so it will not be satisfied for Python >=4.0
- yacv-server requires Python >=3.9,<4.0, so it will not be satisfied for Python >=4.0
[...]

It outputs one of the latter errors for each released version of yacv-server. Half list the required Python as ">=3.9,<4.0" and the other half have it in reverse order, "<4.0,>=3.9". Then the later explanation section of the output has:

[...]
So, because yacv-server (0.9.3) requires Python <3.13,>=3.9
and cq-studio depends on yacv-server (*), version solving failed.

• Check your dependencies Python requirement: The Python requirement can be specified via the `python` or `markers` properties

For yacv-server, a possible solution would be to set the `python` property to ">=3.10,<3.13"
[...]

Why it thinks 3.10 isn't >=3.9?

A few days ago we crossed the mark of 23k issues opened on GitHub!! 🎉🎉

If you've been there, you’ve probably seen that we do our best to give support to all of you 💪🥰

And as you can see below, just in the last six years we've received almost 20k of them!

If I had a software with 3K issues, I would first stop developing new features and start cleaning house.

You cannot make your software stable and rock solid if you have 3.000 users telling the different problems on your software.

You're not Microsoft, Apple, NVIDIA or even RedHat. You're just a couple of guys wanting funding to buy a yacht and call it a day.