ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
alexnask has joined #zig
<achambe>
I like the explicitness of that.
<achambe>
Another thought I had was just runtime checks around lifetimes (vs a strict compiler)
<achambe>
(Just browsing the issue tracker and people bring it up)
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<MajorLag>
alright, that's what I thought. It's a minor inconvenience in my API right now. Comptime varargs would also help, though I made the part that could use it pretty tollerable with a type alias in this case. `pub const List = []const []const u8; ... ComptimeThing(x, y, z, List{"a","b","c"});`
Tobba has quit [Ping timeout: 264 seconds]
<andrewrk>
let's re-evaluate this once #733 is done
<GitHub94>
zig/master 4b0556e Jimmi Holst Christensen: std.zig.parser can now parse `std/heap.zig`:...
<alexnask>
Hi, any tips for getting to understand the compiler internals? I'm currently looking into implementing comptime varargs and I'm just wondering where I should start looking and/or if there is some overview documents to get a feel for how the compiler operates
<GitHub26>
zig/master a7f77d7 Jimmi Holst Christensen: std.zig.parser: requireSemiColon now matches the C++ behavior...
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Tobba has joined #zig
ncx has joined #zig
ncx has quit [Ping timeout: 260 seconds]
alpha has joined #zig
<alpha>
1) Is there docs for the stdlib?
alpha is now known as Guest6208
<Guest6208>
2) Does the stdlib have httpclient and httserver modules?
<andrewrk>
alpha, nope. but Hejsil just finished the self hosted parser, which gets us to the next step of auto doc generation (see https://github.com/zig-lang/zig/issues/21)
<Guest6208>
Okay
<andrewrk>
I just finished a proof of concept TCP server, which needs some API cleanup, and then the next step is either adding http on top of that or trying out multiplexing coroutines onto kernel threads
<Guest6208>
What is the expected release timeline of the http libs?
<andrewrk>
would you like to open an issue for this feature? and then I'll assign a milestone to it, which gives you an idea of the priority
<Guest6208>
Also are there any docs regarding the allocators and their usage in Zig. Coming from other languages, this is the feature which is most different.
<Guest6208>
Sorry I am not on github :(
<andrewrk>
I'll open one
<Guest6208>
Wbu the docs regarding allocators? Since every minor zig code requires its usage?
<Guest6208>
*What about
<andrewrk>
I agree, we should add that to the language reference
<alexnask>
@andrewrk Hi, I'm currently working on comptime varargs, just a quick question, are all vararg functions considered generic?
<andrewrk>
alexnask, yes
<andrewrk>
that's a particularly difficult bug to solve, best of luck
<andrewrk>
I'm considering adding tuples to the language and removing var args, for what it's worth
<andrewrk>
that's one reason I haven't solved this yet
<alexnask>
Ah well I was considering writing tuples on top of the existing language :p
<alexnask>
We "only" need @reflect/@reify to build types in an imperative fashion
<andrewrk>
adding @reflect or @reify might be an easier task than fixing comptime var args
<andrewrk>
if you're looking for something to do
<andrewrk>
and I believe that proposal is accepted
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<alexnask>
The current roadblock I'm facing is that ir_analyze_instruction_elem_ptr relies on get_fn_var_by_index to get an argument out of the varargs, which appears to rely on the function being generic
<alexnask>
Just a quick question if you can answer off the top of your mind, is there any particular reason why ConstArgTuple just hold indices to arguments instead of owning the resolved argument expressions itself?
<andrewrk>
alexnask, I believe that just holding indices and not owning the resolved expression is the cause of the problem you're trying to solve
<andrewrk>
I can't remember if changing it to owning the resolved expression will cause a problem or not - I think you'll have to change some hashing functions at least
<alexnask>
I will explore this route, it seems like it could simplify the generic function code too (remove the need for expanding varargs into the generic function instance, just use one argument everywhere)
<andrewrk>
what do you think about the idea to remove var args entirely and add tuple support?
<andrewrk>
so the format function would look something like: std.debug.warn("foo: {} bar: {}\n", [foo, bar]);
<alexnask>
Hmm
<alexnask>
Personally I'm more of a fan of tuple types living in the std
<alexnask>
Although the two are equivalent, really
<MajorLag>
tuples has the advantage of allowing multiple "varargs" sections too.
<andrewrk>
they're very similar. tuples seem less like a weird special case
<alexnask>
Yeah, that's true
<alexnask>
I think reflection would be better to have first though
<andrewrk>
for tuples, the length and the types would be comptime known, the values would be runtime known
<alexnask>
So that people can easily query their tuple types etc.
<andrewrk>
good point
<alexnask>
And would that example code work with the current type system?
<andrewrk>
and that kinda depends on pointer reform
<alexnask>
Since warn does not know what the tuple type will be
<alexnask>
So for it to work, you would need to pass the tuple type in as a generic argument, right?
<alexnask>
Good point I always forget about var parameters
<MajorLag>
how would that work with a function taking a tuple? would it have to take var or would there be a way to enforce the type, as in `fn whatever(args: f32...)`?
<alexnask>
I don't see why you would want a tuple with all field being of the same type instead of taking a slice but maybe I'm missing something
<andrewrk>
if it wants to enforce a type, how about having the parameters directly be the things wanted?
<alexnask>
And you should be able to write some code to typecheck your tuple/vararg types
<andrewrk>
if we had tuples I think something like @call(functionPointer, tuple_of_args) would make sense
<MajorLag>
the thing with a slice is that it has some ugly construction if you want to use literals, though this can be cleaned up a bit with a comptime helper fn. If you use var, you have to explicitly type all your literals. It's a minor thing, sure.
<alexnask>
Yeah, makes sense and it's actually probably really simple to write in zig instead of a compiler intrinsic
<alexnask>
@MajorLag sure, I'm just saying you could have some enforce_tuple_type(tuple: var, comptime t: type) function to do your typechecking
<andrewrk>
MajorLag, having to type literals for args with `var` is annoying. and I think we can overcome this
<MajorLag>
So like, in move.zig, the current API allows you to create action types to fit your criteria, so you have to pass a slice of values to the function: `var rotateTo = RotateToAction.init(interpolation.linear, 5.0, f32(1.0));` I have to explicit cast the last parameter because it is varargs
<alexnask>
Anyway all I'm saying is that just with @reify and @field you can get a tuple type up and running in zig
<alexnask>
I personally prefer this approach + tuple literals that call into builtins
<andrewrk>
MajorLag, I'll bump up the priority on fixing that
<jab>
Anyone know any other languages that provide C ABI compatibility?
<MajorLag>
andrewrk, how can you fix that? That's a runtime fn, the function has to take `args: ...` and because it can't specify the type the user has to cast the literal. In this case the type is known, I just have no way of telling that to the compiler.
<andrewrk>
this isn't even that hard of an issue. I'll see if I can knock it out soon
<MajorLag>
well, if you say so.
<andrewrk>
worst case scenario, we generate a specialization of the function for each different literal value you use with it
<alexnask>
@andrewrk: I was thinking of something like that: https://gist.github.com/alexnask/41abc5ce1c76bbd9f41608331f9545d8 for tuples, it's actually the first thing I tried out to implement in zig before realizing there was no way to construct types imperatively.
<alexnask>
I really think it would be a killer feature, it just makes metaprogramming sooo much easier
<andrewrk>
what would be a killer feature? @reify and @reflect?
<alexnask>
Yes
<alexnask>
But then again I get way too excited about metaprogramming :p
<andrewrk>
I'm pretty sure I accepted this proposal - the current plan is to add these 2 builtins and then remove the redundant reflection features
<alexnask>
Yes I've read through that issue I plan on taking a stab after I fix (or completely fail to fix :P) comptime varargs
<andrewrk>
I think adding @reflect and @reify is going to be much more straightforward than fixing var args
<andrewrk>
the former is adding new things and the latter is figuring out what wrong decisions I made and reworking the code
<alexnask>
I'll try it out anyways, nothing wrong with getting my ass kicked in the process :P I pretty much just want to get familiar with the code base etc, I've worked on compilers before but one as complex as zig
<alexnask>
not*
<MajorLag>
if you're going to do reify/reflect, it'd be great if it worked against namespaces / empty structs too. this would let us determine if a struct passed to warn has a fmt() fn and call it to allow custom formatting.
<alexnask>
Well in principle I suppose we should be able to @reflect and @reify any declaration right? Types should come first for sure but namespaces sound pretty trivial as well
<andrewrk>
MajorLag, I'm still thinking about your idea of making a file actually just be an empty struct
<alexnask>
@reify-ing function sounds like the most involved usecase (assuming it should be possible, I don't think it's included in the proposal)
<MajorLag>
It just seemed like they were basically the same thing, certainly I use comptime generated empty structs as a way of creating a namesapce at comptime. It seemed that `namespace` was just a base type upon which `struct`,`union`, and `enum` sat.
<andrewrk>
wow it's really exciting how close we are to having a `zig fmt` that correctly handles all std lib code
<jab>
Has there been any proposals for handing stack allocation failure?
<andrewrk>
another idea is to use coroutines - because calling a coroutine requires using an allocator and the call can fail
hinst has quit [Ping timeout: 265 seconds]
hinst has joined #zig
<MajorLag>
speaking of, that async<allocator> syntax only being used in one place bothers me. I think I get the reasoning behind it, it just seems like we should look for other oportunities to do that kind of thing. Like, could promise use it instead of ->?
<andrewrk>
angle brackets? there's a plan to use it for enum<tag> union<tag> and fn<cc>
<andrewrk>
it solves an ambiguity for fn<cc> - consider fn(cc)()
<MajorLag>
ah, ok, nevermind then, you're way ahead of me
<andrewrk>
MajorLag, #623 was a 1-line fix. running tests now
<MajorLag>
This is because I don't write compilers, it really seemed like a harder problem to me.
<andrewrk>
I didn't realize it would be this easy either. I feel kinda bad
<andrewrk>
ah ok it didn't fix it for var args. just `var` type
<MajorLag>
so if I pass `1`, does that turn into a u8 or is it recognized as a literal within the fn, so it can implicitly cast to f32?
<andrewrk>
the latter
<MajorLag>
sweet
<andrewrk>
MajorLag, I think var args integer literals are going to be broken for the same reason as #557. it's related to what alexnask is looking at and the tuple discussion
<MajorLag>
oh well. I can wait, it's clean enough for now.
<MajorLag>
thanks for taking a look though
davr0s has joined #zig
<ragge>
hey! is compiling to wasm supposed to be supported? tried running zig build-exe --target-arch wasm32 main.zig but getting:
<ragge>
Abort trap: 6
<ragge>
unable to create target based on: wasm32-unknown-unknown-wasm
<andrewrk>
ragge, llvm still treats WebAssembly as an experimental target, so it's not included by default
<andrewrk>
however, I enabled it on the CI builds, which you can find on ziglang.org/download
<andrewrk>
we have CI builds for windows and linux
<ragge>
andrewrk: ah, ok, makes sense. I'll check out the CI builds, thanks!
<GitHub57>
zig/master 5b584e0 Jimmi Holst Christensen: std.zig.parser special cased error in return....
arBmind has joined #zig
isd has joined #zig
redj has quit [Ping timeout: 240 seconds]
redj has joined #zig
<hobomatic>
i was just thinking about the namespace/empty struct thing yesterday. One of the first wrong assumptions I made about zig was that empty structs and namespaces were interchangable
<andrewrk>
noted. that's a useful data point
cgag_ has joined #zig
profan_ has joined #zig
occivink has quit [*.net *.split]
benaiah has quit [*.net *.split]
cgag has quit [*.net *.split]
profan has quit [*.net *.split]
cgag_ is now known as cgag
benaiah has joined #zig
occivink has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]