ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
noonien has quit [Quit: Connection closed for inactivity]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
isd has joined #zig
isd has quit [Quit: Leaving.]
SimonNa has quit [Ping timeout: 255 seconds]
SimonNa has joined #zig
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<alexnask>
Iterator(T) (our interface type) holds an implementation object either in an inplace small buffer or on the heap (in which case the buffer is used to hold the heap + alloc pointers)
<Hejsil>
You could probably generate most of that once you have @reify and @reflect
<Hejsil>
Which is exiting
<Hejsil>
exciting*
<Hejsil>
A none owning interface would be a lot simpler to implement though (all interfaces in std are none owning)
<alexnask>
I know
<alexnask>
I actually have some code that does that
<alexnask>
Well, theoretical code
<alexnask>
Btw, @reflect (which I decided to call @typeInfo) is nearly done
<alexnask>
Only function def info is left
<Hejsil>
I have code (that crash the compiler) that does it too :)
<Hejsil>
Uuuh
<Hejsil>
Hype
<alexnask>
I'm going to start work on @reify (perhaps @renderType, I'd like your opinion on the name) after that
<alexnask>
I want to make it explicit you can only reflect/reify types so @typeInfo/@renderType sound good to me, what do you think?
<Hejsil>
I like @typeInfo, but @renderType i'm not sure
<Hejsil>
When I think render, I think, output assembly, video rendering, pretty printers
<alexnask>
Right
<Hejsil>
But I guess it is a kind of code generation
<Hejsil>
So idk
<Hejsil>
@createType ?
<alexnask>
@mixinType, @generateType could be other option
<alexnask>
options*
<alexnask>
or @createType, yes
<Hejsil>
The name shouldn't stop you from implementing it though :)
<Hejsil>
I'm sure, if something half decent is chosen, people will accept it
<alexnask>
I'm sure @reify will be a alot more involved though
<Hejsil>
Probably
<Hejsil>
I wish you all the best of luck
<alexnask>
Thanks
<alexnask>
The only part that kind of bums me out is that we will not be able to generate methods
<Hejsil>
Hmm
<alexnask>
That would involve a full blown mixin-like construct like Dlang (to get from AST to function definition body)
<Hejsil>
Types have some storage data (fields) and global data (const vars and fn). Is it not possible to add a fn to the global data of the type an then generate it?
<Hejsil>
typeinfo.functions.add(some_function)?
<alexnask>
Sure but I don't think this will actually work for more than non-trivial methods
<alexnask>
Idk I'll see what I can do when writing it
<alexnask>
I mean it could be semi/useful if you could bind generic functions and instanciate them somehow
<Hejsil>
I mean. Generating code inside the method can be done with inline loops @field and all that stuff on the Type/Parameter
<alexnask>
Right
<Hejsil>
Anyways, we'll see how that all goes
<Hejsil>
I have no idea of the backend of types in zig
<alexnask>
I guess if the FnDef has a func_type + a function pointer
<Hejsil>
You probably know better that I
<alexnask>
The issue is that if you want your method to have a &Self parameter
<alexnask>
Self is not an actual type yet
<Hejsil>
Oooh right
<Hejsil>
Hmmm
<Hejsil>
That's a hard one
<alexnask>
If you need methods that don't rely on types that are yet to be generated
<alexnask>
Then you could do it, even instanciate a generic function with the type of args you need I think.
<Hejsil>
Is fn def a struct like this: struct { args: []type, arg_names: []const u8, return: type, } ?
<Hejsil>
Or something simular
<alexnask>
It's the only part left but something similar, yes
<Hejsil>
Hmm.
<alexnask>
or rather FnDef = struct { calling_convention etc., args: ArgDef[] }
<alexnask>
ArgDef = { name, type, etc. }
<Hejsil>
Right, my point was that it is `type` and not `TypeInfo` that is stored
<alexnask>
Right, I started with "deep" TypeInfo's
<Hejsil>
Or whatever the @typeInfo returns
<alexnask>
But we agreed with andrew "shallow" typeinfos are better
<alexnask>
So, type's, yup.
<Hejsil>
They probably are, but I could see method generation maybe working if it was deep TypeInfo's
<Hejsil>
But there are probably problems with this
<alexnask>
Deep typeinfos would actually make that possible, you could just point it to the root typeinfo
<alexnask>
Hmm
<Hejsil>
What was the reasoning for shallow?
<alexnask>
Easier to generate, you can cache them (with deep typeinfo there is some non-trivial reasons that make caching more involved), you can just get child info with @typeInfo again
<alexnask>
I didn't think about the methods at the time
<Hejsil>
I see
<Hejsil>
Caching is a good reason
<alexnask>
The code is also much less error prone (I was doing some pretty funky stuff to avoid infinite loops while generating typeinfo's)
<alexnask>
Anyways, I still thionk it's up to debate since this usecase is pretty good, we
<alexnask>
we'll have to see with @andrewrk*
<Hejsil>
Right
<Hejsil>
Methods are important, so it's worth thinking about
<alexnask>
Well I could do something funky like using @typeOf(undefined) to represent Self in argument types but it seems like too much magic :p
<Hejsil>
Could we use `this`?
<alexnask>
'this' always refers to the parent scope right?
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
<alexnask>
@Dodo Alexnadros Naskos
<alexnask>
:D
<Dodo>
okey!
<alexnask>
Alexandros*
<Dodo>
oh hahaha, that'll be pushed in the next push
<alexnask>
I updated the gist with a heap + SBO optimization for the interface btw :)
<alexnask>
And plenty of comments + a couple of examples
<Dodo>
look at the new branch I created xD
<Dodo>
already bussy working on it ^^
<alexnask>
Nice!
<alexnask>
Hit me up if you run into any issues, I haven't tested much though it seems solid
<Dodo>
the few tests so far have not blown up
<Dodo>
soo all going well haha
<alexnask>
I'm just a touch concerned with the comptime vtable generation, I'm not sure if the compiler is smart enough to cache the vtable for an implementation type
<alexnask>
Or if it will create multiple vtables for each use
<alexnask>
I'll check it out
<alexnask>
But at worst I think an intermediate function that just calls IteratorVTable(T).init(ImplType) will be enough to force caching
<alexnask>
But at worst I think an intermediate function that just calls IteratorVTable(T).init(ImplType) will be enough to force caching
<alexnask>
I should probably enable them for my fork too
<Dodo>
there is actually quite some stuff I got to change now hahaha
<Dodo>
which means there's quite some functions already :)
<alexnask>
Yes, I saw there's a lot of stuff in there :)
<Dodo>
I hope I can make it work before dinner
<alexnask>
@Dodo Actually Once fails in comptime on my branch too, I'll take a look after I'm done with @typeInfo
<alexnask>
It doesn't even fail with an error message, it just crashes the compiler :p
<alexnask>
I enabled travis CI and appveyor builds for my fork btw, if anyone wants to play with @typeInfo I'm @alexnask on github and the branch is reflect_reify
<alexnask>
(Or you can find them in PR#951)
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<Dodo>
it crashes the compiler :O
<Dodo>
sounds good xD
<alexnask>
Meh that happens :p
<alexnask>
The compiler is just a program after all ;)
<alexnask>
I've crashed clang lots of times too :P
<alexnask>
Right, so Flatten needs to be heap allocated
<alexnask>
I think, I don't think you can ever make it fit into the small buffer
davr0s has joined #zig
davr0s has quit [Client Quit]
<alexnask>
@Dodo It's pretty trivial, just pass in a &mem.Allocator into your Flatten.init_iter and then pass it trhough to Iterator(T).init
<alexnask>
But you'll have to .deinit your Flatten iterators
<Dodo>
defer flatten.deinit
<Dodo>
right?
<alexnask>
yup (+ a parentheses pair obviously)
<Dodo>
mh, but `frontiter: ?Iter`, can just be 'frontiter: ?&Iter`, but malloc the Iter, and overwrite it each time?
<Dodo>
still need to have deinit to clean up, but well
<alexnask>
Yes, you could handle the allocation in Flatten for sure
<Dodo>
what would be better to do?\
<alexnask>
Hmm
<alexnask>
Well imho you should let Iterator handle the allocation, since it's not strictly necessary for Flatten
<alexnask>
Flatten can work without an allocation
<alexnask>
It's just that if you need it as an Iterator, since Iterator owns the memory if needs to be pushed onto the heap
<Dodo>
so it should only have a .next() method,
<Dodo>
and something to set it up obviously
<alexnask>
Right, any struct with a next(&Self) ?T is compatible with Iterator(T)
<alexnask>
Iterator(T) just handles the vtable stuff + holds the memory
<alexnask>
You could set up Iterator(T) to just point to the iterator implementation instead of owning it but that makes stuff even harder to keep track of imo
<alexnask>
You don't even need an init method that returns an Iterator(T)
<alexnask>
I just wrote it for convenience
<alexnask>
Iterator(T).init(alloc, some_object) will work as long as @typeOf(some_object) has a next(&Self) ?T method
<alexnask>
(which means people could use Zigterator with types made in other packages)
<Dodo>
with some more magic you could turn the arraylist into an array as well, and you can collect any comptime known Iterator into an array \o/
<alexnask>
hmm
<alexnask>
Not sure if ArrayList works at comptime
<alexnask>
Actually I think anything that uses an allocator won't work
<alexnask>
Not 100% on that though
<Dodo>
could create a function that collects into an array, all that's needed is the type, and the length
<alexnask>
It may be th @ptrCast that doesn't work, which may also be the cause of Iterator's not working at comptime atm.
<Dodo>
actually I only need a length...I already know the type !
<alexnask>
It should work in theory (although it's pretty complex to implement in the IR evaluation)
<alexnask>
Right, you can pass a slice to write in and return an error if the slice is not big enough
<alexnask>
Or something similar
<Dodo>
collect_array and collect_slice it is
<alexnask>
@Hejsil Users/travis/build/zig-lang/zig/src/ir.cpp:18733:21: error: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat]
<alexnask>
arg_index, buf_ptr(&fn_type->name)));
<alexnask>
is the error on the MacOS build
<Dodo>
which reminds me, .count() is also a usefull method. That consumes an Iterator, returning how many items it contained
<alexnask>
Alathough that's on my branch so the line number is probably incorrect