<LewisGaul>
Is it possible for a Zig function to return a tuple, and if so how do you declare the return type?
<g-w1>
std.meta.Tuple iirc, but it might not work
<LewisGaul>
ah is that what's used by formatting calls like `print("{s}", .{"hi"})` ?
<g-w1>
no, it just uses anytype since it is an argument
<g-w1>
anytype isn't allowed for return types
<g-w1>
(yet)
<ifreund>
I think that proposal got rejected?
<LewisGaul>
yeah that rings a bell. I can just use an array for now if there's no native support for returning tuples
<g-w1>
does std.meta.Tuple not work?
<LewisGaul>
I haven't tried it to be honest, I only wanted to reach for tuple as I thought it was a native zig concept and seemed a better fit, but using `std.meta` feels like overkill in this case
<g-w1>
iirc in the future it will be `struct { u32, usize, ...... }
<g-w1>
but not sure
<LewisGaul>
from looking through issues that seemed to be an accepted proposal - wasn't sure what the status on it was :)
<ifreund>
yeah I think `struct { u32, usize, ... }` is planned
<LewisGaul>
I will await that, LGTM
ur5us has joined #zig
LewisGaul has quit [Ping timeout: 240 seconds]
brzg has joined #zig
<andrewrk>
g-w1, that field is *zir.Inst in master branch - it's not new
<andrewrk>
when you reference an identifier, if it matches a LocalVal in scope, it will be a reference to that ZIR instruction
<andrewrk>
ifreund, g-w1: I'm about to take on a new task. any toes to avoid stepping on?
<ifreund>
andrewrk: I'm done for the night, don't have anything WIP here
<andrewrk>
cheers!
<andrewrk>
regarding test suite, it's test/stage/* and `zig build test-stage2` runs it
<andrewrk>
oops, test/stage2/*
<andrewrk>
once stage2 gets further along, we'll start running the regular behavioral tests on it
<andrewrk>
we can even do some code coverage analysis to help come up with more test cases :)
<g-w1>
im trying vardecl rn
<g-w1>
kinda there
scraireland has joined #zig
<ifreund>
I think I'm equiped to do if/for/while when I get time
<g-w1>
also porting the zyg test suite to bash at the same time, so we'll se which one gets done first :P
<ifreund>
might try and unify everything like we do in zig fmt
<ifreund>
(i cleane up that code recently as well :D
<andrewrk>
ifreund, it would be sweet to unify test/stage{1,2} and have a declarative way to specify a test and say like, "this one passes for both", "this one passes for 1 but not 2", "this one passes for 2 but not 1"
<andrewrk>
at least for, e.g., compile errors
<ifreund>
yeah that would be nice
<ifreund>
we'll need that infrastructure long-term to maintain the bootstrapping compiler as well
<andrewrk>
yeah. also would be nice to have a way to load test cases at runtime so we don't have to rebuild the test harness all the time
<ifreund>
indeed, stage1 is slow :/
<g-w1>
yeah ive had that problem a lot
<andrewrk>
lots of ergonomic improvement potential in the test harness
<g-w1>
have you done anything with start2 yet?
<andrewrk>
not yet
fengh has joined #zig
fengh has quit [Client Quit]
scraireland has quit [Quit: Connection closed]
powerofzero has joined #zig
<powerofzero>
Hi, I was reading #8284 on GitHub, and that proposal, by my reading, assumes a model where the end binary's package manager will resolve all transitive dependencies. Is this something that has been decided for the official package manager?
<andrewrk>
powerofzero, it has not been definitively decided yet
<andrewrk>
I will say that I am amenable to the idea that the end binary has final say about such things
<powerofzero>
Thanks
brzg has quit [Quit: leaving]
lyhokia has joined #zig
<g-w1>
andrewrk: it seems like you partially updated varDecl already? is this true?
<g-w1>
like some of the things deal with LazySrcLocs
<jokoon>
it's like C++ but simpler and without the complicated stuff, only the simple things that are in C
<jokoon>
It's hard to describe the feeling I have towards zig, but it seems to be the language I was looking for a long time
<companion_cube>
jokoon: what's pythonic about it?
<jokoon>
the 'f'*4
<jokoon>
results in a string
<ifreund>
I think you mean "foo" ** 4
<txdv>
seems like its spring agian
<txdv>
yeah, zig is a clean uped version of C
<companion_cube>
heh, fair enough
riba has joined #zig
<jokoon>
so array are always static sized, right? there aren't containers like std::vector or std::map?
<txdv>
Currently I am looking at raylibs api: void SetWindowState(unsigned int flags)
<txdv>
I realized that flags in C are implemented using macros
<dutchie>
jokoon: std.ArrayList
<txdv>
And now I'm looking at the API and I have no idea how to search for the actual flags, because the type is unsigned int and there is nothing in the type system that argument to the macros
<dutchie>
and std.AutoHashMap and friends
<dutchie>
most of the time if you want a variable sized array in signatures you use slices though
<daurnimator>
jokoon: the standard library is full of container types
<jokoon>
their doc lack examples
<jokoon>
oh wait nevermind
<ifreund>
jokoon: look at the tests in the same source file for examples
riba has quit [Ping timeout: 264 seconds]
aconbere has joined #zig
<dutchie>
at the moment, reading the source code is much better than the generated docs
<dutchie>
as a side bonus, you get to see examples of idiomatic zig code
<companion_cube>
is it the plan that the stdlib would also be specified (like the STL) and have several implementations?
<companion_cube>
or should only the language have a spec, and the stdlib be shared
<ifreund>
what would be the benefit of multiple stdlib implementations?
<companion_cube>
the same as having multiple compilers?
<companion_cube>
(in particular, not depending accidentally on implementation details)
aconbere has quit [Quit: Lost terminal]
forgot-password has joined #zig
<daurnimator>
Is there nothing in build.zig to let you pass extra arguments to the compiler?
<g-w1>
like what?
Raito_Bezarius has quit [Ping timeout: 264 seconds]
<daurnimator>
g-w1: e.g. -Bsymbolic
<g-w1>
the build system should probably have a flag for that
<daurnimator>
yeah. but there seems to be several options that it doesn't have a flag for
<daurnimator>
an escape hatch would be useful
bitmapper has joined #zig
drvirgilio has quit [Remote host closed the connection]
drvirgilio has joined #zig
powerofzero has joined #zig
yyp has quit [Quit: now it's safe to turn off your computer]
craigo has joined #zig
carldd has quit [Ping timeout: 260 seconds]
<txdv>
Is it possible to do object introspection with zig of C code? Like I want to do @import("somelib.h"), then find a function which is name "somefunction" and it should tell me how many arguments there are in it?
<txdv>
has the name* sorry for poor grammar
<ikskuh>
yep
<ikskuh>
just @cImport() it :)
<ikskuh>
you get a normal zig namespace with all comptime introspection available to other zig code
yyp has joined #zig
<txdv>
what are the introspection primitives?
<txdv>
the API for introspection?
<ifreund>
@typeInfo
carldd has joined #zig
<powerofzero>
std.builtin has the TypeInfo type that you get from @typeInfo()
<v0idifyy>
i would have to setup a dev environment (i
<v0idifyy>
(i'm just editing into lib/std)
<g-w1>
just run zig test path.zig
<v0idifyy>
oh!
<FireFox317>
ifreund, ah yeah no problem, these things can happen. I did learn more about this new structure, so that's good anyway xd
Akuli has joined #zig
<v0idifyy>
well yes, it fails. the logic of the function confuses me tons though so i can't seem to find a way to fix it
<ifreund>
v0idifyy: pretty sure passing a file to fs.path.relative() a misuse, it expects two directory paths
<ifreund>
FireFox317: thanks for your understanding, I'll definitely be checking the PR list before I work on things in the future
<v0idifyy>
not documented anywhere if that's the case
<v0idifyy>
even then, doing (".", ".", ".") fails, it returns an empty string
<ifreund>
that's what it's supposed to do
<ifreund>
FireFox317: yeah wrapping your head around the data structures involved is the hard part, if you decide to apply that knowledge and send more code feel free to ping me for a speedy review :)
blackpawn has quit [Ping timeout: 265 seconds]
<v0idifyy>
why? passing an empty string to join fails last time i checked
<ifreund>
and then copy over the instructions after genreating them in a child scope
<cepheus>
weird question, but is it possible to get a function pointer for a BoundFn? i'm writing a structure of sorts atop a C library that makes use of function pointers for callbacks with user pointers, and the code i'm writing to wrap it is type-parameterised, so i need a way to reference the type itself in the callback's context
<g-w1>
ifreund: ok ill try that
FireFox317_ has quit [Ping timeout: 265 seconds]
<txdv>
Hi guys! That talk with the handmade nasa guy was amazing, I didn't know such an awesome community existed
bbuccianti has joined #zig
<cepheus>
whoops, i know where i was going wrong, i was accessing the function via the instance rather than the type
leon-p has quit [Quit: leaving]
<andrewrk>
powerofzero, can you elaborate on your question about build.zig and C dependencies?
<andrewrk>
cepheus, we're trying to get rid of the BoundFn type in the language actually
<cepheus>
hah, in this case i'm largely only aware of it's existence through these edge cases. i did notice there are efforts to eliminate the distinction though
sord937 has quit [Quit: sord937]
<g-w1>
im still very confused about the block thing. if someone wouldn't mind, could you finish that part of the pr? I think I can do everything else
jah has joined #zig
jumpnbrownweasel has quit [Ping timeout: 240 seconds]
<andrewrk>
g-w1, sure thing
<g-w1>
and do you think we should have a seperate suspend scope so that it can have nice src locations?
casaca has joined #zig
ur5us has joined #zig
ncon1 has quit [Quit: Quit Goodbye!]
ncon has joined #zig
wootehfoot has joined #zig
<andrewrk>
not sure what you mean, what does the scope have to do with source locations?
<ifreund>
seems pretty clear to me that we should have a Suspend scope then
<g-w1>
yeah, just wanted to get another opinion :)
<ifreund>
part of me wonders why we bother with async await stuff in self-hosted yet
<g-w1>
its just astgen, vexu added it around a month ago iirc
<ifreund>
that could all be @panic("TODO") until we have the compiler building itself with the cbe
<g-w1>
hmm, ig
<ifreund>
yeah it's just astgen, but it causes maintenece burden as demonstrated right now
<andrewrk>
IMO rip it out if it's not covered by test cases
<g-w1>
rip my work. its fine tho I learned so thats all that matters ;)
<ifreund>
g-w1: you itching to do some ripping or shall I?
<g-w1>
rip away
<ifreund>
:)
<andrewrk>
as a hint, the c backend is probably the simplest way to get test coverage for frontend improvements
<g-w1>
yep, thats how we did runtime error stuff
<g-w1>
ill close my pr as its being ripped
wootehfoot has quit [Read error: Connection reset by peer]
jjido has joined #zig
<andrewrk>
I think we should probably do all of async stuff at once, astgen, Sema, codegen, rather than trying to split it up
<ifreund>
I agree
<ifreund>
and I also think it should wait until the compiler can build itself with the c backend at least
<ifreund>
andrewrk: would you rather have the current async-related zir instructions commented out or deleted?
<andrewrk>
agreed about building itself too
<andrewrk>
deleted
<ifreund>
+1
<ifreund>
we can always go back in the git history to see them
<andrewrk>
yep. hopefully it won't annoy vexu too much. I'll have a chat with him and make sure :)
<andrewrk>
(but go for it)
<ifreund>
cool, it'll probably take me a bit
yyp has quit [Quit: now it's safe to turn off your computer]
jokoon has quit [Quit: Leaving]
midgard_ has joined #zig
midgard has quit [Ping timeout: 265 seconds]
Akuli has quit [Quit: Leaving]
jhartog has quit [Ping timeout: 246 seconds]
<andrewrk>
this untagged union safety is real nice
<dimenus>
my favorite thing to come out of zig recently is userspace SoA
<andrewrk>
the API is not bad!
<dimenus>
that's a pretty great solution without adding more complexity in the language itself
<dimenus>
i like the strategy to move towards DoD for stage-2, but i think having indexes / handles into everything makes it harder to debug under eg gdb
<dimenus>
i could just be tired / stupid though
<andrewrk>
you're right, we are taking a bit of a maintenance hit here
<andrewrk>
I think it's worth the pain though because this is a pretty reasonable use case for the language
<andrewrk>
so if it leads us towards lang changes, that's good
<ifreund>
andrewrk: i'd kill for distinct types for all these different kinds of indexes tbh
<andrewrk>
I'm feeling the same way
<andrewrk>
SpexGuy told me to try using a non-exhaustive enum but idk it felt awkward to try to do that, I gave up after like 20 min of refactoring
<ifreund>
yeah non-exhaustive enums feel like a hack for this, @enumToInt() everywhere makes little sense as you're not using it as an enum
<dimenus>
limiting footguns is a good thing. +1 for distinct types