_Tpouhuk

[_Tpouhuk @Tpouhuk2]

@usgraphics Theres no names for RGB and CMYK values, colorblind ppl are not gonna be able to understand these values :(

[_Tpouhuk @Tpouhuk2]

@sahaj__b It fits into LLM context, it can rewrite it in go probably.

[_Tpouhuk @Tpouhuk2]

@debasishg @_Felipe It's not usually 1 byte. Usually usize.

[_Tpouhuk @Tpouhuk2]

@sahaj__b nah, you'll go bigger

[sahaj @sahaj__b]

Added 2 new features to brainrot.nvim, making it smarter, thanks to @Tpouhuk2 for the suggestions.

- min_error_duration: Errors must exist for at least this long before phonk triggers (so it doesn't play for quick typo fixes)
- lsp_wide:

[_Tpouhuk @Tpouhuk2]

What I'm missing as in daily driver, is the ability to set duration for which errors persist before phonk plays. Cause causing an error and fixing it doesn't deserve the edit, but finally making after 1-2min session errors go away feels good.
Also an option to get all LSP errors for the project tracked, not only the current buffer, would be nice :)

[_Tpouhuk @Tpouhuk2]

@sahaj__b Kernel just writes to this chunk of ram instead of disk, and then syncs with disk. (I guess). So it just writes to RAM cache, and doesnt revalidate things. Needs to write it back to disk after, though

[_Tpouhuk @Tpouhuk2]

@sahaj__b Its still kinda from RAM, it just mmaps file or something. OS caches it, so it doesnt go to disk for every line. It just doesnt copy script contents, cause why would you?

[_Tpouhuk @Tpouhuk2]

@sahaj__b Give us more

[Allan Blomquist @allan_blomquist]

Here's a look at some of our internal programming tools at Tomorrow Corporation!

https://t.co/wsuooryLOg

[_Tpouhuk @Tpouhuk2]

@vaxryy Did you feed it the constants, or just prompted?

[_Tpouhuk @Tpouhuk2]

It's way harder to understand systems with many small parts, than system with a few big parts. Big parts are not easy to understand, but you can't get better by just splitting them into smaller parts.
Smaller parts give the understanding of themselves, but it's pointless if you take the system as a whole.

Bugs and errors are way harder to find when they are on the boundary of communication, and not inside one part. Parts are easy to test, easy to debug. Communication between parts is way harder to debug and test. Because one part expects something from the other, and if expectations are not met, it's over.

If you try to abstract that, then there's type interface, and also unspecified behavior interface. Changing the implementation without changing interface is kinda optimization, but that won't reap any benefits almost always.

If you replace bubble sort with a faster sort, yes, you can get a speedup. But usually performance problems arise when there's a lot of parts trying to accomplish something simple, just because when it was written small parts were already there.

If you wanna get a width of a single character, it can be done way faster than trying to layout the string of text, but the layout code is here, so why not to reuse it?

It's simplified example, but it's almost always something like that.
It's kinda easier to read this code to understand what it tries to accomplish, but it's way harder to read this code if you are trying to understand what it does.

There's huge benefit of knowing what exactly function does. Does it get cached data or not? Does it cache anything at all? How fast is it on certain data?

Performance is all that matters, cause making turing-complete programs that give the right result is as easy, as generating random input and checking if it's right. But it's infeasible.

There may be no benefit in trying to write program with combining a lot of stuff together untill it works, cause maybe what's required is the simplest possible thing that works, and it usually is very fast.

Maybe writing it upfront costs more, but upfront costs of programming are always minuscule compared to everything else

[_Tpouhuk @Tpouhuk2]

Programs do not consist of small objects. Programs consist of procedures (or functions, whatever you call them).

[_Tpouhuk @Tpouhuk2]

Semantics shouldn't be that hard, keyboard navigation is kinda scary, and state management is insanely hard to get right.

You wanna do two things simultaneously:
to give the ability to widgets to create and manage their own state, and also to provide the state from outside, like a controller in Flutter.

Sometimes basic behavior is enough, sometime you wanna expand the card based on other inputs. And it's kinda hard to manage?

[_Tpouhuk @Tpouhuk2]

There should be a way of just writing UI based on data, and not doing weird hierarchies of widgets and trying to inject required data into smallest sub-trees possible.

There's no real benefit of specifying what variable changes what part of the ui tree as you are trying to tie your program state to the Tree state, for no apparent reason except trying to minimize widget rebuilds.

It's drawn on screen, and to draw stuff is very hard. The only feasible reason to not do full UI rebuild, is if rebuild is very very expensive. But it doesn't have to be that way.

In flutter you have 3 different trees, each tree tries to cache more than the previous one, but it doesn't really help.

Full-tree rebuilds introduce jank, but you need full tree build in order to init the page! So why can't you just rebuild the whole tree on every update?

I would rather specify which parts of the tree can be static, than specifying what should be rebuilt on changes.

[_Tpouhuk @Tpouhuk2]

So in order to do the UI you need to draw colored boxes on screen, draw text on screen and get user input. There's plenty of ways to do it in flutter without getting into the widget hierarchy.

The real hard problems is, how to support all the platform specific quirks on the widget boundary.

Layout can be independent from everything, but text-fields are very dependent on the system.
You can get number-keyboard on android, composing regions, handwritten input, etc.

[_Tpouhuk @Tpouhuk2]

Text-layouting is done via SKIA and aggressively cached on the dart side. Harfbuzz should be pretty fast, and maybe there's no need to cache it?

[_Tpouhuk @Tpouhuk2]

Flutter layout and widgets are kinda interesting. There's only one layout pass, but it's kinda 2 passes at the same time.
First pass is pushing sizes constraints down the tree, and the second one, is getting resolved sized and setting positions of children. That allows for pretty much any layout you'll ever need.
If you need something complex, you need to write the layouting code yourself, with pretty simple math, and you'll get where you need.

So instead of composing different widgets to get what you need, you can just write what you need instead.

Boilerplate required for that is immense, but it's doable.

[_Tpouhuk @Tpouhuk2]

@HSVSphere It's way harder to generate parsers for language, instead of just bindings. It's better, but does it worth the time?