ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
mnoronha has quit [Ping timeout: 252 seconds]
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 268 seconds]
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 252 seconds]
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 245 seconds]
mnoronha has joined #zig
return0e has joined #zig
return0xe has quit [Ping timeout: 244 seconds]
mnoronha has quit [Ping timeout: 268 seconds]
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 252 seconds]
darithorn has quit []
porky11 has joined #zig
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
porky11 has quit [Ping timeout: 252 seconds]
davr0s has joined #zig
davr0s has quit [Client Quit]
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 244 seconds]
davr0s has joined #zig
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 268 seconds]
porky11 has joined #zig
porky11 has quit [Ping timeout: 240 seconds]
porky11 has joined #zig
noonien has joined #zig
pancake has joined #zig
<pancake>
ive created a hello world using --release-small
<pancake>
but the generated bin is full of functions that are never called or even referenced
<andrewrk>
if you use !void as the return type, the code that calls main will print an error message to stderr, which was the cause of some of the code
<andrewrk>
this modified version just does exit(0) or exit(1) which generates smaller code
<pancake>
well my hello world is doing a getenv and so on, so its not just a hello world
<andrewrk>
I see
<andrewrk>
anyway I'm aware of all the stuff that makes hello world larger than theoretical. some of it is llvm issues unfortunately
<pancake>
this is 3KB smaller, but still contains those udiv things
<pancake>
thanks
<andrewrk>
I'll look into #54 briefly today. it may be a quick fix
<pancake>
awesome :)
<pancake>
btw it is possible to use ASAN with Zig?
<andrewrk>
not yet
<andrewrk>
you can use valgrind though
<pancake>
not in mac, but yeah
<andrewrk>
the plan is to have the equivalent of ASAN always on in debug builds
<pancake>
main problem i see is the memory usage
<andrewrk>
yeah it's 2x right?
<pancake>
no
<pancake>
much worst
<pancake>
all allocations are never freed
<pancake>
to keep track of doublefrees and usafs
<pancake>
uafs
<pancake>
so its always growing
<andrewrk>
ah I see that is indeed a problem
<andrewrk>
ok we'll need a more sophisticated plan for ASAN support
darithorn has joined #zig
porky11 has quit [Ping timeout: 260 seconds]
porky11 has joined #zig
DutchGh0st has joined #zig
porky11 has quit [Read error: No route to host]
<DutchGh0st>
andrewrk, you there?
<andrewrk>
yep
<DutchGh0st>
I dont know if I missed some of the documentation on async functions, but compling this: https://pastebin.com/7Wkjj0ha , and running it, errors with an integer overflow?
<andrewrk>
can't open my web browser until this llvm debug build finishes linking
<DutchGh0st>
ohh hahaha, well the basic idea is that I have a simple async function, it has a loop running 10 times, each time suspending, and then it returns a u32,
<DutchGh0st>
I also have a `map` function, which is supposed to take a promise, await that promise, and then call a function with the result of the promise, just like the normal .map() would do
<DutchGh0st>
btw, I like the videos you put up on youtube! they're informative :)
<andrewrk>
glad to hear you're getting something out of them
<andrewrk>
looks like your code isn't following the rules about how coroutines work
<andrewrk>
DutchGh0st, every async must be matched with an await, or a cancel. every suspend must be matched with a resume, or a cancel.
<andrewrk>
your call to slow_action () is unconditionally leaking, because it never calls cancel
<DutchGh0st>
o.O
<andrewrk>
`resume mapped` is undefined behavior, you can't `resume` a handle that has not suspended
<DutchGh0st>
so where should I cancel it then?
<DutchGh0st>
and does that mean the first line of every async fn must be 'suspend' if you want to do map, filter, select, and join etc?
<andrewrk>
I think you're best waiting for the coroutine rewrite that I'm working on
<andrewrk>
the generator use case isn't really solved with status quo
<DutchGh0st>
A way to check if a generator is done is to pass like a reference to a bool, and set that to true when the async fn is about to return?
<wilsonk>
any ETA on the coro re-write andrewrk? Or is there still some unsolved/difficult stuff that might take a significant amount of time?
<andrewrk>
wilsonk, it's in progress right now. I had to solve async function pointers, which turned out to be related to normal function pointers and stack growth
<andrewrk>
I believe I have something workable, so I'm pushing forward on the implementation
<wilsonk>
right, I saw the function pointer stuff being talked about. Glad to hear you seem to have a solution
<andrewrk>
bottom line, is that in the rewrite, `async` can't fail\
<andrewrk>
and coroutines are used to solve recursion
<andrewrk>
DutchGh0st, I didn't test this, but here's how you would do a generator with status quo: https://clbin.com/0U9B4
porky11 has joined #zig
<DutchGh0st>
sooo in fn main(), how would you get out the returned value?
<DutchGh0st>
is there a '.output' field on a promise?
<andrewrk>
nope, you have to await it which requires being in an async function
<andrewrk>
I think it would make sense if you could get the returned value if you could assert that the async function returned
<andrewrk>
but that is currently not possible
<DutchGh0st>
mhh, yeah, you could indicate it with an enum,
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Elronnd has quit [Quit: leaving]
davr0s has joined #zig
tom1998 has joined #zig
unique_id has joined #zig
<tom1998>
heyo
<tom1998>
I'm trying to put an enum in a packed struct, but it's telling me I can't put it in, is this normal?
<tom1998>
This is the code, i'm trying to create a packet struct to write some networking data to a socket, then cast it back out the other end: https://pastebin.com/cDA1TNK7
<tom1998>
This is the error I'm getting:
<tom1998>
/home/tom/dev/Practice/zig/zigmog/src/packet/packet.zig:16:9: error: packed structs cannot contain fields of type 'PacketType'
<tom1998>
type: PacketType,
<andrewrk>
hi tom1998
<andrewrk>
you'll need to make the enum packed as well
<tom1998>
Yeah, with 'packed enum' right?
<tom1998>
that's what I did
<andrewrk>
and I think that means you have to supply an explicit integer type to the enum
<tom1998>
ahhhhh ok, hang on
karlguy has joined #zig
<andrewrk>
looks like the error message could be improved to include that information
<tom1998>
So if i do enum(u8), and i go over 256 items in the enum, I assume that's gonna shout at me?
<andrewrk>
right
<tom1998>
It's just that it's not automatic when the enum is packed, i assume for clarity
<tom1998>
ok, cool!
<andrewrk>
or if you assign a value out of range to one of the tags
<tom1998>
brilliant, it compiles!
<tom1998>
Thanks<3
<andrewrk>
no problem
<unique_id>
Andrew, if you remember I had a need for "extern enum" for controling the layout for cache purposes, but of course "extern enum" requires all structs within to also be extern enum. I have another use case now, a struct contains 9 fields of the same type, and also other fields. Some algos would do better to treat those 9 fields as an array, requiring something like "extern enum" to make sure they're all together. Though I don't know
<unique_id>
what kind of aliasing or other UB stuff I'd be walking into.
<unique_id>
The alternative might be to use a union but that may require syntax changes and such all over the place
<euantor>
It's listed as `f8429d6c3288041cdc7cdd5df51b7c44cb94403ac3f0641ebfba9d34ef73b082` but I'm getting `209c6fb745d42474c0a73d6f291c7ae3a38b6a1b6b641eea285a7f840cc1a890`
<euantor>
Either the page is wrong or my internet connection is screwed up :P
<andrewrk>
euantor, I'm getting the same checksum as you
<andrewrk>
will fix
<euantor>
Cheers. I'm putting some docker containers together and caught it in my build script
<andrewrk>
0.2.0 doesn't have runtime libc detection
<andrewrk>
it's nearly useless
<euantor>
Fair enough, I'm just trying to automate the creation of the containers as far as I can so I always have one up to date
<euantor>
And for that matter it would be nice to have a file on the web site that lists version numbers with checksums in a way that's script readable
<andrewrk>
fixed
<euantor>
thanks
<andrewrk>
euantor, if your script trusts the https connection to download the tarball and read the checksum from the site, why not just calculate the checksum?
<andrewrk>
the checksum is for cross-checking with mirrors
<andrewrk>
it seems to me that static builds are strictly better than docker images
<euantor>
I work on windows and target linux fairly often. It's easy for me to do `docker run euantorano/zig build-exe`
<andrewrk>
easier than `zig.exe build-exe` ?
<andrewrk>
zig.exe build-exe --target-os linux --target-arch x86_64
<euantor>
Well, TIL
<andrewrk>
wow you went through a lot of work to accomplish something that is a basic feature :)
<euantor>
I never knew cross compilation was that easy. I'm used to having to muck about with stuff to get that kind of thing working
<andrewrk>
yeah. that's one of the features of zig!
<tom1998>
heyo, back again
<euantor>
I have some other plans with Docker anyway, such as a playground type site. So my work shouldn't end up being in vain
<andrewrk>
euantor, still - inside the docker image you can just wget the static binary and run it. no need for a zig docker image
<andrewrk>
a zig docker image is just an unnecessary waste of bytes
<euantor>
I'll give that a go some time, thanks
<tom1998>
I'm switching on an enum and getting a type from that, then casting a []u8 to a pointer of that type. This works when inline in the main function, but doesn't when in another function - here's an example of the two https://pastebin.com/iFCrhBui
<tom1998>
I'm assuming this breaks some comptime rule, but I was surprised to see the inline version work
unique_id has left #zig ["Konversation terminated!"]
<andrewrk>
tom1998, give me a minute
<andrewrk>
tom1998, your first example, you're trying to return a type (which you can only do at compile time) from a function which accepts a runtime enum value
<tom1998>
yep, i figured that would be it, how come inlining this is fine though
<tom1998>
In the inline example , you put in a runtime value, and get out a type
<tom1998>
Are there any plans to implement macros? This would solve a lot of these issues, 'cause I could just inline the switch, this makes packet handling code pretty brutal with a huge switch statement
<andrewrk>
tom1998, your second example crashes the compiler
<tom1998>
._.
<andrewrk>
I believe you are using a build with assertions off
<tom1998>
Oh hang on, it crashes mine too, but was working earlier - i must have broken it when formatting into the same file with the comments, 2 secs
<tom1998>
oh or maybe i didn't?
<tom1998>
Tbf that does make sense, i was pretty surprised - when you comment out he var x : T = undefined line it works fine
<tom1998>
Ok, regardless, you can use the type in an @intToPtr() call, which is super useful for packet handlinf
<tom1998>
as in, without it segfaulting
<tom1998>
Will this just become a compile error in future?
<andrewrk>
what code?
<andrewrk>
the assertion failure?
<tom1998>
the act of switching on an enum to produce a type
<andrewrk>
yeah, the compile error is switching on a runtime value and then having the expression return a value with a type that requires comptime
<andrewrk>
you can fix it with putting `comptime` before `var my_enum`
<tom1998>
ok, but I can use that type in @intToPtr
<tom1998>
without a compile error, and it works
<tom1998>
it seems like it works so long as you don't need to know the size of the type at runtime, which makes sense
<andrewrk>
sorry I'm looking at a few things at once, what code are you talking about now?
<tom1998>
hang on, it's hard to write an example, let me just paste you the actual code that prompted this
<tom1998>
So, i'm receiving a network packet where the first few bytes are the enum which tells me the type of the packet, and the remaining bytes are the bytes of the struct that I want to cast a pointer to
<tom1998>
packet_data_ptr is the *u8 containing the data, packet_type is the enum at the start of the packet, and ThisPacketType is the type we get from switching on the enum value
<tom1998>
ThisPacketType then gets passed into @intToPtr(), and I get a working pointer to the right type of packet that I can use & do whatever with
<andrewrk>
there's probably a much safer way to do this without using @intToPtr and @ptrToInt
<tom1998>
The compiler complains about alignment with @ptrCast
<andrewrk>
that's an important complaint
<andrewrk>
if you ignore it, then you move the complaint to runtime instead of compile time
<tom1998>
Yeah, but the packet is allocated with malloc() which is aligned properly
<andrewrk>
if you use std.heap.c_allocator it usess malloc() and knows about alignments
<tom1998>
i receive the *u8 from a C library
<andrewrk>
you can use @alignCast
<tom1998>
What does that do, the docs weren't too clear
<andrewrk>
you could also fix the extern declaration for the C library to include the alignment in the pointers
<tom1998>
hang on, is the alignment encoded in the type?
<andrewrk>
that's fair, it would be good to add an example to these docs
<tom1998>
I thought it was just inferred, i.e. a *u8 will always have no alignment
<andrewrk>
`*align(4) u8` is a pointer to a single u8, 4 byte aligned
<andrewrk>
if the alignment matches the abi alignment you can leave it off
<tom1998>
ohhhhhhh
<tom1998>
so i can @alignCast(4, my_ptr) and I'll get an *align(4) u8?
<andrewrk>
and you can always cast down from higher alignment to lower
<andrewrk>
that's right
<tom1998>
I see, and the alignment safety check is omitted when building with releasefast?
<andrewrk>
right
<andrewrk>
even better; instead of checking, it simply informs the optimizer that situation is impossible and lets the optimizer use that information if it can
<tom1998>
ohhhhh i understand what you were saying about the extern declaration in the C library now
<tom1998>
so i can just add it to the declaration of the c library, then it'll force it past the typesystem?
<tom1998>
Back to switchin on a runtime value to produce a type - is this an error that isn't getting thrown that happens to work for some reason and will be removed in a future version?
<andrewrk>
unfortunately .h files do not include this metadata
<andrewrk>
it's only working because your switch only has 1 prong
<andrewrk>
the @panic doesn't count
<andrewrk>
if you add another one it will either do the correct thing which is a compile error, or crash the compiler (which is a compiler bug)
<tom1998>
hang on, let me test that
<andrewrk>
types are only available at compile time
porky11 has quit [Ping timeout: 240 seconds]
<andrewrk>
you can't use a condition which is only known at runtime to determine what type to use
<tom1998>
Thaaaaaaaaaaaaat makes sense, yeah i get a segfault adding another branch
<tom1998>
Okay, that's good to know, ta!
<tom1998>
Regarding macros;) Is that ever gonna be a feature or are you keeping it simple?
<andrewrk>
macros will not be in the language
<tom1998>
A'ight, that's cool, ta for the info
<andrewrk>
partial compilation (inlining loops and comptime variables) should be sufficient. consider that this works for zig to implement formatted printing in the standard library
<andrewrk>
meanwhile rust has macros, but the formatted printing macro is still hard coded into the compiler - they didn't do it in userland for some reason
<andrewrk>
idk the details, but I'd call this a point in favor of zig's alternative to macros
<tom1998>
Yeah that is pretty dumb, macros can simplify a lot of code though, like this switching on types stuff
<tom1998>
The comptime stuff is cool, but it'd be REALLY powerful if you could write something like 'foreach item in this enum, create this code'
<andrewrk>
I would argue that the code you're about to be forced to write instead of using macros, is more readable to a high degree
unique_id has joined #zig
<andrewrk>
nobody wants to read anybody else's macro code
<tom1998>
Depends on the scale, 1k line files which are just switch statements with extra pointer manipulation code sucks too
<unique_id>
Why does -Drelease-safe take much longer than -Drelease-fast? I would have thought it would be the reverse.
<andrewrk>
unique_id, release-fast omits safety checks, so the optimizer has less to do
<andrewrk>
with release-safe, the optimizer is trying to do stuff but has to work around all the safety checks
<andrewrk>
the debug build is the only one we're trying to make build fast
<andrewrk>
and most of the techniques to do that will be in stage2 and not stage1
Ichorio has quit [Ping timeout: 252 seconds]
<andrewrk>
on the other hand, if release modes build time gets out of control, we can introduce some kind of sliding scale where you can choose to dial down the optimization in exchange for less compilation requirements (less memory, less time)
<andrewrk>
there's one more trick up our sleeves too; there is some low hanging fruit where zig can omit safety checks in a lot of places
<andrewrk>
this will speed up release-safe build times as well as debug build times
<andrewrk>
e.g. for loops, no need to check the bounds on every iteration
<unique_id>
Ok I see. I'm doing some data processing and I see very little runtime difference between release-fast and release-safe, so that's pretty cool. 70 million data points processed in a few seconds.
<andrewrk>
llvm probably figured out how to remove a lot of the safety checks, and that's what took so long
<andrewrk>
(or maybe your hot path didn't trigger any safety checks)
<unique_id>
sure
karlguy has quit [Ping timeout: 246 seconds]
unique_id has left #zig ["Konversation terminated!"]
darithorn has quit []
tom1998 has quit [Ping timeout: 246 seconds]
noonien has quit [Quit: Connection closed for inactivity]