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/
fengb has quit [Ping timeout: 256 seconds]
M948e5[m] has joined #zig
<M948e5[m]> hi. i have no programming experience but zig looks promising. is it possible for me to start learning zig or should i wait for 1.0, or just learn something else in the meantime?
<daurnimator> If you have no programming experience then zig might not be the best place to start...
<scientes> M948e5[m], start with C
<daurnimator> no.... don't do that either. start with a scripting language so you learn condition, control flow and object abstractions. then move to something like C or Zig where you have to think about memory
<scientes> oh ok
<scientes> python or ruby then
<scientes> or lua
<daurnimator> yep; those would be fine choices. M948e5[m]^
<scientes> I just quickly ditched those because I was interested in how computers worked
<M948e5[m]> lua? i used to fiddle around with that back in my CS:S days
<scientes> but i guess i still pull out ruby when perfection is not needed
<scientes> the problem with lua is that is had bad backwards compatibility and the alternate implementation have stuck to lua 5.1, which isn't compatible with lua 5.3
<scientes> ruby and python (especially) are the mainstream ones
<daurnimator> scientes: which doesn't really effect learning it....
<daurnimator> M948e5[m]: do you have a particular task you want to complete?
<M948e5[m]> allright, should i focus on one of them or try learning both the same time?
<M948e5[m]> at
<M948e5[m]> no, but i want to understand computers better
<daurnimator> how did you find/pick zig?
<M948e5[m]> i am naturally inclined to find the best and newest approaches to doing stuff, and zig looked the part
<scientes> zig's biggest influence comes from C
<daurnimator> zig's biggest influence is the LLVM IR :P
<scientes> well yeah that is true
<M948e5[m]> how would you go about learning ruby/python if you were me? can you vouch for any good resources, free or paid?
<daurnimator> M948e5[m]: maybe "learn python the hard way"
<scientes> and there is no reason to pay for anything
<scientes> except a GOOD book, but those are few
<daurnimator> scientes: ehhhh. i disagree. for entry level stuff paid books are usually better. but medium/advanced you shouldn't be paying for anything
<scientes> K&R C is a good book, but most good books are for more advanced stuff
<M948e5[m]> are you taking libraries into the equation there?
<scientes> TAoCP is a good book
<M948e5[m]> then again, doubt my local library has anything from the recent millennia
<scientes> libraries buy really horrible books
<scientes> although I have seen somewhat recent stuff at libraries
<scientes> depends which library
<daurnimator> M948e5[m]: https://learnpythonthehardway.org/python3/ <-- I think the first chapter or two are free.
<M948e5[m]> i found a pdf of the whole thing. see you in a couple (months)?
<daurnimator> M948e5[m]: k. just make sure you have the python3 edition not the python2 edition.
<M948e5[m]> ah, crucial difference
<M948e5[m]> i found it. thanks guys
fengb has joined #zig
fengb has quit [Ping timeout: 256 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 258 seconds]
lunamn has quit [Ping timeout: 248 seconds]
Kingsqueee has quit [Ping timeout: 248 seconds]
lunamn has joined #zig
marmotini has joined #zig
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 245 seconds]
<andrewrk> I'd like to think that zig is a reasonable choice to learn system programming
<daurnimator> andrewrk: it is.... (well at least it will be once we have more docs). but that user sounds like they want an intro to programming as a whole. They're not going to find many books/tutorials/stack overflow answers for the programming basics in zig.
<andrewrk> yeah that's a good point. When you're learning programming best to choose a mature language and a compiler with fewer bugs
<andrewrk> And docs and books and stack overflow answers
<daurnimator> andrewrk: copy ellision part 1 ready tomorrow? :)
ltriant has quit [Quit: leaving]
<andrewrk> daurnimator, I'll try! I don't have any behavioral tests passing yet. I have a stripped down test_runner.zig producing a .o file and now i'm working through the regressions in compiler_rt and zig's libc
<andrewrk> I need to figure out what to call that, now that it's renamed to std/special/c.zig. "zig's multi-target libc" doesn't quite explain that llvm produces library calls that depend on these functions
<daurnimator> How is it different to compiler_rt?
<andrewrk> it's the one that has memcpy, memset, and those other libc functions
<andrewrk> compiler_rt is unconditionally required as a dependency of any zig object file
<andrewrk> libc is only needed if not building against a system libc
<andrewrk> for example in freestanding mode
<daurnimator> that's... weird? does llvm have special code for emitting libc calls if it detects you're linking libc?
<andrewrk> it unconditionally emits lib calls
<andrewrk> http://llvm.org/docs/LangRef.html#llvm-memcpy-intrinsic this just calls a symbol named `memcpy`
<andrewrk> and optimizations can (and do in practice) turn loops into memcpy intrinsic calls
<daurnimator> I thought that sort of thing (memcpy) *was* what compiler_rt contained
<andrewrk> llvm also emits lib calls for certain other stuff which is in compiler_rt
<andrewrk> basically the reason they're different is that libc is swappable; compiler_rt is non-negotiable
ki9a has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 248 seconds]
kristoff_it has joined #zig
Ichorio has joined #zig
marijnfs has joined #zig
Ichorio has quit [Ping timeout: 248 seconds]
kristoff_it has quit [Ping timeout: 248 seconds]
Vexu has joined #zig
marler8997 has quit [Ping timeout: 256 seconds]
very-mediocre has joined #zig
alexander92 has joined #zig
Vexu has quit [Ping timeout: 256 seconds]
<very-mediocre> maybe i'm missing something, is there a concise way to unwrap an optional and use it in a boolean expression? i.e. if(optional_idx != null and val < vals[optional_idx]) {...}
<very-mediocre> unwrapping it prior to using it gets messy if the logic is a bit complex
<daurnimator> very-mediocre: does this work? if (optional_idx) |i| if (v < vals[i]) { .... }
<very-mediocre> yes but it gets real ugly when you have a more complex scenario with lots of "else"
heitzmann has joined #zig
Vexu has joined #zig
<BitPuffin> andrewrk: how do you feel about having /**/ comments that are allowed to begin and end only on the same line. Sometimes that's useful for commenting out an argument or something like that
<BitPuffin> I agree that they shouldn't span multiple lines
marmotini_ has quit [Ping timeout: 248 seconds]
knebulae has quit [Read error: Connection reset by peer]
Vexu has quit [Ping timeout: 256 seconds]
heitzmann has quit [Quit: WeeChat 2.5]
heitzmann has joined #zig
Vexu has joined #zig
Vexu has quit [Ping timeout: 256 seconds]
marmotini_ has joined #zig
alexander92 has quit [Ping timeout: 244 seconds]
alexander92 has joined #zig
Akuli has joined #zig
halosghost has joined #zig
halosghost is now known as hg
rain2 has quit [Quit: WeeChat 1.6]
Vexu has joined #zig
marijnfs has quit [Quit: WeeChat 2.4]
Vexu has quit [Quit: Page closed]
alexander92 has quit [Ping timeout: 272 seconds]
fengb has joined #zig
<fengb> For the C devs out there, can zig fmt generate a parse error for the && operator? I always stare at it for awhile
<hg> how do you mean?
<fengb> zig fmt: "if (foo && bar) return;" => "if (foo & &bar) return;"
<fengb> I think that's a bug because the actual compiler gives a helpful hint
<fengb> "error: `&&` is invalid. Note that `and` is boolean AND."
<hg> mm
fsateler has quit [Ping timeout: 244 seconds]
fsateler has joined #zig
tgschultz has quit [Ping timeout: 272 seconds]
<SamTebbs33> fengb: Would it not generate `if (foo and bar)` instead of being a parse error?
alexander92 has joined #zig
<alexander92> what do zig people think about implicit impor
<alexander92> e.g. is it possible to remove quallifcation for all fields of import
<andrewrk> BitPuffin, probably not going to do that - in order to keep the language small & simple we have to give up a lot of miscellaneous things
<andrewrk> fengb, yeah can you open an issue?
fengb has quit [Ping timeout: 256 seconds]
st4ll1 has joined #zig
<andrewrk> this might be one of the most "serious" zig projects in the wild: https://github.com/kristoff-it/redis-cuckoofilter
fengb has joined #zig
<fengb> andrewrk: sure, I'll try to take a stab at it later this week too
<andrewrk> fengb, I think we can make it a parse error with a helpful error. even though `a & &b` produces valid zig AST, it will always be a semantic analysis error
<fengb> The parser actually throws the error so it's zig fmt that's doing something different. It does "handle" || correctly though
<fengb> Does zig fmt and stage2 share a parser?
<andrewrk> yes
<andrewrk> the source is in std/zig/*
<andrewrk> here's a good use case for using zig to make a wasm node.js module: https://github.com/websockets/utf-8-validate
<andrewrk> this node.js module has to compile .c code when you npm install it. this is problematic on windows and can fail in some weird ways depending on how the c compiler is configured
<andrewrk> but if this were written in zig and compiled to wasm, the wasm could be uploaded to npm and then it would work everywhere without depending on system c compiler
<fengb> https://github.com/ziglang/zig/issues/2660 I'm probably glossing over the complexities >_>
<fengb> Oh, || is a real operator; that's why it's working. Would it be okay to add a fake operator just for the parser?
marmotini_ has quit [Ping timeout: 246 seconds]
porky11 has joined #zig
marijnfs has joined #zig
<andrewrk> I think you can look at how stage1 parser handles it
<fengb> Ah I see it. Thanks
st4ll1 has quit [Ping timeout: 245 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 244 seconds]
<marijnfs> what is a good way to ignore a return value?
<marijnfs> i just want to pop some values
fengb has quit [Ping timeout: 256 seconds]
<very-mediocre> _ = somethingThatProducesReturnVal();
<marijnfs> very-mediocre: ah, i was trying that with a const in front, i thought i remembered something like that
Vexu has joined #zig
<marijnfs> thanks
<very-mediocre> :]
<marijnfs> do you perhaps now how i can get an executable in a fixed place in the build script?
<very-mediocre> sorry, I don't
<donpdonp> exe.setOutputDir("."); is what I do
st4ll1 has joined #zig
<donpdonp> which puts app and app.o in the project root. so its a bit messy but its the best ive found.
<marijnfs> donpdonp: nice, that works
<marijnfs> yeah i can live with that
Ichorio has joined #zig
alexander92 has quit [Ping timeout: 248 seconds]
<marijnfs> i need to repeatedly allocate some memory and free it for a function, ideally I would keep it mapped and just grow the memory when needed
<marijnfs> which allcoator does that?
very-mediocre has quit [Ping timeout: 256 seconds]
<scientes> marijnfs, stack allocation does exactly that
<scientes> you just have to make sure the stack is big enough
<mikdusan> heap.ArenaAllocator
<scientes> arena is good too
<marijnfs> does the arena allow for freeing indivivual allocs too? or is it more for just allocatign and then freeing it all
<scientes> freeing it all at once
<scientes> but the arena could really be generalized into a stack allocator
<mikdusan> marijnfs: if i'm not mistaken, any individual free's using arena are just no-ops
<scientes> I've have proposed this, but arena allocator is already so much better than C that no-one is really listening
<scientes> (which is fine)
<marijnfs> scientes: how do i put a certain size array on the stack? should i use the {0} ** something syntax?
<scientes> alloca was removed from zig (and for some good reasons)
<scientes> I think the correct solution is to have a stack allocator that is as fast as stack allocation, but uses a differn't stack.
<scientes> but there just isn't enough interest in doing it the super-fast way for that to happen now
<scientes> as to do it the super-duper-fast way requires quite a bit of tool-chain work
<scientes> but just generalizing the existing arena allocator into a stack allocator would be a good idea
<scientes> and could be done quite easily
<marijnfs> scientes: as in, allowing it to free indivitual elements?
<scientes> or rather, it probably should be a differn't new allocator
<scientes> marijnfs, no, only allowing freeing the most recently allocated elements
<marijnfs> scientes: yeah i see
<marijnfs> and only grow if needed
<marijnfs> would it need a popfree or something?
<scientes> you would use the exiting allocator interface
<scientes> except it would be UB to free in the wrong order
<scientes> ehhh, that would be problematic....
very-mediocre has joined #zig
<scientes> no, it could check it because you pass a pointer
<marijnfs> scientes: you need to keep track of whats allocated, and then check if the free is that last element
<scientes> so it can error out if you do it wrong
<marijnfs> but then you need memory for that overhead too
<scientes> marijnfs, no you only check the current stack pointer and the start stack pointer
<scientes> and when free is called you have then length, and check if the pointer plus the length is the stack pointer
<marijnfs> ah the to be freed + len should be same
<marijnfs> yeah
<scientes> also you need to keep the shadow stack pointer to avoid unnecessary mmap and munmap calls to DirectAllocator
jjido has joined #zig
wootehfoot has joined #zig
<marijnfs> yeah i owuld only unmap when deinit is called
<scientes> yeah but they are just implementing arena allocator
<scientes> *then you are
<marijnfs> just grow if needed, with a double memory style, or just exactly what you need in memory
<scientes> oh i guess not
<marijnfs> could be a mode
<scientes> yeah that would be fine
<scientes> you could also add a "release memory" function
<scientes> which could be general for other allocators
<scientes> that doesn't take any arguments
<scientes> that calls munmap
<tyler569> ex:q!
<marijnfs> yeah would be useful
<tyler569> ack sorry
<marijnfs> o vim
<scientes> tyler569, not vim
<marijnfs> use emacs
<tyler569> lost in tmux over here haha
<scientes> marijnfs, i think you should keep it separate from the arena allocator, and guarantee a continuous stack
<scientes> *contiguous
heitzmann has quit [Quit: WeeChat 2.5]
heitzmann has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marijnfs> scientes: yeah for sure, would be dedicated to one thing
<scientes> well they are quite similar
<scientes> I think that would be great, and already much faster than C
<scientes> and later it can be figured out how to make it screaming fast
shritesh has quit [Quit: segfault]
<scientes> or rather implemented, because I know how to do it
_whitelogger has joined #zig
marmotini_ has joined #zig
<marijnfs> jej, my timsort seems to be working mostly
<marijnfs> i would like to make this allocator for it to make it faster
<scientes> submit as two differn't pull requests however
<scientes> just make the second depend on the first
<scientes> and make sure you have tests
Akuli has quit [Quit: Leaving]
wootehfoot has quit [Read error: Connection reset by peer]
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 272 seconds]
cameris has joined #zig
fengb has joined #zig
gamester has left #zig ["Leaving"]
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 248 seconds]
wilsonk has quit [Ping timeout: 245 seconds]
fengb has quit [Ping timeout: 256 seconds]
marmotini_ has quit [Remote host closed the connection]
vexu has quit [Ping timeout: 248 seconds]
hg has quit [Quit: WeeChat 2.5]
<marijnfs> scientes: yeah for sure, for now i'm trying to wrap my head around the allocator pattern
jjido has joined #zig
<scientes> yeah it got simpler recently, but more confusing
SamTebbs43 has joined #zig
very-mediocre has quit [Ping timeout: 256 seconds]
vexu has joined #zig
Ichorio_ has joined #zig
I_Right_I has joined #zig
Ichorio has quit [Ping timeout: 248 seconds]
st4ll1 has quit [Ping timeout: 248 seconds]
st4ll1 has joined #zig
<scientes> wow, debug llvm+clang is REALLY slow
<Sahnvour> it is indeed
<scientes> like i think it will be faster to rebuild llvm+clang than try building the llvm test suite with a debug version
st4ll1 has quit [Ping timeout: 258 seconds]
st4ll1 has joined #zig
<Sahnvour> are you building llvm with a debug build of llvm/clang ?
<scientes> no building the llvm test suite
<scientes> which is in addition to the in-tree test suite
<Sahnvour> okay
knebulae has joined #zig
Ichorio has joined #zig
Ichorio_ has quit [Ping timeout: 248 seconds]
cameris has quit [Quit: leaving]
fengb has joined #zig
SamTebbs43 has quit [Quit: Lost terminal]
Ichorio has quit [Read error: Connection reset by peer]
<marijnfs> i'm having trouble with @fieldParentPtr, somehow i don't get my struct back
<fengb> Are you passing the allocator pointer? If you pass the struct value, it'll break
<marijnfs> yeah, something like @fieldParentPtr(StackAllocator, "allocator", &stack_allocator)
<marijnfs> wait, i do before: var stack_allocator = sa.allocator
<fengb> Yeah that needs to be var stack_allocator = &sa.allocator
<marijnfs> wait that makes a copy and changes the pointer?
<marijnfs> ooew
<scientes> yeah it needs some more compiler errors
<fengb> I'd expect that to create a stack variable yeah
<scientes> but its still better than Linuxś container_of() macro already
<marijnfs> yeah that is tricky
<fengb> @fieldParentPtr only works on embedded memory spaces so any copying out of the struct will break
<fengb> I don't think I'm using the right terminology
<scientes> you are right
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fengb> Semi-related: better interface pattern -- https://github.com/ziglang/zig/issues/1829#issuecomment-501471033
<marijnfs> fengb: yeah i get the issue
<fengb> Oh I'm just using you as a guinea pig here :P
<fengb> It's definitely a confusing part atm
<marijnfs> fengb: but its gonna be hard to catch such errors
<fengb> The issue has an alternative pattern where we embed the implementation inside of the interface
<fengb> So instead of requiring a parent pointer, which is assumed, it's a child pointer, which is guaranteed
<fengb> And it lets you copy the interface struct around
<marijnfs> so reverse the embedding kind of?
fsateler has quit [Ping timeout: 246 seconds]
fsateler has joined #zig
<fengb> Hmm... there's an implicit dependency on the implementation's lifecycle. I wonder if it's possible for that allocator to "escape" the stack
<marijnfs> stack allocator seems to work
vexu has quit [Quit: WeeChat 2.5]
<marijnfs> if i have a var stack_alloc = &std.heap.FixedBufferAllocator.init(stack_buf).allocator;
<marijnfs> does that stack_alloc get freed after it goes out of scope?
kristoff_it has joined #zig
<fengb> Yes... but stack_alloc is just a pointer
<fengb> So the deallocation shouldn't really do much. Do you want to delete the actual buffer?
kristoff_it has quit [Ping timeout: 248 seconds]
<marijnfs> nah i defer delete that separately
<marijnfs> i'll push what i have now in a separate github, then i have to prepare some tests etc. But I need some help with making sense of the allocator
<marijnfs> if i don't make crazy errors
<marijnfs> bit the timsort seems about twice as fast for now
<scientes> marijnfs, did you see this ?? https://github.com/ziglang/zig/issues/2651
<marijnfs> nope
<scientes> not to say you have to imjplement it
<scientes> but it would be interesting
<marijnfs> i guess I like timSort becuase its time tested
<marijnfs> the default code runs a sort on random values, and compares the speed
<fengb> Shouldn't assume we want direct allocator
<fengb> Usually you allow any allocator to be passed in. Otherwise you'd be excluding runtimes like embedded or wasm (which can't use the direct allocator)
<scientes> wasm can support direct
<scientes> but yeah don't assume
<scientes> and needing an allocator is.....a problem
<marijnfs> fengb: true, it just gets a bit annoying to have to provide allocators to the sort
<scientes> that is why the current sort was chosen
<marijnfs> Isn't the directallocator always available?
<scientes> that is not the zig way
<scientes> the zig way is to always supply an allocator argument
<scientes> it is much more flexible
ltriant has joined #zig
<fengb> DA requires an OS backing. Bare metal embedded have no equivalent
karrick_ has joined #zig
<karrick_> Hello. Finished reading all of the Zig document
alichay has joined #zig
<karrick_> So much for my ability to type
<fengb> How much slower is in-place merge sorting?
<marijnfs> fengb: all tim implementations say it's not really worth it, but i could have a look
<scientes> fengb, there is another protocol to investigate https://github.com/ziglang/zig/issues/2651
<marijnfs> but you also need to allocate stuff for the run stack
<fengb> Alternatively, merge sort should require at most N (N = number of elements) additional memory right? Could we dynamically allocate this on the stack immediately?
<marijnfs> fengb: yes, but you still need an allocator
<fengb> Does zig have var-arrays on the stack?
<marijnfs> no you will kill the stack i think
<marijnfs> i have done that before
<fengb> Ah good point
<fengb> You know... I've never thought about stack much before working with zig
<scientes> fengb, no, alloca was removed from the language
porky11 has quit [Quit: Leaving]
karrick_ has quit [Remote host closed the connection]
st4ll1 has quit [Ping timeout: 268 seconds]
karrick_ has joined #zig
st4ll1 has joined #zig
marijnfs has quit [Quit: WeeChat 2.4]
karrick_ has quit [Remote host closed the connection]
karrick_ has joined #zig
karrick_ has quit [Remote host closed the connection]
karrick_ has joined #zig
karrick_ has quit [Remote host closed the connection]
I_Right_I has quit [Remote host closed the connection]
alichay has quit [Ping timeout: 256 seconds]
ltriant has quit [Quit: leaving]
husho has quit [Ping timeout: 256 seconds]
<scientes> fengb, distributed sorting.... http://sortbenchmark.org/TencentSort2016.pdf