tiehuis

7 ms·

1.
by tiehuis 1y ago
Using a portable minimal markdown dependency (such as cmark [1]) I think markdown can be quite a low barrier here. I personally do similar to what you have described on my blog, with an additional cmark conversion and find it quite simple [
2.
by tiehuis 2y ago
There is an issue proposing this approach: https://github.com/ziglang/zig/issues/4284
3.
by tiehuis 3y ago
Zig had a similar issue which I made an MR to fix. I didn't actually notice Rust had the same issue but that's probably just my forgotten knowledge with how the vec! macros expand when nested.
4.
by tiehuis 3y ago
I as well moved to this sort of approach a few years ago [1]. Definitely like the simple approach and it just stays out of the way. [1] https://tiehu.is/blog/blog1
5.
by tiehuis 3y ago
I wouldn't assume that just because Andrew has written the proposal it will be accepted. There have been plenty of times where proposals from Andrew have been rejected and/or reworked. The sub-items of this task are still valuable
6.
by tiehuis 4y ago
Good comment. Andrew did remove zstd compression on the wasm artifact in this commit [0] for the reasons you mention [1]. [0] https://github.com/ziglang/zig/commit/c51288f1f6be20be9f162c... [1] https:/&
7.
by tiehuis 5y ago
There is a recent draft PR [1] to merge this into the zig compiler itself. LLVM is being placed as a an optional component in the future [2]. Using arocc to fill this gap would mean that seamless C compilation could still be done, without L
8.
by tiehuis 5y ago
This is a nice write-up. Since zig has quite extensive compile-time functionality, one drawback is it is often easy to miss untested branches, especially for non-native targets if they are not regularly tested. It would be quite beneficial
9.
by tiehuis 7y ago
As an example, xxHash [1] would probably get you an easy 5-10x performance improvement over Blake2b. So there are some easy improvements if the cryptographic requirement is not needed. [1] http://cyan4973.github.io/xxHash&#x
10.
by tiehuis 7y ago
Here is a repository with a few more small code examples which may be helpful: https://github.com/tiehuis/zig-rosetta The code itself should be up to date for most, but I'm aware of a few examples than need touch-
11.
by tiehuis 8y ago
A comparable implementation in Zig. Key detail is `@fieldParentPtr` [1], which has the same functionality as `container_of`. const std = @import("std"); const wl_list = struct { prev: *wl_list, next: *wl
12.
by tiehuis 8y ago
Zig's errors are actually different and the variants can be statically known. Error type returns are not usually specified since they can usually be inferred. They can be explicitly specified if needed [1]. For example, the following c
13.
by tiehuis 8y ago
> But if I understand correctly, out-of-the-box, Zig's `union` doesn't get a tag type, right? That's what I meant by Rust's `enum` being safer: you can use it safely in Zig, but you have to actually request safety, be
14.
by tiehuis 8y ago
To elaborate on a few of your remarks/questions. > At first glance, Rust's `enum` looks safer and more powerful than Zig's `union` + `enum`, while Zig's `union` + `enum` appears more interoperable with C. A `union(Tag
15.
by tiehuis 8y ago
Zig is memory-safe if you keep runtime checks enabled (e.g. with debug or release-safe optimization levels) but it does not have the compile-time guarantees of Rust. I don't think the parent comment is a fair reflection. That being sai
16.
by tiehuis 8y ago
It certainly isn't out of reach to get a fairly close speed to GMP implementation-wise if you are willing to optimize the low-level loops in assembly. I think the simple cases are rather straight-forward to reach parity but once you st
17.
by tiehuis 9y ago
Memory is manually managed, yes. We do have defer (as in go) for slightly easier resource management. Zig doesn't have a default memory allocator. Allocators instead are expected to be passed as an argument to functions as they need th
18.
by tiehuis 9y ago
#include <stdint.h> #include <string.h> typedef struct { int32_t a; int32_t b; } Foo; int main(void) { uint8_t array[1024]; memset(array, 1, sizeof(array)); Foo *foo = (Foo*)(&a
19.
by tiehuis 9y ago
There was, but it was removed in LLVM 3.1 [1]. It seems as there have been some attempts to revitalize it [2] but these are targeting older versions and would probably require a lot more work to ever get back in-tree. [1] http://
20.
by tiehuis 9y ago
Not with the builtin error type. Its pretty much analogous to a c error code. If you wanted to send data you would need some other means like you suggest. I'd be interested in finding an ergonomic solution to this but it probably would
21.
by tiehuis 9y ago
Yes you have it right, `unwrap()` is equivalent to `%%`. It will panic if the result is an error. Error values under the hood are just unsigned integers and are returned on the stack. In fact, the granularity at which allocators are exposed
22.
by tiehuis 9y ago
A useful thing of this is also the portability story. Go for example is pretty good as far as I'm aware of cross-compiling to a different target. The main problem would probably be the extra implementation needed, instead of just writi
23.
by tiehuis 9y ago
I've been writing a fair bit since a few months ago, and have written a few things for the stdlib. Here are some examples I like about it. Hassle-free error management Consider you write a function fn div(a: u8, b: u8) -> u8 {