pbaam

12 maanden geledendiscuss

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...

pbaam

2 jaar geledendiscuss

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]*

pbaam

2 jaar geledendiscuss

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)

pbaam

2 jaar geledendiscuss

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

And you will be able to paste from your clipboard or write anything you want. Without cat or piping.

pbaam

2 jaar geledendiscuss

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'

And you could just use scp, but I've found clients without scp and servers with the SFTP subsystem disabled.

pbaam

2 jaar geledendiscuss

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");
  });

You will write:

  const win32 = @import("win32");

Where the module "win32" is declared in build.zig.

[1] https://ziglang.org/documentation/master/#cImport

pbaam

2 jaar geledendiscuss

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.

[1] https://news.ycombinator.com/item?id=19413901

pbaam

2 jaar geledendiscuss

> 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.

pbaam

2 jaar geledendiscuss

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.

[1] https://www.youtube.com/watch?v=V5vZWHP-RqU

pbaam

2 jaar geledendiscuss

> 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.

[1] https://github.com/RealNeGate/Cuik

pbaam

2 jaar geledendiscuss

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.

pbaam

3 jaar geledendiscuss

Lua's codebase is also great for getting started

Submissions

LDAP for Rocket Scientists (2004)

Reverse engineering Coin Hunt binary protocol (2023)

Why did I switch back to Arch from Artix Linux?

PinWin: Pin any window to be always on top of the screen (2020)

The Problem with Nsswitch (2018)

comments