ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
oa is now known as oats
darithorn__ has quit [Read error: Connection reset by peer]
darithorn__ has joined #zig
fsateler has quit [Read error: Connection reset by peer]
fsateler has joined #zig
darithorn_ has joined #zig
darithorn_ has quit [Read error: Connection reset by peer]
darithorn_ has joined #zig
darithorn__ has quit [Read error: Connection reset by peer]
<daurnimator> andrewrk: allocating stack on demand -> instead the zig way is a @ensureStack() builtin?
<daurnimator> andrewrk: note that allocating stack of demand is the *norm* -> if you want to be able to write libraries in zig to use with C (which to me is one of the main benefits of zig), then you need to deal with it...
daurnimator has quit [Ping timeout: 240 seconds]
<scientes> daur.....gone
daurnimator has joined #zig
darithorn__ has joined #zig
darithorn_ has quit [Ping timeout: 245 seconds]
<scientes> wow, I was writing a exit_group() patch at the same time......
<scientes> and i never saw the bug
<daurnimator> scientes: sometimes you've got to be quick around here ;)
scientes has quit [Ping timeout: 246 seconds]
shritesh has joined #zig
scientes has joined #zig
nullheroes has joined #zig
_whitelogger has joined #zig
scientes has quit [Ping timeout: 244 seconds]
<mikdusan> A command-line tool written in Zig to measure the performance of various UTF8 decoders. https://github.com/mikdusan/benchmark.unicode
dewf has quit [Quit: Leaving]
<emekankurumeh[m]> andrewrk:
<emekankurumeh[m]> why do we have this line when building on windows? https://github.com/ziglang/zig/blob/master/CMakeLists.txt#L6611
_whitelogger has joined #zig
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
darithorn__ has quit [Remote host closed the connection]
allochi has joined #zig
allochi has quit [Client Quit]
dch has quit []
dch has joined #zig
scientes has joined #zig
Zaab1t has joined #zig
Zaab1t has quit [Ping timeout: 250 seconds]
Zaab1t has joined #zig
jjido has joined #zig
Zaab1t has quit [Ping timeout: 272 seconds]
fsateler_ has joined #zig
Zaab1t has joined #zig
fsateler has quit [Ping timeout: 268 seconds]
Zaab1t has quit [Ping timeout: 250 seconds]
Zaab1t has joined #zig
a_chou has joined #zig
very-mediocre has joined #zig
a_chou has quit [Client Quit]
scientes has quit [Remote host closed the connection]
scientes has joined #zig
marmotini_ has joined #zig
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 250 seconds]
Zaab1t has quit [Ping timeout: 255 seconds]
knebulae has quit [Ping timeout: 245 seconds]
alot has joined #zig
very-mediocre has quit [Ping timeout: 256 seconds]
scientes has quit [Read error: Connection reset by peer]
shawn_ has joined #zig
marmotini has quit [Ping timeout: 250 seconds]
shawn_ is now known as scientes
knebulae has joined #zig
scientes has quit [Ping timeout: 246 seconds]
Zaab1t has joined #zig
m6w6 has quit [Quit: https://m6w6.name]
m6w6 has joined #zig
<andrewrk> mikdusan, out of curiosity, why is clang --version provided in the README file?
<andrewrk> also I had to add + exe.linkSystemLibrary("c"); to the build.zig file to make it work
<andrewrk> emekankurumeh[m], I don't remember
<andrewrk> you could try git blame
<mikdusan> andrewrk: only to indicate what zig was built with
<andrewrk> ah
<mikdusan> which platform did u need libc. linux?
<andrewrk> yes
<andrewrk> ahh I see. if you test only on macos libc is always available
<mikdusan> so logic basically could then be… if not macos add libc <— better than if linux add libc ?
<mikdusan> (for my build.zig file)
<andrewrk> mikdusan, you can unconditionally add it to your build.zig and that would be correct
<andrewrk> mikdusan, oh you might not actually depend on libc. this is the error I get:
<andrewrk> atom.hoehrmann.zig:20:9: error: dependency on library c must be explicitly specified in the build command
<andrewrk> it's because you have extern "c" fn atom_hoehrmann_spin
<andrewrk> which actually communicates that you expect to find atom_hoehrmann_spin in libc
<mikdusan> oh. i thought it was a cheap way to avoid importing a .h
<andrewrk> you should remove the "c" since it's found in your own .c file
<andrewrk> I can see how what is confusing
<andrewrk> pub extern fn atom_hoehrmann_spin
<andrewrk> mikdusan, it's just the "c". I changed all the `extern "c"` to `extern` and now it doesn't need libc
<mikdusan> 👍 that patch looks strangely byte-for-byte identical to my push
Akuli has joined #zig
Ichorio has joined #zig
<andrewrk> the extern "foo" feature is useful on Windows to generate dependencies on kernel32.dll, ntdll.dll, etc
<mikdusan> so it’s a mechanism to indicate to linker which libs symbs are actually used instead of blanket lib linking. there’s no equiv in C, correct?
vyzkoh__ has joined #zig
vyzkoh_ has joined #zig
vyzkoh__ has quit [Client Quit]
vyzkoh_ has quit [Read error: Connection reset by peer]
noonien has quit [Quit: Connection closed for inactivity]
<andrewrk> correct
Hejsil has joined #zig
<Hejsil> andrewrk, currently working on https://github.com/ziglang/zig/issues/863 and hit a problem I'm not sure exactly how to get past. We have this `([*]align(alignment) T)(undefined)[0..0]` in mem.zig at it crashed my current implementation, because *[0]T is a 0 bit type, so an assert ensures that it has alignment 0
<andrewrk> hi Hejsil, I think that assert might not be necessary. where is the assert?
<andrewrk> oh, is this a new assert you added?
<Hejsil> analyze.cpp:527
<Hejsil> No
<andrewrk> ok, in this context, byte_alignment == 0 means that the pointer type has ABI alignment and therefore an explicit align(x) is not required in the pointer type
<andrewrk> thinking out loud here, alignment for a zero bit type doesn't make sense because there is no address, so alignment is not relevant in any way
<Hejsil> Makes sense
<Hejsil> Btw, the `([*]align(alignment) T)(undefined)[0..0]` is on mem.zig:101
<Hejsil> For more context
<Hejsil> In alignedAlloc
<andrewrk> let me see if I can trigger that assert in master branch
<Hejsil> Well, it is my changes that have caused this. It happens because with the new changes, slicing [0..0] gives you *[0]T but this ptr has an explicit alignment which kinda breaks this "cast"
<andrewrk> Hejsil, here's a clue: in ir_analyze_instruction_ptr_type there is logic that says if (!type_has_bits(child_type)) align_bytes = 0
<andrewrk> so that's why `var x: *align(4) void = {}` doesn't crash in master branch
<Hejsil> Aah, I see
<andrewrk> I think it does make sense for a zero bit type to "destroy" alignment information in the pointer, because there is no address
<andrewrk> and you won't be able to @ptrCast back to a non zero bit type
<andrewrk> however I think that a 0 len slice is allowed to have a pointer with aligned address as long as the element type has bits
<andrewrk> I also think this should be allowed: *align(4) [0]u8
<andrewrk> that could be, for example, the "end" pointer address of a block of memory
<andrewrk> Hejsil, does that help?
<Hejsil> I'll try work from here :)
<andrewrk> hmm. the *align(4) [0]u8 thing contradicts master branch
<andrewrk> I think that requires more thought
<Hejsil> Actually, shouldn't we keep the alignment information for implicit cast?
<Hejsil> like *align(4) const [0]T -> []align(4) const []T
<andrewrk> the thing that makes sense to me is not keeping alignment information if there is no address
<andrewrk> e.g. if @ptrToInt would give "error: pointer to size 0 type has no address" then alignment shouldn't be possible
<andrewrk> if we keep alignment information, we better keep the pointer address too
<Hejsil> Hmmmm
<Hejsil> Let me see when I hit a roadblock next, then I'll think about it some more. I'll try to throw away alignment for now
<andrewrk> ok
<andrewrk> yes this may be an orthogonal problem you have run into, that doesn't have to be solved with your work on 863
<Hejsil> It might have to, as alignedAlloc relies on this cast :)
<andrewrk> for the new_n == 0 case?
<Hejsil> Alright, I should stop talking until I actually hit the problem I'm thinking of, lol
<Hejsil> More coding less talking!
<andrewrk> haha
<Hejsil> My terminal exploded with compiler errors, but not the errors I expected
<Hejsil> zig compiler errors, not cpp compiler erros
<Hejsil> The type system should alway use the instructions type and not the ConstExprValue's type for typechecking yes?
<andrewrk> the ConstExprValue type tells how the data is stored in the ConstExprValue data structure. the instruction's type is the user-visible type according to zig semantics
<andrewrk> I think that's a "yes"
<Hejsil> Alright, then I think I've hit a but along the way. Let me make sure I'm correct here
wilsonk has quit [Ping timeout: 250 seconds]
wilsonk has joined #zig
wilsonk has quit [Ping timeout: 246 seconds]
dd10 has joined #zig
wootehfoot has joined #zig
<dd10> Hello everyone, I'm just discovering Zig-lang, am I correct if I say that “zig-general-purpose-allocator” (https://github.com/andrewrk/zig-general-purpose-allocator) is a way guarentee safety at compile time for the majority of possible failures listed at "memory leak" section in this page: https://en.wikipedia.org/wiki/Memory_safety ? According to some searches on the web, Zig is not considered like a "safe" language (I mean as Rust prom
<dd10> But the on-going work let me think that Zig would like to improve this?
<andrewrk> dd10, not at compile time
<andrewrk> zig is not a safe language
<andrewrk> and it's not planned to ever be
<andrewrk> your first comment got cut off at "Rust prom-"
<dd10> ok, it's clear now =)
<dd10> the comment was: According to some searches on the web, Zig is not considered like a "safe" language (I mean as Rust promises).
<dd10> thanks for responses
<andrewrk> dd10, no problem. zig tries to make it more difficult to cause undefined behavior than other unsafe languages, but it cannot be guaranteed at compile time, and some kinds of undefined behavior cannot be caught at runtime either
<mikdusan> i gotta say discovering the pleasant benefits for something as rudimentary as slices combined with “strings” that are not null terminated.
<mikdusan> the othe day i wrote a fn to split a string on EOF boundries (lines) and was dreading it. but it turned out to be real easy thanks to slices, and didn’t need to alloc memory for the lines either because no null termination.
<Akuli> speaking of that
<Akuli> how should i call a c function that expects a 0-terminated string? do i need this: https://github.com/Akuli/curses-minesweeper/blob/master/src/curses.zig#L35-L38
<andrewrk> mikdusan, you can use std.mem.tokenize or std.mem.separate for that
<mikdusan> even easier
<andrewrk> var it = std.mem.tokenize(buffer, "\n\r"); while (it.next()) |line| doSomething(line);
<andrewrk> Akuli, you may find std.Buffer helpful
<Akuli> i think my main question was whether i really need an allocation each time, because this function is called very often
<andrewrk> in this case why not make mvaddstr take a [*]const u8?
<Akuli> what's that :D
<Akuli> let me look it up from the reference
<andrewrk> it's the type of cstr.ptr, the type that you're creating to pass to mvwaddstr
<Akuli> how would i call the function then? would i need to use c strings everywhere in the rest of the program?
<Akuli> hmm you know what i should do
<Akuli> i should use mvwaddnstr instead, it takes the length of the string as an argument
<andrewrk> you're calling a C function that expects a C string, and you don't want to convert from slices, so that would make sense wouldn't it?
<andrewrk> now that's a much better solution
<andrewrk> after https://github.com/ziglang/zig/issues/265 the type of string literals will be *[N]null const u8. this will implicitly cast to [*]null const u8, which will help a bit because you'll be able to pass zig string literals to functions which expect C strings
<andrewrk> oops. *const [N]null u8
dd10 has quit [Ping timeout: 256 seconds]
Zaabtop has joined #zig
Zaab1t has quit [Ping timeout: 245 seconds]
Zaabtop is now known as Zaab1t
Zaab1t has quit [Quit: bye bye friends]
Hejsil has quit [Quit: Page closed]
<mikdusan> andrewrk: apologies at this basic question; but why is `@typeOf(“hello”)` → `[5]u8` and not `[5]const u8` ?
<andrewrk> `[5]const u8` isn't a type
<andrewrk> `const` is a pointer attribute
<andrewrk> and the array type isn't a pointer
<mikdusan> ok so whenever i see const it’s only about pointer.
<andrewrk> right. even on variables - you can think of `const` as meaning that if you take the address you'll get a const pointer
<andrewrk> after https://github.com/ziglang/zig/issues/265 is done, string literals will be pointers, not arrays. and so they will have `const` in them like you expected
<mikdusan> yes 265 was what made me ask this. my head is spinning a bit.
<mikdusan> re: literals will be points; so “hello” would have typeof `[]const u8` without the need for slicing syntax?
<andrewrk> `@typeOf("hello")` will be `*const [5]null u8` which implicitly casts to `[]const u8`
<andrewrk> status quo string literals cast to `[]const u8` without the need for slicing syntax. but it's a bit of a hack. we'll be removing a possible footgun by changing it
<mikdusan> ah. i see *const.
scientes has joined #zig
<andrewrk> reading `*const [5]null u8` from left to right: "pointer to one 5-element array, which has an extra 0 element not counted in the length, of u8s"
jjido_ has joined #zig
<mikdusan> i think it’s a good decision to not count nullz.
<andrewrk> oops, forgot to add "immutable" in there
<andrewrk> reading `[]const u8`: from left to right: "pointer to a number of elements known at runtime of immutable u8s"
<mikdusan> not entirely clear from 265, if c-literals are going away, what is syntax to specify a literal string with nullz ?
<andrewrk> all string literals will have a null byte after them
<andrewrk> that's why `@typeOf("hello")` will be `*const [5]null u8` - it has the `null` in there
* mikdusan i think that’s a reasonable tradeoff to avoid another syntax. but if u didn’t want to nullz pure zig literals, then something simple like suffix could work?
<mikdusan> like “hello” vs. “hello”z
<andrewrk> so 265 lets us delete syntax from the language. string literals will cast to `[]const u8` (zig-preferred byte slice) as well as `[*]null const u8` (C strings)
<andrewrk> why would you want to do that? to shave off a few bytes from your program size?
<mikdusan> i guess that’s all it saves
<andrewrk> if that's an issue, zig can probably detect when a string literal is never casted to `[*]null const u8` and omit the null byte
<andrewrk> I don't think anyone will find that necessary. C programs already have the null byte for every string literal, and nobody cares about that
<mikdusan> and the guarantee is only that there is nullz, and there is NO guarantee about bytes before nullz; ie: if someone is setting other spots to zero
<andrewrk> correct
<tgschultz> I remember raising the same objection, but withdrew it after I realized that you can use a comptime function call to turn any `*const [N]null u8` into a `[N]u8` if that's really what you want.
<mikdusan> save-a-nullz-byte-optimizer-pass
<scientes> why pub const abi = Abi.gnu; and pub const link_libc = false; ?
dd10 has joined #zig
<scientes> why isn't that abi=Abi.none ?
Akuli has quit [Quit: Leaving]
<andrewrk> scientes, it specifies the ABI of extern functions and structs
Ichorio has quit [Ping timeout: 255 seconds]
alot has quit [Quit: WeeChat 2.4]
<andrewrk> scientes, I don't think you need to do that pthread_self stuff. there's a simple way to make this work and there is an established pattern: if (builtin.link_libc) then use pthread mutexes rather than zig's own implementation
<andrewrk> see for example the implementation of std.os.abort, std.os.exit, std.os.spawnThread
<scientes> I need it to do robust mutexes that can be shared between 32-bit and 64-bit
<scientes> but I will have to investigate if it can co-exist with musl or glibc pthreads
dd10 has quit [Quit: Page closed]
<andrewrk> ok. you might consider opening an issue to discuss your use case if you want this merged into the standard library, because it sounds kinda weird
<scientes> there is an issue
<andrewrk> the implementation of this issue will be what I said with regards to linking libc and using pthreads
<scientes> it won't work with pthread_mutex_t, but I would like the same thread to be able to run musl or glibc thread code and pthread locks, and also zig code and locks
<scientes> however the offset that glibc uses that we have to match to make THAT work, is 24 bytes, which is also a little bigger than I would like the SharedMutex struct to be
<andrewrk> right so I'm not familiar with this use case, and I haven't read that URL yet, and I consider this to be a different issue than #1455. so I'm just giving you a heads up, this isn't an obvious "cool, done, merged" situation. I'll need to understand it first
<scientes> so maybe it would be forbidden to use zig threading and pthread threading from the same thread
<scientes> yes, I C. here is the use case: sometimes you need locking between a client and server, and that server might run 64-bit while the client is 32-bits
<andrewrk> I'll read the logs - gotta run
<wrl> scientes: do you just need to do this on linux?
<scientes> I don't know anything about locking on other platforms
<wrl> use eventfd if you can
<wrl> like if you can build the primitive you need with it
<scientes> A use code would be pulseaudio
<scientes> which currently is slow from 32-bit clients on a 64-bit system (I don't have benchmarks), because of the lack of this
<wrl> well jack uses sem_t
<wrl> in shared memory segments
<scientes> thats the same problem
<scientes> pthread can't handle mixed-arch use-cases
<wrl> jack does though
<wrl> so check how they're doing it
<scientes> it is probably using a UNIX socket like pulse does
<wrl> are you going to make me look this up
<scientes> I mean pulseaudio is amazing with how it works over the IP with mDNS
<scientes> eek, it uses TCP though, instead of fancy UDP
<scientes> fine for some use-cases
<wrl> jack appears to use raw futexes in shared memory segments
<scientes> does it use set_robust_list() ?
<scientes> nope, which means that if jack crashes, your client applications will lock up
<scientes> so again, another use case for zig adding this feature
<wrl> cool
<wrl> well, happy to help
<scientes> oh pulseaudio supports RTP, which is over UDP, so that use-case is covered
wootehfoot has quit [Read error: Connection reset by peer]
wilsonk has joined #zig
Pursche01 has joined #zig
Pursche01 has quit [Client Quit]
<daurnimator> scientes: robust mutexes are only good for one thing: when you want to get notified that a thread died
<daurnimator> (because... on linux; it's the *only* way to get notified that a thread has died)
<scientes> when you are using locks that is pretty useful information