ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<GitHub165> [zig] dimenus opened pull request #617: Added DLL loading capability in windows to the std lib. (master...dll-load) https://git.io/vFyLn
dimenus has joined #zig
<andrewrk> dimenus, can you read the other comments I posted on the previous pull request?
<dimenus> just need to tag 534 i think
<dimenus> the return was modified and i didn't include the checking we mentioned earlier
<dimenus> GOD DAMN TABS
<dimenus> sorry, tests failed due to tabs :(
<andrewrk> you can use -Dtest-filter=foo to target some tests only
arBmind1 has joined #zig
arBmind has quit [Ping timeout: 240 seconds]
<andrewrk> dimenus, oh, sorry I guess my other comment didn't get added
<andrewrk> adding now
jfo has quit [Ping timeout: 248 seconds]
<dimenus> i think VR is one of the few things keeping me on windows
<dimenus> pacman is so superior to anything windows has
<dimenus> andrewrk, sorry i don't understand the full command syntax to execute specific tests
<andrewrk> bin\zig.exe build --build-file ..\build.zig --help
<andrewrk> example:
<dimenus> that's neat
<andrewrk> bin\zig.exe build --build-file ..\build.zig "-Dtest-filter=DLL error" test-std
<GitHub59> [zig] andrewrk pushed 2 new commits to master: https://git.io/vFyC9
<GitHub59> zig/master 1473eb9 Andrew Kelley: add documentation placeholders for unions
<GitHub59> zig/master d108689 Andrew Kelley: Merge branch 'unions'...
<dimenus> nice
<dimenus> also, interesting bug : F:\code\tools\zig\std\index.zig:61:38: error: expected type '&Allocator', found '&Allocator'
<dimenus> lol
<andrewrk> oops
<andrewrk> why is it saying that?
<dimenus> in a test i created in std/index.zig
<dimenus> test "InvalidDll" {
<dimenus> const std = @import("std");
<dimenus> const DllName = "asdf.dll";
<dimenus> const allocator = std.debug.global_allocator;
<dimenus> const assert = @import("std").debug.assert;
<dimenus> const handle = os.windowsLoadDll(allocator, DllName) %% |err| {
<dimenus> assert(err == error.DllNotFound);
<dimenus> };
<dimenus> }
<dimenus> oops double std import
<andrewrk> it's no big deal, results in the same imporrt
<andrewrk> hm that's strange
<andrewrk> I'll have a look
<andrewrk> oh
<andrewrk> I think I might know
<andrewrk> does it add "note: Allocator defined here" for each one?
<andrewrk> I bet one is in std/mem.zig and one is in build/lib/std/mem.zig
<dimenus> no, but i got rid of it by fixing the imports
<dimenus> i used debug defined higher up
<dimenus> hmmm, the test system doesn't link kernel32 though
<andrewrk> it should
<andrewrk> it uses std.debug.warn
<dimenus> oh, it's passing -lkernel32
<dimenus> i thought i fixed that o.0
<dimenus> test runs fine from os/windows/util.zig
<dimenus> so i moved it there
<dimenus> that way it doesn't try to fire on other systems either
<andrewrk> cool
<dimenus> btw, that test-filter seems to only work if you put the test in the index.zig of the top of a module
<andrewrk> you can also do e.g. if (builtin.os == builtin.Os.windows) { ... }
<andrewrk> maybe you're running into lazy analysis issues
<andrewrk> if you put the test in a file that doesn't get imported, it won't find the test
<dimenus> it finds the test, just not if i put in that filter
<dimenus> if i put it in std and use the filter that fires
<dimenus> but if i put it in std\os\windows\ it doesn't fire with the filter
<andrewrk> oh, hm. I think this is a little disorganized
<andrewrk> so if you look at std/index.zig
<andrewrk> those imports at the bottom are to load files for the purpose of testing
<andrewrk> and they're not getting loaded because your filter didn't match "std"
<andrewrk> kinda silly, sorry about that
<dimenus> no worries, test works fine from the location i put it in
<dimenus> so i'll probably update the PR soon
ryan__ has joined #zig
dimenus has quit [Ping timeout: 248 seconds]
tiehuis has joined #zig
<GitHub120> [zig] andrewrk pushed 1 new commit to master: https://git.io/vFy4E
<GitHub120> zig/master b50c676 Andrew Kelley: add parse-c support for unions
jfo has joined #zig
jfo has quit [Ping timeout: 255 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 255 seconds]
arBmind1 has quit [Quit: Leaving.]
arBmind has joined #zig
arBmind1 has joined #zig
arBmind has quit [Ping timeout: 260 seconds]
tiehuis has quit [Quit: WeeChat 1.9.1]
jfo has joined #zig
jfo has quit [Ping timeout: 255 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 248 seconds]
ryan__ has quit [Quit: Leaving]
jfo has joined #zig
jfo has quit [Ping timeout: 268 seconds]
jfo has joined #zig
dimenus has joined #zig
fraya has joined #zig
fraya has quit [Quit: Leaving]
jfo has quit [Ping timeout: 248 seconds]
jfo has joined #zig
<GitHub94> [zig] andrewrk closed pull request #617: Added DLL loading capability in windows to the std lib. (master...dll-load) https://git.io/vFyLn
<GitHub177> [zig] andrewrk pushed 2 new commits to master: https://git.io/vFSlJ
<GitHub177> zig/master a7d07d4 dimenus: Added DLL loading capability in windows to the std lib.
<GitHub177> zig/master 3e83597 Andrew Kelley: Merge pull request #617 from dimenus/dll-load...
<dimenus> thanks andrewrk
<dimenus> also i found a case your union code doesn't quite support yet :)
<dimenus> nvm, i haven't built latest zig.....
<andrewrk> dimenus, I think our macro parser doesn't understand field access
<andrewrk> but we can add that
<dimenus> yeah the unions look properly formatted now in the output
<dimenus> which is good
<dimenus> (using latest zig)
jfo has quit [Ping timeout: 240 seconds]
<andrewrk> dimenus, I think it's just a matter of adding a '.' token to c_tokenizer.cpp and then updating parse_ctok in parsec.cpp to look for field access, and create a zig FieldAccess AstNode
<dimenus> cool
<dimenus> i could probably work on that later today
jfo has joined #zig
<GitHub182> [zig] andrewrk pushed 1 new commit to master: https://git.io/vFSKW
<GitHub182> zig/master 339d48a Andrew Kelley: parse-c: support address of operator
jfo has quit [Ping timeout: 248 seconds]
<dimenus> andrewrk: c-tokenizer is hardcoded to see that a '.' in a macro indicates we're parsing a float :)
<andrewrk> oops :)
jfo has joined #zig
jfo has quit [Ping timeout: 248 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 248 seconds]
arBmind1 has quit [Quit: Leaving.]
jfo has joined #zig
arBmind has joined #zig
<dimenus> andrewrk, in this macro '#define glClearUnion glProcs.Clear' what AST node should be returned to result_node?
<dimenus> glProcs or Clear?
<andrewrk> dimenus, NodeTypeFieldAccessExpr
<dimenus> yeah i just figured it out
<dimenus> looks like it works
<andrewrk> nice!
<andrewrk> now that we have unions I'm motivated to try to get even more c-to-zig translation working
<dimenus> yeah now you should be able to use macros that target struct or union fields
<dimenus> i don't know how common this type thing is, but i've seen it a lot in OpenGL
<dimenus> I was thinking yesterday about making a function loader in zig, but idk if that's even worth it
<dimenus> at this point i'd rather build something around Vulkan
cenomla has joined #zig
<andrewrk> I haven't tried vulkan yet but I'm excited to
<andrewrk> if we had a high quality cross platform library that competed with GLFW and gave you a vulkan context, and then exposed a C interface
<andrewrk> I think that would draw many people to zig
jfo has quit [Remote host closed the connection]
jfo has joined #zig
<jfo> andrewrk can I ask you abt returning a dangle? https://gist.github.com/jfo/798a7cb66ae782f770e682cc0d37c852
<andrewrk> jfo, yes, we do not have advanced value tracking yet
<jfo> yat \o/
<andrewrk> there is a whole class of compile errors that can be enabled when we have it
<jfo> awesome
<andrewrk> and faster debug code that omits safety checks when it knows they're unnecessary
<dimenus> andrewrk, just hit 'unable to evaluate constant expression' @ ir.cpp:6631
<dimenus> only triggers on my macro'ified union situation
<dimenus> getting two errors per one function call (same message)
<andrewrk> can I see the zig code that has the error?
<dimenus> yes
<dimenus> '?extern fn(c_uint)
<dimenus> how do you unwarp that?
<dimenus> i want to use that function
<andrewrk> do you want to assert that it is nonnull? or check if it is null before calling it? it works like every other nullable type
<andrewrk> oh god the docs are wrong
<andrewrk> #465 can't come quickly enough
<andrewrk> (??fn_name)(x)
<andrewrk> this asserts that it is non-null
<dimenus> probably not good to stick in a loop though
<dimenus> getting you an example btw
<andrewrk> it's fine to put in a loop, here's why
<andrewrk> * if it's in a performance bottleneck, you'll use @setDebugSafety(this, false) to disable all the debug safety checks for that block of code, making it perfectly free, just like ReleaseFast mode
<andrewrk> * if it's not in a performance bottleneck, you won't notice it being slow
<dimenus> that union is really 657 items long, i just chopped it out
<dimenus> :)
<dimenus> oops, forgot the function pointers
<andrewrk> I think there are 2 things going on here
<andrewrk> 1. the code in process_symbol_macros in parse.cpp is fooled by field access, so it doesn't do the thing where it makes an inline function alias that ignores the possibility of null
<andrewrk> if you added that I think it would make this work
<andrewrk> 2. maybe we have a compiler crash if you try to execute a nullable function pointer right now, I'll have to check. we definitely want to fix that
<dimenus> i also ran into another crash working on this, i don't think it's related though
<dimenus> ~6302:ir.cpp
<dimenus> return buf_sprintf("(anonymous %s at %s:%" ZIG_PRI_usize ":%" ZIG_PRI_usize ")", kind_name,
<dimenus> (source_node->owner->path == NULL) ? "NULL" : buf_ptr(source_node->owner->path), source_node->line + 1, source_node->column + 1);
<dimenus> the null check wasn't there before and path was null
<andrewrk> oh, I ran into this earlier today but I didn't fix it yet
<dimenus> i realize what i did was a hack, just trying to debug other stuff
<andrewrk> this problem is because we assume AstNodes have info about what zig import file they came from, but if they come from C that value is null
<dimenus> ah, it gets put in the c->macro_table instead of the c->macro_symbol table
<dimenus> I think MacroSymbols should store a handle to their AST nodes so that in process_symbol_macros we can verify that we're at the top of the chain before checking if we're in the global table
<andrewrk> that sounds reasonable
<dimenus> what's happening now is that even if i put field expressions in the macro symbol table instead of the regular macro table
<dimenus> they still won't get an inline function because they're not in the globals table (top level anyway)_
dimenus has quit [Quit: Leaving]
cenomla has quit [Ping timeout: 258 seconds]