pbaam
Joined 3 years ago
Karma
42
Submissions
17
Member since
Aug 5
[ my public key: https://keybase.io/pbaam; my proof: https://keybase.io/pbaam/sigs/Wk2nIaawrTzkm7m-oN3sLH_Z52d7ITFOJnKGVtFVWTU ]
View on Hacker NewsRecent submissions
Comment · 1 year ago
https://ziglang.org/documentation/master/#opaque
> opaque {} declares a new type with an unknown (but non-zero) size and alignment. It can contain declarations the same as structs, unions, and enums
So it can contain methods, just like structs. The only thing it cannot contain is fields (which the example above doesn't contain). An opaque type can only be used as a pointer, it's like a `typedef void* ...` in C but with the possibility to add declarations within a namespace
Edit: the documentation doesn't contain any example of an opaque type which happens to have declarations inside. But here is one: https://codeberg.org/andrewrk/daw/src/commit/38d3f0513bf9bfc...
Comment · 1 year ago
Well, if your compilations turn to be submilisecond it's not an implementation detail :) *. As of now it is only supported for x86_64 Linux (only ELF format) and it has some bugs; incremental compilation is in its very early stages. Andrew talked about it in the 2024 roadmap video[1] why they are digging so low on the multiplatform toolchain (for besides incremental compilation):
- Fast build times (closely related to IC, but LLVM gives very slow development iterations, even for the compiler development)
- Language innovations: besides IC, async/await is a feature Andrew determined to not be feasable to implement with LLVM's coroutines. Async will likely not make it into 1.0, as noted in the 0.13 release notes. It is not discarted yet but neither is it the priority.
- There are architectures that don't work very well on LLVM: SPARC and RISC-V are the ones I remember
My personal point is that a language that is meant to compete with C cannot have a hard dependency on a C++ project. That, and that it's appealing to have an alternative to LLVM whenever you want to do some JIT but don't want to bring a heavy dependency
[1] https://www.youtube.com/watch?v=5eL_LcxwwHg
* There is also the `--watch` flag for `zig build` which re-runs every step (IC helps) everytime a file is saved.
[edit: formatting]*
Comment · 1 year ago
I guess he means that in order to achieve incremental compilation they need to write their own code generation and linker for every architecture and format. This is needed because incremental compilation here doesn't just mean storing object files in a cache directory (which has always worked that way). They also want to cache every analyzed function and declaration. So they have to serialize compiler state to a file. But after analysis is done, LLVM will start code generation from the beginning (which is the time expensive thing, even in debug builds)
Comment · 2 years ago
I know, it's intentionally unrelated. But if you read my first sentence, you can do what you are interested in without using cat.
sudo tee somefile > /dev/null
Comment · 2 years ago
The cat command can be omitted there, as tee reads from standard input by default, even if stdin points to a terminal. I was going to comment an actually useful (and unavoidable in bash) use of cat and ssh, which is to do do nothing with standard input and redirect it to a file:
<file ssh 'cat >file'
Comment · 2 years ago
It will still work. If you look at the type signature of @cImport in the language reference[1], it returns a type just as @import. So you can call @typeInfo on it. But instead of writing
const win32 = @cImport({
@cInclude("windows.h");
@cInclude("winuser.h");
});
const win32 = @import("win32");
Comment · 2 years ago
What a coincidence, some days ago I was reading some HN posts related to lighttpd and I found [1]. The link is dead and it has inappropriate content, so use arhive.org. The author doesn't go too much in detail of why nginx being purchased is a problem, but in how to configure lighttpd. And the first comment predicts the hypothetical case of F5 being problematic.
Comment · 2 years ago
> Sniffing the traffic from the device showed that it was connecting out to tcp.goodwe-power.com:200001
Is 200001 the right port number? Very good read anyways.
Comment · 2 years ago
I remember this option was mentioned in a 3 hour video[1] where Daniel Stenberg himself went through most of the curl command line options.
Comment · 2 years ago
> but they surely can't hope to compete with LLVM in terms of opimisation, can they?
This has been discussed more than once on Zig's discord server. Quoting Andrew and Matthew Lugg's discussion in #compiler-devel about pull 17892:
> mlugg: Shout-out to the people on Twitter and HN who are probably still saying "why would you try to compete with LLVM, LLVM is perfect and can do no wrong"
> andrewrk: worse, they're saying "LLVM is not great but it's the best mankind can achieve"
I think it's very appealing to have a project that focuses on fast build times and wants to seriously compete against LLVM in terms of the optimization pass pipeline, specially when you don't have a beefy computer. With that said, for the time being there are no optimizations made by Zig's own x86 backend (it neither does pass all behavior tests like it was pointed out in the talk, but it can build the Zig compiler itself and some other projects).
Cuik[1] is a project that was mentioned in the Q&A section which illustrates how a compiler can be fast and make optimised builds at the same time.
Comment · 2 years ago
They want to replace LLVM with their own backends. Zig's master branch can now be compiled without LLVM (and without CMake, see bootstrap.c) in x86 Linux because they implemented their own ELF linker and x86 code generation.
It's explained in the talk why they want it: Most of the compile time is spent in LLVM, not in AST lowering or semantic analysis. Andrew also said that LLVM's coroutines weren't good enough to implement async/await.