avoidr has quit [Remote host closed the connection]
marijnfs has joined #zig
marijnfs__ has quit [Ping timeout: 246 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
_whitelogger has joined #zig
kristoff_it has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
<fengb>
Is there a quick way to convert numbers to []u8 with fixed endianness?
kristoff_it has quit [Ping timeout: 268 seconds]
<andrewrk>
fengb, std.mem.readIntSlice
<andrewrk>
or rather std.mem.writeIntSlice
<fengb>
Awesome, thanks!
<diltsman>
On Windows, does Zig compile for 64-bit?
<andrewrk>
not sure what you're asking
<diltsman>
When I build with VC++ I have to choose 32-bit or 64-bit target.
<diltsman>
They build against different sets of Windows libraries.
<andrewrk>
if you don't specify a target, zig chooses the native target. you can use the -target parameter to choose a different target, not only including 32-bit windows but including other operating systems and architectures. the windows 32-bit target is a Tier 2 supported target
NI33_ has quit [Read error: Connection reset by peer]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 246 seconds]
<strmpnk>
I've been thinking about the async/await design for a bit since Thursday's update.
<strmpnk>
Is there a way to "race" multiple async calls/frames and return the first to return a value or fail?
<strmpnk>
It seems like the await mechanism will prevent others from being awaited, which prevents parallelism on the return path.
<strmpnk>
The "all awaits complete" semantics certainly makes errdefer semantics easier at least (re: cancellation was also an interesting problem).
<strmpnk>
I don't think most code will care but certain kinds of I/O heavy work will want to avoid false sequencing, which means the awaiters will all need to have some kind of awareness of the suspend/resume scheduling code to achieve this.
<strmpnk>
Yeah, that does help, though it's unclear where the dangling await would end up.
<strmpnk>
I guess the channel could be consumed and a separate thread or stage in processing could loop to await frames.
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
FireFox317 has joined #zig
<FireFox317>
It seems like the tests for MacOS are stuck in std.event.Channel. It causes the MacOS CI to timeout after 6 hours
<diltsman>
Why is "[*c]c_void" a problem? I see that the standard library uses "*c_void".
<diltsman>
I assume that it has something to do with the union of behaviors of "*T" and "[*]T".
<andrewrk>
FireFox317, should be fixed now. the std lib event loop code is still considered "experimental". After I'm convinced it's going in a stable direction I'll be a lot more careful about breakage
<fengb>
diltsman: yeah [*] means it’s unknown whether it’s single or array.
<fengb>
You shouldn’t design an API like that. It’s only for translating C, where we cannot know without reading the docs
<andrewrk>
standard library usage of *c_void is a smell
<fengb>
Oops, [*c] means unknown
<andrewrk>
[*] means it points to an unknown number of items
<andrewrk>
[*c] means it's unknown, but the API might still require using the pointer as a single item. and since the API is auto-translated, fixing the API to use [*] or * is not possible
<andrewrk>
[*] also means not-null. but [*c] pointers can be null, but they allow treating it as non-null with out compiler type safety (runtime safety instead)
<andrewrk>
if we didn't have C translation, we wouldn't have [*c] pointer types
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 268 seconds]
FireFox317 has quit [Remote host closed the connection]
<diltsman>
Me struggling to make the logical transition from C and C++: Is there some way to have an allocated array that is automagically collected when the array goes out of scope? Something like C++'s std::unique_ptr. My thought is that something vaguely like it is going to be possible, but it will have different syntax and semantics.
<tav>
does anyone know if there's a vdom implementation in zig?
<tav>
if not, I think I'll start working on one
<nrdmn>
diltsman: the language zig doesn't have the concept of dynamic allocation and the stack works the same as in C and C++
<diltsman>
That was my thought. So things have to be done through allocator types. Which means that you can defer the deallocation, but there is no way to transfer the ownership up a level of the stack once you have defered.
<nrdmn>
correct
rjtobin has joined #zig
<diltsman>
Is there a way to specify a set of flags that can be ored together to create a compound value but cannot be ored without any values outside of those flags? The best that I can see is to use constants at the file scope and just be careful to use just the correct ones.
marijnfs_ has joined #zig
<nrdmn>
if you want to use an integer for your flags set and your flags are contiguous, you can use an integer that is exactly the width of your amount of flags
porky11 has quit [Ping timeout: 250 seconds]
<nrdmn>
otherwise you can use a packed struct of bools and switch them on and off individually
<nrdmn>
or u1, I'm not sure if bools are actually 1 bit when packed
<diltsman>
3 non-adjacent bits in the 32-bit integer.
marijnfs has quit [Ping timeout: 245 seconds]
kristoff_it has joined #zig
<andrewrk>
tav, I'm fairly certain there is not
<andrewrk>
nrdmn, yes bools are 1 bit in packed structs
<curtisf>
You can mostly work-around the lack of new structs, because you can generated structs with a `fn get(self: Self, comptime fieldname: []const u8)`, but I didn't do that for my library yet
<andrewrk>
I feel you on the crashes. Towards the end of a release cycle, I focus on stability and bug fixes. So we should start to see those crashes getting fixed over the next month and a half
<andrewrk>
right now we're at peak instability - just finished 2 major reworkings of zig's innards - result location semantics & async/await rewrite
kristoff_it has joined #zig
<andrewrk>
so it can only get better from here
<andrewrk>
also there aren't many big breaking changes left to do
<andrewrk>
we're getting close to the language's final syntax / semantics
<curtisf>
how do you parse recursive structures without an allocator?
<andrewrk>
once zig has unsafe recursion prevention, you won't be able to
<nrdmn>
to prevent my code from being run at compile time, I tried to use an interface for the structs returned from the parsers, but I became too tired to continue to work
<hryx>
andrewrk: I just saw your last stream. Congratulations on the huge merge!
<andrewrk>
thanks hryx :)
<hryx>
sad I missed the poll, but I obviously would have chosen the reptile anyway
<andrewrk>
yeah the name has to be a pun on the language name and it has to be something not already dressed up, so that people can dress it up in cute ways. clearly the other 2 are disqualified
<hryx>
heh. Is the artist already chosen?
marler8997 has joined #zig
<marler8997>
I'm trying to use zig like a regular C compiler where it recognizes C-command-line arguments and other build tools can use it like a c-compiler.
<scientes>
marler8997, zig cc does that....
<marler8997>
but it doesn't work like a normal C compiler
<marler8997>
I can't just do "zig cc hello.c"
<scientes>
oh hmm
<marler8997>
so other build tools don't know how to use it
<scientes>
i though it just calls clang
<andrewrk>
marler8997, that doesn't exist currently. `zig cc` has no system awareness. it's unclear whether that will ever exist
<marler8997>
I'm trying to use zig as the c-compiler to build other C projects using their build system
<marler8997>
I could create a translation program, but wondering if any work/design exists for this already
<andrewrk>
I understand the use case. I think it could be at least considered. can you open an issue?
<marler8997>
sure thing
<andrewrk>
idea being that it will act exactly like clang, except it will set up the linker & includes to use zig's libc, libunwind, etc
<marler8997>
right
<andrewrk>
which is what already happens with the higher level CLI
<andrewrk>
but it's a different CLI than clang
<marler8997>
yeah
Taslem has joined #zig
<marler8997>
If that was supported, we could even use zig to build llvm :)
<curtisf>
Is there a trie or balanced tree map in the standard library that I've missed? also, is there a plain old FIFO queue?
<marler8997>
to "draw one"?
<curtisf>
to draw a ziguana
<fengb>
The ziguana needs a space ship
Taslem has left #zig [#zig]
<andrewrk>
curtisf, have you seen the file std/std.zig?
<andrewrk>
I'm not sure what red black trees are but that might be related (std.rb). I believe TailQueue is a doubly linked list
<andrewrk>
been meaning to change the namespacing, but std.atomic.Queue is a doubly linked list that is protected by a mutex to make it thread safe
<curtisf>
ah, I missed "TailQueue", although I was hoping for a circular buffer. Didn't realize "rb" stood for "red black", that is it
fubd has joined #zig
<andrewrk>
thanks marler8997
<marler8997>
yeah
<fubd>
are bound fns a thing yet?
<fubd>
i.e., can i pass one to a function that takes a "fn() void" callback
<fubd>
will they ever work that way?
keithdc has quit [Ping timeout: 245 seconds]
andersfr has joined #zig
andersfr has quit [Client Quit]
fubd has quit [Remote host closed the connection]
kristoff_it has joined #zig
<shachaf>
andrewrk: On recursion: The "standard" way to handle stack frames is to just use an arena to allocate frames. I guess Zig calls this variant a FixedBufferAllocator (though I don't think the current implementation has frame support?).
<shachaf>
It would sure be nice if platform ABIs just told you how big the stack is rather than expecting you to SEGV if you use too much.
<andrewrk>
shachaf, you can use any allocator to put a frame in it