<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
<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>
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>
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
2021-04-13
<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>
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
2021-04-12
<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; }
<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?
<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
2021-04-08
<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>
does anyone want to be my impartial judge and tell me if I'm taking crazy pills on an issue with win32metadata?
2021-04-02
<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
<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>
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