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/
<daurnimator> andrewrk: I assume #3644 a likely merge? (i.e. should I bother taking the time to rebase the InStream mixin stuff?)
<mq32> oh. looks like you have to manually enable comdats
<andrewrk> now this is working too: https://clbin.com/xEOZS
<andrewrk> daurnimator, I haven't looked closely yet, sorry. been focused on anon struct literals / anon list literals
<daurnimator> andrewrk: that's okay. I'm just going to be suddenly dev-time-poor as of tonight
<andrewrk> llvm does have a pass for this. I haven't tested how good it is
<mq32> btw, andrewrk: does zig allow to have two different functions have the same pointer?
<mq32> this would allow such iptimizations
<rjtobin> Quick question: I have a tagged union "x" of type SomeTaggedUnion, whose active field is ".Foo". I do the following: "x = SomeTaggedUnion{.Bar = x.Foo};". This crashes at runtime ("access of inactive union field"), but works if I split the assignment via an intermediate variable: "const y = SomeTaggedUnion{.Bar = x.Foo}; x = y;". Is this the way it's supposed to work, or a bug? (Not a big deal, just seeing if I should file a report)
<mq32> oh neat
<mq32> it's probably worth trying
<andrewrk> rjtobin, this has to do with result location aliasing the assignment expression. I think there is an issue open for this. it's not decided yet how this will work in final language spec. but it will always work with an intermediate variable
<rjtobin> @andrewrk: cool, makes sense. won't file a report. thanks!
<mq32> because my kernel project is 719248 bytes large atm and i wonder why that is
FireFox317 has joined #zig
<mq32> what are all those "__unnamed_800" symbols?
<daurnimator> mq32: how big if stripped?
<mq32> that is stripped
<mq32> unstripped is 1.6M
<daurnimator> mq32: 719K doesn't seem huge huge...
<mq32> it is, for what that code does
<andrewrk> mq32, if you're going to strip it, try compiling with --strip
<mq32> andrewrk: is there an option in std.build?
<andrewrk> because this exposes a comptime bool that is observed by, for example, std/debug.zig, disabling code that wouldn't work without debug info
<mq32> daurnimator: my demo for embedded hw had much more effects and embedded resources and had like ... 400kB size with music and data
<andrewrk> mq32, yeah, foo.strip = true;
<andrewrk> the __unnamed_ symbols I believe are global constants. zig doesn't correctly garbage collect those yet, but they should be dropped by the linker
<mq32> with --strip: 767168
<mq32> ah, thanks google/bloaty
<daurnimator> mq32: ah I had forgotten that tool existed :)
<mq32> looks like i have too many interesting inits :D
<andrewrk> this is a release build right?
<mq32> release-small, yes
<daurnimator> mq32: or some tables of data in there somewhere....
<mq32> yeah
<mq32> have to search a bit
<mq32> bloaty seems the right tool right now
<daurnimator> mq32: use -d
<mq32> doesn't help
<mq32> we only have one compile unit
<mq32> ah wait
FireFox317 has quit [Remote host closed the connection]
<mq32> someone please slap me
* daurnimator slaps mq32 around a bit with a large trout
<mq32> huh
<mq32> okay, trying to fix this yields: Unreachable at /deps/zig/src/analyze.cpp:4898 in handle_is_ptr. This is a bug in the Zig compiler.
<mq32> but: the problem was *one large array of 512kB set bits*
<daurnimator> mq32: let me guess..... your allocator? :)
<mq32> yeah
<mq32> i can make that information ... smaller
<mq32> also i wonder how to replay that compiler bug
<daurnimator> rr? :)
<andrewrk> idk if llvm fixed this yet but it wasn't putting `undefined` in the bss section. I think that's an open issue in zig right now
<mq32> oh
<mq32> nah, that should work already
<mq32> otherwise the file would be >= 4 megs
<fengb> Was building zig always this fast? It's ~1.5 mins for me now
<andrewrk> if you haven't updated in a while, things that have changed: -DZIG_SKIP_INSTALL_LIB_FILES=on skips installing lib files and translate_c.cpp no longer #include's any C++ files
<mq32> LOL
<andrewrk> building zig itself takes about 17 seconds for me. it's our LLD fork that takes the longest
<fengb> o_O
<mq32> that optimization did it :D
<mq32> .data is now 7500 times smaller than before
<andrewrk> what optimization?
<shachaf> andrewrk: whoa, replacing varargs with structs with metadata seems great.
<fengb> The optimization that deletes all data 🙃
<mq32> this one
<fengb> Ah that makes sense
<shachaf> Have you considered something similar for non-vararg arguments?
<andrewrk> mq32, ah, this would also have done it: https://github.com/ziglang/zig/issues/425
<andrewrk> zig could have ran that init function at comptime
<mq32> yes
<mq32> i know
<mq32> and this bloats my executable by 7500 times
<andrewrk> oh, you were doing it at comptime before
<mq32> because it's initializing "lines" with a lot of "1"s
<andrewrk> ahh
<andrewrk> so #425 would actually compromise this size optimization
<mq32> yes
<andrewrk> well, not really. because you make it a global variable, it cannot run the init at comptime anymore
<andrewrk> ok ignore me
<andrewrk> shachaf, not sure what you mean. have a code example?
<mq32> i just had to remember a wonderful "let's optimize this c++ program talk" which ended up with: "don't do stupid things and your programs will be faster"
<mq32> btw, great talk, not only for c++ programmers. anyone interested? gonna search it, then
<shachaf> Hmm, I guess if you have to use the struct literal syntax anyway it doesn't really add anything?
<shachaf> Maybe the thing I'm thinking of is too much of a departure from what Zig does.
<fengb> But half of C++ is stupid things 🙃
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<shachaf> I'm thinking of something like, every function implicitly takes a struct of its arguments (where the calling convention works out to the regular thing). Then you can call functions as usual, but you can also use struct literals to get things like keyword arguments automatically.
<fengb> Would it make sense to switch expected and actual args for expectEqual? It makes literal inference a lot nicer
<fengb> 90% of my old casts are for tests :/
<andrewrk> fengb, yeah the expectEqual function is useless to me in its current state, something needs to change
<daurnimator> andrewrk: re: var args: still need to be able to call C vararg functions: is that catered for?
<andrewrk> #3652 is ready to merge
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk> c var args is an unrelated feature to zig var args
<mq32> that's the talk i was talking about
keithdc has quit [Quit: leaving]
<daurnimator> andrewrk: awesome, nothing in PR jumps out at me, merge away :)
lunamn_ has joined #zig
dimenus|home has joined #zig
dimenus has quit [Read error: Connection reset by peer]
lunamn has quit [Ping timeout: 268 seconds]
<fengb> Inline anon structs are amazing
<andrewrk> I have a plan for comptime fields to be allowed
<andrewrk> I do need to pay some tech debt though, this implementation limits it to 16 fields / elements, until some internal compiler data structures can get reorganized
<andrewrk> that's not a regression, that's a limit on the new thing
bhansconnect has joined #zig
lunamn_ has quit [Quit: leaving]
<andrewrk> The result location changes was quite an investment but it paid off big time in that branch
doublex_ has joined #zig
doublex has quit [Ping timeout: 268 seconds]
<fengb> src/wasm_exports.zig:5:33: error: expected type 'main.struct:507:31', found 'struct:5:33'
doublex_ has quit [Ping timeout: 240 seconds]
doublex has joined #zig
<andrewrk> fengb, I know what's happening here, I forgot to add a test case for this. An additional change is needed to add a result location cast for fn parameters
<andrewrk> I'm done for today but this will be a straightforward fix
<fengb> Ah okay cool
<andrewrk> There's actually 2 reasons this should work, both so far unimplemented
<andrewrk> Rest assured that is in fact an intended use case
Ichorio_ has joined #zig
Jezza__ has quit [Ping timeout: 276 seconds]
Jezza__ has joined #zig
Ichorio_ has quit [Ping timeout: 250 seconds]
rjtobin has quit [Quit: Leaving]
doublex_ has joined #zig
doublex has quit [Read error: Connection reset by peer]
bhansconnect has quit [Quit: Connection closed for inactivity]
muffindrake has quit [Ping timeout: 252 seconds]
doublex_ has quit [Ping timeout: 250 seconds]
muffindrake has joined #zig
doublex has joined #zig
chemist69 has quit [Ping timeout: 246 seconds]
chemist69 has joined #zig
mahmudov has joined #zig
<fengb> Neat
<bgiannan> So i guess things like `var i = usize(0)` got removed with the anonymous struct PR? But things like `var h: u32 = 0; h += if (a) 3 else 2;` now need to be written like so `h += if (a) @intCast(u32, 3) else @intCast(2);`. Is this intended ?
<bgiannan> nevermind, just saw @as
<fengb> andrewrk mentioned he'll be working on peer type resolutions soon
<fengb> That should get rid of most of these casts
<bgiannan> nice
<bgiannan> is `[_]u8{ 1, 2, 3, 4}` syntax gone?
<andrewrk> bgiannan, no that syntax remains
<andrewrk> the only breaking change recently was @as
<bgiannan> so i had something like this: `const octants = [_][]f32 { [_]f32 { -1, 0, 0, 1 }, ... }`
<bgiannan> and now i have to do `const octants = [_][4]f32{ [_]f32 { ...}, ... }`
<andrewrk> bgiannan, no you just need const on your []f32\
<bgiannan> `[_][]const f32` ?
<bgiannan> why did zig only complained about it now (just updated to 5502160bd)?
return0e_ has joined #zig
jjido has joined #zig
return0e_ has quit [Ping timeout: 276 seconds]
<andrewrk> bgiannan, the @as branch came with this bug fix
<bgiannan> ah i see thanks
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<scientes> Is there a better way to use stepi in debugging where it writes out what changed, so you don't have to repeatedly track registers?
<scientes> and you can just have a (quite verbose) record of what happened
<scientes> instruction-by-instruction
mahmudov has quit [Read error: Connection reset by peer]
return0e_ has joined #zig
return0e_ has quit [Remote host closed the connection]
mahmudov has joined #zig
return0e_ has joined #zig
return0e_ has quit [Ping timeout: 240 seconds]
return0e_ has joined #zig
return0__ has joined #zig
return0e_ has quit [Ping timeout: 276 seconds]
_whitelogger has joined #zig
<Snektron> I think someone posted a useful gdb configuration a while ago with which you can view register state without having to query then
<Snektron> them
<Snektron> Other than that idk
frmdstryr has quit [Ping timeout: 268 seconds]
mattmurr has quit [Remote host closed the connection]
emekankurumeh[m] has quit [Read error: Connection reset by peer]
vegai has quit [Remote host closed the connection]
dtz has quit [Remote host closed the connection]
BitPuffin has quit [Remote host closed the connection]
Demos[m] has quit [Remote host closed the connection]
D3zmodos has quit [Remote host closed the connection]
Snektron has quit [Remote host closed the connection]
fengb has quit [Remote host closed the connection]
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
return0__ has quit [Ping timeout: 265 seconds]
return0e_ has joined #zig
return0__ has joined #zig
return0e_ has quit [Ping timeout: 246 seconds]
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
vegai has joined #zig
Demos[m] has joined #zig
BitPuffin has joined #zig
dtz has joined #zig
D3zmodos has joined #zig
mattmurr has joined #zig
fengb has joined #zig
Snektron has joined #zig
return0e_ has joined #zig
return0__ has quit [Ping timeout: 246 seconds]
frmdstryr has joined #zig
return0__ has joined #zig
return0e_ has quit [Read error: Connection reset by peer]
return0e_ has joined #zig
protty has joined #zig
return0__ has quit [Ping timeout: 250 seconds]
waleee-cl has joined #zig
mahmudov has quit [Ping timeout: 268 seconds]
<bgiannan> Is there any plan to have some strings related stuff in std? Things like pattern matching, strings manipulation, etc. ?
<mq32> bgiannan: there is already a lot of useful stuff in std.mem
<mq32> tokenize, separate, indexOf, ...
<daurnimator> bgiannan: yeah I think so. I've always wanted an lpeg-like thing in there.
<daurnimator> bgiannan: just its way down on peoples priority lists
<daurnimator> if anyone really wants to work on it, they should go for it
<daurnimator> bgiannan: btw, did you ever think more about the objective C bindings I suggested you might want to work on?
<bgiannan> mq32, nice, never saw those yet. separate is precisely what i was writing right now
<bgiannan> daurnimator, no i'm focused on zsettlers right now and trying to not be distracted into anything else
<mq32> tokenize is also really handy ):
<mq32> *:)
<daurnimator> bgiannan: fair.
<bgiannan> mq32, i don 't get the difference between the two?
<mq32> tokenize doesn't yield empty results
<fengb> I believe Andrew is happy to merge anything generally useful into std atm, but there will be an audit before 1.0 to pull out a lot of stuff
<bgiannan> fengb, not sure i get the strategy here. This make me thing i should hold back on using any fancy feature of std before 1.0
<bgiannan> think*
<daurnimator> bgiannan: essentially, until we get a working package manager, then anything that even vaguely belongs in std will probably be added to std.
<mq32> separate will split "at" the string (so if you pass "<>", you will only split when an <> occurs)
<mq32> tokenize will separate on *any* byte, so if you pass "<>", you will split on either "<" or ">"
<daurnimator> bgiannan: then once we have a working package manager, then things will be evaluated and moved out to external libraries.
<daurnimator> bgiannan: in the mean time, any of the things added to std will be upgraded as the language itself evolves
<fengb> Also easier to do regression testing if everything is together
<daurnimator> e.g. u32(0) is now @as(u32, 0) ==> all users in the std library got updated in the same PR.
dimenus|home is now known as dimenus
protty has quit [Remote host closed the connection]
<fengb> https://fengb.github.io/zee_alloc/#std;math.isPowerOfTwo
<fengb> How are these examples generated?
<Snektron> Whats it with var in the docs
<daurnimator> fengb: based on how it was called during tests
<Snektron> Why not just copy the entire function prototype into the docs
<daurnimator> Snektron: that is the function prototype...
<daurnimator> actually something is messed up
<daurnimator> should be `pub fn isPowerOfTwo(v: var) bool`
<daurnimator> return type is bool not var...
<Snektron> I was about to say
<Snektron> I've noticed it on function parameters as well
<daurnimator> maybe the return type ends up `var` if the test fails? fengb: where in your tests did you use isPowerOfTwo? and why did you pass null? :P
<fengb> I don't. I can't run tests in wasm for some reason
<fengb> This is just a semantic dump of my exports
<daurnimator> conf.page_size must be null
<fengb> Well that's 65536, not null
<Pistahh> regarding @as - why wasn't something simpler chosen, like 123u64 ?
<Snektron> Maybe isPowerOfTwo should assure the parameter is an int
<mq32> Pistahh: because that does only work for literals
<mq32> not comptime ints
<mq32> and not for "type promotion", like casting u3 to i4
<Pistahh> mq32: ok, thx
<mq32> i don't like the @at change, but i can understand the reasoning
<mq32> and i don't have a better idea on how to solve it, so ¯\_(ツ)_/¯
<daurnimator> I went through some code I wrote recently to update for the @as change..... the only thing I had to update was testing.expectEqual calls
<daurnimator> turns out casting is pretty damn rare
<mq32> daurnimator: in "every day code" yes
<daurnimator> I initially felt a similar way about it, but not after that experience
<mq32> i had to replace about 300 casts in 4000 LOC
<daurnimator> In another piece of code I changed `var i = usize(0)` with `var i: usize = 0`.....
<mq32> i always try to declare variables like that
<mq32> but:
<daurnimator> which was the only other major usage of coercion I found
<mq32> a = b & ~0x80;
<mq32> this doesn't work, so you have to cast 0x80
<mq32> a = b & ~@as(u8, 0x80);
<mq32> which brings a lot of noise to the code
<daurnimator> Wouldn't that be better written as `a = b & 0x7F` anyway?
<mq32> i want to clear out the 7th bit and don't want to care on what the rest of type is
<mq32> this may introduce problems later if the type of b may change
<Pistahh> mq32: you shouldn't have 0x80 hardcoded in the first place, it should be a const :P
<daurnimator> mq32: but you said the type is u8....
<daurnimator> mq32: previously you would have had to write: `a = b & u8(0x80)`
<mq32> yeah, i know
<daurnimator> uh, with a ~
<mq32> itÄ's not that i like that either, but it's less noisy
<daurnimator> mq32: so did you really want: `a = b & ~@as(@typeOf(b), 0x80)`?
<mq32> yes
<mq32> should change that...
<mq32> but you agree with me that this is a lot of code noise for "making a literal value fit the type"
<mq32> Pistahh: and my constant is called what? "SEVENTH_BIT"?
<Pistahh> mq32: depends.. what is the reason for that operation? :) I suppose it should be SOMETHING_MASK. :)
<mq32> "make sure the seventh bit isn't set because otherwise the receiving end would break"
<daurnimator> mq32: use `a = b & (1 << (7 -1))` instead?
<daurnimator> trying to use bitwise not on a comptime int is your issue here
<mq32> yeah, but it's just an example for a lot of code i have
<Pistahh> mq32: see, SATISFY_RECEIVING_END_MASK_TO_MAKE_SURE_IT_DOESNT_BREAK. :)
<mq32> there's a lot of masks
<mq32> Pistahh: and now i don't know what the exact effect of this is
<mq32> this may be irrelevant in high-level code
<mq32> but on low level, all bit values are more relevant than what the name actually tells
<daurnimator> I forget if we have binary literals... but if so: `a = b & 0b1000000`
<Pistahh> mq32: ok, you can keep the 0x80 then. :)
<daurnimator> oh right I forgot the 'not' again
<daurnimator> /bed
<mq32> daurnimator: yeah it's not easy
<mq32> i could go for "follow all best practises"
<Snektron> a = b % 120;
<mq32> and then the code wouldn't be readable anymore ^^
<Snektron> What does @as actually do again
<mq32> it's implicit cast
<mq32> well, not so implicit cast
<mq32> Pistahh, i have a lot of funny magic values here:
<mq32> mmio_address = 0x55; mmio_address = 0xAA; mmio_address = 0x55; mmio_address = 0xAA;
<mq32> this is a wonderful example :D
vegai has left #zig ["User left"]
<Snektron> In which case would you use it? Are implicit casts going to be removed or something?
<mq32> it's the replacement for u64(0) e.g.
<mq32> so "@as(u64, 0)" is the new "u64(0)"
<Snektron> Or is specifically for when the target type is ambiguous?
<fengb> It used to be usize(1) but it's now @as(usize, 1)
<mq32> so function call syntax is not amgibious anymore
<Snektron> Oh i see
<Snektron> I'd go for literal suffixes instead but sure
<mq32> Snektron: as said above: literal suffixes are another usecase
<fengb> https://teespring.com/stores/wilsons-store-5 wait this is a thing?
<THFKA4> where's the orange-on-black cup? the zig foundation better sell those
return0e_ has quit [Remote host closed the connection]
samtebbs has joined #zig
<samtebbs> Is anyone else getting an assertion failure in type_has_bits (analyze.cpp:5408) since 5b2794349?
<samtebbs> That was part of andrewrk 's anonymouse struct literal PR
<andrewrk> samtebbs, I fixed it just now, thanks for the report
mahmudov has joined #zig
<fengb> zig.foundation tld is available :P
<andrewrk> if only starting a legal entity were as simple as a domain name
<fengb> Well time to park it for millions
samtebbs has quit [Ping timeout: 246 seconds]
<THFKA4> billions
lunamn has joined #zig
<Sahnvour> andrewrk: would you agree that we merge the vcpkg PR as a first step, and open an issue for a unified API over multiple package managers? I feel this has a much broader scope
<Sahnvour> and I think I'll ask the vcpkg folks if they have a better idea on how to query it anyway
<andrewrk> Sahnvour, yes that sounds good
<andrewrk> go for it
<Sahnvour> great, thanks
<andrewrk> are you on board with the idea of trying to integrate it into linkSystemLibrary?
<Sahnvour> I think the very name "system library" is a bit alien to windows obviously, but considering that will probably be the main type of C libraries linked in zig projects, it makes sense to use it for better compatibility
<Sahnvour> and cross-platformness
<andrewrk> I'm open to changing the name. The name is meant to imply that it depends on something installed and managed separately
<Sahnvour> I don't mind the name :)
<andrewrk> it could potentially even do something really interactive like pop up a gui to help you find the library on windows. as long as the intent is specified precisely enough, this would make sense in some cases
<andrewrk> e.g. something like `zig build --gui`
<andrewrk> build scripts are declarative, we're only scratching the surface of what features the build runner could provide
<Sahnvour> yes, interesting
<Sahnvour> until now I've only encountered _terrible_ package management (as in, add all dependencies to source control) so I was resigned and didn't really explore this field
marijnfs has joined #zig
<marijnfs> whatsup
<marijnfs> will we have a package manager soon?:)
<andrewrk> marijnfs, we're getting close
<andrewrk> interested in joining the effort?
<andrewrk> some of these are labeled contributor friendly: https://github.com/ziglang/zig/projects/4
<fengb> ooo compression
<andrewrk> gotta unpack those tarballs
<Sahnvour> so many interesting things, so little time
<andrewrk> I think the actual language changes for the package manager are going to be almost trivial. The main effort is the .zig code that does fetching and file system management
<marijnfs> andrewrk: i'll have a look!
<andrewrk> also it would be a crime to not use evented I/O for the package manager implementation
<andrewrk> this is the ideal use case
Akuli has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
<marijnfs> yeah i mean by now it would be morally incorrect to not use it
<marijnfs> whats the deflation inflation about, like any compression algorithm?
<andrewrk> that's a specific algorithm, the one provided by zlib
<andrewrk> better link: https://tools.ietf.org/html/rfc1951
<andrewrk> thanks for the follow up issue Sahnvour
<Sahnvour> andrewrk: created #3671, not sure I touched the whole idea / phrased it correctly so do not hesitate to improve it
<andrewrk> 👍
<Sahnvour> weird, I cliked to merge the PR, it showed an error but reloading the page shows it was merged
<fengb> How difficult would it be to add default struct values to typeinfo?
<andrewrk> fengb, the main problem to solve is representing the data types in std.builtin
<andrewrk> the type of a field is type `type`, but what type is the value?
<andrewrk> I'm OK with adding a builtin function to expose this info in the meantime
<fengb> Hmm
<marijnfs> andrewrk: don't you want whatever zstd is using?
<marijnfs> it's much faster
<andrewrk> it's quite possible zstd depends on deflate
<andrewrk> but we also need to support common formats, this isn't a question of choosing the best one
<andrewrk> we need a few common ones to "bootstrap" the package manager. And then "fetch plugins" can be installed via the package manager to fetch in more exotic ways (ipfs, git, svn, cvs, etc)
<andrewrk> ("fetch plugins" would be specified project-locally; the goal is to insulate projects from system configurations)
samtebbs has joined #zig
<samtebbs> andrewrk: Thanks for that! :)
<Sahnvour> andrewrk: curious, what's the @typeName of an anonymous struct ? based on source location, something else ?
<andrewrk> struct:line:column
<andrewrk> it's apparently missing the rest of the package path; I need to look into that
<andrewrk> note that if the result location has an actual array, struct, or union, then the syntax will directly instantiate the proper type, with no detour in the type system through an anonymous type
<andrewrk> likewise it's planned to allow this: var x, const y = .{. foo(), bar() };
<andrewrk> this also will directly instantiate x and y with no detour in the type system through anonymous types
<Sahnvour> okay
<andrewrk> this should let us avoid using `undefined` in more places
<frmdstryr> Are there any plans to make "not" a keyword for boolean negation?
<andrewrk> frmdstryr, no. if you're thinking of consistency with `and` and `or`, consider that those are control flow keywords, and `not` is not
<frmdstryr> Yes that's what I was thinking.
<andrewrk> it's also planned to make `~`, `|`, and `&` work on vectors of bools, and therefore probably also scalar bools
<andrewrk> not 100% sure on that yet
Akuli has quit [Quit: Leaving]
<andrewrk> scientes, why would you have a vector of bools anyway?
<scientes> andrewrk, vector of bools is what comparisons return
<andrewrk> hmm. maybe they should return vector of u1 instead
<scientes> that doesn't make much sense though
<scientes> as comparisons otherwise return bool
<andrewrk> I see your point. but you can do branching logic on `a > b` for scalars, but not for vectors
<andrewrk> so something already has to be different for comparisons of vectors
<scientes> you can if you use @reduce()
<scientes> but yes of course vectors are differnt
<andrewrk> `if (@reduce(a > b, .And))` vs `if (@reduce(a > b, .And) != 0)`
<scientes> andrewrk, as I pointed out however a() and b() is differn't from a() & b()
<scientes> even if they return scalar bool
<scientes> that is the important point I am making
<scientes> they are *different*
<scientes> and short-circuits, but & guarantees that both sides are evaluated
<andrewrk> but we don't plan to support `and` and `or` for vectors, right?
<scientes> we can't, because those short-circuit
<scientes> which would be ambiguous
<andrewrk> you would need `@reduce(...) and @reduce(...)`
<scientes> which is different from @reduce(...) & @reduce(...)
<scientes> *different*
<scientes> that's why C++ banning & and | bools is silly
<scientes> because its missing that these are differn't from || and && operators
<andrewrk> in that case it would be better to do @reduce(a & b)
<andrewrk> ...I think. or would it?
<scientes> yeah, it would be communicative
<scientes> it is communicative
<scientes> no difference
<andrewrk> I suppose the optimizer could theoretically figure out that is the same
<scientes> there are more complicated cases however, with floating point reductions
<andrewrk> anyway, yes I think my current opinion is to allow &, ~, | on vector bools, as well as scalar bools
<scientes> my big point there is that they are DIFFERENT operations, even on scalars
<scientes> because of short-circuiting
<andrewrk> yes, do you feel that people are not understanding this?
<scientes> gcc's warnings do not understand that
<andrewrk> ah. well in zig that's why they are keywords, because all control flow is done via keywords
<scientes> you have to put the intermediary into a variable you avoid the warning
samtebbs has quit [Ping timeout: 240 seconds]
<scientes> yes ,that is a good decision
<scientes> "and" and "or" are indeed control flow as well
<scientes> as operators
jjido has joined #zig
ltriant has joined #zig
dimenus has quit [Ping timeout: 265 seconds]
<Sahnvour> without varargs, how can we forward arguments to any function (_not_ using anonymous struct or list) in a generic way ?
<mq32> Sahnvour: Use "var" args :D
* mq32 giggles
FireFox317 has joined #zig
<mq32> fn(generic: var)
<Sahnvour> how do you get `fn foo(comptime function: var, generic: var)` to call `fn bar(a: u32, b: u32)` or `fn baz(c: u32, d: bool)` ?
<Sahnvour> or any other function of various arity
<Sahnvour> provided in `function`
<andrewrk> function(generic.@"0", generic.@"1")
protty has joined #zig
<andrewrk> the use case of different arities is not supported. what do you need that for?
<protty> its used in `std.event.Loop.call()` no?
<Sahnvour> that's useful in a lot of cases for wrapper functions
<andrewrk> protty, yes, I was planning on deleting that as well
<Pistahh> printf-like functions?
<Sahnvour> right now, I was trying the async stuff, to make what I'd call "packaged tasks"
<protty> would this manifest in everything else that takes var args like @newStackCall and @asyncCall ?
<Sahnvour> ie. start an async frame that will suspend just before it calls a provided function and its arguments, to execute it later
<FireFox317> Damn, UART is so annoying to work with, because of the asynchronous nature. but finally managed to get the bootloader to actually work on hardware. Yesterday I thought it worked, but it didn't XD
<andrewrk> FireFox317, nice, can I expect a PR today? :)
<andrewrk> protty, I'm not planning to change those builtins with regards to var args
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<FireFox317> andrewrk: Uhm, not today I think. When were you having the demo? And what would you expect to be in my PR? :)
<andrewrk> Sahnvour, I'm interested in seeing how this use case works out. as always, realistic use cases are the best arguments in any discussion about changes made to the language
<andrewrk> FireFox317, I'm about to start working on an rpi demo for handmade con this weekend. my travel begins tomorrow evening
<Sahnvour> tidying up my example, it's not working at all but hopefully can demonstrate what I want to achieve
<andrewrk> FireFox317, I was hoping to just get the framebuffer working on real hardware
<andrewrk> I think it might work to just run markfirmware's repo with some modifications
jjido has joined #zig
<leeward> Just did an update and `zig build docs` leads to "zig/build.zig:158:13: error: invalid builtin function: 'as'"
<FireFox317> andrewrk, ah yeah, that should be possible. Jup, markfirmware's stuff works on real hardware, I tested that. Then I started on working the usb and got sick of exchanging the sd card, so tried to get the bootloader working, but that was harder than expected :^)
<andrewrk> leeward, are you perhaps hitting https://github.com/ziglang/zig/issues/3024 ?
<leeward> andrewrk: I don't think so. I'm not running msvc. This is on Debian GNU/Windows (WSL) and I don't actually have Microsoft's dev tools installed.
<leeward> Unless that's actually about some system library that I'm not seeing.
<andrewrk> leeward, sounds like your `zig` is pointing to an old build
<andrewrk> did you run make?
<leeward> I ran `rm -rf build && mkdir build && cd build && cmake .. && make -j13 install` then back up to the zig directory and ran `zig build docs` to get the error.
<bgiannan> mq32, glad you pointed out to me those std.mem functions. Wrapping text in under 30loc: pub fn wrap(allocator: *Allocator, string: []const u8, width: usize) ![]u8 {
<leeward> crap
<bgiannan> assert(width > 3);
<bgiannan> var justified = try Buffer.initSize(allocator, string.len);
<bgiannan> var leftover: []const u8 = string[0..];
<bgiannan> while (leftover.len > 0) {
<bgiannan> const trimmed = mem.trim(u8, leftover, " ");
<bgiannan> if (trimmed.len > width) {
<bgiannan> if (mem.lastIndexOfScalar(u8, trimmed[0..(width - 1)], ' ')) |last_whitespace_index| {
<bgiannan> try justified.append(trimmed[0..last_whitespace_index]);
<bgiannan> leftover = trimmed[last_whitespace_index..];
<bgiannan> } else {
<bgiannan> // If no whitespace before eol, let the line as-is (should not happen)
<andrewrk> leeward, I don't think you need to rm the build folder, that's just going to make things take longer
<bgiannan> try justified.append(trimmed);
<bgiannan> leftover = trimmed[trimmed.len..];
<bgiannan> }
<bgiannan> } else {
<bgiannan> try justified.append(trimmed);
<bgiannan> leftover = trimmed[trimmed.len..];
<bgiannan> }
<bgiannan> if (leftover.len > 0)
<bgiannan> try justified.append("\n");
<bgiannan> }
<bgiannan> return justified.toOwnedSlice();
<FireFox317> ?
<leeward> andrewrk: Yeah, I just did it to be safe...but I forgot to set CMAKE_INSTALL_PREFIX.
<bgiannan> woops
<bgiannan> sorry mean to copy-paste gist link
<bgiannan> better
<FireFox317> XD
<leeward> Nice.
<andrewrk> bgiannan, new challenge: do it with O(1) memory
<andrewrk> you'll probably have to change the API to be an iterator
<andrewrk> only if you think that's a fun challenge, obviously if you're trying to get work done that could be a distraction :)
<leeward> andrewrk: It was my failure to specify the CMAKE_INSTALL_PREFIX. Move along, nothing to see here.
<andrewrk> leeward, no worries. personally, I have a softlink in ~/bin/zig to the build folder of my source checkout
<Sahnvour> andrewrk: I hope it's clear, also I just started with the async stuff so it might contain more errors than I thought https://gist.github.com/Sahnvour/13f35b72ba91c8ce305a1b95ab333341
<leeward> Mmm, that's an interesting way to do it. I wasn't sure that the only thing to install was the actual zig executable though.
<andrewrk> the zig binary finds its lib files by searching up the tree of the directory the binary resides in
<andrewrk> it looks for ./lib/std/std.zig, then ../lib/std/std.zig, then ../../lib/std/std.zig, etc
<leeward> And that works if it's invoked through a symlink?
<andrewrk> yes
<andrewrk> Sahnvour, it kinda looks like you're reinventing async/await. have you tried doing it with async/await instead?
<leeward> fun
<bgiannan> andrewrk, i'll put the idea on my list ;)
<andrewrk> leeward, combine this with -DZIG_SKIP_INSTALL_LIB_FILES=on, your `make` will get reasonably fast
<andrewrk> Sahnvour, instead of offload(), async. instead of .get(), await
<Sahnvour> andrewrk: I don't want my functions to start right away by an async call
samtebbs has joined #zig
<leeward> andrewrk: It's already under 3 minutes for a full build from nothing. Given how infrequently I rebuild it, that's fine. Good to know though.
<andrewrk> Sahnvour, are you aware of std.event.Loop.startCpuBoundOperation() ?
<Sahnvour> not until now
<Sahnvour> I'm catching up last month :) thanks
<andrewrk> the Windows I/O Completion Ports integration with std.event.Loop might need some improvements for this example to work on Windows
<andrewrk> or maybe not, I haven't tested it yet
mahmudov has quit [Ping timeout: 268 seconds]
<samtebbs> With the recent changes to casting, is the recommended way to reinterpret a struct as an integer still @bitCast?
<Sahnvour> I think what I want to do basically is a akin to the eventloop
<samtebbs> I'm getting seeminlgy random values from my packed struct each time I run my program
<samtebbs> This has been happening since the same commit that I report was causing an assertion failure earlier
<Sahnvour> but with explicit control, and not only for IO
<protty> is running some setup/tear-down logic for a given user function (instead of the user having to copy & surround their code with that setup/tear-down code) a good use case for var args? In a language like rust for example, passing in arguments to the user function could be done with a closure at the user function definition. In zig, thought it would
<protty> normally be done using var args
mahmudov has joined #zig
<andrewrk> samtebbs, yes, do you have a bug report open for this?
<samtebbs> andrewrk: Not yet, I can get a reeduced tets case and open one
<andrewrk> protty, good question. I don't have a good answer for this yet
<Sahnvour> +1 protty
<andrewrk> samtebbs, I do have packed struct improvements on my priority list here
<andrewrk> Sahnvour, you can also provide your own duck-typed event loop in the root source file and implement startCpuBoundOperation(), waitForFdReadable(), yield(), etc
<andrewrk> if you want the rest of the std lib to integrate with your event loop
<Sahnvour> andrewrk: maybe it just boils down to `@expand(.{"foo", false, null})` to go from an anonymous list litteral to a number of parameters for a function call
<andrewrk> Sahnvour, protty: if we have compelling enough use cases for that, then so be it
<Sahnvour> I'll think about it, but on the first look that's a serious drawbacks from removing var args
dimenus has joined #zig
<Sahnvour> andrewrk: the thing is I don't really care about integration with the stdlib, I want to have a set of worker threads that do asynchronous tasks I want to execute and they most likely do not contain any IO, they're pure computations
<Sahnvour> and maybe they must respect a particular ordering, so the execution must not start immediately, hence why I want to package them in a frame to be resumed later
<andrewrk> I see
<protty> Could stdlib offer up something similar to a ForkJoinPool which is user initialized and configured locally instead of globally (similar to FixedBufferAllocator's usage)?
<Sahnvour> C++ implementations I know of store a function pointer, and either keeps a void* to point to user data to pass to the function on execution, or use type erasure techniques to store parameters in a type-safe way ; I figured in zig we can just start a frame with the arguments, suspend it and then on resume : execute the function
<Sahnvour> I think that's like OS fibers but in pure userland
<Sahnvour> (minus the task switching maybe)
<andrewrk> I definitely think that std lib needs a lot of changes until it is in the final version with respect to evented I/O and async/await in general
<andrewrk> some ideas are clear to me, some are not. it will require some exploring
FireFox317 has quit [Ping timeout: 245 seconds]
<Sahnvour> I'll get references for what I meant, it's pretty standard in game engines
frmdstryr has quit [Ping timeout: 245 seconds]
doublex has quit [Ping timeout: 245 seconds]
dimenus has quit [Read error: Connection reset by peer]
<leeward> Sahnvour: That sounds an awful lot like passing a closure.
dimenus has joined #zig
<leeward> Incidentally, andrewrk, are there distinctions between async/await and closures or continuation passing that I'm not seeing?
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<leeward> (or maybe I actually understand them)
<fengb> Is this a weird pattern? `while (j < i) : (j -%= 1) {`
<fengb> Relying on overflow to break the loop
<fengb> underflow*
<Snektron> depending on what you do that can be dangerous
<fengb> var j: usize = i - 1;
<leeward> Why not `while (j >= 0)` with signed j?
<fengb> Because i is slice len
<fengb> Oh, I'm doing a +1 right now, so Ican change that to a -1
<Snektron> if you want to make it more explicit you could do and j != usize_max, otherwise i would just leave a comment near it
<Snektron> or you could write some inline assembly to query the overflow flag ;)
wootehfoot has joined #zig
<fengb> It certainly beats C, where I accidentally overflow and get infinite loops
<fengb> There's @subtractWithOverflow() but that takes an extra variable
<leeward> Is all this just to walk backwards through a slice?
bjorob has joined #zig
<fengb> Yes lol
<leeward> I feel like there's got to be a better way.
<fengb> It's an inner loop so doing subtraction makes less sense
dimenus has quit [Ping timeout: 246 seconds]
<fengb> Er, iterating down makes more sense than doing offset math
<leeward> You mean it's better than `for (_, i) |thing| { const idx = thing.len - i; ... }`?
<leeward> I kinda wonder what a compiler would do with that.
<fengb> Oh I can use a for loop for the first
<fengb> >_>
<leeward> I'm guessing it would generate something pretty good. There aren't any extra branches, at least.
<samtebbs> andrewrk: I made an issue for it at https://github.com/ziglang/zig/issues/3674
<fengb> Gotta save thos precious cycles
doublex has joined #zig
<Sahnvour> leeward: yes that's similar to closures
samtebbs has quit [Ping timeout: 240 seconds]
<andrewrk> thank you samtebbs
<andrewrk> fengb, my pattern for this: var i = slice.len; while (i != 0) { i-= 1; doThing(slice[i]); }
moo has joined #zig
<fengb> I do like comparison to 0. Pretend to be more optimized :P
wootehfoot has quit [Ping timeout: 240 seconds]
moo has quit [Read error: Connection reset by peer]
<andrewrk> Sahnvour, it could be possible to instantiate a @Frame() without calling it
<andrewrk> something like: var frame = @Frame(func){ .arg1 = foo, .arg2 = bar }; resume frame;
<andrewrk> this would not work for function pointers
bjorob has quit [Ping timeout: 240 seconds]
lunamn_ has joined #zig
<fengb> Does a while (true) expression really need an else?
<andrewrk> fengb, it's not supposed to need an else
<andrewrk> I think there's an open issue for this
lunamn has quit [Ping timeout: 268 seconds]