1
point
laladrik
Joined 50 karma
barber-stoic-come@duck.com
- laladrikDuring the last couple of years working on Rust programs I collected a number of GDB scripts. Eventually, they evolved into the project. Also, I wrote an article about how I came up with each of the scripts https://alexmarkov.xyz/blog/rustToolsGdb.html
- That's a good introduction. There is a video which I'd say complements the article. It's called "Getting pixels on screen on Linux: introduction to Kernel Mode Setting" [1]
1. https://www.youtube.com/watch?v=haes4_Xnc5Q&list=PLz9LbZJP-T...
- Recently Khal [1] released JSON interface. In short, Khal is a Linux CLI calendar application. I'm working on a proof-of-concept GUI[2] for the interface. I expect to implement typical views for a calendar application: daily, weekly, monthly.
- The conclusion of the article says that it's not the language problem either. Under the title "So, is Go the problem?" Or do you mean something else here?
- Yeah, that's a pity that D didn't gain the popularity. It brought some features which were borrowed to mainstream languages. However, the features didn't help D to become popular. I have a hunch that templates from D were the inspiration for the comptime in Zig. Also, Reading D is almost easy as reading Zig. I remember I couldn't get my head around async/await from Python 3.5. I knew it was based on generators. However, the stack switch was absolutely mysterious to me. I understood it only from the implementation of fibers from the D's standard library.
- Hello everyone, I started programming because I wanted to make games. However, I got a chance to bring the food to the table making on web sites. A few months ago I came across a list of challenges for a programmer. One of challenges was creating a clone of Space Invaders. I created a clone of the game and wrote the article. In the article I wrote about the challenges related to gamedev which I faced. With gamedev background I wouldn't have them, I guess. However, for me as for a backend programmer, they were something. I hope the article is good enough to inspire other programmers like me to complete their first games.
- 6 points
- Hello, I've been playing with Zig the last couple of months. The navigation between document symbols in Neovim is a bit complicated the document has symbols with the same name. I improved it adding the path to every symbol. For example you have two structures:
You get the following items in the navigation list:const App = struct { fn init() @This() { return .{} } }; const Connection = struct { fn init() @This() { return .{} } };
Essentially, it's a configuration of Telescope and Nvim-Treesitter. You can take the file from here https://laladrik.xyz/zig_document_symbols.lua. However, if you curious about the process of creating a custom Telescope menu and inspection of the source code with Tree-sitter, checkout the entire article.App::init Connection::initAlso, 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/
- 3 points
- I fail to see the reference to be honest. I remember the term from OpenGL, when I rendered something to a framebuffer (actually its attachmets) and then applied to the current framebuffer. It helped me to do effects like night vision. Does using offscreen rendering imply using OpenGL?
Does GPU rendering mean that I have to involve OpenGL/Vulkan?
- A clear. I hid it in my mind. I haven't tried the approach with indices, because... well, I was lazy to do it. However, I agree that this approach would be better, then the current one.
> 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.
- Ok, now I remember what was the deal with Hotspot. It makes it possible to work with a flamegraph of mine. However, it takes almost half a minute to load my perf.data. However! I totally recommend Hotspot over my hack in case when you need to have a comprehensive view of the data. In particular, I love to see the off-CPU load, which my FlameGraphViewer doesn't show.
- > The author isn’t talking about implementing an ECS or b-tree here.
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.
- > please just let Xlib die
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?
- Unfortunately, I can't find the original perf file I get the flamegraph https://laladrik.xyz/img/pic.svg out of. However, I can create with a similar bunch of data and provide it soon.
- I love pprof. I used it so many times to profile my Go applications. However, as you wrote, the visualization is in a browser, which I found incapable to render the flamegraphs I had to work with.
- I said "fast and native" because none of browsers made it impossible to inspect the flamegraph.
> In this case it is though, so I don't see why it would be a problem for it to be web based.
Would you like to say that your browser is able to render the flamegraph https://laladrik.xyz/img/pic.svg and inspect it? As I wrote in the article (the first paragraph), it takes a couple of seconds to render the graph, and nothing happens when I press on a frame. Could you check it, please? If your browser renders it as fast enough and allows to open a frame, please, let me know how could I improve any of browsers. I would really appreciate it.
- Hello, I found that it's difficult to visualize the flamegraph out of the huge amount of data when I was profiling Rust Analyzer. Viewing the flamegraph in a browser (Firefox and Chrome) made it impossible to view. In fact, it was simply frozen. I made this visualizer to solve my problem. Maybe it would help someone else. I leave the link to my article about it, but you can find the link to the project right in the first paragraph.
