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/
joey152 has joined #zig
ur5us has quit [Ping timeout: 256 seconds]
ur5us has joined #zig
daex has quit [Ping timeout: 256 seconds]
daex_ has joined #zig
squeek502_ has joined #zig
Nilium_ has joined #zig
betawaffle has quit [Ping timeout: 268 seconds]
Nilium has quit [Ping timeout: 240 seconds]
squeek_ has quit [Ping timeout: 240 seconds]
andrewrk has quit [Ping timeout: 240 seconds]
cow-orker has quit [Ping timeout: 240 seconds]
nickster has quit [Ping timeout: 240 seconds]
Nilium_ is now known as Nilium
andrewrk has joined #zig
<jjido> mikdusan I don't like IEC/IEEE decimal numbers anyway. Why allow denormalised representations?
<jjido> "representations that have the same numerical value but different quantum exponents, e.g., (1, 10, −1) representing 1.0 and (1, 100, −2) representing 1.00, are distinguishable."
<jjido> crazy
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nickster has joined #zig
_whitelogger has joined #zig
shakesoda has quit [Quit: Connection closed for inactivity]
_Vi has quit [Ping timeout: 240 seconds]
ur5us has quit [Ping timeout: 256 seconds]
shakesoda has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
AndroidKitKat has quit [Remote host closed the connection]
AndroidKitKat has joined #zig
MajorLag has joined #zig
mikdusan1 has joined #zig
Snetry- has joined #zig
daex has joined #zig
andrewrk has quit [*.net *.split]
daex_ has quit [*.net *.split]
tgschultz has quit [*.net *.split]
mikdusan has quit [*.net *.split]
Snetry has quit [*.net *.split]
MajorLag is now known as tgschultz
dddddd has quit [Ping timeout: 256 seconds]
andrewrk has joined #zig
daex has quit [Ping timeout: 265 seconds]
daex has joined #zig
_whitelogger has joined #zig
<daurnimator> fengb: heh. I just andrewrk's fixup commit.... I was going to make some of those same changes
<fengb> Great minds think alike :)
<diginet> jjido: the alternative to not allowing them is far worse and more complicated
joey152 has quit [Remote host closed the connection]
rappet has quit [Ping timeout: 272 seconds]
rappet has joined #zig
_whitelogger has joined #zig
frett27_ has joined #zig
frett27 has quit [Ping timeout: 240 seconds]
marmotini_ has joined #zig
ur5us has joined #zig
marmotini_ has quit [Remote host closed the connection]
Kingsquee has joined #zig
_whitelogger has joined #zig
<Kingsquee> so I'm looking over the zig documentation, and it says that casting a signed number to unsigned int is UB
<daurnimator> Kingsquee: where?
<daurnimator> Kingsquee: with @intCast: yes: you're promising that the number fits in the destination
<Kingsquee> oh, can I @yoloCast or something?
<daurnimator> Kingsquee: e.g. you might have a i64, but you *know* its only between 10 and 4000: you would @intCast it to a u12
<daurnimator> Kingsquee: you might be looking for @bitCast for going between unsigned and signed?
<daurnimator> that lets you e.g. go between a isize and a usize
<Kingsquee> I see there's also @as
<daurnimator> Kingsquee: @as only lets you go... "bigger" e.g. `@as(u64, my_u32)` works, `@as(u32, my_u64)` is a compile error
<Kingsquee> so many casts
<Kingsquee> a cast-astropy
<daurnimator> Kingsquee: @intCast is a pinky-promise that you can fit into the destination
<daurnimator> Kingsquee: if you're not sure if you can fit into the destination, see @truncate
<daurnimator> Kingsquee: explicit over implicit
<Kingsquee> this is interesting since I never thought about this stuff being implicit
<Kingsquee> and yet it be
<Kingsquee> @daurnimator @bitCast looks like what I was expecting, yep
<Kingsquee> thanks
<daurnimator> Kingsquee: and FYI, @bitCast will compile error if the types are not exactly the same size.
<Kingsquee> yeah, I saw
<Kingsquee> same dealio as rust's mem::transmute<T>(x)
<Kingsquee> this language looks pretty nice
<Kingsquee> the smooth jazz that is anyerror feels almost sinful after coming from rust
<daurnimator> Kingsquee: welcome :) what sort of things do you work on?
<Kingsquee> i make bideo game
slurpie has quit [Ping timeout: 258 seconds]
<Kingsquee> I've been trying to do a thing with fixedpoint numbers in rust but the language's lack of compiletime numbers in generics has limited my shenanigans
<daurnimator> What's on the menu Kingsquee?
<Kingsquee> so productivity hasn't been all that great but I really didn't want to go back to C++
<Kingsquee> and then Zig ((holylight))
<Kingsquee> so I'm playing around with it despite its apparent infancy
<daurnimator> you didn't follow the script! :( https://youtu.be/U_JbTHp6uzI?t=4
<Kingsquee> these memes cannot contain a force as strong as I
jjido_ has joined #zig
<jjido_> diginet: as far as I can tell all that denormalised do is defer the normalisation until the time you need to compare two numbers.
frett27 has joined #zig
frett27_ has quit [Ping timeout: 258 seconds]
<Kingsquee> man...this looks so much more comfy to use
<Kingsquee> the fact I could just write normal code for generics is beautiful
<Kingsquee> this is the kind of crap I'm dealing with atm https://pastebin.com/raw/2hv1NSKL
<Kingsquee> basically type-level register finagling
frett27_ has joined #zig
<Kingsquee> is zig actually practically usable in its current state?
<Kingsquee> or are we regularly playing compiler bug whack-a-mole
TheLemonMan has joined #zig
<daurnimator> Kingsquee: you will hit compiler bugs.... but its usually when you have buggy code
<Kingsquee> fair
frett27 has quit [Ping timeout: 256 seconds]
<daurnimator> Kingsquee: which is to say: *most* compiler bugs tend to be when the zig compiler makes assumptions that your code is well-formed: when your code is bad, zig goes off and crashes in weird and wonderful ways
<Kingsquee> hmmm
<daurnimator> they're getting less and less frequent though :)
<Kingsquee> that kind of assumption feels iffy though
<daurnimator> Kingsquee: essentially missing validation in various stages of the compiler that later stages assume to have occured
<Kingsquee> whats the turnaround time on fixes like?
<Kingsquee> and/or how hard is it to fix things
<daurnimator> anywhere from 10 minutes to 6 months? ;)
<Kingsquee> . _.
<daurnimator> (depends on how hard it is to fix it; and who is around with the relevant skills+interests)
<Kingsquee> what kind of stuff are you working on with zig?
<daurnimator> good question. I think I've managed to get too absorbed into zig itself and have barely worked on anything *in* zig... instead have been working on zig itself
<Kingsquee> the hero we need, not the one we deserve
<daurnimator> I should actually go back and finish some projects
<Kingsquee> what were you working on?
<Kingsquee> also I should ask, how's jai's compile time doing
<Kingsquee> er, zig
<daurnimator> one project was a decentralised messaging protocol
<Kingsquee> (they're kinda occupying the same region in my brain)
<daurnimator> compile time is mostly waiting for LLVM itself: we have plans to one day write our own assembler so we don't have to wait on LLVM; but that's pretty far off
ur5us has quit [Ping timeout: 256 seconds]
<Kingsquee> not hitting any massive slowdowns with evaluation of comptime stuff?
<daurnimator> comptime is not fast.... but I think only a couple of people have actually hit real slow paths
<daurnimator> we have plans to optimise it in future: in theory it shouldn't be any slower than, say, cpython; but bug fixing and language changes take priority
<Kingsquee> yeah, the issue I see hit in rust occasionally is type recursion and non-obvious compiletime increases from certain comptime programming patterns
<Kingsquee> have to do weird workarounds like "don't assign to (the rust equivalent of) a comptime variable before returning it, just return the expression immediately"
daex has quit [Ping timeout: 260 seconds]
daex_ has joined #zig
<Snektron> <Kingsquee "I've been trying to do a thing w"> Arent there const generics by now?
<Kingsquee> no, we have typenum
<Kingsquee> monstrous beauty that it is
<Snektron> Huh
<Snektron> Weird, i thought they hit stable already
<Snektron> I see
<Snektron> Rust development is so slow
<Kingsquee> that's becoming my main beef with it yes
<Kingsquee> I've been patient but it's getting insane
<TheLemonMan> it takes time to get things right
<daurnimator> rust and I had irreconcilable differences around that fact that memory is not infinite
<TheLemonMan> when you are past the 1.0 you cannot throw shit to the wall and see what sticks
<Snektron> Thats true
<Kingsquee> daurnimator: explain
<TheLemonMan> rust panics on OOM
<Kingsquee> hot take: in any situation you'd possibly panic on OOM, you should be preallocating your own heap and writing your own allocators
<daurnimator> Kingsquee: https://github.com/rust-lang/rfcs/pull/2116 is as good a point to start as any; its quite the rabbit hole
<Kingsquee> *possibly not panic
<daurnimator> Kingsquee: correct answer: panic is unrecoverable. never panic on OOM.
<Kingsquee> catch_unwind?
<Kingsquee> like, what are you going to do if you have no more memory, call an x86 intrinsic to pray to the gods
<daurnimator> i.e. "unable to allocator memory" must be an error returned/thrown by functions. i.e. functions that allocate need to have a way to signal errors
<Snektron> <Kingsquee "hot take: in any situation you'd"> I think using your own allocator is not very useful in rust, since you can only have one allocator really
<Kingsquee> daurnimator: fair enough
<Kingsquee> I actually tried this with writing my own containers, but didn't find it very useful
<daurnimator> Kingsquee: try using zig ones, we do it right :)
<Kingsquee> and the OOM error handling everywhere was pretty fugly
<TheLemonMan> stackable allocators are quite nice
<Kingsquee> Snektron: custom global allocator allocating custom allocators allocating custom containers allocating PODs
<Kingsquee> it's the only way to be sure
<Snektron> Aaaa
<Kingsquee> ^ -^
<Kingsquee> reading about zig's allocators now
<Kingsquee> this is...actually quite thoughtful
<daurnimator> Kingsquee: its more that anything that needs an allocator *must* take an allocator as an argument (or at least during object creation)
<Kingsquee> yeah, rust's hidden allocation always bugged me
<Kingsquee> https://ziglang.org/documentation/master/#Choosing-an-Allocator why is there a difference between `arena` and `allocator` here
daex_ has quit [Ping timeout: 240 seconds]
<TheLemonMan> arena is an allocator as it implements the Allocator trait
<TheLemonMan> `allocator` is the interface implementation
<Kingsquee> that seems unusual
daex has joined #zig
<daurnimator> ?
<Kingsquee> I'd expect arena to be the allocator with the interface implementation
<Kingsquee> arena.create(i32)
<TheLemonMan> the whole interface story is not completely fleshed out yet, check out #130 for more details
<Kingsquee> hmmmm
lunamn has quit [Quit: Ping timeout (120 seconds)]
lunamn has joined #zig
<Kingsquee> wait, I thought zig was self hosted
<Kingsquee> /src is full of .cpps 8V
<Kingsquee> RUSED 8V
<Kingsquee> gotcha
<daurnimator> Kingsquee: not yet. and /src-self-hosted is where the self-hosted implementation is
daex has quit [Ping timeout: 258 seconds]
<daurnimator> Kingsquee: see also https://github.com/ziglang/zig/issues/853
<TheLemonMan> that comment is slightly stale, bytesToSlice was removed last week
daex has joined #zig
<frett27_> seems the std.io.getStdout().outstream().print function is broken on the head ?
<frett27_> is it linked to buffer introduction ?
<daurnimator> frett27_: hmm? got an example?
<daurnimator> frett27_: .outStream() was only really introduced last night...
<frett27_> here : Semantic Analysis [803/1039] /home/use/zig/lib/std/fmt.zig:329:32: error: expected 6 arguments, found 4
<frett27_> return try value.format(fmt, options, out_stream);
<frett27_> ^
<frett27_> try formatType(
<frett27_> ^
<frett27_> in just a line : (using)
<frett27_> try std.io.getStdOut().outStream().print("{}\n", .{dev});
<daurnimator> frett27_: did you implement your own .format() method? the trait signature changed.
<frett27_> no, i tried to compile the svd2zig project
<frett27_> for embedded
<daurnimator> frett27_: please file a bug with svd2zig to use the new .format() interface
<frett27_> thnx so much, i'll adjust the code and make a pull request
daex has quit [Ping timeout: 265 seconds]
<daurnimator> Kingsquee: as you may notice: things can move pretty quickly round here :)
daex has joined #zig
<Kingsquee> daurnimator: as long as I can move pretty quickly as well, that might be amenable
<daurnimator> Kingsquee: if not, you can always still to the releases. Though you're likely to hit a bug that we only fix in master.
<daurnimator> s/still/stick/
<Kingsquee> eeh I tried that back when rust was beta
<Kingsquee> there's a balance to it
_Vi has joined #zig
betawaffle has joined #zig
daex_ has joined #zig
daex has quit [Ping timeout: 268 seconds]
<frett27_> daurminator: thnx, made the pull request, it works fine : https://github.com/vegecode/svd2zig/pull/6
jjido_ is now known as jjido
jjido has quit [Quit: Textual IRC Client: www.textualapp.com]
jjido has joined #zig
mahmudov has quit [Ping timeout: 256 seconds]
sammich has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
sammich has joined #zig
frmdstryr has joined #zig
tdc has joined #zig
daex_ has quit [Ping timeout: 265 seconds]
daex has joined #zig
<Kingsquee> so I see that there's arbitrary i#/u# integer bit width syntax, that's hella cool
<Kingsquee> but...can *I* do that?
<Kingsquee> or is that builtin
<Kingsquee> it'd be nice to have that same general syntax for fixedpoint
<Kingsquee> ...wait a minute, the language could have fixedpoint built in
<Kingsquee> 8V
<mq32> Kingsquee: the language does not have fixed-point types builtin yet
<Kingsquee> oh no now i will mak compiler and will never mak game
<mq32> but there are proposals for that
<Kingsquee> I would be interested in working on this
<mq32> if you want, you can do that
<mq32> mikdusan wrote a writeup about the compiler, you can find it on his github
<mq32> there is also some other compiler internals docs
<mq32> but i recommend working with the lang first :)
<Kingsquee> ofc
<Kingsquee> I'm just getting excited )))
<Kingsquee> is there an rfc process?
<mq32> we use github issues for tracking proposals
LakeByTheWoods has joined #zig
Patrice_ has joined #zig
FireFox317 has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
frett27_ has quit [Ping timeout: 258 seconds]
tdc has quit [Remote host closed the connection]
tdc has joined #zig
daex_ has joined #zig
daex has quit [Ping timeout: 260 seconds]
daex_ has quit [Ping timeout: 255 seconds]
FireFox317 has quit [Remote host closed the connection]
FireFox317 has joined #zig
daex has joined #zig
daex_ has joined #zig
daex has quit [Ping timeout: 240 seconds]
frett27 has joined #zig
daex_ has quit [Ping timeout: 268 seconds]
LakeByTheWoods has quit [Remote host closed the connection]
slurpie has joined #zig
daex has joined #zig
jessermeyer has joined #zig
daex has quit [Ping timeout: 240 seconds]
mahmudov has joined #zig
daex has joined #zig
daex has quit [Ping timeout: 256 seconds]
daex has joined #zig
slurpie has quit [Ping timeout: 268 seconds]
dddddd has joined #zig
daex has quit [Ping timeout: 256 seconds]
daex has joined #zig
mikdusan1 is now known as mikdusan
daex has quit [Ping timeout: 255 seconds]
mahmudov has quit [Ping timeout: 258 seconds]
daex has joined #zig
marmotini_ has joined #zig
<pixelherodev> ... huh. I just realized why I stopped using email to track Zig issues: I filtered Zig emails into a different folder and then forget about it :(
return0e has quit [Remote host closed the connection]
return0e has joined #zig
<TheLemonMan> andrewrk, ping
daex has quit [Ping timeout: 258 seconds]
daex has joined #zig
SimonN has joined #zig
SimonNa has quit [Ping timeout: 240 seconds]
mahmudov has joined #zig
daex has quit [Ping timeout: 265 seconds]
<pixelherodev> Anyone have Zig syntax highlighting for kak?
<pixelherodev> Ah, found one
<jessermeyer> kakoune?
daex has joined #zig
<jessermeyer> lmao the readme
<pixelherodev> Yeah I know
<pixelherodev> But the highlighter I linked is broken so I need to fix it anyways
daex has quit [Ping timeout: 240 seconds]
<shakesoda> frustrating, keep running into c abi problems trying to build this program on linux
<shakesoda> guess i'm windows only for now
daex has joined #zig
<pixelherodev> What sorta problems?
<shakesoda> #1481
<shakesoda> compiler outright errors when trying to use cimgui functions that take (certain?) struct parameters on x86_64 linux
<shakesoda> https://github.com/ziglang/zig/issues/1481#issuecomment-545990720 <- I'm not the first one to get here for this reason
daex has quit [Ping timeout: 240 seconds]
<shakesoda> not quite a showstopper, but frustrating, I have to modify a bunch of functions to take pointer args instead to workaround whenever I'm up for fixing that build
<jessermeyer> Huh, That reminds me that I had some issues with DX12 COM that I never got to the bottom of. Possibly related.
<jessermeyer> I recall passing a struct with an int offset for a heap descriptor and it would always fail. Worked fine compiling in straight C.
<jessermeyer> Now I'm in Vulkan land, and thankfully the API takes pointers universally from what I can tell.
daex has joined #zig
jjido has joined #zig
<TheLemonMan> eh fuck this shit, I keep stumbing into LLVM bugs
<pixelherodev> I configured kak to auto-zig fmt on idle, not realizing how often that was. I hit enter, it hits backspace :P
waleee-cl has joined #zig
<TheLemonMan> zig fmt is a drug
daex has quit [Ping timeout: 265 seconds]
<pixelherodev> Yeah
<pixelherodev> I upped the idle timeout a bit and now it's perfect
<pixelherodev> Auto-formats nearly the instant I stop typing :)
slurpie has joined #zig
daex has joined #zig
mahmudov has quit [Ping timeout: 240 seconds]
marmotini_ has quit [Remote host closed the connection]
<jaredmm> I'm going through and fixing some translate-c issues and I've started to see a lot of redefinition errors. (pub const __ = @compilerError) that are all identical. One instance of a const and pub const definition with the same @compileError body.
s-ol has quit [Remote host closed the connection]
<jaredmm> I'm checking without my patch to confirm it didn't create the scenario rather than just being hidden because of all the other errors.
<jaredmm> I'm attempting to bisect with my patch to be sure, but I think I'm doing it wrong. I'm following the hot-fix example on https://git-scm.com/docs/git-bisect#_examples.
<jaredmm> Is that the best way to deal with this scenario or is there a more efficient route?
<frett27> i'm having a redefinition issue for pointer on struct, is that's legal ? https://godbolt.org/z/Xjfy7P
<jaredmm> (Although looking at an old master I see the issue there, just not reported as an error because of an earlier error, so it doesn't seem to matter for this case)
<frett27> because of the same name for parameter and global variable
<pixelherodev> Variables can never shadow other variables
<pixelherodev> You'll have to rename one
adamkowalski has joined #zig
mahmudov has joined #zig
<adamkowalski> What is the rule with anonymous struct literals? Sometimes when I call a function it works fine, other times I get `error: TODO: type coercion of anon struct literal to struct`
marijnfs has joined #zig
TheLemonMan has quit [Ping timeout: 240 seconds]
TheLemonMan has joined #zig
frmdstryr has quit [Ping timeout: 255 seconds]
jessermeyer has quit [Remote host closed the connection]
Akuli has joined #zig
<fengb> andrewrk: I'm looking at implementing optional shrinkFn. Your old branch hijacks realloc if shrinkFn is null: https://github.com/ziglang/zig/commit/92122f988a811a0c2f606377e18b1f2060ec4c08#diff-c666216954ff0e34f3cb9f3e806e3f53R157
<fengb> But FBA has an explicit test to do an in-place expand if it's the last element
<adamkowalski> fengb: do you happen to know why the anonymous struct error above happens?
<fengb> Nope... but I've seen it semi often
<fengb> One major problem I had (that might be fixed) is that anon literals can't be coerced into anon structs e.g. fn blah(args: struct {})
<adamkowalski> it worked when I defined the struct in the file where the function was being called though
<adamkowalski> I had a common struct I wanted to refactor into one file, and then all those other files could no longer use it anonymously
<adamkowalski> nevermind even when I declare it in the same file it seems to not work
<adamkowalski> okay awesome, I'm glad it's a known issue. Sounds like 0.6 has some cool things planned
<fengb> Well... it's only about a month away so don't hold your breath on a fix :P
<adamkowalski> okay well I don't mind getting involved, it sounded like Andrew thought it was a relatively simple issue
<adamkowalski> Are there any design docs or something which describe the overall structure of the compiler?
<adamkowalski> I guess I can start by looking at the unit tests?
<fengb> I don't really know much about the compiler either :P
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<adamkowalski> awesome thanks, I'll get to reading
<andrewrk> TheLemonMan, yo
<TheLemonMan> I forgot what the question was heh
<TheLemonMan> gah I love some more crazy SIMD-related test failures
<andrewrk> TheLemonMan, I wonder how the llvm10 branch fares
<TheLemonMan> much better I guess
<TheLemonMan> the 10 series already fixes a few crazy codegen problems
<pixelherodev> Just for the record: github.com/pixelherodev/kak-zig
<pixelherodev> Found a better version, then integrated zig-fmt
<Kingsquee> considering arbitrary sized numbers, is there any support / libraries for dynamic bitwidth integers that don't overflow? (except when hitting max integer bitwidth)
<TheLemonMan> the stdlib has "classical" bigints
<Kingsquee> hmm
<pixelherodev> Only thing I need to fix for kak-zig is `zig build` integration (which works with my setup, but the commands to go the errors are confused by the zig command line showing up in the output due to verbose mode)
<Kingsquee> is there a way to disable the implicit conversion from machine sizes to bigints for integers?
<Kingsquee> i.e. getting a compiler error if I use a u129
<andrewrk> llvm10 branch passed the full test suite with llvm assertions enabled
<andrewrk> llvm10 rc4
<Kingsquee> I imagine if someone starts doing high perf code with type generation one could accidentally tank their perf as complexity increases
<andrewrk> Kingsquee, there's no implicit conversion from primitive int types to std.math.big.Int
<Kingsquee> andrewrk: I mean the support for arbitrary i#/u#'s
<Kingsquee> i512 etc
<Kingsquee> i7
<Kingsquee> u9
<andrewrk> using large fixed width int sizes doesn't necessarily mean tanking perf. it could actually be quite well performing
<andrewrk> the "maximum machine int size" is different for different targets
<andrewrk> applications should pick reasonable upper bound limits for integers and then use the appropriate types
<pixelherodev> Is there an equivalent to __LINE__ / __FILE__ ?
ur5us has joined #zig
<Kingsquee> andrewrk: I'm just exploring zig now, so sorry for the unfamiliarity, but can the width of a returned integer type be defined using comptime calculations?
<andrewrk> Kingsquee, yes
<Kingsquee> conceptually equivalent to concat(u, n+m) -> u#
<Kingsquee> where # is the sum of n+m
<Kingsquee> because in that case, the 'reasonable upper bound' for integers may quickly become obfuscated behind a bunch of typegen
<Kingsquee> so it'd be nice to have some kind of `-set-max-integer-width #` to help with linting intent
marijnfs has quit [Ping timeout: 255 seconds]
<andrewrk> nah you don't need that. try it out a bit and see
<andrewrk> just put a type on something if you want to limit its size
<Kingsquee> hmm, true
<Kingsquee> I have to remember to do that though!
<Kingsquee> EVERYWHERE
<Kingsquee> that said I could just add that check to said typegen macros :I
<Kingsquee> hmmmmmmmmmmmmmm :I
<jaredmm> How would a compiler intrinsic from a C header get translate-c'd? Are there any existing examples?
marijnfs has joined #zig
<pixelherodev> Poorly, from what I remember :(
<fengb> andrewrk: I'm looking at implementing optional shrinkFn. Your old branch hijacks realloc if shrinkFn is null: https://github.com/ziglang/zig/commit/92122f988a811a0c2f606377e18b1f2060ec4c08#diff-c666216954ff0e34f3cb9f3e806e3f53R157
cow-orker has joined #zig
<fengb> But FBA has a implementation / test to do an in-place expand if it's the last element
<pixelherodev> Integrated `zig build` into kakoune :)
<pixelherodev> It's actually *easier* to jump between errors now than in Vim
<jaredmm> More "how is it expected to be done" rather than how well does it work. I know clang has definitions for the MSVC intrinsics. Is the expectation that each intrinsic is re-implemented in Zig?
<Kingsquee> is there a way to define a test should fail?
<Kingsquee> better yet, fail to compile?
<TheLemonMan> no
<TheLemonMan> you can add a @compileError that's only triggered if the code compiles
<andrewrk> fengb, sounds like FBA would not be elligible for null shrinkfn
<andrewrk> I don't understand your concern- realloc is non-optional so it's always available
<Kingsquee> hmm
<Kingsquee> variables in tests don't seem to be scoped to the test?
<Kingsquee> test "fooy" { var foo: i32 = 4; } const foo: i32 = 10;
<Kingsquee> "error: redefinition of foo"
<TheLemonMan> the local variable is shadowing the global one
alichay has joined #zig
<fengb> I don't think null shrinkfn should dictate how an expand should work
<Kingsquee> TheLemonMan: fn fooy() void { var foo: i32 = 4; } const foo: i32 = 10;
<Kingsquee> no error
<andrewrk> fengb, in what way does null shrinkfn dictate how an expand should work?
<Kingsquee> oh interesting, it doesn't display the error unless fooy() is used
<andrewrk> pretend that I have no idea what you are talking about because I wrote that code years ago and don't remember
<TheLemonMan> everything that's not referenced won't be compiled/analyzed at all
<Kingsquee> I'm not sure if this is a feature or not
<andrewrk> it has benefits and problems
<Kingsquee> yeah
<andrewrk> this is the same problem as conditional compilation that all languages have, but zig has it for every function
<fengb> Your old implementation checks if there's a null shrinkfn, it'll automatically do a copy expand for realloc
<TheLemonMan> it's great when you're refactoring a lot of code
<fengb> I don't think that should be there, only a special case for a shrink realloc
<TheLemonMan> it's not great when you discover some code path has bit-rotted
<andrewrk> yeah. it's not considered to be a "closed" part of the language design
<andrewrk> still an unsolved problem
<Kingsquee> noted
<fengb> I'll make my change and have you review it :P
<andrewrk> fengb, I think I agree with you that it should call realloc on the underlying implementation
tdc has quit [Ping timeout: 260 seconds]
<Kingsquee> oh jeez, namespaced_global.zig
<Kingsquee> mind = blown
<TheLemonMan> that's a good title for a talk, "Zig blows (your mind)"
<Kingsquee> this is going to take some getting used to
<andrewrk> Kingsquee, zig is a Domain Specific Language for generating machine code. if you think of it this way, it may help
<adamkowalski> andrewrk: is there some guideline on when anonymous struct literals work and don't work? I've had some issues with them today
<Kingsquee> andrewrk: what else could one want
<adamkowalski> I'm getting error: TODO: type coercion of anon struct literal to struct
<andrewrk> adamkowalski, you can avoid this problem by time traveling until the TODO is implemented, or by using @as
<adamkowalski> Kingsquee: everything is lazy evaluated, which is great, it speeds up compile times. However, something thats a gotcha is tests wont run if they aren't referenced. So if you look at the standard libraries main file is has to "reference all decls" and then it will force evaluation and run your whole test suite
<adamkowalski> andrewrk: But is there a guideline on when it will work? In other parts of my codebase I am able to use them
<Kingsquee> interesting
<andrewrk> adamkowalski, yes, when the result location has a type
<adamkowalski> So here is the call site: const actual = try minimum(f64, &arena.allocator, x, .{});
<adamkowalski> and the function prototype: pub fn minimum(comptime T: type, allocator: *Allocator, tensor: CpuTensor(T), parameters: ReduceParameters) !CpuTensor(T) {
<adamkowalski> shouldn't type inference pick up that parameters is of type ReduceParameters
<adamkowalski> and then the .{} will be implicitly of type ReduceParameters?
<andrewrk> yes
<adamkowalski> so does the result location not have a type in this case? I guess I don't understand what that means
<andrewrk> TheLemonMan, it's pretty neat how the Target feature set can use SIMD as an actually more convenient way to add/remove items from the set righ? :D
<andrewrk> idk if the codegen is better or worse, but in theory it should pretty much be the same
<TheLemonMan> hah yeah, that's what pushed me to implement some other missing ops
<andrewrk> I need to get the skeleton of stage2 figured out, with async I/O and all that good stuff, so that contributors can have something exciting to work on
<andrewrk> a big milestone recently is that now the std lib tests build with --test-evented-io
<TheLemonMan> great! the CI fails because of a QEMU bug :(
<andrewrk> (but they fail at runtime due to an event loop bug - which is good because that's what I want to be working on now)
adamkowalski has quit [Quit: Lost terminal]
adamkowalski has joined #zig
<TheLemonMan> andrewrk, do you think it's possible to upgrade qemu in the azure img?
<adamkowalski> andrewrk: I think there was a break on master last night or today btw./Users/adamkowalski/zig/lib/std/fmt.zig:329:32: error: expected 6 arguments, found 4
<adamkowalski> return try value.format(fmt, options, out_stream);
<adamkowalski> but allocPrint still uses the old arguments so it breaks when called
<frett27> adamkowakski: got the same, if you define a specific format trait
<frett27> you have to change the signature
<frett27> of format
<adamkowalski> of allocPrint?
<adamkowalski> I guess I can submit a PR
<frett27> ha, not the same issue
<fengb> Are you using a custom formatter?
<frett27> i change a bit some code linked to custom "format" trait changes yesterday
<Kingsquee> hm, so I tried removing 'threadlocal' from the thread local storage example in the documentation, and I get a "panicked during a panic"
<fengb> I probably should have worked on a better compiler error :/
<adamkowalski> fengb: yeah I am
<adamkowalski> ah it seems like now we just need to pass fmt, options and out_stream
<frett27> yep
<Kingsquee> I expected random order :I
<TheLemonMan> Kingsquee, the assertion failed
<TheLemonMan> when #4731 is merged you'll get a proper error message
<fengb> Yeah it’s just the compiler could have helped with better detection / messaging. I’ll actually go and add it real quick
<Kingsquee> TheLemonMan: cool, thanks
<Kingsquee> we don't have expected value printing for asserts yet either hey
<Kingsquee> "assertion failed, expected X, got Y"
<TheLemonMan> assertions expect a boolean expression
<TheLemonMan> you may want std.testing.expectEqual
<Kingsquee> "std.debug.panic("expected {}, found {}", .{ expected, actual });"
<Kingsquee> I guess this is why they call it testing :D
<adamkowalski> std.testing.expectEqual(expected, actual)
ur5us has quit [Ping timeout: 240 seconds]
<Kingsquee> adamkowalski: no, that's the error message using expectEqual gives me
<adamkowalski> ah
<adamkowalski> yeah for more complex types I sometimes write my owh expectEqual
<TheLemonMan> what else should it do? fix the error for you?
<Kingsquee> TheLemonMan: print what the values of expected and actual are
<adamkowalski> and if you define formatted printing for your type that can help a lot
<Kingsquee> it's just an i32 mang
<Kingsquee> ain't nothin fancy here
<adamkowalski> it works for most things, unless you are dealing with nested arrays
<TheLemonMan> ... it does ?
<Kingsquee> TheLemonMan: where
<TheLemonMan> "std.debug.panic("expected {}, found {}", .{ expected, actual });"
<Kingsquee> except it actually printed that
<Kingsquee> not the values
<adamkowalski> are you sure you're using a real terminal emulator? is the standard out being manipulated at all
<adamkowalski> in emacs things are a bit fishy
<Kingsquee> lets see
<Kingsquee> nope, same thing
<Kingsquee> lemme paste
<adamkowalski> use a pastebin, showcase your test case and your output please
<andrewrk> TheLemonMan, I can look into it. I briefly looked into it before and it seemed difficult
<andrewrk> it would be nice if more projects just gave you a tarball you could unpack...
<adamkowalski> Kingsquee: line 15 Test [2/2] test "thread local storage"...expected 1237, found 1235
<Kingsquee> sorry, forgot to paste testTls, but it just executes `tl_x += 1` like in the example, but without the asserts
<Kingsquee> adamkowalski: oh man that's hidden in the melange
<TheLemonMan> Kingsquee, "expected 1237, found 1235"
<TheLemonMan> what you were pointing to is the stack trace...
Akuli has quit [Quit: Leaving]
<Kingsquee> in my defense, it's far more visible :v
<Kingsquee> so expectEqual is actually saying it backwards, based on the params, which is kinda whatever, I'll just reverse them
<Kingsquee> but when I reverse them I get "error: expected type 'comptime_int', found 'i32'"
<TheLemonMan> the prototype is expectEqual(<expected>, <actual>)
<Kingsquee> right, so when I put a literal into expected and variable into actual, it gives that error
<adamkowalski> if you have a comptime_int use @as(i64, 5)
<fengb> Yeah the inference is wonky. See also https://github.com/ziglang/zig/issues/4437
<TheLemonMan> eh, it's not much a matter of type inference being wonky, it's because how expectEqual is defined
<TheLemonMan> `fn expectEqual(expected: var, actual: @TypeOf(expected))`
<TheLemonMan> so if `expected => comptime_int` actual has to be comptime_int too...
<TheLemonMan> andrewrk, yeah it seems the only way to do so is to built it by hand
marijnfs has quit [Quit: Lost terminal]
<Kingsquee> but we can do 'var a: i64 = 5"
<TheLemonMan> and?
<Kingsquee> it just seems like by the expectEqual logic we should have to do `var a: i64 = @as(i64, 5)`
<fengb> Kingsquee: it's because the args match JUnit, but our type inference needs to be the other way around
<fengb> So we can only do left to right inferencing, and it doesn't work when comptime literals are on the left side
<TheLemonMan> that's an implicit cast
<adamkowalski> I think it's fine as is. you want to make sure expectEqual does not implicitly change types
<adamkowalski> if it's a literal it will be a compile_int/compile_float unless explictily casted otherwise
<TheLemonMan> 5 is comptime_int, the compiler is smart enough to know it fits into a i64 and so inserts the cast for you
<fengb> I'd prefer if expected is on the right, and a lot of people on that issue agree :P
<adamkowalski> having to type a tiny bit more is worth having the power of compile time numbers
<Kingsquee> TheLemonMan: I'd expect typing a literal into something that has an integer type will be the integer type, no exceptions :V
<adamkowalski> and if you really care, you can easily write an expect equal which accepts two vars and then does the coercion yoruself
<adamkowalski> it already does that
<adamkowalski> if you have a function expected an i32 and you pass a comptime_int it will conver it
<adamkowalski> but in this case the leftmost argument is a comptime int, and so the right argument (which must match the left most argument) will not be known at comptime
<Kingsquee> ah, I see
<fengb> It's really just this one function
<Kingsquee> yeah lets swap dat order
<fengb> Most of the other times, it resolves as you expect or it's actually ambiguous
<fengb> I do kinda like Rust's 1u32 syntax though
<Kingsquee> I prefer its 'as' syntax, frankly
<Kingsquee> just wish it doesn't some special snowflake for basetypes
<Kingsquee> in practice I just write my own `.cast<T>()`'s
<Kingsquee> so when somethings been added to Milestone 0.7.0 or whatever, does that imply it's accepting PR's?
<fengb> No, it just means it's planning to be worked on for 0.7 release. You can make PRs for anything at any time
<Kingsquee> ah, so if someone does it before 0.7, we're not in conflict
<Kingsquee> just means it's graced awrk's bucket list
<fengb> Right
<Kingsquee> nice
<fengb> Or more likely... he'll look at it 2 months before end of release and push it out again >_>
<fengb> Release features are rather lax heh
<Kingsquee> HRMMvibratingface.mov
<adamkowalski> this is a fun error
<adamkowalski> ./src/eager/cpu_tensor.zig:28:9: note: 'error.NoSpaceLeft' not a member of destination error set
<adamkowalski> ) error{NoSpaceLeft}!void {
<adamkowalski> am I crazy?
<Kingsquee> there is no space left in the destination error set, ergo you have caused all possible errors across all time and space axis
<adamkowalski> I think it's because I'm using recursion and the error set is not properly being inferred. I'll keep digging
<Kingsquee> huh, this is interesting
slurpie has quit [Ping timeout: 256 seconds]
<Kingsquee> so without threadlocal storage on the global variable storing 1234, I ran two threads, each incrementing tl_x by 1, and after wait()ing for each thread to finish, I expectEqual'd tl_x to be 1236
slurpie has joined #zig
<Kingsquee> in practice I get either 1236 or 1237
<Kingsquee> I'd expect the thread execution order to be nondeterministic, but the value should be deterministic after the wait()s, no?
<fengb> I wouldn't expect 1237... but 1235 wouldn't surprise me
<adamkowalski> andrewrk: In the past you mentioned I could use error{}!ReturnType and the compiler will tell me what to put in. It seems like that is no longer the case? Any Ideas
<Kingsquee> but it's wait'd!
<fengb> Oh waiting between each thread?
<fengb> Anyway... not sure how 1237 came out
<Kingsquee> oh wait, yeah I messed up
<Kingsquee> it's 1235 or 1236
<Kingsquee> hol' up
<adamkowalski> fengb: do you happen to know any code examples with formatting + recursion after the api change?
<fengb> (tl_x += 1) => (tl_x = tl_x + 1). No guarantees the assignment will happen directly after the add so it's possible both threads picks up 1234 and adds by 1
<fengb> And one of the assignments is just clobbered
<fengb> You should be able to just delete the leading Error and inference would just work
<adamkowalski> not with recursion
<adamkowalski> ./src/eager/cpu_tensor.zig:53:13: error: cannot resolve inferred error set '@TypeOf(src.eager.cpu_tensor.printTensor).ReturnType.ErrorSet': function 'src
<fengb> Hmm
<fengb> @TypeOf(out_stream).Error!void
<adamkowalski> it's trying to infer the error set, which I'm assuming means following each function call to find the error set and then do the union
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<adamkowalski> and when it follows the recursive call it's realizing it's going into an infinite loop?
<adamkowalski> Hell yeah!!! that worked, thanks
<fengb> np
<fengb> I'll add that to the compile error :)
<fengb> Maybe I should just add that everywhere in the code. It doesn't need it... but it'll be more obvious looking at the examples
<adamkowalski> I mean overall it's a much slimmer/cleaner API so I like it
<adamkowalski> it just took me a second to update to it, so I haven't gotten anything done today haha
<adamkowalski> I've been adding in all the type names to fix the anonymous struct issue, and then updating the formatted printing
<fengb> Sure, there's no reason we can't be more helpful (other than I forgot)
<fengb> It runs both in parallel and waits on execution
<fengb> That's a race condition
<fengb> Spawn starts the execution. Wait only waits for completion
<adamkowalski> Kingsquee: Are you sure you don't want to use an atomic
<adamkowalski> the issue is not the wait
<adamkowalski> it happens well before then
<adamkowalski> try to describe what you think is happening
<Kingsquee> adamkowalski: I'm not very familiar with threading so I very well might
<adamkowalski> you either need a mutex, or a atomic operation
<Kingsquee> oh, I guess it makes sense
<adamkowalski> but yeah I'm curious what you think is happening (at a high level)
<adamkowalski> then we can figure out how to change the intuition
<Kingsquee> I'd expect each thread to load the value into a local register, modify it, and then write back to main memory/cache/wherever it is
<Kingsquee> if they both load at the same time then both values written would be 1235
<Kingsquee> if they do slightly before/after we'd get 1236
<adamkowalski> and in your example are you using a thread local variable?
<fengb> This error message looks pretty verbose :(
<adamkowalski> just because you call it tl_x doens't make it so
<Kingsquee> I was half-thinking originally they'd both be working on the same memory location, which obviously isn't so
<Kingsquee> adamkowalski: I was originally, but then removed the threadlocal keyword
<Kingsquee> just didn't bother to modify the variable name
<Kingsquee> wanted to see what would happen
<adamkowalski> right, so it will "very rarely" be 1236
<adamkowalski> it has to read the variable in both threads
<adamkowalski> there is some likelihood it will be 1234 in both
<adamkowalski> because it tries to read from l1 cache, which will miss
<adamkowalski> then go to l2, l3 and then main memory
<adamkowalski> l1 and l2 are not shared per core
<adamkowalski> it depends on your architecture*
<adamkowalski> then when you write it writes to cache
<adamkowalski> it doesn't write just that variable either, but a whole cache line
<adamkowalski> so what you really want to do is have some sort of syncronization
<adamkowalski> either use an atomic operation, such as compare and exchange
<adamkowalski> which will look at the current value, if it matches what you expect then it will do the swap
<adamkowalski> or you can use a lock, and wait until you acquire it, then do the mutation, release the lock
<Kingsquee> is there some reading on how atomics actually work?
<adamkowalski> but the best thing to do is not share memory between threads at all (at least mutibly)
<Kingsquee> I've looked a little before but it felt very handwavey
<Kingsquee> yessssss
<adamkowalski> overall atomics are fairly straightforward in concept
<adamkowalski> just like in a database
<adamkowalski> either the whole transaction succeeds or fails in an atomic unit
<adamkowalski> keep in mind if your goal is increased performance and so you are trying to move to a multi threaded envirnonment, but your solution is to share mutable state between threads, you may very well be slower then a single threaded solution
<Kingsquee> yeah, that's intuitive
<adamkowalski> I recommend only sharing immutable data between threads. Or partition the work so that each thread works on a different section of an array and coordination is not required.
<adamkowalski> Or use a queue and send messages back and forth between threads. but each thread does not share any data between themselves
<adamkowalski> mutable data + locks and threads is like a stop light at an intersection. Only one direction can move freely at once
<adamkowalski> prefer on ramps and off ramps of highways which route traffic to different part of the system uninteruprted
<Kingsquee> wouldn't you need some sort of lock to stop queues from having race conditions?
<Kingsquee> eg thread1 writes to queue1, thread2 writes to queue1
<Kingsquee> then again could just have unidirectional queues
<Kingsquee> only lock then would technically be a 'being written to' flag
<Kingsquee> perhaps a 'being read' flag
<adamkowalski> yes the queue would have to be written in terms of locks and or atomics, but it's much easier to get one part of the system correct and tested and then everybody else just benefits
frett27 has quit [Ping timeout: 256 seconds]
Patrice_ has quit [Ping timeout: 255 seconds]
<adamkowalski> aditionally you could have three queues one for the writer, which is not locked, and is where you can place things when the middle queue is currently locked
<adamkowalski> one at the reader which the middle queue can write to when the reader is unaviable, as to not lock the main queue
<adamkowalski> then the middle queue would require a lock, then read from the write queue, and then put onto the read queue
<adamkowalski> the point is the complexity is managed once rather then dealing with threading everywhere which becomes really complex really fast
<adamkowalski> Kingsquee: this is a great talk about that https://www.youtube.com/watch?v=9HspeHGBg-Q
<Kingsquee> neat, thanks!