ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
Zaab1t has quit [Ping timeout: 244 seconds]
wilsonk has quit [Ping timeout: 246 seconds]
steveno has joined #zig
kristate has joined #zig
wilsonk has joined #zig
steveno has quit [Quit: Leaving]
wilsonk has quit [Ping timeout: 250 seconds]
schme245 has joined #zig
schme245 has quit [Ping timeout: 240 seconds]
darithorn_ has joined #zig
darithorn has quit [Remote host closed the connection]
darithorn_ has quit [Quit: Leaving]
marmotini_ has joined #zig
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 250 seconds]
schme245 has joined #zig
marmotini has quit [Remote host closed the connection]
marmotini has joined #zig
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schme245 has quit [Remote host closed the connection]
schme245 has joined #zig
schme245 has quit [Remote host closed the connection]
schme245 has joined #zig
_whitelogger has joined #zig
schme245 has quit [Remote host closed the connection]
schme245 has joined #zig
schme245 has quit [Remote host closed the connection]
schme245 has joined #zig
schme245 has quit [Ping timeout: 246 seconds]
very-mediocre has joined #zig
schme245 has joined #zig
schme245 has quit [Ping timeout: 245 seconds]
schme245 has joined #zig
wilsonk has joined #zig
steveno has joined #zig
jevinskie has joined #zig
marmotini has quit [Ping timeout: 246 seconds]
marmotini has joined #zig
schme245 has quit [Remote host closed the connection]
<andrewrk>
your compile error output shows a file called `des` not `des_test.zig`
<andrewrk>
are you trying to @import a non zig source file?
marmotini_ has quit [Ping timeout: 245 seconds]
<schme245>
no, I have two files: des.zig and des_test.zig, and I'm trying to move the tests from the first one to the second one
<schme245>
des.zig compiles fine, and des_test.zig has this as the first line: const des = @import("des");
<andrewrk>
why does it say des:1 and not des.zig:1?
<andrewrk>
you have a file called `des` on your file system, which starts with the byte 0xcf
<schme245>
should the import be `const des = @import("des.zig");`?
<schme245>
ohh shiii... it's trying to load the eez
<andrewrk>
and you didn't give --pkg-begin des des.zig --pkg-end args
<schme245>
*exe
<schme245>
this is PEBKAC, I need to read up on the build system
<schme245>
sorry for the noise
<andrewrk>
no worries
<andrewrk>
the build system is very experimental rigth now. I will to improve the usability and documentation greatly before really pushing for people to use it
Akuli has joined #zig
<schme245>
I love that the build system is regular Zig code
<schme245>
Zig actually reminds me quite a bit of Clojure (my current fav language) due to it's focus on simplicity and great meta-programming/reflection facilities :)
noonien has quit [Quit: Connection closed for inactivity]
<andrewrk>
I have big plans for the build system
<andrewrk>
once zig has its own libc and can build C libraries, and we get the package manager going, zig build is going to let you depend on any dependency tree of zig and C libraries, all while keeping your project's build instructions as simple as `zig build`
<shachaf>
Hmm. Even on Linux you need to dynamically link against the system libc if you use any other system dynamically linked libraries, don't you?
<andrewrk>
that's right - this would be for static library dependencies
<Akuli>
would that mean that using the system's dynamically linked libraries will be hard? or just use a compiler option that links everything with the system's libc?
<shachaf>
So if you have to link against some dynamic library, you'd be using parts of both the static and the dynamic libc?
<andrewrk>
linking against a system's dynamically linked library will be a supported use case, but non-default. note that when you choose to do that, your project's build instructions become 2 steps: 1. install system libraries 2. zig build
<shachaf>
I'd rather statically link everything, but for things like OpenGL that's not an option (right?)
<andrewrk>
I say "default" but really I mean "recommended by me". either way you would be specifying in your build script "depend on this zig package statically" or "depend on system library foo"
<andrewrk>
for the opengl case, it's actually a case of loading at runtime, which I am researching if we can do without depending on system libc
marmotini has quit [Ping timeout: 272 seconds]
<shachaf>
Hmm, you're implementing the X protocol yourself?
<shachaf>
I've wondered whether doing that is feasible, but it looked to me like it wasn't compatible with libGL.
<andrewrk>
yes zig-window will implement the X protocol and the wayland protocol
<Akuli>
andrewrk, how is the x protocol library intended to be used, when it'll be done? just creating applications with it? will the applications be able to use e.g. gtk themes?
<andrewrk>
the problems I ran into: (1) blocking on coroutine rewrite (2) need to implement runtime library loading to load the drivers
<andrewrk>
both solvable, just will take some time
<andrewrk>
Akuli, the main use case would be for windowed or full screen games
<andrewrk>
or specality applications such as a digital audio workstation / photo editor
<shachaf>
So the plan is to do dynamic loading of libGL yourself and do your own relocations and everything?
<andrewrk>
if you want gtk themes you have to link the system gtk libraries, as far as I know
<andrewrk>
that's right
<Akuli>
ummmm
<Akuli>
is this whole project there just to avoid linking to the system's gtk libraries?
<shachaf>
OK. I've thought about doing that in the past and it seemed like it'd be too fragile. But I didn't think about it for very long.
<andrewrk>
Akuli, why would you want gtk for a full screen / windowed game that has its own ui code?
<Akuli>
this really feels like a problem that has been already solved to me
<Akuli>
tk has already cross-platform window code that uses x11 and other platform-specific apis
<Akuli>
so does gtk, and qt
<andrewrk>
shachaf, the good thing about loading is that the code is already implemented in a dozen places, you can just port it. and it's one of the most stable ABIs that never changes
<Akuli>
i see this as a thing that someone will use like let me try this thing for an image editor (for instance), ok how do i add a menubar? wut is that menubar so ugly? why isn't it using my gtk theme?
<shachaf>
What's stable?
<andrewrk>
shachaf, the ELF file format, for example
<shachaf>
The unstable part I'd be worried about is "which parts of libc libGL etc. depends on"
<andrewrk>
when we load gl at runtime, we would see that it needs libc, and we would load libc too
<shachaf>
You can look at an existing GL implementation but you never know what nvidia or whoever will use in the future.
<shachaf>
Oh, so you are talking about loading the system libc.
<shachaf>
Just replacing ld-linux
steveno_ has joined #zig
<andrewrk>
right. one of the goals is to have an actually static executable on linux
<andrewrk>
I'm not joking or exaggerating when I say zig's goal is to replace C
<shachaf>
OK, that makes more sense. But then how can you implement the X11 protocol yourself, since libGL just depends on libX11?
<andrewrk>
the protocol is actually pretty simple, it's just bytes over a socket
<andrewrk>
and the protocol has a stable ABI
<andrewrk>
libX11 is just cruft
<shachaf>
I agree with all of that.
<shachaf>
But I thought the way GL was exposed, you had to use libX11.
<andrewrk>
indeed, if you look at the dynamic libraries the gl driver depends on, it includes a bunch of libX11 libraries. which means the application will have to load them in order to use the driver
<shachaf>
Since all the glx functions take a Display * or whatever.
<andrewrk>
so some of your code speaks the X protocol directly, and some of it does it via the driver, which we can't control
<shachaf>
Huh. And that works?
<andrewrk>
that's one of the things I'm exploring. I haven't reached a proof of concept yet
<andrewrk>
but if it works - you end up with a lean, static executable that will run on *any* linux distro
<shachaf>
I didn't look into it that deeply, like I said. I was under the impression it wouldn't work that well.
<shachaf>
Would be nice if it does, though.
<shachaf>
How much do you get out of implementing the X protocol yourself if you're also using libX anyway?
<andrewrk>
you get a static executable
<Akuli>
why is statically linking a "good" thing? is there not a reason why most things are dynamically linked nowadays?
<andrewrk>
Akuli, it's mostly a historical thing, from when hard drives were 1 MiB
<shachaf>
But it's not "really" static because it still depends on loading the system X11
<shachaf>
I mean libX11
<Akuli>
isn't a statically linked thing slower to compile?
<Akuli>
if the executable will contain a pile of libraries in it, that is
<andrewrk>
it really is - because it runs on any linux distro, and if it can't find the system driver, it can give a helpful error message, or even let the user configure at runtime with command line args or config files, which driver to load
<shachaf>
OK, sure, that part is fine. I mean, what do you get out of reimplementing the X11 protocol if you're also relying on loading the system libX11.
<andrewrk>
you don't know that the driver depends on system libX11. it might not
<andrewrk>
for all you know it's 1 big .so file that you can plunk in to contiguous memory
<shachaf>
You do because the calls in the ABI, glXSwapBuffers etc., take a Display * argument. Don't they?
<shachaf>
And you need to get that from XOpenDisplay, since it's part of the libX11 ABI, not the X11 protocol.
<shachaf>
I might be missing something.
<andrewrk>
Akuli, yes, static linking does work at compile time, that dynamic linking puts off until runtime. but it doesn't automatically mean your build is going to be slow. I have a lot of things in mind for what zig stage2 will do to compile fast
<andrewrk>
shachaf, I see your point. that would indeed be a monkey wrench in my plans. I haven't gotten to that part yet
<andrewrk>
in my opinion this would be an API deficiency and I would go so far as to open an issue with the driver team and start a discussion before giving up
<shachaf>
OK. Will be curious how you solve this.
<shachaf>
I mean, there are lots of API deficiencies, but these are the ABIs that exist. Everything's a mess. :-(
<andrewrk>
I'm going to do my part in trying to solve it in what I think is the best way, before giving up
<shachaf>
++
<shachaf>
I have some statically linked C code with no libc, and it's not that much work to get something working with the Linux kernel ABI, but then there are a bunch of annoyances for other services provided by the system.
<shachaf>
I imagine you'll also need to write code to parse /etc/passwd, /etc/resolv.conf, etc. yourself? Those are probably stable enough that it isn't a problem.
<andrewrk>
yes. and even then there are some services that rely on patching glibc to get different behavior for getusername etc, and these services are simply incompatible with static executables
<andrewrk>
that is unfortunate, since linux guarantees a stable kernel ABI, it seems these services made a poor decision to rely on patching glibc
<andrewrk>
anyway, like you said, it's a mess, but it's my intention to empower zig users to create the best possible applications, document the various pitfalls on all the operating systems, and solve everybody's use cases in reasonable ways
<andrewrk>
it's just going to take some time. there are a lot of problems to solve, and I'm leaving no rock unturned
wootehfoot has joined #zig
<Akuli>
question: if zig will be a thing that c projects will use, will zig act as just a linker? or a compiler that does macro preprocessing etc as well?
<Akuli>
if i have a c project, how will this be different from just compiling with clang? i get a different libc, but will i notice any practical difference?
<andrewrk>
the main reason for this is so that zig packages can depend on C libraries, without introducing a dependency on system C compiler
<andrewrk>
which matters especially for cross compilation
<Akuli>
so this is for zig programmers who want to use clang compatible libraries?
<andrewrk>
there should not be any practical difference
<andrewrk>
in general, it's to minimize third party dependencies
<andrewrk>
I want programmers on any platform to be able to depend on each other's code, and it will "just work"
steveno_ has quit [Read error: Connection reset by peer]
steveno has joined #zig
m_p has joined #zig
m_p has quit [Client Quit]
very-mediocre has quit [Quit: Page closed]
steveno has quit [Remote host closed the connection]
Dennis0 has joined #zig
Akuli has quit [Quit: Leaving]
noonien has joined #zig
niftynei has joined #zig
schme245 has quit [Remote host closed the connection]
schme245 has joined #zig
schme245 has quit [Remote host closed the connection]