mlugg

6 ms·

1.
by mlugg 2mo ago
> OP handles the small change problem by hashing IR instead of source text OP here---I think you got confused somewhere, because this isn't true! The hashes we take are of source code, they're just stored inside of the firs
2.
by mlugg 2mo ago
Oh, I forgot to respond to the "corrupted binary" thing in my other reply, sorry. Right now, yep, corrupting the binary that the compiler reads would crash the compiler. In future, we want to detect the corruption and force a clea
3.
by mlugg 2mo ago
Zig uses a "single compilation unit" compilation model, so even if we did what you're suggesting, pretty much everything in the post would still be relevant, especially the whole-file stuff and the semantic analysis stuff. No
4.
by mlugg 2mo ago
It works through the fact that I specified "runtime" function ;) A bit after that quote I have a note about `inline` functions in Zig, where I mention that they perform semantic inlining, which means dependencies triggered by the
5.
by mlugg 2mo ago
That's there for translate-c, it's not used for compiling C code (To be clear, squeek502 is a part of the Zig core team [0], so he knows what he's talking about :D) [0]: https://ziglang.org/news/welcoming
6.
by mlugg 2mo ago
It only works with our self-hosted code generation backends (the main one being for x86_64), which right now don't have any optimisation passes. It's planned that they will in future, but that's a long-term goal. Also, any op
7.
by mlugg 2mo ago
Zig team member here---obviously I can't say for sure yet, but I'm pretty confident the number will be basically identical. In the Zig compiler, incremental updates (rebuilds) have a small amount of overhead which is roughly propo
8.
by mlugg 2mo ago
Worth noting that while it's absolutely unfortunate that we're hitting this Forgejo design flaw, AGit honestly is just a better workflow, and I (Zig core team member here, full push access to the upstream repo) have started using
9.
by mlugg 3mo ago
`u3` would be base 8, i.e. octal---I think you meant to use `[400]u6`? Aside from that: I'm not familiar with how standard base64 deals with endianness, so I'm not sure if it would match that, but this `@bitCast` would certainly g
10.
by mlugg 3mo ago
Uh, no? My writing style just happens to include a lot of em-dashes, as is very common. And it's not like I'm pasting a weird Unicode codepoint all over the place, that's just (rightly) how my Markdown gets rendered...
11.
by mlugg 3mo ago
I appreciate the kind words :)
12.
Fix Your Asserts(kristoff.it)
8 points by mlugg 4mo ago|0 comments
13.
by mlugg 5mo ago
> The current interim plan... What do you mean by "interim"? As I explicitly stated in the comment you quoted, it has never , and likely will never, been planned for the Zig compiler to become incapable of using LLVM. The LLVM
14.
by mlugg 5mo ago
> the build for x86_64 Linux failed. Hm, are you referring to the CI failure on the x86_64-linux-release CI job on the current tip of master on the main Zig repository? That one's a flaky test, not indicative of a serious problem. (
15.
Incremental Compilation with LLVM(ziglang.org)
4 points by mlugg 5mo ago|0 comments
16.
by mlugg 6mo ago
It is indeed (somewhat) related, and in fact that was fixed by this PR: https://github.com/ziglang/zig/issues/25771
17.
by mlugg 6mo ago
Oh, no problem at all & no shade of any kind intended! I just wanted to clarify this point since it seems like a good few people got that misconception. That doesn't mean you can't discuss breakage anyway, or ask questions of
18.
by mlugg 6mo ago
Hi, author of this devlog here! Not to dismiss concerns about breaking language changes, but there seems to be a bit of a misconception here that this compiler change was highly breaking and will require significant effort from Zig users to
19.
by mlugg 10mo ago
Zig team member here: we've migrated to Forgejo Actions [0], which is a system built into Forgejo (the Git forge used by Codeberg) which is very similar to GitHub Actions. In fact, while 1-to-1 compatibility is a non-goal, it's a
20.
by mlugg 10mo ago
I think this thread caused a bit of a hug of death; I too was seeing pretty bad page loads earlier today, but that seems to have sorted itself out. Understandable imo, because Codeberg simply haven't had to deal with this level of traf
21.
by mlugg 10mo ago
GitHub's API has extremely aggressive rate limits which make migrating large numbers of existing issues and PRs off of the platform borderline impossible. AIUI, this is why Gitea's main repo is on GitHub: they couldn't figure
22.
by mlugg 10mo ago
Forgejo Actions is what Zig has migrated to. It's very similar to GitHub Actions; the downside of that is that you inherit questionable design choices, but the big upside is that migration is super easy. While they don't target 1:
23.
by mlugg 10mo ago
This is extremely misleading. "Membership" is about direct contribution to and influence over the non-profit; it'd be somewhat analagous to being a GitHub shareholder. The very first question on Codeberg's FAQ [0] makes
24.
by mlugg 10mo ago
This was the very first thing I noticed when we (the Zig team) started seriously trialing Codeberg. Honestly, the transition was worth it just for the ability to navigate the website without a 3-5 second wait every time I click a link.
25.
by mlugg 10mo ago
> This has been pointed out to them many times, and it's seemingly not something they're willing to fix. On the exact page you're on is a link to an issue [0] acknowledging that the CAPTCHA is inaccessible and expressing t
26.
by mlugg 10mo ago
Yeah, that's actually what we've done on the Zig GitHub repository. However, it doesn't stop pushes to existing PRs, which isn't ideal; and, yes, it's quite hard to escape the conclusion that there being no "un
27.
by mlugg 10mo ago
PRs are not optional: there is no way to disable them on GitHub. I can't be sure that this is intentional, but it certainly works out well for them that this is one of many properties which make it quite difficult to migrate away from
28.
Actions/runner: safe_sleep.sh rarely hangs indefinitely(github.com)
5 points by mlugg 1y ago|0 comments
29.
by mlugg 1y ago
> Well, no. In zig that's `const x = foo(io)`. If `foo` needs to do IO, sure. Or, more typically (as I mentioned in a different comment), it's something like `const x = something.foo()`, and `foo` can get its `Io` instance from
30.
by mlugg 1y ago
Not quite: * Global variables still exist and can be stored to / loaded from by any code * Only convention stops a function from constructing its own `Io` * Only convention stops a function from reaching directly into low-level primiti

More ›