<marler8997> found it!
<marler8997> txdv, thanks I think that will work
<marler8997> I want to lookup a convo in zig irc that happened sometime last year, anyone know of a way to do that?


<marler8997> andrewrk, if a package is included multiple times with different names in the same compilation, is it compiled the exact same way?
<andrewrk> marler8997, I think this is related to another issue that isn't solved yet, which is wanting to set different optimization modes (-O) per package
<marler8997> but in that case the value could be known at runtime only
<marler8997> also might need something like that for my build proposal
<marler8997> andrewrk, this issue: https://github.com/ziglang/zig/issues/8812
<andrewrk> marler8997, status quo is the package name is not observable except as a way to use `@import`. what did you have in mind?
<marler8997> TheLemonMan, I can't confirm or deny whether overflow is still occuring becase of the FileNotFound error
<marler8997> so I'm not sure if I can confirm whether or not the integer overflow would occur if this FileNotFound error did not occur
<marler8997> I'm not getting this instead: Unable to dump stack trace: FileNotFound
<marler8997> I just saw the stack trace but I needed to look at the 2nd stack trace
<marler8997> maybe the issue isn't happening
<marler8997> oh wait, you know what
<marler8997> when I fix it, I no longer hit that condition, so problem may be elsewhere
<marler8997> should be: if (debug_dir.virtual_address < header.virtual_address)
<marler8997> instead of: if (debug_dir.virtual_address < header.virtual_address + header.pointer_to_raw_data)
<marler8997> TheLemonMan, I think there's a mistake in my logic to detect the virtual address overflow
<marler8997> looks like it's not overflowing...
<marler8997> thread 23144 panic: debug virt 241704 header virt 225280 ptr 219648 file_offset=236072
<marler8997> here's a run with printing the file_offset:
<marler8997> thread 24444 panic: debug virt 241608 header virt 225280 ptr 219136
<marler8997> oh gotcha
<marler8997> here's all the files: https://pastebin.com/Fh8GyEt0 which one's did you want?
<marler8997> you want a tar file or something?
<marler8997> ifreund, if we allow the package name to affect compilation, the solution should be trivial, I think an enum with all the package names would be nice. If we dont' allow it to affect compilation, it might be quite difficult, I can't think of a solution atm
<marler8997> TheLemonMan, yup, looks like it's still there
<TheLemonMan> marler8997, can you still reproduce #5476?
<marler8997> andrewrk, what is your thoughts on having the package name affect compilation? Do we do that today? Should we allow that?
<marler8997> yeah, and yes the proposal is incomplete. I created it for now to document the concept and we might need to wait a bit before we know what the implementation will look like (i.e. how do we get the package name?)
<marler8997> and my idea was to provide the package name, but make it known only at runtime
<marler8997> my proposal for optional build.zig dependencies ran into this issue as well
<marler8997> because I'm not sure if Zig assumes that a package will compile the same way depending on if it's package name changes
<marler8997> not that I know of, and doing so could pose problems
<marler8997> if we didn't need subcategories, we could simplify std.log.scoped to only contain the package name and nothing else
<marler8997> I see std.log not only being used to differentiate packages, but also contain sub-categories within the same package
<marler8997> yeah I would agree
<ifreund> marler8997: no, but when writing a package you can put all of your logging in a scope with the same name as your package, and I would consider this good practice
<marler8997> ifreund, are you saying there's already a way to get the package name from log scopes?
<marler8997> ifreund, I just made this issue: https://github.com/ziglang/zig/issues/8812
<ifreund> marler8997: as in an automatic way to do that? You can already do it pretty easily manually afaik
<marler8997> I had an idea to do with std.log. What do people think about adding a way to namespace the log scopes with the package they come from?
<marler8997> fyi, I realized the metadata does include a "packing size". So I'm translating a packing size of 1 to "packed". Not sure what to do about 2/4 byte packings...?
<marler8997> found it, there's a "#pragma pack(1)" in mmsystem.h around the location where it include mmeapi.h...wow
<marler8997> wow, I can copy the entire header and it still shows sizeof is 20! there's something really wonky going on here
<marler8997> I don't really see any alignment directives around it...weird
<marler8997> oh interesting, when I copy the struct definition to my local file in C++, the sizeof goes to 20! So the header must be using some sort of alignment directives somewhere
<marler8997> the WAVEFORMATEX struct is the 3rd parameter, when I use "extern struct" I get error 32 (WAVEERR_BADFORMAT)
<marler8997> using "extern struct" changes the layout in such a way that windows does not recognize it, it's only when I use "packed" that it accepts it
<daurnimator> marler8997: zig @sizeOf is not the actual size; it's how large it would be in an array. more like `max(@realSize(), @alignOf())`
<marler8997> I'm generating all win32 structs using "extern struct". I'm not sure if this is an exception, or if they're all actually supposed to be packed?
<marler8997> in zig, if it's "packed" it's 18 bytes, which is the correct size based on both what C++ says and the fact that it only works at runtime if it's 18 bytes. But when I mark it as "extern struct", it's 20 bytes
<marler8997> I've got a weird discrepancy on win32 between the size of a struct


<marler8997> oh that's interesting
<ikskuh> marler8997: if you don't know a init value, you can init to @as(Payload, undefined)
<marler8997> ah good
<marler8997> or simpler, just an optional value
<marler8997> is it possible to get the address of the payload of an optional field?
<marler8997> shoot, problem is I can't use the git email commands because they haven't fully implemented support behind proxies
<marler8997> what's a "pull request via email" mean with sourcehut?
<marler8997> yeah, I suppose that's a big one
<marler8997> I'm unaware of the advantages the old model has
<marler8997> it's interesting, it's half way between the old model and the new github PR model
<marler8997> so maybe ok
<marler8997> I suppose my email is in the commit
<marler8997> do I just send another patchset with my email cc'd?
<marler8997> correcting mistakes also seems to be problematic
<marler8997> oh I forgot to cc my own email as well, shoot
<marler8997> ah,
<marler8997> the problem with sending an email via patchset is there's no feedback to know if my change has even been received
<ifreund> marler8997: I think their mailing lists replace that
<marler8997> do you think they will add a pull-request model, where it hosts discussion and you can check the status of your change?
<marler8997> ah, in the "summary" page, "Prepare a patchset" link
<marler8997> a bit clunky, but seems to work, I'm trying to send a second patchset and I can't seem to find the page that does it again!
<marler8997> the github repo says it's a mirror of the sourcehut repo, which tells me he would prefer patches there
<marler8997> ok, I went through the web ui to send a patchset to his commit email, hopefully it works
<ifreund> marler8997: yeah, looks like he doesn't have one listed, I'd just send to whatever email he uses for commits then
<marler8997> I don't see one in the "summary" page, is that where it would be? https://git.sr.ht/~dbandstra/zig-wav
<marler8997> trying to send a patchset on sourcehut to dbandstra (never done it on sourcehut before). does he hang out here?
<marler8997> shoot you're right
<marler8997> oh not working on linux either
<marler8997> looks like zig build -p . not working on windows though :(
<marler8997> I feel like your question has resolved my issue :)
<marler8997> uh....since you're asking I'm guess no
<marler8997> :)
<marler8997> this is taking me way too long, how do I change the install path in build.zig?


<marler8997> I once looked into writing dlang bindings to libc++....then I realized the same thing, it was going to be a montrous undertaking
<marler8997> I'm sure I will regret asking, but what's the messiness?
<marler8997> that's not a horrible solution
<marler8997> I dunno, I'm going back and forth. explicitly forcing a function to always be inlined is actually completely orthgonal to any calling convention
<marler8997> it's like a 45 degree relationship :)
<marler8997> doing so implies it's not orthogonal, they do seem related but the coupling is a bit odd
<marler8997> if we went back to "inline fn", do you think we should make it an error to specify inline with at least some kinds of calling conventions?
<marler8997> yeah good point in favor of inline
<marler8997> yeah it seems like Zig could kinda go eitehr way
<marler8997> if we decide to keep it orthogonal, then callconv(.Inline) doesn't make sense
<marler8997> thinking on it, I can't really tell if it's simpler to keep inline orthogonal to the calling convention or not
<marler8997> emulator => emulate
<marler8997> given we could emulator today's behavior, I don't think there's any use cases we couldn't support. so we have 2 solutions to compare now
<marler8997> In the case where you want to emulator todays behavior, you would have to define the function using the default calling convention, then define a wrapper with an explicit calling convention
<marler8997> if we did that, I think the question would be, are there any use cases Zig couldn't support?
<marler8997> language spec simplification
<marler8997> to follow up on the train of thought, what would happen if we made non-default calling conventions imply nonline?
<marler8997> gotcha
<marler8997> so if a function has a non-default calling convention, some callers can still inline it?
<marler8997> so nonline prevent all callers from inlining it, is that correct?
<marler8997> unless, you're saying that some callers could inline it and some may not?
<marler8997> how could you inline a function with a non-default calling convention?
<marler8997> a non default calling convention infers nonline does it not?
<marler8997> call(.NoInline) would mean the default calling convention, but you're not able to inline it
<marler8997> andrewrk, I'm not sure I understand your comment about not being able to know what the calling convention is


<marler8997> I ended up going with the 6900 xt, my VR looks very nice now :)
<marler8997> but they were always on backorder, and I just never felt confident enough to pull the trigger on it especially with risk of dammage in shipping
<marler8997> I seriously considered that route, I found systems with a 3080 for around $3000
<wilsonk> marler8997, instead of buying a gpu alone, could you buy an entire machine to get the gpu and then resell what you don't need to save some money? I think pre-builts can still be found at a somewhat reasonable price (sorry for the late reply but I forgot to ask the other day)


<marler8997> WSAStartup would still be leaky though because it's global (not thread local). So any thread that calls it and changes the version would affect all other threads within the same process
<marler8997> yeah, I got bit by that one years ago, there's tons of restrictions on DllMain
<marler8997> you can't load other Dlls inside DllMain, and WSAStartup can load other Dlls
<marler8997> right, but you can't call WSAStartup inside DllMain
<mq32> marler8997: DllMain() would be an option here…
<marler8997> yup, like I remembered
<marler8997> > An application must call the WSACleanup function for every successful time the WSAStartup function is called. This means, for example, that if an application calls WSAStartup three times, it must call WSACleanup three times. The first two calls to WSACleanup do nothing except decrement an internal counter; the final WSACleanup call for the task does all necessary resource deallocation for the task.
<marler8997> scratch the DllStartup idea
<marler8997> > The WSAStartup function typically leads to protocol-specific helper DLLs being loaded. As a result, the WSAStartup function should not be called from the DllMain function in a application DLL.
<marler8997> double checking...
<marler8997> WSAStartup does maintain a reference count
<marler8997> what's the leaky problem with WSAStartup?
<marler8997> UEFI actually might be able to use that
<marler8997> I wonder if there are other platforms that would need something like that?
<marler8997> so andrewrk, if I'm making a zig library that requires some sort of initialization with optional parameters, wouldn't you say that I should provide some type of "init" function? Couldn't zig's `std.os` do the same thing?
<marler8997> looks like go is taking advantage of some type of "static module constructor" as well
<marler8997> networking is especially weird, they've got windows-specific functions, and then a half-baked version of the posix ones
<marler8997> with the fallback method, if the user calls WSAStartup themselves they can select their own version
<marler8997> actually the init method may be problematic if an applications want's a specific version
<marler8997> so, do you think we should put an "init" call before calling anything in ws2_32, or do a fallback?
<marler8997> I see, then it's good
<marler8997> oh, the atomicLoad isn't setting done?
<marler8997> I'm looking at once.zig in "call"
<marler8997> so if the first thread increments the atomic, any thread can come in and start using ws2_32 before the first thread has called WSAStartup
<marler8997> it's using atomicLoad
<marler8997> ooo, that might cause an issue
<andrewrk> marler8997, yeah init_once is just a mutex + flag so that multiple threads can race to initialize something and only 1 wins and the others wait
<marler8997> init_once makes it thread safe?
<marler8997> very similar to GCC'c c constructor
<marler8997> yeah, not sure if sys/windows/net.rs: init is supposed to be called by the user?
<marler8997> I'm extremely familiar with ws2_32. I had to implement my own version of it
<marler8997> I'm very unfamilair with AFD to be any help with analyzing that
<marler8997> gotcha
<marler8997> lol, I know what local maximum means, but how is ws2_32.dll a local maximum?
<marler8997> what do you mean by local maximum?
<marler8997> I have a weird idea, creating a wrapper dll around ws2_32.dll and using DllStartup to call WSAStartup
<andrewrk> marler8997, I'm *this close* to banning ws2_32.dll from zig std lib altogether
<marler8997> WSAStartup is not thread safe
<marler8997> andrewrk, there's another concern about calling WSAStartup as a fallback
<marler8997> oh right
<marler8997> I was curious, in your "hash" function, why do you need to copy the string to a temporary on the stack in order to call readIntNative on it?
<marler8997> fengb, I got pointed to your Swhash type


<marler8997> I recal the compiler was using one shared queue for jobs, did we switch to a work stealing strategy?
<marler8997> and it's fast because you're not hammering on the shared queue from all processor cores all the time
<marler8997> oh interesting, so instead of 1 shared queue, work stealing means 1 queue per core, and when you run out, you iterate through all the other queues?
<marler8997> ah yes, that's what I've come to understand as well I think. Keeping cache lines isolated between cores is number 1 priority
<marler8997> andrewrk, what was your epiphany?
<marler8997> yeah it's been bad for a while, no end in sight
<marler8997> yes
<waleee-cl> marler8997: is that US-style prices with no VAT?
<marler8997> VR gaming
<andrewrk> marler8997, what are your goals/plans for the hardware?
<marler8997> Should I go $2,200 for the rx 6900 xt or $1600 for a rtx 3070?
<marler8997> I can't take it anymore I'm buying an overpriced graphics card today


<marler8997> are async frames pinned in memory?
<marler8997> var frame: @Frame(foo) = undefined; _ = async frame foo(...);
<marler8997> I feel like maybe async would be easier to understand if we explicitly required the frame memory to be given at the call size
<marler8997> fengb here's my answer thanks to your help: https://www.reddit.com/r/Zig/comments/n3407d/need_help_writing_a_custom_event_loop/
<marler8997> yeah, but I think you're right, with that new nuget of understanding I'm able to solve this guys question on reddit now
<marler8997> does the documentation say this? I was reading it and don't remember it saying that
<marler8997> ah
<marler8997> "the block"?
<marler8997> so if you returned from your current function where you called async, then the async frame itself would also be invalidated correct?
<marler8997> you're saying it reserved space on the stack while the async call is alive
<marler8997> oh wait
<marler8997> can't be
<marler8997> but it's not a pointer to the stack is it?
<marler8997> I don't understand the lifetime of the memory pointed to by @frame()
<marler8997> the stack is invalidated after every function call regardless of whether you call it in a loop
<marler8997> there's something really screwy with the async implementation at the moment
<marler8997> is this expected, when I call an async function twice in a row, each call gets a new @frame() pointer, but when I call it multiple times in a loop, each call returns the same @frame pointer...?


<marler8997> the higher you turn on the air conditioner, the lower your cpu temps will be
<marler8997> wow
<marler8997> gotcha
<g-w1> marler8997: analyzed ir
<marler8997> sorry to interrupt, but air?
<marler8997> feb not far back enough :(
<marler8997> I'm looking for something from months ago
<marler8997> I think it only works for one day?
<marler8997> is there a way to grep this irc channel?


<marler8997> weird, it's like a poor man's version of ip
<marler8997> some googling reveals there is tcp over ipx (https://tools.ietf.org/html/rfc1791), however, I'm not familiar with ipx
<marler8997> you were saying that's bad design?
<marler8997> still have the question about using tcp outside of ip
<marler8997> good discussion, pedantic's confirmed
<marler8997> I suppose I forgot because of my familiarity with sockaddr_in, since it combines both the ipaddr/port
<marler8997> gotcha, now I see what you're saying, I forgot the port was part of the udp/tcp header
<marler8997> ah
<marler8997> why not?
<marler8997> you could send an IP packet to
<marler8997> I'm not sure what you mean by "connect to", it sounds like you're talking about implementation details?
<marler8997> is it though?
<marler8997> why say it's the port that differs rather than the ip?
<marler8997> couldn't you just as easily say it is the ip that is different, and the port is the same?
<marler8997> I mean, you bring up an interesting point but I'm not sure I agree with that perspective yet
<marler8997> not sure I quite understand
<marler8997> :)
<marler8997> well I'm curious what you're being pedantic about now
<marler8997> so why would you have 2 implementations of the Address type for udp/tcp?
<marler8997> of which udp and tcp share
<marler8997> the address of a udp packet/tcp packet is not apart of the udp/tcp protocol, it's apart of the IP protocol
<marler8997> why bad design?
<marler8997> you could implement it over serial for example
<marler8997> why's that?
<marler8997> oh?
<marler8997> you could implement udp/tcp on top of other transports as well
<marler8997> both udp and tcp are built on top of the IP protocol
<marler8997> that's not what I mean by equivalence here
<marler8997> they do?
<mq32> marler8997: to be pedantic:
<marler8997> ah, thanks
<marler8997> what is std/x ?


<marler8997> interesting ideas for sure, sounds like there's still thing to think about
<marler8997> So @maxSizeOf is comptime known, @sizeOf is runtime known
<marler8997> I suppose you could make those runtime known as well?
<marler8997> also affects @alignOf
<marler8997> true, how would you deal with @sizeOf?
<andrewrk> marler8997, no, the compiler wants to wait and see if it can delete fields, re-order fields, etc
<mq32> marler8997: you can delete fields from structs then when they are not required
<marler8997> what's the reasoning behind not allowing offsetof to be known at comptime? It's still known at comptime isn't it?
<marler8997> zig-install/bin/{exe's/dll's} and zig-install/lib/{so's}
<marler8997> maybe we use the bin/lib structure, but on windows, we deploy .dll files to bin?
<marler8997> like, /etc/install.conf
<marler8997> yes, but it would be opt in
<marler8997> another idea is to support platform install zig configuration defaults?
<ifreund> marler8997: I think you're certainly right that we need to be able to set bindir/libdir manually, we can't right now afaik
<marler8997> --prefix=/usr --bindir=bin --libdir=lib
<marler8997> mikdusan, sure for some platforms, that doesn't do anything for my platform (Nix)
<ifreund> marler8997: I don't install stuff manually system-wide, I use ~/.local as my prefix
<marler8997> though I know it's a common practice
<marler8997> Installing files like that system-wide doesn't seem like a good idea to me
<ifreund> marler8997: I don't like that, as then you can't just point your prefix at /usr to install system-wide, you have to toggle some other option as well
<marler8997> otherwise all your scripts and documentation will have to say things like "run zig-install/foo on windows, and zig-install/bin/foo on posix"
<marler8997> I think it would be simpler if we just install everything to the same directory by default, and then provide an option to split up bin/lib files
<marler8997> I think that was one of the other questions, whether to have windows/posix diverge
<marler8997> this is just a default though, for systems that seperate bin/exe, I imagine you could specify that
<marler8997> on windows, .exe and .dll need to be in the same directory
<marler8997> I can get behind that
<marler8997> build_root/install just as fine for me :)
<marler8997> none whatsoever
<marler8997> I vote for $CWD/install
<marler8997> lol, yeah you're the 2nd commentor :)
<marler8997> ifruend, I may have made an issue for that already
<marler8997> interesting
<marler8997> but I didn't know of a way to do it in a library
<marler8997> I had a similar idea to force a string to only be known at runtime, even though it was a string literal
<marler8997> I suppose it's a builtin so you can do whatever you need to
<marler8997> to force a value to be runtime?
<marler8997> is that possible?
<marler8997> right, is this only a comptime restriction then?
<marler8997> offsetOf = ptr - fieldParentPtr(...)
<marler8997> you can derive offsetOf from fieldParentPtr
<marler8997> wouldn't the same logic apply to fieldParentPtr that you're applying to offsetOf?
<marler8997> andrewrk, regarding proposal 8642 that it looks like you created


<karchnu> marler8997: yes. From what I saw, std.event already has an abstraction around epoll/kqueue, it would be awesome to use this and have something like libevent by default in the language.
<ifreund> marler8997: we don't use sr.ht's instance, rather one hosted by lavatech, so I don't think that affects us at all
<marler8997> karchnu, yeah I created an abstraction around epoll and/or select. would be cool to see if I could modify it to use something from std lib


<marler8997> lol, yeah that one's kind cool :)
<karchnu> marler8997: perfect, thanks!
<marler8997> thats my version of netcat, coded to be simple
<marler8997> you give good points about not including the aliases though
<marler8997> ok will do
<andrewrk> marler8997, wait for the result of https://github.com/ziglang/zig/issues/2115
<marler8997> I'm gonna have to go implement logic to detect and de-alias enums now...bleh
<marler8997> well, that's what my comment was about anyway
<marler8997> I was just looking at source / ast
<marler8997> for a project like this that has many users, I would think to employ a healthy amount of TDD but it's more like hacks on top of hacks
<marler8997> they've made some commits that have broken things horribly in the metadata, so it seems like they have no real testing
<marler8997> the win32metadata project is done so weird btw, it also seems very unorganized and unplanned
<marler8997> my guess is it would be even higher percentage in implemenation code
<marler8997> astnodes takes alot more memory in the internet_explorer example
<marler8997> I can't argue with that
<marler8997> dang, there's 1577 instances of enum aliases in win32!
<marler8997> my solution to that was to include them in a seperate list outside of normal fields
<marler8997> the reflection things is one of the issues I remember considering when I looked into @fieldAlias