<daurnimator>
emekankurumeh[m]: but that would be pointer sized...
<daurnimator>
I guess the questions ends up being: "how can I embed an opaque type in another structure to get another structure (but with methods) of unknown size?"
<daurnimator>
which now I phrase it like that.... seems related to supporting VLS
<emekankurumeh[m]>
but you can't store a OpaqueType, only pointers to it
<daurnimator>
emekankurumeh[m]: that's the problem/issue :P
<emekankurumeh[m]>
that makes sense
rjtobin has quit [Ping timeout: 272 seconds]
ltriant has quit [Ping timeout: 244 seconds]
ltriant has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
kristoff_it has joined #zig
jjido has joined #zig
return0e_ has joined #zig
Ichorio has joined #zig
return0e has quit [Ping timeout: 245 seconds]
kristoff_it has quit [Ping timeout: 248 seconds]
marijnfs has joined #zig
NI33_ has joined #zig
ltriant has quit [Quit: leaving]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
ntgg has quit [Remote host closed the connection]
belse has joined #zig
hesamr has joined #zig
hesamr has quit [Remote host closed the connection]
<belse>
has someone an example of a build.zig files for a modularized hierarchic c lib?
<belse>
I wanted to play around with libagar but the makefile does not work for me so I thought it maybe easier to write a specific build.zig for playing around
<dimenus>
is anyone having trouble building zig in mingw64?
<dimenus>
linker complains about not being able to find a bunch of llvm libs
<dimenus>
even though they exist
<nrdmn>
which ones
<emekankurumeh[m]>
no?
<dimenus>
LLVMDebugInfoMSF/LLVMBitReader/LLVMCore
<dimenus>
etc
<dimenus>
they all exist in /mingw64/lib
<dimenus>
hmm
st4ll1 has joined #zig
<emekankurumeh[m]>
are you static linking or dynamic linking?
<dimenus>
i've tried both
<dimenus>
same problem
<dimenus>
it's like my path is hosed for some reason
<dimenus>
can you ls /mingw64 for me?
<emekankurumeh[m]>
so cmake is finding the libraries but, the linker can't
<dimenus>
correct
<emekankurumeh[m]>
hmm, I'm afk but I just have the base stuff if my mingw64 directory
<emekankurumeh[m]>
what linker are you using? gnu-ld
<emekankurumeh[m]>
it might be worth mentioning that I usually use lld
<mikdusan>
mq32: yes you're right there is ambiguity with undefined methods in my proposal
<mikdusan>
also a new type such as "interface" is very clear but am concerned it would lose the namespace ability of struct
<mq32>
yeah, that's what i though about, too
<mikdusan>
an alternative would be to remain struct but mark the special functions with a new keyword "method". i mused about this a bit:
<mikdusan>
if using 'method' kw, we could also drop `self: @This()` and make it implicit. only 1 issue would remain: constness of self.
<mikdusan>
i suppose this could handle it: `const format = method(out: *Stream) Error!void;` would be whatever default is. i suppose mutable.
<mikdusan>
and `const format = method const(out: *Stream) Error!void;` but that's a lot of const's
<mikdusan>
a complete flip on this could be; where we have `const format : fn(self: @This(), out: *Stream) Error!void = undefined;`
<mikdusan>
could become `const format : fn(self: @This(), out: *Stream) Error!void = abstract;` or somesuch.
<mq32>
oh man
<mq32>
having *any* syntax is easy, but having good, consistent syntax is damn hard
marijnfs has joined #zig
<mikdusan>
what if 'interface' was used... and it's simply a restricted-struct in two ways. 1. no fields. 2. fn with first arg @This() are semantics of a method.
batok has joined #zig
autodidaddict has joined #zig
<mq32>
i though something like this, yeah
<mq32>
but i don't like it, because it doesn't follow the "one obvious way" rule
<mikdusan>
true
<mikdusan>
premise that a new kw is required: here's just vanilla subst of 'fn' -> 'method' and what one would think it means at first impression:
<mikdusan>
1. `const format = method(self: @This(), out: *Stream) Error!void`
<fengb>
I'd be curious if we could make a semi-decentralized web of trust
<fengb>
I definitely feel like we should have strong "core" packages, but there should be major differences between defacto standards, decently maintained, and completely untrusted
<fengb>
AUR kinda just smoshes the last 3 together
<andrewrk>
non-statically-bounded stack allocation is unsound
<fgenesis>
solves the problem in a way i didn't even think of
<andrewrk>
it's basically the same thing as having an array on the stack
<andrewrk>
so do that instead of alloca
<fgenesis>
as in, u8 buf[9000] and go from there, i see
<andrewrk>
yes, and if you don't want to pay 9000 bytes of stack size, then don't put it on the stack. but the fact is that is how much stack you might use if that's your upper bound
<fgenesis>
i actually prefer using _malloca() and _freea(), even for C++ things, but sadly that's a MS extension. not too hard to implement portably tho
<fgenesis>
but then the whole global allocator nonsense starts again, so yes, the allocators look a lot cleaner :)
<andrewrk>
fgenesis, look at std.heap.stackFallback
<andrewrk>
looks like the uses of it got removed, but it puts an array of whatever (comptime) size you want on the stack and uses that for memory, falling back to a backup allocator
st4ll1 has quit [Ping timeout: 245 seconds]
st4ll1 has joined #zig
<autodidaddict>
My C skills are pretty rusty.. mostly on the build side. Is there a good book that will help refresh my memory of its foundations to help with my understanding of where Zig fits in this space?
<autodidaddict>
for example, my exposure to things like cmake is only involuntary when something I need requires me to use it
<andrewrk>
autodidaddict, I don't think you need a book to grok build systems. the idea is to avoid introducing an additional system dependency while providing a way for a project to have a build script
<autodidaddict>
I was watching your Lua video and I started having horrible flashbacks of events I thought I'd forgotten - hours/days spent twiddling .h files to make things work
<autodidaddict>
So I thought clearly this is some dark magic I've long since forgotten
firefox317 has quit [Remote host closed the connection]
<dimenus>
does zig emit CodeView or DWARF for mingw?
<dimenus>
CodeView I imagine?
vexu has joined #zig
<mq32>
andrewrk, are you going to stream later?
Akuli has joined #zig
DutchGh0st has joined #zig
<DutchGh0st>
I have a question about the reallocFn on the allocator defined in std.mem
<DutchGh0st>
When exactly should it return an error, and when exactly should it 1) alloc something new, and 2) realloc in place?
jjido has joined #zig
<fengb>
Whenever reallocFn cannot provide the space, it should return an error
<fengb>
Are you writing your own allocator?
wootehfoot has joined #zig
<DutchGh0st>
Yes
<DutchGh0st>
a stack allocator
batok has quit [Remote host closed the connection]
<DutchGh0st>
so it can basically shrink in place, but not grow in place
<fengb>
The error should happen if you can't allocate a block. This can be for any reason: max size, no contiguous memory, etc.
<DutchGh0st>
its literally the simplest thing ever
<DutchGh0st>
I dont even keep track of the free regions within the array
<fengb>
Hmm... that sounds like the FixedBufferAllocator
<fengb>
For in-place realloc, you can simply return the same base pointer address with the updated slice
<DutchGh0st>
if (new_size <= old_mem.len) { return old_mem[0..new_size]; }
<fengb>
"When the size/alignment is less than or equal to the previous allocation, this function returns `error.OutOfMemory` when the allocator decides the client would be better off keeping the extra alignment/size"
<DutchGh0st>
Well I donno, the client wanted to shrink, so they get a shrink
<fengb>
So you can either shrink in place or error out indicating the allocator doesn't really support shrinking
<DutchGh0st>
I mean its fine to say like "ohh first I have an allocation of a thousand bytes, and I realloc it to 900 bytes"
<fengb>
An explicit shrink calls the shrinkFn, which should never fail
<DutchGh0st>
so what should I do according to the docs of the function? error out?
<fengb>
Yeah, it's up to the caller to decide whether to do a shrink or realloc(smaller)
<DutchGh0st>
Honestly it would perhaps be simpler if it was just 3 function, alloc, realloc and shrink/free
<fengb>
It used to be
<DutchGh0st>
instead of realloc handling both new and realloc
DutchGh0st has quit [Remote host closed the connection]
<DutchGh0st>
instead of passing in a slice, it makes the buffer for you basically
<DutchGh0st>
I guess I could set it to undefined as well
andersfr has joined #zig
Akuli has quit [Quit: Leaving]
andersfr has quit [Remote host closed the connection]
andersfr has joined #zig
<fengb>
That looks fine. Looking at this, I wonder if FixedBufferAllocator should have this intrusive variant in std
<fengb>
I suppose it saves only 1 line of code so maybe not worth it
andersfr has quit [Ping timeout: 272 seconds]
<DutchGh0st>
Well Im annoyed by the fact that if I only want the allocator, I also have to create a buf in std's variant
<DutchGh0st>
while I can just say: yeahh whatever, give me an allocator that can fill 1024 bytes
<fengb>
Yeah I get it. I think this is the more "natural" way of using it but it's slightly less flexible
<fengb>
I don't think I've ever reused the buffer, but it's a possibility
<DutchGh0st>
fengb, would you say that std.ArrayList backed by a stack allocator, is actually an array with a dynamic interface (think like push and pop etc)
<DutchGh0st>
I think its cool you can just do that. In Rust for example there is std::vec::Vec, which is dynamic and uses heap allocation, and there is this crate called ArrayVec which provides the same functionality as a Vec, but uses a stack buffer. However, thats twice the code there
<fengb>
Yeah, I really love how explicit allocators enable better code
<fengb>
One thing I haven't toyed with is an ObjectPoolAllocator, but I imagine it'd be similar
<DutchGh0st>
the only thing is that a native ArrayVec doesnt need to call stuff like `realloc` because it already knows its size, while stack allocator + vec still calls the allocators realloc function once a while, doing copies that could be avoided
<fengb>
You might be able to get a bit complicated and support in-place enlarging
<DutchGh0st>
if you enlarge the last allocation its easy, just bump the cursor along
<DutchGh0st>
but how do you know its the last allocation? you could place like a u32 before each allocation, which would stand for some kind of generation key or something
<DutchGh0st>
and then also hold the current generation as a field in the allocation, and if they match its the last one, yeah
<DutchGh0st>
I guess the type holding the generation could varry, a stack allocator of only a thousand bytes can have a thousand generations, which fits in a u26
<DutchGh0st>
*u16
<DutchGh0st>
but then the buffer would become 1000 + 2000, because a thousand u16 is 2000 bytes
DutchGh0st has quit [Remote host closed the connection]
<fengb>
Hmm, I was thinking each data structure could have its own allocator, but I guess that's a limited assumption
autodidaddict has quit [Remote host closed the connection]
andersfr has joined #zig
vexu has quit [Quit: WeeChat 2.5]
andersfr has quit []
marijnfs_ has joined #zig
<dimenus>
how do i make a subslice of a bigger slice?
halosghost has quit [Quit: WeeChat 2.5]
<fengb>
biggerSlice[start..len]
<dimenus>
yeah idk why i was making it more complicated than it is
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
return0e_ has quit [Read error: Connection reset by peer]
return0e has joined #zig
dimenus has quit [Ping timeout: 248 seconds]
marijnfs_ has quit [Ping timeout: 264 seconds]
marijnfs_ has joined #zig
jjido has joined #zig
marijnfs_ has quit [Quit: WeeChat 2.4]
wootehfoot has quit [Read error: Connection reset by peer]
dimenus has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
dimenus has quit [Ping timeout: 245 seconds]
hio has quit [Quit: Connection closed for inactivity]
batok has joined #zig
<batok>
no streaming today?
<andrewrk>
I'm either going to do a late one or do it tomorrow, i'm on a roll with async functions and won't be stopped
<emekankurumeh[m]>
nice
dch_ has joined #zig
gonz__ has joined #zig
l1x_ has joined #zig
odc_ has joined #zig
st4ll1 has quit [Ping timeout: 258 seconds]
st4ll1 has joined #zig
dimenus has joined #zig
<dimenus>
is there a way to debug a library with gdb?
l1x has quit [*.net *.split]
dch has quit [*.net *.split]
gonz_ has quit [*.net *.split]
odc has quit [*.net *.split]
gonz__ is now known as gonz_
odc_ is now known as odc
dch_ is now known as dch
l1x_ is now known as l1x
ltriant has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]