KubaSO has quit [Remote host closed the connection]
daurnimator has quit [Quit: WeeChat 2.8]
daurnimator has joined #zig
<andrewrk>
pixelherodev, yo
ur5us has joined #zig
Mulugruntz has joined #zig
heitzman1 has joined #zig
heitzmann has quit [Ping timeout: 264 seconds]
drp has joined #zig
<pixelherodev>
andrewrk: hi
<pixelherodev>
Good news: about to open the first CBE PR
<pixelherodev>
Inline asm works with inputs and outputs; stddef.h is auto-included if needed; function calls without args and with `noreturn` or `void` return value works :)
<andrewrk>
neat!
<pixelherodev>
Need some help to go further
<pixelherodev>
Mostly, just need to wait for your PR i believe
<pixelherodev>
andrewrk: does `pub` work in self-hosted yet?
<pixelherodev>
Is there any way to check `if (pub)` from a Module.Fn?
<leeward>
I wonder if _start needs a `while (1);` to get rid of that warning.
<pixelherodev>
Nah
<pixelherodev>
Going to provide a way to `unreachable`
<pixelherodev>
Still working towards that example I posted
<pixelherodev>
Ah wait, that Pr's not good yet
<pixelherodev>
It's targeting C99 but emitting _Noreturn
<andrewrk>
pixelherodev, we don't even have structs and @import yet
<andrewrk>
nice work, will give you a review in one moment
<pixelherodev>
Not ready yet regardless, need to properly handle the standard
<pixelherodev>
But reviewing before I do that is helpful because I won't be changing much
<andrewrk>
yeah I was going to ask, given that the use case of c back end is to be valid C code in as many different C compilers as possible, wouldn't it make sense to have it be C89 and not configurable?
<pixelherodev>
The idea is to make it fully flexible
<pixelherodev>
We should support C89 of course
<andrewrk>
what's the use case for non-C89?
<pixelherodev>
But if you want to generate C11, you should be able to do so; it's not that much work anyways
<pixelherodev>
e.g. _Noreturn
<andrewrk>
IMO we should have #ifdefs for _Noreturn
<pixelherodev>
There's a number of convenience features that make it easier (and potentially more efficient) to map with C99 / C11
<andrewrk>
idea being to emit code that works in all the c standards
<pixelherodev>
The goal is to make it possible to generate code that's good for e.g. SDCC (--c-standard C89) or code that's more efficient but only works with new compilers (e.g. designated initializers)
<pixelherodev>
This isn't just about compatibility though, it's about readability
<pixelherodev>
I also want to directly copy comments
<pixelherodev>
The goal is to produce readable code that can be maintained without knowledge of the original
<andrewrk>
I don't think we're on the same page regarding readability
<andrewrk>
consider that we may introduce optimization passes that would sit between zig source and the c back end
<pixelherodev>
I think that should be a compiler option as well
<pixelherodev>
You should be able to say, "make me efficient C" or "make me readable C"
<pixelherodev>
It's not like it's much work for the compiler
<andrewrk>
I agree with you that those are two different use cases, but I'm not sold on bringing the second one into scope for the zig project
<pixelherodev>
I can understand that, even if I'm definitely going to try to change your mind :)
<andrewrk>
fair :)
<andrewrk>
anyway, your PR is nearly mergeable already, let me just give you some review comments
<pixelherodev>
I think we need to make *some* decision on the matter now, even if it's just "Let's postpone deciding this"
<pixelherodev>
Because the PR needs to be tweaked accordingly (strip out C standard? actually pay attention to it? simply emit warnings?)
<andrewrk>
well, can we agree that the former use case is the primary one to target for now? (emitting .c code that is supposed to work in as many different compilers / standards as possible at the same time)
<pixelherodev>
For sure
<pixelherodev>
I'm going to add C89 to the CStandard enum and make that the main target for now
<andrewrk>
ok
<pixelherodev>
Removing it or implementing the others will come later
<pixelherodev>
No reason to torch it (since it might still happen), but if you're not sold on it there's no reason to dump the work in yet either
<pixelherodev>
For C89, noreturn will probably just map straight to void and have a call to unreachable() at the end
<pixelherodev>
Need to work on user-provided unreachable handler, I think
<pixelherodev>
A lot of this work blocks on frontend stuff though
<andrewrk>
you can check for gcc / clang / msvc / other versions with #ifdef
<andrewrk>
probably even the existence of _Noreturn
<pixelherodev>
True
<pixelherodev>
I should probably `#define noreturn` accordingly
<sqwishy>
Is there a good place to find zig libraries to read? I'm curious about writing a parser. I was going to look at something called zigini but it looks like all the links to the project on github just 404
<andrewrk>
there are a few parsers in the standard library
<andrewrk>
json for instance, and the self-hosted .zig source parser
<daurnimator>
pixelherodev: why not target all C versions with a mess of macros?
<daurnimator>
for at least e.g. _Noreturn it should be a simple ifdef
<pixelherodev>
daurnimator: that's what's going to be done for older targets (e.g. C89(
<pixelherodev>
)
<pixelherodev>
but if you're targeting C11 anyways, you probably don't want to have to read through a mess of macros :P
<daurnimator>
hmmm... could we throw the macros into a C header zig-bridge.h or something?
<pixelherodev>
Potentially, but that doesn't really help
<pixelherodev>
That just moves the mess elsewhere
<pixelherodev>
The idea is that if I'm targeting e.g. modern Linux, I don't want that around at all
<pixelherodev>
But if I'm targeting e.g. SDCC, there's no point in checking for _Noreturn anyways
<andrewrk>
the point is to remove complications from both the zig compiler implementation and the CLI
<pixelherodev>
That's true...
<pixelherodev>
It's a tradeoff, but I'm not sure that the tiny bit of complexity really matters here
<andrewrk>
if your goal is to output readable .c code, you will only be doing a 1 time translation, and then manually cleaning up the output. if your goal isn't that, you've already lost. the output is not source, it's generated code
jicksaw has quit [Quit: ZNC is kill]
* pixelherodev
shrugs
<pixelherodev>
Alrighty
<pixelherodev>
I'll remove the enum and clean this up
<pixelherodev>
But if I'm doing it this way, I'll take daurnimator's idea a step further
<pixelherodev>
I'll include all the ifdef guards in a source file in the repo, and @embedFile it :)
<pixelherodev>
I'm still only dealing with single file output for now
<pixelherodev>
I'll need to rework this to support multi-file output later, at which point it might get #included
<andrewrk>
sounds good to me
jicksaw has joined #zig
<pixelherodev>
Not sure how I'd check for e.g. _Noreturn via ifdefs - I'll probably just check for the standard version
<pixelherodev>
e.g. GNU99/GNU89 will use __attribute(noreturn), C11 and up will use _Noreturn, and C89/C99 will just be void
<andrewrk>
pretty sure msvc and gcc still support noreturn in c89 mode
<andrewrk>
it's ok to do compiler checks
<daurnimator>
yeah. check standard version and then compiler version
<pixelherodev>
That can come later
<pixelherodev>
It's really not a priority :P
<daurnimator>
and don't forget the non_null attribute :)
<pixelherodev>
None of that is happening until the frontend improves
<daurnimator>
uh, `__attribute__((nonnull))`
<daurnimator>
huh, TIL nonnull takes the argument indices that are non-null
<pixelherodev>
Header is good to go, just need to modify tests to auto-prepend it to expected output
<pixelherodev>
Okays!
stripedpajamas has joined #zig
aerona has joined #zig
<andrewrk>
pixelherodev, alright, feel free to ping me when you're ready. if you address all that stuff it should be good to go
<pixelherodev>
Within three-four minutes i think
<pixelherodev>
How would I go about truncating an open file? :P
<pixelherodev>
Ah wait nvm
<pixelherodev>
I see what I was doing
<pixelherodev>
andrewrk: do we want to support incremental update of C targets?
<pixelherodev>
IMO it's not worth doing
<andrewrk>
nah. I mean the update() API should work fine
<pixelherodev>
I was thinking in terms of adding tests and such
aerona has quit [Remote host closed the connection]
<andrewrk>
nah
<pixelherodev>
Plus, I'm setting truncate to true in setWritable
<pixelherodev>
Was going to `TODO support incremental` when I realized there's no real reason to do so
<andrewrk>
agreed
<andrewrk>
setWritable/setExecutable should be no-ops for CBE
<pixelherodev>
makeExecutable already is (make, not set; my bad)
<andrewrk>
makeWritable too. the point of it is to undo what makeExecutable does
<pixelherodev>
I did
<pixelherodev>
already :)
<pixelherodev>
Just need to tweak the Unimplementeds and it's done
<pixelherodev>
:)
<pixelherodev>
andrewrk: should I pass in the Module and do `return module.fail`?
<andrewrk>
look at how codegen does it
<andrewrk>
codegen.zig
<andrewrk>
I think the same mechanism should work
<pixelherodev>
Not really
<pixelherodev>
It sets err_msg on a Function
<pixelherodev>
We don't have those :P
<pixelherodev>
Ah wait, looking at the wrong place
<pixelherodev>
got it
<pixelherodev>
Just doing some minor fixup and pushing all the requested changes :)
<daurnimator>
if we pass it back to translate-c do we have a working zig to zig compiler? :)
<daurnimator>
pixelherodev: I expect much can be shared with emit-h code?
<pixelherodev>
Not yet
<pixelherodev>
I need to work on multi-file output first
<pixelherodev>
for now, it generates the header as part of the .c file
<pixelherodev>
andrewrk: ping :)
<andrewrk>
gotcha
<pixelherodev>
Anyone here have an old GCC?
<pixelherodev>
e.g. 5ish?
<pixelherodev>
...oops
<pixelherodev>
... or...not?
<pixelherodev>
andrewrk: One minor dumb I'm working around in CBE rn is that there's an attempt to embed strings from inline asm into the output even though they're never used
<pixelherodev>
e.g. `syscall`, `rdi`, `rax`
<pixelherodev>
You can notice the same thing if you `objdump -d` a binary produce by stage2 w/o CBE
<torque>
godbolt does
<pixelherodev>
?
<andrewrk>
pixelherodev, I think you can leave that. should be cleaned up in release builds, but not necessarily debug builds
<torque>
have old gcc versions
<pixelherodev>
andrewrk: it's not referenced
<pixelherodev>
at all
<pixelherodev>
not in debug info or anything
<pixelherodev>
All it does is make disasming more annoying
<pixelherodev>
torque: ah right
<andrewrk>
I don't think it's part of this CBE PR tho
<pixelherodev>
That's the second time someone's pointed it out
<pixelherodev>
andrewrk: Nah, I mean, CBE works around it currently
<pixelherodev>
In a really
<pixelherodev>
really
<pixelherodev>
dumb way
<pixelherodev>
I should remove that TBH, but then I need to figure out how to avoid generating invalid identifiers :P
<andrewrk>
yeah don't do that kind of thing, that's what I mean by "avoid local maximums"
<daurnimator>
pixelherodev: make sure you test with GCC 4.7
<pixelherodev>
daurnimator: good call
<daurnimator>
it's probably the most important historical gcc version
<andrewrk>
"not done yet" is a lot easier to improve than "done wrong"
<pixelherodev>
daurnimator: it does work :)
<pixelherodev>
With GCC 4.7
<pixelherodev>
andrewrk: for sure
<daurnimator>
pixelherodev: awesome :)
<daurnimator>
pixelherodev: for 4.7 support you need to e.g. use __thread instead of thread_local. though you probably haven't got that far yet
<daurnimator>
I would encourage you to test with GCC 4.7 and the most recent releases of GCC and Clang, and tiny c compiler.
<pixelherodev>
More curious if it works with e.g. SDCC
<pixelherodev>
Going to test with KCC and cproc as well
<pixelherodev>
Works with Clang 3.0 and ICC 13.0
<pixelherodev>
... but not clang 5 or newer, apparently
<daurnimator>
pixelherodev: do tcc?
<pixelherodev>
Not important right now
<pixelherodev>
Going to sleep
<pixelherodev>
... right after I do basic mapping
<andrewrk>
pixelherodev, just that one problem left, everything else looks good
<pixelherodev>
I think I'm going to just do $ -> _ for now?
<pixelherodev>
and _ -> __
<pixelherodev>
No, that's terrible
<pixelherodev>
I could just comment out the inline asm test for now and leave this an explicit TODO
<andrewrk>
this is a general problem since zig has @"aoeu" identifiers
<pixelherodev>
I know
<pixelherodev>
I was going to just limit the valid identifier range
<pixelherodev>
So that you can't try to use emoji identifiers and translate them
<andrewrk>
you could also just change it from $ to something else, I'm not married to that prefix
<pixelherodev>
True
<pixelherodev>
Or maybe I should just try to find where it's being generated and remove it
<pixelherodev>
Ahh, I see
<pixelherodev>
It's being lowered to a `str` in ZIR
marnix has joined #zig
<pixelherodev>
and all strs are generated, even if they aren't referenced, IIUC
<pixelherodev>
Would be neat to lazy evaluate ZIR in reverse order
<andrewrk>
it's an anonymous Decl generated at comptime, and not detected as garbage until update()
<pixelherodev>
But would be a major change for the worst reasons
<pixelherodev>
andrewrk: yeah, I noticed
<andrewrk>
it wouldn't solve the problem, actual mark+sweep garbage collection is needed to omit these anonymous decls generated at comptime
<andrewrk>
which is an option available to us. but it may not be worth it in debug builds. we'll see
<pixelherodev>
hmm
<pixelherodev>
another option would be a special ZIR instruction for comptime-only string literals
<andrewrk>
think bigger picture
<andrewrk>
that doesn't solve the actual problem for zig source code
<pixelherodev>
Yes it does, doesn't it?
<pixelherodev>
Instead of adding str, we'd add $FOO
<pixelherodev>
and this would actually mean doing *less* work to get rid of them, instead of more
<andrewrk>
arbitrary zig code deals with comptime values
<andrewrk>
we don't find out if the values are referenced until the comptime code finishes running, and we do a sweep
<andrewrk>
that's the problem. adding a new zir instruction doesn't address it
<pixelherodev>
In this specific case though (feeding a literal to a builtin / asm), it would help
<pixelherodev>
And it'd mean less work for a potential GC if one was added
<pixelherodev>
but that might not be worth it anyways
<pixelherodev>
I should just nap, and come at this again in the morning
<andrewrk>
it doesn't help with .zig source code. the analysis would not be able to use your proposed new zir instruction
<pixelherodev>
Here it definitely would
<pixelherodev>
e.g. `args[i] = try self.astGenExpr(scope, input.expr);` in genAstAsm
<pixelherodev>
astGenAsm*
<pixelherodev>
That currently sees StringLiterals and produces `str`, even though we can say for certain that if it's a literal here, it doesn't need to be emitted
<pixelherodev>
(though if an identical string is used, it *would* be; that's a different story)
<pixelherodev>
Another option might be to have the actual string generated at the first reference to it by runtime code instead of when we see the `sr`
<pixelherodev>
`str`*
<pixelherodev>
but that means an extra branch on any access to a str, which would probably be waaaay too wasteful in the long run
<pixelherodev>
... andrewrk: is there any reason we can't make `asm` ZIR take string literals instead of `str`s?
<pixelherodev>
It's definitionally incapable of taking runtime strings anyways
<pixelherodev>
... except it can take comptime strings, not just literals
<pixelherodev>
Hmm
<andrewrk>
pixelherodev, I think I would like to make inline assembly take string literals for those things yes, rather than arbitrary expressions
<andrewrk>
then this problem - which we still need to solve - would not be rearing its head for this particular use case
<pixelherodev>
That would mean that e.g. `comptime const a = "syscall"; asm(a);` would be illegal?
<andrewrk>
yes
<pixelherodev>
The question then is whether there's a valid use case for it
<pixelherodev>
... but no, I don't think we should encourage complex usage of inline asm
<andrewrk>
I was even thinking it might be nice to tokenize the asm source directly rather than having it be a string literal. but let's not get ahead of ourselves
<pixelherodev>
so asm_source goes from *Inst to []const u8?
<pixelherodev>
Should I do that?
<pixelherodev>
(and fix all the tests and inevitable breakage :P)
<andrewrk>
if you go that route you'll need to do a proposal, get it accepted (I'll wait a day or two to let someone object), update the grammar spec, update self-hosted parser and stage1 parser, update zig fmt, and then you can do that
<pixelherodev>
Righty
<pixelherodev>
I think I'll leave the CBE PR open, and we should hold off on it for now
<andrewrk>
ok
<daurnimator>
andrewrk: hang on...
<daurnimator>
objection already :)
<pixelherodev>
There's a few more things we need to decide before it can really take off anyways
<pixelherodev>
daurnimator: let's hear it! :)
<daurnimator>
one sec; going to find the proposal that I sent to allow it in the first place :P
<andrewrk>
Eleanor has some inline assembly proposals that are probably relevant as well, which I haven't familiarized myself with yet
<jaredmm>
You should doubt, because it is a gross exaggeration speared on by massive annoyance.
<pixelherodev>
lol
<pixelherodev>
Still don't doubt it
<pixelherodev>
oh crap
<jaredmm>
For whatever reason, I have been unable to build SDL2 on Windows successfully in a way that works with llvm (lld-link).
<pixelherodev>
andrewrk: you merged the CBE PR already?
<pixelherodev>
whooops
<pixelherodev>
Need to submit a new one to fix it up then :P
<fengb>
Did you break everything?
<leeward>
jaredmm: I had problems trying to cross-build with SDL2 for Windows. I took the easy route though, and gave up.
<pixelherodev>
fengb: no, but I fixed a bit that I didn't push
<jaredmm>
leeward: I also gave up, in September of last year, so my year estimate is not entirely wrong (but wholly misleading because I have not worked on it).
<leeward>
I think it counts if you're demoralized so much that you can't look at it for a year.
<pixelherodev>
^
<pixelherodev>
For sure
stripedpajamas has joined #zig
<jaredmm>
Windows in a nutshell, really.
<marler8997>
jaredmm, what issues are you running into?
dddddd has joined #zig
<jaredmm>
It was a series of issues on Windows. Exported symbols not working the same between lld-link and link.exe, libraries/DLLs not existing, not being able to build lldb-mi, SDL refusing to use anything that wasn't DX9, etc. I have it mostly working these days.
<marler8997>
gotcha, typical windows grind
layneson has joined #zig
Cynthia_ has joined #zig
dch has joined #zig
oats is now known as didymos
euantor has joined #zig
tracernz has joined #zig
<andrewrk>
xackus, did #5811 pass the `./zig build docs` for you locally, and pass tidy?
l1x has joined #zig
<andrewrk>
unfortunately there was a hiccup in the CI which would have provided testing for that PR
gonz_ has joined #zig
nikki93 has joined #zig
eddyb[legacy] has joined #zig
creationix has joined #zig
dputtick has joined #zig
utzig has joined #zig
cncl has joined #zig
lqd has joined #zig
strmpnk has joined #zig
waleee-cl has joined #zig
layneson has quit [Ping timeout: 246 seconds]
JimRM has joined #zig
<sqwishy>
Hi. My boss won't use zig unless it's 1.0, when will zig 1.0 be released so I can use zig?
<pixelherodev>
andrewrk: do you think we should tweak CBE to go outside the ZIR pipeline?
<ifreund>
a while, there won't be any corners cut. At least a year or longer I'd guess.
<pixelherodev>
?
<pixelherodev>
what did I miss? (power went out, SSH-chater restarted)
<pixelherodev>
chatter*
<ifreund>
someone asked how long until we should expect a 1.0 release
<pixelherodev>
Ah I see
Cynthia_ is now known as Cynthia
<pixelherodev>
Yeah, 1.0 isn't going to be released until stage2 and the language are 100% complete
<pixelherodev>
there won't ever be a Zig 1.1, for instance (at least in terms of the *language*; compiler bugfixes are to be expected)
<ifreund>
i think you mean there won't ever be a 2.0
<ifreund>
assuming we are semantic versioning
<pixelherodev>
both
<pixelherodev>
The language will be set in stone at 1.0 IIUC
<ikskuh>
yeah that's what i figured as well. it wants to replace C, so we have to have the same qualities in reliability
<pixelherodev>
Ahh, so we have to wait 10 years to make any changes? :P
<ifreund>
nah, just start objective-zig or zig++
<pixelherodev>
at which point we'll start working with the Zig++ team to make our language more like theirs, right?
<pixelherodev>
Or does that wait until Zig11?
<ifreund>
3011?
<ifreund>
er, guess it could just be 2111
<andrewrk>
pixelherodev, no, certainly not
kushalp has joined #zig
<andrewrk>
remember, the goal is not source to source translation
<pixelherodev>
I was thinking e.g. decl lookup is wasted effort
<pixelherodev>
s/decl/local var
<pixelherodev>
but yeah
<pixelherodev>
I see that
<andrewrk>
it's not wasted effort, it's absolutely necessary
<pixelherodev>
andrewrk: do you have an ETA on regalloc branch?
<andrewrk>
let me see if it's passing tests
<pixelherodev>
Oh neat
<andrewrk>
well I didn't add any new ones yet
<pixelherodev>
Want me to do that? :)
<pixelherodev>
hmm
<pixelherodev>
I should probably focus on CBE blockers
<pixelherodev>
Those are useful for ZIR and Zig as well, and have immediate payoffs
<pixelherodev>
And it means avoiding stepping on each others toes, hopefully
<pixelherodev>
Or maybe not, since e.g. assignment is one of the biggest ones :P
<pixelherodev>
`_ = ` should probably use a Discard MCValue or something like that
<andrewrk>
_ = should be dealt with before it gets to codegen
<pixelherodev>
Not for cgen though
<andrewrk>
why would it be different?
<pixelherodev>
For cgen, we want to know that we're deliberately discarding a result
<pixelherodev>
(void)blah();
<andrewrk>
no we don't, you're thinking of the other use case again
<pixelherodev>
I'm thinking of suppressing warnings
<pixelherodev>
Not readability of *source*, but of compilation output
<andrewrk>
I'm not following
<pixelherodev>
... never mind, apparently
<pixelherodev>
I thought that calling a function and ignoring its return value without an explicit (void) was a warning
jzelinskie has joined #zig
<pixelherodev>
So yeah, it's fine
<andrewrk>
I'm still not following
wootehfoot has joined #zig
<andrewrk>
every IR instruction is either: referenced later, not referenced later but has side effects, not referenced later + no side effects
<andrewrk>
(1) emit as `T x = foo();` (2) emit as `(void)foo();` (3) skip codegen
marnix has joined #zig
<andrewrk>
you can check ir instruction isUnused()
matti has joined #zig
ovf has joined #zig
<pixelherodev>
Ah true
dingenskirchen has quit [Quit: dingenskirchen]
<andrewrk>
you can see how this output is not going to look anything like the source
dingenskirchen1 has joined #zig
yrashk has joined #zig
<pixelherodev>
Ofc
dingenskirchen1 is now known as dingenskirchen
guan has joined #zig
betawaffle has joined #zig
cbarrett has joined #zig
karrick has joined #zig
r0bby has joined #zig
wjlroe has joined #zig
procnto has joined #zig
<pixelherodev>
andrewrk: yeah I completely see what you're getting at now
<pixelherodev>
For `_ = blah`, should we just treat it as blah and lower it?
<pixelherodev>
The only real difference is that we want to error if the `_ =` isn't present
marnix has quit [Remote host closed the connection]
THFKA4 has left #zig ["WeeChat 2.4"]
<andrewrk>
the goal is no special casing for CBE, it's just yet another machine code format
<andrewrk>
the same analysis code that handles `_` will handle it for all architectures
ur5us has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
<pixelherodev>
andrewrk: I know
<pixelherodev>
I'm talking in terms of the Zig -> ZIR part
<pixelherodev>
i'm doing more frontend work now
rzezeski has joined #zig
<ifreund>
if I just do `zig build test` that runs the std tests as one of the things right?
* pixelherodev
shrugs
<pixelherodev>
Read build.zig lol
<pixelherodev>
It says run all the tests
<pixelherodev>
So I assume so
<pixelherodev>
Yes
<pixelherodev>
It will
<pixelherodev>
test_step depends on stage2, lib/std/std.zig, test/stage1/behavior.zig
<pixelherodev>
and possibly others
<pixelherodev>
compiler-rt
<ifreund>
i was tryna be lazy :P
<pixelherodev>
lol
<pixelherodev>
So you had me do your work
<pixelherodev>
Ugh
<pixelherodev>
;(
<pixelherodev>
;0
<pixelherodev>
;) *
<andrewrk>
easy on the line spam in irc plz
<pixelherodev>
Yeah, sorry, not intentional
<pixelherodev>
Was trying to correct a typo, then corrected that :P
_Vi has quit [Ping timeout: 244 seconds]
wootehfoot has joined #zig
wootehfoot has quit [Client Quit]
stripedpajamas has quit [Quit: sleeping...]
layneson has joined #zig
st4ll1 has joined #zig
backwhack has joined #zig
shcv has joined #zig
<shcv>
is there a way to do something like closures in zig?
<shcv>
hmm; I think I found a different way to do what I wanted anyway
stripedpajamas has joined #zig
stripedpajamas has quit [Ping timeout: 256 seconds]
<pixelherodev>
andrewrk: so when translating Zig to ZIR, `_ = blah` -> `blah`?
<pixelherodev>
There's no need to explicitly drop the returned value, right?
<pixelherodev>
Hmm
<pixelherodev>
I'm envisioning targeting a fully stack-based ABI
<pixelherodev>
We'd need a way to drop the value from the stack
<pixelherodev>
Except that ZIR would still have an identifier for it, we'd just not be using it
<pixelherodev>
So it should be fine...
cole-h has joined #zig
layneson has quit [Ping timeout: 256 seconds]
<pixelherodev>
Hmm
<pixelherodev>
I need to get a better view of the astGen stuff before I try this
<pixelherodev>
And I don't have time for that right now
didymos is now known as oats
xpyxel has joined #zig
<xpyxel>
hey there! I've got a question regarding the std, I'm on windows trying to use the `os.socket` function to create a socketfd but when attempting to do so it says there's no such thing in the windows namespace
<ifreund>
xpyxel: yes, most of the stuff in std.os is posix only (there is an open issue to move this stuff to a proper std.posix namespace)
<xpyxel>
ah thanks, was curious as to why as i was looking at the `os.zig` file in the github and it looked like it was using windows sockets 2 on windows, but when i attempted to use it, it failed
<ifreund>
Yeah it looks like there is at least some support for windows sockets in the standard library, I'm not on windows though so I can't really give much advice :/
dermetfan has quit [Ping timeout: 272 seconds]
<xpyxel>
I miss linux sometimes, but i casually play some windows-only games here and there so it's hard :/
<ifreund>
looks like zig-nework's code is a good example of using the std's windows sockets
<ifreund>
no luck with wine? last time I got the itch to play skyrim it worked near flawlessly
<xpyxel>
some heavier games such as say, Rocket League (which unforunately dropped linux support officially earlier this year) has i think a bronze or silver rating on WineHQ
nikita` has quit [Quit: leaving]
xpyxel has quit [Remote host closed the connection]
<leeward>
rocket league dropped linux support?
<leeward>
Good thing I never enjoyed it.
<fraktor>
I was just thinking of getting into it too.