<marler8997> would the ".Foo" syntax work with "enum { pub const Foo = ... }" ?
<marler8997> is the motivation behind removing aliases just because aliases are bad practice? Like, there's no reason to support them?
<marler8997> but if/when enum aliases are removed completely?
<marler8997> so if I see multiple enum values with the same value, I should choose one?
<marler8997> ah
<marler8997> what's a field alias though?
<marler8997> aliased field?
<marler8997> what about zigwin32/api/internet_explorer? that's the next biggest one but includes more than just aliases
<marler8997> ah I see, that's cool to see
<marler8997> 7 MB of tokens !
<marler8997> of course it does, I wrote it :)
<marler8997> I'll start with a single file then, and go from there
<marler8997> or a single file
<marler8997> so, I suppose std could maintain a list of functions it wants, and the files they would go into
<marler8997> I modify my tool to take this list and generate the std bindings and the "extended" bindings
<marler8997> this would in turn pull in the types and constants it needs as well
<marler8997> what I'm thinking is, we maintain a list of all the functions that std requires and/or wants to pull in
<marler8997> I like your first option
<marler8997> now way, I don't think we should include the full set of bindings in std
<marler8997> so design the file structure by category/commonaility of use?
<marler8997> it's 12 MB on its own!
<marler8997> everything.zig more of an idea at the moment
<marler8997> I didn't include everything.zig in that, 55MB including that :)
<marler8997> btw, full bindings is about 43 MB of source code
<marler8997> for example, I could put all the win32 bindings in a single file
<marler8997> andrewrk, not necessarily, just wondering what your thoughts were on it
<marler8997> with the generated bindings, we now have a good idea of how big a full set of win32 bindgs is: https://github.com/marlersoft/zigwin32/tree/main/src/win32
<marler8997> oh that one, yes I'm familair
<marler8997> will read
<marler8997> andrewrk, what are your thoughts on splitting the windows bindings in std by the dll they appear in? Do we want to continue this route?
<marler8997> .
<marler8997> I see this sort of thing all the time in firmware, you see errors all over the place and it can be hard to track down the real initial error. Sometimes it can be good to tell the system to just quit on the first error so you don't have to play detective to figure out where things initially went wrong
<marler8997> so in this case, B is a red herring
<marler8997> if you exit on first failure, you would stop on test A, but if you would continue, it would go on to test B and say it failed as well, even though that test is not broken, it's only broken because test A corrupted it
<marler8997> I think an example would help. say test A is corrupts memory, and it causes test B to fail
<marler8997> if a test failed and that's the only test you ran, I don't know how that test could be a red herring...?
<marler8997> but I was saying that this would eliminate red herrings that are caused by the initial failure, and continuing to run the tests instead of exiting
<marler8997> there are other kinds of red herrings
<marler8997> by "red herring", I was meaning, something that failed because of something else
<marler8997> you wouldn't get a red herring because you would have exited before you got to it
<marler8997> not sure you like an option to quit on first failure? or the proposal?
<marler8997> sometimes, the first error can cause a cascade of other failures that are just red herrings
<marler8997> to eliminate cascading failures
<g-w1> marler8997: why would you want an option to quit on the first failure?
<marler8997> second question, do we want to trim what's in the std library?
<marler8997> first question, do we want to keep the "separate functions by dll" design in std?
<marler8997> andrewrk, I'm looking into win32/std integration and got some questions if you're available
<marler8997> nice
<marler8997> nah, defer if (something) try foo();
<marler8997> with successdefer, the block can return an error
<marler8997> I agree with the way defer is currently designed, this only makes sense for a successdefer
<marler8997> you can't return errors in a defer block
<marler8997> it's the "try" that causes the issue
<marler8997> it just seems odd that I have to erase the error type
<marler8997> I think in my case, using "defer foo catch unreachable" is better than using a labeled block
<marler8997> I see, successdefer is not common enough to warrant the benefits of keeping init/defer code close together
<marler8997> if we use labeled blocks, why have defer at all?
<marler8997> will have to put it in all the return locations
<andrewrk> marler8997, I've found it pretty reasonable for this use case to just put the footer logic at the bottom without trying to defer it
<marler8997> andrewrk, here's the gist of what I'm doing: https://gist.github.com/marler8997/9d6a8e9aa53378388957e4c9824de525
<marler8997> since you can't do "try" inside a normal defer
<marler8997> yeah, I just had a use case where I wanted to do "try foo()" inside a defer, but it only makes sense on successdefer
<marler8997> is there a proposal for successdefer that would allow errors inside the block?


<andrewrk> marler8997, I was thinking along the same lines
<marler8997> for example, instead of defining it's own type for SOCKET's, it would just reference std.os.windows.SOCKET
<marler8997> so what I'm thinking, is the extended/full set of windows bindings, would actually reference whatever is defined in the standard library
<marler8997> the std lib will always have some of the windows bindings I'm guessing yes?
<marler8997> andrewrk, wanted to gauge what direction you see the std lib going with windows bindings


<marler8997> that does produce some much better optics
<marler8997> what was the fix?
<marler8997> ugh, flaky ci failures are the worst
<marler8997> feck
<andrewrk> marler8997, no, this was a particularly YOLO release from upstream and we are still dealing with the consequences
<marler8997> andrewrk, did everything work out with the llvm 12 release?


<marler8997> yeah it's an interesting one
<marler8997> andrewrk, ok
<andrewrk> marler8997, status quo: no
<marler8997> does Zig guarantee that a value being assigned is always valid while being used on the right hand of an assignment? even if the value is aliased on the right hand side? i.e. https://gist.github.com/marler8997/64338f902027783d2159abbaf796b6a6


<g-w1> marler8997: my os src is not up yet, but it doesn't run on bare metal yet, only qemu
<marler8997> that blx instruction issue looks very similar, I think I was getting blx instruction errors when compiling for the gameboy advance arm7 chip
<marler8997> oh it's just the boot.S file so far, nothing else?
<marler8997> g-w1, is it on github? link?
<marler8997> we might be able to help more if you show us some code
<nefix> marler8997: I haven't understood a thing of what I've just read xD
<marler8997> nefix, if you're into reading, you can take a look at https://github.com/ziglang/zig/issues/980


<marler8997> I'm trying to figure out why pragmas would work with native compilation but not cross ...?
<marler8997> it seems like it's a native vs cross compilation issue
<marler8997> also windows.h not found...am I missing something?
<marler8997> that's odd, with -Dtarget=i386-windows and -Dtarget=x86_64-windows, I get "winsock2.h" not found?
<marler8997> let me check what it does for the other targets
<marler8997> I assume that's what it does for the native target
<marler8997> yeah pragma lib is pretty nice sometimes. I supposed it would have to be clang that reports it to Zig
<marler8997> unfortunately, Zig development on windows always seems to be a field of landmines :(
<marler8997> here's the second issue: https://github.com/ziglang/zig/issues/8544
<marler8997> oh no, it's not the symbols that are missing. For some reason when I use -Dtarget=native-native-gnu, the #pragma(lib, "ws2_32.lib") is being ignored?
<marler8997> shoot, I may have found another bug. When I compile with -Dtarget=native-native-gnu, the ws2_32.lib symbols seem to be missing
<marler8997> I'll create an issue :)
<marler8997> should it be working with build-exe as well?
<marler8997> andrewrk, I was using build-exe, but I think it's working now that I've created a build.zig and am now using that
<andrewrk> marler8997, yes that's how it's supposed to work, it shouldn't be looking for windows sdk with that triple
<marler8997> visual studio is not installed on this machine, I thought the native-native-gnu would get around that though...?
<marler8997> zig build-exe -Dtarget=native-native-gnu -lc ... prints an error that says WindowsSdkNotFound


<marler8997> yeah it kinda seems like that huh? :)
<marler8997> copied from proposal: naming conventions, the choice to return values or references, handling mutable vs const references to @This(), and requiring the caller to go through a function that can execute arbitrary code when all they want to do is access the field.
<marler8997> getter functions is one solution but comes with it's own problems
<marler8997> copied from the proposal: ...The problem is there's no way to forward a field from from a nested type to the parent. Unlike functions that can forward calls to other functions, fields have no ability to do this....
<marler8997> oh, I have a proposal for that :)
<marler8997> ?
<marler8997> you could put your code in one of them, and have the other one just forward calls to the other
<marler8997> not sure that's what I'm looking for, the use case here is my buildpkgs proposal is incomplete, a module needs a way of reporting it's "package path" to the build system, but a modules package path shouldn't affect it's compilation, so I'm wondering if there's a way to give it access to the path at runtime, but not allow it to read the contents at comptime
<andrewrk> marler8997, var x = "foo".*;
<marler8997> I mean, you could just declare it as extern and link it in later, but I'm wondering if you could do it in pure zig without compiling it separately
<marler8997> is there a way or a trick to create a string constant, but not allow it's contents to be used at comptime?
<marler8997> @tryImport might be mentioned, maybe just briefly
<marler8997> agree, this alone wouldn't justify @tryImport
<marler8997> since std is always evaluated, it adds a "hook" into std that allows the "start" package to be overriden, and it's nice because it's implemented in the std library instead of being hardcoded in the compiler
<marler8997> if we had @tryImport, then std.zig could do something like: comptime { _ = if (@tryImport("start")) |s| s else @import("start.zig") }
<marler8997> andrewrk, I had another idea to solve the start bootstrap problem


<marler8997> if we implemented the "start" package, could we remove the hardcoding in the compiler to always import std.zig?
<marler8997> :) lol
<marler8997> ok, ttyl then
<marler8997> I guess I'm becoming convinced that "start" is special enough to warrant an explicit feature like this, rather than relying on the compiler always evaluating std and the _ = start lines in std.zig
<marler8997> but with an explicit "start" feature, the "start" package always gets evaluated, so now we don't need #2 in std, which divorces std from the startup code
<marler8997> the issue with gba is we can't really solve 1
<marler8997> right now, std/start.zig works because of 2 things, 1) std.zig is always evaluated and 2) there is a _ = start in std.zig
<marler8997> the interface is also a bit more explicit/clear I think
<marler8997> not saying this is the main difference, but this one could be enforced I think, in start.zig, comptime { assert(@import("starg") == @This())) }
<marler8997> thinking...
<marler8997> so basically "std/start.zig" would get set to "start" by default, but could be overriden
<marler8997> reserve the package "start" to contain the module that has the export to start the evaluation chain
<marler8997> Ok I'm just back to the "start" idea, I think I'm liking that more now
<marler8997> "entry" is the module that always gets evaluated, "app" is where the user defines "main" and whatever else
<marler8997> maybe we should have an "app" module and an "entry" module?
<marler8997> but no, the root module is where the user can configure things
<marler8997> more thinking out loud, what if we made "start.zig" the root module for executables?
<marler8997> it's not a good solution, just thinking out loud at the moment :)
<marler8997> so in my case, comptime { _ = main; } doesn't cause main to be exported directly, but it causes it to be evaluated which causes @import("gba") to be evaluated which in turn causes start.zig to get evaluated...
<marler8997> right, unless you imported the module inside main
<andrewrk> marler8997, comptime { _ = main; } wouldn't do anything because it doesn't export anything. if you did export fn main() then it would work and you don't need the comptime
<marler8997> if we find value in not requiring the user to include comptime { _ = main; }, then we would be adding that same "value" to third party libraries as well
<marler8997> so if we're saying that we're ok with requiring all users to use comptime { _ = main; }, the why would "std" get special treatment?
<marler8997> right now Zig is hardcoding std.zig to always be evaluated whether or not it is used, which is why helloworld works without comptime { _ = main; }
<noam> marler8997: why would that be needed?
<marler8997> comptime { _ = main }; fn main() void { ... }
<marler8997> whatever solution we use, I feel like we'd have to be ok with requiring it on helloworld.zig as well
<noam> marler8997: `_ = foo;`?
<marler8997> here's another idea, what if we included a way to force function to be evaluated but not export it?
<marler8997> interesting
<andrewrk> marler8997, in C this is solved by putting other source files on the command line (with separate compiler invocations). there's nothing stopping us from doing that in zig, however I think it's better having a root source file and to have the source code decide what other files to import, specifically because it allows you to use comptime logic to selectively import
<marler8997> ok, well, that kinda seems like a similar issue
<andrewrk> marler8997, yes that's currently the way to do it
<marler8997> *would you use
<marler8997> if one were to write say a dynamic library in Zig, and you had exports split amongst multiple files, you use comptime { _ = @import("funcs1.zig); _ = @import("funcs2.zig"); } ??
<marler8997> I'm trying to think if there are use cases where you'd want this behavior on things besides the program entry point
<marler8997> or, we could add a command-line option to provide a "start.zig" module?
<marler8997> for example, we could reserve the "start" package, and allow the user to set it
<marler8997> we could create another special package name for this
<marler8997> yeah it seems related
<marler8997> that could get kinda hairy for a library that runs on multiple platforms
<marler8997> sounds possible
<ifreund> marler8997: you said forgetting it produces an invalid rom. Can you trivially check if the produced binary is invalid?
<marler8997> do you have a way that forgetting it could cause a good error message?
<marler8997> I mean, import gba/start.zig
<marler8997> yeah, we never get far enough to import start.zig
<andrewrk> marler8997, seems like start.zig should unconditionally do `_ = root;` do you see any reason why this is insufficient?
<marler8997> I'm almost done creating an issue to describe this problem and a potential solution
<marler8997> ah, thanks for the reference
<marler8997> const _ = @import("std"); wouldn't do anything
<marler8997> well, comptime { _ = @import("std"); } right?
<marler8997> andrewrk, yeah I kinda surmised that
<andrewrk> marler8997, the zig compiler effectively hard codes `_ = @import("std")`
<marler8997> if they don't put it, it compiles fine and you just get an invalid rom image
<marler8997> yes that works
<marler8997> maybe we could add a new field to std.build.Pkg like "force_eval"?
<marler8997> it looks like std.zig get imported/evaluated even if you don't explicitly @import it
<marler8997> compile_var_package looks interesting, maybe it has to do with that?
<marler8997> that just adds it to the package table, it doesn't force it to be "evaluated" as far as I know
<marler8997> but wait
<marler8997> ah
<marler8997> yeah could be
<ifreund> marler8997: pretty sure that std.zig import is hardcoded in the compiler
<marler8997> I'm hoping there is some configuration in build.zig that will allow me to force a module to get imported, so it works just like std.zig
<marler8997> however, what forced "std.zig" to get imported in the first place?
<marler8997> the std library does the same thing, it has comptime { _ = start } in std.zig, which forces start.zig to get imported
<marler8997> the startup code is identified by a link section, and is located in a zig module in the gba library, problem is, how do you force zig to import a library?
<marler8997> I've created a new library based on the existing ZigGBA one, which uses a custom linker script
<marler8997> I've got an issue with compiling a Gameboy Advance rom that I'm not sure how to solve, maybe someone has ideas


<Raito_Bezarius> Wow marler8997 :D
<marler8997> oh interesting, I've only debugged EFI on hardware with a lauterbach
<Raito_Bezarius> yes marler8997
<marler8997> out of curiosity, how are you running your efi app? qemu?
<marler8997> its pe/coff I believe


<marler8997> does anyone want to be my impartial judge and tell me if I'm taking crazy pills on an issue with win32metadata?


<marler8997> ok
<andrewrk> marler8997, yeah I like that strategy. we already have a dependency on allocating that size on the stack on windows
<marler8997> yes, ArrayHashMap is insertion order
<marler8997> yes
<marler8997> you might be able to leverage the parser logic in std.json and create your own object
<marler8997> yeah that's exactly what I needed it for in Dlang as well
<marler8997> I ended up having to implement my own parser rather than using the one in std
<marler8997> lol, I spent a bunch of time trying to get a round-trip json parser in Dlang :)
<marler8997> so, we create the path on the stack, then call the nt function with that stack memory reserved?
<marler8997> > The maximum path of 32,767 characters is approximate, because the "\\?\" prefix may be expanded to a longer string by the system at run time, and this expansion applies to the total length.
<marler8997> but I suppose with our own implementation we wouldn't be subject to that
<marler8997> well, it looks like that might be the maximum path if it isn't already an NT path
<andrewrk> marler8997, yo I'm back
<marler8997> I have some ideas, let me know when you'd like to discuss
<marler8997> andrewrk let me know how you want us to deal with potentially long paths where ".." goes past the current relative path name
<marler8997> looks like the max path is 32767, we could allocate that on the stack couldn't we?
<marler8997> looks like that was the limit for everything before Windows 10
<marler8997> andrewrk, it looks like the reactos implementation only supports paths up to 260 chars :(
<marler8997> are you suggesting zig shouldn't work in wsl?
<marler8997> the chmod one caused us issues because we had a tool that was looking for the EXECUTABLE bit and windows just gives everything the executable bit
<marler8997> timestamps might behave differently too
<marler8997> it's been a while, but things like chmod may not work
<marler8997> yeah that could definitely be the case
<marler8997> but WSL1 didn't create symlinks that way, whatever it did the file was all messed up when you went back to windows
<marler8997> but on linux, a symlink is just a normal file whose contents is the path to the target and has a special bit set in the mode
<marler8997> I'm not familair with how the NTFS vfs driver works for WSL2
<marler8997> with wsl1, if you made a symlink on an NTFS filesystem from WSL, then it created this weird file that windows didn't know what to do with
<marler8997> well, wsl1 or 2?
<marler8997> wsl is linux
<marler8997> lol, everyone else gets to use linux :) No one wants to touch this turd
<marler8997> wow no merge conflicts after 4 months
<marler8997> ok, I'll look into this more and get back to you on the second PR then
<marler8997> hmmm
<marler8997> should I resurrect the old PR and we go with that, at least for now?
<marler8997> I do see alot of work and potential maintenance for a small upside
<marler8997> I mean, maybe we can, but I don't see alot of benefit
<andrewrk> marler8997, ok. yeah. having broken down the pieces, it seems inevitable to rely on heap allocation for opening a file path. thanks for indulging me on this rabbit hole. I agree, we can't do better than RtlDosPathNameToNtPathName_U_WithStatus
<marler8997> trying to avoid using the heap kinda seems like we're trying to polish a turd :)
<marler8997> the way I kinda look at it is windows is messed up in all sorts of ways
<marler8997> so I think the choice is either use this, or come up with a non-heap implementation
<marler8997> yeah
<marler8997> here was that PR: https://github.com/ziglang/zig/pull/7537
<marler8997> but requires heap
<marler8997> right, ntdll provides a function to resolve ".." for us
<marler8997> then I would suggest we just use the function windows provides for us
<marler8997> if we're going to heap allocate
<marler8997> let me look into this implementation and I'll update my PR if it works
<marler8997> ah
<marler8997> what is midipix?
<marler8997> the function that all the kernel32 methods used required the heap, so my PR that used it was rejected by you because of that
<marler8997> NtQueryObject?
<marler8997> I have a branch in ReactOS where I pulled out all the path logic, let me go find that
<marler8997> still trying to refamiliarize myself with all this
<marler8997> that seems familair
<marler8997> like 4096
<marler8997> maybe NT_PATH_MAX is larger
<marler8997> hmmm
<marler8997> I can go back and confirm
<marler8997> it's been a while, but that's what I remember the reactos implementation doing
<marler8997> ..\a would just be an error (too many .. paths)
<marler8997> a\..\b would become b
<marler8997> then the ".." has nothing to remove from the path
<marler8997> if you pass something like ..\a
<marler8997> I'll fix the absolute path issue, and document this behavior in the comments and then let you know when it's ready
<marler8997> yes I will definitely do that
<marler8997> but I didn't want to work on it until we were on the same page
<marler8997> it only works with absolute paths, I need to modify it to convert all relative paths to absolute paths before resolving ".."
<marler8997> there's a problem in my PR
<marler8997> well hold on
<marler8997> yeah, this last point is one I hadn't thought of the last time we discussed
<marler8997> CreateFile will always resolve symlinks the windows way
<marler8997> if you change the behavior of symlinks on windows, then paths will get resolved differently when you pass paths to kernel32 functions
<marler8997> the problem is
<marler8997> I have an issue open about it as well
<marler8997> we had a whole discussion about this months ago :)
<marler8997> and then confirmed it with some tests
<marler8997> I discovered this when I looked at the implementation in ReactOS
<marler8997> yes
<marler8997> maybe you forgot :)
<marler8997> on windows, paths are resolved before symlinks
<marler8997> andrew
<marler8997> right
<marler8997> you have to account for the fact that they might work in some situations
<marler8997> for functionality
<marler8997> I would suggest not relying on them
<marler8997> andrewrk correct, avoid symlinks on windows :)
<marler8997> sure
<andrewrk> marler8997, I'm around if you wanna chat about '..' on windows


<marler8997> ah clever
<marler8997> here's the full code I'm trying to compile, just creating a comptime string map with 100 entries: https://gist.github.com/marler8997/4d0021165706ea121c523dbaf5bf8974
<marler8997> how would I set the eval branch quota when I'm initializing a ComptimeStringMap?


<marler8997> "the context"?
<marler8997> how would a comptime allocator catch memory leaks done by a runtime allocator?
<marler8997> even better when they're caught at comptime? possible?


<marler8997> it's not exposed to anything outside of net? what do you mean? it's pub
<marler8997> here's the docs for "open" as well: https://pubs.opengroup.org/onlinepubs/007904875/functions/open.html
<marler8997> I'm not really sure either, but I do know that introducing a wrapper has some problems and I'm just trying to make everyone aware of them
<marler8997> opening a PR for networking is one good way to get some opinions out of me :)
<marler8997> It makes sense when you're only working with 1 of them, but once you start to get into multiplexing and real-world applications then tend to break down I find
<marler8997> I've seen people create wrappers for Socket too many times and it always seems to make things more complicated