ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<JinShil>
However, one thing that I couldn't find covered in the documentation was Zig's answer to code reuse.
<JinShil>
I like programming in D primarily because of its modeling, code reuse, and metaprogramming features (mixins and templates specifically)
<JinShil>
It probably the primariy reason I don't care for Rust.
<JinShil>
I like Zig's approach to simplicity, but how can we achieve great code reuse in Zig the way it can be achieved through inheritance, mixins, and templates in other languages.
<JinShil>
?
<andrewrk>
hi JinShil
<andrewrk>
it sounds like you're asking about language features rather than package managers
<JinShil>
Yes, I'm not looking for libraries if that's what you mean.
<andrewrk>
I'm not sure I understand the question
<JinShil>
I want to be able to easily mix in (for lack of a better word) features of one struct in another without having to rewrite functions and such to forward calls to an encapsulated struct.
<JinShil>
At tleast that's one use case.
<andrewrk>
oh I see. you're specifically asking about inheritance (or similar)
<JinShil>
Yeah, not specifically inheritance, but something that allows me to reuse code. Inheritance is just one feature. There are many others.
<JinShil>
Just one statement and you get all the fields, methods, etc... of the base, and you can even override some features of the base with the vtable implementation.
<alexnask>
right, you could do much of the same but I don't think there is any way to mixin additional bits of AST (at least yet)
<alexnask>
So that you can automatically generate the required methods and vtable bindings
<andrewrk>
so Missile gets the RigidBody functions?
<andrewrk>
and fields
<alexnask>
Actually, I think auto constructing the vtable may be possible but making the wrapper functions to call into it can't I thin
<andrewrk>
what's the difference between that and having rigid_body be a field of Missile?
<JinShil>
Yeah, right. It gets all the functionality of RigidBody, and the methods can even be overridden in Missile
<andrewrk>
ability to override stuff
<JinShil>
The difference is encapsulation (you don't have to expose the RigidBody as a field of Missile, and if you do choose to encapsulate RigidBody, you don't have to write all the methods that simply forward to RigidBodies members.
<JinShil>
I guess what would be nice is some way to do the following 3 things:
<JinShil>
1. Add Rigid Body as a child of Missile.
<andrewrk>
you wouldn't have to write all the methods if it was a field - you'd use a pointer to the rigid_body field where a RigidBody was required, and use @fieldParentPtr to get the Missile ptr from a RigidBody ptr
<JinShil>
2. Automatically expose all public methods of RigidBody in Missile
<JinShil>
3. Override methods of RigidBody in missile.
<andrewrk>
I won't close it until I've written a GUI in zig
<alexnask>
noice
<JinShil>
Yes, GUI would be a great use case.
<andrewrk>
fair warning though: my goal is to make a GUI without having to add a language feature, and then triumphantly close the issue
<andrewrk>
but I'll keep an open mind
<JinShil>
haha
<JinShil>
Ok, based on your answers, I'll assume that Zig doesn't have much more than what C provides for this use case. It appears others are trying to influence you with Rust's traits and Go's interfaces. Add me the queue with D's mixins :-)
<alexnask>
@andrewrk The PR now passes the tests btw
<MajorLag>
move.zig was inspired by a Java library, so it has tended towards an oop inheritence-hierarchy kind of structure. That is a bit painful to deal with in zig, but not quite as bad as I'd expected. One thing that has helped is leveraging comptime to create new derivations of a base type with minor changes automatically.
<alexnask>
@JinShil Reflection/reification of types is planned
<andrewrk>
JinShil, your synopsis is correct, and I have noted your queue position :)
<JinShil>
lol
<andrewrk>
MajorLag, I'm guessing @field would help?
<alexnask>
To build types with imperative code at compile time, this covers lots and lots of the mixin usecases
<andrewrk>
alexnask, yeah - @reflect and @reify are planned. That might actually make mixins possible in userland
<JinShil>
Hmm. Is the a proposal for those documented yet?
<alexnask>
Depends of if any declaration can be reified or types only, I don't think it's that clear in the issue
<MajorLag>
For isntance, where Scene2D has a group of Actions like "MoveBy", "MoveTo", "RotateBy", "Fade", etc, I have one implementation: "ChangeAction". ChangeAction is a comptime function that generates a new action type with a comptime parameter list of which variables the action will be changing.
<alexnask>
But if every declaration is possible, then it's as easy as parsing strings into an AST, mapping that into builtin structures and reifying
<alexnask>
And you basically have D mixins
<andrewrk>
in summary: @reflect(T) returns at comptime full information of type T, and @reify(T) is the inverse - it turns a description of a type into an actual type
<andrewrk>
MajorLag, oh right. I forgot you figured out how to do that. @field will also work for other kinds of field access though, in addition to struct fields
<andrewrk>
essentially it's the `a.b` syntax but the `b` is a comptime string
<MajorLag>
If you have `info`, wouldn't that already have the member counts and names in it? You could just do something like `for(info.members) | member | { if(mem.eql(u8, member.name, name) ...`
<alexnask>
@Dodo I don't think nested functions are supported, the usual workaround is to create an empty struct with your function and use it from there
<alexnask>
Like you could have const Iter = struct { fn filter(...) { ... } }; then use Iter.filter instead of filter
<alexnask>
You are also missing semicolons on your returns
<Dodo>
mhh
<Dodo>
._.
<Dodo>
its been a long time I've actually written 'return ....;'
<alexnask>
Also, why is your iterator of type "type"
<alexnask>
Yes I like the rust-style last expression is returned
<Dodo>
I dont know actually, I really dont know what a good way is to create an Iterator...
<alexnask>
I actually used to work on http://ooc-lang.org which did the same back in 2010/2011 :p
<alexnask>
Well, the "type" type is the type of... types :P
<alexnask>
You should probably take a "var" which basically means you accept any kind of argument since you don't know the exact type of your iterator
<alexnask>
Or you could make an Iterator(comptime T: type) type with a vtable, then use @fieldParentPtr for "subclasses" of the iterator
<Dodo>
one of my thoughts is to create a function called 'iter', that you can give anything that has a .next() method, and from there on you'd be able to chain
<alexnask>
let me find a good example of this pattern
<Dodo>
so you'd end up like 'iter(myitter).filter().map().take_while()' or something
<alexnask>
yes, you could do that but there are tradeoffs
<Dodo>
unless there's something like Interfaces that I don't know of yet?
<alexnask>
There aren't but there is a pretty standard pattern people use (it's all over the standard library, for example)
<alexnask>
I'll send you some link to std code and write a basic one for Iterators
<Dodo>
cool! :D
<alexnask>
Take a look at std/mem.zig for the "Interface" declaration and std/heap.zig for some implementations to get the basic idea
<alexnask>
Note that you must always take the iterator field by reference before using it, otherwise you will copy the iterator vtable but not the iterator state, if that makes sense
<alexnask>
I just added a Map iterator too for an example of something that is not that trivial
<Dodo>
ah yeah
<Dodo>
but it's a commonly used function of Iterators ^^
<alexnask>
Yes, just to show some metaprogramming techniques :0
<alexnask>
:) *
<alexnask>
I'm pretty sure I can make it just take a function and infer the types from there
<alexnask>
Let me try :P
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<Dodo>
this looks so much more..intimidating than I expected honestly
<alexnask>
It's kinda clunky because there is no interface type in zig, you have to make it yourself like you would in C.
<alexnask>
But it's a really useful pattern and if you get how it works it's pretty easy to implement/use.
<Dodo>
I've never really worked in C ^^
<alexnask>
I see
<alexnask>
Basically you make a vtable type by hand (In this example, Iterator(T))
<alexnask>
Then your implementations provide their functions and have a vtable field (the "it" field here) and fill it up with the function implementations
<alexnask>
And you use @fieldParentPtr to go from a vtable pointer to a pointer to the implementation
<Dodo>
In school we had a little bit of Java, then I quickly realized that I liked python more, and then someone from school told about Rust,,, and thats it
arBmind has quit [Ping timeout: 260 seconds]
<alexnask>
This is basically handmade traits, without language support
<Dodo>
yeahh
<alexnask>
Just ask away if you don't get some part of the code :)
<alexnask>
I'm pretty sure all that will be abstracted away once we have @reflect and @reify
<Dodo>
(btw, !sometype means 'error or sometype', right>)
<alexnask>
Yes
<Dodo>
wouldn't it be nicer to have an Iterator return ?sometype
<alexnask>
It's pretty much the same thing I think but I'm not too sure waht would happen if sometype is nullable itself
<Dodo>
well that would just nest nullables?...? I don't know?
<alexnask>
I used an error to make it clearer that nullables are allowed to be part of the iterator but you can try using a nullable for sure
<alexnask>
I updated the gist with a version of Map that takes a single function argument btw
<Dodo>
is there a nice loop, unwrap the nullable, but if its null then break
<alexnask>
You can do 'const val = it.next() ?? break;'
<Dodo>
*is there a nice way to loop...
<alexnask>
In a while(true) loop
<Dodo>
yay!
<alexnask>
I expect once there are some more metaprogramming features available much of this will be abstracted away
<Dodo>
allright, now Im going to try and make 'filter' work
<Dodo>
can I check at compiletime if the predicate (or function passed into filter) has a returntype of bool?
<alexnask>
Yes, take a look at the updated gist at Map
<alexnask>
It first checks you passed in a function
<alexnask>
Then, you can just use FunctionType.ReturnType to get a "type"
<alexnask>
So you can do FunctionType.ReturnType == bool
<alexnask>
(and @ArgType for argument types, .arg_count for argument count)
<alexnask>
Wierd, can you try changing line 16 to "fn filter(comptime predicate: var) type {" ?
<Dodo>
that seems to do it
<alexnask>
That's a confusing error message... Probably deserves a bug issue request
<alexnask>
Btw, your filter implementation has a bug ;)
<Dodo>
well, ofcourse it complained, I didn't provide a return type...
<Dodo>
oh no!
<alexnask>
Sure but it should tell you that
<alexnask>
Not that it expects a brace :p
<Dodo>
oh my predicate takes 'val' ?
<Dodo>
so I cant even return 'val' since I would've moved out of it?
<alexnask>
No, I don't think that's an issue
<alexnask>
I can give it away but I suggest you try it out on a couple of testcases :)
<Dodo>
for now Im getting another error :3
<Dodo>
main.zig:41:20: error: use of undeclared identifier 'InPutIt'
<Dodo>
or I cant even type...capitals
<alexnask>
InputIt != InputIt :D
<alexnask>
InPutIt** woops
<MajorLag>
FYI: you don't need to do `it.next() ?? break` in a while true loop, you can just use the while loop itself to unwrap: `while(it.next()) |*val| {}`
<alexnask>
Ah, true
<Dodo>
thats nicer indeed
<Dodo>
const T = @ArgType(FnType, 0); <--- @ArgType of 0 is mostly a reference, so that doesnt really help much here
steveno_ has joined #zig
<Dodo>
so if @ArgType(FnType, 0) is an &sometype, can I get the 'sometype' out of that ?
<alexnask>
T.ChildType == sometype
<alexnask>
or .Child, not 100% sure
<Dodo>
can you also check at compiletime that @ArgType(FnType, 0) is a reference to whatever?
<alexnask>
You should probably write some function UnwrapArg(comptime ArgType: type) type that checks to see if you have a pointer type (though typeids) and unwraps it
<alexnask>
You can use @typeId like I do to check wether the argument is a function
<Dodo>
expected type '&usize', found '&const usize <--- where is this &const popping up from?
<alexnask>
I assume the |val| capture defines val as const
<alexnask>
A quick workaround is using &const usize for your predicate
<alexnask>
Since It should not mutate the value anyways
<alexnask>
It's actually more correct, sadly there is currently no way to check if a Pointer type is const or non const to enforce it and give a clearer error message
<alexnask>
You're capturing by pointer and printing out the pointer ;)
<Dodo>
oh while consuming I still used the ptr
<Dodo>
but now if you wanted to go crazy and map, filter, and some other stuff on an Iterator.... you have to write quite some stuff, and you cant really chain
<alexnask>
var map_it = &Map(addOne).init(&Range(0, 10).init().it).it;
<alexnask>
etc.
<alexnask>
Not the prettiest, it works though ;)
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
davr0s has quit [Client Quit]
<alexnask>
Do I don't quite see what you mean
davr0s has joined #zig
davr0s has quit [Client Quit]
<Dodo>
well what would be nice to be able to write is like 'iterator.map(somefunc).filter(somepredicate).map(someotherfunc)'
<alexnask>
I updated my gist with Filter, Map, Range, Repeat, a reset feature and examples using integers and structs if anyone is interested btw
<Dodo>
now, that would kind of nest from the inside out
davr0s has joined #zig
<alexnask>
You can add those as functions to Iterator
davr0s has quit [Client Quit]
<alexnask>
And use the types you made
davr0s has joined #zig
davr0s has quit [Client Quit]
<Dodo>
on line 72, what is the type of val?
<alexnask>
should be &const T
<alexnask>
I pass it by value to the predicate and struct get upgraded to &const T automatically
<alexnask>
So it works for scalars and structs (with by value semantics for scalars, by reference for structs)
<Dodo>
huh woa'
<alexnask>
I'll write an example Iterator method to do chaining like yo udescribed ;)
<Dodo>
what about DoubleEnded Iterators? :P
<alexnask>
Well, you would write a new interface
<Dodo>
xD
<Dodo>
oh, one function that is nice to have too is zip!
<alexnask>
Hmm, the issue would be in your iterator type functions, they would need to retrn types that work with both the ForwardIterators and BidirectionalIterators
<alexnask>
Also, chaining is still ugly since you need to keep all of yor iterators on the stack, so yo can't jst initialize one and return a reference to the iterator vtable in a function
<alexnask>
But I'm sure there could be some workaround
<alexnask>
Perhaps with an inline function? Not sure what the behaviour is (if it will keep the stack variables of the inlines function or not)
<alexnask>
Probably not
hoppetosse has joined #zig
<Dodo>
if `iter_a` is an Iterator, can I write "const iter_a_type = @typeOf(iter_a.next());"
<Dodo>
or would that already call .next() ? :3
steveno_ has quit [Ping timeout: 255 seconds]
steveno_ has joined #zig
<MajorLag>
A thought: leverage comptime to create a pipeline instead of chaining itorator objects. `var result = pipeline(iterator, filterFn, mapFn, reduceFn);` pipeline would use inline while loops to pass the output of the iterator through the provided fns.
<MajorLag>
...I think the only problem with that is a few missing comptime features, like inferred return type and varargs
<alexnask>
@Dodo That should work withot calling it in runtime
<alexnask>
@MajorLag Yes it shold be doable as is, I was just wondering if I could make it work with the current thrown together design :p
<alexnask>
I tried fixing comptime varargs but the code is really confusing
<alexnask>
Since I'm not familiar with zig internals, I will get back to it at some point after I get more familiar by fixing other bugs and adding some features
<alexnask>
Inferred return types would be great too but most of the time you can just write a helper type function and then use @typeof(this).ReturnType in the function body.
<Dodo>
comptime is magic :3
<alexnask>
Running code at compile time is great, yes :) I especially like the zig way of treating everything as a value at compile time, soo powerful
<Dodo>
no tuples?
<MajorLag>
not yet
<Dodo>
mhh guess Ill make my own struct then for now
<alexnask>
We just need @reify for tuples, it can be written into the standard library
<alexnask>
Although andrewrk was considering removing varargs and adding tuples at a language level
<andrewrk>
I'm becoming more and more convinced this is a good idea
<andrewrk>
var args is buggy because it's not a simple concept
<alexnask>
Yes, it would remove a bunch of non trivial code for handling varargs from the compiler for sure
xkern has joined #zig
redj has joined #zig
davr0s has joined #zig
redj has quit [Ping timeout: 240 seconds]
redj has joined #zig
<Dodo>
const Tuple = struct { t1: item_a, t2: item_b, }; <--- printing this is weird
<MajorLag>
andrewrk: there's no timing functions hidden in std somewhere I'm not seeing are there? As in, getTicks or QueryPerofmanceCounter.
<andrewrk>
MajorLag, no, but an addition to add this would be most welcome
<andrewrk>
on linux it's clock_gettime, potentially with the vdso optimization
<MajorLag>
I was kinda hoping to avoid implementing it myself, but I'll take a look. As I recall, the vdso is mapped to a fixed location as an elf so right?
<andrewrk>
as a first pass you can do without vdso optimization
<MajorLag>
true, but I may as well see how much extra effort would be required for it while I'm at it
<Dodo>
error: expected type '&Iterator(usize)', found '&const Iterator(usize)'
<alexnask>
Does it work if you use a comptime block around all 3 variable declarations?
<alexnask>
Seems like the compiler thinks the Ranges are const
<Dodo>
mh nope, same error
<alexnask>
Btw the way you wrote Chain and Zip is fine but you don't get runtime polymorphism. I would suggest either having runtime polymorhpsim for all the iterator types or for none
<alexnask>
Let me try it out for 2 mins, I'll get back to you
<Dodo>
Im not sure I understand 'runtime polymorphism'? you mean that Zip/Chain now both only have a next method, and never say they are an Iterator(sometype)
<alexnask>
Indeed, that means you cannot write some function that takes an unknown type of iterator at runtime
<Dodo>
mhhhh okey, well, Ill add some kind of .it field then
<alexnask>
That is a design choice, you could just use generics and do everything at compile time and it will be (a bit) faster, you just lose the runtime polymorphism
<alexnask>
It's like using templates in C++ instead of virtual functions, if you've ever used C++ before.
<Dodo>
what would it be compared to Rust? trait objects?
<Dodo>
I basically dont know any C/C++ ^^
<alexnask>
Yes, rust trait objects appear to be some form of dynamic dispatch (aka runtime polymorphism)
<alexnask>
Basically, using a 'var' parameter everywhere will create a new function at compile time for each type used
<Dodo>
so how would I make Chain/Zip be able to virtually dispatch?
<alexnask>
While doing the whole Iterator vtable thing is like doing an impl of some trait in rust
<alexnask>
You would add an iterator field and initialize it like in Map etc.
<alexnask>
You can think of the Iterator struct as a rst trait
<alexnask>
And adding a field + initializing it is like implementing the trait for some type
<alexnask>
It's just a table of functions with the same type, rust just automatically gets the original self pointer for you while we do it manually with @fieldParentPtr
<Dodo>
I seemed to have crashed the .exe :O
<Dodo>
Need to look into this haha, this is not good!
<Dodo>
but for now there's dinner, bye!
Dodo has quit [Quit: Page closed]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<alexnask>
error: expected type '[]u8', found '[4]u8'
<alexnask>
Is this a bug or expected behavior?
<alexnask>
Ah, forgot a const somewhere
<andrewrk>
Dodo, gdb and valgrind are great tools for figuring out what's wrong
<alexnask>
@andrewrk Is there any way to get a listing of a struct's methods?
<alexnask>
I'm trying to make some automatic vtable system
<andrewrk>
I don't think that's currently possible. This would be exposed with @reflect
Dodo has joined #zig
Ichorio has joined #zig
<Dodo>
alexnask, is it true that if I dont put a '&' in front of the Iterator, the whole things blows up?
<alexnask>
Yes, you will copy the vtable's value so @fielParentPtr will fail
<alexnask>
I'm writing a small library for easier vtables, it uses a whole different design
<Dodo>
now it should work with virtual dispatch
<Dodo>
tho I'm not sure if I like things like '&Zip(usize, usize).init(filter, other).it;', I'd much rather write "&Zip().init(filter, other).it"
<Dodo>
but zip(usize, usize) is clear what it zips over...but for long nested types that gets verry annoying I think
<Dodo>
oh, .enumerate(), almost forgot :3
redj has quit [Read error: Connection reset by peer]
<alexnask>
With just @field (assuming it would work for methods too), something like: http://prntscr.com/j62vof would be possible
<alexnask>
Anyway, back to making crinkler work :P
<Dodo>
Crinkler?
<alexnask>
It's a "compressing linker" for Windows
<Dodo>
ahh ha
<alexnask>
Pretty much a linker + executable packer in one, I'm trying to make a simple 4KB demo
<alexnask>
(in zig)
xkern has quit [Ping timeout: 256 seconds]
<Dodo>
doesn't that involve crazy shenanigans?
<alexnask>
Yes, one of which is using clinker ;)
<alexnask>
Zig seems pretty suited since it comes with dead code elimination out of the gate and is low level
<Dodo>
yeahh
<alexnask>
+ all the comptime stuff will be useful too
<Dodo>
what about fields of a struct, will they get automatically be optimized in the right order?
<alexnask>
are you referring to packing or hot/cold data?
<Dodo>
I've seen that in C, if you mess up the order of your fields, your struct might become really big, while it really could be smaller if the order of the fields was switches a little
<alexnask>
Ah, yes you are talking about packing.
<alexnask>
There is a 'packed' keyword for structs that will pack them as tightly as possible
<Dodo>
I wonder how that's done in Zig, does that happen automatically"? or do you need to do it manually
<Dodo>
ohh
<alexnask>
Or rather, it will preserver the field order and byte sizes
<Dodo>
because if you have a fully generic struct, that's nice to have I guess
steveno_ has quit [Quit: Leaving]
<alexnask>
It's mostly for interacting with other systems
<alexnask>
For example, some file format header
<alexnask>
Can be represented with a C struct, and if you do it right and you tell your compiler to pack it you can just cast a chunk of memory into that struct
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<andrewrk>
Dodo, zig provides no guarantee about order of fields in a struct (unles you use packed or extern) so that we can optimize the layout
<andrewrk>
however no layout optimization is currently done
<andrewrk>
alexnask, the 4k restriction is about executable code size rather than runtime memory size, right?
<andrewrk>
I believe that packed structs could potentially cause larger binaries, since their fields will be unaligned, and therefore bit-shifting instructions may be required to access fields
<andrewrk>
Dodo, taking a struct by const ptr and immediately copying it is equivalent to taking a struct by value
<Dodo>
but my Iterator returns me owned items ;o
<Dodo>
or hang on
<alexnask>
@andrewrk The 4KB restriction is on the executable yes
<alexnask>
And you can only link against default windows libraries (+ opengl or directx)
isd has joined #zig
<alexnask>
@andrewrk Can I completely remove the panic handler?
Dodo has quit [Quit: Page closed]
<andrewrk>
alexnask, it should go away when compiled with --release-small
<andrewrk>
assuming you never call @panic()
<alexnask>
Ok, good, I'll check it out to be sure.
<alexnask>
Btw, with build-obj I assume the compiler_rt and builtin object files are included in the produced output?
<andrewrk>
alexnask, this doesn't work now, but when I do some reorganization, you'll be able to have your panic handler have a body of @compileError("panic called") and you'll get a compile error everywhere a panic is possible
<andrewrk>
this would be insanity to do in debug mode, but could make sense to do in release-small or release-fast mode
<alexnask>
It's probably clinker's fault, I may try to link against some older SDK
<andrewrk>
alexnask, did you use the zig-generated kernel32.lib or the msvc-provided one?
<alexnask>
I use the msvc one, I though zig just copied it over
<andrewrk>
you also need libc or zig's generated builtin.o
<alexnask>
Ah ok, compiler_rt.obj too I assume?
<andrewrk>
zig is actually generating minimal .lib files with only the entries that you actually call
<andrewrk>
this lets us produce windows .exe files on other platforms
<alexnask>
Nice, I'll try using the zig-cache ones then
<andrewrk>
yes compiler_rt.obj is also required in the same way builtin.obj is. it's possible that you don't end up needing them, in which case the unused symbols would be omitted once https://github.com/zig-lang/zig/issues/54 is solved
<andrewrk>
you can work around it by putting the .o files in .a files first
<andrewrk>
oh, actually I don't know how it works on windows
<alexnask>
Right, now I remember why I didnt use the zig-cache kernel32.lib, crinkler doesn't appear to handle ar archives well
<alexnask>
Anyways, thanks for the help I'll try out a couple of things
<andrewrk>
kernel32.lib is an ar archive?
<alexnask>
file says so
<alexnask>
kernel32.lib: current ar archive
<andrewrk>
hm. odd. that's generated by LLD from a .def file
<alexnask>
I could try using link.exe to generate it and give it a shot
<alexnask>
LLD may just not care and use ar archives
<andrewrk>
it's not the underscores is it?
<andrewrk>
is zig messing up the underscores of the kernel32 fn names?
<alexnask>
Are there supposed to be underscores? I don't see how lld and link.exe would accept them
<alexnask>
If it was wrong, I mean
<andrewrk>
I mean it's just part of the name. so if there was a mismatch you would get undefined symbol errors, just like you are now
<andrewrk>
that's what dllimport and dllexport do, just mangle the names of things
<alexnask>
Ah ok I though C symbols had no name mangling
<andrewrk>
sadly on windows DLLs they do
<alexnask>
That's why the underscores surprised me
<andrewrk>
I remember I tried to solve this correctly a few months ago, and I thought that I had succeeded, but unfortunately I don't remember all the details
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
hopppetosse has joined #zig
hoppetosse has quit [Ping timeout: 256 seconds]
isd has joined #zig
<MajorLag>
so um... zig seems unable to find the vcruntime path even though I'm passing it the absolute path via --msvc-lib-dir
<alexnask>
Nice managed to get it down to just undefined '__imp__LoadLibraryA@4'
<andrewrk>
MajorLag, it's probably looking for a specific file
<alexnask>
Which is weird since it's in kernel32 but doesn't appear to be in the def file
<andrewrk>
alexnask, the zig generated one?
<MajorLag>
andrewrk: here's the thing, backreving to 0.2.0.9df2a6a5 works fine
<alexnask>
@andrewrk Yup
<alexnask>
actually, let me make sure
<alexnask>
But I don't think building the .lib overrids the .def
<andrewrk>
does the .def have it in there?
<alexnask>
Nope
<alexnask>
ExitProcess
<alexnask>
, HeapCreate,
<alexnask>
WriteFile
<alexnask>
GetLastError,
<alexnask>
, GetStdHandle,
<alexnask>
HeapAlloc,
<alexnask>
HeapReAlloc,
<alexnask>
HeapFree,
<alexnask>
GetConsoleMode,
<alexnask>
GetFileInformationByHandleEx
<MajorLag>
andrewrk: actually... old version fails too, it just doesn't report it except as an exit code...
<alexnask>
woops
<MajorLag>
which is weird, I know this was working yesterday because I was using c_allocator
<alexnask>
Huh
<alexnask>
Managed to link by using lib.exe to generate kernel32.lib then link against that library + the system kernel32.lib
<alexnask>
Which is weird, if I only link against the system kernel32.lib I get undefined references :p
<alexnask>
2.278 bytes with 10 calls to std.debug.warn
<alexnask>
Not bad
<alexnask>
1.5KB for the whole demo code and data... sounds good :P /s
jjido has joined #zig
<alexnask>
Windows .lib files are ar archives after all btw, not quite sure why it's not working with the lld generated lib
hopppetosse has quit [Ping timeout: 256 seconds]
jjido has quit [Ping timeout: 265 seconds]
<MajorLag>
andrewrk: using process monitor, it doesn't look like zig is respecting my commandline passed paths.
<MajorLag>
as in, it doesn't even appear to attempt to look for them.
<alexnask>
@MajorLag Did 'zig build' break for you too on windows in one of the latest releases?
<alexnask>
It appears to run into an unreachable while running the build executable on my machine
<MajorLag>
yeah, not sure which one. The older version I thought worked actually doesn't, but because of how it errored that wasn't obvious to me yesterday.
<MajorLag>
but my problem is different than yours, zig ignores the paths I'm passing it to the runtime and kernel32.lib
<alexnask>
I'll try it out too in a couple of minutes so we can see if it reproducible