<marler8997>
I want to lookup a convo in zig irc that happened sometime last year, anyone know of a way to do that?
2021-05-18
<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>
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?
<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>
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?
2021-05-13
<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
2021-05-06
<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)
2021-05-05
<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>
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
2021-05-04
<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>
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...?
2021-05-01
<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?
2021-04-30
<marler8997>
weird, it's like a poor man's version of ip
<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
2021-04-28
<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
2021-04-27
<marler8997>
lol, yeah that one's kind cool :)
<karchnu>
marler8997: perfect, thanks!
<marler8997>
thats my version of netcat, coded to be simple