ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
presiden has quit [Ping timeout: 240 seconds]
ForLoveOfCats has quit [Quit: Konversation terminated!]
<plumm> andrewrk: should the test name appear more than once?
<plumm> or more, is it a possibility?
<andrewrk> it can happen if the tests write to stdout/stderr
<andrewrk> this will get better in the future when is done
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> stratact, thanks for your contribution! I was inspired by your work to continue further on it and do
<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> I would also caution against doing it too soon before, as it will create unnecessary churn
<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
<mq32> andrewrk: the usual way to create an OpenGL context is glXCreateContext ( )
doublex has joined #zig
<andrewrk> I'll look at the source of glXCreateContext and see if it can't be broken down further
<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]
dimenus has joined #zig
<s-ol> hey, i posted this issue a couple of days ago about C-imported enum types:
<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: 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
<joethephish> yeah, the same backend is what gives me hope!
<joethephish> 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
<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
<stratact> upvoted
<mq32> oh that link reminds me that i should continue on the markdown parser...
<mq32> andrewrk, do you want a specific feature set?
<companion_cube> hello commonmark
marijnfs has joined #zig
<mq32> companion_cube, if you want commonmark, you have to implement it yourself :D
<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
<mikdusan> i hope so. also here's a rough count of some values for typical `test std.zig`:
<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
<andrewrk> that's fair
<mq32> ha, markdown works well with the new layout:
<andrewrk> wow that's much more readable
<mikdusan> oh sweet.
<plumm> so nice!
<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> ky0ko, const target = b.addStandardTargetOptions(); foo.setTheTarget(target);
<andrewrk> ky0ko, this will give you the native target by default, and allow overriding it with netbsd-powerpc
<andrewrk> I missed a `null` parameter to that function there
<andrewrk> pixelherodev, we don't ever get to assembly, we go straight to machine code
<andrewrk> in the use case of fast debug builds, LLVM is never touched
<andrewrk> yes it is a large project
<pixelherodev> That means changes to the compiler...
<pixelherodev> Or should this be a stage2 target only?
<andrewrk> to the self-hosted one yes, which already needs to be reworked due to the new async/await semantics
<pixelherodev> What would be a good issue to start with wrt the self hosted compiler?
<pixelherodev> I want to be able to help work on it, but at the moment I haven't touched it yet
Snektron has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk> pixelherodev, I have a good answer to that:
<pixelherodev> Thanks!
<andrewrk> have a look at for an example of hryx doing some work on this
<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?
<andrewrk> Snektron, it means moving more logic from translate_c.cpp to translate_c.zig. the issue I linked explains it:
<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
<andrewrk> enums are inconsistent because is being considered
<Snektron> Doesn't mention anything about enums
<andrewrk> which matters more than just style because is proposed
<Snektron> aha, i see
<Snektron> since i have been naming my enums in snake case
<Snektron> regarding #995: i suppose part of the verbosity can be relieved with enum literals
<andrewrk> it's going to be so, so very satisfying to delete translate_c.cpp
<Snektron> The example would then be written as `(try result_tree.errors.addOne()).* = Errors{.expected_var_decl_or_fn = .{.token = token_index}}`
Demos[m] has joined #zig
dtz has joined #zig
vegai has joined #zig
BitPuffin has joined #zig
jzck has joined #zig
fengb has joined #zig
D3zmodos has joined #zig
daurnimator has joined #zig
emekankurumeh[m] has joined #zig
mahmudov has quit [Ping timeout: 246 seconds]