02:50 <daurnimator> uh, not really. mainly the JVM

02:51 <daurnimator> I run some of my systems with overcommit 2; only JVM programs give trouble

02:51 <tyler569> I think he meant like virtual machines and host migration

02:52 <daurnimator> > 09:44:08 <andrewrk>it will be ok if the kernel devs were smart enough to not get too clever and keep vm mappings separate if they came from separate mmap calls

02:52 <daurnimator> ^ did they not?

02:58 <mikdusan> https://stackoverflow.com/questions/43743555/munmap-failure-with-enomem-with-private-anonymous-mapping

03:07 <daurnimator> no seems they didn't.... adjacent mmaps are merged.

03:07 <daurnimator> that's fucking annoying

03:07 <daurnimator> (I wrote a quick test program)

05:04 <emekankurumeh[m]> really?

05:05 <daurnimator> andrewrk: so I've ended up wanting 'do while' loops quite a lot in zig

05:05 <daurnimator> one particular use case that I think might convince you, is... counting over a whole integer range

05:06 <daurnimator> e.g. imagine I have a u8 counter and I want to enumerate over 0-255

05:06 <daurnimator> var i = u8(0); while (i < 256) : (i += 1) {} // this doesn't work, as i cannot hold 256

05:07 <daurnimator> vs a 'do while': var i = u8(0); do {} while (i != 255) : (i += 1);

06:47 <gonz_> Has there been a regression in how the VS code the plug-in is able to report errors? I'm trying to use it and it's not even marking obvious things like missing semicolons.

06:48 <gonz_> It's finding the zig binary (it can format automatically) and the formatter will complain about these obvious things, but it doesn't seem to actually relay them to VS code in terms of diagnostics.

06:56 <gonz_> Also, is there a file watching mode?

07:15 <gonz_> Actually, this is trivial to do with `watchexec` so I guess it doesn't really matter: `watchexec 'zig run hello.zig'`

07:16 <gonz_> `watchexec` also targets a lot of platforms so it's pretty generally useful for these things.

11:34 <cloudhop> I'm building a shared library with an exported C interface, and I can get Zig to install the DLL to `./lib/`, but even though I can find the generated `.h` file in `zig-cache`, I can't seem to convince zig build to install it anywhere. Is there some equivilent to installArtifact that outputs the header files?

14:42 <FireFox317> cloudhop: I think you want `setOutputDir`, it should install all the files to that folder

14:48 <andrewrk> I think .h files are not handled well in the build system yet

14:48 <andrewrk> there's sort of a dependency problem in the compiler right now, because C objects are compiled before zig root source file. if the C objects depend on the generated .h file, that won't work

15:14 <scientes> ugggh, there is so much operator overloading the C++

15:14 <scientes> even if you can accept that you still never know what algorithm or data structure is being used

18:18 <terinjokes> that's frustrating, looks like the channel logs are missing messages from this morning

22:07 <gamester> Hah, I had a ton of "[]const []const u8" in my code. Arrays of slices, but with that additional const. The [_] was an excellent change, makes things much clearer.

22:09 <andrewrk> glad to hear it

22:32 <cloudhop> so, I was able to use setOutputDir to convince zig build to dump *all* the files for my library, but I think it would be more helpful if the build system placed the header files in an `/include/` directory (or even a user defined directory). Should an issue be filed on this?

22:32 <andrewrk> cloudhop, have you tried the install target?

22:32 <andrewrk> that's going to become the default target in the future

22:32 <andrewrk> err sorry, they're called "steps" not "targets" :)

22:33 <cloudhop> that's when i'm using zig build install

22:33 <andrewrk> yeah

22:34 <andrewrk> and you have to use b.installArtifact()

22:34 <cloudhop> Yes, but I already do that

22:34 <cloudhop> This does not install the headers

22:35 <cloudhop> If I comment out setOutputDir, this only installs the EXE and the DLL: https://pastebin.com/Y05V65y3

22:36 <andrewrk> this sounds like a bug in std/build.zig

22:37 <cloudhop> I've been digging around build.zig, but there doesn't seem to be *any* code that would install the header files, at least not directly. There's a lot of indirection through so it's hard for me to follow.

22:38 <andrewrk> cloudhop, hmm yes it would be in InstallArtifactStep.make and I don't see any logic for the .h file

22:40 <andrewrk> ok so it's TODO rather than a bug :)

22:40 <cloudhop> Should an issue be filed on this or do you track TODOs elsewhere?

22:40 <andrewrk> yep please file an issue if you would like to track progress on this

22:46 <cloudhop> done

22:48 <andrewrk> thanks

22:59 <cloudhop> Is it possible to export a function pointer in a C interface? I'm trying to export a function that returns a function pointer to C and i hit `TODO implement get_c_type for more types`

23:17 <terinjokes> I asked the same question yesterday. There's an issue open on GitHub for someont to decide what the generated header should look like.

23:19 <terinjokes> https://github.com/ziglang/zig/issues/2173

23:27 <cloudhop> oof

23:28 <cloudhop> if I can't export function pointers I can't... do anything

23:28 <terinjokes> do you need the generated headers?

23:28 <cloudhop> I could probably manually write the C header but I was specifically trying to avoid that

23:29 <cloudhop> The problem is that I have a seperate backend for this UI library, which is defined by a C interface that returns a struct of function pointers to all the plugin's functions

23:29 <cloudhop> so the entire C interface is all function pointers

23:30 <cloudhop> Even worse, there are going to be callbacks, which must be exported so any C compatible ABI can utilize them, which will also be problematic if zig can't export function pointers

23:31 <terinjokes> are you defining the plugin interface? or has the UI library already defined it?

23:31 <cloudhop> I'm defining it

23:31 <cloudhop> hence why i wanted to export it