<daurnimator>
oh cool. the async inference goes up to _start. that's cool!
<daurnimator>
if main is async, should we automatically create an event loop?
<rsdimenus>
andrewrk: what cpu is in the new build? :D
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
batok has quit []
<daurnimator>
with your fetchUrl/readFile example. if e.g. readFile was *not* a suspending function, would it work?
marijnfs_ has joined #zig
<andrewrk>
daurnimator, I was considering that too re: automatically creating an event loop for main()
<andrewrk>
daurnimator, planned to work but I haven't done that proof of concept yet
<daurnimator>
andrewrk: I suppose it means we'd need as @isAsync function.... which doesn't seem to fit well
marijnfs has quit [Ping timeout: 245 seconds]
<daurnimator>
like... it's obviously possible: you could in a stupid world, check for the compile error "main is async" and try again..
<daurnimator>
but I don't see how to fit it in to other things. maybe you do
<daurnimator>
oh.... hang on we have a possibly easier solution: what if we *always* async-called main?
<daurnimator>
andrewrk: ^
<daurnimator>
if you `async foo()` and foo is not async: does it get optimised to a normal call?
<Tetralux>
It turns too async.
<Tetralux>
turns foo async*
_whitelogger has joined #zig
mikdusan1 has joined #zig
mikdusan1 is now known as mikdusan
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 268 seconds]
ltriant has quit [Ping timeout: 246 seconds]
return0e has quit [Read error: Connection reset by peer]
rsdimenus has quit [Ping timeout: 272 seconds]
<hspak>
man there's a lot of catchup to do to beat Zig & Sharko on youtube search
mikdusan has quit [Ping timeout: 246 seconds]
ltriant has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
schme245 has joined #zig
ltriant has quit [Ping timeout: 246 seconds]
ltriant has joined #zig
kristoff_it has joined #zig
schme245 has quit [Ping timeout: 248 seconds]
LargeEpsilon has joined #zig
ltriant has quit [Quit: leaving]
kristoff_it has quit [Ping timeout: 245 seconds]
marijnfs_ has quit [Quit: WeeChat 2.4]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
laaron- has joined #zig
<mq32>
andrewrk: I have to reframe my question from the stream yesterday: "Can i check if i can resume (not await) a coroutine frame or if it is done already" usecase: multiple suspend points with runtime execution length
<mq32>
example: "Download *arg* files, return the result as an array."
schme245 has joined #zig
vramana has quit [Quit: Connection closed for inactivity]
mikdusan has joined #zig
schme245 has quit []
kristoff_it has joined #zig
mikdusan has quit [Ping timeout: 248 seconds]
return0e has joined #zig
return0e has quit [Read error: Connection reset by peer]
Ichorio has joined #zig
return0e has joined #zig
Tetralux has quit [Read error: Connection reset by peer]
<presiden>
I thought you was asking for porn, not user with nick pron
<presiden>
:D
mikdusan has quit [Ping timeout: 246 seconds]
<dimenus>
too early in the morning for that
<presiden>
anyway, yes, pron is in irc
<presiden>
tho, don't know if it's the same person as that hn user
Tetralux has joined #zig
avoidr has joined #zig
<gonz_>
> Although I find Zig very interesting—and I wish Andy the best of success with it—the trade-off that the Rust offers is more in line with my values and my ethics.
<gonz_>
You're all being super unethical, guys.
<dimenus>
because we like manual memory management? :D
<gonz_>
Presumably.
<dimenus>
while you can forget to free memory, the pervasive use of allocators seems to make tracking that easy even without valgrind
<dimenus>
And errdefer is such a great addition for cleaning up failure cases
<dimenus>
i'd much rather work in a language that doesn't force me into specific memory lifetimes based on scope
<mq32>
dimenus: true that!
<fengb>
I agree with gingerBill where he mentioned unknown lifetimes are pretty rare
<gonz_>
I was with this gnuvince guy partially until he brought ethics into it.
<fengb>
Most of the harder problems I’ve had is solved pretty elegantly with arenas. I kinda wish I knew about them before Zig
<dimenus>
fengb: cmuratori / jonathan blow talk about them a lot
<dimenus>
more common in games for sure
<kristoff_it>
I think in the grand scheme of things Rust will have a good impact on Zig, even on these subjects. The language (maybe with the help of some good old marketing efforts) has sensibilized a lot of people on the importance of correctness (great!) but as it often happens with complex messages, the nuances got lost in translation and a lot of people think a roided out type system is the only way to go. I think it's easier to provide more contex
<kristoff_it>
t to these people than try to build awareness from scratch, especially without a fat marketing budget.
<dimenus>
andrew is trying to put food on the table, not buy a yacht
<fengb>
He’s had the ultimate yak shaving journey
<dimenus>
i wanted to support Andrew back in 2017, but being on Windows created too much friction
<dimenus>
and the language has done the whole great desigil'ing since then
<mq32>
oh, on topic of linux: does someone here has experience with NixOS as a hobby development platform?
<mq32>
(hobby dev == stuff that's mostly not going to be published anyways)
<gonz_>
I feel like I showed up at precisely the right time. I had heard of Zig before but was busy stacking abstractions on top of each other for a while.
<fengb>
I believe Andrew is on nix
<gonz_>
mq32: I used it for Haskell and misc. tooling for a bit. I ended up feeling like it was too much work and I wasn't doing things that really benefited all that much from it.
<dimenus>
gonz_: you were busy stacking abstractions or zig was?
<gonz_>
I was
<mq32>
gonz_, that's my impression right now as well.
fubd has joined #zig
<fubd>
is there a "zig check" ?
<mq32>
i'm using Arch Linux and i'm still quite happy for hobby stuff
<fubd>
my program has gotten big enough that I want to make vim tell me when I have a compile error
<mq32>
but for publishing stuff to other people, linux is sadly more DLL hell than windows is
<fubd>
and it'd be nice to do get errors without having to emit a binary
<dimenus>
fubd: zigfmt will warn you about syntax errors
<dimenus>
not semantic errors though afaik
<fubd>
yeah the vim tools already do zig fmt
<gonz_>
Adding a checker to ALE for zig might be nice
<fubd>
that's what i have going
<fubd>
just calling zig build
<dimenus>
zig does do some aggressive build caching, so it's only compiling things you changed recently
<fubd>
i'll publish it once it's working well
<dimenus>
but i agree that having a check option might be a better option
<gonz_>
As far as I can tell the VSCode extension just does zig build and I'm just going with that.
<fengb>
Yeah a compiler check can skip LLVM altogether. Would save quite a bit of time
nairou has joined #zig
laaron- has quit [Remote host closed the connection]
<nairou>
andrewrk, just out of curiosity, is there any difference for you between Patreon and Github Sponsor? Do you have a preference?
<gonz_>
nairou: Github matches your sponsorship for 1 year, so github is better to use
<strmpnk>
GitHub is matching contributions in the first year so I think it'd be the better choice. I'm also not sure if GitHub is taking a fee or not but that also might be a factor.
<strmpnk>
Heh. Scrolled one line too little.
<gonz_>
andrewrk has asked explicitly for people to use GitHub sponsors, so I think it's a safe bet.
laaron has quit [Remote host closed the connection]
<nairou>
Ah okay. I knew he was excited to have an additional channel, didn't know he specifically asked for that to be used. Thanks.
laaron has joined #zig
laaron has quit [Remote host closed the connection]
sourgrasses has joined #zig
laaron has joined #zig
bheads has joined #zig
<fubd>
i'm confused about this error message 'unable to evaluate constant expression'
<fubd>
i'm trying to glue on a null byte at comptime but that's not gonna work, i'm going to need a buffer
<fengb>
But you're currently trying to slice what the compiler thinks is a non-array
<fubd>
i thought i just verified that it was an array
<fubd>
i thought "var" meant "try compiling this code and if it blows up complain"
<fengb>
Oh
<fubd>
and that the checking was up to you
<fengb>
I haven't used it much sorry >_>
<fengb>
Ah yeah sometimes comptime leads to weird errors.
<fubd>
i think in this particular case it would be useful to see an error message like "uniformLoc has a comptime parameter 'name', but you're passing a runtime parameter'
<fengb>
The tricky issue is that most functions work at comptime and if it doesn't, it's hard to know whether the function is bugged or the invocation is bugged
<fubd>
right
<fengb>
Yeah I had the same issue, which is why I jumped to comptime. I forgot the error message wasn't clear so I thought I misapplied my experience :P
<fubd>
ok, it compiles now--i just make an array on the stack of the right size
<fubd>
i guess this is a particular case where i start to wonder about code size
<fubd>
i.e., does the compiler generate a new copy of that function for every invocation with a different string length?
<fubd>
or, does the stack allocation happen "dynamically"
<fubd>
perhaps that's a question best answered by godbolt :)
<fengb>
Different copy for different comptime values
<fubd>
i don't have a good intuition for how the comptime stage actually gets "lowered"
<fubd>
yet
<fubd>
in that case, it might be better to have a "max size" and an assert, so that I don't explode out my code size....hmmm
<fubd>
warning: the compiler has created 200 versions of this function. are you mad?
<fengb>
lol
<fubd>
some footguns are more obvious than others
<fengb>
I remember someone (daurnimator?) created a comptime dispatch that was a "perfect closure". Downside is that it's a different function for every possible captured value
<Tetralux>
What do people think about having the ability to remove the current element while iterating over std.ArrayList?
mikdusan has joined #zig
<Tetralux>
Only I'm contemplating trying to make a PR for it.
<dimenus>
can you do inclusive end slicing in zig?
riverlakedev has joined #zig
<dimenus>
eg I want 0 through 6 not 0-5
<Tetralux>
s[0..n+1] xD
<dimenus>
or iterate backwards?
<Tetralux>
I've always preferred inclusive ranges, so I know your pain.
<riverlakedev>
but in that case every time you want to iterate all elements of array you'll have to do for x in y[0..len-1]
<bheads>
s[0..=n] //inclusive operator maybe??
<Tetralux>
riverlakedev: for (y[0..n-1]) |x| {}
<Tetralux>
But yes.
<Tetralux>
bheads: ugh...
<Tetralux>
I'd rather inclusive was default.
<Tetralux>
It makes it less confusing about what indices you'll get.
<bheads>
with 0 based indexing exlusive is used more
<Tetralux>
bheads: You use inclusive ranges already, it's just that you don't type the -1.
<Tetralux>
#Explicitness.
<riverlakedev>
and i'd be happy to be able to define my own functions like + (not redefine/overload), that work by taking argument from left and argument from right
<riverlakedev>
in that way we'd be able to define inclusive_range function with understandable name
<bheads>
UFCS could improve that
halosghost has joined #zig
<riverlakedev>
is there a library for build.zig that runs pkg-config and uses its output for linking and includes?
<andrewrk>
riverlakedev, I believe no one has done that yet
<riverlakedev>
i'll be first :D Good
<riverlakedev>
looks like that is only required thing to be able to build c/gtk project with zig build system
<bheads>
also would be nice to do for ranges: for(min..max+1) |val| { ... }
<bheads>
which leads back to the inclusive vs exclusive debate
<andrewrk>
I'm open to considering for loops supporting generators
<bheads>
+1
<scientes>
otherwise for is not very useful
<bheads>
what I like about the for range is the index var is not in the surrounding scope
<scientes>
yeah, alot of people get ticked by that
<scientes>
i don't see it as a big deal
<Tetralux>
Yeah, I don't like having the `var i: T = 0;` or whatever in my scope when I only want it in my loop.
<Tetralux>
It's fine if that's the only while loop, but not really if there's more than one.
<fengb>
I spent 2 hours debugging a "i += 0" so I'm in favor of generators :P
<bheads>
lol
<scientes>
fengb, if the 0 is a comptime_int that could be an error
<riverlakedev>
is there a minimal pastebin for code to quickly share here?
<gonz_>
euantor: Thanks for reminding me that sourcehut exists. I really like the principles behind the site and I feel like it's worth sponsoring.
<dimenus>
i use source hut for personal projects
<euantor>
gonz_: Definitely. I've been a supporter of them for a while, though I'm yet to move many of my projects over and I had some issues accessing their sevrices over SSH due to my ISP for a while
<Tetralux>
Is there a way to emit a "note" message at runtime?
<Tetralux>
( .. as part of a panic?)
<bheads>
one thought I had for testing the state of an async fn: you spawn multiple async file load functions, where you want to resume them but only want to await on them if its done. ie the async fn checks if the file load is done, else is suspends again
<Tetralux>
If std.ArrayList has an iterator that can remove elements, does it make sense to have that be the default one you get? Or does it make more sense to have to say `var itr = list.iteratorMut();` for that?
<Tetralux>
If an iterator that can remove elements _is_ the default one you get, you'd say `var itr = list.iteratorConst();` for the one that _cannot_ remove elements.
<Tetralux>
Unless there's a way to determine if the child type of a pointer is const?
<Tetralux>
Though maybe the explicitness is better anyway.
<fubd>
seems like the stdlib usually uses 'const' for const things and (nothing) for mutable things
<Tetralux>
Indeed. In which case, .iterator should give you an iterator that allows you to remove elements?
<Tetralux>
And if you have a `const` list, you have to do .iteratorConst instead.
<Tetralux>
I only ask because you normally do _not_ need to remove elems.
<Tetralux>
If you attempt to remove the same element twice, should it panic unconditionally?
<Tetralux>
Or should it only panic in debug mode, and be a no-op in release?
<fengb>
I'd expect it to be undefined behavior in release-[notsafe] modes
<Tetralux>
Remind me - does unreachable crash release?
<riverlakedev>
it looks like i cant read stdout of process started with std.os.execve...?
<fengb>
Tetralux: only release-safe
<fengb>
I kinda think we should rename the modes so it sounds like “this should be the standard” and not “training wheels”
<Tetralux>
But in release-fast it MAY have no effect, but MAY also just crash?
<Tetralux>
Or is it always no-effect?
<fengb>
It’s optimized out of -fast and -small
<fengb>
So undefined behavior if those points are reached
<fengb>
Who knows what LLVM would do
<Tetralux>
Meaning that it would be wise to assume that it'll just skip over unreachable in release-fast.
<Tetralux>
Should the iterator's remove procedures return the elem that was removed?
<Tetralux>
I assume that they should.
<Tetralux>
In which case, the fallback if you call remove twice in release-fast, is to return {}.
<Tetralux>
Seem reasonable?
fubd has quit [Remote host closed the connection]
riverlakedev has quit [Quit: Leaving]
<Tetralux>
Huh...
<Tetralux>
Okay.
<Tetralux>
I can't put a `return {}` after unreachable.
<Tetralux>
I can fix it, but that does seem to be contradict how release-fast works.
LargeEpsilon has quit [Ping timeout: 252 seconds]
<fengb>
release-fast implies removing all runtime checks. This includes overflows, array OOB, uninitialized memory, etc.
<Tetralux>
Indeed. But the compiler acting like you will never go beyond unreachable means that it might lead you into thinking that behavior is dependable.
<scientes>
Tetralux, to the contrary, its preventing you from assuming otherwise
<Tetralux>
It is, but that's not reality xD
<scientes>
oh i see
<Tetralux>
If you assume that unreachable is effectively noreturn, because the compiler essentially says so, and then in release-fast it keeps going, it might REALLY corrupt things.
<fengb>
If you need dependable error processing, you should be returning error unions
<fengb>
That's the point
<fengb>
release-fast == thar be dragons
<scientes>
yeah don't use unreachable if you don't want unreachale
<fengb>
Again, I think it's a copy problem. release-safe should imply "this is the normal release", while release-fast is "I'm driving without the seatbelt because I trust what I'm doing"
<Tetralux>
donpdonp: The bit field at the end of the second one?
<donpdonp>
oh thats something the zig translation doesnt handle yet?
<Tetralux>
Does Zig even _have_ bit fields?
<Tetralux>
It doesn't, right?
<gonz_>
Ls
<gonz_>
No
<donpdonp>
gonz_: dvorak? :-)
<gonz_>
Indeed :D
<gonz_>
Svorak A5
<donpdonp>
i recognized that typo :)
<Tetralux>
I tried learning Dvorak once.
<donpdonp>
colemak is a better choice, imho.
<Tetralux>
Why's that?
<donpdonp>
90% of the benefit, 30% of the learning curve
<fengb>
Zig has bitfields. C bitfields are underdefined so it's hard to translate properly
<Tetralux>
Is that because more of the buttons are the same as QWERTY?
<donpdonp>
Tetralux: yes.
<donpdonp>
fengb: hmm.
<fengb>
Clang example: struct { int a:8 }, the struct size is usize but "a" is only 8 bits. We magically gain padding, and the C standard doesn't specify where the padding goes
kristoff_it has quit [Ping timeout: 248 seconds]
batok has joined #zig
<oats>
does zig not have a mutable string type yet?
<companion_cube>
[]u8?
<oats>
so could that be used with unicode.zig in the stdlib for safe unicode strings?
<companion_cube>
safe mutable strings? :s
<fengb>
I think the plan is to keep Unicode in std rather than be a language feature
avoidr has quit [Quit: leaving]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 258 seconds]
<Tetralux>
Do we have a way to test if something panics yet?
<Tetralux>
And ideally also what message you get.
bheads_ has joined #zig
bheads has quit [Ping timeout: 246 seconds]
bheads_ is now known as bheads
<fengb>
scientes: these undefined behavior articles are amazing
<companion_cube>
damn, I don't understand the code in yesterday's stream
zangent has joined #zig
<companion_cube>
it's not clear which functions are async :/
nairou has quit [Remote host closed the connection]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 248 seconds]
<andrewrk>
dimenus, that's an important question that should be added to the docs. I believe the answer is "no it does not assume that". it certainly doesn't make a probabalistic assumption, it either assumes it or it doesn't
jmiven has quit [Quit: reboot]
<dimenus>
apologies for adding 'probably' to that
jmiven has joined #zig
<dimenus>
lol
<dimenus>
from my perspective, the hash doesn't seem to work with slices as it's the ptr of the slice itself that is hashed, not the contents
<dimenus>
i'll put together a test
<andrewrk>
the auto hasher? that's easy to check
<andrewrk>
it hashes the pointer as an int and the length
<andrewrk>
that's a counter intuitive default. I personally think it should either hash the contents or emit a compile error
<Sahnvour>
hashing keys should not follow pointers
<Sahnvour>
nor slices as they're just fat pointers
<Sahnvour>
if you want it to do that, provide your own hash function (to hash []const u8 as strings for example)
<andrewrk>
that's a reasonable stance to take
<companion_cube>
following pointers means having to handle cycles
<Sahnvour>
I'm sorry I don't have a clear rationale, but having pointers as keys in a hashmap is somewhat frequent and does not necessarily require hashing the pointees
<andrewrk>
maybe we can provide std.BytesTable(V) or something that has `[]const u8` key with the eq and hash functions set
<andrewrk>
weird name, but that's a pretty common use case
<andrewrk>
another brainstorming idea: std.DeepAutoHashMap(K, V)
<andrewrk>
"deep" meaning "it follows pointers"
<Akuli>
std.PointerFollowingAutoHashMap
<dimenus>
maybe make it not handle top level slices?
<Akuli>
hmm that's java
<dimenus>
that seems not intuitive then
<dimenus>
if i wanted the ptr, I'd give it a pointer
<dimenus>
i think a compile error is the most reasonable stance there, if it's &foo[0] instead, that's a lot more explicit
<andrewrk>
dimenus, a slice *is* a pointer. (and a length)
<dimenus>
agreed
<dimenus>
but as the user of a function, i would have to dig through the source to know that it's not actually hashing the contents
<dimenus>
emitting a @compileError points the user in the right direction
<dimenus>
eg "either give me just a pointer or use your own hash fn"
<andrewrk>
I do agree there is an organization / docs / naming / discoverability problem here
<Sahnvour>
would you expect a naked pointer to hash the content or not ?
<dimenus>
no
<andrewrk>
oh interesting, I'm using std.AutoHashMap incorrectly in tools/process_headers.zig
<dimenus>
Sahnvour: doesn't the current implementation follow the pointer though?
<Akuli>
why not have AutoHashMap take an argument to help it decode how to hash
<Akuli>
decide
<Sahnvour>
no it doesn't
<dimenus>
nvm
<andrewrk>
did it used to?
<dimenus>
sorry
<dimenus>
because it's an Auto, you can explicitly pass a hash function
<Sahnvour>
andrewrk: this changed in my recent PR, I assumed the CI tests would be enough to discover such cases
<dimenus>
I'm just trying to figure out a reasonable default
<dimenus>
Sahnvour: it does not, you're not doing that particular test
<dimenus>
i already have a broken test sample
<andrewrk>
Sahnvour, I think you made a reasonable decision. but I also think we do have an API usability problem - people are going to guess wrong about how this works
mattisme has left #zig ["Kicked by @appservice-irc:matrix.org : Idle kick: User has been idle for 30+ days."]
<Sahnvour>
agreed it needs documentation
<Akuli>
i think something like std.HashMap([]const u8, MyStruct, std.pointer_hash) would be quite good
<companion_cube>
what if you have a struct with 2 strings inside?
<companion_cube>
there you have to get into hash combinators
<dimenus>
and i apologize if I'm coming off as confrontational, i'm definitely just looking for discussion
<Sahnvour>
dimenus: that's expected, from my point of view
<Sahnvour>
to get your test passing, use a custom hash for strings
<Sahnvour>
autoHash does not follow pointers
<dimenus>
understood, I'm not arguing that it isn't possible
<dimenus>
i'm asking what a reasonable default is
<andrewrk>
AutoHash([]const u8, V) behavior changed in 5bd407b27890fbed82891289e6a2bf2da93c2a41
<Akuli>
doesn't zig distinguish "pointer to one item" and "pointer to array" clearly? i think using that here would be very good?
<Sahnvour>
I thinks that's similar as using `const char*` as a key, opposed to w `std::string`, in c++
<dimenus>
Akuli: it does, it's just the default implementation only hashes the ptr itself
<Akuli>
i think it should hash the contents for "pointer to array" cases
<Akuli>
but not for non-array pointers
<dimenus>
I'm more in favor of a compile error than changing the behavior of the implementation
<dimenus>
If you want naked ptrs, give it a naked ptr
<andrewrk>
my only claim is that if people are, in practice, being surprised at how something works, we probably need to change the API
<Sahnvour>
but can we be sure that's always an error to shallow-hash a slice ?
<Sahnvour>
I doubt it
<dimenus>
in what case would it not be?
<andrewrk>
not necessarily. the point of making a compile error would be to direct the programmer to choose a more explicit type. for example: ShallowAutoHash or DeepAutoHash
<Sahnvour>
I think there isn't much difference between a pointer and a slice. I totally agree this can be confusing though
<andrewrk>
this is a precedent set by, for example, the division operator
<dimenus>
there is a usage difference
<andrewrk>
for unsigned types, it does what you expect. for signed integers, does anyone know what it does?
<dimenus>
even if it's a very minute difference at the low level
mla has joined #zig
MajorLag has joined #zig
<gonz_>
Doesn't it seem less surprising and more consistent to never follow any pointers at all?
<andrewrk>
does zig have floored division or truncating division for signed integers?
<dimenus>
I'm not suggesting that it follow the pointer
tgschultz has quit [Read error: Connection reset by peer]
knebulae has quit [Read error: Connection reset by peer]
MajorLag is now known as tgschultz
<dimenus>
I'd rather have it be a compile error so the user knows "oooh, this default doesn't follow pointers - I need to make something that does"
<dimenus>
or something that reflects what I need
<gonz_>
Well, I agree with that
<Akuli>
python has flooring / and i have done e.g. (-nbits) / (-8) to figure out how many bytes are needed for storing a sequence of bits
<gonz_>
I was just trying to gauge whether or not the consensus was any different.
<andrewrk>
"auto" means "do what I mean." so if it's ambiguous what the user means, then it should be a compile error, and the user should have to choose a more precise API
<Sahnvour>
fair point andrewrk
<dimenus>
my point here is just that u8 slices are very commonly strings so by default, the AutoHash does not do what is intuitive with regards to string hashing
<Akuli>
hmm i think i actually did -(nbits // (-8)) for whatever reason
<andrewrk>
Akuli, zig gives a compile error for signed division
<Akuli>
yeah i think that's better than python's behaviour
<Sahnvour>
dimenus: in the end I agree, a compile error would be better to just get confusion out of the equation
<dimenus>
I also agree that chasing pointers in a default implementation is not useful
<dimenus>
If you want a deep copy, it should be explicit somewhere
<dimenus>
*deep hash
<Sahnvour>
Akuli: since we have default values for struct members now, the std.HashMap API could evolve to take a comptime configuration struct, indicating if the users wants deep hashing or not, and to provide custom hash/eql function, for example
<Sahnvour>
`false` would be the default, but yeah something like that
<Akuli>
i would expect []const u8 keys to "just work" with whatever the default is, because that is the most common case
<dimenus>
it's just the AutoHash, you can easily specify a different hash function
<Akuli>
how about std.PointerHashMap, very explicit
halosghost has quit [Quit: WeeChat 2.5]
<Sahnvour>
I'm not found of demultiplying the hashmap types when the only change is already expressible in the base API
<dimenus>
andrewrk: do you want an issue created for this or just a PR?
<dimenus>
this is going to break a lot of tests though......
<dimenus>
hmmm
<dimenus>
wait nvm, the hash tests don't use slices
<Sahnvour>
maybe we can try to flesh out the design of the hash module a bit more by the way
<dimenus>
sounds good
Akuli has quit [Quit: Leaving]
<Sahnvour>
I'd go for an issue
dimenus has quit [Quit: Leaving]
shritesh has joined #zig
shritesh has left #zig [#zig]
shritesh has joined #zig
LargeEpsilon has joined #zig
shritesh has quit [Quit: ZNC 1.6.6+deb1ubuntu0.2 - http://znc.in]
shritesh has joined #zig
LargeEpsilon has quit [Ping timeout: 252 seconds]
marijnfs_ has joined #zig
Summertime has quit [Quit: Sunsetting.]
Summertime has joined #zig
sourgrasses has quit [Quit: leaving]
Ichorio has quit [Ping timeout: 264 seconds]
Summertime has left #zig ["Leaving"]
Ichorio has joined #zig
rsdimenus has joined #zig
<nrdmn>
andrewrk: when compiling EFI apps with >4kB stack usage, zig complains "lld: error: undefined symbol: __chkstk". We don't need stack checks on uefi. Do you know any elegant solution to this? I have not found any way to turn off stack checking globally for EFI binaries, only for individual functions.
<andrewrk>
nrdmn, yes, I belive target_supports_stack_probing sholud be modified to return false for uefi
<nrdmn>
I tried returning false in target_supports_stack_probing, but that doesn't seem to help
<andrewrk>
that might be the one where llvm decides to emit calls to chkstk based on the target, so we should provide the implementation. can you try adjusting the logic in that compiler_rt code to include the uefi target?
<andrewrk>
if your goal is to not emit calls to uefi, that might require upstream patch to llvm or figuring out how to set a configuration flag on the target
<andrewrk>
*emit calls to chkstk on uefi
knebulae has joined #zig
<nrdmn>
builtin.os is not builtin.Os.windows on uefi
<andrewrk>
nrdmn, that's good to know. would you also be willing to try modifying the logic in compiler_rt (linked above) so that the if statement did builtin.os == .windows or builtin.os == .uefi ?
<andrewrk>
I don't see a reason why not to have debug features enabled for debug builds even on uefi
<nrdmn>
apparently, in llvm, Subtarget.isOSWindows() == true for uefi applications
kristoff_it has quit [Ping timeout: 246 seconds]
<andrewrk>
nrdmn, that is decided by the function get_llvm_os_type in target.cpp
<andrewrk>
do you think it should be different?
<andrewrk>
I considered it briefly in the past and made this decision
<nrdmn>
ZigLLVM_Win32 directly translates to Triple::Win32, right? LLVM's Triple.h doesn't offer any better alternative and I'm not sure what it implies if we set it to Triple::UnknownOS for UEFI
<andrewrk>
nrdmn, yes that's right
<andrewrk>
it has to do with the ABI of function calls chkstk and stuff
<nrdmn>
checking for uefi in std/special/compiler_rt.zig makes the error message go away, but won't that add pointless stack probes?
<andrewrk>
what makes them pointless?
kristoff_it has joined #zig
<andrewrk>
in debug mode, they turn undefined behavior into a panic that tells you stack overflow occurred
<andrewrk>
and the cost is pretty cheap, the checks are only needed for functions with large stack frames
wootehfoot has quit [Read error: Connection reset by peer]
<nrdmn>
uefi only guarantees a minimum stack size of 128K in boot mode, but there's no way to determine the actual stack size
<nrdmn>
If I'm writing my own OS, I'm going to set up my own stack at some point, which very well may be much larger than that. I don't want it to panic in debug mode because zig doesn't know about my stack
<andrewrk>
if the provided chkstk implementation is invalid for uefi then certainly the correct solution is the diff you linked earlier
<andrewrk>
at this point you're the only zig community member doing UEFI stuff, so I trust your judgement
<nrdmn>
I have no idea what my diff means for other targets