<andrewrk>
an untagged union would be the right way to model the data
<andrewrk>
union { non_gnu_libc: void, gnu_libc: Version }
<andrewrk>
all that would do is introduce a panic sometimes, in some build modes
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 255 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 260 seconds]
LakeByTheWoods has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 255 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 258 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 260 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 260 seconds]
frett27 has quit [Ping timeout: 240 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 255 seconds]
<LakeByTheWoods>
In translate_c do C inline functions (or other functions in imported code) get parsed with the parceC... functions or do they all go through clang and the trans... functions? I want to know if it's safe to assume that the parseC functions will always be parsing macros.
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 240 seconds]
<LakeByTheWoods>
Ah, I think I answered my over-arching question `// eventually this will be replaced by std.c.parse which will handle these correctly`
marijnfs has quit [Ping timeout: 240 seconds]
marijnfs_ has joined #zig
<andrewrk>
LakeByTheWoods, inline functions are parsed and semantically analyzed by clang. only macros are parsed and heuristically translated by zig
<LakeByTheWoods>
Awesome, thanks!
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 260 seconds]
alexnask has joined #zig
marijnfs has quit [Ping timeout: 240 seconds]
marijnfs_ has joined #zig
LER0ever has quit [Remote host closed the connection]
_Vi has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 265 seconds]
_whitelogger has joined #zig
marijnfs has quit [Ping timeout: 240 seconds]
marijnfs_ has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 260 seconds]
mahmudov has quit [Ping timeout: 258 seconds]
mahmudov has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 260 seconds]
alexnask_ has joined #zig
alexnask has quit [Ping timeout: 255 seconds]
_whitelogger has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 255 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 265 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 265 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 260 seconds]
<daurnimator>
andrewrk: so.... now with different versions of e.g. windows supported, how do we make structs different per-version?
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 260 seconds]
LakeByTheWoods has left #zig [#zig]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 255 seconds]
dddddd has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 255 seconds]
mahmudov has quit [Ping timeout: 240 seconds]
marijnfs has quit [Ping timeout: 240 seconds]
marijnfs has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 255 seconds]
marijnfs_ has quit [Remote host closed the connection]
rappet has quit [Ping timeout: 240 seconds]
rappet has joined #zig
alexnask_ is now known as alexnask
<alexnask>
andrewrk: Do you think a '@genericFunctionInstance' builtin that takes a generic function pointer and a tuple of argument types and returns a funcion pointer would be reasonable?
<alexnask>
I feel like it could be useful for metaprogramming if you are using tuples and @call to generate functions (e.g. in std.interface if I could generate a tuple type from a slice of types and had this builtin I could generate vtable functions for any number of arguments)
<alexnask>
Right now I am forced to switch on the number of arguments and generate a closure accordingly, since using a tuple argument would make the function generic
<pixelherodev>
So I just learned that LLVM supports both ATT and Intel syntax for inline asm
<pixelherodev>
Not sure why I was surprised by that
<pixelherodev>
... unless shrinkFn is a function pointer, which I vaguely recall being accurate
<daurnimator>
pixelherodev: it's not a method, its a field
<daurnimator>
yeah
<pixelherodev>
Can you change which field of a union is active without assigning it to a freshly initialized union?
<pixelherodev>
That is, `const a = union {A: blah, B: blob }; const b = a{.A = blah};`; can you do `b.B = blob`? or do you need to do `b = a {.B = blob}`?
<alexnask>
andrewrk: Scratch that, passing a slice of argument types wouldn't work, it would need to be a tuple of types + comptime values I guess but then building a tuple is a whole other issue
<daurnimator>
If we get @reify, I wish it could synthesize from a list of field names, types and offsets
<daurnimator>
where the offsets don't have to be in order
<daurnimator>
would be helpful when reverse engineering
<daurnimator>
but also when creating struct definitions from specs
<daurnimator>
TIL the windows TEB has: `StaticUnicodeString` and its Buffer seem to be provided as a convenience for pretty much any API function that has temporary need of a pathname-sized buffer.
metaleap has joined #zig
jessermeyer has joined #zig
<jessermeyer>
How am I to report compiler bugs like 'Assertion failed at D:\a\1\s\src\analyze.cpp:1003 in get_fn_type. This is a bug in the Zig compiler. Unable to dump stack trace: debug info stripped'?
<jessermeyer>
The code base I have isn't exactly small.
<jessermeyer>
It's not huge either tho.
<jessermeyer>
Also, the file path in that assertion doesn't make sense to me since the compiler and src are stored on C:.
<daurnimator>
jessermeyer: did you compile your zig executable yourself?
<jessermeyer>
So unless Zig is creating a tmp directory on D (which would be a bad move here, since that's a platter disk drive), I dunno.
<jessermeyer>
Nope.
<daurnimator>
its a reference to where zig was on the machine that compiled zig
<jessermeyer>
Nightly as of... yesterday I believe.
<jessermeyer>
Zig is not stored on my D Drive.
<daurnimator>
jessermeyer: and are you the machine that compiled zig?....
<jessermeyer>
Oh, I missed 'that compiled zig'.
<jessermeyer>
Sorry, eyes go too fast.
<jessermeyer>
I've isolated the compiler bug down to the first inclusion of a vulkan type. var instance = zeroes(VkInstance);
<jessermeyer>
That type comes to me through translate-c.
<jessermeyer>
So, maybe the compiler can't zero out that field since it's opaque?
<metaleap>
after updating zig to current nightly (after keeping it unupdated for maybe ~10 days or so at my end), std.io.BufferedInStream seems to have a new bug where it's blocking itself forever or sth when using it like `&std.io.BufferedInStream(std.os.ReadError).init(&std.io.getStdIn().inStream().stream).stream);`. my 2 langservers (dummy one and zig-wip one) had "no stdio going on seemingly" (radio silence instead of back+forth chatter) until i temporarily
<metaleap>
switched back to `&std.io.getStdIn().inStream().stream`. (after lettin off some steam that is). seems like i hit sth that unit tests didnt, will take a look
TheLemonMan has joined #zig
<alexnask>
jessermeyer This is (obviously) a compiler bug, intended behavior is a @compileError() from mem.zeroes
<jessermeyer>
I submitted an issue with minimal repo.
<alexnask>
Yeah I saw it, just calrifying what should happen
<alexnask>
clarifying*
<jessermeyer>
Agreed, thanks. :)
<TheLemonMan>
the intended behavior is an error from the compiler
<TheLemonMan>
@opaqueType is not a valid return type
<jessermeyer>
The assertion helped me track down what went wrong. That's rare in my experience.
<jessermeyer>
At least this far removed from the source of the problem.
<alexnask>
mem.zeros checks for Opaque types and @compileErrors (along with other unsupported types)
<TheLemonMan>
compilers are complex beasts
<jessermeyer>
Smells like a regression then.
sammich has quit [Read error: Connection reset by peer]
<TheLemonMan>
nope, there's a missing error check in the semantic analisys code
sammich has joined #zig
<frmdstryr>
Yo TheLemonMan, I have another arm related issue that I'm hoping you can help with
<TheLemonMan>
shoot!
<frmdstryr>
So this was happening before the change to llvm10
<frmdstryr>
Still occurs with llvm10
<frmdstryr>
The code works fine in debug mode but when building with release-safe it hard faults when loading main.main
<frmdstryr>
the instruction it's hard faulting on is vpush {d8-d15}
<TheLemonMan>
hmm, misaligned stack?
<frmdstryr>
and i've narrowed it down to something with the inner loop in display.zig line 698
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
meraymond2 has joined #zig
<fengb>
daurnimator: using streams seems to be a lot easier. I might actually be able to get it working this weekend
jjido has joined #zig
<andrewrk>
daurnimator: re: "TIL the windows TEB has: `StaticUnicodeString` and its Buffer seem to be provided as a convenience for pretty much any API function that has temporary need of a pathname-sized buffer."
<andrewrk>
Wow that's an incredibly useful find!
<andrewrk>
A couple things to verify though: is it per thread? Does it work with IOCP? What if applications are using it, will we suprise people by clobbering the data?
meraymond2 has quit [Remote host closed the connection]
<TheLemonMan>
andrewrk, I have a nice solution for the osx version detection problem, but only works from High Sierra onwards
<frmdstryr>
Can I somehow cast a fixed sized multi dimentional array to a slice of slices?
<jessermeyer>
Is it possible to include comptime const variables in debug information for inspection? I'd like to constify where-able, but I'm not generally in favor for that if it hinders debuggability.
<alexnask>
I think there is an issue open about this
<BaroqueLarouche>
I want to do those formats: GIF, PNG and JPEG
<BaroqueLarouche>
PNG is very high priority
<shakesoda>
yeah, rather important
<shakesoda>
dumping tgas to disk is just extremely easy to write and useful for generating graphics
<shakesoda>
so i hacked that up some weeks ago
<BaroqueLarouche>
wow look so simple to write
<BaroqueLarouche>
(TGA)
<shakesoda>
feel free to use that code, it's only the most basic case but it is enough to be useful
hazeycode has joined #zig
<hazeycode>
Hi Zig people!
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mq32>
hey hazeycode
<hazeycode>
I have a silly question... I couldn't find the answer in the docs... is there a way to pass a comp time var through zig build? i.e. `zig build --gfx_backend=VULKAN` ?
<metaleap>
hazeycode: everything you pass following `zig build` is *definitely* accessible from your `build.zig`, but from other source files (those being *built*) i dont think so. or if it is i never heard about it.
<metaleap>
if you do `zig builtin` you see all the stuff coming from the build-time that your to-be-built source files have access to at comp-time
jjido has joined #zig
<hazeycode>
Thanks metaleap! Do you know a good approach for achieving something along the lines of the following?
<metaleap>
the only hack you could do is that the param in your build.zig and write some "my_generated.zig" file before building. then your other code @import("my_generated.zig")
<metaleap>
s/that/take
<mq32>
hazeycode: ½ Answer: You can add custom options/defines to zig build with
<metaleap>
oh nice i didnt know about that. still this is only accessible in build.zig and to "pass it into the src-files about to be built" would require some .zig file-gen'ing right?
<hazeycode>
Nice! Thanks guys that's a huge help
<hazeycode>
It's kinda a shame (I think) it could be cool to have something like a compile time getenv kinda thing
<mq32>
i don't know if that fits the spirit of zig
marmotini_ has joined #zig
<mq32>
it's a thing that always bugged me about a lot of C libraries
<mq32>
you can configure the hell out of em
<mq32>
the best possible outcome is a single executable for an os/platform combination
<metaleap>
a comptime dict to be instrumented when the compiler is invoked? sounds like a decent idea to me. but yeah better keep those build-opts nicely-described and dont do silent defaults then
marmotini_ has quit [Ping timeout: 260 seconds]
LakeByTheWoods has joined #zig
<hazeycode>
I guess the proper way to have modular program layers is to build them as separate fragments that you switch on at build time and have a single interface.zig to import. I think that would be nicer than the hack I'm trying atm
<mq32>
yeah,, just make multiple files
<mq32>
as you are building multiple executables
<hazeycode>
Ok yeah I'll do that and make use of `pub fn option(self: *Builder, comptime T: type, name: []const u8, description: []const u8) ?T`... thanks for the advice!
<hazeycode>
It is possible to separate declarations from definitions right? With regard to said interface.zig
<alexnask>
Iirc you want to do something like std.zig
<alexnask>
If I understand correctly* woops brainfart
rjtobin has joined #zig
<hazeycode>
alexnask possibly yeah. I guess my problem is the same as building std.zig; specifying a platform layer to build and link against while maintaining a portable interface, in the future I may have a PS4 layer for example that I want to swap in easily. I'll take a look at how std.zig is built
<alexnask>
Ah right, I would recommend you take a look at how std.os stuff is handled
<hazeycode>
Thanks!
<alexnask>
It's really easy and graceful in zig though, you basically just have conditional imports
<hazeycode>
Yeah that was sort of my original question, how do I get a comp var through zig build to do said conditional import
<alexnask>
Right, not sure about setting custom globals through the build system
<alexnask>
A hack like defining them in some options.zig file generated by build.zig like someone mentioned will work for sure
<alexnask>
But it does sound like a useful thing to build into the build system/compiler
metaleap has quit [Quit: Leaving]
hazeycode has quit [Ping timeout: 260 seconds]
hazeycode has joined #zig
<mq32>
BaroqueLarouche: do you think it's a good idea to have a library for loading/saving images AND modifying the image contents?
<BaroqueLarouche>
mq32: yes
<mq32>
hmm
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mq32>
yeah, makes sense probably
<mq32>
What about gpu acceleration?
<BaroqueLarouche>
if we implement image filers, why not
dddddd has joined #zig
jessermeyer has quit [Remote host closed the connection]
<andrewrk>
There is zig build API to do this. It's not well documented
<andrewrk>
But it's a good use case that is supported
<andrewrk>
That was in response to hazeycode
<BaroqueLarouche>
andrewrk: did you see the compilation erro I reported a while back ?
karrick has joined #zig
<hazeycode>
Thanks andrewrk that's great news to me! Good you point me in the right direction of this API?
<hazeycode>
*Could
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
ur5us has joined #zig
marmotini_ has joined #zig
hazeycode has quit [Ping timeout: 260 seconds]
marmotini_ has quit [Ping timeout: 258 seconds]
hazeycode has joined #zig
jjido has joined #zig
<mikdusan>
hazeycode: I think this example should help: