00:15 <tiehuis> ganderzz: you are returning a stack local variable 'buffer' from that clean function. I would suggest instead taking a slice of bytes as a parameter which the function can write to

00:20 <schme245> how do I allocate a struct on the heap?

00:21 <andrewrk> schme245, you need an allocator

00:21 <schme245> and then `allocator.create`?

00:22 <andrewrk> the best place to get one depends on what kind of application you are making. if you're linking libc, you probably want std.heap.c_allocator. if you're making a command line application, I recommend the example set by std/special/build_runner.zig. if you're making a library, you should probably accept an allocator as an argument

00:22 <andrewrk> allocator.create/destroy is for a single-item pointer; allocator.alloc/free is for slices

00:23 <schme245> gotcha, I'm familiar with allocators but I've only been using them with slices so far, thanks

02:05 <mikdusan> given struct ‘Foo’ that has field ‘code: [10]u8,’ how to get the size of ‘code’? i can hardcode a const def in the struct, but is there something convenient like @sizeOf(Foo.code)?

02:05 <andrewrk> code.len

02:05 <andrewrk> that's if you have an instance

02:05 <mikdusan> i need it while initilizing the struct

02:06 <mikdusan> so: .code = []u8{0} ** __SIZE_OF(Foo field code)

02:08 <andrewrk> I recommend a def, but if you don't want to do that you can use @sizeOf(std.meta.fieldInfo(Foo, "code").field_type)

02:09 <mikdusan> 👍

04:21 <ganderzz> tiehuis: Shoot, I'll look into that. Thanks!

06:18 <andrewrk> alright that merge should fix the CI of master branch

06:22 <mikdusan> re: last commit comment; I honestly read “ziglang/caching” as “ziglang ka-ching!”

06:28 <andrewrk> zig build has full caching now

06:29 <andrewrk> well, at least for zig objects, libraries, and executables

07:03 <emekankurumeh[m]> nice!

08:14 <emekankurumeh[m]> andrewrk builds on mingw are broken, i'm getting linker errors about undefined references to symbols from z3.

09:23 <emekankurumeh[m]> nevermind, i fixed it.

09:25 <emekankurumeh[m]> andrewrk: does windows even have the concept of dynamic linkers?

09:35 <dewf> do you mean something other than linking against or runtime loading a DLL?

14:46 <andrewrk> emekankurumeh[m], maybe in the context of mingw/cygwin? I'm not sure

16:05 <kristate_> andrewrk: did you see the man page for macos re: mtime?

16:06 <kristate_> andrewrk: Variants which make use of the newer struc- tures have their symbols suffixed with $INODE64. These $INODE64 suf- fixes are automatically appended by the compiler tool-chain and should not be used directly.

16:07 <kristate_> I will take a look at the new caching implementation,

16:22 <andrewrk> we're already doing the inode64 thing in os.cpp

16:22 <andrewrk> it happens automatically in C

16:25 <kristate_> yeah, this is stage1

16:26 <kristate_> did some tests, seems like HFS partitions are rounding to nearest second -- APFS is working

16:26 <mikdusan> andrewrk: re: recent commit, macos HFS+ has a mtime resolution of only 1 second. the newer APFS apparently has 1 ns resolution

16:27 <kristate_> andrewrk: shouldn't we check hashes if mtime is the same?

16:27 <andrewrk> kristate_, the whole point of mtime is to avoid the cost of hashing the file

16:28 <kristate_> andrewrk: right -- if mtime is the same, then we could revert to hasing

16:28 <kristate_> hashing

16:30 <andrewrk> that doesn't avoid the cost of hashing the file on cache hit

16:31 <kristate_> andrewrk: ah, to clarify, we could do it only if tv_nsec was 0

16:31 <andrewrk> that's an interesting idea

16:33 <kristate_> do you want to write the patch or should I? :-)

16:37 <andrewrk> I want to consider it more before a patch

16:37 <andrewrk> it wouldn't be strictly an improvement - there are pros and cons

16:38 <kristate_> andrewrk: I think it is an improvement where it comes to correctness.

16:38 <kristate_> sure, we have a speed penalty, but right now as it stands, the caching sub-system is incorrect on macos for HFS partitions

16:38 <andrewrk> yes exactly, and it is worse in terms of performance for the use case where source files will be modified by users

16:39 <andrewrk> even nanoseconds is technically incorrect

16:42 <andrewrk> "strictly an improvement" means it is categorically better in all use cases

16:42 <andrewrk> when something is strictly an improvement, a patch is always welcome. otherwise, sometimes, more deliberation is required

16:42 <kristate_> andrewrk: well, in that case we should remove mtime.

16:44 <kristate_> Also, I am wondering what your list of pros/cons are?

17:17 <emekankurumeh[m]> andrewrk, I don't think so. I've never heard of a dynamic linker for mingw.

17:57 <Akuli> how do i loop over a HashMap so that i destroy each keyvalue pair in the loop? the hash function must not be called on destroyed keys

17:58 <Akuli> i'm thinking of: while (hm.iterator.next()) |kv| { _ = try hm.remove(kv.key); destroy the keyvalue pair; }

17:58 <Akuli> but that seems to be quite inefficient, looking at the implementation of remove()

22:38 <andrewrk> I think I can make the caching perfect, even when the file system only has resolution down to seconds, without giving up skipping the expensive hash in the common cases

22:51 <andrewrk> after fstating a file and collecting its mtime, also look at the clock time, rounded down to the same resolution as the mtime. if they match, this file is too "fresh" and the mtime cannot be relied on - a future write could have the same mtime. it will have to be hashed next time as well as this time.

23:49 <emekankurumeh[m]> i don't know if it's zig's fault or lld's fault but lld is segfault whenever zig tries to link executables.