02:05 <MajorLag> because of the limitations of comptime, even FixedBufferAllocator isn't really very useful. For instance, you can't use ArrayList at comptime.

02:57 <andrewrk> Oh that's right. Allocator depends on @ptrCast. That's one reason I want to make it work at comptime

02:58 <andrewrk> There's a problem though - types that don't have a guaranteed byte layout, such as structs

04:00 <MajorLag> It is possible to get an instance of type `(block)` into a variable. This doesn't appear to have any useful implications, I just thought it was interesting.

04:49 <Braedon> Hey all, hows it going :) Just want to gather a little more opinion on locales, currently I'm planing to use CLDR (the official unicode repository of data) and at compile time downloading the relevant files and baking that information into the application

04:50 <Braedon> Though only doing it for the locales that the user requests in their build.zig

04:51 <Braedon> Which of course they could select all of them :), then lets say they select 'tr-TR' they would get information like `locale.getLocaleByTag("tr-TR")` which is a compile time function only :)

04:53 <Braedon> If they wanted to do a generic any tag kind of solution they would have to import all locales in their build.zig file which would of course bloat the binary a little then they would have to call the function `locale.getLocaleByTagRuntime(tagName)`

04:54 <Braedon> Locales will have effectively the same information as the 'defaultLocale' which can be loaded in by well `locale.getDefault()` or `locale.getCurrent()` (since default != current in all circumstances), but that doesn't require baking (though it would for some functions such as toUpper/toLower)

04:56 <Braedon> Side note: locales like Ascii and the Full unicode which really are not 'locales' but just kind of piggy back on the system to get functionality desired like doing an ascii locale would be used for archaic systems are baked without user input, since they will also often be used for the generic functions like `atoi` which are dependent on locale :)

10:35 <abique> Hello

10:41 <abique> I did not understand well how the namespace works in zig

10:41 <abique> Does zig have namespace?

10:56 <tiehuis> is this in regards to imports or just if you can namespace things in a file, like C++ namespaces?

10:58 <tiehuis> you can pretty much do namespaces by just using a struct and not defining any member functions/variables

11:00 <tiehuis> have an INFLATE implementation working by the way

11:01 <tiehuis> just doing some round-trip testing against zlib but will probably finish that tomorrow

11:01 <tiehuis> spent an hour wondering why it wasn't seeming to work and it turned out I was using a wrong test vector

11:06 <abique> Thank you for the struct info

11:07 <abique> But the drawback of using a struct for namespace is that you can't have many files into the same namespace

11:07 <abique> If you take in c++ for example std is defined in many places and can be extended in new files

11:07 <abique> But you can't do that in zig right?

11:08 <tiehuis> no, not like that

11:09 <tiehuis> although, you can re-export multiple files into the same namespace and link different files into the same namespace

11:09 <tiehuis> if you look at the std library, it does this a lot with all the `index.zig` files

11:11 <tiehuis> this does have the advantage over c++ namespaces in that it's just a tree all the way up so if you wanted to scan sub-dependencies of imported files you just need to follow the imports

11:15 <abique> cool

11:27 <abique> tiehuis: what stage is currently zig?

11:27 <abique> is the language more or less finished?

11:28 <abique> and only the standard library remains

11:28 <abique> or you expect that the language will change a lot until version 1.0?

11:29 <tiehuis> no, i still think there are various things that we want to be solved, definitely best to ask andrewrk this

11:37 <abique> I'm looking for a new langage, tired of C++, I don't understand rust at all but zig still seems early stage..

11:43 <abique> By the way

11:43 <abique> I did not find vector type

11:43 <tiehuis> that is named ArrayList

11:43 <abique> I mean like llvm's vector type

11:44 <abique> so you can do SIMD

11:44 <abique> For math

11:44 <tiehuis> oh, simd hasn't really been looked at as far as I'm aware

11:44 <abique> Make it a priority

11:45 <abique> Also LLVM already provides everything you need

11:45 <tiehuis> yeah, i'd like to try a few things with it at some point and have seen the llvm support

11:45 <abique> you just have to expose the llvm vector type :)

11:45 <tiehuis> i'll make an issue now to make a note and get any discussion going

11:46 <abique> Great :)

11:48 <abique> how many people are developing zig?

11:49 <tiehuis> a few people somewhat actively maybe, ~6-7 with regularity?

11:50 <tiehuis> that's just on the compiler stuff, there are others who are writing their own projects which also helps in figuring out use-cases/bugs etc

11:51 <abique> Who's behind this project? Is there any company?

11:52 <tiehuis> not that I'm aware, it was started by andrewrk

11:52 <abique> And most of you are in America / Europe ?

11:53 <tiehuis> most are i think, although im not

12:08 <tiehuis> made an SIMD issue here: https://github.com/zig-lang/zig/issues/903

12:09 <tiehuis> it is pretty barebones at the moment since it's late and i don't write much simd

12:09 <tiehuis> if anyone is more familiar and/or has some strong opinions then post any discussion there

12:10 <abique> ok

14:29 <raytracer[m]> andrewrk: I was able resolve my problem with smallpt(https://github.com/raytracer/zig-smallpt). I was returning a &const Vec(T) in the radiance function for some reason. I changed it to a regular Vec(T) and that resolved the issue though I don't know why it ever worked in debug mode.

14:29 <MajorLag> Something strange is going on in debug mode. I had a similar issue, but it only seemed to affect win32.