03:01 <wilsonk> andrewrk: thought I would take a quick stab at issue #4020, bit if I modify ir.cpp so that ir_resolve_fn() is only called if CallModifier is always_inline, compile_time or async_kw then a new error comes up: 'cannot assign to constant'. There are only two spots that can happen: ir.cpp:17920 or 17940. 17940 is where the actual error message originates from so I assume allow_write_through_const is false when it should be true? Maybe?

05:35 <andrewrk> happy new year from -0500

05:42 <leeward> \o/

11:39 <daurnimator> http://cliffle.com/blog/m4vga-in-rust/ they should have tried zig :P

12:17 <companion_cube> maybe they wanted a stable language though :)

13:01 <Snektron> daurnimator, i found an old laptop with an i486, so maybe ill try to make something for that in Zig

13:01 <Snektron> it also has vga graphics

13:23 <daurnimator> Snektron: would be more interesting to see zig running on stm32 devices

13:24 <daurnimator> is espressif in llvm 10?

14:07 <daurnimator> no :(

14:23 <frmdstryr> daurnimator: zig already works on stm32 devices, there's 2 projects on github

14:23 <frmdstryr> i've also got it working on one yesterday

14:24 <frmdstryr> the problem is porting all the drivers which are all in c

14:24 <daurnimator> frmdstryr: link?

14:24 <daurnimator> frmdstryr: yeah I figured as much. though @cImport should get you pretty far right?

14:24 <frmdstryr> https://github.com/tralamazza/embedded_zig

14:25 <frmdstryr> https://github.com/yvt/zig-armv8m-test

14:25 <frmdstryr> haven't tested the armv8 one, i don't have one of those laying around

15:24 <protty> is there a way to guarantee struct field layout order without using `extern struct`?

15:24 <fengb> Packed struct

15:24 <protty> do you have to specify the alignment of each field manually or does it still do that in a packed struct?

15:25 <fengb> Every field is assumed to be align 0

15:25 <fengb> So you’ll have to manually align them. And zig gets confused if the struct isn’t a multiple of 8 bits

15:27 <fengb> If you’re not actually packing, extern is fine since C struct alignment is well defined

15:28 <fengb> Actually wait... no it’s not. Forget I just said that

15:28 <protty> so extern struct all the way down?

15:30 <protty> hm, how would you go about fitting std structs in there as well?

15:32 <protty> nvm, think I can do this with alignment on fields instead

17:56 <andrewrk> protty, you probably need https://github.com/ziglang/zig/issues/3133 to use packed structs for your use case

18:50 <swoogan> can the run step in a build.zig execute an arbitrary command?

18:50 <andrewrk> yes

18:51 <andrewrk> swoogan, here's an example: https://github.com/andrewrk/clashos/blob/69b0fd199aa57c7807a7e07fadeaa05f55abf308/build.zig#L33

19:04 <swoogan> thank you

20:08 <schme245> in this code, is the if statement guaranteed to get inlined since the `encrypted` parameter is known at compile time? or does that only apply to comptime variables?

20:08 <schme245> https://github.com/schmee/zig-crypto/blob/master/src/des.zig#L293-L332

20:08 <schme245> `encrypt` parameter, sorry

20:09 <andrewrk> schme245, in order for encrypt to be known at compile time, you will need to annotate it with `comptime`

20:09 <andrewrk> but if you do that, then, yes

20:09 <schme245> hmm, that leaves me with an interesting conundrum

20:10 <schme245> I want to have the `desCryptCbc` method available in the API to give users flexibility, but I also want to use it to DRY up my code

20:10 <schme245> does that mean I need two versions of that function, a private one where `encrypt` is comptime, and a public one where it's not?

20:10 <andrewrk> do you actually need encrypt to be comptime known for semantic reasons? or are you considering performance?

20:10 <schme245> it's for performance

20:11 <andrewrk> have you measured it with and without making it comptime? I predict there will be no difference

20:11 <schme245> I agree, but I still think it's interesting whether this is possible or not

20:11 <andrewrk> sure, you can make your API whatever you want

20:18 <schme245> I'm trying to understand if it's possible to avoid this duplication: https://github.com/schmee/zig-crypto/compare/asdf?expand=1

20:19 <schme245> the only difference between desCryptCbcInline and desCryptCbc is that encrypt is comptime

20:19 <schme245> I understand that it doesn't matter for performance in this case, but there might be others where it does

20:24 <andrewrk> where's the duplication?

20:24 <andrewrk> that looks fine to me

20:25 <schme245> sorry, easier to see like this: https://github.com/schmee/zig-crypto/blob/be7256f836f00b5f53e0911acb3f42dbe8c8b737/src/des.zig#L293-L357

20:27 <andrewrk> oh, have desCryptCbc do an if on encrypt, and call desCryptCbcInline with comptime known encrypt

20:28 <andrewrk> I would also suggest enum{encrypt, decrypt} instead of bool

20:28 <andrewrk> make it first parameter too, and then API becomes: desCryptCbc(.encrypt, keys, iv, inData, outData)

20:29 <schme245> sorry, how do I call a fn with a comptime known parameter? I thought that had to go in the fn signature

20:30 <andrewrk> with an `if` on encrypt, within each branch of the `if` you have comptime-known encrypt

20:30 <andrewrk> if (x) foo(true) else foo(false)

20:30 <andrewrk> this will work even if foo has a comptime parameter

20:30 <andrewrk> definitely do the enum thing though, kill that bool

20:32 <schme245> alright, gimme a minute and I'll see if I got this straight

20:40 <schme245> ahh so it would be like this then: https://github.com/schmee/zig-crypto/compare/asdf?expand=1

20:41 <azth> Hi all. When I run this locally (compiler version `zig-macos-x86_64-0.5.0+25051832b`), the program exits with a `SIGBUS (Misaligned address error)`. Link to program: https://godbolt.org/z/vooLCw

20:42 <azth> However, if I change line 10 to `var point = I32Wrapper{.x = 10}`, and call `var p = foo(&point)` it exits without errors.

20:45 <azth> Actually, I was able to reduce it to:

20:45 <azth> ```

20:45 <azth> https://godbolt.org/z/TovbYf

21:09 <schme245> andrewrk: just updated the code with your suggestions, thanks a lot for your time! :)

21:10 <schme245> also, is DES of interest for the std lib? there's already AES in there, and while it's preferable there are many protocols which depend on DES

21:11 <hryx> Can anyone remind me how to build without @panic? I have the boilerplate code with `export fn entry` and `pub fn panic` but I forget if there's a required build flag

21:12 <fengb> release-fast should remove panic

21:14 <andrewrk> fengb, are you thinking of unreachable? @panic is defined to call the panic handler in all build modes

21:14 <andrewrk> hryx, you're trying to get a minimal file for debugging zig ir, yes?

21:14 <fengb> Oh I thought the question is removing the handler

21:14 <fengb> For unreachable

21:15 <hryx> andrewrk: exactly. actually I was trying to shrink the output of what azth linked (but they just left)

21:15 <hryx> er, not zig IR in that case, but the asm

21:16 <andrewrk> https://gist.github.com/andrewrk/5684434a2a8d4cbb08bb0d855c4f2ada

21:16 <hryx> thanks! I know mikdusan had a gist previously but looks like it's gone

21:17 <andrewrk> oh, nice, I think mikdusan put it in the FAQ: https://github.com/ziglang/zig/wiki/FAQ#i-would-like-to-use---verbose-ir-but-it-is-really-loud-how-can-i-focus-the-compiler

21:18 <hryx> ah, cool

21:19 <andrewrk> fengb, you are correct that if the panic handler is proven unreachable by the optimizer, it will be removed

21:19 <andrewrk> in a large application this is unlikely to be the case however

21:20 <fengb> Technically correct but not helpful. That’s me! :P

21:27 <hryx> Ahhhh now I see what I was doing wrong. I was using `zig run` instead of `zig build-obj`. derp

21:30 <schme245> andrewrk: DES in std lib, yay or nay? (reposting my question from above in case you missed it, if not, sorry for spam!)

21:31 <andrewrk> schme245, yay with the caveat that it may be removed during https://github.com/ziglang/zig/issues/1629

21:33 <schme245> cool, I'll take a look at the other crypto in std and see if it makes sense to match the existing APIs!

21:33 <schme245> also, same caveats as for AES re timing attacks etc applies ;)

21:34 <andrewrk> yes, the relevant issue for that is https://github.com/ziglang/zig/issues/1776

21:43 <traviss> schme245, did you ever post your code for benchmarksgame? i was curious to see how you got vectorization to work for the nbody problem.

21:46 <schme245> well, as expected, it turns out I'm a dunce and the actual numbers are ~4-ish for my code and 2.6-ish for Rust

21:46 <schme245> next up now that I'm done with DES is to see if I can beat it with @Vector

21:47 <schme245> let me throw the code of the anyways

21:50 <schme245> wow, that'suuuh... one hell of a sentence xD anyway, here's the code: https://github.com/schmee/zig-experiments/blob/master/nbody.zig traviss

21:50 <schme245> traviss: ^

21:50 <traviss> ah. thats still sounds like a pretty good time. i tried myself to port the nbody-gcc-8.c solution but ran into problems related to _mm_cvtps_pd and similar

21:51 <traviss> thank you :)