<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>
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>
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!
<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: 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 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
2021-02-10
<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>
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?
<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?
<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
2021-02-07
<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.
<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?
<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>
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