<daurnimator>
andrewrk: btw, any top priorities you'd like me to look at? I've got lots of things I want to do with zig; but not sure how to prioritize them :P
<andrewrk>
give me a couple hours, I'm typing up a proposal for an epiphany I had while running just now and then I'm grabbing a bite to eat
<adtac>
mikdusan: I'm not awarem today is my first day with zig
<adtac>
but if that was intentional, I can remove that commit
<andrewrk>
I'm afk but I believe I figured out how to make ptrcast, inttoptr, and fieldparentptr safety checked
<andrewrk>
If you look at the proposal I just opened
<andrewrk>
Alright back in a bit
<mikdusan>
adtac: honestly i have no idea; it was just a nagging and probably inconsequential question i had about stack trace behavior
<mikdusan>
adtac: probably best forget i asked :)
<mikdusan>
MTSBMMS
<tgschultz>
andrewrk: I'm a bit confused, isn't the whole point of @ptrCast and @intToPtr to change the type?
<tgschultz>
oh wait, I get it. It only safety checks things that have no well-defined memory layout.
<tgschultz>
So like, in type-erasure and restore circumstances. That might actually be really helpful in Interface Reform.
<tgschultz>
andrewrk: another note, I'm not sure that'll buy much for @fieldParentPtr either. I did my own experimentation with a similar concept when I first started with zig and as I recall the actual behavior of the stack kept data 'valid' a lot longer than I'd have thought. Hmm... is it a terrible idea to overwrite the stack frame with 0xaa on return in debug/safe builds?
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
<daurnimator>
tgschultz: that brings up a related issue I've thought about a few times: writing `undefined` after freeing or deinit-int items
<daurnimator>
e.g. I've stared at .deinit methods before and wondered why they don't set fields to undefined
<andrewrk>
daurnimator, you would do like the example and use inline assembly with that special comment with --emit=asm and then run the llvm-mca command like it says there
<emekankurumeh[m]>
i just hope zig debug builds don't become as slow as rust debug builds.
<andrewrk>
I think it's best practice to do this, but it's not enforced
<andrewrk>
emekankurumeh[m], you mean compile time, or run-time?
<daurnimator>
andrewrk: heh... I think your link there actually has it wrong!
<andrewrk>
how so?
<emekankurumeh[m]>
rust is slow on both accounts, but specifically meant run-time
<daurnimator>
andrewrk: hrm... so I suppose we conflate two things: IMO there should be a "reset"-like function. that does init on an existing data structure. I guess that's myob.* = MyClass.init()
<andrewrk>
right. deinit() in english is "free the associated resources and then set to undefined"
<daurnimator>
it's weird how deinit() isn't really the mirror of init()
<andrewrk>
isn't it?
<andrewrk>
init() operates on undefined memory and makes it into a valid state
<andrewrk>
deinit() operates on a valid state and makes it into undefined memory
<daurnimator>
it doesn't operate on undefined though; it returns an object by value
<daurnimator>
in practice with copy ellision its the same thing
<daurnimator>
but... weird not-quite-mirror
<andrewrk>
hm I don't see how it's not a mirror
<daurnimator>
it would be a mirror if init() took a *Self
<andrewrk>
it essentially does. with no-copy semantics it literally does
<daurnimator>
right; which i said above
<andrewrk>
assignment is initialization
<daurnimator>
okay I think I'm convinced: style guide addition?: deinit() methods should end with `self.* = undefined;`
<andrewrk>
var x: i32 = undefined; x = 1234; x = undefined;
<andrewrk>
that sounds good; though you're inventing a new guide - one that talks about semantics rather than style
<andrewrk>
but certainly a useful guide
<daurnimator>
andrewrk: going further: `allocator.free(x)` should always be followed by `x = undefined`
<mikdusan>
in a release-fast is `x = undefined` a no-op ?
<daurnimator>
mikdusan: yes.
<andrewrk>
daurnimator, for that one we can put it in the Allocator interface
MajorLag has joined #zig
<daurnimator>
andrewrk: howso?
<andrewrk>
mikdusan, even better than a no-op - it's a no-op that gives the optimizer more information
<mikdusan>
ah true!
<daurnimator>
andrewrk: btw, will `self.* = undefined` be a single valgrind request or one for each member?
<andrewrk>
single
<daurnimator>
awesome :)
<andrewrk>
howso -> simple: in free() we put the x = undefined right after the call to shrinkFn
<andrewrk>
I honestly expected it to already be there
<andrewrk>
I must have forgotten
<daurnimator>
andrewrk: but you pass the pointer to free(); not the pointer to your pointer.
<andrewrk>
ahh right. I am mistaken. It's the allocator implementation's responsibility to do what it will with the freed memory. it may become unmapped
tgschultz has quit [Ping timeout: 250 seconds]
MajorLag is now known as tgschultz
<andrewrk>
I actually don't agree about allocator.free(x); x = undefined;
<andrewrk>
I think it's contextual. certainly sometimes, maybe even often, that would be appropriate
<daurnimator>
andrewrk: IMO dangling pointers are a hazard
<andrewrk>
certainly. I have an idea to completely solve that for stack variables. the GeneralPurposeDebugAllocator is on track to solve that for heap memory
<daurnimator>
I still feel like setting them to undefined would be good practice
<andrewrk>
I'm not sure we're even disagreeing. I'm just saying it's contextual. For example if you had a ?*T you would simply set it to null
<daurnimator>
there's always exceptions to rules like this. e.g. if we have a XOR-linked-list, then we may need to keep the pointer around for a bit to find the next node...
<daurnimator>
which is why it's a "guide"; not a compile error ;P
tgschultz has quit [Ping timeout: 276 seconds]
qazo has quit [Ping timeout: 255 seconds]
<daurnimator>
andrewrk: so... priorities you'd like from e.g. me?
<andrewrk>
do any of the contributor friendly labeled issues look good to you?
<andrewrk>
this issue is a good investment because it means that work done on translate-c is the actual real work that will be in the self-hosted compiler
<daurnimator>
I don't particularly want to get into the C++ side of development.
<daurnimator>
I that issue mainly now translating C++ to zig?
<andrewrk>
yes it is
<daurnimator>
Is there a WIP branch somewhere?
<andrewrk>
it's master. you can look at `zig translate-c-2`
<andrewrk>
look at some of those latest commits
<andrewrk>
you would have to write a C API wrapper for libclang. other than that it's all .zig code
<andrewrk>
so it is a bit of C++ because you have to understand the libclang C++ API
<andrewrk>
understood if that's not your jam
<daurnimator>
Writing the C wrapper for libclang is the bit I'm not really interested in
<andrewrk>
fair
<andrewrk>
any of the other contributor friendly issues?
<daurnimator>
Many of them seem pretty low priority...
<daurnimator>
Could do the hex floating point one... just pinged the user who already said they'd do it
<andrewrk>
how about inflate/deflate in the std lib
<daurnimator>
You know I'm interested in #2007... but that's mostly blocked on coroutines (and for the parts that aren't... I already have a PR open :) )
<daurnimator>
andrewrk: could do. pinged other users that have expressed interest.
<andrewrk>
I'm pretty confident nobody is working on that
<daurnimator>
schmee said they were as recently as March
<daurnimator>
I might tackle #480
<shachaf>
Oh man, coroutines. I should read what's been going on with that.
<andrewrk>
daurnimator, I wouldn't limit yourself to 0.5.0 either
<emekankurumeh[m]>
i did a little work somewhat related to #2007, prettying up the apis for networking operations. it's a little stale though: https://github.com/emekoi/zig/tree/socket
<shachaf>
Looks like it's been written up in the past few days?
<andrewrk>
daurnimator, for 480 would you try to do a release mode allocator?
<daurnimator>
andrewrk: yes.
<andrewrk>
exciting
<daurnimator>
obviously with as many safety features as possible
<daurnimator>
but nothing that would impact speed
<andrewrk>
really? I thought release fast would not care about any safety features
<andrewrk>
I guess if it truly did not affect perf
<daurnimator>
andrewrk: misc ideas: undefined in the right places; guard pages; alloc/free counter (per bucket?); some catching of double frees.
<daurnimator>
can probably also have canaries around non-page sized allocations (where guard pages wouldn't work)
<daurnimator>
andrewrk: want me to push orderedRemove now and we debate rename later?
<andrewrk>
sounds good
<andrewrk>
merged. alright I'm going to bed, good night
<daurnimator>
night
<daurnimator>
http.headers PR rebased on top of master.
ltriant has quit [Quit: leaving]
ltriant has joined #zig
<daurnimator>
emekankurumeh[m]: so I've been thinking about a socket library for zig for a while
<daurnimator>
emekankurumeh[m]: watching the way things are going... I think we need a higher level abstraction than what you have there; as well as a lower level one....
ltriant has quit [Client Quit]
<daurnimator>
emekankurumeh[m]: to explain further: OSes are opening up options to "batch" operations: so that you can e.g. have multiple setsockopt calls in flight at once.
<daurnimator>
similarly, you can queue dependant operations; e.g. "setsockopt*5, then listen, then accept"
jjido has joined #zig
<emekankurumeh[m]>
or perform them asynchronously
<daurnimator>
so the API I think I'd want is one where you have a `mysocket.setDesired(sockopt)` and then an optional `mysocket.drainQueue()`
ltriant has joined #zig
<daurnimator>
where a naieve (and portable) implementation just sets up operations in a buffer; and only does the syscalls on drain.
<emekankurumeh[m]>
that sounds similar to the builder pattern i nrust
<emekankurumeh[m]>
zig has some abstractions over overlapped io in std.event.fs so i think i would start from there. probably look at rust's mio/miow
ltriant has quit [Quit: leaving]
<daurnimator>
emekankurumeh[m]: oh, you *can* shared the commandbuffer thing between all std file "HANDLE" things: so yes, this can spread to the file module IMO
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
purelazy has joined #zig
<purelazy>
Hi
<daurnimator>
purelazy: hi
<purelazy>
Hi daunimator. I'd like to try to compile for an Arduino (AVR core)
<purelazy>
Was wondering if anyone had a link to a howto page
_whitelogger has joined #zig
<daurnimator>
I know someone was looking at it before, but not sure if they got anywhere. What stage is your cpu architecture in the support list?
<purelazy>
daurnimator: Tier 4
<daurnimator>
purelazy: that pretty much means you'll have a lot to figure out yourself
<daurnimator>
purelazy: I assume you're looking for freestanding support?
<purelazy>
daurnimator: I don't know what freestanding means
<daurnimator>
purelazy: meaning no Operating System
<daurnimator>
purelazy: you might try and build an object file for your cpu containing something simple like a function that does `return 42`
<purelazy>
daurnimator: Then yes. The Arduino has no OS
<daurnimator>
e.g. try and build a file containing the following with `zig build-obj`: export fn meaningoflife() i32 { return 42; }
<purelazy>
I should probably play around with the Linux Tier 1 first
<daurnimator>
purelazy: FWIW I don't see 'avr' anywhere in the output of `zig targets`
<daurnimator>
purelazy: you may have to compile your LLVM with custom flags to get AVR support?
<tyler569>
if you look at the tier descriptions though, t4 may require a special experimental LLVM
<daurnimator>
purelazy: yes. but see definition of tier 4 https://ziglang.org/#Tier-4-Support : LLVM may have the target as an experimental target, which means that you need to use Zig-provided binaries for the target to be available, or build LLVM from source with special configure flags. zig targets will display the target if it is available.
<daurnimator>
purelazy: not sure where/how you installed your 'zig' binary. What is your output of `zig targets | grep avr`
<daurnimator>
purelazy: I'd start by trying to link in a library build like that to an existing arduino C project. If that works then you can see how far things go....
<purelazy>
daurnimator: First I need the compiler
<daurnimator>
purelazy: you can just download a zig binary from the download page
<purelazy>
I'll be getting zig-linux-x86_64-0.4.0+f8117a07.tar.xz
<daurnimator>
purelazy: sure. that's what I used in my gist above.
<purelazy>
daurnimator: And do I need LLVM stuff?
<daurnimator>
purelazy: the binaries on the download page include everything you need
<daurnimator>
and luckily enough they were built with the experimental LLVM AVR target enabled :)
neceve has joined #zig
<purelazy>
daurnimator: What is zigs relation to C (and/or) C++.
<daurnimator>
purelazy: what do you mean by "relation"?
<daurnimator>
in terms of syntax? in terms of zig implementation? in terms of interoperation?
<purelazy>
I read Zig is also C, so would Zig be in the "superset" relation?
<purelazy>
Like C++ is a superset of C
<daurnimator>
purelazy: zig is not also C.
<daurnimator>
purelazy: zig has a few interesting interoperation points: 1. @cImport lets you import a C header and use it in zig code. 2. `zig translate-c` will translate C code to zig code. 3. you can use `zig build` as a C build system and `zig cc` as a C compiler.
<purelazy>
"Zig is also a C compiler" on the Zig homepage
<daurnimator>
purelazy: yes. which is to say that the zig binary includes a C compiler (`zig cc`). zig the languge isn't a superset of C.
<purelazy>
So how would you describe Zig, the language - in relation to C or otherwise?
<purelazy>
It is very C-like :)
<daurnimator>
purelazy: the language? implicit; un-managed; powerful; fast; "safer than C"
<daurnimator>
uh, s/implicit/imperative/
<purelazy>
daurnimator: would you include "C-like syntax" in your description list?
<daurnimator>
purelazy: no not really
<daurnimator>
it's C-like in the same way that all unmanaged imperative languages look like C....
<daurnimator>
(and even some managed ones)
<purelazy>
daurnimator: OK. I'm getting it
<purelazy>
It's not C
<presiden>
I like that in declaration, the identifier name is first then followed by type,
<presiden>
unlike in C where the type first followed by identifier
<presiden>
daurnimator, yeah, type inference becoming mainstream might be one of the reason
<purelazy>
daurnimator: So its not C and Zig is also a C compiler. That makes no sense to me at all
<purelazy>
What am I missing?
<daurnimator>
purelazy: zig the language vs zig the binary?
<purelazy>
What is zig the binary
<purelazy>
(sound like a new Marvel character)
<purelazy>
I know what a language is
<daurnimator>
purelazy: the program that you download called "zig"
<purelazy>
Zig the binary is a C compiler
<daurnimator>
yes. in addition to: a zig (the language) compiler, a build system, and more.
<purelazy>
daurnimator: Thanks. That's very clear now.
purelazy has quit [Quit: Page closed]
Zaab1t has joined #zig
Zaab1t has quit [Client Quit]
hio has joined #zig
_whitelogger has joined #zig
tgschultz has joined #zig
<tgschultz>
andrewrk, I meant, like, can we, in debug/safe, insert a call right before return that gets the current stack frame and sets it to 0xaa? No heap allocation involved.
rivten has joined #zig
<rivten>
Hello everybody ! I hope everyone is doing fine :) I had two quick questions for everybody. I'm trying to dynamically load zig code from zig code. There's two things I'm blocking on : (1) I didn't find any build.zig files to build DLL (windows and linux). (2) Am I forced to export my functions in my DLL with the C ABI even if I'm loading them back in Zig afterwards ?
<rivten>
(I guess the answer to the second question is yes since the DLL could very well be loaded from another language, but maybe there's a better way in Zig to implement dynamic code loading)
<daurnimator>
rivten: 1. what are you struggling with? I wrote one once and it seemed simple enough. 2. yes :(
<rivten>
Well I just struggle with finding examples :( All I ever see is reference to the Tetris build file which builds an exe and then run it.
<tgschultz>
Once you remove all the things that could never work across a DLL boundary anyway (comptime, type checking, etc.) you're basically at the C abi already anyway.
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
scientes has joined #zig
<rivten>
Ok ! I got it working in the end :) it feels great ahah
<rivten>
it was pretty seamless in Zig once I found out what to do
halosghost has joined #zig
mouldysammich has quit [Quit: WeeChat 1.9.1]
scientes has quit [Ping timeout: 258 seconds]
scientes has joined #zig
rivten has quit [Ping timeout: 256 seconds]
scientes has quit [Ping timeout: 252 seconds]
<andrewrk>
tgschultz, re: insert a call right before return that gets the current stack frame and sets it to 0xaa -> the problem is that when you call a function, it will overwrite your 0xaa's with the new function call frame. then if a dangling pointer is used it clobbers the new fn call
<tgschultz>
that's true today too. but imagine we add the saftey checks you're talking about. If I return a pointer to such an object that exists in my stack frame and then later try to use it, it will almost certainly assert because the check will the type code as undefined or whatever data that memory has been overwritten with. There's less chance of it mysteriously working in debug and then not in release-fast.
<tgschultz>
though I see your point about allocating and invalidating that frame for other pointers.
<andrewrk>
I see what you're saying - based on https://github.com/ziglang/zig/issues/2414 if type ids were e.g. 4 random bytes, it would be very unlikely that the new fn would populate those bytes the same way
<andrewrk>
but this would only catch @ptrCast, @intToPtr, etc
<andrewrk>
consider that you might just try to dereference a pointer that you thought was the same type all along
jevinskie has joined #zig
<mikdusan>
andrewrk: small revisit. i mentioned last night about --color { auto, never, always } . and that's pretty std for command line option. but not for ENV var... i don't find any examples of a standard. there is PR 2413 for env ZIG_DEBUG_COLOR
<mikdusan>
do you think ZIG_DEBUG_COLOR should simply accept the same kind of string values?
<andrewrk>
yes
<mikdusan>
ok i'll comment on pr
<andrewrk>
"never" "always" and then anything other than that means "auto"
<mikdusan>
yup!
<andrewrk>
docgen.zig needs updated
<mikdusan>
this PR is for env variable. i think we'll need another for instances of --color: src/main.cpp, doc/docgen.zig, src-self-hosed/main.zig, src-self-hosted/arg.zig
<andrewrk>
docgen.zig makes use of that env variable
<mikdusan>
your grep-fu is superior. i'll add request to pr.
<tgschultz>
we haven't implemented @OnePossibleValue() or whatever that was yet have we?
<andrewrk>
correct
bugabinga has joined #zig
<andrewrk>
daurnimator, is 2326 ready for merge?
<andrewrk>
I'm ok with doing the posix api layer thing separately later
neceve has quit [Read error: Connection reset by peer]
<andrewrk>
what did you do to get the msghdr struct layouts for arm64, netbsd, and freebsd?
meheleventyone has joined #zig
wilsonk has quit [Ping timeout: 255 seconds]
gwn has joined #zig
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gwn has left #zig [#zig]
Sahnvour has joined #zig
<shritesh>
andrewrk: Can you look at 2420? I'm new to POSIX and I'm following the same structure with all the other functions.
<andrewrk>
shritesh, yep I'm going through all the PRs now
<andrewrk>
currently on 2381, going from oldest to newest
<shritesh>
Thanks. Cool-ish demo coming tonight
<tgschultz>
ok, PackedIntArray/Slice are written, tested with bit widths from 0-256. I'll give it one more look over after lunch then run a full CI and make a PR. std.mem seem a reasonable place for it?
* andrewrk
excited
<andrewrk>
tgschultz, my suggestion: put the new code in a new file, and then all we have to figure out is what is the std lib path, whether it be std.mem.PackedIntArray or std.something_else.PackedIntArray
<andrewrk>
honestly I'd be fine with std.PackedIntArray
jjido has joined #zig
shritesh has quit [Quit: shritesh]
<tgschultz>
That makes sense, that's where array_list is
<tgschultz>
ArrayList rather
wilsonk has joined #zig
<Sahnvour>
andrewrk, are there plans to have traits over allocators, to allow specific optimized behaviour by the clients?
scientes has joined #zig
<tgschultz>
why would that be necessary? create different allocators for different optimized use cases.
<Sahnvour>
library code could make use of it if present, and still support any allocator
<Sahnvour>
for example iirc some windows allocation functions zero out the memory, but I doubt that's the case for most general allocation functions
<andrewrk>
Sahnvour, not sure, at this point
wootehfoot has joined #zig
bugabinga has quit [Ping timeout: 258 seconds]
qazo has joined #zig
<tgschultz>
that means shoving that information into every allocator interface struct, and every routine that does allocation would have to make the decision to take advantage of it or not. I'd say its better to let the programmer determine which features to take advantage of by passing an appropriate allocator.
<scientes>
yeah it should be another allocator
<tgschultz>
ever write some code, and some tests, and then the code works the first time and your reaction is to get suspicious?
<andrewrk>
every time
<scientes>
^^^this
<andrewrk>
sometimes I use gdb just to make sure the code is doing what I think it's doing
<tgschultz>
Originally PackedIntSlice was just PackedIntArray but with a slice of u8 backing it instead of an array. Then I decided to make it an actual slice of a PackedInt(Array/Slice) and it seems to actually have been as simple a change as it appeared.
<andrewrk>
living the zig dream
<andrewrk>
when you don't hit immaturity / compiler bugs it's actually quite lovely
<scientes>
haha
<tgschultz>
yes, the compiler bugs are annoying. They are a lot fewer than they were a year ago though.
return0e has quit [Remote host closed the connection]
<mikdusan>
andrewrk: can u clarify: when asserts are **enabled** are you getting a good test run or failure?
<mikdusan>
(re: #2421)
<andrewrk>
mikdusan, on my laptop I am using the build instructions from the README and getting all tests passed
<andrewrk>
the build instructions from the README use the default build mode which is Debug which has assertions enabled
<mikdusan>
wow.
<emekankurumeh[m]>
does zig build with experimental llvm targets enabled ?
<andrewrk>
can you clarify the question?
<scientes>
zig uses the system llvm
<andrewrk>
scientes, this is not true for the official ziglang.org/download builds
<scientes>
yes that is true
<scientes>
so yeah, clarification
<andrewrk>
mikdusan, I just did a 100% clean build on my macos laptop from a fresh terminal, fresh clone of zig, all tests passed
<mikdusan>
this is me sitting here perplexed
<mikdusan>
all i can think of is my /usr/include is empty. and /usr/local/include is near empty (has fuse/ and that's it)
<andrewrk>
it could be nondeterminism in LLD
<mikdusan>
can u pastie output of: zig build test --verbose --verbose-cc --verbose-link --build-file test/standalone/static_c_lib/build.zig
<mikdusan>
just checking: is your `ar` from /usr/bin ?
<Sahnvour>
tgschultz, this is not related to the programmer's choice of allocator. they have no control over what advantage the library code they use can make of the allocator's specifics
<andrewrk>
mikdusan, zig no longer shells out to `ar`; it uses ZigLLVMWriteArchive
<Sahnvour>
it could be done with flags stored in the allocator struct, but I don't have a strong opinion about it, just thinking
halosghost has quit [Quit: WeeChat 2.4]
shritesh has joined #zig
mht has quit [*.net *.split]
niftynei has quit [*.net *.split]
nore has quit [*.net *.split]
l1x has quit [*.net *.split]
<andrewrk>
whew. alright finished that round of PR reviews. Next round is on Tuesday. and now I get to do some coding
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
mht has joined #zig
niftynei has joined #zig
nore has joined #zig
l1x has joined #zig
return0e has joined #zig
<tgschultz>
Sahnvour, that's how it is in C's world of One True Global Allocator, but we don't have to do it that way in zig. The library takes an allocator, the programmer gives it an allocator that does what the programmer wants it to do.
Sahnvour_ has joined #zig
<companion_cube>
it's sometimes the case in C, too, I think — like, sqlite can take a custom allocator iirc
<Sahnvour_>
I understand that, I must not be expressing myself clearly. An allocator that gives zeroed memory (which is not always the case AFAIK) can be useful to some container or algorithm that would then not need to do it itself (assuming it wants zero initialized memory). But since it has to support any allocator implementing the interface, it currently is unable to know wether it can skip doing `memset(dest, 0, size)` and would in some cases do it
<Sahnvour_>
when it is not necessary.
Sahnvour has quit [Ping timeout: 250 seconds]
<Sahnvour_>
Agreed that's not necessarily a commun usecase, but there may be some like that.
<Sahnvour_>
My point is the programmer doesn't need to know about this, that's a contract between the allocator implementer and the container/algorithm using it. That's a side bonus on top of the choice the programmer made regarding its allocation strategy but he has no control over it.
<Sahnvour_>
s/he/they
<scientes>
Sahnvour_, yes, but it would be a differn't allocator
<scientes>
Sahnvour_, maybe allocators could have attributes like that
<Sahnvour_>
Talking about VirtualAlloc on windows, which does exactly that. This is a minor property, one should very probably not base their allocator choice on it. But this property can be used by some piece of code they also may not need to know how it works. That's just out of the programmer's scope in 99% cases.
<Sahnvour_>
If you're using a VirtualAlloc-based allocator, you have no choice but to get zeroed pages, your choice is severely limited. But why not make the most out of it ?
<tgschultz>
WIf the algorythm requires zeroing memory then it should take a ZeroingAllocator, or take var and check if it is an Allocator or ZeroingAllocator to make its decision. ZeroingAllocator could just be a wrapper for Allocator but it forces the programmer to assert that the allocator they're passing does the zeroing for it. This avoids having a bunch of bit flags in the Allocator interface struct that are only used in a handful of
<tgschultz>
cases.
<tgschultz>
Probably an ever growing number of bit flags at that
<donpdonp>
is there useful information to capture when a zig build crashes?
<donpdonp>
not building zig, but while zig is building a project
<Sahnvour_>
the thing is, we're usually passing &mem.Allocator's around, and not the actual FooAllocator, so the type-based solution is less convenient. But I don't like adding another field to Allocator either... whatever
<tgschultz>
that's why I mentioned the interface reform. I think the standard should be that we preserve type information unless it is necessary to erase it.
<tgschultz>
current interfaces don't do that
<tgschultz>
wait, no, I didn't mention that because I erased that version of my reply.
<scientes>
Sahnvour_, you don't need another field, this is a compile-time thing
<scientes>
all you need is the @typeName proposal that was accepted
<scientes>
or memberName or whatever it was
<Sahnvour_>
tgschultz, I didn't see your message mentionning this, and I agree :)
<scientes>
or yeah interface reform
<Sahnvour_>
scientes, in the current state allocators can only carry information through runtime values to the code using them, since we erase the type via function pointers
<Sahnvour_>
tgschultz, oh right, that explains it
<tgschultz>
what we're trying to accomplish with interface reform is a userland proof of concept for taking `var` as the standard and type-erasing for storage or exporting.
<tgschultz>
ultimately that may become something handled at the language level
wilsonk|2 has joined #zig
<mikdusan>
how about adding an arg (not a storage bit!) to existing functions or new functions that capture intent. programmer tells allocator give me zero'd memory. allocator decides how to efficiently do it.
wilsonk has quit [Ping timeout: 258 seconds]
<Sahnvour_>
this approach might end up adding many new functions/parameters, which is not really desireable