<cloudhop>
Is there a "hello world" example that uses a build.zig file? I can compile hello world using 'zig build-exe blah.zig', but I cannot for the life of me get it to output an EXE when i use build.zig - i can find the EXE inside /zig-cache/, but it never copies it to the current directory (or the source directory, or anywhere I can find)
<mikdusan>
cloudhop: have you tried adding an "install" artifact?
<cloudhop>
which has the only build system example i could find
<cloudhop>
if the build system has no docs, well, that kind of explains why it was so hard to figure out how to use it
<andrewrk>
I'm planning on making `install` the default step of zig build, with a default install prefix of something like build-<mode>
<mikdusan>
cloudhop: also this would tell you where install was defaulting to: `zig build install --verbose` (probably /usr/local/bin)
<andrewrk>
cloudhop, zig build has been slowly evolving toward what it will eventually be, it's in a bit of a transitionary state
<daurnimator>
misc idea I had last night: what if aligned pointers were packed? -> `*align(4096) packed foo` -> only needs to take up `usize-12` bits
<cloudhop>
I was only invoking it with `zig build`, not `zig build install`, since I just wanted it to build it to the current directory, not install it.
<andrewrk>
daurnimator, that's an interesting idea
<mikdusan>
riddle me this batman: how come cmake is so noisy about `install` and why can't we tell it to only be noisy about work actually done
<andrewrk>
cloudhop, currently `zig build` runs the default step, which you have full control over
<andrewrk>
so you could tell it to install to the current directory or anything else
<daurnimator>
andrewrk: I guess I should make an issue for it?
<cloudhop>
Ok, so the only real issue is the prefix directory then
<andrewrk>
daurnimator, sure if you can come up with a reasonable use case
<daurnimator>
andrewrk: I was thinking about how the linux kernel (and windows!) use the lower bits for various flags.
<scientes>
daurnimator, can you explain that idea another way?
<andrewrk>
the proposal should probably mention the option of just doing that behavior if it's in a packed struct
<scientes>
daurnimator, oh i use the low bit in rb.zig
<andrewrk>
oh but if `packed` were a pointer attribute, zig would know to mask before doing loads/stores
<andrewrk>
that's useful. theoretically could even be communicated to debug info
<scientes>
oh yeah, I have been thinking about this for years
<scientes>
but usually you get a very negative reaction
<scientes>
however this isn't "extern packed" which has to be compatible
<andrewrk>
I'm amenable to ideas that make existing use cases less error prone
<daurnimator>
(assuming the type 'foo' already has e.g. a 8-byte alignment)
<scientes>
yeah I think it should be done
<scientes>
and it shouldn't require you to order them just right
<daurnimator>
it should take on normal packed struct semantics
<scientes>
if you want to control how they are packed you have to use sub-structs
<scientes>
daurnimator, yes but this isn't "extern packed" it is not c compatible
<andrewrk>
yeah if a "packed pointer" was in a packed struct, then it would take up a number of bits equal to the number of overaligned bits relative to the element type
<daurnimator>
scientes: from zig packed struct docs: > Fields remain in the order declared.
<scientes>
daurnimator, that is "extern packed"
<andrewrk>
wait, no, it's unrelated to the element type. it's just the alignment of the pointer
<scientes>
daurnimator, i know, i'm just saying it should be called "extern packed" because it is a c compatible interface
<andrewrk>
packed structs are allowed in extern stuff
<scientes>
I think we should add "extern packed", and then in a only "packed" struct pointers would be bit-stuffed in the low bits automatically
<scientes>
no need for a pointer attribute
<andrewrk>
pointer attribute would make loads/stores work correctly
<scientes>
yeah but the struct attribute would add that, only when the allocator used it
<scientes>
because you don't need to mask if nothing is stored there
<scientes>
and the allocator can actually guess which pointers are used the least
<scientes>
it is a more flexible interface
<andrewrk>
the way that pointers to packed struct fields work is that the pointer type actually encodes everything needed to do loads/stores
<andrewrk>
there's a syntax for bit offsets in pointer attributes
<scientes>
yeah i'm saying that this belongs as a struct attribute only that implicitely sets a hidden pointer attribute
<scientes>
thats a more flexible interface
<daurnimator>
created #2652 to track
<scientes>
and provides the same behavior
<andrewrk>
this concept of hidden type attributes doesn't exist yet, but I have thought of a few other use cases for it. not sure if any of them are good ideas yet
<scientes>
we already have it for argument attributes
<scientes>
its just an implementation detail
<andrewrk>
how so?
<scientes>
sret, byval
<andrewrk>
neither of those are available to zig during analysis
<andrewrk>
that's not what I'm talking about
<scientes>
@setRuntimeSafety()
<daurnimator>
andrewrk: hrm. do we even need the pointer attribute? couldn't it just be the default?
<scientes>
daurnimator, that is what i am saying
marijnfs has quit [Ping timeout: 258 seconds]
<scientes>
daurnimator, except performance-wise you really should only apply it to packed structs, except these are differn't from c-compatible packed structs
<scientes>
but that is still problematic
<daurnimator>
similar to how e.g. a i7 might be stored in a 8bit register or passed as a 32bit parameter. and takes up 8 bits in a non-packed struct -> `*align(4096) foo` might be passed in a 64bit register, and takes up usize bits in a struct.
marijnfs has joined #zig
<scientes>
there is no need to make it a explicit pointer attribute, but there needs to some way to get the heuristic right
<scientes>
because it does impact performance
porky11 has quit [Ping timeout: 248 seconds]
ltriant has quit [Ping timeout: 248 seconds]
<emekankurumeh[m]>
are c packed structs laid out in memory the way they are declared?
<scientes>
yes
<scientes>
with no space between
<scientes>
(except the low bits of pointers haha)
<scientes>
not sure how it handles types < 8 bits
<scientes>
but it is the same on all architectures
<emekankurumeh[m]>
wouldn't it make more sense to move those around so they pack better?
<scientes>
emekankurumeh[m], packed in C is for serializing
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 244 seconds]
<emekankurumeh[m]>
no in c, for the compiler to be allowed to rearrange fields
<tgschultz>
So my new BMP library works at comptime now because it doesn't require an allocator. However, it is orders of magnitude slower than loading at runtime, so it's still better to preprocess and @embedFile. Still, much better code than a year ago, in my estimation.
mbarkhau has quit [Ping timeout: 246 seconds]
<daurnimator>
thinking about serialisation formats with schemas like protobuf and ASN.1.... I think they're a place where @reify is really required
<daurnimator>
tgschultz: also I was thinking about your lack-of-@reify-workaround.... I think it could be made to work at runtime without too much work; do you agree?
<scientes>
tgschultz, what is "BMP"?
<scientes>
daurnimator, lets do something easier before ASN.1, and the protobuf guy (who I met, and know he lived) created CapNCrunch
<scientes>
CapNProto
<daurnimator>
scientes: capnproto can be very complex; and is not widely used; i don't think it's a great starting point.
<daurnimator>
scientes: if you're looking for something easy to prototype with, doing something with just json-schema may work for you.
<scientes>
i have enough projects right now
<daurnimator>
scientes: but protobufs (because gRPC) and ASN.1 (because X509 and TLS and also LDAP) are going to be the huge winners.
<scientes>
we could do wireguard before that however
<scientes>
but yeah TLS eventually, but it is difficult
<daurnimator>
dbus is also one that will eventually be useful. though it needs an XML library which I wouldn't even suggest tackling
<scientes>
or actually trying to write a generic IPC for the Linux kernel?
<scientes>
that they will accept
<daurnimator>
... no.
<daurnimator>
WebIDL is one that might catch a few new contributors
<scientes>
I am interested in doing new things
<scientes>
I have plenty of those projects
<scientes>
you can always just call C
curtisf has joined #zig
<daurnimator>
scientes: ... did you even understand my original comment?
<scientes>
the @reify one?
<daurnimator>
yes; and how it's relevant to implementing schema-based standards?
<scientes>
I am excited to see what people do with it, but I am not there yet
<scientes>
I kinda have to see it to understand it
<scientes>
so no, i did not understand your comment
<daurnimator>
the important thing about doing it in zig is that you can (at comptime) do `const mytype = protobuf.parse(@embedFile("myfile.proto")); const a_foo = mytype.foo{.x = 42};`
<curtisf>
Oh, I didn't know about `@embedFile`, I was wondering how you'd bring in a proto file
<scientes>
that is beautiful
<curtisf>
I wonder if it would be better than just using a compiler though
<daurnimator>
and my point was that constructing `mytype` there really requires `@reify`.
<scientes>
when I used @embedFile I found it quite slow, but it is still useful
<scientes>
daurnimator, I just haven't used that use case, but I think it is a good idea
<scientes>
def. better than STL
<scientes>
oh yeah I see what you are saying about CapNProto
<daurnimator>
curtisf: also welcome :) I had a question/comment to something you asked the other day but you had left the room by the time I replied
<curtisf>
what's that?
<daurnimator>
I can't remember now :P
* daurnimator
checks logs
<daurnimator>
curtisf: oh. it was about the parser/generator written in zig
<daurnimator>
curtisf: one of the projects I keep meaning to get to is writing a PEG engine that works at comptime
<daurnimator>
curtisf: would be perfect for the sort of thing we were just talking about (e.g. parsing .proto files). as well as lots of other places.
<curtisf>
That's more or less what I was working on (although I guess it's more "recursive descent" since I don't currently need the lookahead features of peg)
<curtisf>
I finished writing a code generator for C in it and hated it, so I wanted to try redoing it in Zig, and it's much, much nicer. But also I don't know Zig yet so lots of things are tricky for me
<scientes>
curtisf, i'd love to see it
<daurnimator>
curtisf: my plan was to do it very similar to LPEG (mostly because that's what I know well... and has been effective in other projects of mine)
<scientes>
I find code-generators difficult because you have to think about too many things at once
<curtisf>
Here's my work in Zig so far, it needs a lot of cleaning up still (and the implementation isn't done yet): https://hastebin.com/ohuwupepax.zig
<daurnimator>
curtisf: see std.ArrayList to replace your List
<curtisf>
oops, that was just me testing out comptime, I am using ArrayList, lol
<scientes>
can i create IrInstruction in ir_analyze?
<scientes>
I guess I can just call into another ir_analyze funciton
<andrewrk>
I have made it to the part of copy-elision branch where I'm fixing regressions in the behavioral tests
<curtisf>
daurnimator: Those aren't really regular expressions though, are they? e.g., /((aaa)|(aaaaa))+/ will match `aaaaa` as a regexp but not as a peg
<scientes>
can I create IrInstructions during iranalyze pass?
<scientes>
and if so do i use old_irb, or new_irb?
<daurnimator>
curtisf: it doesn't support the | operator.... and IIRC, neither does the regular expression standard (they're part of PCRE, which is an extension to plain regexps)
<scientes>
daurnimator, make sure you support greed/non-greedy, and do not implement back-tracking
<curtisf>
well it's called `+` in peg, right? `|` is one of the three fundamental regex operations
<andrewrk>
scientes, yes during IrAnalyze pass you look at old_irb instructions and produce new_irb instructions
<andrewrk>
if you look at any of the ir_analyze_instruction_foo functions that is what they are doing
<daurnimator>
curtisf: PEG syntax/nonclementure is all over the place: every paper/implementation uses different symbols. I'm not sure who's "+" you're talking about :P
<curtisf>
wait, what? Posix regex doesn't include `|`? That's central to what regular expressions are, though
<daurnimator>
curtisf: only extended posix regexes do
<curtisf>
When I say "regular expression" I mean the computer science concept
<curtisf>
which is PCRE sans backrefs and lookaheads
<daurnimator>
(ever wondered why you need to use 'egrep' vs 'grep'?)
<andrewrk>
scientes, zig has exactly 2 zig ir passes - the first one generates IrInstructions from AST nodes, the second one generates IrInstructions from the old IrInstructions
<andrewrk>
nearly everything is in the second pass
<andrewrk>
the first one is pretty much only to flatten loops and such into basic blocks
<curtisf>
is there any chance Zig would add gotos?
<andrewrk>
they were hygienic but they became redundant
<scientes>
can i generate IrInstructions in the second pass?
<scientes>
just build it then call analye on it
<scientes>
its just that i need to resolve the type to decide what to do
<scientes>
and you can't resolve types in the first pass
<curtisf>
Is it useful for me to file an issue for an error message I find confusing?
<curtisf>
(the missing return error I mentioned above)
<scientes>
curtisf, yes, especially if you look into what it could be or even produce a patch
<curtisf>
I think this would be a straightforward thing to patch to learn how Zig is put together, but not sure how quickly I can set up zig development
<scientes>
curtisf, what os are you on?
<curtisf>
Windows 10
<scientes>
oh, i have no idea
<scientes>
although I know zig can be build with msvc
<andrewrk>
curtisf, should be pretty straightforward. everything is documented in the readme and/or the wiki
<curtisf>
Yea... I tried building Zig from source using mingw and using WSL, but I gave up. Something was broken with my setup
<andrewrk>
that's not the documented way to build zig from source on windows
<scientes>
zig supports windows
<scientes>
not just posix compatibility layers
<curtisf>
I know, I've just never learned how to use VS. I guess now might be the time
<scientes>
yeah I avoided it too...I tried just using clang and meson to do things
curtisf has quit [Quit: Page closed]
curtisf has joined #zig
<terinjokes>
is there any work on providing HTML docs for std?
<scientes>
there are currently no docs, because that is waiting on a doc generator to be written terinjokes
<daurnimator>
so issue is that you would need to compile everything? and that what is compiled is different per architecture? makes sense.
<andrewrk>
yeah and build options
<andrewrk>
and generic types and functions
<daurnimator>
k. should I close 2573? or is it just super-deprioritized now?
<andrewrk>
in summary, comptime is integral to zig and you need full "comptime code coverage" to get proper docs
<hryx>
I think there are some pretty big design decisions to be made that are affected by that fact
<hryx>
yeah ^
<andrewrk>
I'll comment on it and close it. I'll at least put some explanation there and point to the issue I haven't yet typed up
<hryx>
(regarding the docgen I mean)
<andrewrk>
we also need "comptime code coverage" to get proper IDE refactoring features
<daurnimator>
andrewrk: I can still see it being useful long term for e.g. REPL usage. or when debugging. But now you've explained I see it's not useful for short term doc generation
<andrewrk>
this is a fundamental problem of conditional compilation, which is a necessary component of portable compile-to-machine-code languages. so this is a fundamental challenge; not something zig has caused to happen with its choices
<andrewrk>
and so therefore if we pull off the multi-builds solution it will actually be a pretty meaningful contribution to computer science
<daurnimator>
It actually brings to the surface an interesting question.... what if e.g. a function behaves entirely differently based on some build option? Shouldn't the docs be different depending on the build option?
<andrewrk>
right. one of the main jobs of documentation generation is to expose nondeterminism
<terinjokes>
i see this with godocs
<andrewrk>
I see browsing generated docs as being extremely useful, even if you have 0 doc comments
marmotini has joined #zig
<andrewrk>
what I mean is that the docgen will have to reconcile the set of builds together and detect when the different builds produce different behavior
<daurnimator>
if (build_option) { /// This function frobbles } else { /// This function encabulates } ...... hrm.
<cloudhop>
I wonder if some of this could be dealt with by creating a "megafunction" that touches all possible code paths
<andrewrk>
if the api of the function is the same, it won't matter. but things such as types of args that depend on build options, error sets, etc are interesting to the docgen
<daurnimator>
cloudhop: that's what I originally proposed. but problem pointed out was that it still doesn't cover e.g. structs that different based on target architecture
<andrewrk>
I think it's going to be reasonable to code this feature if stage2 is designed with it from the ground up
<daurnimator>
cloudhop: which then brought up can we do a union of compiling for every arch/OS/etc? "multi-target build"
<cloudhop>
I mean, I suppose I meant the actual comptime function generating different structs as being included as a different branch
<cloudhop>
e.g. can you deal with this if and only if you know all possible build options?
<daurnimator>
cloudhop: which then brought up "but what about build options?" (see option #226)
<daurnimator>
s/see option/see issue/
<cloudhop>
Is there a reason these compile time options can't be laid out in a build.zig file? Or is this considered unacceptable
<andrewrk>
yeah build.zig is a good place for build options
<andrewrk>
I think it's a bit clunky declaring arbitrary options at the moment, at some point here the package manager implementation is going to have a way for packages to declare the options they support and there will be a system for choosing such options when depending on a package
<andrewrk>
anyway one thing at a time, I'm still working on copy elision branch
<daurnimator>
^ yep. I've been trying to hold off on asking andrewrk too many questions :P
<scientes>
same haha
<terinjokes>
i'd just read the std source for now :)
<andrewrk>
I got a lot done today on it. if I have another productive day tomorrow I should have a sizable chunk of the test suite passing
<scientes>
me too actually
<andrewrk>
good night
cloudhop has quit [Quit: Page closed]
lunamn has joined #zig
jjido has joined #zig
wilsonk|2 has quit [Ping timeout: 248 seconds]
hio has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
neceve has joined #zig
mixi has quit [Remote host closed the connection]
mixi has joined #zig
marijnfs_ has joined #zig
<daurnimator>
Another thing I've been meaning to do: port gimli to zig.
<daurnimator>
gimli is a crypto primitive: can be used as a PRNG, cipher, and more.
<daurnimator>
If anyone wants to beat me to it.... :)
SamTebbs33 has joined #zig
mikdusan has quit [Ping timeout: 258 seconds]
avoidr has quit [Quit: leaving]
occivink has joined #zig
cameris has joined #zig
<tgschultz>
daurnimator, I'm fairly confident the only way to make PseudoStruct work at runtime is to use a hashtable and some kind of union of everything, which feels quite COM Dispatch.
<tgschultz>
scientes: BMP, the image format. Rewriting my PNG lib is next on the list.
<daurnimator>
tgschultz: it won't be performant, but I guess it's an `inline for` that needs to be swapped for a `for` to make it runtime?
<tgschultz>
I don't think it is that straight-forward, since you can't do type things at runtime.
<tgschultz>
I'm really not sure something as heavy handed as @reify is necessary for things like protobuff. PseudoStructs would work, but if we wanted better integration with normal struct semantics there's the old @addField() idea and that would probably be sufficient.
<daurnimator>
tgschultz: yeah... though if you have a constraint list of primitive types (i8, u8, i16, i32, u64, i64), and have byte-offsets.... you should be good?
kristoff_it has quit [Remote host closed the connection]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 246 seconds]
heitzmann has quit [Quit: WeeChat 2.5]
heitzmann has joined #zig
marijnfs has quit [Ping timeout: 252 seconds]
marijnfs has joined #zig
wilsonk has joined #zig
<marijnfs>
why can't i directly deref a [*]T ? It seems nices to me than using the index operator
<donpdonp>
do you mean ptr.*
<marijnfs>
donpdonp: yes
<marijnfs>
say you have a slice and take its pointer slice.ptr
<andrewrk>
marijnfs, you can, use [0]
<marijnfs>
that thing can only use [0]
<marijnfs>
andrewrk: indeed
<marijnfs>
seems like .* is nicer to me
<marijnfs>
it's a syntax thing i guess
<andrewrk>
it's about preventing mistakes
<andrewrk>
if you know which one you have, you use .* or [0] and everything is easy. if you don't know which one you have, it would be dangerous to use the wrong one since it's a pretty strong hint that a mistake is being made
* donpdonp
agrees
<andrewrk>
marijnfs, also, sorry didn't see that you mentioned the index operator in the question originally
jjido has joined #zig
<marijnfs>
andrewrk: yeah thats a good point
<marijnfs>
llvm figures out it doesnt have to add 0 i'm sure
<marijnfs>
is there a binary search?
<scientes>
oh yeah i ran into that and it was no big deal
<scientes>
marijnfs, i did a binary search that works on arbitrary length serialized strings