ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
errpr has quit [Ping timeout: 252 seconds]
Sahnvour has quit [Remote host closed the connection]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
jmiven has quit [Quit: co'o]
jmiven has joined #zig
<suirad> andrewrk: what minimal windows do you plan on zig targeting? I was considering doing the windows portion of std.mutex and was reading over the various api to use.
<suirad> its looking like for winxp: CriticalSections; for winvista-win7: SRWLocks; and for win8+: WaitOnAddress since its the closest thing to a futex. But those I have found before digging into documented/undocumented winnt stuff.
<suirad> perhaps NtWaitForKeyedEvent/NtReleaseKeyedEvent?
suirad_ has joined #zig
suirad has quit [Ping timeout: 256 seconds]
emekoi_ has joined #zig
<emekoi_> i was working on porting std.Muted to windows, but i didn't consider the different versions of windows
emekoi_ has quit [Ping timeout: 256 seconds]
oconnor0 has quit [Quit: Quit]
_whitelogger has joined #zig
<daurnimator> re: the pointer subtraction issue: how do you get the "array size" of a type in zig
<daurnimator> e.g. if an object has size 3 but alignment 2. then it takes up 4 bytes per item in an array, right?
<MajorLag> arrays don't have "specially" aligned elements. @sizeOf(u24) is 3, and @alignOf(u24) is 4. @sizeOf([10]u24) is 40. You can't declare [10]align(2) u24, it'll be a compile error.
<MajorLag> oh, interesting. andrewrk: this violates the @alignOf(T) <= @sizeOf(T) rule.
<MajorLag> as stated anyway, I'm pretty sure it is doing what's intended, it just isn't documented correctly?
<suirad_> emekoi_: what api were you going to use for it?
<daurnimator> MajorLag: huh? isn't the rule the other way around?
<daurnimator> MajorLag: from @alignOf docs: " The result is a target-specific compile time constant. It is guaranteed to be less than or equal to @sizeOf(T). "
<MajorLag> right, and @alignOf(u24) is 4, but @sizeOf(u24) is 3. 4 > 3.
<daurnimator> MajorLag: would depend on the system. some probably have 1, some will have 2, others may have 4
<MajorLag> right, but the fact that it violates the rule on any machine means the guarantee is not a guarantee.
<daurnimator> yup
<daurnimator> so sounds like we need to do work there
<daurnimator> going back to my question though: how *do* I get the array index of an item given a pointer to it and the base??
<MajorLag> `const item_index = (@ptrToInt(item_ptr) - @ptrToInt(base_ptr)) / @alignOf(ItemType);` I guess? Since you can't have a custom alignment of array items, @alignOf() will be the "natural" alignment.
<daurnimator> MajorLag: even though the docs say align might be < sizeof?
<MajorLag> hmm....
<MajorLag> boy, having to add a math.max in there...
<daurnimator> isn't not even math.max
<daurnimator> wouldn't it be the lowest multiple of alignOf larger than sizeOf?
<MajorLag> yeah, I guess it would be.
<daurnimator> In C we solve this by using pointer subtraction :P but here I'm trying to emulate pointer subtraction in zig.
<MajorLag> Ok, here's a crazy idea: const elem_size = @ptrToInt(base_ptr[1]) - @ptrToInt(base_ptr[0]);
<daurnimator> MajorLag: is it valid in zig to do base_ptr[1] if the array is only 1 long?
<daurnimator> or are you saying to do it on the base ptr case to [*]?
<daurnimator> *cast
<MajorLag> well, I'd do elem_size using a comptime block, so I'd just create a length two array in there to do it with.
diltsman has joined #zig
<diltsman> "section" changed to "linksection". I can see that this better clarifies what it references, but was there some particular case that this helps with?
<diltsman> Did I see that that is a bug? Did this change with a move to the Zig based Zig compiler?
<benjikun> yes it does seem like something that was apparently blocking something from working with the self-hosted compiler
<benjikun> excuse my use of the word something lmao
<diltsman> I'm thinking that I am going to have to start spending time fixing bugs/incomplete fixtures in the compiler.
_whitelogger has joined #zig
_whitelogger has joined #zig
<emekoi> suirad_: InitializeCriticalSection and friends
emekoi has quit [Quit: Page closed]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<daurnimator> hrm. I tried out the export to C functionality..... not working so well
<benjikun> how so
oconnor0 has joined #zig
<benjikun> Did you look at this?
<benjikun> try doing it with the build.zig setup
oconnor0 has quit [Quit: Quit]
<benjikun> I know that's probably not much help, sorry
<benjikun> haven't really used the C export functionality yet
_whitelogger has joined #zig
suirad has joined #zig
daurnimator[m] has joined #zig
suirad_ has quit [Ping timeout: 256 seconds]
benjikun has quit [Quit: Lost terminal]
tiehuis has joined #zig
<tiehuis> daurnimator: you'll need to use an 'extern struct' the struct returned by makeThing to ensure it is c-compatible
<tiehuis> also you'll probably need an opaqueType here on the inner node else it may be easier to simply use opaqueType for the makeThing and do a ptrCast in the c function boundary
tiehuis has quit [Client Quit]
wink_ has quit [Quit: - A hand crafted IRC client]
wink_ has joined #zig
_whitelogger has joined #zig
davr0s has joined #zig
Zaab1t has joined #zig
<daurnimator> How would @OpaqueType help here? Isn't that for accessing opaque types? not exporting them?
<daurnimator> (also... what's going on with the capitalisation on that)
<daurnimator> quiet day
<daurnimator> also adding export to u32thing doesn't change the output.
desperek has joined #zig
<desperek> hi
<desperek> is zig zig->c->gcc?
<daurnimator> desperek: no. it's zig->llvm ir->binaries
<desperek> ahm
porky11 has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
m4ge123 has quit [Read error: Connection reset by peer]
davr0s has joined #zig
m4ge123 has joined #zig
shollrollah951 has joined #zig
desperek has quit [Quit: xoxo]
_whitelogger has joined #zig
<presiden> let say I wanna write a function that takes an array and modify it
<MajorLag> darnumator, in 1748 you ask for a way to ignore the issue. Are you aware of @alignCast? If not you might want to clarify what you're asking for.
<presiden> for example: fn foo(a: [10]u8) void { a[0] = 42; }
<presiden> ^ that didn't work right, since a is const in this case
<MajorLag> fn foo(a: *[10]u8) void { a[0] = 42; }
<MajorLag> It works like passing structs does. If you pass it straight the compiler is free to choose if it is passed as a pointer or a copy, which means it has to be const.
<presiden> ah, so it's pointer to an array of 10 element
<MajorLag> yes, a pointer to an array of u8 with a comptime-known length of 10. As far as I'm aware, you can treat a *[N]T just like [N]T, so you shouldn't need to change anything else.
<presiden> thanks MajorLag
return0e has quit [Ping timeout: 252 seconds]
return0e has joined #zig
steveno_ has joined #zig
SimonNa has joined #zig
steveno_ has quit [Ping timeout: 252 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<daurnimator> andrewrk: re: @sizeOf(): another thought occurs. If I have a u24, I expect that it would fit in a mmap of length 3.
<andrewrk> do you mean actual mmap? because that requires allocations of at least page size
davr0s has joined #zig
<daurnimator> andrewrk: isn't that a linux-specific thing?
* daurnimator not sure. just another case I was thinking about
<daurnimator> andrewrk: either way, sizeof not being the actual size of something is... weird
<daurnimator> I also have no idea how zig does bitfields yet
<nbjoerg> I wouldn't put bitfields into any modern language...
<daurnimator> I'd prefer them over composing flags for lots of system APIs
<nbjoerg> I don't think they offer any real advantage
<nbjoerg> but I should find the time to write the mixin proposal since that would somewhat address the c&p overhead of non-bitfield designs
errpr has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
<MajorLag> daurimator: zig uses packed structs. `const BitFields = packed struct { b0: bool, b1: bool,, b2: bool, b3: bool... b7: bool };` will be a single byte. In my experience, this is actually harder to work with that consts because you can't use bitwise operators on them.
allan0 has quit [Ping timeout: 246 seconds]
<nbjoerg> at least from the cfe experience, they also often result in bad performance
<nbjoerg> and large code
wootehfoot has joined #zig
Zaab1t has quit [Quit: bye bye friends]
return0e has quit []
return0e has joined #zig
benjikun has joined #zig
errpr has quit [Ping timeout: 264 seconds]
shollrollah951 has quit [Quit: Leaving]
suirad has quit [Quit: Page closed]
wootehfoot has quit [Read error: Connection reset by peer]