Comments URL: https://news.ycombinator.com/item?id=46385723

Points: 1

# Comments: 1

1. https://www.youtube.com/watch?v=haes4_Xnc5Q&list=PLz9LbZJP-T...

1. https://github.com/pimutils/khal

2. https://codeberg.org/laladrik/Semana

Comments URL: https://news.ycombinator.com/item?id=45430595

Points: 6

# Comments: 1

    const App = struct {
        fn init() @This() { return .{} }
    };

    const Connection = struct {
        fn init() @This() { return .{} }
    };

    App::init
    Connection::init

Also, while I working on it, I found that LuaJIT 2.1 compares strings as fast as integers. Eventually, I did a little research about it and published the results here https://laladrik.xyz/blog/luaStringComparison/

Comments URL: https://news.ycombinator.com/item?id=43764084

Points: 3

# Comments: 1

Does GPU rendering mean that I have to involve OpenGL/Vulkan?

> You describe that attempt in detail.

I appreciate if you put a quote, because I fail to find the description of the attempt in detail. In fact, instead of assuming that a vector is pinned I wrote this "I realized that the problem is related to the fact that vectors of children move in the memory if they don't have enough space to extend."

> The code you ended up with is still dangerous code, because your boxes are still not guaranteed to remain pinned in memory.

You are right, boxes are not pinned, but the data, which the point to, is pinned, isn't it? My pointers point to that part of memory.

Do you mean that b-tree might work here better?

> They’re just populating an array from a file when the program launches, then freeing the whole thing when the program terminates. It’s really not rocket science.

That's exactly why I consider indices.

> since they assumed memory allocated by vec would be pinned (it isn’t)

Could you tell me, please, where you read in the article that I assume it? I wrote in the article "I realized that the problem is related to the fact that vectors of children move in the memory if they don't have enough space to extend." and even made an animation for clarity https://laladrik.xyz/VectorMove.webm. However, if you see the assumption in the article, please, let me know. I correct it or elaborate.

I don't have arguments against the point about Xlib. However, I struggle to use its alternative XCB. XCB doesn't have enough documentation to understand how to use it. In fact, I even looked at the source code of Qt and GTK, but the usage doesn't explain the XCB API. I'd really appreciate if you share with me the data you have. The only thing which I found recently is the wrapper from System76 https://pop-os.github.io/libcosmic/tiny_xlib/index.html. However, it's not a documentation still. I just hope to find some usages of the wrapper and communicate with the original API.

> if you ignore the existence of Wayland

How did you conclude it? I even mentioned it in the article. I don't use it - it's true. However, I can't wait to do it. I've been trying for a couple of years now. Regrettably, I experience various technical difficulties every time. As a result, I still use my i3.

> For something like fast visualizations, you should really go with something that does offscreen rendering and then blits the result.

Do you mean double buffering?

> though obviously modern tools should use GPU rendering

Would you mind elaborating on it?