ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
_whitelogger has joined #zig
scientes has left #zig ["Leaving"]
scientes has joined #zig
darithorn has quit []
davr0s has joined #zig
<meowray>
I remember there is a gcc/llvm ABI incompatibility in 7.0.0 with ADT/Optional.h
<meowray>
-DLLVM_ENABLE_RTTI is also a thing
wilsonk has quit [Read error: Connection reset by peer]
wilsonk has joined #zig
unique_id has joined #zig
<unique_id>
I love how easy it is to create multiple executables from the same project. So I can have singleplayer, client, and server projects within the same codebase with no file tracking needed.
_whitelogger has joined #zig
very-mediocre has joined #zig
davr0s has joined #zig
allan0 has quit [Ping timeout: 252 seconds]
very-mediocre has quit [Ping timeout: 256 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
unique_id has left #zig ["Konversation terminated!"]
ManDeJan has joined #zig
allan0 has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
very-mediocre has joined #zig
davr0s has joined #zig
ManDeJan has quit [Ping timeout: 268 seconds]
meena has quit [Remote host closed the connection]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
very-mediocre has quit [Ping timeout: 256 seconds]
davr0s has joined #zig
tridactyla has quit [Ping timeout: 276 seconds]
wilsonk has quit [Read error: No route to host]
return0e has quit [Remote host closed the connection]
return0e has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
return0e has quit [Remote host closed the connection]
return0xe has joined #zig
return0xe has quit [Read error: Connection reset by peer]
return0e has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
darithorn has joined #zig
davr0s has joined #zig
MajorLag has joined #zig
<wink_>
andrewrk: as expected when we compile the llvm/cfe sources with either the Arch Linux installed gcc or clang it works. I can only assume I was mistaken that it worked with installed clang *without* compiling the llvm/cfe sources.
<andrewrk>
wink_, unfortunately, we're forever stuck with this situation, since we depend on C++ for interfacing with llvm/clang
<wink_>
Is it that gcc/clang don't use a common ABI or some other reason?
<andrewrk>
I'm not sure what the c++ standard is, whether this is a bug or not, but yes, gcc/clang have different C++ ABIs, and even different versions of the same compiler sometimes have different c++ ABIs
<andrewrk>
bottom line is, if you're using C++ and you want to avoid a whole class of annoying bugs to troubleshoot, always use the same compiler for all your dependencies and your application
<andrewrk>
in zig we avoid this problem by not having a Zig ABI
<wink_>
The lack of Zig ABI is because it compiles "whole" programs, isn't it? If zig supported "modules" with separate compilation to standard ".o" or ".a" then it would need an ABI, correct?
<andrewrk>
correct
<andrewrk>
put another way, zig does support "modules" but you have to use the C ABI
<andrewrk>
that's what `zig build-lib` does
<wink_>
hmmm, can a "module" fn return `error!xxx` ?
<scientes>
no
<wink_>
So not terribly useful for "zig" modules, great to be able to use zig to create C compatible "modules".
<wink_>
Is there a plan to create an intermediate format of maybe the AST or ... for creating "zig modules".
<andrewrk>
no
<andrewrk>
there is no use case for that
<wink_>
How can I create a module that doesn't include the source code?
<andrewrk>
zig has rejected this use case
<andrewrk>
code obfuscation is not in scope
Ichorio has joined #zig
<wink_>
Interesting, wouldn't something in an intermediate format be faster to compile?
<andrewrk>
yes, and the self hosted compiler does use an intermediate format in order to achieve faster compilation times
<andrewrk>
but this is an implementation detail of compilation. the intermediate files are not accessible or available for use by the user
very-mediocre has joined #zig
<wink_>
Ok, but if versioned sounds like it would be just the ticket for "zig modules".
<andrewrk>
there's no use case for that
<wink_>
LOL, you've got to be kidding, we just talked about two use cases, faster compiles and distributing code without sources. So "no use case" is being disingenuous.
<andrewrk>
faster compile times is achieved without creating a stable versioned ABI, so that is not a use case for a stable versioned ABI
<andrewrk>
and as I mentioned, code obfuscation is a rejected use case
<andrewrk>
it's not even a self-consistent use case. you can't distribute a generic function, and then expect it to be obfuscated, by definition
<very-mediocre>
It might be more suitable for LGPL licensed modules though, to ship as an opaque package
very-mediocre_ has joined #zig
<andrewrk>
the LGPL allows source integration with proprietary software, you just have to separately provide the source of the LGPL thing you used
<bheads>
What about plugin architectures?
<andrewrk>
use the C ABI
<bheads>
SO we lose part of the zig safty
<wink_>
The notion of a module that can be distributed provides benefits and whether or not you want to use any particular feature. Its up to the programmer to decide how they want to implement any given algorithm.
very-mediocre has quit [Ping timeout: 256 seconds]
very-mediocre_ is now known as very-mediocre
<wink_>
I like zig, but you seem to be artifically limiting it. Anyway, lots of time for it to evolve, thanks for creating it!
<very-mediocre>
andrewrk: re LGPL tried looking it up, it seems ambiguous. This answer, while non-definitive, contradicts the idea that you can use LGPL source without infecting your own source code: https://softwareengineering.stackexchange.com/a/86158/307310
<andrewrk>
requiring whole program source at compile time is anything but a limitation. it gives the compiler the freedom to do unheard of optimizations and safety checks
<bheads>
I agree, that is the best case, but not always feesable
<very-mediocre>
I don't mean to bash you on the head with this andrewrk, several of us are kind of hammering on the same point and it might feel like we're ganging up on you
<very-mediocre>
I just think LGPL use case is a big deal, it was very common back when I worked in C and C++
<andrewrk>
very-mediocre, thanks for clearing that up, that's good to know
<andrewrk>
so LGPL should be chosen carefully as a license for zig packages. it's infectious. you can't use LGPL zig packages unless your app is LGPL
<andrewrk>
I'm fine with this as being how it works
<andrewrk>
I see this shared library as an ugly hack to work around an unnecessary legal complication. I have no intention to compromise any of zig's potential due to popularity of restrictive licenses
<andrewrk>
GPL / LGPL were always meant to be infectious anyway. If you're going to go that route, be brave, go for it all the way and only use GPL software. don't chicken out and do some ugly hack compromise
<very-mediocre>
Well the principle of LGPL is that the library is user replaceable without the main program being open source
<very-mediocre>
the "ugly hack" is distributing libs as object files, then you have to ship your main program as an object file too
<very-mediocre>
I think it's ugly in C++ because of toolchain variations
<andrewrk>
right. who wants to ship object files? users can't run object files
<very-mediocre>
Well I think it'd be superior in zig since there'd be 1 zig
<very-mediocre>
not multiple compilers with different interfacess
<andrewrk>
you can still do all this with the C ABI
<andrewrk>
and I'm saying "no" to the LGPL use case for introducing a stable Zig ABI. it's too much in direct contradiction with many things zig is trying to accomplish
<very-mediocre>
I guess LGPL libs can be shipped as DLLs for windows...
<very-mediocre>
but there won't be any .so equivalent.
<andrewrk>
why no .so equivalent?
<very-mediocre>
Actually you're right.
<andrewrk>
`zig build-lib` creates .so's
<andrewrk>
even for this LGPL use case, zig is strictly an improvement over C
<very-mediocre>
Yeah, for a second I thought .so was static linking
<very-mediocre>
I'm inexperienced in linux dev
<andrewrk>
the rejected proposal is to introduce *another* ABI, one that basically requires shipping all zig programs with a zig compiler
<very-mediocre>
Am I wrong then that DLL/.so modules solve all concerns, not just my LGPL concern?
<andrewrk>
the requested feature is to, for example, be able to put `fn parseInt(comptime T: type, buf: []const u8) error!T { ... }` in a .DLL / .so
<very-mediocre>
ok, my mistake for not groking this fully.
<wink_>
Just to be clear, my goal was for zig programmers to be able to share modules and when those modules are linked into an "exe", no zig compiler would be necessary.
<andrewrk>
zig programmers can do that by using `zig build-lib`
<wink_>
But, that doesn't allow the programmer to use features of zig such as error handling.
<very-mediocre>
if this doesn't get added, this can potentially be done by distributing an additional metadata file + a tool to generate safe zig code that wraps the library.
<very-mediocre>
I just reinvented header files, but actually I think that's ultimately appropriate
<very-mediocre>
apparently even C++ ABI is "stable ish" at best