ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
dbandstra has joined #zig
geocar has quit [Quit: Connection closed for inactivity]
kristate has joined #zig
kristate has quit [Ping timeout: 248 seconds]
<GitHub131>
[zig] dbandstra opened pull request #1300: A few new functions in InStream/OutStream (master...more-stream-functions) https://git.io/fNgXR
davr0s has joined #zig
Ichorio has quit [Ping timeout: 256 seconds]
<GitHub173>
[zig] dbandstra opened pull request #1301: add SliceOutStream, rename SliceStream to SliceInStream (master...slice-out-stream) https://git.io/fNg1q
return0e has quit [Ping timeout: 248 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
aesl has joined #zig
<aesl>
what is the correct way to return a string from a function?
<kristate>
woke up -- I slept longer than I anticipated, but it is the weekend :-)
<dbandstra>
aesl, i believe the problem is that you are trying to modify a literal string
<dbandstra>
aesl, "axexixoxu" has the type `[]const u8`, not `[]u8`
<aesl>
I tried that because I didn't know how to allocate a string lol
<dbandstra>
if you first do `var string = "axexixoxu";` then at least it can be modified
<dbandstra>
you probably will have to use the slice operator to pass it to the function - `replace(string[0..])` - because the `string` var is an array, not a slice, and arrays don't get implicityl converted to slices
<dbandstra>
(unless they are const)
<aesl>
oh alright
<dbandstra>
with that out of the way, to compare strings you have to use a function `std.mem.eql(u8, first, second)` , not ==
<dbandstra>
zig is pretty c-ish when it comes to strings
<aesl>
alright
<aesl>
and what about the error I get compiling
<aesl>
error: expected type '[]u8', found '[9]u8
<dbandstra>
that says it's expecting a slice, you provided an array
<dbandstra>
solution is just as i said to tack `[0..]` to the end of the array you were trying to pass
<aesl>
oh okay that's simple
<dbandstra>
(`array[0..]` is short for `array[0..array.len]`)
<aesl>
cool it compiles
<aesl>
I have experience from Rust and C
<aesl>
so its really really nice to have a middle ground
<aesl>
and thank you dbandstra
<dbandstra>
np
<aesl>
is there a standard library reference?
<dbandstra>
nope
<dbandstra>
it's just a collection of stuff for the time being
<dbandstra>
it would be nice to write some docs but things are still changing frequently
<aesl>
that's alright
<aesl>
and say I wanted to allocate my own string instead of writing to the string that's passed into the function
<aesl>
what could I do to copy that string
<aesl>
kind of like strdup from string.h in C
<dbandstra>
first of all allocation-related stuff is really explicit in zig
<dbandstra>
so if there was strdup function, it would take an allocator as a param
<dbandstra>
i haven't dealt with allocators a lot personally, not sure if such an alloc-and-copy function exists
<dbandstra>
but you need first an allocator, such as std.debug.global_allocator (warning: crappy, but i'm not familiar with the others)
<aesl>
oh okay
<aesl>
well I actually saw mem.copy and tried to use it but I got an error using s.len as the size of the array
<dbandstra>
note the `!` prefix in the return type, not sure if you've come across that yet, but it means the function may return an error
<aesl>
oh okay, and no I have not
<dbandstra>
briefly, errors are just another value that gets passed around and returned, and there's a few different syntaxes in the language to make it convenient
<aesl>
okay
<aesl>
I'll need to look into errors
<aesl>
yup I <3 zig
aesl has quit [Read error: Connection reset by peer]
kristate has quit [Remote host closed the connection]
kristate has joined #zig
<kristate>
andrewrk: you online?
<kristate>
hmm, 1:28 am in NYC
zolk3ri has joined #zig
kristate has quit [Ping timeout: 244 seconds]
dbandstra has quit [Quit: Leaving]
kristate has joined #zig
davr0s has joined #zig
bheads has joined #zig
bheads has quit [Ping timeout: 264 seconds]
kristate has quit [Ping timeout: 260 seconds]
geocar has joined #zig
kristate has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
kristate has quit [Remote host closed the connection]
kristate has joined #zig
quc has quit [Remote host closed the connection]
quc has joined #zig
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
kristate has quit [Ping timeout: 256 seconds]
kristate has joined #zig
quc has quit [Read error: No route to host]
quc has joined #zig
Ichorio has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
return0e has joined #zig
kristate has quit [Remote host closed the connection]
<bodie_>
Implementing ReFaL in Zig would be a really fun project.
<bodie_>
I wonder if I can find good enough docs to make a go of it.
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
qazo has quit [Ping timeout: 244 seconds]
qazo has joined #zig
kristate has joined #zig
ofelas has quit [Remote host closed the connection]
kristate has quit [Remote host closed the connection]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ofelas has joined #zig
quc has quit [Remote host closed the connection]
quc has joined #zig
kristate has joined #zig
noonien has quit [Quit: Connection closed for inactivity]
kristate has quit [Ping timeout: 244 seconds]
very-mediocre has joined #zig
v1zix has joined #zig
davr0s has joined #zig
companion_cube has joined #zig
<companion_cube>
hi, I'm curious about zig (can't say I need it, but still)
<companion_cube>
there are some interesting design points such as the ability to parse .h files — wouldn't that tie the compiler to a C compiler, long term?
<companion_cube>
is there a goal of, some day, having several compilers, perhaps a gcc frontend?
<companion_cube>
maybe even automatic translation from C?
<companion_cube>
(in a tool, not in the compiler)
aesl has joined #zig
<companion_cube>
I quite like the rust-inspired syntax, and the simplicity of the design centered around comptime
kristate has joined #zig
quc has quit [Ping timeout: 256 seconds]
kristate has quit [Remote host closed the connection]
dbandstra has joined #zig
<andrewrk>
dbandstra, std.mem.dupe
<andrewrk>
hi companion_cube
<companion_cube>
hi andrewrk
<andrewrk>
yes, ability to parse .h files ties zig to libclang
<dbandstra>
andrewrk, ah nice
<companion_cube>
are you the main author, andrewrk?
<andrewrk>
yes
<andrewrk>
although several others have made substantial contributions
<companion_cube>
heh, nice. I like the design, mostly, there even are sum types ✔
<andrewrk>
we have a proof of concept of automatic translation from C
<andrewrk>
zig translate-c foo.c
<companion_cube>
I was reading about Jai earlier, and it's underwhelming, but the "struct of arrays" transformation is cool, and probably doable comptime in Zig
<andrewrk>
it's missing a lot of stuff
<companion_cube>
that's pretty cool!
<companion_cube>
even though it ties even further to having a full C compiler…
<andrewrk>
it does, but there's a clear subset of the language that is divorced from C
<andrewrk>
if you don't use @cImport, and you don't do --library c, we don't actually need the libclang dependency
<andrewrk>
err, sorry I confused 2 things there. if you don't do --library c, then your binary doesn't depend on libc.
<andrewrk>
if you don't use translate-c (which is the same feature as @cImport) then zig compiler doesn't depend on libclang
<andrewrk>
so, once the world is done using C we can delete that dependency ;)
<companion_cube>
:D
<companion_cube>
it'd still be nice to have several compilers (like D has), with something lightweight like dmd in addition to more optimizing, heavier compilers
<andrewrk>
that's a possibility. personally, I'm focused on language stabilization and getting to 1.0.0
<andrewrk>
which I don't consider a dmd equivalent a prerequisite of
<companion_cube>
oh, of course
<companion_cube>
(I'm just worried that some features that would make it to 1.0 would preclude the existence of such lightweight tools)
<companion_cube>
(by requiring a full C compilation chain)
<andrewrk>
the current plan for the language specification is that it will define a clear subset which is "C-less Zig" and so a zig implementation could be compliant with the note that it is "C-less"
<companion_cube>
makes sense.
<andrewrk>
zig really does not depend on C in any way. it just has features to interact with it
<companion_cube>
thanks for your answers!
<andrewrk>
well, sorry that's not technically true. zig depends on llvm, which is written in C++, which depends on C. So there you have it
<companion_cube>
I suppose it stills makes a lot of sense to reuse some C stuff (e.g jemalloc to get a good allocator)
<Bas_>
I actually think so far my two favorite features from Zig are the error handling and the build-in unit test capability
<dbandstra>
nice!
qazo has quit [Ping timeout: 244 seconds]
<Bas_>
It means I can actually do test driven development very easily. Even if it's a bit troublesome currently on windows without stack traces ^^
<dbandstra>
yeah the unit testing is awesome
<Bas_>
And compared to C++ I notice that I need less code, so that's also great.
<dbandstra>
hmm speaking of which, is there a better way than this to assert an error return? `assert(if (func()) false else |err| err == error.SpecificError);`
<Bas_>
Yes....
<andrewrk>
std.debug.assertError
<andrewrk>
I think we can just add == and != support for comparing error unions against error codes though
<dbandstra>
:nerdface:
<andrewrk>
so after that it would be assert(func() == error.SpecificError)
<andrewrk>
I don't know if there's an issue open for that. maybe I'll just open one right now
<dbandstra>
that sounds similar to comparing optional to non-optional
<dbandstra>
which i think i said i would make an issue for but never did
<Bas_>
How would you check if you correctly deallocated all memory? Is there some debug allocator that does that?
<andrewrk>
Bas_, not yet! but that's certainly a good idea to have in the standard library
<andrewrk>
here's a 3-step strategy that works today:
<andrewrk>
1. use std.heap.c_allocator and --library c
<andrewrk>
2. use the --no-rosegment workaround
<andrewrk>
3. run your tests or application with valgrind --leak-check=full
qazo has joined #zig
hooo has joined #zig
<hooo>
gg, I cant even figure out how to get the length of a string. var xy: []const u8 = "HI"; warn("{}\n", cstr.len("hi")); ===> error: expected type '[*]const u8', found '[2]u8'
<Bas_>
maybe try without the const? Or just omit the type :P
<Bas_>
Also I'm not sure if "hi" is a c string
<dbandstra>
what is cstr?
<andrewrk>
dbandstra, std.cstr is a namespace
<dbandstra>
ah i see
<andrewrk>
hooo, arrays and slices have a .len property
<andrewrk>
"hi".len; xy.len
<andrewrk>
cstr is for when you have null terminated strings
<hooo>
Okay I tried to google it for a long time and searched through the std
<Bas_>
I have a question. When implementing functions that work on self, I usually do:
<Bas_>
fn bla(self: * const Self)
<Bas_>
Would it also work the same with just:
<Bas_>
fn bla(self: Self)
<Bas_>
?
<andrewrk>
yes
<andrewrk>
you should use *const Self only if you need to guarantee that it's not a copy
<Bas_>
Ok, usually I don't care.
<andrewrk>
right. the example is if you're using @fieldParentPtr, then you would care
<Bas_>
I see
andi3 has joined #zig
<andi3>
one more reason to have less use cases for @fieldParentPointer
<andi3>
...and hello everyone :)
<andrewrk>
yes andi3 I know you hate @fieldParentPtr :)
<andi3>
yes my brain is still not ready for it, that's certain :D
<Bas_>
It's weird, I agree.
<andi3>
the function itself is fine, its just its (wide) usage :)
<andi3>
there is some issue about return types and how it should be discouraged to return var because it hinders readability which I totally agree
<andi3>
just how feasible would it be to have smart fix its that would replace those vars in my code so I could actually type the way I want but get the good documentation/ high quality code corrected by the compiler ?
<andrewrk>
quite possible, if the rest of your parameters were not generic
zolk3ri has joined #zig
<andi3>
yes sure there are some cases where its not possible
Bas_ has quit [Ping timeout: 252 seconds]
andi3 has quit [Quit: Page closed]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
rom16384 has joined #zig
very-mediocre has quit [Quit: Page closed]
mahmudov has quit [Ping timeout: 256 seconds]
rom16384 has left #zig [#zig]
davr0s has joined #zig
<MajorLag1>
Early someone mentioned general purpose allocation. It comes up a lot, but I'm personally not finding I'm missing it. I think this is an advantage of zig's not having a default allocator; you just don't really need a single allocator to handle dozens of different use cases because you can choose a more appropriate one for every case. I use DirectAllocator when experimenting, but when I nail down how something works I'm always using a more
<MajorLag1>
uned allocation strategy. Between arenas, fixed-buffers, and my rpmalloc-inspired pooling allocator I don't really feel any need for something more general purpose. Just my 2c.
<dbandstra>
i'm personally using a custom thing which is a fixed buffer, with two allocators working as stacks on each end
<MajorLag1>
kinda like the Quake Hunk allocator, IIRC?
<dbandstra>
'free' does nothing, but you can do a 'mark' and 'clear to mark'
<dbandstra>
exactly haha
<MajorLag1>
If it was good enough for Carmack, it's probably pretty good.
<dbandstra>
yeah you can basically use one side for persistent allocations, and the other side for temporary stuff
<dbandstra>
well suited for a game where you don't need dynamic allocations (fixed max number of entities)
<andrewrk>
MajorLag1, that's good to know
<andrewrk>
the first real use case I've had for one is the allocator for coroutines, but I think that can be a pooling one
<MajorLag1>
Or if having an upper limit on allocations is acceptable. For instance, if you have a particle system at reach the limit of allocations, it's probably not a big deal to just not create any more particles.
<dbandstra>
yeah although when you run out of space for one thing you run out of space for everything
<MajorLag1>
only if you haven't separated the memory spaces by use.
<dbandstra>
yeah you would just allocate a particle system with room for N particles, inside the hunk
<MajorLag1>
right, and if allocating a new particle OOMs, just shrug and keep going.
<MajorLag1>
andrewrk, I haven't had to use anything with coroutines yet so I don't have any experience with them in zig. Isn't the allocator for a new stack or something though?
<andrewrk>
I need to do some experiments but here's my working understanding
<andrewrk>
an async function call can be guaranteed to not allocate memory under these conditions: 1. the async function is known at compile time. 2. the promise is awaited in the same stack frame/ coro frame as the async function call
<andrewrk>
further, most asyc function calls fit this category, although not all of them
<andrewrk>
the memory that is allocated is a single stack frame - the "coroutine frame" for the async function
<andrewrk>
so if you, for example, did this: while (true) { await async foo(); await async bar(); }
<andrewrk>
that looks like: alloc N bytes; free those N bytes; alloc M bytes; free those M bytes
<andrewrk>
there's probably a really efficient allocation strategy for this
<andrewrk>
sorry, in the above example there would be no allocations
<andrewrk>
but assuming that there was, it would still look like that pattern
<andrewrk>
for example if you had a hash table hashed on allocation size, it should be pretty efficient
<andrewrk>
because these N and M values are static and there are a relatively small number of async functions possible
<andrewrk>
the number of async functions is fixed at compile time; the allocation size is not determined at runtime
<MajorLag1>
Yeah, pooling allocator seems appropriate since you have fixed sizes. In mine I stole an idea from rpmalloc and align my spans of blocks on a po2 boundary, so I can find the span a block belongs to with a single bitwise and.
dbandstra has quit [Quit: Leaving]
Ichorio has quit [Ping timeout: 264 seconds]
hooo has quit [Ping timeout: 252 seconds]
mahmudov has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]