ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
darithorn has joined #zig
<karlguy>
Just wanted to thank you guys for how great Zig is. It restores my faith in humanity that there are some people that understand what it means to create an viable alternative for C (unlike the crazy people at Rust) :)
<karlguy>
Also quick question, what's the use case of non-power-of-two primitive sizes?
<karlguy>
Besides bitflags, of course
<andrewrk>
hi karlguy
ofelas has joined #zig
<andrewrk>
non power of two sizes will still be power of 2 sizes if you look at, e.g, @sizeOf(u3)
<andrewrk>
they're used for 2 purposes right now
<andrewrk>
1 is to have a smaller maximum range, so that we can, for example make the operand to left shift have just the right amount of bits so that undefined behavior cannot be invoked
<andrewrk>
2 is for bit fields - if you put them in a packed struct
mahmudov has quit [Remote host closed the connection]
<karlguy>
Ok, got it. So if I had a bit field containing a u5 and a u3, would it occupy a byte of space?
<karlguy>
* in the future
<karlguy>
Or would this have to always be done in an unpacked struct
<karlguy>
Nevermind, that was a stupid question that I should have thought more about before asking. :P
<GitHub176>
zig/master e78b1b8 Andrew Kelley: self-hosted: basic IR pass2
karlguy has quit [Ping timeout: 240 seconds]
karlguy has joined #zig
quc has quit [Remote host closed the connection]
zolk3ri has quit [Remote host closed the connection]
_whitelogger has joined #zig
darithorn has quit [Quit: Leaving]
v1zix has joined #zig
dbandstra has joined #zig
v1zix has quit [Ping timeout: 252 seconds]
donzx has quit [Remote host closed the connection]
donzx has joined #zig
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
donzx has quit [Remote host closed the connection]
donzx has joined #zig
donlzx has joined #zig
donlzx has quit [Client Quit]
donzx has quit [Client Quit]
donlzx has joined #zig
beetcoin has joined #zig
<beetcoin>
hi, all.
<beetcoin>
Zig seems like a very cool project. I just heard about it
davr0s has joined #zig
Guests has joined #zig
Guests has quit [Ping timeout: 252 seconds]
<unique_id>
hi beetcoin. I'm enjoying it a huge amount after a very tiny adjustment period. I'm not returning to c++ :)
<beetcoin>
unique_id, indeed, my first comment after learning about Zig was: "wow, this is an ACTUAL C++, not a C++#$%^&
<beetcoin>
"
<beetcoin>
in the early days, the conceit was that C++ was, to most people, "C plus classes"
<beetcoin>
which is already a lame idea
<beetcoin>
then add 25 years of kitchen sinks and crazy ideas
<beetcoin>
Zig is a wonderful idea
<stratact>
it's still possible that Zig might implement some form of OOP either via inheritance or composition
<beetcoin>
I remember reading some O'Reilly book called "21st Century C" and was sorely disappointed by the quality of the book... when what we really wanted was basically what Zig promises
<beetcoin>
stratact I've yet to really play around with it, I might do it this weekend if I get a chance. I just watched the talk about "Perfect Software"
<beetcoin>
Does anyone know why it's called "Zig"?
<stratact>
andrewrk would definitely be able to tell you that :P
<unique_id>
stratact: open set polymorphism is important, no one should fault a language for trying to tackle that problem
<unique_id>
so it wouldn't surprise me if zig gains features in that area, if they are needed
<stratact>
I'm not faulting Zig for that, I'm just telling beetcoin that Zig will have some form of that because of the "C plus classes" comment
<unique_id>
badly worded on my part, I agree with you
very-mediocre has joined #zig
dbandstra has quit [Quit: Leaving]
<very-mediocre>
Not sure if this is a terrible suggestion: some way to cache comptime computed consts
<unique_id>
beetcoin: the industry definitely moved too far into the OOP design patterns gang-of-four camp :) - Also, I guess C++ should have gained destructive moves instead of adding rvalues and all of that, at this point there's just too many things that wouldn't be here were C++ designed from the ground up.
<unique_id>
redesigned*
<beetcoin>
agreed on all points
<very-mediocre>
unique_id: so true, Factories of Factories made me hate programming for a while
<beetcoin>
i would vastly prefer composition to inheritance. if the devs go with some kind of trait system based off static dispatch, that would probably be the best compromise
<beetcoin>
i've already heard talk of call graph analysis
<beetcoin>
so that fits in very well...
<very-mediocre>
beetcoin: have you seen composition in golang?
<very-mediocre>
it's basically struct embedding
<beetcoin>
i wrote one script in Go two years ago and got annoyed with GOPATH
<beetcoin>
so i know very little about it haha
<very-mediocre>
it's intuitive like inheritance, no need to explicitly access the component
<very-mediocre>
i see
<beetcoin>
I know it's fashionable to bash on Go these days
<very-mediocre>
it has a lot of flaws, but i think it nails composition and interfaces
<beetcoin>
I see, I'll have to look closer
<very-mediocre>
people always say "golang interfaces have problems" but I'd love to hear why and I've yet to find any specific objections
<very-mediocre>
just skim the 2 code blocks and you'll get it, it's very intuitive
<beetcoin>
that's perfectly reasonable to me
<very-mediocre>
right now in zig if you look at std.io for example, there's a lot of `self.stream.[whatever]`
<very-mediocre>
it's a bit clunky if you're writing a stream that wraps another stream
<very-mediocre>
`FileStream.stream.dosomething`
<very-mediocre>
you can't really say FileStream "is a" stream
<very-mediocre>
it "has" a stream
<very-mediocre>
but in golang you can do "is a" and "has a" even in composition
<very-mediocre>
anyway, I like this approach. Just my 2 cents
<beetcoin>
i see what you mean, yeah clunky
<very-mediocre>
tbf composition is clunky like that in almost all languages
<beetcoin>
good point
Bas_ has joined #zig
<beetcoin>
it's just that I've read and used Rust and tons of other approaches, and everything I read about Zig "scratches the itch" better than any of the others
<beetcoin>
I'm not aware myself of how many similar projects to Zig have been tried
<beetcoin>
but it's just so nice so far :)
<beetcoin>
I especially love no hidden flow control and the emphasis on no hidden allocations
<very-mediocre>
it is pretty great
<very-mediocre>
So far I've only toyed with it in my spare time, if I had consistent blocks of spare time I'd do something
<very-mediocre>
more than just toy
<very-mediocre>
I have a few personal niggles, e.g. I dislike `while (i < 5) : { i += 1}`
<very-mediocre>
and I'd love to have simplistic OOP
<very-mediocre>
but despite that I believe this is shaping up to be my favorite low level language
<very-mediocre>
imho continuation expressions are an unnecessary construct that adds very little
<very-mediocre>
while other things that were more valuable were left out on purpose for the sake of minimalism e.g. c-style for loops
<very-mediocre>
also `:` is a type indicator nearly everywhere else
<very-mediocre>
hope this is taken constructively, not as bashing. I love the language.
<beetcoin>
yeah hmm...
<beetcoin>
switch is vastly improved though
<beetcoin>
"else" is better than "default"
<beetcoin>
although it's common to bind as in a match to some name which could be used in the "else" case
<unique_id>
The continuation expression is what turns a while loop into a c-style for loop, though without the init part
donlzx has quit [Remote host closed the connection]
donlzx has joined #zig
ofelas has quit [Quit: shutdown -h now]
ofelas has joined #zig
donlzx has quit [Remote host closed the connection]
donlzx has joined #zig
<Bas_>
Yesterday I asked about reallocFn, but I actually still have a question about that.
<Bas_>
Does it act like the C realloc function? In that it tries to extend the current memory and if that fails allocates a new piece and copies the data over for you?
<Bas_>
Because I actually don't like that it does that magic for you. That means it's only useful for extending dynamic arrays/vectors and nothing else.
<Bas_>
In cases where you want to insert an element or do something different than appending you will want to reorder the data and the extra copy will only harm you.
tiehuis has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
donlzx has quit [Remote host closed the connection]
<tiehuis>
Bas_: that is going to depend on the allocator being used
donlzx has joined #zig
<Bas_>
Hmm...
<Bas_>
What I was thinking was that it should just try to extend the memory and if that's not possible return an error. So the caller can then do the alloc-copy-free dance.
<unique_id>
tiehuis: so an allocator could return an error every time an expansion fails, instead of allocating new memory?
<Bas_>
But if that's not explicitly (documented) in the interface people might not handle that case.
<unique_id>
You do make a good point Bas_. traditional realloc isn't efficient when inserting
<tiehuis>
if you look at std/mem.zig, realloc is only going to call the underlying reallocFn implementation and if that fails it will return an error
<tiehuis>
if your reallocFn didn't want to copy elements then it could, but yeah, it isn't specified in the top-level so wouldn't
<tiehuis>
work with the behaviour of other allocators at the moment as far as i'm aware
<beetcoin>
wait, what's the difference between realloc and reallocFn?
<tiehuis>
so an Allocator is a struct that has 3 user-defined functions, allocFn, reallocFn, freeFn
<tiehuis>
you create a new allocator by filling in those functions and you get some extra functions on top of that once implemented
<beetcoin>
Ah
<tiehuis>
the c allocator binding for example just uses malloc, realloc and free here
Ichorio has joined #zig
<beetcoin>
right, that's interesting
<tiehuis>
if you look at std/heap.zig that is where all the allocators are implemented
<beetcoin>
i was reading in there
<beetcoin>
so it keeps the entire heap in userspace but provides an interface for substituting different approaches or styles of allocation
<unique_id>
realizing that you haven't touched the mouse in hours is pretty cool :) "WHOAH what's that? A mouse! I forgot about that thing, cool!"
<beetcoin>
Zig is an ambitious project... with a lot of promise
<beetcoin>
kind of daunting actually
<beetcoin>
btw i take back what i said about runtime dispatch
<unique_id>
Give it a few days, it should become simpler than C to you. Though learning the zig standard library might take some time with the lack of documentation.
<unique_id>
or maybe more than a few days, I've followed the project on and off before committing
<beetcoin>
Well, I should say the person who should be daunted is the creator himself. A lot of pressure to get things right early
<Bas_>
He's got the right mindset imo.
<Bas_>
And I really feel like it has the potential to become great.
zolk3ri has joined #zig
<beetcoin>
i do too.
<beetcoin>
i haven't even used it but i'm falling in love the 'try'
<beetcoin>
the LAZIEST thing you can do is handle the error properly
<beetcoin>
i totally relate to the idea of wanting to throw out an entire library because the error handling is worrisome
<unique_id>
Maybe Linus will comment on zig at some point
<Bas_>
lol
<beetcoin>
well shit, i have to get on a plane "tomorrow". time to go to sleep. goodnight gents
<unique_id>
gn
<Bas_>
good night
davr0s has joined #zig
<Bas_>
I think Linus doesn't like type based aliasing.
<GitHub198>
zig/master 5f1aa35 Andrew Kelley: Merge pull request #1232 from BarabasGitHub/fix-array-list-insert...
<GitHub198>
zig/master fe98a2d Bas van den Berg: Add a copyBackwards to fix the broken insert methods for ArrayList.
<GitHub198>
zig/master a1cafa6 Bas van den Berg: Improve ArrayList insert unit tests.
andi3 has joined #zig
<GitHub123>
[zig] andrewrk closed pull request #1233: Replace loop in ensureCapacity with a std.mem.max for the new capacity. (master...remove-weird-loop-in-array-list) https://git.io/fNmUj
<andi3>
what if the difference between a struct with fn foo()... and a struct with foo: fn() ....I assume the second one is a function pointer?
<Bas_>
If I want to look into stack traces for windows, do I have to fiddle around in the compiler?
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<Bas_>
or is it all in std.debug?
<unique_id>
andrewrk: two tests in the documentation use the term "continuation expression"
<andrewrk>
ah
<unique_id>
andrewrk: also I think where it says "windows not supported" it's supposed to say "fuchsia not supported"
<andrewrk>
you're right
<andrewrk>
I think "continuation expression" means something else. maybe I can call it "continue expression"
<unique_id>
yes, that term is used once in the documentation
<unique_id>
:)
davr0s has joined #zig
<andi3>
I think I now know how allocators work and how zig currently handles interfaces
<andi3>
so if I have an Interface like Allocator and it has some function pointers
<andi3>
If I implement that interface in my custom struct I embed an Allocator struct and set those pointers accordingly and when someone expects to get an Allocator I just pass that member of my new struct
<andrewrk>
precisely
<andi3>
but now I have to deal with those function pointers and aren't function pointers less efficient than functions on a struct itself?
<andrewrk>
that's precisely the tradeoff that you make when you use interfaces
<andi3>
Like struct Foo { fn foo() ...} vs struct Foo { foo : fn ...} the second one always has to do the lookup
<andi3>
but if I had real interfaces I would not have to do that tradeoff
<andrewrk>
real interfaces use function pointers too
<andi3>
because than the Inferface would just demand, hey you should have a function foo
<andi3>
and as soon as Foo has foo() then is has this interface
<andi3>
and if Foo would not have foo then my compiler would shout at me
<andi3>
real interfaces use function pointers too - sorry I do not understand
<andrewrk>
I think what you are describing, zig has with duck typing
<andi3>
but you can't specify the type
<andi3>
I mean you can use TypeOff and assert
<andrewrk>
the point of an interface is that you can use the same machine code with multiple different implementations, which inherently requires function pointers
<andi3>
not if you statically dispatch, in that case the interface is just used as a guard at compile time
<andrewrk>
it sounds like you're talking about duck typing vs contracts
<andi3>
yes if that is the proper name
<andrewrk>
you want to be able to say that a parameter has to have a write() method, or a certain field, or something like that
<andi3>
I mean your allocators would certainly be better with constraints than with all the function pointers
<andi3>
yes
<andi3>
and not use reflection all over the place
donlzx has quit [Ping timeout: 276 seconds]
<andrewrk>
that is quite possibly the case
<andrewrk>
I don't consider the issue resolved
<andi3>
ok, how come the first allocators are implemented using const name = struct {} and then the StackFallBackAlloc is implemented using anonymous struct in some function and some ParentPtr I do not quite understand :(
<andrewrk>
for API convenience at the callsite
<andi3>
I do not really see the difference in any case I would have thought the other allocators would want to provide the same api convenience?
<andrewrk>
because they would get leaked when the function returned
<andrewrk>
but the stack fallback allocator knows that its lifetime can't last longer than the stack frame of the calling function
<andrewrk>
so its API can be more convenient
<andi3>
ok thanks for the explanation I understand a bit more of it, what I still miss is why do you do that `const self = @fieldParentPtr(Self, "allocator", allocator);` it gives a pointer to the struct you (this) are currently in but isn't that equal to this anyway?
<andrewrk>
when you have const Foo = struct { field: Field }, and you have a *Field pointer, you can get a *Foo pointer
<andrewrk>
because if you know where field is in memory, you can do math to calculate the base of the struct
<andi3>
yes I just do not get why this is needed in the StackFallbackAllocator functions because to me it seems as if `this` was already the same of the Parent pointer of the allocator field of allocator
<andrewrk>
this is the same as all the other allocators - they all use @fieldParentPtr in their alloc, realloc, and free functions
<GitHub194>
zig/master ed3181f Andrew Kelley: Merge branch 'eduardosm-extern-return-small-struct'
<GitHub194>
zig/master f78d4ed Andrew Kelley: add an assertion to the test
<GitHub194>
zig/master 722b9b9 Eduardo Sánchez Muñoz: codegen: Store returned value if type is 'handle_is_ptr' and function is not 'first_arg_ret'....
<GitHub84>
[zig] andrewrk closed pull request #1234: codegen: Store returned value if type is 'handle_is_ptr' and function… (master...extern-return-small-struct) https://git.io/fNmYu
<winksaville>
I just ran the compiler tests and it took 18min30s is there a way to run only a specific test?
<andrewrk>
winksaville, there are a few options
<andrewrk>
I just added this option: -Dskip-release
<andrewrk>
this makes all the tests complete in ~5 min for me
<andrewrk>
but it's still quite comprehensive
<andrewrk>
there's also -Dtest-filter=fooo which will run only tests matching "fooo"
<andrewrk>
also each type of test has its own step. for example you can run only the compile error tests with the `test-compile-error` step instead of the master `test` step
<andrewrk>
winksaville, stage2 is under construction; it is not an operational compiler
<winksaville>
ok, the README.md says "...which can be used for testing and developement." so I wasn't sure :)
zolk3ri has quit [Ping timeout: 276 seconds]
<andi3>
so now you've implement alloc for the allocator of the ArenaAllocator and use ParrentPtr to get to the files of the struct its embedded in, but mem.Allocator already has an alloc() func so if you call alloc on the allocator member of ArenaAloc e.g. what is it even going to do? I think zig has already gone to far :D
<andrewrk>
winksaville, yep, for example `zig fmt` is only available in stage2
<winksaville>
andrewrk, so it has build-exe, build-lib, build-obj and the targets list is "complete" do those commands work?
<GitHub56>
zig/master 29c756a Andrew Kelley: docs: correct some misinformation
<andrewrk>
build-obj is under construction. I don't even know what those other commands will do
<andrewrk>
(until I make further progress)
zolk3ri has joined #zig
<andrewrk>
andi3, this is what it looks like if you don't have any OOP features and you try to do some amount of OOP stuff
<andi3>
I don't get it and I'm really afraid tbh
<winksaville>
andrewrk: I ran "time bin/zig build --build-file ../build.zig --prefix $(pwd)/stage2" it took 6s, I run it again it still takes 6s. Compared to ninja which takes 20ms to build zig the second time, are there plans to speed up and parallelize zig build?
<andrewrk>
yep, lots of them
<andrewrk>
zig currently does absolutely zero caching
andi3 has quit [Ping timeout: 252 seconds]
<andrewrk>
so that's how time it takes to rebuild everything, including compiler_rt.o and builtin.o
<andrewrk>
in fact in that command it's buidling compiler_rt.o and builtin.o twice - once for the build script and once for building stage2, which I believe is the default step
<winksaville>
andrewrk: sg, is stage2 designed to be parallelized?
<andrewrk>
yes it is. from the very beginning
<andrewrk>
it's also designed to be a long lived process, caching in memory
<andrewrk>
so you don't so much as perform a build, as you do establish an ongoing build, which will keep your targets up to date in response to file system notifications
<GitHub180>
zig/master 91636f1 Andrew Kelley: Merge pull request #1237 from BarabasGitHub/fix-reallocating-from-0...
<GitHub180>
zig/master c021a44 Bas van den Berg: Fix aligned reallocation from zero size.
<GitHub180>
zig/master 8be6c98 Bas van den Berg: Create unit test that tests aligned reallocation.
<Bas_>
yay
donlzx has joined #zig
andi3 has joined #zig
<andi3>
at which point is DirectAllocator.alloc ever called ? in the tests only DirectAllocator.allocator is used
<andi3>
ah so you have your directAlloator with en allocator member which has the alloc func of Directallocator set as its allocFn which is called by the alloc fn ob allocator, easy
unique_id has quit [Ping timeout: 240 seconds]
unique_id has joined #zig
donlzx has quit [Quit: Leaving]
<andi3>
and when you call the alloc of the allocator of DirectAllocator then it calls allocFn which calls alloc of DirectAllocator which gets the pointer to direktAllocator and uses its members to do some stuff, still horrifying
<Bas_>
how do I assert that something returns an error?
<andrewrk>
Bas_, std.debug.assertError
<Bas_>
ah ok
<andrewrk>
you can do it manually with if and @panic