ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
redj has quit [Read error: Connection reset by peer]
cenomla has quit [Quit: cenomla]
mal`` has quit [Quit: Leaving]
redj has joined #zig
mal`` has joined #zig
<MajorLag_>
The regular array initialization syntax seems fine to me. Initializing a mutable slice at compile time was a bit odd, in the end I had to that strange label/break construct. I think that could be improved, for instance, it could actually say 'comptime' somewhere.
cenomla has joined #zig
cenomla has quit [Quit: cenomla]
redj has quit [Read error: Connection reset by peer]
<GitHub197>
zig/master b71a56c Andrew Kelley: cleanups that I meant to put in the previous commit
redj has joined #zig
wilsonk has quit [Remote host closed the connection]
wilsonk has joined #zig
arBmind has joined #zig
redj has quit [Read error: Connection reset by peer]
skyfex has joined #zig
redj has joined #zig
arBmind has quit [Quit: Leaving.]
arBmind has joined #zig
redj has quit [Ping timeout: 240 seconds]
redj has joined #zig
jfo has joined #zig
jfo has quit [Quit: WeeChat 1.9.1]
MajorLag_ has joined #zig
<MajorLag_>
Is there code somewhere that demonstrates usage of @setDebugSaftey? I have a situation where some math divides by zero with floats and would prefer to just disable it for those two lines.
<MajorLag_>
Nevermind, I worked it out.
<lqd>
MajorLag_: maybe something like @setDebugSafety(this, false);
<MajorLag_>
yeah, that's what I'd worked out. Enclosing those two lines in a block and throwing that at the top seems to have done it.
skyfex has quit [Quit: Page closed]
aiwakura has quit [Quit: Ping timeout (120 seconds)]
aiwakura has joined #zig
<MajorLag_>
I don't understand the reasoning behind having to cast enum types. If I explicitly declare enum(usize), I later have to cast it to usize explictly. If I need to then use that value as a u16, I'd then have to double cast it? It seems to me that if I explicitly declare an enum as a type the casting should be implicit.
<andrewrk>
MajorLag_, maybe we can get rid of the double cast
<andrewrk>
well, here's the deal
<andrewrk>
casting from an enum to its integer tag type is a safe operation, guaranteed to work
<andrewrk>
casting from an integer type to a smaller one can cause overflow
<andrewrk>
I want that to be clear
<MajorLag_>
I guess I don't see how having to explicitly cast to the type you already specified when you created the enum helps with that. Granted, if I try to use an enum(usize) as a u16 I should have to cast it, but if I use it as a usize (for instnace, as an array index) then I don't see how you're ever telling the programmer something they don't already know.
<andrewrk>
you're making the point that if the programmer specifies enum(usize) then the programmer intends to use the type interchangeably with a usize
<andrewrk>
that's currently not what zig understands the programmer's intent to be in this case, but let's open that up for discussion
<MajorLag_>
yes... though now that i think about it that isn't necessarily true
<MajorLag_>
They way this came about is that I'm using an enum to have a set of named constants that are used as array indexes. In this case, the array is bool and tracks key states. I create and initialize the array using @memberCount(). If @memberCount() worked on a struct of constants, I could use that, but I'd have to manually specify the values. It could be that this is a bit more of an edge case than I originally thought.
<MajorLag_>
In fact, now that I'm forced to think about it, I could just use a struct of named bools.
<MajorLag_>
On that note, is there a way to express "this is just a one-off struct, not a type"?
<andrewrk>
MajorLag_, what would that do differently than if it were a type?
<andrewrk>
if all the fields are of type void, then the type will have 0 bits and not generate any runtime code
<andrewrk>
feel free to share your code, maybe I can make a suggestion, or maybe it will convince me to change zig in some way to handle the use case better
<MajorLag_>
The struct in this case does have fields, of type bool. But I only ever need a single instance of it. In C, this could be expressed as:
<MajorLag_>
Though that does mean listing every field twice.
<andrewrk>
agreed
<andrewrk>
zig optimizes for other goals, sometimes at the cost of verbosity
<MajorLag_>
In most cases I appreciate the extra specificity over the verbosity. I'm hoping the few that bother me are ultimately just a matter of finding the best way to work with the language.
<andrewrk>
I'm definitely interested in examples of code that is awkward to express in zig
<MajorLag_>
var keys: struct {up: bool, down: bool, left: bool, right: bool} = undefined; is less verbose, but means I should probably initialize it later, which I'd end up doing with a memset and a sizeof. What do you think of adding a way to specify that I want to initialize something by zeroing its memory?
<andrewrk>
this is one of those cases where I think explicitly initializing fields is worth the upfront cost.
<andrewrk>
the cost of typing a few more keys on the keyboard
SimonNa has quit [Remote host closed the connection]
<MajorLag_>
question: @memset(@intToPtr(&u8, @ptrToInt(&keys)), 0, @sizeOf(@typeOf(keys))); seems to work, but @memset(@ptrCast(&u8, &keys), 0, @sizeOf(@typeOf(keys))); produces an invalid cast error. Am I missing something obvious?
<andrewrk>
MajorLag_, can I see the code that defines keys?
<andrewrk>
MajorLag_, with @memset were you getting "out of bounds pointer access"? I just reproduced this, and it's a bug. the bug is not present if keys is a local variable instead of a global
<andrewrk>
however, the idiomatic way to do what you are doing works
<MajorLag_>
odd, with memset I get "invalid cast from type '&(anonymous struct at ...)' to '&u8'", other attempted variations did produce OOB pointer errors though.
<andrewrk>
I suggest the "idiomatic" way from by above code paste, or better yet, use your text editor's fancy tooling to explicitly initialize every field to false
<andrewrk>
isn't the key data really an array?
<MajorLag_>
it was, but I changed it to a struct because indexing an array with enums was a bit unwieldy.
<MajorLag_>
Personally I feel like initializing a struct or array to 0 is a common enough operation that 'zeroes' keyword makes sense, but maybe I'm wrong. I wrote a fuse implementation a while back, there are lot of structs with fields I never use or care about, but that could cause issues if they weren't set to 0.
<andrewrk>
maybe you could use a helper function: fn key(id: KeyId) -> bool { return keys[@TagType(KeyId)(id)]; }
<MajorLag_>
Ok, well, here's a thing. I can avoid listing every field twice and get the behavior I wanted by just creating a new file "keys.zig" full of pub vars and importing it. If there's a way to create an arbitrary namespace in Zig that I'm not aware of, I could do that in the same file.
<MajorLag_>
Not that that's a big deal
<andrewrk>
you can get an arbitrary namespace with an empty struct
<MajorLag_>
...so you can. That you could use structs like this wasn't obvious to me. I was under the impression it only worked for constants.
jjido has joined #zig
cenomla has joined #zig
arBmind has quit [Quit: Leaving.]
jjido has quit [Read error: Connection reset by peer]
alandipert has quit [Quit: Ping timeout (120 seconds)]
alandipert has joined #zig
cenomla has joined #zig
apatap has joined #zig
arBmind has joined #zig
itsMontoya has joined #zig
<itsMontoya>
Hey andrewrk
<itsMontoya>
Long time no talk! Sorry I've been MIA for a bit
<andrewrk>
hi itsMontoya
<itsMontoya>
Does zig have an HTTP listener within the stdlib?
<itsMontoya>
I did a quick docu search and didn't find anything
<andrewrk>
not yet
<itsMontoya>
Ah ok - I'm trying to think of a simple project I can do in zig to get my feet wet
<andrewrk>
there's some non-blocking I/O work done in a branch
<itsMontoya>
But most of my shit is web services
<andrewrk>
a game would be a fun candidate
<andrewrk>
or a CLI utility
<itsMontoya>
Maybe CLI utility
<itsMontoya>
I feel like a game would be too difficult for me as I'm just trying to get the syntax down better
<andrewrk>
I also plan to add coroutines soon. that + non blocking I/O will make it attractive to do networking
<itsMontoya>
Yes! I like that
<itsMontoya>
So you are going the coroutine route instead of the async/await route?
<andrewrk>
the two are related
<andrewrk>
coroutines are building blocks to implement async/await
<itsMontoya>
Ah true, I guess I meant the difference between golang and .net
<itsMontoya>
Where golang doesn't have async/await at all
<itsMontoya>
Rather, each coroutine gives the illusion of being sequential
<itsMontoya>
Without needing async/await to handle the part of waiting
<andrewrk>
I see. I want to achieve async/await, if I can do it without compromising zig's goals of: no hidden control flow, no hidden memory allocations, explicit error handling
<itsMontoya>
Well I think that the golang model would suite you better then
<itsMontoya>
async/await == hidden control flow IMHO
<andrewrk>
yes. if we can make it work within the requirements, that would be ideal
<itsMontoya>
It's one thing that drives me crazy about Rust
<itsMontoya>
The async/await is done with macros
<itsMontoya>
so you get these obscure errors
<itsMontoya>
It's just not a pleasant experience
<andrewrk>
I need to experiment with it
<itsMontoya>
I built a toy http handler with tokio
<andrewrk>
it's not clear how to proceed with coroutines yet
<itsMontoya>
It was not fun lol
<itsMontoya>
Even rust veterans were like "That's uncharted territory"
<andrewrk>
a straightforward debugging experience is central to zig
<andrewrk>
yes, for example assuming the pthread model, you would have 1 pthread_cond per channel
<itsMontoya>
I was going to just port that
<itsMontoya>
Oh sorry, private repo :(
<itsMontoya>
Long story short, I've written channels already. So porting shouldnt be too bad
<itsMontoya>
I love that you have all these int types
<itsMontoya>
u2,u3,u4
<itsMontoya>
There are times where I just need like 0-7, but I settle for u8 because that's the smallest I have access to
<jfo>
Concurrency is so interesting to me and I look forward to learning about it more as it gets implemented. is the `kernel thread` you refer to in issue the same as a pthread? is that the same as forking a process? do you want to support green threads? are channels related to erlang style message passing? so many new things to learn :)
<jfo>
++learning
<itsMontoya>
jfo: Yes
<itsMontoya>
Coroutines would be green threads
<itsMontoya>
and he's working on getting that going, but they want to implement it without ruining zig's core values
<itsMontoya>
RE channels: Yes, it's for message passing. Similar to erlang
<itsMontoya>
Golang also uses channels for communication
<itsMontoya>
Hell, I use them on Rust quite a bit as well
<itsMontoya>
Shit andrewrk - I think I found the project I want to do
<andrewrk>
jfo, yes pthreads are kernel threads
<andrewrk>
forking a process is different than a kernel thread
<itsMontoya>
Then jfo can write an actor framework on top of the channels :P
<andrewrk>
erlang style message passing is equivalent to channels
<itsMontoya>
andrewrk: aur/zig 0.1.1-1 (3, 0.01)
<itsMontoya>
Is that recent?
<andrewrk>
374 commits to master since this release
<andrewrk>
I recommend master branch
* jfo
clap
<itsMontoya>
Oh ok, I won't be lazy then. I'll github it
<andrewrk>
release 0.2.0 is scheduled for 1 week after llvm 6 comes out, which is currently feb 21
<itsMontoya>
I wish I knew more about VScode plugins
<itsMontoya>
I'd love to write a zig vscode plugin, linters have made me lazy
<andrewrk>
I believe there exists a zig vscode plugin already
<jfo>
what is the advantage of having green threads in addition to system threads? does that increase the complexity for dealing with concurrency in user land as opposed to letting the os handle it?
<andrewrk>
you can go into a pretty deep rabbit hole trying to answer that question
<andrewrk>
my summary of it is: kernel threads are more resource-intensive for the system, whereas coroutines can be cheaper
<andrewrk>
with kernel threads you let the OS scheduler decide how to schedule things. with coroutines the application decides how to schedule things
<andrewrk>
it kinda doesn't make sense to have more than N kernel threads where N is the number of CPU cores you have
<lqd>
the number of threads is also limited
tridactyla has joined #zig
<lqd>
ie you can have many many more green threads than system threads
<jfo>
will that distinction be made explicit, I wonder? i.e. will I know when I'm asking for a pthread vs a green thread and can a green thread potentially be a system thread without me knowing and does it matter if that's the case
<lqd>
to me, it usually is explicitly different yes, as in the green thread is modeled as functions/blocks/goroutines/whatever, and threads not at all