00:07 <emekoi> can anyone point me to a *really* simple example of async in zig?

00:09 <emekoi> the examples in the docs are kind of confusing.

01:01 <seedofonan> I'm trying to build the Zig in the Wild project Micro:Bit Demo. The author says

01:04 <seedofonan> "Linking does not work properly with Zig" but then the codebase is also fairly old, almost 1 yr. I've corrected the small amount of bitrot so zig produces an .obj. GCC linker complains that the .obj isn't valid. So is it still expected for now that I must use LLVM's LDD?

02:51 <vegecode> Hello, I have allocated the memory for 1e6 u2's. I wanted to see how many bytes that was. I expected 250e3 bytes, but when I print the byte length by using @sliceToBytes(buffer).len, it says the full 1 million bytes is used.

02:52 <vegecode> I am using --release-fast. Is zig supposed to support packing of types like that? I thought it could for structs and imagined it would do that automatically for bit widths smaller than 8 that divide nicely into the native word size

02:56 <vegecode> Is it possible to get zig to do this on it's own or do I need to do it manually with an array of structs?

03:43 <vegecode> Can a function require a slice of a specific width?

03:43 <emekoi> what do you mean by width?

03:44 <emekoi> is it an error if your code compiles fine, but you don't cancel or await any of the promises you make?

03:46 <vegecode> I don't know anything about concurrency in Zig.

03:47 <vegecode> What I mean is can I have a compile time check that a slice parameter to a function has a minimum number of indices?

03:47 <vegecode> If I need six numbers in the array, I would like it to require slices of at least that width and fail to compile instead of failing at runtime

03:48 <emekoi> i don't think you can because a slice's length is a runtime value

03:49 <vegecode> Thanks, that's what I thought too.

04:34 <MajorLag> vegecode: even packed structs are subject to alignment rules when in arrays. There currently isn't a concept of a packed array.

04:35 <daurnimator> This is one of the problems with the current @sizeOF

04:35 <daurnimator> it gives the size of an array element. not the actual size...

15:47 <wink__> Need to build zig on windows, the wiki page says to use VS 2017 15.8. Two Q's, will the community version work and the download page has 15.9 has that been tested with zig?

17:19 <seedofonan> I'm trying to build the Zig in the Wild project Micro:Bit Demo. The author says "Linking does not work properly with Zig" but then the codebase is also fairly old, almost 1 yr. I've corrected the small amount of bitrot so zig produces an .obj. The linker from GCC ARM embedded complains "zig-cache\test.obj: file not recognized" -- a lot worse than "not work properly". Is that expected, or am I probably doing something wrong?

18:28 <Hejsil> --test-filter is not very useful... If your global test that imports all other tests doesn't match the filter, then no tests are run...

19:02 <j`ey> seedofonan: you can run 'file' on it

19:10 <seedofonan> j`ey, I don't understand about 'file'. What should I try?

19:11 <j`ey> file zig-cache\test.job

19:11 <j`ey> oh, this is on windows?

19:41 <seedofonan> j`ey, yes, on windows. What help is the file test.job? There isn't one in my zig-cache, though.

19:41 <j`ey> I meant obj, not job

19:56 <seedofonan> I got past last problem. My link needs "--target-environ eabi". On to the next. Thanks j`ey and anyone listening :-)

19:57 <seedofonan> I mean, my zig.exe build-obj needs "--target-environ eabi"

20:35 <MajorLag> When did @field get updated to support accessing non-field type-namespaced definitions? The things I miss without the chatbot. I'll have to find a way to keep abreast of the changes without it.

20:39 <Hejsil> MajorLag, I dont think @field has changed since it was added. It should work the same as a.b, for any types of a

20:46 <MajorLag> Oh wait, you're right. The issue wasn't calling it on type.definition, it was trying to use it to get the type of a field from a type using @typeOf(@field(T, field_name)). Nevermind. Still, I should track changes better.