ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
mahmudov has quit [Remote host closed the connection]
dbandstra has quit [Quit: Leaving]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
noonien has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<kristate>
andrewrk: I'm excited about caching!
unique_id has joined #zig
<unique_id>
andrewrk: Do you know anything about game audio? As far as I know, when it comes to open source solutions OpenAL was pretty much the only thing awailable. Then browsers wanted to provide 3D audio and so a nice spec was born. Browsers implemented this and some people extracted it out for non-browser use (LabSound), so now there's two solutions for open source game audio.
<unique_id>
There is SoLoud, which seems really nice, however its author had a two year break from the project after getting some constructive criticism from a game developer (according to his blog). I'm guessing that criticism was SoLoud lacking a graph based design which the browser spec has.
<unique_id>
So anyway, that's why I'm converting Webkit's code/LabSound to Zig, but my game and anyone else that wants to use it
<unique_id>
for* my game, sigh
<kristate>
unique_id: sounds cool!
<kristate>
unique_id: where are you located?
<unique_id>
I'm back in Iceland now (where I'm from).
<unique_id>
I'm forgetting Godot! They've written their own stuff
davr0s has joined #zig
kristate has quit [Remote host closed the connection]
Hejsil has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<andrewrk>
unique_id, my plan was to implement my own mixer and stuff for my next game
<andrewrk>
I haven't done that before though so I'm not sure I have any advice
<unique_id>
"It is a goal of this specification to include the capabilities found in modern game audio engines as well as some of the mixing, processing, and filtering tasks that are found in modern desktop audio production applications."
<unique_id>
Sounds like a good starting point :)
<unique_id>
from the Web Audio API spec
davr0s has joined #zig
Hejsil has quit [Quit: Page closed]
bheads has quit [Ping timeout: 244 seconds]
kristate has joined #zig
clownpriest has joined #zig
scientes has quit [Ping timeout: 240 seconds]
kristate has quit [Ping timeout: 252 seconds]
<unique_id>
I'm so opinionated, I've changed the design a lot already during porting
wink_ has joined #zig
clownpriest has quit [Ping timeout: 252 seconds]
<unique_id>
though I just mean to favor perf and explicitness over flexibility, we'll see how it goes. Ok enough about my stuff.
kristate has joined #zig
clownpriest has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<MajorLag>
andrewrk, I'm curious what's so difficult about making @ptrCast work at comptime. I am admitedly ignorant of compiler internals.
<andrewrk>
it's not inherently difficult, but the way it's currently designed makes it difficult
<andrewrk>
comptime values are a tagged union, and a comptime pointer value points to other comptime values
<andrewrk>
if you pointer cast, it doesn't, like, mangle the bytes or anything. it just has a mismatching type and value
<andrewrk>
so code has to be modified to detect this mismatch and handle it appropriately
<andrewrk>
e.g. in the example I posted, the underlying data is still an array of u8's
<andrewrk>
so the code that looks at a field has to, instead of expecting the comptime value tagged union to be a packed struct, do a memory interpretation
<andrewrk>
or at least adding a TODO compile error
kristate has quit [Remote host closed the connection]
clownpri1 has joined #zig
clownpriest has quit [Ping timeout: 252 seconds]
<MajorLag>
seems to me that if you eliminated ConstPtrValue and integrated pointer types into ConstExprValue, then a comptime pointer would just be a new ConstExprValue with its own type information. Of course, I say that without looking at how any of this is acutally used.
<MajorLag>
Oh, I think I see. You can't just point to the data because the data isn't just the bytes of the value.
<andrewrk>
exactly
<andrewrk>
I figured out a way that we can have TODO compile errors for all this stuff for now, and then incrementally add support for comptime byte reinterpration of various things
clownpriest has joined #zig
clownpri1 has quit [Ping timeout: 250 seconds]
<MajorLag>
That seems like it'd be kind of fragile.
<andrewrk>
it's strictly better than status quo
<andrewrk>
what are now segfaults and assertion failures become compile errors
<andrewrk>
and then we can make progress on supporting various kinds of comptime byte reinterpretation, so then compile errors gradually turn into working test cases
<andrewrk>
at no point does the compiler get worse
kristate has joined #zig
<MajorLag>
Yeah, that makes sense and all, I just mean that it seems like it might be better to rethink the approach to comptime values entirely so that pointers and pointer casting work in a more natural fashion. Having to special case all possible conversions seems cumbersome.
<andrewrk>
stage2 is an opportunity to do that
davr0s has joined #zig
<kristate>
☆
<MajorLag>
fair enough
<andrewrk>
also there's not really code duplication. the problem is just this complicated
unique_id has quit [Remote host closed the connection]
<andrewrk>
e.g. you have to write "serialize to/from bytes" code for every type that supports it
<andrewrk>
it shares code with @bitCast
<andrewrk>
representing the data as annotated bytes rather than meaningful data is more convoluted, and probably slower
<andrewrk>
so I don't think it will work different in stage2
<andrewrk>
although the ergonomics of it and fragility will be mitigated in other ways
<MajorLag>
On a different topic, zig theoretically allows for `@IntType(false, @maxValue(u32))`. This is of course a ridiculous type to use, but if it is supported then how could something like `TypeInfo` reasonably represent it?
<andrewrk>
or maybe zig should choose something a bit more conservative, such as u16 for those types
<andrewrk>
oh, wait alignment is u29
<MajorLag>
it certinaly seems to fall into YAGNI territory.
<andrewrk>
eventually we're going to need to write a zig language specification, and it should probably have a good reason for choosing the max other than "this is llvm's max"
<andrewrk>
or maybe not. I'll open an issue
<MajorLag>
still, I wouldn't say it is reasonable to have typeInfo contain 65535-bit integer fields.
<andrewrk>
I don't follow. wouldn't it just have this: bit_count: u23
<MajorLag>
what about something like .max_value?
<MajorLag>
I mean, that can just be done in a function, but then there's enum_value and other things...
<andrewrk>
fn maxInt(comptime T: type) T { ... }
<MajorLag>
perhaps typeInfo doesn't need to have a fixed structure, and it's fields can changed based on the type it describes.
<andrewrk>
why do we need to make typeInfo more complicated?
<MajorLag>
"more complete" is what I'm aiming for.
<MajorLag>
I guess it really doesn't need to be.
<andrewrk>
type info should be the stuff you can't get another way
<andrewrk>
max int value is a property that can be computed based on bit width and signed-ness, so type info should just have bit width and signed-ness
<MajorLag>
I think I'm still thinking that ultimatly it would be used with @reify, in which case people might want to create a type with a maxValue less than its bit_count allows for saftey check purposes, but @reify is probably too complicated to make it into the language anyway.
<andrewrk>
I've been thinking about a similar feature about integer types that have value ranges distinct from the bit width
<andrewrk>
it would need to be integrated into the type system
<andrewrk>
and in this case yes, it would be a property of type info
<andrewrk>
yeah and as you pointed out this would require type info struct to be generic
<MajorLag>
There's also the matter of multiple mechanisms to get the same information. Type.bit_count vs @typeInfo..bits, for instance. My understanding was that we'd want to introduce std.meta and unify over typeInfo.
<andrewrk>
that's still the plan
unique_id has joined #zig
<andrewrk>
there's a wip branch I think
clownpri1 has joined #zig
clownpriest has quit [Ping timeout: 252 seconds]
clownpri1 has quit [Ping timeout: 252 seconds]
clownpri1 has joined #zig
clownpri1 has quit [Ping timeout: 252 seconds]
clownpri1 has joined #zig
clownpri1 has quit [Ping timeout: 252 seconds]
clownpri1 has joined #zig
geocar has joined #zig
clownpriest has joined #zig
clownpri1 has quit [Ping timeout: 252 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
clownpriest has quit [Ping timeout: 240 seconds]
clownpri1 has joined #zig
clownpriest has joined #zig
clownpriest has quit [Client Quit]
clownpri1 has quit [Ping timeout: 250 seconds]
clownpriest has joined #zig
clownpriest has quit [Client Quit]
clownpriest has joined #zig
clownpriest has quit [Client Quit]
clownpriest has joined #zig
clownpriest has quit [Client Quit]
clownpriest has joined #zig
kristate has quit [Remote host closed the connection]
clownpriest has quit [Quit: clownpriest]
clownpriest has joined #zig
clownpriest has quit [Client Quit]
clownpriest has joined #zig
clownpriest has quit [Ping timeout: 240 seconds]
<unique_id>
There's nothing like going through C arithmetic code and not knowing what's supposed to overflow and what isn't :) I'm convering date algorithms...there's probably lots of intentional overflow! I blame C of course.
<unique_id>
it's actually c++ code which is why im porting it
<andrewrk>
you can always play it safe and put % on all the ops
<unique_id>
yep
clownpriest has joined #zig
clownpri1 has joined #zig
clownpriest has quit [Ping timeout: 252 seconds]
clownpri1 is now known as clownpriest
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
martinium has joined #zig
<martinium>
so I just found out about this lang and am trying to set up the precompiled binaries on my system. Is there a a specific environment variable I need to set that points to zigs lib directory?
<andrewrk>
martinium, you should be able to unarchive the binaries, and then run zig directly from that directory
<andrewrk>
1. extract all 2. run zig
<martinium>
I linked the binary to my usr/local/bin directory for access throughout system
<martinium>
let me test directly from folder to see if it makes a difference
<martinium>
Unable to find zig lib directory. Reinstall Zig or use --zig-install-prefix.
<andrewrk>
martinium, I'll make a note to have zig additionally check realpath for the std lib files
<martinium>
cool
<martinium>
I just found out about this lang
<martinium>
looks very promising
<martinium>
do you work on windows primarily?
<martinium>
If I were to use --zig-install-prefix what would that look like?
<martinium>
--zig-install-prefix=directory
<andrewrk>
my home os is linux
<martinium>
good
<andrewrk>
I don't think you need to resort to --zig-install-prefix
<martinium>
tried running it from base directory
<martinium>
still isn't checking the relative path
<martinium>
for the lib folders content
<andrewrk>
it's doing readlink("/proc/self/exe") to find out the search path for lib dirs
<andrewrk>
I just tested it, and it worked. did you do something other than tar xvf and then run it?
<martinium>
if I point the compiler to a directory with a few .zig files I want to build them all will it build them all in sequence or must you specify individually