notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
hspak has quit [Quit: bye]
<cCCCCcccccCCc>
ikskuh: As a follow-up, I had another break a bit ago and I was able to get everything going with your help. Thanks again!
hspak has joined #zig
<daurnimator>
andrewrk: no more 0.7.0 section on download page?
<daurnimator>
ah I see above you decided to replace it
<daurnimator>
I guess checksums are still available from the json version of the page
hspak has quit [Quit: bye]
a_chou has quit [Remote host closed the connection]
waleee-cl has quit [Quit: Connection closed for inactivity]
spiderstew has joined #zig
spiderstew_ has quit [Ping timeout: 240 seconds]
osa1 has quit [Quit: osa1]
a_chou has joined #zig
osa1 has joined #zig
<justin_smith>
I'm trying to make a function that takes a string argument, when I have var foo "abc" and call f(foo.*) it says expected type '[*:0]u8' and got '[3:0]u8' - how do I fix the parameter declaration here?
<andrewrk>
justin_smith, can you take a utf8-encoded string?
<andrewrk>
if so, `[]const u8` is the type for you
<justin_smith>
OK, thanks, trying
<justin_smith>
andrewrk: cool, that solved it, I'm not sure how I would have figured it out without IRC though
<daurnimator>
justin_smith: try and break down what the type means
<daurnimator>
`[*:0]u8` = pointer to unknown number of u8s, but it ends in a 0.
<daurnimator>
`[3:0]u8` = 3 u8s then a u8 that is 0.
<daurnimator>
--> you could use `&` to turn your `[3:0]u8` into a `*[3:0]u8`. then you'd I guess need to know that "3" can coerce to "unknown number"
<daurnimator>
alternatively, if you don't want an unknown number, you can use `[]u8` to say "a runtime-known number"
<daurnimator>
you can also say e.g. `[:0]u8` to say "a runtime known number and there is a 0 afterwards"
a_chou has quit [Quit: a_chou]
<daurnimator>
you'd need to consider the purpose and body of your function to know which of these you want....
a_chou has joined #zig
a_chou has quit [Client Quit]
<justin_smith>
daurnimator: right, I started by declaring it as []u8, and then since I didn't have any examples of working string code handy, I was just trying various combinations of declarations and array / slice types to make the compiler happy
<justin_smith>
it would be nice if I could use "" for an initializer, then use it as a []u8, what I want is an array of u8 with a known length
<justin_smith>
I'm not trying to use C apis or anything, just match substrings from an input
ur5us has joined #zig
kkd has joined #zig
marnix has joined #zig
sord937 has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
<daurnimator>
justin_smith: you can
<daurnimator>
justin_smith: well; you can't use it as a []u8. but you can use it as a []const u8
lucid_0x80 has joined #zig
<dch>
there's no 0.7.1 download prebuilt tarball for FreeBSD x86_64, was this an oversight?
<dch>
^ cc andrewrk when he wakes up again
<andrewrk>
dch, still working on that tarball. should be up tomorrow
<andrewrk>
same with macos
<dch>
np. if there's anything I can help with, sing out. I pushed the lang/zig port up as it seems to work fine here, but obviously thats a build-from-src thing.
<dch>
also, congrats! 0.7.1 is almost 75% of the way to 0.99.999999
<andrewrk>
lol
<daurnimator>
we doing metafont-style versioning? :)
<daurnimator>
> The intervals between such maintenance periods are increasing, because the systems have been converging to an error-free state. The latest and best TeX is currently version 3.14159265 (and plain.tex is version 3.141592653); METAFONT is currently version 2.7182818 (and plain.mf is version 2.71). My last will and testament for TeX and METAFONT is that their version numbers ultimately become $\pi$ and
<daurnimator>
$e$, respectively. At that point they will be completely error-free by definition.
<radgeRayden>
lol
<dch>
not sure if package management tools are ready to represent irrational numbers and fundamental universal constants as version numbgers yet
<dch>
lmao
lqd has joined #zig
<semarie>
I think such tools would need it only to be sure the package has reach the "bug free state". else it would be fine.
<dch>
if only pkg managers reached a bug free state
<viashimo>
when doing bit shifts, i keep ending up with the following formulation: "var one: u64 = 1; x = one << some_var;"
<viashimo>
without doing this, the error is the the literal 1 doesn't have a comptime known width. is there are way to specify the width of an integer literal at comptime?
alexnask[m] has quit [Ping timeout: 260 seconds]
marnix has quit [*.net *.split]
dominikh has quit [*.net *.split]
jicksaw has quit [*.net *.split]
raggi has quit [*.net *.split]
terinjokes has quit [*.net *.split]
signop has quit [*.net *.split]
nickster has quit [*.net *.split]
bkleiner has quit [*.net *.split]
companion_cube has quit [*.net *.split]
Thalheim has quit [*.net *.split]
sjums has quit [*.net *.split]
kandinski has quit [*.net *.split]
alexnask[m] has joined #zig
amk has quit [Ping timeout: 246 seconds]
amk has joined #zig
dominikh has joined #zig
bkleiner has joined #zig
companion_cube has joined #zig
nickster has joined #zig
Thalheim has joined #zig
marnix has joined #zig
terinjokes has joined #zig
jicksaw has joined #zig
signop has joined #zig
raggi has joined #zig
kandinski has joined #zig
sjums has joined #zig
<daurnimator>
viashimo: `@as(u64, 1) << some_var`
<viashimo>
daurnimator: ok, thanks!
kenran has joined #zig
hlolli_ has joined #zig
cole-h has quit [Quit: Goodbye]
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
<kenran>
I've got a learnopengl project started in Nim some weeks ago, and I looked at how andrewrk was doing it in his tetris example. I'm on NixOS, so I created a simple shell.nix that contains glfw3 and epoxy, and I could do `nix-shell --run 'zig build play'` and it would work. But now (I guess a couple of nix-channel updates later) I'm getting "C import failed" with 'epoxy/gl.h' file not found. Any idea what's
<kenran>
happening maybe?
<kenran>
I know it's a long shot...
<ikskuh>
heya kenran
<kenran>
hi :)
<ikskuh>
not sure if i can help here, my nix experience is pretty shallow
<ikskuh>
do you have a nix file created for the build environment?
<kenran>
it basically provides only the glfw and epoxy libraries when entering the nix-shell environment. without that, the C imports fail in any case :)
<kenran>
in there, I can do `zig build window` or something just fine, usually. I didn't check for two weeks or so, and now I'm getting the C import failure even in the nix shell
<ikskuh>
weird
<kenran>
it might not have to do anything with Zig itself though, I don't know enough about it
<kenran>
ok, it's not just epoxy. that's just the first error. it cannot find glfw3.h any longer either. now it's definitely something with nix/my system
earnestly has joined #zig
st4ll1 has quit [Ping timeout: 256 seconds]
st4ll1 has joined #zig
<kenran>
I don't get it still. Trying out with a simple C++ example linking against -lglfw and including <GLFW/glfw3.h>, calling glfwInit() works in a `nix-shell -p gcc glfw3`, but I cannot get it to work for Zig anymore.
lucid_0x80 has quit [Ping timeout: 256 seconds]
jokoon has joined #zig
<jokoon>
wow 220 users
<ikskuh>
heya jokoon
<jokoon>
how many users are using a 3D engine or doing gamedev?
<jokoon>
I found an engine
<ikskuh>
i'm writing a game engine, prime31 is also writing some advanced game stuff in zig
<jokoon>
Curious if you can use zig to build console games
<jokoon>
or android
<ikskuh>
yes, you can do
<ikskuh>
console was afaik done by BaroqueLarouche, android was done by me (at least the baby steps)
<jokoon>
I would guess zig doesn't have the same goal in terms of safety compared to rust, but it's still better than C++ or C
<jokoon>
the didot engine seems quite advanced
<kenran>
I think I got it now... in the tetris repo it was some weird combination of importing the seemingly wrong package (glfw vs glfw3), and then cDefining something, plus including pkg-config in the nix environment.
<kenran>
AND ofc linking in the correct order.
<ikskuh>
kenran: oof
<kenran>
this is exhausting
<kenran>
I'm trying to write a terminal emulator (for educational purposes). I've selected 3 languages to try out: Nim, Zig, and Common LISP.
<ikskuh>
jokoon: no, zig doesn't try to guarantee most safety, but it tries to get very far without being in the way for the user
<ikskuh>
problem: ZWL doesn't support text input yet, this is yet to be done :(
<kenran>
Nim has a good package manager, is very fast as well and easy to learn, plus good C FFI. Zig has no package manager(? yet?), but has even easier C FFI, thus I could use freetype for font rendering (which Nim has no working bindings to atm).
<ikskuh>
yeah, there is no package manager yet
<kenran>
CL produces huge executables but is the most mature and best to work with imho, due to the REPL, and the awesome CFFI as well (lots of existing packages with good APIs).
<kenran>
I think as long as I only use some C libraries, I don't have a need for a package manager, as I can just use nix, right?
<ikskuh>
yeah, nix is a package manager :D
<kenran>
ikskuh: I got the window and triangle examples weeks ago, but they were broken today. I still don't understand why they ever worked on this NixOS system, seeing what I had to do today to get them to work.
marnix has quit [Read error: Connection reset by peer]
<earnestly>
It's funny how there's people like me who balk at the thought of yet another language package manager, and others who literally cannot cope without one
<ikskuh>
i don't really feel like zig actually needs one (at the moment)
<earnestly>
Hopefully it won't *need* one, that it exposes flags, environments, etc. to find necessary packages in a filesystem without having to use a bad package manager as middleman
marnix has quit [Ping timeout: 260 seconds]
marnix has joined #zig
<earnestly>
I often throw these new languages at a Makefile to see if it's sophisticated enough to build its objects and link things together as separate, trackable stages
<kenran>
Yeah I do the same actually. I even use make for languages that have a package manager and/or build tooling because it often makes for a nicer "UI".
<earnestly>
Well I'm not using it for the UI, that's often why people abuse Makefiles unfortunately
<ikskuh>
"zig build" is pretty awesome though
<kenran>
I'd be very fine with Zig just having a set of packages in nixpkgs, where, similar to how I use C libraries atm, I can just enter a nix-shell and then they're includable.
<ikskuh>
doing the stuff i do in zig build with Makefiles would be horror
<kenran>
Because I hate dealing with git submodules
<kenran>
Not for the idea of it, but because they're quite unwieldy imho
<ikskuh>
kenran: you can also just paste the whole library into your codebase and be done
<earnestly>
ikskuh: That should be a hint
jokoon has quit [Quit: Leaving]
<earnestly>
That it would be horrible
<ikskuh>
hm?
<earnestly>
That it would be horrible to transpant into something as simple as a Makefile should be a tell that something has gone wrong
<ikskuh>
i think i don't understand
<earnestly>
transplant*
<ifreund>
I disagree, there's a reason most projects are moving to meson these days
<ifreund>
*most non trivial projects
<ifreund>
and the zig build system is similar in scope to meson
<earnestly>
Yes, exactly
<ifreund>
and for trivial projects you can call zig build-exe in a Makefile with no issue :D
<earnestly>
ifreund: What's better: needing meson or not needing meson?
<ifreund>
I feel like that's not the right question. Of couse you can do everything that meson can do in a Makefile, but depending on the use-case it may be far more complex to implement and to maintain
<earnestly>
No you most certainly should /not/ be doing anything like that in a Makefile
<dominikh>
I think his argument is that things shouldn't be complex and unless all you need is a trivial makefile, things have gone wrong
<ifreund>
imo the extra dependency on meson more than pulls it's weight for non trivial projects
<ikskuh>
dominikh: look at the build script for zig showdown :D
<ifreund>
dominikh: that's a much more clear way of stating it :D
<earnestly>
dominikh: Yes, it's a Wirthian attitude which I don't think people know about. They also look at most Makefiles on the web and see how horrendous they are and believe that's what I'm refering to
<ikskuh>
it's not a complex project, but as soon as you have some modular dependencies, hell breaks loose
<earnestly>
ifreund: I like people to come to that conclusion naturally
<earnestly>
ikskuh: Why?
<dominikh>
FTR, I don't think I agree with it. Building things is hard, and if your makefile can be simple, it's solely because it's deferring to another build system (say zig build-exe)
<ikskuh>
12 packages, where some have C dependencies, but are only linked optionally
<ikskuh>
support for 2 different platforms, 3 different renderers, with 2 ways to manage resources
<earnestly>
ikskuh: That's straight forward to do with gnu make
<earnestly>
Almost 500 lines for a build definition
<earnestly>
400 sloc according to github
<ikskuh>
stuff like "when i have pulseaudio, enable this"
<ikskuh>
is not easy in gnu make either
<dominikh>
500 lines in the language you're already working with, with all the logic clearly visible. Versus make's own syntax with its own quirks and magic
<ikskuh>
↑
<ikskuh>
and you quickly leave the path of compatible make files
<earnestly>
I don't think any of you know what good makefiles look like and it may be terminal at this point
<ikskuh>
ever tried writing a makefile that runs on two platforms?
<CommunistWolf>
> good makefiles
marnix has quit [Read error: Connection reset by peer]
<ikskuh>
earnestly: there is no such thing as "good makefiles" for complex projects
<ikskuh>
been there, done that
<ikskuh>
i tried
marnix has joined #zig
<ikskuh>
i tried hard
<ikskuh>
but: as soon as the logic is too complex, having a imperative language is just the better option
<earnestly>
Yeah sure, nevermind. I think people are so caught up in the "makefile" thing that they're not really understanding; and I can almost guarantee that you've never seen a good makefile
<earnestly>
Hence the general attitude I always get, which is so predictable
<earnestly>
"Good makefile"
<earnestly>
"No such thing"
<earnestly>
etcv.
<ikskuh>
please define what a "good makefile" looks like
<ikskuh>
i've written a lot of makefiles
<dominikh>
well, you haven't shown a good makefile for a real-world, complex project yet
<ikskuh>
as soon as you need stuff like dependency tracking
<ikskuh>
the makefile isn't good anymore
<earnestly>
There's no point in this discussion
<ikskuh>
earnestly: how do you do dependency tracking in your make files?
<earnestly>
It misses the point
<ikskuh>
if you don't ,it's not a good makefile
<ifreund>
fwiw I get your point, I just have a slightly higher tolerance for software complexity than you do
<ikskuh>
if you do, i want to know how
<earnestly>
ikskuh: Like I said, there's no point in this discussion
<ikskuh>
then i don#t get to learn how a good makefile looks
<ikskuh>
well
<ikskuh>
keep on your high stance
<ikskuh>
and keep your secrets
<ikskuh>
if you don't want to share the secret knowledge of good makefiles
<ikskuh>
you'll never see them
<dominikh>
ikskuh: you just haven't seen one!
<earnestly>
Or read the manual
<ikskuh>
i read the manual
<ikskuh>
doh
<ikskuh>
still, there's no nice way for proper dependeny tracking
<ifreund>
the point is that you shouldn't need dependency tracking
<dominikh>
just don't have dependencies
<dominikh>
everything can be beautiful if you ignore the real world
<ikskuh>
ifreund: it makes sense to check if i need to rebuild things that take hours to build :D
<earnestly>
dominikh: (Ideally, don't ifdef)
<ikskuh>
earnestly: how do you do different dependencies on different platforms then?
<ikskuh>
i don't know a way except ifdef
<earnestly>
ikskuh: By sharing a common internal api while striving to the most portable feature set. An intersection of features rather than a union
<earnestly>
There's an old paper called "ifdef considered harmful" which discusses some of this
<ikskuh>
so
<ikskuh>
how do i do it then?
<ikskuh>
i write a library shim X
<ikskuh>
X wraps pulseaudio for linux and wasapi for windows
<ikskuh>
now i have to link to different implementations of X on windows, linux
<ikskuh>
i now need ifdef in my makefile
<earnestly>
Sigh
<ikskuh>
yes, we're in the real world
earnestly has left #zig ["WeeChat 3.1-dev"]
<ikskuh>
i now have the same interface (by using libsoundio)
<ikskuh>
i don't need #ifdef in my code anymore
<ikskuh>
but i now need the logic in the makefile
<dominikh>
what is your intersection between the Linux kernel and the Windows kernel…
<ikskuh>
(because i also need to link against libpulse on linux and wasapi on windows)
<dominikh>
ikskuh: and someone needs to build libsoundio
<ikskuh>
dominikh: i ignore that for now
<ikskuh>
even without that i have the same problem
<ifreund>
I'm sure the answer to that would be don't write cross-platform software
<ikskuh>
↑ i think so, too
<ifreund>
or rather write everything for posix only
<ikskuh>
wouldn't support windows newer than XP
<ifreund>
cross platform across linux/bsd/whatever is fine
* dutchie
notes that earnestly quit a couple of minutes ago (just after "yes, we're in the real world")
<dominikh>
plenty of nice APIs on Linux that the BSDs don't have
<ikskuh>
even then, you cannot rely on makefiles :D
<ikskuh>
dutchie: oh lol
<dominikh>
thanks dutchie
<dominikh>
it's a weird horse to die on
<dominikh>
(does make still use mtimes to figure out what to rebuild? because that's tremendously flawed)
<ifreund>
yeah, y'all should have your client show quit messages for people who have said something in the last 5 min
<ikskuh>
so the solution to "how do you cope with the real world" is "don't"
<dominikh>
ifreund: funny you would say that. mine does, and I still missed it in the frenzy of disagreeing with someone on the internet :P
<ikskuh>
ifreund: i did, but i just mentally skip quit messages :D
<ifreund>
heh
<ikskuh>
dominikh: LOL same :D
<ikskuh>
but i really wanted to know how they solve this
<ikskuh>
because they said they know better than me, and i want to get better
<dominikh>
odds are they don't solve it
<ifreund>
at least not in a way that you would consider "solved"
<ikskuh>
but to get a conclusion: zig build is way more portable than a "make" will ever be :D
<ikskuh>
we only need dependency tracking for our self-written files now
<dutchie>
yeah, and you don't have to learn another arcane syntax with non-portable implementations
<dutchie>
what's that word lispers use to say that everything is the same shape
<dominikh>
Personally, I think that both makefiles and zig build files are bad for most open source, and much prefer the Go model, with no arbitrary code executing at build time, and anything that doesn't fit into the build model needs to be generated and checked in. I only value the Zig model in highly custom, probably prorietary work, like games
<dutchie>
homoiconicity!
<dutchie>
sort of like that
<dominikh>
bbl, dinner
<ikskuh>
dominikh: i think doing some stuff in zig build isn't that bad. especially as you can encode most platform dependencies in a nice and configurable way
<ifreund>
how do go projects add a build step to e.g. compile man pages and install them?
<ifreund>
or are you supposed to check the compiled versions into git??
<dominikh>
ifreund: check the compiled version in, or defer to another build system (like the linux distro package manager that builds man pages, anyway)
<ifreund>
I'm using scdoc so I'd need to check them int
<ifreund>
I really don't like checking the output of code generators/compilers into vcs
<dominikh>
generally speaking, you can download a Go project, run `go build`, and it will build the proejct, without running custom code. if that's not good enough for your needs, you're screwed. some projects use e.g. Bazel instead
<dominikh>
but I definitely do believe in checking in generated code. It means I don't need your generator to compile the project
<dominikh>
and there won't be version drift in the generator, either
<dominikh>
(I also can blindly build a project, outside a sandbox, and only have to worry about bugs in Go itself, not about exploits in your build script)
<ikskuh>
the solution to version drifts in the generator is also checking in the generator into your repo
<ikskuh>
and build it on the platform you use
<dominikh>
plus my generator's dependencies, and…
<ikskuh>
zig showdown for example converts assets via zig code
<ikskuh>
if i check in the genereated files
<ikskuh>
the repo gets 10 times the size
<radgeRayden>
re: make, I've just rewritten mine that coordinates building several dependencies for a game into a doit python script and couldn't be happier about it
<dominikh>
at any rate, Go's model works well for 95% of actual Go projects; the rest have to use a different build system. I'm sure Go's model would suck majorly for, say, a game and its asset pipelines
<dominikh>
which sounds like what "zig showdown" is, too
<ikskuh>
yeah :D
<dominikh>
I don't actually know what that is
<ikskuh>
for zig we need at least a convenient way to declare packages
<dominikh>
I view programming languages and their tooling from two different perspectives: the "make sure junior devs can't ruin my day" perspective and the "I know what I'm doing, get out of my way" perspective. I can look at most people's Go code and not shoot myself; I definitely don't want to read most people's C code :P
<dominikh>
if you only work with other experts, whoo. use a powerful language
<dominikh>
if you don't, it's amazing when people can't fuck up majorly
<ikskuh>
i think zig hits a sweet spot there
<ikskuh>
the stuff is simple, and basically saf
<ikskuh>
eif you want to shoot, you can do so, but it will be visible
<dominikh>
Somewhat. still plenty of ways to shoot yourself with vanilla-looking Zig
<dominikh>
e.g. retaining a pointer to a stack variable when you shouldn't. boom.
<ifreund>
yeah, zig is closer to C than Go by that mesasure
<ifreund>
but it's also what I want
<dominikh>
I mean, there's a reason I switched to Zig for my Wayland compositor, but will stick to Go for higher level tooling
<dominikh>
way different needs
<ifreund>
I'm doing AoC in go this year because it's at least partially productive if I use a language I've never used before
<ifreund>
but go kinda annoys me
<dominikh>
Go won't really let you swim against the current
<ifreund>
especially the stupid Capitalize to make it public thing
<dominikh>
^ one of my favourite features :P
<ifreund>
I want my types capitalized so I can do func (point Point) Point {}
<dominikh>
well, that receiver should probably be called p or pt instead
<dominikh>
Go likes its 1-2 letter local variable names, so you rarely have conflicts like that
<ifreund>
yeah that's pretty much what I've been doing
<ifreund>
but I still think having types TitleCase is a huge win for readability
<dominikh>
I'm already pleasantly surprised you didn't call it self :P
<ifreund>
and go cant do that consistentl
<ifreund>
also it doesn't seem to have immutability
<dominikh>
looking at an identifier and knowing if it's exported or not is also a big win, though. different tradeoff
<ifreund>
fair
<dominikh>
it does not, no
<ifreund>
that's probably a bigger blocker to me wanting to use it for larger projects tbh
<ifreund>
error handling also makes me miss zig :/
<dominikh>
because Go doesn't have try?
<ifreund>
yeah
<dominikh>
well, Zig still won't let me attach values to errors :P
<ifreund>
I'm halfway convinced attaching values to errors isn't needed
<dominikh>
I'm 100% convinced it is
<dominikh>
unless you want to rely on out parameters
<ifreund>
for what purpose? logging can be done where the error occured
<dominikh>
an error "open failed" is utterly useless without knowing which path it concerns
<dominikh>
and not just for the user's sake (and I disagree with logging where the error occured; that's too deep in the stack), but also the programmer for any sort of batch job
<dominikh>
it also allows for nested errors, ideally. this big operation failed because some sub operation failed.
<ifreund>
I'm not sure how this could be implemented cleanly without allocation or making returning errors very expensive
<dominikh>
you probably can't do full Go-style errors without allocation, but the simpler form of one value per error would "only" need a errorset-specific union of possible values
<dominikh>
and I still definitely want to know for what path the open syscall failed when the error bubbled up the stack
<ikskuh>
i'm convinced we don't need error attachments
<ikskuh>
especially not for the example you've shown
<ikskuh>
FileNotFound is pretty much 100% precise which file was not found
<ikskuh>
if you bubble it up when you open two files though, you lose information
<ikskuh>
which means that your returned error code is bad
<dominikh>
well, there is an infinite number of file names and only a finite set of error codes
<ikskuh>
yes
<ikskuh>
but
<ikskuh>
there is a very finite number of files you open
<ikskuh>
in a function invocation
<ikskuh>
that is mostly 1
<ikskuh>
like
<ikskuh>
std.fs.cwd().openFile("foobar", .{})
<ikskuh>
if that returns FileNotFound
<ikskuh>
i don't have to ask *WHICH* file closes
<dominikh>
That's a very trivial example. Consider a more polymorphic use case. Maybe openFile determines the file to open via some computation
<dominikh>
in which case, it needs to communicate to the caller which file it chose that failed to open
<leon-p>
in that case, why not simple split it into two functions, chooseFile and openFile? Then when the FileNotFound error comes up the context calling openFile definitely knows which file was not found.
<dominikh>
do you further want to split up the function if it needs to choose multiple files? have some sort of contiuation to pass in all the file names? you're also quickly going break abstractions.
lucid_0x80 has joined #zig
<dominikh>
*going to
hexaflex has joined #zig
<hexaflex>
I found another compiler bug: #7442
<dominikh>
at the end of the day, `main` should be the one doing logging. if something failed, it should have enough information to log how the action failed
<dominikh>
and main doesn't know all the arguments for all the functions in the entire call stack
koakuma has joined #zig
<dominikh>
all other examples are just more specific variations of this.
<ikskuh>
dominikh: in that case, it looks like the error reporting is non-trivial anyways
<hexaflex>
Errors are not very useful without adequate context
nore has joined #zig
<ikskuh>
dominikh: your example in that proposal is a parser
<dominikh>
(not my example)
<ikskuh>
oh, sorry
<ikskuh>
but even then:
<ikskuh>
there are two kind of errors in programs
<ikskuh>
zig errors are only one kind, and exceptions (what people use in other languages) are also of the same kind
<ikskuh>
unexpected errors in the program flow
<ikskuh>
the other kind is expected errors
<ikskuh>
most programmers i know don't really distinct between them
<ikskuh>
parsing some text is either expected to fail (user input) and not expected to fail (non-user input)
<dominikh>
I find the notion of "unexpected errors" to be misleading. errors are always expected, they happen all the time. Zig already gets that right by _not_ having exceptions, and making handling of errors explicit. so I think your two kinds of errors _should_ be conflated. and attaching values with errors happens to cater to both kinds.
<ikskuh>
zig errors are meant for the second use case
<dominikh>
if I ask the kernel to open a file, I fully expect it to fail
<ikskuh>
i think they should not be conflated
<ikskuh>
because i don't need to report most failure conditions
<dominikh>
(and if parsing cannot fail, it should be parsed at compile time)
<ikskuh>
or even have more complex reporting than "oh no"
<ikskuh>
what i mean is:
<ikskuh>
when i expect a file to have a certain format
<ikskuh>
"InvalidChar" and "Overflow" are the same error: InvalidFormat
koakuma has quit [Quit: Leaving.]
<dominikh>
But InvalidChar and Overflow subsume InvalidFormat. one is strictly more powerful than the other
<dominikh>
you don't need the less capable kind of error if you have the more capable kind
koakuma has joined #zig
<ikskuh>
that's a question of philosophy
<dominikh>
using InvalidFormat also assumes that the caller never cares to know about the actual error
<ikskuh>
in most cases, that's true
<dominikh>
my "philosophy" is probably strongly biased by Go and its notion of interfaces and behavior
<ikskuh>
like "i want to load a 3D model"
<ikskuh>
and i don't care if a number overflows
<ikskuh>
or if a vertex is out of bounds
<ikskuh>
the model is still broken and i cannot continue
<dominikh>
which makes it very straightforward to have N errors that all identify as "invalid format (because ...)"
<ikskuh>
when i'm writing a santizer for 3D models that's a different use case, but that requires very different data structures
<dominikh>
if I want to load a 3D model and it doesn't, I really want to tell my user how the model is broken
<ikskuh>
why?
<ikskuh>
do you really wnat to say: "byte 34523424 in file C:\…\file.fbx is out of bounds"?
<ikskuh>
do you really expect *anyone* to fix that?
<dominikh>
because the user knows more. they may know why that error occured. maybe they just edited the model with their own tool
<dominikh>
imagine if `ls foo/bar/baz` just said `error.`
<dominikh>
the error message wasn't good enough if I have to strace your program
<ikskuh>
dominikh: the thing is: for whom do you build your programs?
<ikskuh>
the people i write software for don't read error messages
<ikskuh>
they just *ignore* them
<dominikh>
I write programs for "hackers", people with roughly the same understanding of computers as me
<ikskuh>
yeah
<ikskuh>
that's very different :D
<dominikh>
and I write programs the way I'd want them to be
<ifreund>
they'd probably prefer an error trace then
<ikskuh>
^=
<dominikh>
I _hate_ using software written for idiots
<ikskuh>
write the return trace to the log
<ikskuh>
which you can enable/disbale
<ikskuh>
but the normal user doesn't *WANT* this information
<dominikh>
I also hate error traces, tbh. I don't call about your call stack, I care that some file had the wrong permissions
<dominikh>
*don't care
<dominikh>
Python-style error "handling" is the worst. you hit ^C and it shows you a stacktrace because it got a sigint "exception"
<dutchie>
`raise SystemExit`
<dominikh>
there's still a distinction between a hacker _using_ software and _working on_ software. the former cares about the nature of the error, but not its precise location in the source code
<fengb>
Why is that bad? It shows you where it bailed out
<dominikh>
because I don't care where it bailed out; I just wanted to kill the process. it doesn't have to tell me anything
<dominikh>
it's not unexpected that the process got a sigint after I hit ^C
<dominikh>
similarly, if it can't find a file, I don't care about where in the code opening that file failed. I wanna know the file name, that's the useful information to me as the user
<dominikh>
not 30 lines of stack trace
<dominikh>
stack traces are for programmers, error messages are for users
<dominikh>
stack traces are for truly unexpected errors, like a segfault. expected errors don't need stack traces
xackus has joined #zig
nyaayaya has joined #zig
sawzall has quit [Ping timeout: 272 seconds]
nyaayaya has quit [Client Quit]
hexaflex has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<ikskuh>
they should be linked from the 0.7.1 release notes
fwg has quit [Quit: .zZ( sleep is healthy )]
lucid_0x80 has quit [Ping timeout: 240 seconds]
cole-h has joined #zig
tomku has quit [Ping timeout: 240 seconds]
tomku has joined #zig
marnix has quit [Ping timeout: 246 seconds]
marnix has joined #zig
fwg has joined #zig
fwg has quit [Client Quit]
fwg has joined #zig
LanceThePants has quit [Read error: Connection reset by peer]
LanceThePants has joined #zig
tomku has quit [Ping timeout: 256 seconds]
<leeward>
hmm, I wonder if that hack in the linker script to drop "elf32-msp430" is why "info reg" in gdb showed me x86 register names.
<leeward>
The thing it called eax was r0 though, which is amusing.
tomku has joined #zig
fwg has quit [Quit: .zZ( sleep is healthy )]
leon-p has quit [Remote host closed the connection]
fwg has joined #zig
wootehfoot has joined #zig
ur5us has joined #zig
karrick has quit [Read error: Connection reset by peer]
procnto has quit [Read error: Connection reset by peer]
kwilczynski has quit [Read error: Connection reset by peer]
kushalp has quit [Read error: Connection reset by peer]
r0bby has quit [Read error: Connection reset by peer]
karrick has joined #zig
procnto has joined #zig
kwilczynski has joined #zig
r0bby has joined #zig
kushalp has joined #zig
fwg has quit [Quit: .zZ( sleep is healthy )]
fwg has joined #zig
fwg has quit [Quit: .zZ( sleep is healthy )]
fwg has joined #zig
weekOldRoadkill has quit [Quit: Leaving]
fwg has quit [Client Quit]
<leeward>
If I have a comptime-known constant, is there a way to get it into an inline asm statement without going through a register?
<leeward>
Other than literally writing its value in the string, that is.
<ikskuh>
leeward: good question, i think you can use a fitting inline info
<ikskuh>
i think using "i" is the right thing
<leeward>
ikskuh: Can you elaborate?
<leeward>
`: [number] "{i}" (my_constant)`?
<ikskuh>
only "i", not "{i}"
<ikskuh>
but yes
<leeward>
trying
tomku has quit [Ping timeout: 260 seconds]
<leeward>
Hey, it works!
<ikskuh>
\o/
tomku has joined #zig
<g-w1>
why does test-stage2 not tell me which test leaked memory, (or am I just not seeing it) https://paste.rs/755 ? it just tells me one of the tests in stage2/test.zig failed, which is very broad
<g-w1>
Just realized that I can tell from the stack trace of the zir_sema, but this would still be a nice feature to have
stzsch has joined #zig
sord937 has quit [Quit: sord937]
tomku has quit [Ping timeout: 256 seconds]
tomku has joined #zig
ur5us has quit [Remote host closed the connection]
ur5us has joined #zig
<g-w1>
ok, this is the weirdest thing, I am getting those memory leaks shown to me when doing zig build test-stage2, but when I just try to build a test that is causing a memory leak using `./zig-cache/bin/zig build-exe test.zig` it does not show a leak? I have pushed the code to `g-w1/stage2-compile-log` if anyone wants to take a look.
ifreund has quit [Ping timeout: 265 seconds]
ifreund has joined #zig
<g-w1>
*pushed to `g-w1/zig branch stage2-compile-log` on github
<marler8997>
zig build test-stage2 doesn't just build an executable, it builds and runs tests
<pixelherodev>
Finally made up my mind: going to work on an alternative compiler :)
<marler8997>
pixelherdev, share more
nycex- has joined #zig
nycex has quit [Ping timeout: 240 seconds]
<pixelherodev>
marler8997: not much to say just yet
<pixelherodev>
Still in the planning stage
<marler8997>
what made you think to make an alternative compiler?
<pixelherodev>
See backlog :P Mostly, stage1 == :( and stage2 is (IMO) overcomplicated
<marler8997>
backlog as in the number of bugs/issues?
riba has joined #zig
<pixelherodev>
chat history :P
<marler8997>
which day?
<pixelherodev>
grep pixelherodev; should be one of the most recent commentsby me
<marler8997>
not sure how to grep the logs...is there a way to download them?
<pixelherodev>
Ah, I'm used to weechat; I have them locally already :P
<marler8997>
yeah I'm clicking through each day looking for "pixelherodev" on the web interface
<marler8997>
so knowing the day would be helpful
<g-w1>
dec 2
<marler8997>
thanks g-w1
GrooveStomp has joined #zig
xackus has quit [Read error: Connection reset by peer]
xackus_ has joined #zig
<marler8997>
pixelherodev, you said you find CBE-ing stage 2 "kinda repulsive after more thinking about it"...what sort of things did you discover are repulsive about it?
wootehfoot has quit [Read error: Connection reset by peer]
<pixelherodev>
Firstly, CBE is explicitly intended to produce binaries disguised as C source - which is one reason its input is ZIR, not Zig. This is akin to producing asm, then using a naive decompiler, and manually cleaning up the output. It's absolutely *not* going to be pretty - and isn't meant to be. Secondly, and relatedly, this is going to mean changing the CBE in abranch *specifically for the translation*,
<pixelherodev>
to make its output easier to work with, which I don't agree with. Fundamentally, it means that we'll need to maintain two copies of an identical compiler in different languages.
<marler8997>
pixelherodev, yes I recall the plan being a one-time generation to C, then maintaining both backends independently
<marler8997>
I asked why we wouldn't just use the CBE as part of codegen, why would we maintain it independently but never got an answer
<pixelherodev>
...?
<g-w1>
is your backend going to be adopted by the zig project once it gains momentum?
<marler8997>
...?
<fengb>
Generated code isn’t considered maintained code
<pixelherodev>
marler8997: the generated compiler would be stage1
<pixelherodev>
Not a backend
<marler8997>
yes
<fengb>
Projects like Debian will not include raw generated code
<pixelherodev>
It'd be maintained separately because we need a proper bootstrap compiler
<marler8997>
right, I'm saying why
<pixelherodev>
And generated code isn't remotely acceptable as such :P
<marler8997>
right
<pixelherodev>
Might as well use a binary.
<fengb>
Ask Debian :P
<marler8997>
right
<marler8997>
so then why is that the plan?
<pixelherodev>
I fully agree with debian on this
<pixelherodev>
g-w1: Who knows? That's not my *intent*, but I wouldn't have a problem with it if it did. My intent is to make a compiler that *I* like
<marler8997>
I think my first statement was confusing, let me reword
<marler8997>
I recal the plan to be that once CBE was working, we would perform a one-time generation to convert the compiler to C, then maintain that C compiler independently
<marler8997>
to support bootstrap
<marler8997>
but why would we do that? Instead, why not keep the CBE unmodified? Why do we need to maintain it? If it has a problem, we should fix it in CBE correct?
<fengb>
Because it’s a generated code base and not fit for real bootstrapping
<marler8997>
fengb yes
<marler8997>
but what about my question?
<marler8997>
oh wait nvm
<pixelherodev>
CBE != generated code
<marler8997>
you're saying we shouldn't use the gnerated code for bootstrapping
<fengb>
The problem is generating it at all nullifies it from certain tool chains
<fengb>
Yeah
<marler8997>
isnt' that what Nim does?
<marler8997>
and other languages?
<fengb>
A lot of languages bootstraps into C yes
<marler8997>
I was perusing another langauge that only supports a CBE, and it commits it's generated C code to a repo for bootstrapping
<fengb>
Zig wants to bootstrap without C, but also with C
<pixelherodev>
Yes. That's one of the key reasons I'll *never* use Nim.
<marler8997>
fengb, not following
<marler8997>
what's wrong with using CBE for bootstrapping?
<fengb>
Cause the rule lawyers don’t allow generated sources
<pixelherodev>
Same as using a binary for bootstrapping, which defeats the purpose
<fengb>
I don’t know why they don’t like it
<marler8997>
who are the rule lawyers?
<fengb>
Debian for one
<marler8997>
oh gotcha
<marler8997>
So the reason for not using CBE to bootstrap is because of Debian?
<pixelherodev>
That's *a* reason.
<fengb>
Basically, anything with CBE is considered starting with Zig, which isn’t really bootstrapped from C at a purity level
<marler8997>
pixelherodev, all programs are technically bootstrapped by binaries if you go down far enough
Akuli has quit [Quit: Leaving]
<pixelherodev>
marler8997: but most *can* be bootstrapped with a "fully" source chain
<pixelherodev>
There's a distro that bootstraps from a raw assembler
<marler8997>
pixelherodev, by using CBE, we're bootstrapping from the Zig source
<marler8997>
and using C as an intermidiary format
<pixelherodev>
We're using C as a *binaryformat*
<pixelherodev>
It's not any better than using ELF
<marler8997>
pixelherodev yes
<marler8997>
but we're generating it from the Zig source
<pixelherodev>
That's the *problem*,yes :P
<marler8997>
it's not the same as having a binary that you don't have source to
<marler8997>
for the C code from CBE, we have the source to re-generate it
<pixelherodev>
Doesn't matter
<marler8997>
that's all that matters :)
<marler8997>
that's the distinction
<pixelherodev>
If you have the GCC source, that doesn't make the binary acceptable for bootstrapping
<marler8997>
The source is what is used for bootstrapping
<marler8997>
The GCC source
<pixelherodev>
Exactly
<marler8997>
and the binary is an output of that
<pixelherodev>
Using the CBE would mean using a Zig *binary* for bootstrap
<marler8997>
so in the Zig case, the Zig source code is the source, CBE is an intermediate representation
<pixelherodev>
CBE output == binary
<marler8997>
pixelherodev, sure, but I'm not saying that we submit just CBE to debian
<pixelherodev>
It's *explicitly* produced *after* optimization, lazy eval, comptime, etc
<marler8997>
you can submit the Zig source, and generate the CBE
<pixelherodev>
Nope!
<fengb>
They can’t process zig source
<pixelherodev>
Can't generate the C variant *without the Zig compiler*
<marler8997>
they can only process C source then?
<pixelherodev>
Which you can't build... *without a Zig compiler*
<fengb>
And they can’t use the CBE code because it’s generated
<marler8997>
they can only process C source then?
kenran has quit [Remote host closed the connection]
<pixelherodev>
Or langs with a C-based compiler
<pixelherodev>
That's true of almost every distro
<marler8997>
so how do they process C source?
<fengb>
That’s the bootstrapping problem
<marler8997>
which they have solved
<pixelherodev>
Depending on the distro: with the existing C compiler (GCC, self-bootstrapped), with a bootstrap chain from assembly (simple assembler -> complex assembler -> simple C compiler -> complex C compiler)
<fengb>
The point is they only have to trust the C bootstrap right now
<fengb>
They won’t trust the Zig bootstrap
<marler8997>
why?
<pixelherodev>
Trusting trust, for starters
<fengb>
Because Zig isn’t big enough
<fengb>
Or trustworthy
<pixelherodev>
Eh, not quite
<marler8997>
why would they trust source written in C but not in Zig?
<pixelherodev>
They don't trust the *binary*
<pixelherodev>
It's not about the source
<fengb>
They have to trust something. And they already trust C
<marler8997>
pixelherodev, I've moved on to the next question
<pixelherodev>
It's possible to write a compiler which maliciously injects code into binaries
<marler8997>
the next question is...."how do they process C source"
<pixelherodev>
I answered that :P
<pixelherodev>
> Depending on the distro: with the existing C compiler (GCC, self-bootstrapped), with a bootstrap chain from assembly (simple assembler -> complex assembler -> simple C compiler -> complex C compiler)
<marler8997>
so they are using binaries to bootstrap?
<pixelherodev>
When bootstrapping Gentoo for instance, it uses the system compiler (typically GCC) to build the target compiler
<pixelherodev>
Then the target compiler builds everything else
<marler8997>
so they are using binaries to boostrap?
<pixelherodev>
Depends on the distro
<marler8997>
there's a distro that doesn't us binaries to bootstrap C code?
<CommunistWolf>
also debian's definition of FOSS is pretty strict
<pixelherodev>
Like I said, there's at least one that uses an assembler
<fengb>
The point is, you can’t introduce a new binary in the chain. Zig is considered a binary if you can’t build it. And the source is considered tainted
<CommunistWolf>
if it's not the form preferred for making changes, it's not the source
<marler8997>
*fengb* why can't you introduce new binaries into the chain?
<CommunistWolf>
ran into this with some shaders once
<marler8997>
how did the original C compiler get introduced into the chain?
<pixelherodev>
marler8997: because that expands how much needs to be trusted
<pixelherodev>
Via assembler
<pixelherodev>
There are paths to bootstrapping GCC from ahex editor
<CommunistWolf>
there was a time when debian wasn't self-hosting, but today is not that time
<marler8997>
pixelherodev, yes, but you're limiting everything to custom maintained C code
<pixelherodev>
The emphasis is "maintained"
<marler8997>
i.e. you're saying you can't use CBE in this chain
<fengb>
Because you shouldn’t have to add more trust
<marler8997>
right, so by extension, binaries aren't maintained, so you can't use binaries either
<marler8997>
but the chain does have binaries
<marler8997>
these rules are contradicting each other
<pixelherodev>
no
<fengb>
C exists because it exists. Kind of a roundabout answer yes but that’s the bootstrapping problem
<marler8997>
yes, but that's not the contradiction
<fengb>
You can’t add more assumptions to trust though
<fengb>
Cause some people won’t trust it
<pixelherodev>
the binaries in the chain aren't comparable to adding an arbitrary new binary
<marler8997>
the contradiction is that you're saying we can't use the CBE in the chain because it's generated code, but binaries themselves are generated, so saying that the chain can't have generated code doesn't hold true
<fengb>
CBE source is tainted source
<pixelherodev>
The binary was at some point produced by a trusted compiler, and is thus in turn trusted
<marler8997>
it's generated source just like binaries
<marler8997>
if you disallow generated code then you can't use binaries either
fwg has joined #zig
<pixelherodev>
CBE output (or any random binary) isn't a known part of the chain
<marler8997>
and do these toolchains update the C binaries?
<pixelherodev>
The existing compiler has a history
<marler8997>
you said that you can't add new binaries, but I have a hard time believing that they never update their toolchains
<fengb>
Most bootstrapping starts with some assumptions
<CommunistWolf>
some parallels can be had with bootstrapping debian to a new architecture
<fengb>
One common assumption is a C compiler
<pixelherodev>
There was at one point a trusted binary built from trusted source
<pixelherodev>
That was used to build a trusted binary, etc
<fengb>
It sucks that C gets to be special but that’s how history has evolved
<pixelherodev>
CBE output itself has to be produced *by a Zig compiler*
<fengb>
Other bootstrapping chains actually code up a C compiler in assembly
<pixelherodev>
That Zig compiler *binary* - the thing *producing* CBE output - *is not trusted*
<marler8997>
pixelherodev, and that Zig compiler can be generated with C source (that is also generated)
<pixelherodev>
Who gets to generate the CBE-ed compiler? Not Debian./
marnix has quit [Ping timeout: 264 seconds]
<pixelherodev>
marler8997: nope
<CommunistWolf>
these days they use the amd64 compiler and cross-compile things to solve the bootstrapping issue. way back before debian 1.0, they probably snagged a gcc from redhat or so. they won't do it today
<marler8997>
pixelherdev, yup :)
<pixelherodev>
because at some point in the history, there *will* be an untrusted compiler
<pixelherodev>
If I do it, that means I had an arbitrary Zig binary, which I could've tweaked to be malicious
<pixelherodev>
Which means CBE source could be malicious
<marler8997>
pixelherdev nope
<pixelherodev>
The distro cannot produce the binary themselves
<pixelherodev>
Not without analready-trusted binary
<marler8997>
you take your trusted C compiler, compile the code generated by CBE, now you have a Zig compiler
<fengb>
Anal ready 🤔
<fengb>
CBE is tainted source. Already not viable
<marler8997>
what do you mean "tainted"?
<pixelherodev>
marler8997: but that CBE output was produced *by a compiler*
<pixelherodev>
Which *is not trusted*
<marler8997>
so
<pixelherodev>
The CBE output isn't trustworthy
<marler8997>
it's source code that you can read and verify
<pixelherodev>
No, it's not.
<marler8997>
just like any other source code
<fengb>
So committees argue this and reject generated source
<pixelherodev>
CBE output *is binary*
<marler8997>
how do you verify any source is trusted?
<pixelherodev>
CBE output is 100% considered binary code
<pixelherodev>
Even by Zig.
<fengb>
Again, you don’t have to convince us
<pixelherodev>
Actually, you do :P
<marler8997>
it's not 100% binary code, it has aspects of both binary and source code
<fengb>
(You might have to convince phd, but he doesn’t really matter here)
<marler8997>
how do you verify any source is trusted?
<pixelherodev>
marler8997: according to the Zig project (or, if you prefer, according to Andrew): CBE output is 100% intended to be a binary
<fengb>
If Debian rejects this, and they will, then it’s unviable
<marler8997>
you're claiming that CBE is untrusted, so that how do you determine whether any new source is trusted or untrusted?
<pixelherodev>
It's not about the CBE
<pixelherodev>
It's about the compiler producing it
<marler8997>
how do you verify whether new source is trusted or untrusted?
<pixelherodev>
Which is stage2 built by stage1
<pixelherodev>
(or stage2 built by stage2 built by stage1)
<fengb>
Lots of people auditing the source
<marler8997>
how do you verify whether new source is trusted or untrusted?
fwg has quit [Quit: .zZ( sleep is healthy )]
<marler8997>
so why can't people audit CBE source?
<fengb>
They won’t touch generated sources
<pixelherodev>
Because it's *not source*
<pixelherodev>
It's machine code disguised as C
<pixelherodev>
Deliberately
<pixelherodev>
That's how it was designed
<pixelherodev>
Forgetting Debian for a second
<pixelherodev>
Every decision made in the CBE's design has been to make its output machine code disguised as C, and *not* sourcecode
<marler8997>
so you're saying because it's hard to read?
<pixelherodev>
It's as good as assembly
<marler8997>
not really though
<pixelherodev>
Yes, really
<marler8997>
but in any case, assembly is still source that can be audited
<pixelherodev>
It runs after optimization, and isgenerated from IR
<marler8997>
are you saying that all assembly code is untrusted?
<fengb>
Not generated assembly though
<pixelherodev>
Good luck getting anyone to take "Let's audit a few MLoC of asm!" seriously :P
<pixelherodev>
Handwritten asm, sure
<fengb>
No, just generated code is off limits
<marler8997>
if so, how did they verify the original compilers written in assembly?
<pixelherodev>
Because handwritten asm is readable
<pixelherodev>
The output of `gcc -O2` is nonsense
<marler8997>
ok, so the reason is, generated code is harder to read than handwritten code?
<pixelherodev>
(as far as humans are concerned)
<pixelherodev>
Not "harder," "unreasonable"
<pixelherodev>
It's *not real code*
<marler8997>
so if we made CBE readable then it wouldn't be a problem?
<pixelherodev>
You know how Super Mario 64 was decompiled?
<CommunistWolf>
no
<pixelherodev>
Understanding it requires the same kind of process
<CommunistWolf>
it has to be the preferred format for making changes
<CommunistWolf>
that is what the definition of source means in this case
<marler8997>
CommunistWolf gotcha
<marler8997>
ok what about this
<pixelherodev>
Hence, the one shot translation
<pixelherodev>
In which we, effectively, compile it to machine-code-as-C and then decompile it into C
<pixelherodev>
That's not something that can reasonably be done multiple times
<marler8997>
deploy Zig code and CBE code, during build, compile CBE to make Zig compiler, then compile Zig code to CBE, compare that generated CBE is the same as the committed CBE
<pixelherodev>
You *can't*
<pixelherodev>
Because that requires trusting it
<pixelherodev>
Which is never going to happen
<CommunistWolf>
easiest (haha) way to solve the bootstrapping problem is probably to write a minimal zig compiler in C-or-something-else
<marler8997>
if they are equivalent, then you by veryfing the Zig code you are transitively also verifying the CBE code
<pixelherodev>
marler8997: nope
<pixelherodev>
trusting trust
<pixelherodev>
compiler can modify the sources it's compiling
<pixelherodev>
if you don't trust CBE, then the produced Zig compilerisn't trustworthy either
<marler8997>
pixelherodev, be careful what I just said is a bit complicated, you may want to take a moment to ponder on it
<pixelherodev>
So its generated CBE can't be trusted
<pixelherodev>
Not really
<pixelherodev>
This is a known problem
<marler8997>
I didn't say CBE is trusted
<CommunistWolf>
go probably got into debian via gccgo, although I'm not certain of that
<pixelherodev>
It has to be for that to work
<marler8997>
my scenario assumes CBE isn't trusted
<pixelherodev>
yes, but it doesn't solve it
<marler8997>
again, take a moment to look at it
<pixelherodev>
The generated CBE could be malicious
<CommunistWolf>
maybe it was added when the go compiler still wasn't self-hostingf
<marler8997>
it's not simple
<pixelherodev>
I *did*
<marler8997>
pixelherodev yes I agree
<pixelherodev>
Don't assume that I don't understand lol
<marler8997>
I didn't assume, you just responded very quickly to something that is complex
<pixelherodev>
All it proves is that the generated CBE and the sourceCBE are equally malicious
<marler8997>
I'm still thinking about it myself and am unsure about it
<pixelherodev>
If the source CBE is untrustworthy, then the Zig compiler from it isn't, and the final CBE - *even if it matches the input* - still isn't trustworthy
<pixelherodev>
marler8997: I responsed quickly because, as I said, this is a known problem with aknown solution
<pixelherodev>
Look up "trusting trust"
<marler8997>
pixelherodev, we're not dependign on CBE being trustworthy
<pixelherodev>
False
<marler8997>
we're depending on the Zig source being trusworthy
<pixelherodev>
Nope
<pixelherodev>
With a trusting trust attack, the source doesn't have to be malicious
<pixelherodev>
The compiler *modifies it*
<pixelherodev>
An untrustworthy compiler means no source is trustworthy
<marler8997>
We're using CBE to verify that Zig's trustworthiness implies CBE's trustworthiness
<marler8997>
we generate an untrusted Zig compiler
<pixelherodev>
Output of CBE is an untrusted compiler
<pixelherodev>
Untrusted compiler on trusted source == untrusted output
<marler8997>
We use that untrusted Zig compiler to compile the trusted Zig code to a new CBE
<pixelherodev>
marler8997: yes, *but*
<pixelherodev>
The output is untrusted
<pixelherodev>
Which means *its output is untrusted*
<marler8997>
we compare the new CBE with the original CBE to verify they are the same, which implies that the original CBE is equivalent to the trusted Zig code
<pixelherodev>
The finalCBE matching the original CBE doesn't prove that its trustworthy
<marler8997>
I didn't say it did
<marler8997>
I said it proves that CBE is equivalent to the Zig code
<pixelherodev>
No, it doesn't!
<pixelherodev>
All it proves is that *if* the compiler is malicious, it's smart enough to corrupt its output in a matching way!
donniewest has quit [Quit: WeeChat 3.0]
fwg has joined #zig
<marler8997>
but that "smartness" is encoded in the Zig source
<marler8997>
yes, all of this depends on the trustworthiness of the C compiler
<pixelherodev>
marler8997: fundamentally, your solution misses a key fact.
<marler8997>
pixelherdev, ok but what is that fact?
<pixelherodev>
The generated Zig compiler can, when producing CBE, *deliberately produce the malicious code*
<pixelherodev>
Which will of course match the malicious input
<marler8997>
pixelherodev, the Zig source code is trusted though, so if it did produce malicious code then that's fine
<pixelherodev>
No!
<leeward>
pixelherodev: That seems like a large leap, but ok.
<pixelherodev>
It's not!
<pixelherodev>
The generated Zig compiler will be exactly as malicious as the compiler used to build it!
<CommunistWolf>
it's totally a thing
<marler8997>
my solution assumes we can verify the trustworthiness of the handwrittne Zig compiler
<pixelherodev>
It *doesn't matter!*
<leeward>
Do you trust a C++ compiler? Because I can compile Zig from scratch with one of those.
<pixelherodev>
No
<marler8997>
pixelherdev yes!
<pixelherodev>
:P
<pixelherodev>
marler8997: Even if the source is trustworthy, the output isn't
<pixelherodev>
That's *literally what the trusting trust is*
<marler8997>
The Zig compiler's maliciousness == the maliciousness of the compiler used to build it
<marler8997>
yes that is true
<marler8997>
I never said it wasn't
<pixelherodev>
And since that's malicious, its output is too
<pixelherodev>
Which means it'll match
<leeward>
Ok, so get an old version of G++ that's written in C, build it with your trusted C compiler, use it to build a modern version of LLVM, then use that to build Zig?
<marler8997>
I'll go through the sequence again with more details
<pixelherodev>
*and still be malicious*
<marler8997>
we start with a trusted C compiler (TCC for "trusted C compiler")
<earnestly>
leeward: That doesn't help
<pixelherodev>
leeward: there's nothing more to go through lol
<leeward>
That sounds like less work than reimplementing Zig from scratch in C.
<pixelherodev>
leeward: that requires the ability to trust *any* C++ compiler ;)
<marler8997>
Then we have "untrusted C code generated from Zig's CBE" (UZC1 "untrusted Zig C code 1")
<leeward>
Ah, so you don't trust even the source version of a C++ compiler.
<marler8997>
Then we have the trusted Zig source code that is handwritten, verified by humans TZC
<pixelherodev>
leeward: I don't trust anyone who would willingly write a C++ compiler lol
<pixelherodev>
marler8997: it doesn't matter
<marler8997>
Then we compiler the untrusted C backend code to create an untrusted Zig compiler
<pixelherodev>
The Zig source's trustworthiness is 100% irrelevant
<marler8997>
pixelherodev, I'm not done with the sequence
<pixelherodev>
It doesn't matter
<pixelherodev>
You've already broken it :P
proteusguy has quit [Ping timeout: 260 seconds]
<marler8997>
pixelherodev, it's broken because it's not finished yet...lol
<pixelherodev>
What you're missing is that a malicious compiler *modifies the sources*
<leeward>
How is it broken? It's an untrusted compiler.
<pixelherodev>
You *can't* verify the handwritten sources
<leeward>
As long as he means untrusted, it doesn't matter if it's malicious.
<pixelherodev>
Because you can't *see* them if the compiler is malicious
<pixelherodev>
If the compiler is malicious, it can fully ignore the source code
<leeward>
I want to hear the end, marler8997.
fwg has joined #zig
<pixelherodev>
It can see "I'm compiling Zig!" and use an in-memory malicious copy it bundles
<marler8997>
ok, so we have an untrusted Zig binary
<pixelherodev>
untrusted binary's output could legitimately be an RNG :P
<leeward>
Oh, important point: do you have an objdump that you trust, pixelherodev?
<marler8997>
Then we can take that Zig binary, and use it to re-generate a new vesrion of the C Backend from the trusted Zig source code
<pixelherodev>
marler8997: for that to work, you have to trust that that Zig binary is in fact translating the zig to C
<marler8997>
If we find that the new C backend is equivalent to the original C backend code that we generated our Zig compiler from, then that says the CBE is equivalent to the trusted Zig code that we verified
<earnestly>
Trusting trust is about how you can't trust the "trusted compiler"
<marler8997>
pixelherodev yes
<pixelherodev>
marler8997: fundamentally, that "untrusted compiler" can't even be trusted to *bea compiler*
<marler8997>
but you can trust that because the Zig source code is trusted
<pixelherodev>
It can literally just spit out its own source
<pixelherodev>
No, you can't!
<marler8997>
that's literally the only thing you can do, is verify the original source
<pixelherodev>
The source *isn't trusted* if the compiler isn't
<marler8997>
it would be the same if the compiler was written in C
<marler8997>
pixelherdev. yes
<CommunistWolf>
I'm not sure this one is going to get it
<pixelherodev>
That "compiler" can literally just run `puts(MALICIOUS_CBE);`
<marler8997>
pixelherodev, again this is a bit complicated but you need to think about this for a minute
<pixelherodev>
No, it's not!
<pixelherodev>
A malicious compiler's output is effectively meaningless
<marler8997>
I'd have to formalize it a bit more on my end, but I believe I'm using induction to prove it
<pixelherodev>
There is *no reason* to believe that the produced CBE is in any way related to the "trusted" source
<pixelherodev>
Why would you think that?
<CommunistWolf>
still, worth another go. your original source, and what you trust, is zig. so you take that and run it through something to get some CBE. later, you do it again. you can't trust either copy
<leeward>
marler8997: UZC1 is generated from what source by Zig's CBE?
<CommunistWolf>
whether the two CBEs are equivalent is irrelevant
<pixelherodev>
^
<pixelherodev>
You're proving them equivalent, sure
<marler8997>
leeward, it doesn't matter because the second time we generate it, it has to be generated form the Zig source
<pixelherodev>
That doesn't prove that *either* is equivalent *to the zig source*
<CommunistWolf>
now, if your "something" took in the trusted zig and outputted zig, you could compare its output to the trusted input
<marler8997>
and they have to be equivalent
<CommunistWolf>
that utility would be called "cat"
<pixelherodev>
marler8997: it's *not* though!
<CommunistWolf>
it doesn't help us
<pixelherodev>
That's the mistake!
<marler8997>
but practically it's generated from the Zig source
<pixelherodev>
Nope!
<pixelherodev>
The untrusted compiler *can ignore the source*
<leeward>
marler8997: Ok, so what does it purport to do? I'm missing some context.
<pixelherodev>
So there is *zero* trust to the idea that its output is equivalent to the source!
<earnestly>
The point is that you can't trust the "trust"
<CommunistWolf>
a separate compiler doesn't solve the trust issue at all, incidentally, it just solves the bootstrapping issue
<pixelherodev>
marler8997: the malicious compiler can always produce a binary that's equivalent to `echo 'printf("Hello world!");'`
<pixelherodev>
That'd result in it "generating" that printf regardless of the input
<marler8997>
pixelherodev, how does that binary compile the Zig source code into a CBE that is equivalent?
<marler8997>
but I can't really read why we're talking like this :)
<pixelherodev>
marler8997: *if* the input is trusted, you've proven that the output is as well
<pixelherodev>
if the input compiler is untrusted, you've proven that *the output is as well*
<earnestly>
(And the ddc solution doesn't stop malicious compilers; it just means the compiler's source code is what the compiler used)
<leeward>
We're talking about Ken Thompson's turing award lecture, right? That's the kind of thing everyone interested enough to be in this channel should read.
<marler8997>
pixelherdev, untrusted doesn't mean malicious
<marler8997>
it has not been proven to be malicious or non malivious
<pixelherodev>
all you're proving is that they're equally trustworthy
<pixelherodev>
Which is redundant information
<marler8997>
a compiler can be untrusted, then then verified after the fact and then become trusted
<pixelherodev>
No, it can't
<marler8997>
which is what my proposed solution attempts to do
<pixelherodev>
An untrusted compiler will produce an untrusted output
<marler8997>
pixelherdev yes
<pixelherodev>
You keep insisting that the generated CBE is meaningful
<pixelherodev>
Why?
<marler8997>
I didn't say anything to the contrary
<pixelherodev>
Why do you think that the CBE produced by the compiled CBE is useful information?
<marler8997>
I'm saying, a compiler can be untrusted at one point in time, and then trusted after verifying it sometime later
<pixelherodev>
Okay, but again
<pixelherodev>
> Why do you think that the CBE produced by the compiled CBE is useful information?
<pixelherodev>
Forgot trustworthiness
<pixelherodev>
Why is this remotely relevant?
<marler8997>
the CBE it untrusted
<marler8997>
*is untrusted
<pixelherodev>
Its output is for all intents and purposes gibberish
<marler8997>
but the Zig source is trusted yes?
<pixelherodev>
Source can't be trusted
<leeward>
Why not?
<pixelherodev>
The question is "if this was machine code would it be trustworthy"
<marler8997>
pixelherodev....uh wut
<marler8997>
source can't be trusted? so then what can be trusted?
<pixelherodev>
If the compiler is malicious then *all source is malicious*
<leeward>
No, the question is "if this source is compiled by a trusted compiler, would I trust it?"
<pixelherodev>
The question is "given a trusted compiler, can we trust this?"
<pixelherodev>
^
<pixelherodev>
Yes, exactly
<marler8997>
a compiler doesn't make source malicious, it produces malicious binaries
<leeward>
If the answer there is yes, then the source is trusted.
<pixelherodev>
marler8997: sure. and malicious CBEs.
<marler8997>
pixelherdev yes
<pixelherodev>
That's literally my point
<marler8997>
you're not following here, you keep going back to this point, which i AGREE with
<pixelherodev>
The CBE-ed output of the "trusted source" can't be trusted
<pixelherodev>
ever
<pixelherodev>
(unless the compiler is)
<marler8997>
pixelherodev, yes I agree
<pixelherodev>
(which is, in your argument, *unknown*)
<marler8997>
no it's not
<pixelherodev>
Yes it is
<CommunistWolf>
how do you prove CBE generator is safe, without reference to the CBE?
<pixelherodev>
marler8997: that was the coreof your argument!
<marler8997>
it's very simple
<CommunistWolf>
can it be done?
<pixelherodev>
We don't yet knowif we can trust the compiler
<marler8997>
but first I need pixelherodev to agree with the points, the first one being "The Zig source is trusted"
<pixelherodev>
unless you already trust a compiler, its output can't be assumed to be related in any way to the source
<marler8997>
pixelherodev I agree
<pixelherodev>
marler8997: you still haven't answered
<marler8997>
answered what?
<pixelherodev>
*Why* do you think the compiler built from CBE is generating CBE?
<pixelherodev>
You say "we can compare its CBE output"
<pixelherodev>
But if we can't trust theCBE compiler, *its output is unrelated to the trusted Zig source*
<marler8997>
thinking...
<pixelherodev>
Unless you trust the input, you *cannot trust that the output of the compiler* in any way is related to the Zig source
<pixelherodev>
For all you know, it might produce the output regardless of what sources you give it
<pixelherodev>
Which means that your trust chain still doesn't include the Zig sources at all
<pixelherodev>
Which means no part in the chain is trustworthy
<marler8997>
yeah I'm missing a piece here
<pixelherodev>
Fundamentally, your argument relies on the trustworthiness of the Zig source, corret?
<pixelherodev>
s/corret/correct/
<marler8997>
pixelherodev yes
<marler8997>
what I'm trying to do is find a way for the Zig source code to verify the CBE source code
<pixelherodev>
Well, unless the compiler is *also* trusted, there's no equivalence between the source and the generated output
<pixelherodev>
Which means that the trustworthiness of the source *cannot* be expounded onto the CBE "produced from it"
<pixelherodev>
Which means that the original cannot be trusted
<marler8997>
pixelherodev, correct, if we can find a way to verify the CBE is equivalent to the Zig source, then we can solve the problem yes?
<pixelherodev>
And thus, the output cannot be, either
<pixelherodev>
marler8997: this is an unsolved problem, so I wish you luck :P
<marler8997>
this is equivalent to trusting the binary of A C program so long as we trusted the C source and the compiler yes?
<pixelherodev>
The best we can do is prove equivalence
<marler8997>
pixelherodev, can you answer the question though?
<pixelherodev>
yeah
<pixelherodev>
Thing is, in a very real way, it's impossible to trust the *tools*
<marler8997>
ok, you could be right this is an unsolved problem, I'll think on it a bit more
<pixelherodev>
The most obvious example is evil microcode
<pixelherodev>
Imagine a microcode smart enough to detect when e.g. `sudo` is being run
fwg has quit [Read error: Connection reset by peer]
<pixelherodev>
There's *no way to detect this*
<marler8997>
pixelherodev can you answer the other question?
fwg has joined #zig
<marler8997>
> if we can find a way to verify the CBE is equivalent to the Zig source, then we can solve the problem yes?
<pixelherodev>
marler8997:which one?
<pixelherodev>
Ah
<pixelherodev>
Yes
<pixelherodev>
s/Yes//
<marler8997>
ok cool, we're on the same page now
<pixelherodev>
Meant, "ah yes that question" :P
<pixelherodev>
That'd prove equivalence
<pixelherodev>
That is doable
dingenskirchen has quit [Quit: ZNC 1.8.1 - https://znc.in]
<pixelherodev>
There's a solution involving using two compilers
dingenskirchen has joined #zig
<pixelherodev>
Which, IIRC, allows proving source/binary equivalence to a higher degree
<pixelherodev>
unless you can trust *every single piece* (assembler, linker, compiler, hardware(!!!))...
<marler8997>
sorry what?
<marler8997>
what was the answer to the question?
<pixelherodev>
I believe Thompson's conclusion was "you have to trust the people instead of trying to trust the tools"
<pixelherodev>
marler8997: you can prove that source == binary, yes
<marler8997>
hmm, I don't think that was the question
riba has quit [Ping timeout: 260 seconds]
<pixelherodev>
Or at least that the compiler isn't the *only* thing compromised
<pixelherodev>
Imagine e.g. `hexdump`, `cat`, `objdump`,... are malicious
<marler8997>
the question is, if we can prove that the Zig soruce code is equivalent to the CBE, can we solve the problem of creating a trusted Zig compiler from the Zig source?
<pixelherodev>
marler8997: yes, but the only solution that's been devised in the last few decades requires *multiple compilers*
<pixelherodev>
Which wouldn't help us here
<marler8997>
huh?
<pixelherodev>
Yes, it would; no, you can't prove it
<marler8997>
can't prove what?
<pixelherodev>
that source == CBE
<earnestly>
Unless you're willing to write another (or more) zig compilers
<pixelherodev>
Or maybe you can
<marler8997>
oh, how do you know that?
<pixelherodev>
But if you figure out a way, it'll be a relatively big dela
<pixelherodev>
deal*
<pixelherodev>
since the only method currently known got someone their doctorate IIRC :P
<marler8997>
because it would have big implications? Why is that?
<fengb>
You could probably rewrite a dozen compilers with that time
<pixelherodev>
marler8997: because you're far from the first person to try this
<pixelherodev>
marler8997: and nobody's figured out a solution
<marler8997>
you're saying the Zig situation is equivalent to others that have not been solved, if that's true then sure
<marler8997>
I'm not sure that's true though
<pixelherodev>
It's not Zig-specific
<pixelherodev>
It's a compilers problem
<fengb>
The bootstrap problem
<pixelherodev>
proving CBE==Zig is no different from proving GCC binary == GCC source
<marler8997>
This situation sounds unique because not many other tools have a CBE like this, I'm operating under the insight that this may produce a unique situation with a fairly simple solution
<pixelherodev>
and, fundamentally, the very idea of proving it requires the assumption that kernel/toolchain isn't malicious
<pixelherodev>
marler8997: CBE *is binary*
<marler8997>
if it's equivalent to this very difficult problem then it's not going to be solved simply like this
<pixelherodev>
that's what I was trying to explain :P
<pixelherodev>
There's no practical difference in proving that CBE == Zig and that ELF == Zig
<marler8997>
pixelherdev, in many ways yes
<marler8997>
in regard to trust I'll assume it is 100% equivalent here
<marler8997>
ok so you're calling this situation equivalent to others by treating CBE as a binary
<pixelherodev>
CBE and binary are both "code generated by a program"
<pixelherodev>
There is no simple solution to "prove code generated by program equals inputs to program"
<marler8997>
pixelherodev oh?
<pixelherodev>
`zig fmt` is easy to prove; you can prove that the ASTs are equal
<pixelherodev>
marler8997: let's make this a bit worse (paranoid level 9000!): what if cat,objdump,readelf,hexdump,etc are lying to you?
<marler8997>
I'm not familiar with this problem
<leeward>
There's another well established method: auditing the object code.
<pixelherodev>
Which only works if the tools for viewing it can be trusted :P
<leeward>
yes
<marler8997>
leeward yeah, but I'll assume we can't do that here to get through pixelherodev's arguments
<pixelherodev>
also, in case this wasn't abundantly clear: trust isn't remotely why I want an alternate compiler
<earnestly>
"The problem of trusting trust"
<leeward>
Though objdump is not so complicated a tool that it can't be hand-written in machine code. Particularly if you're taking on a project like auditing a compiler's object code.
<marler8997>
so where does this statement come from ""prove code generated by program equals inputs to program"
<earnestly>
leeward: blackbox silicon, dijkstra original problem with tests
<pixelherodev>
marler8997: if I give you a random binary, and its source, how would you prove them equal?
<leeward>
If code generated by a program equals its inputs, your program is cat and the proof is trivial.
<pixelherodev>
CommunistWolf: I kinda lost all respect for Yudkowski after reading his "autobiographical" post
<leeward>
earnestly: Yes, trusting hardware is getting to be a challenge these days. Used to be you could pop the cap off your 8086 and verify that the transistors are where they're supposed to be.
<CommunistWolf>
I don't really care about the individual humans
<leeward>
I used to have a poster of that somewhere.
<marler8997>
pixelherodev, the obvious way is to take a trusted compiler and regenerate the binary from source
<pixelherodev>
marler8997: ah, but what if it optimizes differently?
<pixelherodev>
even the obvious way only works if the compiler produces an identical binary
<leeward>
-O0: the most trustworthy of optimizer settings
<fengb>
leeward: you don’t have a SCT to validate the trillions of gates?
<pixelherodev>
Which for a lot of projects is unusual already
<marler8997>
sure, but it's still solvable in certain cases
<marler8997>
I'm not saying it's solvable in the general case
<CommunistWolf>
but no, the original seems to be from a paul christiano, whoever that is
<pixelherodev>
marler8997: if you assume the tools are trustworthy, sure - but keep in mind that you specified "trusted compiler" as a prerequisite
<leeward>
fengb: 8086 doesn't have trillions of gates. It has less than 30k transistors. Still, yes, you do need some fancy equipment.
<marler8997>
pixelherodev, yes I realize that :)
<marler8997>
you have to start somewhere of course
<leeward>
And I guess you have to trust that your scanning electron microscope is telling you the truth.
<CommunistWolf>
if "the solomonoff prior" is one of your "tools", this is basically the thompson paper extended to the many-worlds hypothesis
<CommunistWolf>
very painful
<pixelherodev>
marler8997: you stumbled on exactly why all source has to go through C
<earnestly>
Yeah, you may not want to take the implications of this into meatspace
<pixelherodev>
e.g. Debian has compiler builds they consider trustworthy already
<pixelherodev>
Therefore, given trusted sources, they trust the outputs
<marler8997>
pixelherodev, what?
<earnestly>
And reproducible builds to try and limit the nsa quantum problem
<pixelherodev>
if we give them a Zig compiler whose source istrustworthy, they'll trust the binary
<leeward>
Or we could go further back in time. LSI features are in the micrometers, which you could probably see with a good enough optical microscope.
<pixelherodev>
and we could potnetially use itfor bootstrapping
<pixelherodev>
marler8997: there's existing *binaries* of C compilers considered trustworthy
<marler8997>
sure, but I'm still not sure we can't solve the CBE case, I'm formalling it a bit right now to be sure
<pixelherodev>
good luck
<pixelherodev>
Like, genuinely
<marler8997>
thanks :)
ur5us has quit [Ping timeout: 260 seconds]
<pixelherodev>
I'm not expecting much; feel free to prove me wrong ;)
<marler8997>
well the solution I proposed earlier is at best incomplete
<pixelherodev>
maybe task a neural network to solve it ;P
<pixelherodev>
(please don't, that was friendly sarcasm :P)
hf69 has quit [Quit: WeeChat 3.0]
<marler8997>
Back in college I did alot of this Lisp variant called ACL2 that allowed you to write mathematical proofs in Lisp.... :)
<pixelherodev>
How to prevent (and/or cause) the robot uprising: "yo, AI: solve the halting problem!"
<marler8997>
I'll just get a nueral network to create a proof in lisp :)