ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
hasen_judy has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<GitHub179>
zig/master dfbb825 Andrew Kelley: fix self hosted tokenizer handling of EOF
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
Hejsil has joined #zig
Tobba has quit [Ping timeout: 256 seconds]
Hejsil has quit [Client Quit]
arBmind has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
cenomla has quit [Quit: cenomla]
arBmind has quit [Quit: Leaving.]
<vegard>
-- Could NOT find CLANG (missing: CLANG_LIBRARIES CLANG_INCLUDE_DIRS)
<vegard>
oops. I get that ^ when I run the cmake command from the readme
<vegard>
I have installed clang and libclang-dev
lqd has quit []
lqd has joined #zig
<vegard>
alright, looks like I needed llvm-5.0 and clang-5.0 on ubuntu
<vegard>
/home/vegard/git/zig/deps/lld/lib/ReaderWriter/MachO/MachONormalizedFileToAtoms.cpp: In function ‘llvm::Error lld::mach_o::{anonymous}::processSection(lld::DefinedAtom::ContentType, const lld::mach_o::normalized::Section&, bool, const lld::mach_o::normalized::NormalizedFile&, lld::mach_o::MachOFile&, bool, bool)’:
<vegard>
/home/vegard/git/zig/deps/lld/lib/ReaderWriter/MachO/MachONormalizedFileToAtoms.cpp:487:21: error: ‘size’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
<vegard>
offset += size;
monteslu has quit []
monteslu has joined #zig
hoppetosse has joined #zig
<vegard>
there's a few more, gonna pass -Wno-error=maybe-uninitialized in CXXFLAGS for now
<vegard>
and -Wno-error=strict-aliasing ...
<vegard>
it works.
Hejsil has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<MajorLag_>
So about that deref operator. `$` isn't unprecedented and is apparently not a big deal to type on international keyboards. It is however ugly.
<andrewrk>
unreachable.zig:1:1: error: expected variable declaration or function, found Invalid
<vegard>
oh, okay.
<andrewrk>
it still can be fixed, just low on my priority list :)
<andrewrk>
MajorLag_, things like the argument to libc `puts` should be `[*]null const u8` instead of `?[*] const u8` is one reason that we have @import("std").c
<andrewrk>
I think it would make sense to just put all the libc prototypes in there, to get the better APIs
<andrewrk>
plus, we're going to need that anyway for zig's libc implementation
<andrewrk>
once we have our own libc we're going to rock the cross compilation world
<MajorLag_>
I don't do a lot of cross compilation, so I guess I don't follow?
davr0s has joined #zig
hoppetosse has quit [Ping timeout: 256 seconds]
<andrewrk>
say you're making a game, and you want it to work on linux and windows
<andrewrk>
and it depends on zlib and libpng
<andrewrk>
once we have our own libc, you'll be able to actually build zlib and libpng, with zig, for both targets, no matter which target you're developing on
<andrewrk>
`zig build` in your game's repo will be able to do everything
<andrewrk>
zig libraries will be able to depend on c libraries, without a dependency on a system C compiler
<andrewrk>
the less things you require people to manually install, the more useful zig libraries can be
<MajorLag_>
So the Zig libc implementation would literally replace libc. So would libpng/zlib object files be lniked against Zig-libc and my code, or would libpng/zlib get built using translate-c and the Zig-libc?
<andrewrk>
if you opted into this, libpng/zlib would be linked against zig-libc, and your code linked against zig-libc as well
<andrewrk>
but then implementations would ultimately be the same, e.g. if you used the libc allocator, or if you used the zig default general purpose allocator, it would be the same thing
<MajorLag_>
But I still would have no requirement for a C environment, which is wicked cool.
<andrewrk>
yeah that's the idea
<andrewrk>
the implementation would be mostly a port of musl
<andrewrk>
which is what we've already done for e.g. std.math
<andrewrk>
and musl is gaining popularity recently with docker and alpine linux
<andrewrk>
so we'd actually have pretty decent compatibility with popular libraries
<Hejsil>
Hit that on a refactor of some code. Good thing it wasn't to hard to find, as I was aware I needed to change the function signatures
<andrewrk>
yeah I'm really sorry that is quite a nasty bug
tridactyla has quit [Remote host closed the connection]
<MajorLag_>
Oh neat, you can use comptime type creation to instead create a namespace. For example, to only write a bunch of math functions once and create f32 and f64 versions.
hopppetosse has joined #zig
<andrewrk>
yep. you can also accept f32 or f64 as a comptime parameter
<andrewrk>
I guess you already knew that and prefer the namespace way of organizing. that's neat, I hadn't thought of that
tridactyla has joined #zig
hoppetosse has quit [Ping timeout: 256 seconds]
Hejsil has quit [Read error: Connection reset by peer]
dd3 has joined #zig
clownpriest has quit [Ping timeout: 256 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
hopppetosse has quit [Ping timeout: 240 seconds]
hopppetosse has joined #zig
<MajorLag_>
yeah, but if I wrote it like: lerp(comptime T: type, s: T, e: T, x: T) T then I would always have to pass the type in when calling it.
<MajorLag_>
this way I can just import it: const interpolate = @import("interpolate.zig").Create(f32);
<andrewrk>
yeah that's pretty nifty
<MajorLag_>
then I can call any interpolation in the library with the specified type.
<MajorLag_>
I don't know if you caught Jon's library stream, but he was talking about a similar concept for Jai. Zig already has it, it turns out.
<andrewrk>
I didn't catch it
<andrewrk>
any other interesting nuggets?
aiwakura has quit [Ping timeout: 260 seconds]
<MajorLag_>
It was a while ago. Um... He talked about different ways they might do things like add a type to "Print", you know, register handlers for things at comptime. I'm sure I'm forgetting a lot.
hasen_judy has joined #zig
dd3 has quit [Ping timeout: 240 seconds]
<andrewrk>
ah I've thought about that
<MajorLag_>
I can think of a way to accomplish it in Zig today, I think.
<MajorLag_>
Taking fmt as an example, you'd have it first see if the type was a struct and contained a function with the right signature (or name), then call that with the flags between "{}"
<MajorLag_>
If it didn't, fallback to normal behavior
<andrewrk>
that's a nice idea
<andrewrk>
one crazy thing I just thought of, format could take a namespace (@import) as a special arg, e.g. "{@}" and that arg isn't printed, instead it's expected to have a comptime function that can override printing for different types
<andrewrk>
and then in that format, after that arg, it checks that comptime function first to see if it has an override
<andrewrk>
so you could even kinda change the default printing for ints and non-structs using this strategy
<MajorLag_>
Yeah, that seems totally doable.
<andrewrk>
a comptime string arg such as the format arg is really a Domain Specific Language
<andrewrk>
you can pretty much do anything as long as it doesn't call external functions or os api
<MajorLag_>
Behind the scenes, is there any difference between a struct and a namespace? Are structs a superset of namespace?
<andrewrk>
they're implemented differently, but in practice an empty struct is the same thing as a namespace
<MajorLag_>
the Create() I mentioned above is implemented as returning an "empty" struct full of function pointers. I use them pretty interchangeably.
<MajorLag_>
er, not pointers
<MajorLag_>
specifically not pointers
<MajorLag_>
I could even extend it to do some basic reflection on struct types and make educated guesses as to what the importer wanted. Like, it's a struct full of f32 members, or an array of such, so it is probably a vector. That's overengineering though.
<MajorLag_>
Or I could get really crazy: const interpolate = @import("interpolate.zig").Create(ComplexStruct, "memberName", "member2Name", "member3Name"); specifying which members to perform interpolation on for that type.
<andrewrk>
MajorLag_, this is why I think we don't need macros
<MajorLag_>
I would have to agree. There's very little I think I couldn't do with comptime. There are probably a lot of language features that could be implemented in "std" if one were inclined.
<MajorLag_>
Did you add the ability to call nakedcc if they're (void)void? if so I might take another crack at computed jumps.
<MajorLag_>
it occurs I could have also used inline maybe.
<andrewrk>
I don't remember. I'll have to get back to you on that, I'm about to be busy for the evening