ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
blinghound has quit [Remote host closed the connection]
doublex has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
pangey has quit [Ping timeout: 260 seconds]
craigo has quit [Ping timeout: 264 seconds]
_whitelogger has joined #zig
rzezeski has joined #zig
CodeSpelunker has joined #zig
CodeSpelunker has quit [Quit: CodeSpelunker]
CodeSpelunker has joined #zig
nvmd has joined #zig
CodeSpelunker has quit [Quit: CodeSpelunker]
<gruebite> heh, may: while (var i: usize = 0) (i < 42) (i += 1) { ... }
<gruebite> maybe*
<gruebite> forgot the colons
craigo has joined #zig
<Kingsquee> huh, interesting
<Kingsquee> sokol_debugtext integrates some font data directly in its source code, and offers functions to initialize font structs with them
<Kingsquee> when I try to do that via zig, it fails
<Kingsquee> but when I port the raw font data into the zig source and do it manually, it works
<Kingsquee> I wonder if the data's being optimized out or misaligned or something
<Kingsquee> on the c side
craigo has quit [Remote host closed the connection]
craigo has joined #zig
<gruebite> how was the c compiled?
<Kingsquee> sokol.c compiled through build.zig
<Kingsquee> addIncludeDir and addCSourceFile
pmwhite has quit [Ping timeout: 240 seconds]
<pixelherodev> Ha, woot! all three Passed CI :D
<gruebite> what is a good convention for allocation and returning something that needs to be freed? in C it's stricky too and requires documentation/naming convention
<gruebite> if you're passing in an allocator you're probably expecting it to allocate and need freeing
<gruebite> but not necessarily
<pixelherodev> I use h_
rzezeski has quit [Quit: Connection closed for inactivity]
cole-h has quit [Quit: Goodbye]
stripedpajamas has joined #zig
KKRT has joined #zig
xoich has joined #zig
marnix has joined #zig
marnix has quit [Ping timeout: 240 seconds]
antaoiseach has joined #zig
<antaoiseach> Do we have the equivalent of limits.h in Zig? I searched the stdlib, but couldn't find anything close - only floating point max/min in math.zig
<pixelherodev> Recursive detection of .c files in src/ ;)
<pixelherodev> antaoiseach: there's std.math.maxInt
<antaoiseach> pixelherodev: D'oh .... I'm an idiot! :D
<antaoiseach> Thanks, mate!
<pixelherodev> No worries!
<pixelherodev> We've all been there :)
<antaoiseach> Hahaha
antaoiseach has quit [Client Quit]
decentpenguin has quit [Read error: Connection reset by peer]
craigo has quit [Ping timeout: 264 seconds]
decentpenguin has joined #zig
<pixelherodev> Woot, it works :)
<pixelherodev> Zig build system is awesome even for C projects
<pixelherodev> `zig build -Dtarget=native-linux && ./zig-cache/bin/coyote` -> `Not yet implemented, sorry!`
<pixelherodev> I love this so much
stripedpajamas has quit [Quit: sleeping...]
<gruebite> nice!
<pixelherodev> Yeah, it's awesome
<pixelherodev> Currently figuring out what language features to focus on for the language jam :)
Kingsquee has quit []
riba has joined #zig
xoich has quit [Quit: leaving]
riba has quit [Ping timeout: 256 seconds]
riba has joined #zig
hspak has quit [Ping timeout: 256 seconds]
riba has quit [Ping timeout: 264 seconds]
drewr has quit [Ping timeout: 244 seconds]
drewr has joined #zig
<ikskuh> pixelherodev: if you pr-merge libraries of mine into std, please notify me on github ;)
<pixelherodev> Ah right :P
<ikskuh> because if they get merged, i can archive the original repo and hint people at zig std
<pixelherodev> ikskuh: I mentioned it in #spu-mark-ii IIRC
<ikskuh> yeah, still tag me on github so i can keep track of it
<pixelherodev> Gotcha
<pixelherodev> Is it weird that I'm surprised they all passed CI? :P
<ifreund> man, having zig fmt disabled for the file is kinda annyoing
<pixelherodev> Very annoying.
<pixelherodev> you know what, fourth PR incoming.
<ikskuh> ifreund: why is it disabled
<pixelherodev> I'm going to narrow down the fmt: off to the specific sections
<pixelherodev> ikskuh: because bug
<pixelherodev> Well, fmt doesn't do what we want
<pixelherodev> Not exactly bug
<pixelherodev> #5948
<ifreund> nice
<ifreund> I'm currently working on what I see as the first step for wasm/PE whatever, which is making the code a bit more generic/less Elf-centric
<ikskuh> \o/
<ifreund> the idea is to avoid conflicts with alexnask[m] after this PR is done
<ikskuh> nice
<pixelherodev> ... dammit, does `zig fmt: off` only get recognized at root scope?
<ifreund> yes ...
<pixelherodev> Forgot about that
<ifreund> pixelherodev: guess you should just implement that feature :P
<pixelherodev> That's a *bit* more complex
<pixelherodev> If anyone here has worked with `zig fmt`, I'd rather pass the torch to you :P
<pixelherodev> Otherwise, #5948 is on my todo list for Monday
<pixelherodev> So it'll hopefully be reenabled soonish anyways
<ifreund> yeah I haven't touched zig fmt yet, though probably will at some point
<ifreund> there are a couple of other things I want it to do
<pixelherodev> Anywho it's five AM, I'm going to take a quick nap before I get to work :P
<ifreund> non-caffineated tea didn't fix the sleep?
<pixelherodev> Nah
<pixelherodev> this is a holdover from yesterday :P
<pixelherodev> I accidentally allnightered, so I crashed during the afternoon
<pixelherodev> Now I nap until ten, then sleep on time tonight, and hopefully get my sleep fixed within two or three days tops
<pixelherodev> Can't have sleep[ing issues] interfering with Zig, after all ;)
dermetfan has joined #zig
<Snektron> Doubt
<ikskuh> (X)
marnix has joined #zig
trevarj has joined #zig
trevarj has left #zig [#zig]
bsrd has quit [Quit: WeeChat 2.9]
<alexnask[m]> ifreund: Cool, this is basically what I did too but I will build on this code
<ifreund> alexnask[m]: yeah, my goal was to get it PR'd as soon as possible so we could both move forward without further conflicts
<ifreund> it's nothing too groundbreaking really :D
<ifreund> will conflict with pixelherodev's elf 16 PR though
<alexnask[m]> Meh what can you do we will have to rebase multiple times for various changes anyway I think :P
<ifreund> such is life :D
<ifreund> there's also a fair amount of elf-specific stuff referenced in Module.zig
<DarkUranium> Meh, I think that orcs & tieflings are far more interesting than elves!
<alexnask[m]> what about coffs? /s
<daurnimator> we do need to support ORC actually
<daurnimator> also you missed the more obvious play on words that is DWARF
<DarkUranium> daurnimator, but DWARF already exists.
<DarkUranium> Already, actually exists.
<DarkUranium> Neat.
stalli has quit [Ping timeout: 240 seconds]
<daurnimator> make sure you read the Etymology section
<ikskuh> nice
<ifreund> heh
Ashpool_ has joined #zig
<Ristovski> this is interesting. When using cimguis `c.igText("%.3f", io.*.Framerate);` the value is always zero, however if I print it with std.debug.print it works just fine
<Ristovski> or rather, it doesn't update
Ashpool__ has quit [Ping timeout: 264 seconds]
<ikskuh> s Framerate a f64 or f32?
<ikskuh> maybe you need to expand it to f64 first?
<Ristovski> I think it's f32
<alexnask[m]> Doesnt `%f` apply to both float and double? (at least in stdio). Though idk how the printf/w.e. implementation figures out what it is
<Ristovski> oh wait, ikskuh you are right
<Ristovski> @as(f64, io.*.Framerate) works
<ikskuh> congratulation, Ristovski. you discovered a bug!
<ikskuh> codegen bug even
<Ristovski> @as(f64, io.*.Framerate) works
<Ristovski> whoops
<ikskuh> alexnask[m]: "..." is enforcing widing types from … to int or double
<ikskuh> except when the type is larger
<alexnask[m]> huh, TIL
<ikskuh> "%f" only takes doubles, when you pass a float, it gets widened
<ikskuh> same mistake is in the lite-c compilre btw
<ikskuh> that's how i knew it could be this :D
<ikskuh> i ran into the same trap a long time ago
<Ristovski> Oh, TIL as well
<ikskuh> i don't know the exact rules, but passing stuff into a C "..." has special rules
<alexnask[m]> Yeah looks like "default argument promotions" happen for varargs (integer promotions + float -> double)
<alexnask[m]> (was wondering if it was implementation defined or smth but no, these promotions happen when no prototype is present and for varargs)
<ikskuh> yay
<ikskuh> C is nice.
<ikskuh> :D
<Ristovski> hmm, interesting, when doing c.printf("%f", 3.0) I get "TODO: support C ABI for more targets" even tho "pointers, integers, floats, bools, and enums work on all targets"
<Ristovski> happens with an integer as well
<ikskuh> yep
<ikskuh> that's because you're passing a comptime_float and comptime_int
<Ristovski> ah, that makes sense
bsrd has joined #zig
xackus_ has joined #zig
<Ristovski> Hmm, how hard would it be to make std.debug.print pretty print structs for example? (pretty print == format them across multiple lines, with indentation)
<Ristovski> I should clarify - C structs
<daurnimator> Ristovski: does it not already?
<alexnask[m]> Does std.fmt do pretty printing? I thought it just printed all in one line
<Ristovski> alexnask[m]: It prints all in one line
<Ristovski> Hmm, this could actually be done if I could somehow loop over the C struct members
<alexnask[m]> I guess there could be a format specifier to do it but honestly I would just write a mixin that provides a pretty printing format fn
<Ristovski> oh hmm
<alexnask[m]> This can definitely be improved
<Ristovski> alexnask[m]: oh wow!
<Ristovski> alexnask[m]: how could this be made to work with structs returned from C?
<alexnask[m]> Ah, if you dont have control over the definition of the struct right? Let me write it up it should be relatively simple :)
<Ristovski> Yeah, exactly
<Ristovski> I've been scratching my head over this today
<alexnask[m]> Here you go: https://zig.godbolt.org/z/Gx4bdY
trevarj has joined #zig
<alexnask[m]> (thiss assumes you are passing by value to prettyPrint, it could check if its a pointer and use that as well but I was lazy :P)
trevarj has left #zig [#zig]
<Ristovski> alexnask[m]: this is great! cheers
<Ristovski> Aaah, I see now
Ashpool_ is now known as Ashpool
euandreh has joined #zig
craigo has joined #zig
pangey has joined #zig
dermetfan has quit [Ping timeout: 260 seconds]
<pixelherodev> ifreund: whatcha doi g thaf conflicts with the ELF PR?
<pixelherodev> gah sorry, mobile kbd
rzezeski has joined #zig
<ifreund> shouldn't be too annoying to resolve either way
<pixelherodev> If it is, it's my own fault for not getting mine in sooner
<ifreund> why can I not find anything about wasm32 vs wasm64 in the spec
<pixelherodev> Because the spec sucks?
<ifreund> either that or I'm missing something
<ifreund> ah, it seems that wasm64 may not actually be a thing yet
<ifreund> which would make sense as the spec uses 32 bit addresses everywhere
dermetfan has joined #zig
<pixelherodev> Ah right, I actually knew that ifreund
<pixelherodev> Because when I was SPU II backending early on, I triggered a "WASM64 is not yet supported" because it thought spu_ii == wasm64 for a bit lol
<ifreund> lol
pmwhite has joined #zig
waleee-cl has joined #zig
riba has joined #zig
wootehfoot has joined #zig
riba has quit [Ping timeout: 240 seconds]
<pixelherodev> ifreund: nice work!
<pixelherodev> (5974)
<ifreund> thanks, I just did what seemed to need doing :)
<pixelherodev> That's what we've all been doing :)
mattmurr has joined #zig
<ifreund> well, looks like there's no way to access globals in wasm with indirection
<ifreund> guess only functions will be incrementally complied
<fengb> wasm64 doesn’t exist
<ifreund> fengb: well, there is this now: https://github.com/WebAssembly/memory64
<fengb> I need to keep up with proposals
cole-h has joined #zig
<ifreund> man LEB128 being variable length massively screws with incremental compilation
<pixelherodev> LEB?
<pixelherodev> wasm thing?
<ifreund> encoding for all the values: https://en.wikipedia.org/wiki/LEB128
<ifreund> not just wasm, also used for dwarf
<pixelherodev> Gotcha
zigusr has joined #zig
<zigusr> hmm, any good example for zig library with C API ?
<pixelherodev> Exported C API?
<pixelherodev> Not that I"m aware of
<pixelherodev> I'm working on one currently, but it's not finished, and won't be published for a while
<zigusr> yeah, I need some reference material :0
dermetfan has quit [Ping timeout: 260 seconds]
<ifreund> ok, I read the LEB128 spec more carefully and it looks like I can do the encoding in such a way that the max size is always used
<ifreund> it's gonna waste some bytes, but this is not for release builds :D
<pixelherodev> Check how DWARF is doing it!
<pixelherodev> We use DWARF now ;)
<pixelherodev> Andrew added that a few days ago
<ifreund> I don't think the current dwarf support in stage2 writes any LEB128 values yet
<pixelherodev> Ah, okay
<pixelherodev> Then Andrew will have to check how *you* do it ;)
<andrewrk> ifreund, oh let me push this function that I added :)
<ifreund> oh did you just implement writeULEB128Fixed()?
<ifreund> that's what I was doing :P
<ifreund> perfect
<andrewrk> love that we had the same exact idea :D
<fengb> tfw you have the same idea as god >_>
<companion_cube> personality cult is bad, fengb ;)
<ifreund> feels good man
<pixelherodev> companion_cube: depends on the personality
CodeSpelunker has joined #zig
<companion_cube> nah
<ifreund> idk, cults are usually a bad thing regarless
<leeward> pixelherodev: It really doesn't.
<pixelherodev> companion_cube: plus, it's less a personality cult, and more a code cult?
<andrewrk> I'm with companion_cube
<pixelherodev> "LoOk AT ThE COdE QuaLItY!!"
<companion_cube> I was just reacting to "god" :)
<pixelherodev> :P
<ifreund> they tend to involve loss of free thought and mindless action
<companion_cube> (no offense andrewrk ;))
<pixelherodev> yeah I'm messing around lol
<Snektron> andrewrk, did you happen to have any further thoughts about implcit single->many pointer?
<andrewrk> Snektron, I haven't put any more thought into it yet
<Snektron> In the mean time i've just written a small asManyPtr function which works quite well
<andrewrk> this will probably get demoted from a PR to an open issue proposal (linked to the closed PR)
<pixelherodev> andrewrk: I split the PRs :)
<pixelherodev> PR -> three PRs :)
<andrewrk> Snektron, often it's easier to do design work together with design work, e.g. multiple days in a row thinking about big picture stuff
<Snektron> Sure. Just made it as a pr since the implementation wasn't much work, but i probably should have made an issue first
<andrewrk> it's no problem
<pixelherodev> Finally compiling LLVM + Clang on my laptop :(
<pixelherodev> I need a C language server for a different project
<andrewrk> pixelherodev, nice, will have a look today
<andrewrk> I also need to do LLVM11 upgrade stream, part 2
<pixelherodev> Thanks :)
moo has joined #zig
metabulation has joined #zig
wootehfoot has quit [Ping timeout: 256 seconds]
moo has quit [Ping timeout: 260 seconds]
dddddd has quit [Ping timeout: 260 seconds]
wootehfoot has joined #zig
metabulation has quit [Ping timeout: 260 seconds]
wootehfoot has quit [Read error: Connection reset by peer]
dddddd has joined #zig
nycex has joined #zig
<zigusr> anybody has good example for libs written in zig with C API exposed?
<leeward> zigusr: something like https://www.nmichaels.org/zig/c-library.html ?
<leeward> It has extra stuff for combining the Zig code with C code, but `export fn add(a: i32, b: i32) i32 {` does that.
<zigusr> nop, that's too toy like
<zigusr> that part i figured myself in a few minutes
halbeno has joined #zig
<leeward> What problems are you running into?
halbeno_ has quit [Ping timeout: 244 seconds]
cole-h has quit [Quit: Goodbye]
<pixelherodev> PR Sunday?
<pixelherodev> "Three PRs merged for the price of one!"
<alexnask[m]> :)
<leeward> Better than 1 for the price of 3.
<pixelherodev> I'm thinking that in the Billie Maise voice (if I spelled that right)
<leeward> Billy Mays?
<pixelherodev> prob
<leeward> With the ads for OxiClean?
<pixelherodev> *all* the ads
<leeward> Congratulations, you've been probationally removed from The List.
<pixelherodev> lol
<leeward> Use of hyperbole is not allowed for members of the pedantic society.
<zigusr> leeward: that I don't know the language behaviour yet :)
<pixelherodev> leeward: technically it is
<zigusr> I like to see examples
<zigusr> yeah, I was hoping people are doing stuff with zig/C interop yet outside of the compiler :)
<leeward> zigusr: Well, I have 1 nontrivial Zig module that's part of a C library: https://github.com/nmichaels/smear/blob/zig/src/cancelq/cancellable.zig
<leeward> pixelherodev: That may have been a record for shortest time spent off the list.
<zigusr> cool !, I'm lookign for examples how to pass an zig state struct into C as a void*
<ifreund> oh so interfacing with a C lib from zig? I do a ton of that in river
<zigusr> no, interfacing zig code as a C lib
<fengb> Oh the opposite
<leeward> Yeah, that's a bit less common.
<pixelherodev> leeward: that was very deliberate ;)
<leeward> pixelherodev: I had guessed.
<fengb> Bearssl has some callbacks that comes back to Zig
<ifreund> well, if you pass an extern struct from zig, then it's just like any other C struct from C
<leeward> I suspect the reason is that people willing to learn and write Zig code would rather write Zig code.
<gruebite> yeah
<Nypsie[m]> zigusr: Vexu exposes his scripting language as a C lib also: https://github.com/Vexu/bog
<ifreund> accesing fields of a non-extern zig struct from C would be UB
<gruebite> but i also see a benefit to writing zig and exposing it as C
<pixelherodev> Vexu wrote a scripting language? Neat
<leeward> zigusr: You might want to look into @Type(.Opaque).
<leeward> gruebite: Tons of benefit, it's just that the corpus of Zig code isn't that big yet and it tends to be focused on writing Zig instead of writing C libraries in Zig.
<zigusr> I want to convert some cython code I have to zig
<alexnask[m]> Yeah bog looks pretty good Ill def use it if I ever need a smal lscripting thing in a zig program
<gruebite> yeah
<gruebite> zig ecosystem could grow more
<gruebite> i'm making stuff :)
<leeward> Well, the language isn't even stable yet. It's early days.
<gruebite> yeah
<pixelherodev> andrewrk: that PR does three things: debug.warn -> debug.print; removes a redundant parameter from runOneCase; refactors runOneCase's Execution branch to not try running tests natively when cross-compiling
<gruebite> for me i'm already seeing huge benefits using zig, so the instability is a tradeoff i'm accepting
<ifreund> same, zig makes things a lot nicer
<pixelherodev> Most of us agree :)
<leeward> selection bias being what it is
<pixelherodev> Exactly
<pixelherodev> wouldn't be here if we didn't
<pixelherodev> Wouldn't be active at least
<pixelherodev> I lurk in channels of stuff I don't use :P
<gruebite> hahaha same
<pixelherodev> If I find it interesting enough
<andrewrk> ifreund, I'll push my ULEB128 commit
<zigusr> how does zig lang compare to v lang ? :0
<ifreund> andrewrk: cool, I already pulled and rebased onto it so it's not really blocking me atm
CodeSpelunker has quit [Quit: CodeSpelunker]
<andrewrk> ok cool
<andrewrk> ifreund, I like how git lets you cherry pick a commit like that, and then later when you rebase it will just delete it :)
<leeward> "$2 = <optimized out>" :(
<ifreund> yeah git is really awesome
<andrewrk> leeward, in stage2 that would be a bug in zig code instead of llvm code :)
<leeward> andrewrk: \o/
<leeward> I said -O0, dammit!
<ifreund> what is currently blocking me is the design work around making wasm incremental compilation work well, but I'm slowly figuring things out
<andrewrk> ifreund, it took me several days of not coding and scribbling in notebooks to figure out how to do incremental compilation for ELF, so take your time :)
<ifreund> binary size is not going to be anywhere near optimal for incrementally compiled debug builds though
<andrewrk> of course, that's to be expected
<andrewrk> consider that the work flow for someone using incremental compilation debug builds is testing on their own computer
<ifreund> yeah
<gruebite> will incremental builds be optional?
<ifreund> I'm going to be putting a fair amount of padding in the file too in order to avoid copying sections around all the time
<leeward> They should be turned off with --release-*
<pixelherodev> Should be optional for debug too IMO
<pixelherodev> `--no-incremental` or something
<andrewrk> it's possible. I won't promise it, but likely the code needed for --release* builds to work could be reused for non-incremental debug builds as well
<andrewrk> ifreund, makes sense. I'm about to do the same with the line number program debug info
<pixelherodev> Or we could rename debug -> development and release-safe -> release-debug ?
<gruebite> might be a lot to support. what's the usecase for --no-incremental during debug builds?
<andrewrk> ifreund, did you see that btw? :D https://github.com/ziglang/zig/issues/5963
<pixelherodev> It'd be pretty trivial probably
<pixelherodev> gruebite: cross-compilation is one example
<pixelherodev> Or freestanding code
<gruebite> ahh yeah
<pixelherodev> I can see it being useful, but I can also see it being annoying
<pixelherodev> Going to take the ELF PR a bit further
<andrewrk> cross compilation isn't an example because incremental compilation and cross compilation work fine together
<pixelherodev> Merging File.{ELF,C}.allocator into File.allocator
<leeward> release-safe doesn't imply debug symbols
<pixelherodev> andrewrk: yes, but you might not *want* it, even if it *works*
<leeward> and I really want my release builds that will still crash but are optimized.
<pixelherodev> I think release-debug makes sense
<pixelherodev> Potentially as an *additional* build mode
<leeward> Those two things are different. It's either release or debug.
<pixelherodev> release-safe: no debug symbols, optimized, safety checks
<leeward> Unless you're debugging in prod.
<pixelherodev> release-debug: debug symbols, optimized, safety checks
<pixelherodev> Maybe we should replace release *modes* with release *specifiers*
<fengb> Maybe split the mode like we did CPU features
<leeward> I wouldn't mind a release-small-safe, but safe and small are opposed goals so it won't bother me too much if we don't get it.
<Sahnvour> ideally we'd split the mode into debug features enabled or not
<ifreund> andrewrk: I did give it a read and it helped me get in the right mode of thought for this design work, but wasm is different enough that it's not really applicable
<andrewrk> leeward, we have `--release-safe --strip` for non-debuggable safe release builds
<pixelherodev> DOsOf => debug symbols, optimized for speed and size, no safety checks
<pixelherodev> OfS => optimized for speed, no debug symbols, safety checks
<pixelherodev> etc
<leeward> I guess that works.
<pixelherodev> (probably a better way to specify it)
<ifreund> does wasm have some concept of debugging symbols like dwarf?
<ifreund> i sure hope not :P
<fengb> They sorta added dwarf
<andrewrk> ifreund, makes sense. hmm maybe look up "source maps"
<andrewrk> it's the same concept
<fengb> I think it’s just a Chrome custom thing atm
<pixelherodev> Most webshit starts as custom Chrome things lol
<andrewrk> ifreund, I've been feeling good about designing by starting with the memory layout. E.g. what fields will be in memory for each Decl, for each Fn, for each File, etc
<zigusr> how do i get libc in windows buidls ?
<pixelherodev> WebSerial, WebUSB, Web*...
<andrewrk> once that all makes sense in your head, it takes a while, but the other pieces will fall into place
<pixelherodev> zigusr: uhhh... -gnu?
<pixelherodev> I think that uses mingw
<fengb> Google wants to push web “standards”
<zigusr> can i use msvcrt ?
<andrewrk> I think this is what "data oriented design" means
<pixelherodev> fengb: yeah, exactly
<alexnask[m]> zigusr: `-lc` will autodetect msvc and link to it
<zigusr> k, tnx
<zigusr> is that documented anywhere?
<leeward> pixelherodev: I think if we break out all the composable bits, the best way to spell it is "--release-safe" means "--safe -Ofast", "--release-fast" means "--unsafe -Ofast --strip", etc.
<fengb> -O2 >_>
<ifreund> andrewrk: Yeah, I've also been working memory-first so far, it makes a lot of sense for this kind of stuff
<pixelherodev> leeward: yeah, exactly
<pixelherodev> fengb: We don't have optimization levels
<pixelherodev> Might be better to use -Ospeed -Osize
<Sahnvour> andrewrk: exactly, know the data and design the processing around it :)
<pixelherodev> To avoid confusion with GCC / Clang one
<pixelherodev> ones*
<pixelherodev> the*
nikita` has joined #zig
<alexnask[m]> zigusr: Not sure if the native libc detection is documented
<leeward> GCC supports -Ofast.
<fengb> Oh it does? That’d match at least
<leeward> -O0 -O1 -O2 -O3 -Os -Ofast -Og
<pixelherodev> leeward: that's why I said -Ospeed instead of -Ofast
<pixelherodev> -Ofast on GCC is a no-no
<pixelherodev> It *trades conformance* for speed
<leeward> Pfft, conformance.
<pixelherodev> --release-fast doesn't do that
<fengb> Oh really?
<pixelherodev> -Ofast includes -ffast-math
<fengb> Wait why would a compiler break conformance?
<leeward> "Disregard strict standards compliance."
<pixelherodev> fengb: performance
<pixelherodev> -Ofast is just that
<pixelherodev> It's *fasT*
<pixelherodev> No matter the cost
<pixelherodev> For a lot of applications, it actually makes sense
<leeward> -ffast-math and -fno-protect-parens
<pixelherodev> Most applications will be fine if float behavior isn't 100% conformant
<leeward> Incorrect results in a quarter the time!
<pixelherodev> ^ exactly
<pixelherodev> But in most cases, nobody really cares
<pixelherodev> 90% of applications can run with -ffast-math
<leeward> Pfft, floats. I don't use those anyway.
<ifreund> hmm, I don't think I'm going to put time into debug info for wasm yet. Nothing is standardized
<andrewrk> that sounds completely reasonable
<pixelherodev> Agreed
<fengb> MVP
<Snektron> <fengb "Wait why would a compiler break "> Well for example strictly x+x is different from 2*x for floats
<Snektron> It yields a different result
<Snektron> Yet those operations might have different performance implications
<leeward> exponent++
<leeward> not always correct
<leeward> ?
<ifreund> pixelherodev: "Note that this also moves allocator and file from File.ELF and File.C into File" You should really put stuff like this in a separate commit tbh
<pixelherodev> I *know*
<pixelherodev> ifreund: I'm splitting commits for test harness PR rn
<andrewrk> pixelherodev, i'd like to focus on just 1 PR from you at a time
<pixelherodev> andrewrk: does it matter to you if I split the ones in ELF as well?
<pixelherodev> That's fine
<andrewrk> gave you an ihex review
<pixelherodev> I saw
<pixelherodev> aerc in another tmux tab, got notified nearly immediately ;)
<andrewrk> if you look at the way the zig project uses ELF, it's a similar situation. we actually duplicate reading/writing ELF things in quite a few places. sometimes it's appropriate to avoid too-high-level abstractions
<andrewrk> the great thing about a frozen spec like ELF or IHEX, is that it becomes more OK to duplicate code that relies on the details of the spec
<andrewrk> of course things like constants can be abstracted at no cost, but others are inherently coupled with the surrounding code
<andrewrk> I'm vetoing the callback thing
<pixelherodev> Gotcha, will update soon
<pixelherodev> Finishing up the test harness split now
<pixelherodev> just running tests to ensure commits are properly self-contained
<andrewrk> ok. I'm looking at your oldest PR only until it is closed or merged before moving on
<pixelherodev> Fair
<pixelherodev> On the bright side, that gives CI time to finish ;pl;
<pixelherodev> lol*
<gruebite> top level constants, lower or uppercase?
<andrewrk> pixelherodev, the art of upstreaming big changes is its own skill, but I promise you it will be worthwhile in your career
<pixelherodev> I know :)
<pixelherodev> Hopefully ZSF gets an anonymous billionaire sponsor and Zig *becomes* that career ;P
<andrewrk> ok your oldest PR is now ihex. your move :)
<pixelherodev> andrewrk: any issues with just removing the callback and having it return the data structure?
<pixelherodev> That makes the most sense to me
<pixelherodev> `while (true) { record = parse(); // use record }` instead of `while true { parse(handleRecord); }`
<pixelherodev> (removing the loop from within `parse`)
<andrewrk> idk, that PR kinda seems out of place to me. I suggest to close it for now and focus on one of the other two
<pixelherodev> Sure
<pixelherodev> Makes sense
<pixelherodev> That makes ELF the oldest I think
<pixelherodev> andrewrk: *your* move now ;)
<pixelherodev> If only I could send patches from a non-GitHub repo to Zig :(
<pixelherodev> that's unrelated though
<andrewrk> damn it looks like we're even going to have incremental compilation and debug info for SPU Mk II ? that's pretty slick
Ashpool has quit [Quit: Leaving]
<pixelherodev> Eventually, yes
<andrewrk> pixelherodev, for future reference it really helps to explain when you add big stuff like this address space thing
<pixelherodev> For sure, yeah
<pixelherodev> i'll make sure to do that in the future
<pixelherodev> Note that debug info will require an emulator that understands it
<pixelherodev> But there's no reason I couldn't do that for my Tricarbon JIT for instance
<pixelherodev> On that note, need to work on my backend rewrite :)
<pixelherodev> I'll wait for PR comments before proceeding probably
factormystic has quit [Read error: Connection reset by peer]
* pixelherodev facepalms
<pixelherodev> Thought I'd closed it
<pixelherodev> andrewrk: okay, your turn :)
* pixelherodev facepalms
<pixelherodev> I closed the wrong one
<alexnask[m]> lol
nvmd has quit [Quit: Later nerds.]
dermetfan has joined #zig
<pixelherodev> Okay, my turn again :)
<andrewrk> now it's my turn to code :)
<Snektron> Pair programming?
<andrewrk> no, I was just spending a few hours doing code reviews
<pixelherodev> :P
<andrewrk> that was my gentle way of saying, "I'm going to ignore you for a few hours"
<pixelherodev> Don't worry, I'll ignore you too!
factormystic has joined #zig
<pixelherodev> Biggest use case for CBE focus: it'd allow for easily using the Zig test suite system with C code easily
<pixelherodev> and there's not a single good C test system
<pixelherodev> Whoa!
<pixelherodev> Kristall properly highlights code in HTML??
<leeward> pixelherodev: I don't know about there not being a single good C test system. That's a difficult claim to prove.
stripedpajamas has joined #zig
<ifreund> absolute claims generally are :D
<leeward> Feels like the setup for the xkcd about standards.
<pixelherodev> I mean... yeah?
FireFox317 has quit [Ping timeout: 246 seconds]
<companion_cube> is spu mk2 a real thing? can you get a board for it?!
<ifreund> companion_cube: see https://ashet.computer/
adamkowalski has joined #zig
<alexnask[m]> xq makes a physical one yes
<adamkowalski> if you have an ArrayList(bool) will the bits be packed? Or will each element still take 1 byte
<alexnask[m]> It will not be packed
<adamkowalski> dang
<adamkowalski> is there a reason for that?
<Snektron> Efficiency
<pixelherodev> Implementation is generic
<Snektron> Theres std.PackedIntArray
<adamkowalski> Can you elaborate on that Snektron
<pixelherodev> ArrayList doesn't special-case any types
<pixelherodev> Well, it adds writer / reader for u8 :
<pixelherodev> ;P
<adamkowalski> it doesn't seem intuitive to me
<alexnask[m]> vector<bool> was a great idea /s
<Snektron> Loading a single bit costs a load, shift and mask
<adamkowalski> Vector bool was a problem because of references
<Snektron> While loading a byte thats either 0 or 1 requires just a load
<Snektron> And maybe a sign extent
<adamkowalski> I don't want to deal with single elements though
<adamkowalski> thats the point of storing it in a vector
<adamkowalski> data oriented design and all that
<Snektron> Furthermore, i believe arrays have C abi
<adamkowalski> you should operate on vectors at a time, never with single elements. And process the array in it's entirety
<Snektron> Although im not sure what a zig bool translates to in C
<adamkowalski> preferably loading into simd registers and do operations on a vector lane at a time
<alexnask[m]> Iterating through an ArrayList is very common. Some kind of PackedArrayList would be good to have though
<ifreund> adamkowalski: well, zig can do that too. See std.meta.Vector
<ifreund> (for simd)
<Snektron> Are referring to std::vector or std.meta.Vector/@Vector?
marnix has quit [Ping timeout: 256 seconds]
<leeward> std.ArrayList is not the same as std.meta.Vector.
nikita` has quit [Quit: leaving]
<alexnask[m]> I dont think anyone suggested its the same? :P
<alexnask[m]> Also, Alex Stepanov, why?
<Snektron> I got kinda confused when adamkowalski went from vector<bool> to simd
<Sahnvour> alexnask[m]: nobody's perfect :)
KKRT has quit [Quit: KKRT]
ur5us has joined #zig
dermetfan has quit [Ping timeout: 256 seconds]
<ronsor> I'm wondering. Is it possible to use suspend/resume to implement a sort of user-space cooperative threading system?
<pixelherodev> I think so?
<pixelherodev> I think protty did that, right?
<pixelherodev> `zap` IIRC
<pixelherodev> Works both cooperative and preemptive IIRC
<ronsor> zap? Is it on GitHub?
<ronsor> interesting
wicd has joined #zig
xackus_ has quit [Ping timeout: 246 seconds]
adamkowalski has quit [Ping timeout: 256 seconds]
stripedpajamas has quit [Quit: sleeping...]
adamkowalski has joined #zig
<gruebite> so i haven't touched too much on zig's async await. it doesn't look like it offers actual threading but a mechanism to do it?
<fengb> It’s just fancy coroutines
<gruebite> yeah exactly
<gruebite> i love coroutines though
<fengb> You can apply a thread work pool to it
FireFox317 has joined #zig
<fengb> The builtin event loop mechanism sets up worker threads = cores iirc
<gruebite> so it facilitates threading
adamkowalski has quit [Ping timeout: 246 seconds]
<fengb> But that’s optional. It’s primarily designed for handling async io style work
mikdusan has joined #zig
<fengb> Not just io, but stuff that would be handled similarly to event loops in other languages
cole-h has joined #zig
<pixelherodev> hmm
<pixelherodev> does it make sense to make e.g. linksection a builtin?
<pixelherodev> instead of `const foo linksection() = blah;`, `const foo @linksection() = blah;`?
<pixelherodev> ... nah, probably not.
ifreund has quit [Read error: Connection reset by peer]
ifreund has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
FireFox317 has quit [Ping timeout: 260 seconds]
_whitelogger has joined #zig
<andrewrk> ooh, found a nice use case for pwritev
adamkowalski has joined #zig
<andrewrk> oh, damn it, I keep thinking it lets you put multiple offsets
<Snektron> pixelherodev, i was thinking whether its better to have an `attribute` builtin
<Snektron> Would probably be close to what eleanor-nb proposed, but the basic idea is to group stuff like packed, extern (?), linksection, etc
<Snektron> With idea that a hypothetical glsl/spir backend needs a few more attributes
adamkowalski has quit [Ping timeout: 240 seconds]
<Snektron> Example: fn a() attribute(.{.callconv = .C, .linksection = .text}) void
<Snektron> extern vertex: Vec2F attribute(.{.binding = 1});
<Snektron> Just a thought really, but it seems keyword pollution to introduce those things for shaders, especially since there are quite a lot of options
<andrewrk> I could see that making sense
<Snektron> Plus, there might be other architectures which require specific attributes... This way, they can be added without breaking problems