61–70 of 82 posts
I’ve been using Zig for a new JavaScript build tool and I really like it. It’s great for writing performance-critical code. It took me about two weeks to feel comfortable & productive in it.
Earlier quoted context omitted.
I really, really wish Zig had RAII. I am so used to this in C++ and have grave difficulty living without it. But it has been shot down as RAII is considered a high-level feature. Well, I guess I will admire the language from a distance but I am unlikely to use it practically. https://github.com/ziglang/zig/issues/782
With regards to RAII (as in constructors/destructors, not the stuff in the issue you linked), I think it simply didn't fit within Zig's goals. A big part of Zig is readability; what you read is what you get, and RAII is very much not that. Looking at a block of C++ code, there's no way to tell what happens unless you also know what the constructors/destructors of each data type in the block does.
EDIT: Aaand shockingly, I'm not the first to come up with this idea: https://github.com/ziglang/zig/issues/782
I’m wondering if Zig is useful for targeting microcontrollers? (For example the Raspberry Pi Pico.)
This was a rough release cycle for downstream users of LLVM. During testing of the release candidates, we found and reported 7 regressions from LLVM 11. However, despite having reproducible regressions reported as release blockers, the LLVM project tagged release 12.0.0. Not only were there open regressions at this time, but the 12.0.0 tag did not even tag the tip of the release/12.x branch - so there were fixes alre…
Well, this says that zig team reported those bugs as "release blockers".
Doesn't mean the LLVM release team also considered them release blockers (or that it had too).
I was curious about this bit from https://ziglang.org/download/0.8.0/release-notes.html#Self-H... , since I work on the new LLD for Mach-O backend: > Additionally, it is doubtful that the new backend will allow for seamless cross-compilation to macOS since every macOS binary is required to be a PIE and link dynamically against libSystem dylib, which will require the lib's presence on the host for the lld to reference…
As far as cross-linking is concerned, we do the same thing we do for macOS libc headers - we ship the definitions. You can think of it as effectively shipping a preprocessed version of libSystem.tbd with Zig. This is still early days though, so currently as a workaround for not having a functional yaml parser (so that `zig ld` can link against tbds), every unresolved proxy symbol is simply assumed to come from libSystem. This is of course not ideal since then unresolved symbols are flagged only at runtime rather than at link time.
Anyhow, shipping preprocessed libSystem.tbd makes it possible to cross-compile valid PIE binaries (which is a strict requirement on Apple Silicon anyway).
If you wanna discuss it more, feel free to DM me in Zig's Discord - I'm always game to discuss linkers!
This was a rough release cycle for downstream users of LLVM. During testing of the release candidates, we found and reported 7 regressions from LLVM 11. However, despite having reproducible regressions reported as release blockers, the LLVM project tagged release 12.0.0. Not only were there open regressions at this time, but the 12.0.0 tag did not even tag the tip of the release/12.x branch - so there were fixes alre…
> we found and reported 7 regressions from LLVM 11. However, despite having reproducible regressions reported as release blockers Well, this says that zig team reported those bugs as "release blockers". Doesn't mean the LLVM release team also considered them release blockers (or that it had too).
The changes to the IR data structures in this release are really neat- whole trees and graphs fit in a small fixed number of flat arrays. This saves on allocations, saves on total memory usage, and makes them trivial to serialize because there are no pointers. I recently arrived at a similar design for manipulating NFAs as adjacency matrices, as a replacement for more pointer-y adjacency lists, by way of sparse matri…
Great point! I've been using Rust for 4–5 years now and putting objects in Vecs and using integers as "pointers" felt a lot like cheating (i.e., "I'm doing the wrong™ thing!"), but every time I tried to "fix" things to use references my code ended up uglier, harder to understand, and sometimes slower.
In time, I've learned that it's perfectly fine way to structure data. And as you point out, it makes it easier to work on a large structure structure itself rather than having to go through its individual components (e.g., you can manipulate all the nodes in a graph with a simple for loop rather than having to do a DFS/BFS traversal).
This was a rough release cycle for downstream users of LLVM. During testing of the release candidates, we found and reported 7 regressions from LLVM 11. However, despite having reproducible regressions reported as release blockers, the LLVM project tagged release 12.0.0. Not only were there open regressions at this time, but the 12.0.0 tag did not even tag the tip of the release/12.x branch - so there were fixes alre…
It's the first release by a new release manager as far as I can tell: https://www.phoronix.com/scan.php?page=news_item&px=Tom-Stel... So hopefully just temporary transition pain while the new manager learns the ropes.
Quality really went down with that RH guy.. :/
The changes to the IR data structures in this release are really neat- whole trees and graphs fit in a small fixed number of flat arrays. This saves on allocations, saves on total memory usage, and makes them trivial to serialize because there are no pointers. I recently arrived at a similar design for manipulating NFAs as adjacency matrices, as a replacement for more pointer-y adjacency lists, by way of sparse matri…
The changes to the IR data structures in this release are really neat- whole trees and graphs fit in a small fixed number of flat arrays. This saves on allocations, saves on total memory usage, and makes them trivial to serialize because there are no pointers. I recently arrived at a similar design for manipulating NFAs as adjacency matrices, as a replacement for more pointer-y adjacency lists, by way of sparse matri…
Can you point out the section of the release notes that discusses this change? I'd like to read more and I'm not able to figure out what you're referring to.