ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<andrewrk>
achambe, there's a cost for unused imports if you use the `use` keyword
<andrewrk>
which is one reason that it is discouraged
<andrewrk>
(although there are appropriate times to use it)
<alexnask>
Hmm I'm having trouble with Fn TypeInfos
<alexnask>
I'd like to generate the original info, before all generic parameters get type erased etc.
<alexnask>
Idk if type erased is the right terminology
<alexnask>
I'm guessing I could generate it if I got the FnTableEntry
<alexnask>
But that's not possible since I'm operating on types, hmm
adsr has left #zig ["WeeChat 2.0"]
<andrewrk>
you only have information up to the first generic parameter
<alexnask>
Right
<alexnask>
I'll be able to output correct information for function decls (methods + in namespaces) though
<alexnask>
So that's good :p
<alexnask>
Only definition info left (+ Namespace info which is basically just definition info)
<alexnask>
And tests + docs
isd has quit [Ping timeout: 240 seconds]
isd has joined #zig
isd has quit [Quit: Leaving.]
relatingdata has joined #zig
alexnask_ has joined #zig
relatingdata has quit [Quit: Page closed]
alexnask has quit [Ping timeout: 240 seconds]
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Dodo>
'cuz when I initialize an 'ExactChunks' Iterator within the 'DoubleChunks' Iterator, the slicelength and chunk_size printen are correct, however in the first .next() call,
<alexnask>
basically he adds some magic number to all implementations
<alexnask>
And checks for it when getting the self pointer from the interface
<Dodo>
so if I say that self.head is 'Iterator(T)', and then write '&self.head.next() ?? return null;' , it should also work?
<alexnask>
No, you always need to keep the implementation struct on the stack if you are going to use it later
<alexnask>
If you only keep the Interface(T)
<alexnask>
You will basically copy the function pointers
<Dodo>
mhh
<alexnask>
But when calling them they assume that the whole object is alive
<alexnask>
@fieldParentPtr
<alexnask>
Looks at the offset of the field in the struct
<alexnask>
And gets you back a pointer to the whole struct based on that offset
<alexnask>
So if you've only copied the .it field, it will return garbage
<Dodo>
pfwhoa
<Dodo>
so I applied the correct fix ... mhh
<Dodo>
good to know
<alexnask>
If you want to be able to only keep the Iterator(T)
<alexnask>
Then the Iterator(T) should own the memory of the implementation object
<alexnask>
As well as the function pointers to the implementation's functions
<alexnask>
For example Iterator(T) could have 16 bytes or so of data to store the implementations
<alexnask>
I'll make a gist for you on how it's done later if you're interested
<alexnask>
I have to run atm
<Dodo>
oh yeah, I'd like to!
<Dodo>
no problem haha, I'll be around the whole day I think, otherwise tomorrow afternoon
<alexnask>
It's basically the same idea I showed you with the vtable metaprogramming stuff but I'll make it more focused, not so generic :P
<alexnask>
All right, see you later then :
<alexnask>
:)
<Dodo>
byyee!
<alexnask>
(You can use any allocation strategy you want but storing the object inline is the most convenient most of the time)
<MajorLag>
@alexnask: unfortunately the "guard field" pattern I was using didn't really help that much, due to how the stack behaves in reality. Half the time code that should have crashed would work because the guard value just happend to still be within valid memory somehow, until you switched siwtched compile modes, OSs, or otherwise changed enough stuff to make the stack behave differently. andrewrk and I talked about a runtime check that could c
<MajorLag>
ver cases like this by checking at return if you were returning a pointer to an address an a stack frame that's about to die, but I'm not sure how plausible it is.
steveno_ has joined #zig
<Dodo>
if I take a function with 1 argument: 'bytes: []u8', can I say: 'bytes = bytes[4..]' ?
<Dodo>
because I get ' error: cannot assign to constant'
<Hejsil>
Arguments are const
<Hejsil>
fn a(b: usize) void. Here b is declared as const b = ...
Woj has joined #zig
Hejsil has quit [Ping timeout: 260 seconds]
Woj has quit [Client Quit]
SwickRotation has joined #zig
SwickRotation has left #zig ["Leaving"]
<Dodo>
how can I make them non const?
<Dodo>
it would be nice to be able to do such a thing
<Dodo>
now it's 4 times the same,... verry explicit
<Dodo>
I mean, I could make a helper function that returns !usize, depending if the digit was larger than 10 or whatever, and have atoi() return that error,
<Dodo>
but that would involve more checks, right? 'cuz then atoi() has to check if it got back an error or a usize,...
Dodo has quit [Quit: Page closed]
alexnask_ has joined #zig
<alexnask_>
Dod did you see the gist i shared btw?
<alexnask_>
Dodo*
noonien has joined #zig
Dodo has joined #zig
<alexnask_>
Dodo did you look at the gist i posted?
<alexnask_>
Its an alternate iterator interface implementation
<Dodo>
would that mean you could say something like "Range(0, 10).enumerate().take(10).map(//somefunc)" ?
<Dodo>
but...the struct you'd like to implement Iterator for, has to be smaller than or equal to 16 bytes?
<alexnask_>
Yes
<alexnask_>
You could heap allocate the object if it doesnt fit
<alexnask_>
Essentially a small buffer optomozation
<Dodo>
can't you pass in the size of the struct so its always stack allocated?
<Dodo>
and have `mem` be the size?
<alexnask_>
This would require a new iterator type for each type size
<alexnask_>
So a new interface
<alexnask_>
Otherwise you can heap allocate
<alexnask_>
But keeping a buffer around for small objects still would be good
<Dodo>
yeahh
jjido has joined #zig
<Dodo>
I'll try and update the current version tomorrow :)
Dodo has quit [Quit: Page closed]
alexnask_ has quit [Ping timeout: 240 seconds]
Aequus has joined #zig
return0e_ has quit []
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<alexnask>
@Dodo check out the updated gist when you can, it implementes a SBO that holds the heap and allocator pointers when the object is too big to fit in the inline buffer
<alexnask>
You need at least 17 bytes on x64 though (2 pointers + 1 flag byte)