<marler8997> It might give people a bad impression when they see "return error.bad" and realize it's not triggering an actual error
<marler8997> the first `afunc` in example.zig is demonstrating the new code with a very uncommon use case, namely, a function that returns an error without triggering a throw
<marler8997> missing close paren: " // NEW: propagate error (equivalent to OLD `return error.Bad`"
<marler8997> I like that you're tracking the revision notes
<marler8997> yup just saw em :)
<marler8997> reading


<marler8997> cool let's give it a try
<marler8997> would be nice to jump on a discord call and discuss? you have that ability?
<marler8997> is it's return type u32?
<marler8997> is f3() the same signature as in your proposal?
<marler8997> one thing it could mean is "return catch doit()" would return an error up to the caller, but it wouldn't add an error on the error stack and errdefers won't run, so it would be a way to return an error without putting your function on the stack
<marler8997> I'm talking about "return x" after that
<marler8997> right I understand that part
<marler8997> otherwise, a function could return an error-union value in a error state, but error handling hasn't been triggered
<marler8997> if we make returning error unions a compile error, then it means that a function will only return an error if an only-if error handling has been triggered
<marler8997> then what is it returning?
<marler8997> but you're saying "return catch doit()" won't be returning error.Overflow?
<marler8997> and we return catch doit()
<marler8997> say, doit returns error.Overflow
<marler8997> well I'm have a few questions now since you said that "the error is gone"
<marler8997> so what state is it in now?
<marler8997> it's an error-union value that is in an error state
<marler8997> how is it gone?
<marler8997> if you did return x, and x is an error, and errdefers don't run (your hot take), then what happens on the caller? Does their catch trigger?
<marler8997> like, if you catch the error union, you'd have to do something like fail catch doit()
<marler8997> as a value
<marler8997> maybe it should be an error to return an error union from a function?
<marler8997> so I'm a bit perplexed at what happens with return catch doit()
<marler8997> so with "return catch doit()" does that mean errdefers won't execute?
<marler8997> well it doesn't solve, maybe say it would provide a syntax to solve #2647?
<marler8997> in "Related proposals", you could mention that this proposal could be used to solve #2647
<marler8997> I spelled your name wrong, mikdusan
<marler8997> since we switched to "catch", not a new keyword anymore
<marler8997> mikdusam this line needs corrected " // NEW: keyword `catch`, type is error-union"
<marler8997> -strip might help as well, and -Orelease-small
<marler8997> the only way I know of is to remove references to stdlib stuff
<marler8997> mikdusan changes look great
<mikdusan> marler8997: would you mind take a look at https://gist.github.com/mikdusan/4a14547a094b0e2cc9eb206fd1c6bb81 ; it's a pending update to proposal #7812,
<marler8997> yeah that would definitely be an improvement on the status quo
<ifreund> marler8997: interesting indeed, it should be a compiler error though tbh since doing the wrong thing silently is worse
<marler8997> ifreund, interesting, the 2-float struct works if I define the function in Zig, even with callconv(.Stdcall), so Zig current implementation actually works, it's just different from the C specifiction right now...lol
<marler8997> looks like it works as a function parameter, just not a return value
<marler8997> it's only 8 bytes
<marler8997> Must fall under this one: "x86_64: struct & union return values <= 16 bytes"
<marler8997> ifreund ok good, at least it's a known issue
<ifreund> marler8997: yeah, returning structs of floats by value is known to be buggy in stage1
<marler8997> found an issue where I'm calling a WINAPI function from Zig and it's returning a struct with 2 f32 floats...is this a known issue?
<marler8997> everyone it's time to zigup your compiler and cleanse your projects of evil, cast out the demon of ambiguous array specifiers!


<voldial> marler8997: gcc USE flags:
<marler8997> well, nixos has that in it's configuration file
<voldial> marler8997: yea, they let you decide ./configure opyions globally or per-package. so I can say (for example) disable X support on everything)
<marler8997> USE flags?
<voldial> marler8997: heha. gentoo, but Nix is sweet... it's just missing the compile flags we love (called USE flags)
<marler8997> nice, it's like dipping your toes in the NixOS water :)
<voldial> marler8997: symlink layout for gcc: https://bpa.st/7Q2A
<marler8997> good ol' symlink
<voldial> marler8997: exactly.
<marler8997> how does the mechanism work to change versions? symlink?
<marler8997> oh wow, this file looks alot like yocto recipe files
<voldial> marler8997: here is the pull to convert the git-head zig ebuild to work with the latest code for example, the :9 to :11 is specifying the llvm "slot" to use. https://github.com/gentoo/gentoo/pull/19007/commits/83fe09567bdd0bddb98d42ada3b89bdb60ca8ffa#diff-3161cd3b11e8ef662a999ec0a5c0bd1a8d8141430e44a40bffecf0d2fe11bb28
<marler8997> oh cool
<voldial> marler8997: no sorry, I was saying that portage has someting similar to zigup, in a ebuild (the install instructions portage parses) you can specify which version of something to use or depend on. it's very mature and nice.
<marler8997> voldial are you saying portage's cmdline parsing is similar to the example I sent you?
<voldial> marler8997: you prob know, but portage does something similar, we have slots, so parallel installed versions of stuff is easy
<marler8997> an application specific parser that's used in multiple places makes sense. It's the general case that seems to be hard
<ifreund> andrewrk, marler8997: My reason for an abstraction here was to avoid code duplication between (eventually many) sub commands
<marler8997> yeah, it seems like every time I see a cmdline parsing library, there's always corner cases to handle which eventually makes the library bloated/complex or using the library ugly
<voldial> marler8997: cool
<andrewrk> marler8997, same. I don't really see the value in an abstraction for this
<marler8997> I pretty much do the same thing to parse arguments in all language now, here's an example: https://github.com/marler8997/zigup/blob/master/zigup.zig#L179
<voldial> marler8997: "does exactly one thing" style then?
<marler8997> I haven't used an option parser in years
<andrewrk> marler8997, I'll poke Loris to update the doctest repo
<marler8997> I dub this new version of Zig as holy water, cleansing all it touches, starting with the ziglang.org gatekeeper
<marler8997> ah
<marler8997> hmm, still not sure how things get deployed :)
<andrewrk> marler8997, these failures: https://github.com/ziglang/www.ziglang.org/commits/
<voldial> marler8997: no luck, tried -fPIE with and without -fPIC: https://bpa.st/TRWA
<voldial> marler8997: oooo. sorry
<marler8997> you sent the -fPIC example, not -fPIE
<voldial> marler8997: I did: https://bpa.st/EXIQ
<marler8997> -fPIE?
<marler8997> oh you know what, I'm an idiot, I was calling setTarget somewhere else with .{ .os_tag = .windows }
<marler8997> build.zig is using b.standardTargetOptions(.{})....so not sure what's wrong
<marler8997> I seem to be getting 64-bit executables with: zig build -Dtarget=i386-windows ??
<marler8997> is it the ziglang.org CI issue you mentioned the other day?
<marler8997> andrewrk, so what's holding up the new commits from getting to ziglang.org?
<marler8997> when there are things missing, I've been putting them in missing.zig
<marler8997> I've created an issue: https://github.com/microsoft/win32metadata/issues/217
<marler8997> yeah looks like its not in win32metadata
<marler8997> nope not too early, that's great someone is exercising this code, let me look
<tdeo> marler8997: i'm missing a constant, PROCESS_QUERY_LIMITED_INFORMATION, i'm not sure if that's win32metadata's fault or not
<marler8997> nice, I see some assembly written in hex :)
<marler8997> oh interesting, what do you use that for? Like making bots?
<marler8997> like, the strings from a .exe file?
<marler8997> cool is it public? link?
<marler8997> fixed
<marler8997> right, that would have to happen in some cases, not sure how many
<marler8997> what kind of problems do you forsee?
<marler8997> I think *opaque{} might make sense for things like HANDLE and the like?
<marler8997> ah
<marler8997> I see it on types but I don't see any as function parmaeters
<tdeo> marler8997: there are a lot, i'm looking in system_services.zig
<marler8997> but maybe there are some cases still using ?*opaque{}? Can you point me to the one you're seeing?
<marler8997> tdeo yeah I actually already ran into that and changed it to ?*c_void for things like function parameters
<tdeo> marler8997: from what i can tell in zigwin32, you use ?*opaque{} where the bindings specify an unknown type pointer, have you considered using ?*c_void instead? from what i understand it's impossible to pass a pointer to a function taking an anonymous ?*opaque{} without some weird typeinfo hackery
<marler8997> the win32metadata project is still pretty new, they'll probably get added in later
<marler8997> interesting I don't see the error codes in the metadata
<marler8997> yeah, they got some geniuses over there are Microsoft
<daurnimator> marler8997: ha. yeah they've done that too... see e.g. WinsockError in `lib/std/os/windows/ws2_32.zig`
<marler8997> it's always easy to add corner case handling as well
<marler8997> like, imagine they accidently included a bad value, now all the names are messed up
<marler8997> right, I'm not sure what I like better yet
<marler8997> well luckily I didn't have any conflicts yet
<marler8997> eww
<marler8997> what kind of weird?
<daurnimator> marler8997: I remember windows have a couple of weird ones where there were enums mashed together weirdly
<daurnimator> marler8997: I would do it only if *every* enum member has that prefix.
<daurnimator> marler8997: looks great :)
<marler8997> andrewrk, hate to say "I told you so"...not really though :)
<marler8997> let the propogation of {s} begin
<marler8997> andrewrk perfect!
<marler8997> ok cool, so after CI is done it automatically deploys


<marler8997> actually a better version of my question, is there a way to track the progress of the next version to be deployed?
<marler8997> how does ziglang.org downloads get updated?
<marler8997> Microsoft Stonks!
<marler8997> but waiting for you files to unzip gives you more time to look at the ads :)
<marler8997> daurnimator, I solved the enum prefix issue. for all the values inside the enum, if the value name contains the name of the enum then it is stripped off. Along with that, you can still access the enum value outside the enum with the fully-qualified name. Checkout MSHLFLAGS again at https://github.com/marlersoft/zigwin32/blob/main/src/win32/api/com.zig
<marler8997> on my machine its 20ms to "touch foo", that can definitely add up
<marler8997> about 2.1MB
<andrewrk> marler8997, thanks for the PR on the def files. Mind checking for me, how much more bytes does this add? just curious
<marler8997> I answered my own question, when I switched to 8.0.0, now my file copies aren't changing the files that are already there
<marler8997> hmmm, my mingw version was 6.0.0, but it looks like there are newer verions, should I be using 8.0.0?
<marler8997> andrewrk here's the PR for those updated def files: https://github.com/ziglang/zig/pull/7990
<marler8997> actually I might take a contract to work on adding COM support to CoreCLR
<marler8997> we also stopped using COM, but we weren't using much of it luckily
<marler8997> like PrivateAccessors for unit tests needed a replacement
<marler8997> yup it works, there were some thing we needed to change but we got it done
<marler8997> we thought about coreclr but at the time it wasn't ready, it might be a better choice nowadays
<marler8997> We're using mono
<marler8997> lol, you're in the exact same boat as us
<marler8997> biggest reason we needed to was CE didn't support newer processors/hardware
<marler8997> yeah that's what we did
<marler8997> well, I think they planned to stop allowing it soon
<marler8997> right but I'm surprised Microsoft is letting you license it still
<marler8997> how are you still shipping products with WinCE though? Microsoft won't license it anymore, I think EOL might be next year?
<marler8997> oh that's really cool
<marler8997> so upgrading to just those referenced by win32metadata might be a reasonable step forward for the time being
<marler8997> andrewrk, it looks like there are quite a few .def files that are not being referenced by win32metadata
<marler8997> so what do you guys do with CE?
<marler8997> lol
<ikskuh> marler8997: i don't think so, you're not of the other 7 devs we have :D
<marler8997> do we work in the same place?
<marler8997> what do you do with CE?
<marler8997> the old embedded version of windows, stripped down, but no longer supported
<marler8997> WinCE is actually one of my specialities...but little good that does me nowadays :)
<marler8997> lol...well you can always provide your own .lib files
<marler8997> it's interesting that they are split by platform, I wonder if we could remedy that
<marler8997> we won't need the ones in libce....that OS has been dead for a while
<marler8997> list generated with: grep -r "extern \"" | awk '{ print $3 }' | sort | uniq
<marler8997> I'll get a list of what's being referenced, might help
<marler8997> right
<marler8997> Maybe I can get a list of which ones are currently being referenced in win32metadata
<marler8997> ah
<marler8997> if it's only 118KB compressed then why not
<marler8997> not too bad
<marler8997> ah
<marler8997> ok will do
<marler8997> ok, they must not be that big then
<marler8997> do we want to include everything in win32?
<marler8997> andrewrk, gotcha, is that scalable though?
<marler8997> I should rewrite the ported example in Zig-style as well
<andrewrk> marler8997, all we need to do is copy the def files from mingw-w64 into the respective place in zig lib/ dir
<marler8997> v0idify, yeah it's pretty ugly
<marler8997> andrewrk, I was trying to port a direct2d example, which uses d2d1.lib
<andrewrk> marler8997, which libs do you need that we're not providing?
<marler8997> maybe all I need to do is generate ".def" files as apart of my win32 codegen? If there's some way to tell Zig to create a .lib file to link against?
<marler8997> andrewrk, as I understand, we are using libc/mingw to create Windows .lib files to link against? If so, what's our stance on those lib files? Should they have everything in win32? If not, then do you have any thoughts on how one might link against a lib that's not in there?
<ikskuh> marler8997: very cool!
<marler8997> ok, COM is now working, I'm calling COM from Zig! :)
<marler8997> good luck
<marler8997> allocation can be a pretty deep topic
<marler8997> if you just want raw u8 buffers, and you allow move then that's the one you want
<marler8997> I actually did the rewrite on std.Allocator, and we put in pretty good explanations of how the new interface works in std/mem/Allocator.zig
<marler8997> realloc is free to move memory
<marler8997> realloc is a superset
<marler8997> if you allocation is at address 100, and something else is at address 150, you'r maximum size is always 50
<marler8997> virtual memory is still flat
<marler8997> memory is flat, so it can only grow as far as it takes to get to the next reserved address
<marler8997> "in place" is the keyword here
<marler8997> it's a resize in place
<marler8997> it can't
<marler8997> in general expect any allocator to fail to expand an allocation in place
<marler8997> correct
<marler8997> probably same story for C allocator
<marler8997> testing.allocator is gpa now
<marler8997> gpa probably put it into a bin where it can't resize in place past a certain length
<marler8997> I believe so yes
<marler8997> and if there is a conflict within in the same interface, then I add a numeric suffix, i.e. "obj.Foo(a)" and "obj.Foo1(b)"
<marler8997> ran into an issue because Zig doesn't support overloading. Current idea is to prefix all COM methods with the interface they belong to, i.e. instead of "obj.Release()" you write "obj.IUnknown_Release()"
<marler8997> I've updated the COM generation a bit, still not finished but getting closer
<marler8997> shoot that's the first I've heard of those
<marler8997> async ones?
<daurnimator> marler8997: how do the "Async" ones work? you call begin; yield to the main loop; then call end?
<marler8997> I already pushed your 2 suggestions btw
<marler8997> I'll probably need like 10 or 15 minutes
<marler8997> actually I think there is
<marler8997> I wonder if there's a way we could do something like that for COM methods
<marler8997> yeah that's not a bad idea
<daurnimator> marler8997: ooo, idea for the "bare" enum values.. a helper function called like: `pub usingnamespace std.meta.enumValues(MSHLFLAGS)`
<marler8997> yeah, thanks for that
<marler8997> as for prefixes, that's not a bad idea, I could have the enum values without the prefixes, and then aliases outside the enum with the prefixes
<marler8997> woops
<daurnimator> marler8997: `return self.vtable(self);` -> you're calling a struct?
<daurnimator> marler8997: would you be able to take off prefixes for things like MSHLFLAGS_ ?
<marler8997> maybe it's getting generated from libc/mingw?
<marler8997> so where is Zig's instance of lld-link look for .lib files on Windows?
<marler8997> aaaaaand, now I'm generating COM


<marler8997> hmmm, I don't see the odbc functions in there, unfortunately
<zags> marler8997: next, @import("odbc") ? :d
<marler8997> this is the last major thing missing from the bindings at this point
<marler8997> I'm actually going to generate Zig code for all the COM types in win32metadata
<marler8997> calling IDispatch on it's own would be easy
<marler8997> oh I see, yes you're right
<daurnimator> marler8997: are you not? I thought this was some of the proceeds of that windows definitions project you were doing
<marler8997> daurnimator, doing it at comptime?
<marler8997> calling IDispatch from Zig, yes
<daurnimator> and infact marler8997: comparing your comptime results to what IDispatch tells you at runtime might be useful for test cases
<zags> marler8997: so I can soon IDispatch from Zig?
<marler8997> getting ready to implement the Win32 COM bindings for Zig :)
<DarkUranium> marler8997, there is one for C#, too. I saw it while researching Roslyn.
<marler8997> imagine getting ZLS to work by compiling it to WASM and running it in the browser ??!!??
<marler8997> yeah I wonder if they could get plugins to work
<marler8997> lets' you view github repositories in a browser like you're using VSCode
<marler8997> wow saw this on reddit, pretty nifty: https://github1s.com/ziglang/zig


<Piraty> marler8997: if i'd be that upstream, i'd require you to give that commit a descriptive text
<marler8997> the first PR to win32metadata from the Zig community: https://github.com/microsoft/win32metadata/pull/212 I feel proud to be apart of this community that fixes other people's upstream projects


<marler8997> I shouldn't be getting a dependency loop from it
<marler8997> current solution is to check if the root modules defines UNICODE=true/false...then set the aliases accordingly
<marler8997> nah
<marler8997> right now I'm trying to deal with the UnicodeAlias part, I'm getting a dependency loop
<marler8997> looks like ILspy might print all powers of 2 >= 16 as hex
<marler8997> ilspy prints them as hex, should find out what ilspy is doing
<marler8997> we could go through all the values of an enum and if they are all powers of 2 them assume they are flags and print them in hex
<marler8997> good question, not that I'm seeing in the metadata
<marler8997> the metadata just contains the raw values, we'd have to apply our own rules/tricks to do that
<marler8997> oh the integer stuff
<marler8997> @TagType?
<mikdusan> whupsee. marler8997 ^^ 2 lines above was meant for you.
<ifreund> I think you mean to tag marler8997 :P
<marler8997> made a good amount of progress on win32metadata binding gen, take a look at what it's generating so far: https://github.com/marlersoft/zigwin32/blob/main/src/win32/api/file_system.zig


<zags> marler8997: please do make an issue for discussion. This will be a source of bugs if not fixed.
<marler8997> ifreund yes, an issue just to discuss the merits may be worth it
<marler8997> mostly because today you can do { decls; expr... }
<marler8997> with(decls) expr...it's an interesting idea, though, if I were a betting man I would bet against it being accepted at this point. Even if I were in Andrew's position I'm not sure I would accept it either. Zig has taken a pretty strict stance on new features, understandably so
<zags> marler8997: you should write it up :)
<ifreund> it hasn't been properly proposed yet, just mentioned in passing by marler8997 on a related issue
<marler8997> could be, that would explain why Zig thinks they are different but LLVM may have optimized them to be the same
<marler8997> interesting that the strings that match still have the same pointer, it looks Zig has already anticipated these issues
<marler8997> thx for correction
<marler8997> yes comptime
<ifreund> marler8997: I don't think memoization can/should work for dynamic strings built at runtime, did you mean comptime?
<marler8997> andrewrk, looks like I tracked down the issue I was having with https://github.com/ziglang/zig/pull/7676 if you want to take a look at it
<marler8997> ifreund ok thanks
<ifreund> marler8997: pretty sure I've hit that before, but I don't remember a bug report
<marler8997> mikdusan1, I've opened an issue here if you're interested: https://github.com/ziglang/zig/issues/7948
<marler8997> no
<mikdusan1> marler8997: is one null terminated and the other not?
<marler8997> I found a bug in generic function instantiation where the compiler doesn't see 2 comptime strings as equivalent if one of them is a slice, even if their contents are the same,anyone know if this is a known bug?
<marler8997> gimmeMoreOfThoseSweetSweetFileDescriptors...lol


<marler8997> g-w1, thanks for the reminder, there's so many notifications on github I don't always see these
<g-w1> marler8997, not sure if you saw this, but it is needed to make zigup work https://github.com/marler8997/ziget/pull/4


<marler8997> the "Kind" field is like the "tag" of a union
<marler8997> and it does look like I'd also need #5326
<marler8997> daurnimator does that work with recursive types?
<marler8997> UInteger meaning u64
<marler8997> well in that case, what if just add UInteger as a case to the union for now and leave BigInt up to the next guy?
<marler8997> create Number union that can support i64/f64 and BigInt?
<marler8997> ok well, I'd like to do what I can to at least add support for u64, so what path would you deem appropriate for me to accomplish this goal?
<andrewrk> marler8997, that logic does make sense to me
<marler8997> is that just me?
<marler8997> gotcha, well for me it seems like it should either be configurable, or support everything
<marler8997> so you think we should support a subset?
<marler8997> I think all possible could be BigInt with a decimal component, BigFrac? :)
<marler8997> if we don't make it generic, then do you think we should support all possible numbers representable by the JSON spec, or a subset?
<marler8997> but the alternative is just supporting all kinds of numbers
<marler8997> I was thinking of punting the decision to the user by making it configurable
<marler8997> that's one idea
<marler8997> but that doesn't handle large integers
<marler8997> Would make the Value union match the JSON grammar, kinda nifty
<marler8997> so Number would also be a union