ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<donpdonp>
ive gone through the ticket item and see how to declare all kinds of pointers, but im assuming the argc in my example is the right type, and i need to construct a pointer inside gtk_init()
<donpdonp>
im not sure how to state &argc to satisfy ?[*]c_int
kristate has quit [Remote host closed the connection]
Hejsil has joined #zig
<Hejsil>
andrewrk living the dream that few can
kristate has joined #zig
<Hejsil>
Looking forward to lots of progress on Zig :)
<andrewrk>
:)
kristate_ has joined #zig
clownpriest has joined #zig
<clownpriest>
andrewrk, awesome!
kristate has quit [Ping timeout: 260 seconds]
<clownpriest>
i've only been playing with zig for a week now, but so far it feels like it's hitting a real sweet spot
<andrewrk>
happy to hear that
clownpriest has quit [Ping timeout: 260 seconds]
clownpriest has joined #zig
davr0s has joined #zig
<bheads__>
andrewrk, I have a small D application I want to rewrite (it works fine, but the GC is being a PITA) thats released in production. Right now C/C++ seems like my only viable option, but I hate C++ and I am dreading writing in it again. What kinda of state is Zig in for production projects? Maybe released in a month or two...
<andrewrk>
bheads__, I can't recommend zig in production until 1.0.0
<bheads__>
damn...
<Hejsil>
andrewrk, where does Zig do the layout for extern structs?
<andrewrk>
bheads__, I am curious though, what in particular is being a PITA about the gc?
<bheads__>
the D GC cant compact or minimize
<andrewrk>
Hejsil, LLVM respects C ABI for structs
<Hejsil>
Aah, right
<andrewrk>
I believe right now there is actually no difference between extern structs and normal structs. it's just "zig reserves the right" sort of thing
<bheads__>
The app I have process large FASTQ files and does lots of network IO to our back end at curiogenomics
<andrewrk>
the struct/union code is a mess. I really need to revisit how all that works
<bheads__>
So after processing a few files it sits there eating 500mb
<bheads__>
and the std lib hides all of its memory usgae so I really dont know if its a leak or just a bad GC
<andrewrk>
Hejsil, there's a class of bugs/issues that will never really need to be in stage 1 - so if it's possible to wait until the self hosted compiler comes out, then we don't have to maintain 2 implementations of it
<andrewrk>
e.g. the std lib / self hosted compiler does not need that feature in order to build
<Hejsil>
Righto
<andrewrk>
but I mean don't let that stop you if you see a reasonable way to do it
<andrewrk>
I think for #1072 you would be pioneering some new code - I don't think any feature like this exists yet
<Hejsil>
Well, extern unions get all the features of normal unions when I tweak the type checking :)
<Hejsil>
It's just, that I need to make sure the layout is right so I can generate a header
<andrewrk>
I think that is a matter of a few things:
<andrewrk>
make sure the LLVM type gets generated correctly in resolve_union_type
<andrewrk>
make sure constants get generated correctly, in render_const_val
<andrewrk>
make sure the instructions that depend on struct layout in codegen.cpp are correct, e.g. IrInstructionStructFieldPtr or equivalent for unions
<andrewrk>
and then update the generate .h file code (that will be the easiest)
<Hejsil>
Well, couldn't easily wrap my head around resolve_union_type, and if it requires a rework anyways, then I'll leave it for now
<bheads__>
So far I dont see anything missing in zig just need: argument parsing, process spawning, file io, socket io, threading, mutexes, (I was using json for config and a db but I can roll my own format), zlib (gzread) and https post (I am using win api and curl)
<andrewrk>
bheads__, ah, yeah, it's too bad zig isn't stable yet, because it is particularly well suited for doing these kind of operatings while maintaining a low memory overhead
<bheads__>
oh and protobuf (but I would just use protobuf-c and convert that to zig..)
<bheads__>
is there an estimate on 0.3?
<andrewrk>
bheads__, yes, mid-september
<andrewrk>
the day that llvm releases 7.0.0, I merge llvm7 branch into master and then fix bugs for 1 week. then release 0.3.0
<bheads__>
if zig fmt intended to help migrate 0.2 to 0.3
<bheads__>
is**
<andrewrk>
that's a good question. I could have a couple of special subcommands to zig that can help migrate 0.2 to 0.3
<andrewrk>
I'll make that decision when we're closer to that date
<bheads__>
I think go has a tool that does that
rain1 has joined #zig
kristate_ has quit [Remote host closed the connection]
darithorn has joined #zig
kristate has joined #zig
kristate has quit [Ping timeout: 256 seconds]
kristate has joined #zig
kristate has quit [Read error: Connection reset by peer]
<bheads__>
ah I see that moves the std lib into the lib folder in the build path
<bheads__>
sorry about the noise
<andrewrk>
no worries
<andrewrk>
I don't mind questions, especially when the documentation is so incomplete
kristate has joined #zig
kristate has quit [Ping timeout: 245 seconds]
rlp10 has joined #zig
<bheads__>
thanks
donpdonp has quit [Read error: No route to host]
kekkel has quit [Ping timeout: 260 seconds]
clownpriest has quit [Ping timeout: 260 seconds]
rlp10 has quit [Ping timeout: 260 seconds]
<very-mediocre>
Are booleans in zig just sparse ints like in C++?
<very-mediocre>
(or was it bytes)
<very-mediocre>
Looks like it, thanks anyway :]
<MajorLag1>
very-mediocre: a packed struct of booleans is a bitfield, but other than that I think so.
<andrewrk>
very-mediocre, in packed structs they are 1 bit
<very-mediocre>
I see
<andrewrk>
elsewhere they are guaranteed that @sizeOf(bool) == 1
<andrewrk>
I'm not sure I understand your question though
<very-mediocre>
In C++, iirc even for a struct of bools, each bool would use up at least 8 bits
<very-mediocre>
even in a packed struct, I believe
<bheads__>
I dont think there are any systems that can address a single bit, but you can address a byte
<very-mediocre>
In C++ you'd use a userland bitset implementation
<very-mediocre>
for packing bits into a primitive e.g. byte yourself
<bheads__>
correct, but looks like zig will do the addressing for packed structs
<very-mediocre>
I see, so I'll assume from that that there's no need for bitset implementation and the compiler takes care of it?
<bheads__>
thats what andrewrk suggest, I guess its not documented yet
<very-mediocre>
ok I see LLVM uses i1 to represent bool, that pretty much confirms it
<very-mediocre>
thanks!
<andrewrk>
very-mediocre, if you use `extern struct` you get C ABI layout. If you choose `struct` you get no layout or size guarantees other than that each field will be at least ABI aligned. If you choose `packed struct` then you get exactly the fields you choose, in that order, no padding, and when you take references to fields, the pointer has metadata that allows zig to do bit shifting
sg-james[m] has joined #zig
<very-mediocre>
I see
<very-mediocre>
Appreciate the detailed answer
dbandstra2 has joined #zig
Anilm3 has joined #zig
very-mediocre has quit [Ping timeout: 260 seconds]
very-mediocre has joined #zig
kristate has joined #zig
darithorn has quit [Remote host closed the connection]
fkaa has joined #zig
kristate has quit [Ping timeout: 264 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
AndrewLaFountain has joined #zig
<AndrewLaFountain>
Good day everybody. Where should I look if I want to help with documentation?
<andrewrk>
AndrewLaFountain, here
<andrewrk>
happy to answer questions
<AndrewLaFountain>
Thanks Andrew! I wish you well following your significant other around. I'm litterally doing the same, just from the west coast. Was there a specific moment of conception for zig, or was it more of a slow boil sort of idea\?
<andrewrk>
slow boil for sure
<AndrewLaFountain>
It's really well done. What would be the most effective spot for documentation? From what I can tell, we're going for doc generation from commented source?
<andrewrk>
the plan is to do it in only the self hosted compiler, and not in stage 1 (c++ compiler)
<andrewrk>
there is also the language reference
<andrewrk>
which is about half done
<AndrewLaFountain>
A perfect. Thanks a ton. I have to get back to the day job pretty soon, but I'll read through that issue page and the reference and see what I learn.
darithorn has quit [Remote host closed the connection]
<very-mediocre>
Got a potentially silly question...
<very-mediocre>
Is there a way to loop over a range, without having to reference an array?
<very-mediocre>
nvm, I'll use while
dbandstra2 has quit [Ping timeout: 260 seconds]
<t5c>
very-mediocre: what about for (array) |item| { ... } ?
<very-mediocre>
that's in relation to an array
<bheads__>
I think he was ask for something like for (0..10) |i| { }
<very-mediocre>
Yep
<very-mediocre>
It seems like it's a design decision not to have traditional `for` loops in favor of `while`
<t5c>
oh, ok. now I get it ;)
<very-mediocre>
Apologies if these questions are a bit mundane
\\\\\\\\\\\ has joined #zig
<bheads__>
very-mediocre, did you see the while loop continuation express? while (i < 10) : (i += 1) {}
<very-mediocre>
I did not!
<andrewrk>
very-mediocre, there's an issue for this
<andrewrk>
although I think the resolution is that we're not going to have syntax for that\
<very-mediocre>
I see
<very-mediocre>
I like the confidence
<andrewrk>
this is one of those cases where we will sacrifice some convenience in order to keep the language simpler
<very-mediocre>
Part of the draw of this language is the confident design decisions, so I'm not complaining, for now anyway :)
<bheads__>
makes sense to me, plus it avoids the inclusive/exclusive issue
<andrewrk>
however, there is one more thing which may cause zig to have this ability after all, and it's how we end up implementing generators with coroutines
<clownpriest>
the simplicity of the language is so incredibly valuable
<clownpriest>
anything it takes to prevent becoming c++ (or dare i say rust), is worth the immediate convenience that sugarry syntax brings
<bheads__>
or what happened to D
<clownpriest>
yeah D is a sad story, been following it for years, really hoping it would eventually make it out of the weeds....so sad
<very-mediocre>
That's what drew me. I kind of escaped from C/C++ years ago and never found a more modern replacement
<bheads__>
yeah, to bad I have production code and web sites running on it
timetoplatypus has left #zig [#zig]
<very-mediocre>
What are you referring to wrt. to D. The GC dependency?
<andrewrk>
rest assured I consider language simplicity one of the main features of zig
<clownpriest>
:)
<bheads__>
the GC and stdlib and shared is killing me every day in D
<andrewrk>
what's "shared"?
<bheads__>
a nightmare
<bheads__>
it was an attempt to mark data as shared for concurrency
<bheads__>
it was half baked and never finished
<andrewrk>
oh interesting
<andrewrk>
I need to study this because I have some similar ideas about how to aid concurrency with zig
<bheads__>
its really hard to do right
<andrewrk>
agreed
<very-mediocre>
I think you're on the right track with async/await and some kind of green threads backend for the multiplexing
<very-mediocre>
or just threads, not necessarily green
<bheads__>
yeah you need the full gambit of threads fibers and coros
<clownpriest>
whatever the solution is, it would be nice if it's amenable to static analysis for race conditions
<andrewrk>
clownpriest, 100% agreed
<very-mediocre>
I've only ever seen that done in Rust
<andrewrk>
I believe go has a high quality race detector too
<very-mediocre>
I'm sure there's something about async/await that's amenable to analysis though, at some point you have to `reduce`
<bheads__>
there is also languages like pony that promise high concurrency but safe
<very-mediocre>
golang's approach reminds me a bit of linting, seems to catch some common gotchas
<clownpriest>
doesn't pony have a runtime tho? if there's a runtime tracking all dynamic memory allocations then that's different than the compiler being able to track lifetimes statically
<bheads__>
not sure, have not dived into
<clownpriest>
andrewrk, what are your thoughts on RAII style scoped dynamic memory?
<bheads__>
its very much a lite version of lifetime tracking
<clownpriest>
interesting
<bheads__>
scope int* x = new int; // will call delete x when it leaves scope
<bheads__>
of course it doesnt work at all with the stdlib, so kinda useless as a language feature
<clownpriest>
lol
<very-mediocre>
Lifetime annotations are one of the worst things about Rust
<clownpriest>
yeh it's pretty intense
<bheads__>
I do like the idea of lifetimes, but rust takes it to far
<very-mediocre>
I don't know if it's because of the obnoxious syntax or if the idea itself is just cumbersome
<very-mediocre>
A comment about it from hackernews stuck with me: "this is a case of the cure being worse than the illness"
<andrewrk>
very-mediocre, let's focus on working on zig rather than trash talking other languages
<very-mediocre>
Hey I'm not trashing it, I like Rust
<very-mediocre>
but the lifetime annotations are not for me as I was looking to lower the amount of mental load that goes towards writing the code
<andrewrk>
same here
dbandstra2 has joined #zig
<very-mediocre>
I would legitimately trash very few languages, the world of programming is in a pretty good state now
<andrewrk>
clownpriest, hm I'm not sure I have a general answer to your question. If you can point to some specific code, I may have an opinion on how the best way to write that would be (whether with RAII or otherwise)
<andrewrk>
very-mediocre, thanks. I didn't mean to offend, I just want to make sure that as we get an influx of new community members, we can keep the vibe healthy and positive
<clownpriest>
i guess one idea is that structs have destructors, so like, all structs have their deinit() called on scope exit, and it's the struct's responsibility to have something senible done to the memory they own in that deinit() call
<clownpriest>
something above and beyond depending on the programmer to remember to defer struct.deinit()
<andrewrk>
clownpriest, the downside of that is that we would give up "no hidden control flow" - that is - if you see a struct initialized, you have to go read the definition to find out if any code runs at scope exit
hoppetosse has joined #zig
isd has joined #zig
<clownpriest>
right, true
<very-mediocre>
andrewrk I understand, tonality doesn't convey well on the net
noonien has quit [Quit: Connection closed for inactivity]
<andrewrk>
whereas, currently in zig, if you don't see a function call, you can be sure control flow is contained entirely within the code you are observing
<clownpriest>
couldn't you make the argument that stack allocated variables get handled in with unseen control flow on scope exit tho?
<clownpriest>
isn't that part of the OS?
<andrewrk>
add $sp, 0x16 is hardly hidden control flow
<clownpriest>
right lol
<dbandstra2>
andrewrk: has there been any consideration of making `const` pointers "deep" in zig?
<andrewrk>
dbandstra2, probably not. can you elaborate?
<dbandstra2>
andrewrk: i can't remember if there was some fatal flaw with that idea in c/c++
<dbandstra2>
like it seems somewhat weird that ArrayList.deinit takes a const* self, but it has a side effect (self.allocator is not const)
<dbandstra2>
although i guess that's sort of ok since allocator is something that is created outside and passed in, not something "owned" by the array list
very-mediocre_ has joined #zig
<andrewrk>
I see
<andrewrk>
I don't think this will change. if you consider the simplest case: var x: i32 = 1234; const ptr = &x; ptr.* += 1;
<andrewrk>
this all makes sense. I don't see how it could be different
very-mediocre has quit [Ping timeout: 260 seconds]
<dbandstra2>
yeah i guess a deep thing would be a different keyword
<very-mediocre_>
sounds like immutable
<andrewrk>
const means immutable
<very-mediocre_>
Yes, I meant the "different keyword" suggested by dbandstra2 could be something like immutable
<very-mediocre_>
although maybe that's silly, I'm just brainstorming a bit :)
<dbandstra2>
i was just throwing that out there and hoping someone would inform me of a previously reached conclusion hehe
<dbandstra2>
i think the reason it doesn't always work in a low-level-ish language is that there's sometimes a field buried in a struct which still has to be mutable no matter what, because it's doing some kind of optimization
<very-mediocre_>
Not that JavaScript is the greatest language on the planet, but in that realm it's been accepted that deep immutability is a user space thing
<very-mediocre_>
i.e. immutable.js
<very-mediocre_>
and lots of Object.freeze and similar things
byronh has joined #zig
<very-mediocre_>
andrewrk and all other contributors: thanks, I love zig
<very-mediocre_>
I wanted to say that before leaving
<andrewrk>
very-mediocre_, cheers! come by any time for questions or demos
<very-mediocre_>
👍
very-mediocre_ has quit [Quit: Page closed]
<hoppetosse>
andrewrk: just popped in to say congratulations and good luck with the big plunge into full-time Zig!
<andrewrk>
thanks hoppetosse
<hoppetosse>
I haven't been very active due to university and work, but I hope to be able to dive deep in the summer =)
<andrewrk>
looking forward to it
<andrewrk>
the language will be a little more stable by then
byronh has quit [Ping timeout: 240 seconds]
byronh____ has joined #zig
<hoppetosse>
Pointer reform was a pretty big deal
Ichorio has quit [Ping timeout: 240 seconds]
<hoppetosse>
I didn't want to pick up tick again before that was through
bavier` has joined #zig
<andrewrk>
I expect to finish the pointer reform issue today
<andrewrk>
but not null terminated pointers yet
<bavier`>
hello zig folk. Just wanted to say, as a compiler nerd, contributor to GNU Guix, and supporter of bootstrappable.org, I appreciate your commitment to the Zip bootstrapping process
<bavier`>
s/Zip/Zig
<andrewrk>
bavier`, I think you are the first one to appreciate this particular thing. happy to hear that :)