mahmudov has quit [Remote host closed the connection]
batok has quit [Remote host closed the connection]
<plumm>
andrewrk: testing.expectError does not expose the underlying error return trace, is there a way to substitute return traces so I can see where the issue occured?
Ichorio_ has joined #zig
Ichorio has quit [Ping timeout: 250 seconds]
muffindrake has quit [Ping timeout: 276 seconds]
muffindrake has joined #zig
doublex_ has quit [Quit: Quit]
doublex has joined #zig
chemist69 has quit [Ping timeout: 250 seconds]
chemist69 has joined #zig
Ichorio_ has quit [Ping timeout: 250 seconds]
<shachaf>
andrewrk: Hmm, you're implementing the X11 protocol after all?
<shachaf>
Did you figure out what to do with GL?
<andrewrk>
shachaf, haven't gotten to that part yet. GL is low priority
<andrewrk>
vulkan first
<shachaf>
Doesn't either one require Xlib?
stratact has joined #zig
<andrewrk>
it depends on the target os and window manager
<stratact>
andrewrk: thanks for merging the PR and nice refactoring 👍
<andrewrk>
which involved a very deep windows api rabbit hole
<stratact>
I'm glad to help! Yeah, the Windows work is impressive, that's a lot of LoC.
<shachaf>
Is there any OS (/window manager?) that you can do it on?
tane has joined #zig
<tane>
howdy
<plumm>
howdy
<tane>
I'm currently trying to use the ZIG parser implemented in C++ and noticed that some pointers seem to be tagged, e.g their value is 1, does anyone know what that means?
tgschultz has quit [Ping timeout: 240 seconds]
ltriant has quit [Quit: leaving]
tane has quit [Quit: Leaving]
doublex has quit [Ping timeout: 250 seconds]
<scientes>
hmmm
<scientes>
no idea
tane has joined #zig
mahmudov has joined #zig
<andrewrk>
shachaf, I'm not sure what you're asking
<andrewrk>
tane, where do you see this?
<tane>
andrewrk, in AstNodeParamDecl's name buffer pointer
<andrewrk>
tane, I don't think that's intentional, it sounds like you're looking at uninitialized memory
<tane>
ok, will have a look again later
<tane>
maybe that's due to my call to ast_parse with NULL for the third argument :)
<tane>
I was too lazy to setup that type properly
<tane>
andrewrk, do you know whether someone is working on a consistency checker for the stdlib, e.g. naming, parameter declarations and so on?
<shachaf>
andrewrk: As far as I know, functions like glXSwapBuffers (and whatever the Vulkan equivalent is that connects Vulkan to the X11 connection) are provided by a shared library that requires an Xlib Display * argument.
<shachaf>
Which forces you to use Xlib rather than implementing the protocol yourself.
<andrewrk>
tane, I'm pretty sure nobody is currently working on that
<shachaf>
I got the impression that you were working on a thing that doesn't go through Xlib, but maybe I misunderstood.
<andrewrk>
shachaf, it doesn't go through Xlib but it does speak the x11 protocol
<andrewrk>
tane, currently the std lib is still in an experimental phase. when the language stabilizes then the std lib will go into a stabilization phase
<tane>
andrewrk, that's not a problem, I will just play around a bit. My goal was to find some types of inconsistencies programatically, so it might help in the stabilization
<shachaf>
Then how do you call the Vulkan functions?
<andrewrk>
shachaf, that's not implemented yet. but you load the driver as a dynamic library
<shachaf>
Sure, but then how do you call it? The functions exported by libGL (and Vulkan, I'm pretty sure) take an Xlib Display * argument.
<shachaf>
(I hope I'm not missing something really obvious here?)
<andrewrk>
if that's the case then the project is doomed
<andrewrk>
thanks mq32. yeah it's doing something with the X protocol which potentially could be done without calling glXCreateContext
<mq32>
cool
<mq32>
i hope zig-window will be a success
<mq32>
as i'm using SDL2 mostly just for "create window with OpenGL context and get input for that", it would be neat to remove that dependency
<shachaf>
If you're using Nvidia drivers it won't go through mesa at all, right?
<shachaf>
I have an X11 layer I replaced SDL with since there are a bunch of things SDL can't do. But my impression was that I had to use Xlib. It would be nice if that's not true.
<Snektron>
Just throwing out there that Vulkan surfaces can also be initialized with wayland handles or even xcb handles
<Snektron>
If someone is making a zig equivalent of glfw, i'd argue usinv xcb instead of Xlib since its a bit nicers (although also incomplete) and split the actual render backend code from the windowing part
<shachaf>
How do you initialize a Vulkan surface with an xcb handle?
<shachaf>
Oh, there's a separate header for it. I guess it has that over GL.
mahmudov has quit [Quit: Leaving]
mahmudov has joined #zig
<Snektron>
yeah theres just a surface function like for the other
<Snektron>
surface types
wizermil has joined #zig
wizermil has quit [Client Quit]
<muffindrake>
I don't think I've seen the noalias keyword in zig docs. Is that like the restrict qualifier in C?
<muffindrake>
noalias appears in function signatures, but it's not explained by itself
dimenus has quit [Read error: Connection reset by peer]
<s-ol>
it sees a type mismatch between imported enum values and the enum type (nested in a struct). is that normal?
<s-ol>
mq32 (and andrewrk): and so I learn about zig-window... guess I will be rewriting zig-imgui to run off that soon then
<s-ol>
zig-window is planned to take care of input as well I assume?
joethephish has joined #zig
joethephish has quit [Remote host closed the connection]
tane has quit [Quit: Leaving]
tgschultz has joined #zig
waleee-cl has joined #zig
jzck has quit [Remote host closed the connection]
Snektron has quit [Remote host closed the connection]
emekankurumeh[m] has quit [Remote host closed the connection]
BitPuffin has quit [Read error: Connection reset by peer]
dtz has quit [Read error: Connection reset by peer]
Demos[m] has quit [Read error: Connection reset by peer]
vegai has quit [Remote host closed the connection]
fengb has quit [Remote host closed the connection]
D3zmodos has quit [Remote host closed the connection]
keithdc has joined #zig
joethephish has joined #zig
<joethephish>
hello! anyone know if any work has been done to see if a zig-compiled static library can be used on Nintendo Switch?
<joethephish>
(I'm no expert with low level compilation / ABI etc, so I don't know whether it's enough that zig supports 64 bit ARM)
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen1 has joined #zig
dingenskirchen1 is now known as dingenskirchen
firefox317 has joined #zig
<firefox317>
joethephish: That should just work, but maybe you will find some issues on the way. There are a lot of people here that can help you with those. And ofcourse you should be able to run arbritrary code on the switch
porky11 has joined #zig
<firefox317>
See this issue regarding the current support for arm64: https://github.com/ziglang/zig/issues/2443. Most stuff just works but there are some issues with the current stdlib
<joethephish>
Makes sense. Off the top of my head, I feel like not having stdlib might not be an issue? Since most stuff would be done in custom ways via Nintendo's own SDK, whether that's logging, memory allocation, etc etc
<joethephish>
One of the things I'm not sure about is the set of compiler options that Nintendo "requires" to be passed into clang according to their docs. Though not sure whether I should really discuss those here because they're from a confidential doc :-/
<firefox317>
Oh damn, you have access to Nintendo's own SDK. That's some cool stuff, are you a game developer? It really depends on what kind of flags they need, but it should be possible since we use the same backend as clang (LLVM)
<joethephish>
Yep I'm an indie game dev (from inklestudios.com)
<joethephish>
yeah, the same backend is what gives me hope!
<joethephish>
...is there a way in build.zig to tell it to pass arbitrary extra parameters into clang, if they're not already handled natively via zig's own build structs?
<firefox317>
But for some flags you maybe have to change some stuff internally in the compiler. And probably you want to keep track of this issue for cpu features https://github.com/ziglang/zig/issues/2883
<joethephish>
ahha yes that's exactly the right issue
<firefox317>
We use clang to compile c code, but for zig code you need to pass parameters to LLVM
<joethephish>
yeah
<joethephish>
that makes sense
<firefox317>
Using `-mllvm` you can pass arbitrary flags to the LLVM backend I think
firefox317 has quit [Ping timeout: 252 seconds]
mahmudov has quit [Ping timeout: 268 seconds]
joethephish has quit [Ping timeout: 260 seconds]
firefox317 has joined #zig
lunamn has quit [Ping timeout: 265 seconds]
wilsonk has quit [Ping timeout: 265 seconds]
firefox317 has quit [Ping timeout: 245 seconds]
firefox317 has joined #zig
firefox317 has quit [Remote host closed the connection]
wilsonk has joined #zig
batok has joined #zig
wootehfoot has joined #zig
<stratact>
Hello Zig-iverse o/
<andrewrk>
hi stratact
<stratact>
andrewrk: I'm thinking of getting back into the swing of things. I probably need to relearn and update myself with Zig
<andrewrk>
ha I don't think that much has changed in 2 weeks :)
<companion_cube>
the stdlib docs! woo
<stratact>
Ah, great! And we have stdlib API docs now?
<stratact>
Ohhh! Nice
<stratact>
I'd say there should be a direct link in the website documentation to the API docs
<companion_cube>
I mean, is there even another markdown? :p
<andrewrk>
mq32, the main feature I'm interested in is line breaks and internal documentation hyperlinks when `something_like_this` matches a decl in scope
<mq32>
okay, i can serve that already :)
<andrewrk>
that's 90% of usefulness
<mq32>
should prepare a pull request
<mq32>
i also have *emphasis*, **boldness**, - unordered lists and 1. ordered lists with nesting
<andrewrk>
and I know this might be an unpopular requirement, but no external libs, you have to code the markdown parser in main.js
<mq32>
it's about 200 LOC
<plumm>
≠≠≠≠/2
<plumm>
oops
<andrewrk>
mikdusan, nice! I'm happy to see that you started taking advantage of -DZIG_ENABLE_MEM_PROFILE
<via>
~/
<andrewrk>
another idea I had regarding ConstExprValue is to do what many scripting languages do, e.g. with integer types. so for example the integer 1 can always be a certain ConstExprvalue *
<mikdusan>
fyi the results it produces are very consistent with Xcode's memory profiler that i was using
<andrewrk>
good to know
<mikdusan>
i'm toying with interning a ton of the consts to see how that works out
<andrewrk>
also feel free to rename ConstExprValue to ZigValue if you want to
<andrewrk>
ah yeah that's what that's called, "interning"
<andrewrk>
we should be able to free every `Const` IrInstruction
<andrewrk>
I'm pretty sure none of the pass1 instructions need to be alive during codegen phase
<andrewrk>
ConstGlobalRefs is a mess. that data/code used to make sense and now I need to audit all of it
<mikdusan>
i'm assuming we can fold all voids.. and undefined... and dedup based on values for bool, and the other numbers
<andrewrk>
yes, anything where type_has_one_possible_value
<mikdusan>
right now as it stands "unembedding" has a penalty of about 100 megabytes because added pointer. so i don't want to commit anything until we get above water
<mq32>
it turns out that if you remove a lot of crazy features from markdown, your parser gets quite "short"
<plumm>
what crazy features? id say the same for TOML lol
<companion_cube>
call that micro-markdown ;)
<mq32>
companion_cube, yeah, probably
<andrewrk>
the nice thing about markdown is that it degrades gracefully
<mq32>
plumm, just read some stuff in the spec i posted above
<companion_cube>
tbh I think it's cool, if you're compatible with the correspnding subset of cmark
<mq32>
yeah i made some adjustments like improved code docs
<mq32>
but for code blocks i just went with ``` for entry/exit
<shachaf>
andrewrk: Wayland doesn't solve any of this because the API is written the same way. EGL/Vulkan functions take a wl_display * and so on.
doublex has quit [Ping timeout: 245 seconds]
Ichorio_ has joined #zig
doublex has joined #zig
<andrewrk>
btw anyone who is doing generated docs work: you may not have noticed but there is a new flag: -fno-emit-bin
<andrewrk>
shaves off a lot of time when doing std lib docs
plumm has quit [Quit: leaving]
<mq32>
oh nice!
lunamn has joined #zig
mahmudov has joined #zig
<tgschultz>
stdlib docs are going to be pretty big for adoption. I suppose I should go over my contributions and make sure they produce something reasonable.
<tgschultz>
also, kind of a long shot, but is anyone aware of a linux utility (using seccomp maybe?) that can arbitrarily redirect a program's 'open' syscalls?
<companion_cube>
something based on ptrace, maybe?
<tgschultz>
that's a start, thanks. I see someone working on snapd has experimented along these lines. I had hoped for a ready made solution.
dimenus has quit [Ping timeout: 268 seconds]
dimenus has joined #zig
lunamn has quit [Ping timeout: 245 seconds]
lunamn has joined #zig
porky11 has quit [Quit: Leaving]
dimenus has quit [Remote host closed the connection]
dimenus has joined #zig
<andrewrk>
anyone who has a source build of zig on posix, try pulling latest master (after f65b1d46804bce7) and run: make && ./zig test ../lib/std/std.zig -lc
<andrewrk>
the progress display is quite nice now
<mikdusan>
is that the "building dependency" stuff?
wootehfoot has quit [Quit: pillow time]
<pixelherodev>
I would, but my laptop (which has Zig) doesn't have working internet at the moment. I had to quickly replace the screen last week after it broke and I apparently forgot to reconnect the I/O board (so ethernet isn't working) and the wifi antennas are a tad loose (so I don't get a signal where I am right now)
<pixelherodev>
I'll have to try later :P
<andrewrk>
mikdusan, yeah but I messed up the nodes a bit before, now that's fixed and it's integrated with zig's semantic analysis
<mikdusan>
oh neat
<andrewrk>
now it's obvious that most of the time is spent waiting for LLVM :P
<pixelherodev>
In other words, once the stage2 compiler works, we need to replace the LLVM implementation with a new one in Zig?
<pixelherodev>
(joking!)
<andrewrk>
yeah. seriously though, llvm is not fast enough for debug builds, plus lots of zig's target audience is concerned about LLVM monoculture
<andrewrk>
the problem of creating a debug mode code generator is a less difficult task than competing with the performance optimizations
<andrewrk>
it's still a large project though, when you consider you have to do O(N) architectures, object file formats, and debug info targets
<andrewrk>
however the biggest use case for fast debug builds is game devs who are interested in x86_64
<mikdusan>
ah so you're thinking _really_ fast and straight to machine object? ie: no external assembler required?
<andrewrk>
yes, if build-exe is provided and no objects to link
<andrewrk>
this is also related to hot code swapping
<andrewrk>
which could be quite useful if the compiler can take advantage of language semantics, e.g. no guaranteed struct size or layout
<mikdusan>
i mean given that most people _develop_ on x86_64 it wouldn't really be that bad if x86_64 was the only fast backend available
<pixelherodev>
Especially if it leaves room to add more
<andrewrk>
precisely - that would be high reward for relatively small cost
<pixelherodev>
With a proof of concept on the most valuable target, it would be a lot easier for others to join in and add the platforms of their choice
<andrewrk>
yes
<ky0ko>
i'd be somewhat displeased with only having x86_64, but i'm also the sort of person that runs netbsd on a powermac g4 as a primary computing device
<pixelherodev>
The assembler is the easy part though
<andrewrk>
ky0ko, we have to start somewhere, all the targets aren't going to become simultaneously available
<ky0ko>
yeah that's fair
<pixelherodev>
The question is, how do we get to assembly? Write a "simple" LLVM IR -> x64 assembly translator in Zig? Or replace LLVM in the pipeline entirely? Either way, that's going to take a lot of worj
<pixelherodev>
s/worj/work
<ky0ko>
speaking of netbsd on powerpc, how can i set my build target when i'm using "zig build"?
<ky0ko>
is that something that needs to be done in build.zig?
<andrewrk>
jonathan blow demod doing something like this and got very fast results. however his proof of concept is limited to alway-rebuild-everything strategy, which, has the major benefit of simplicity. but it's limited to small-medium size projects, where I plan to support very large projects in zig via incremental compilation & linking
<andrewrk>
some of the code in translate_c.zig is a bit clunky, which you are welcome to rework as you see fit. it can be quite a satisfying thing to work on, because you have well-defined input (C code) and well defined output (translated zig code)
<andrewrk>
and it lends itself to small improvements ("this 1 new test case now works")
<andrewrk>
completing this sub-project (make translate-c self-hosted) will have to be done before we can make self-hosted the thing we ship
<andrewrk>
but the good news is that if this sub-project is completed, then we can delete 5,162 lines of C++ code, even before the rest of self-hosted is done
<andrewrk>
this goes for anyone else looking to contribute too - this project is large but modular and friendly towards multiple simultaneous contributors with a small bit of coordination
<mikdusan>
heh interning enum_literals for test std.zig saves 40 MiB
Snektron has quit [Ping timeout: 276 seconds]
<andrewrk>
beautiful
<andrewrk>
it might be nice to do that memory analysis for the compiler_rt tests too. we have those gigantic test files
<pixelherodev>
How many tests are there for that?
<pixelherodev>
(self-hosted translation)
<andrewrk>
oh it's actually smaller than std lib memory usage
<mikdusan>
`g->string_literals_table` is this already string lit interning?
<andrewrk>
mikdusan, also in case you didn't figure this out yet, you can make "Unknown_X" get replaced with a useful name by passing a name in for the relevant allocate() call
<andrewrk>
pixelherodev, have a look at test/translate_c.zig. both stage1 and stage2 tests are in there.
<pixelherodev>
Neat
<andrewrk>
mikdusan, yes, under some conditions arrays go into that table, to make comptime []const u8 parameters cache as expected
<andrewrk>
you can try disabling that and see what behavior tests fail
<andrewrk>
mikdusan, we have a bit of a design issue to consider here with regards to memory: the language semantics currently require comptime calls to always return the same result; this is why ArrayList(u8) == ArrayList(u8)
<andrewrk>
well, I think this is OK. I was going to say that a program can require an arbitrary amount of memory to be stored by doing comptime calls. but this is already true, for any language; a program could be arbitrarily long
Snektron has joined #zig
<Snektron>
test
<Snektron>
if translate-c is made self hosted, would that mean making an entire c parser in Zig?
<Snektron>
Or would that still be done by clang, then make Zig interact with the whatever clang spits out?
<Snektron>
also is it me or does something not sync up well with the log?
<Snektron>
ah its me, i was having trouble with matrix
<pixelherodev>
What branch should the work on translate_c.zig go under?
<pixelherodev>
s/should/is/
<pixelherodev>
Is it on the master branch at the moment?
<Snektron>
andrewrk: did you catch what i asked about the recommended style some time ago?
<andrewrk>
pixelherodev, yeah master branch. you can use `zig translate-c-2` to try out the self hosted code. @cImport is hard coded to be the c++ implementation at the moment
<Snektron>
as i recall, enum literals should be formatted in snake case, yet thats not always the case in the standard library