<andrewrk>
pauladamsmith, 'OpenGL/gl.h' file not found
<andrewrk>
I'm not sure how to make that work. OpenGL is deprecated on macOS, so I'm not sure what a real fix would look like, apart from implementing a metal-specific graphics backend
<andrewrk>
I guess for now, tetris is an example that only works on linux
<pauladamsmith>
ah, didn't know that about the deprecation. oh, well. thanks anyway
<andrewrk>
and then... idk probably I wouldn't support macOS because I don't fancy doing metal-specific code
<shawn_>
except that linux is now wayland
fengb_ has left #zig [#zig]
shawn_ is now known as scientes
fengb_ has joined #zig
<andrewrk>
I mean, zig-window would support macOS
<andrewrk>
scientes, why do you say except?
<scientes>
well why are you working on x11?
<scientes>
it is kind of deprecated at this point
return0e has joined #zig
return0e has quit [Remote host closed the connection]
<andrewrk>
you're asking about why I use xfce as my desktop?
<scientes>
and even before that libx11 was for libxcb
<andrewrk>
or are you asking why zig-window would support X11 in addition to Wayland?
<scientes>
yes
<andrewrk>
wayland hasn't won the mind share. x11 is prevelant. I still use it, for one.
<andrewrk>
if I switched I would lose obs-studio support, which I use weekly for live streaming
<andrewrk>
I love the latest and greatest, but wayland has been promising a lot for a long time and not delivering
<andrewrk>
I feel skeptical at this point
<scientes>
I was a bit ticked that I couldn't stream my desktop
<scientes>
it didn't really promise that much
<andrewrk>
if it was better than X11 then it would be more popular
<scientes>
but it did promise a few things, like secure input handling
<scientes>
which it delivered
<andrewrk>
anyway, point being if you want a portable window abstraction, X11 is still relevant. and it's a good place to start because it will work on both X11 and Wayland desktops
<scientes>
true
<andrewrk>
also I found out the C library for X11 that everyone uses is blocking whereas the X11 server is inherently asynchronous
<scientes>
thats why there is libxcb
<andrewrk>
so it will be interesting to expose an event-based API
<scientes>
but the extensions to x11 that everyone uses make it more like wayland
<scientes>
so that was the whole reason
<andrewrk>
I'm pretty sure libxcb is exactly what I'm talking about
wilsonk has joined #zig
wilsonk|3 has quit [Ping timeout: 246 seconds]
return0e has joined #zig
pauladamsmith has quit [Ping timeout: 256 seconds]
wilsonk has quit [Ping timeout: 250 seconds]
daurnimator has quit [Ping timeout: 240 seconds]
ijneb has joined #zig
mikdusan has joined #zig
<mikdusan>
on macos, it’s all metal from apple. opengl is on lifeline stuck at some old version. vulkan has no support from apple but a company open-sourced MoltenVK which is a vulkan wrapper around metal. apparently it works pretty darned good. was sponsered by one of the big game engine companies iirc.
<andrewrk>
if moltenvk is good, that makes vulkan the de facto standard
<mikdusan>
there’s serveral claims/examples of opengl games on mac ported to MoltenVK getting excellent fps improvements
<scientes>
the source can be freed once it has been parsed, right?
<mikdusan>
i’m pretty sure you want source to stick around for the lifetime of an ast.Tree
<scientes>
I guess that is necessary anyways, in order to display error messages
<andrewrk>
stage2 is a long running process. it does reference counting on resources, which is necessary since components can be updated independently from each other
<andrewrk>
down to single-function edits
<scientes>
you mean the compiler will stick around when you recompile your code
<andrewrk>
mikdusan, vaporware project for games and graphics-based applications. see the README in the github link above
<mikdusan>
found link.
<andrewrk>
stage2 presents several as yet unsolved problems. for example, if you have 3 functions, and then update function 2, and then update function 3, each function has a difference reference to a different AST
<andrewrk>
and if you insert blank lines between functions, zig is smart enough to not recompile anything.... except now all the debug info is wrong
<andrewrk>
in theory we should be able to update a single integer in the output when you insert a blank line
<andrewrk>
which is an offset in the debug info
<andrewrk>
anyway. I can't get back to that fun stuff until more stage1 stuff is done
<mikdusan>
you know what’d i’d love to see? a new editor written in zig. not text-based but vulkan-based. it’s own font engine. persistent structures (ie. snapshots) for text. tie with super-build system for granular incremental builds. and oh yeah, some bells/whistles visualizing code section recompiling, while you’re editing.
<scientes>
mikdusan, what about gnome-builder?
<scientes>
thats almost what you are describing
noonien has quit [Quit: Connection closed for inactivity]
wilsonk has joined #zig
<scientes>
but honestly, I like a real simple editor
<scientes>
too many bells and whistles get in the way
<scientes>
I use gedit, and lots of git grep
<andrewrk>
wow, gedit, hahaha
<mikdusan>
is gnome-builder macos savvy or does it treat it like a 3rd-class citizen?
<andrewrk>
somehow I'm not surprised. and I'm not being condescending either
<andrewrk>
I used gedit for a few years
<scientes>
I even wrote a lang file for it, but it isn't polished
<gonzus>
Since I'm here, I have another basic question.
<gonzus>
pub fn set(self: *Foo) {}
<gonzus>
Is the usage of "*Foo" (as opposed to "Foo") what makes that function able to modify self?
<gonzus>
If I leave the "*" out, I do get compilation errors for lines that modify any field in self.
<gonzus>
So I guess it is. But I ask because the docs say that the compiler chooses when to pass a reference and when to make a copy. I guess that's from an optimization POV.
<andrewrk>
oh, you must have already seen this, apologies
<gonzus>
Yeah, I did.
<andrewrk>
the answer to your question is yes. when you pass a mutable pointer, the function body can write through the pointer
<gonzus>
Ok. So this is actually nice. Because no matter what you pass (Foo or *Foo), you always access the data the same way (no "." vs "->"). And even if you pass Foo, the compiler may decide to pass a *Foo (for efficiency sake). But you MUST pass a *Foo if you want to modify the value.
<andrewrk>
correct
<gonzus>
I think a short explanation of this (passing parameters by reference to make them modifiable) would be a good addition to the docs.
<andrewrk>
noted
<gonzus>
If I create a struct (such as Point), is there a standard method name to define, so that I can use printf to print it? Can you point me to docs / examples?
<scientes>
zig doesn't have interfaces, because that would bloat the run-time
<bheads_>
zig build-exe test.zig --library c -target x86_64-linux-musl
<bheads_>
getting this error on debian: posix_spawn failed: Too many open files
<bheads_>
did I miss a step when building zig for musl?
<scientes>
bheads_, i'll have a patch in a sec
<bheads_>
nice, is the compiler leaking file descriptors?
<scientes>
well my patch wont fix that
<scientes>
the default limit is 1024 which is quite low
<scientes>
and is kept low to not break applications that use select()
<bheads_>
sure, but we shouldn't have to change users open file limit to compile
<scientes>
its just for the process
<andrewrk>
bheads_, hmm that's weird. I don't know why zig would have more than a handful of files open at once
<tgschultz>
btw gonzus, the `u0` was a result of `u1` requiring a type with Log2(1) bits to shift by.
<bheads_>
bumped the soft limit up ulimit -Sn 2048
<andrewrk>
yes the number of bits you are allowed to shift a u1 by is 0.
neceve has joined #zig
<scientes>
bheads_, hard limit defaults to 4096
<scientes>
so see if that works
<bheads_>
yeah but it was hitting the soft limit
<bheads_>
ulimit -Sn 2048 worked
<andrewrk>
it also might have worked if you changed nothing and tried again
<andrewrk>
I don't know why this error occurs
<bheads_>
I have tried multiple times on two different machines
<bheads_>
both debian
<scientes>
look at strace -e trace=open and figure what is geting opened
hio has joined #zig
<scientes>
yeah with trace=openat you can see it is opening up the work from lib/zig/libc/(musl|include)
<scientes>
to implement @cInclude()
<andrewrk>
@cInclude? you mean -isystem args passed to the child process?
<scientes>
ahh, i think it is leaking fds with the caching code
<scientes>
cause the other ones are getting re-user
<andrewrk>
sounds like a bug. the caching code is supposed to close all fds when done
<andrewrk>
I don't see anything obvious
<scientes>
ahh yes found it
<scientes>
oh no
<scientes>
ahh there it is
<scientes>
andrewrk, you could use __attribute__((cleanup))
<andrewrk>
scientes, thanks for the fix, looks good. does the strace look better?
<scientes>
yes
<andrewrk>
I'd rather not use attribute cleanup in stage1
<andrewrk>
but yeah errdefer would have prevented this
<daurnimator>
andrewrk: did we get anywhere with a 'may longjmp' annotation?
neceve has quit [Remote host closed the connection]
halosghost has joined #zig
jjido has joined #zig
<gonzus>
tgschultz yeah, I see that now. Thanks.
gonzus has quit [Quit: Page closed]
gonzus has joined #zig
<gonzus>
I decided to move to zig head (with brew install --HEAD zig)
<gonzus>
Now when I compile anything I see these messages:
<gonzus>
Warning: Unable to write cache file '/Users/XXX/Library/Application Support/zig/stage1/exe/1uvZ9H2R-YSuuebH14sv$bO4DRYGGw1GYFIA9O2brRJbX5AaqLnUF4hBoxSMYUgA.txt': file system error
<gonzus>
The tests still run, so this is indeed a warning.
<gonzus>
The file is created and has perms 644 and correct owner, but 0 byts.
<gonzus>
*bytes
<andrewrk>
hmm. I should make that have a more detailed error message
<gonzus>
Also, this is driving me nuts: I know I can use {x} to print a hex value. Can I give it a specified width, and tell it to prepend it with zeros if needed?
jjido has quit [Quit: Connection closed for inactivity]
<andrewrk>
gonzus, {x2} will pad to 2 digits
<andrewrk>
gonzus, I pushed a commit that will print a more detailed error message for you