ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
ntgg has joined #zig
doublex has quit [Ping timeout: 245 seconds]
itsMontoya has quit [Remote host closed the connection]
doublex has joined #zig
ntgg has quit [Ping timeout: 268 seconds]
ntgg has joined #zig
doublex has quit [Quit: Quit]
doublex has joined #zig
mmx870 has quit [Quit: Ping timeout (120 seconds)]
mmx870 has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
doublex has quit [Quit: Quit]
doublex has joined #zig
konv has joined #zig
konv has quit [Remote host closed the connection]
chemist69 has quit [Ping timeout: 245 seconds]
chemist69 has joined #zig
mahmudov has quit [Remote host closed the connection]
cyanmide has quit [Ping timeout: 245 seconds]
mmx870 has quit [Ping timeout: 240 seconds]
mmx870 has joined #zig
ntgg has quit [Ping timeout: 240 seconds]
LargeEpsilon has joined #zig
<Gertm> How far along is Zig in terms of libraries? I couldn't find a reference to that on the website.
<Gertm> Not the stdlib, but third party libraries. Or is this too early in Zig's development still?
konv has joined #zig
tdc has quit [Ping timeout: 240 seconds]
earnestly has joined #zig
tdc has joined #zig
ltriant has quit [Quit: leaving]
kristoff_it has joined #zig
_Vi has joined #zig
kristoff_it has quit [Ping timeout: 265 seconds]
kristoff_it has joined #zig
Ichorio has joined #zig
tdc has quit [Read error: Connection reset by peer]
Ichorio has quit [Ping timeout: 246 seconds]
kristoff_it has quit [Remote host closed the connection]
tdc has joined #zig
hasanyasin has joined #zig
avoidr has joined #zig
hasanyasin has quit [Remote host closed the connection]
samtebbs has joined #zig
<samtebbs> Hi all. What would be the best way to read a packed struct T from a file?
<mikdusan> binary? you could write it out usual way. then later open file, mmap, close file, cast and copy, munmap
<samtebbs> Ok, that sounds a bit more complicated than just reading in the fields (they're all integers) and assigning them to an instance of the type.
<samtebbs> In C I would do something like `T t; read(file, &t, sizeof(T));`
<mikdusan> that'll work too
<mikdusan> std.mem.toBytes() and std.mem.asBytes() would be of service
tencho has joined #zig
<tencho> Hello.
<tencho> How do I make a struct non copyable ?
return0e_ has joined #zig
return0e has quit [Ping timeout: 240 seconds]
<samtebbs> mikdusan: oh nice, thanks
<mikdusan> tencho: i believe zig does not currently support non-copyable. but see these 2 issues that discuss it:
rifkik has joined #zig
<rifkik> Can you please merge this?
<rifkik> or is there something preventing you?
<tencho> mikdusan: Thanks! Aha I had the second problem yesterday. I took me some time to figure it out.
samtebbs has quit [Ping timeout: 240 seconds]
Barabas has joined #zig
vpzom has quit [Remote host closed the connection]
Snektron has quit [Remote host closed the connection]
BitPuffin has quit [Read error: Connection reset by peer]
Demos[m] has quit [Read error: Connection reset by peer]
vegai has quit [Remote host closed the connection]
dtz has quit [Write error: Connection reset by peer]
jzck has quit [Remote host closed the connection]
fengb has quit [Remote host closed the connection]
D3zmodos has quit [Remote host closed the connection]
<Sahnvour> andrewrk: ah, yes, the mandatory codegen bugs with new cl.exe ;)
BitPuffin has joined #zig
slice has quit [Quit: cya]
slice has joined #zig
<Barabas> It's so hard to find out what version you have of what in visual studio...
<Barabas> It really is amazing how they manage to make such a mess of things
Barabas has quit [Remote host closed the connection]
Gertm has left #zig ["WeeChat 2.3"]
dingenskirchen has joined #zig
Barabas has joined #zig
Demos[m] has joined #zig
dtz has joined #zig
jzck has joined #zig
fengb has joined #zig
D3zmodos has joined #zig
vegai has joined #zig
<Sahnvour> Barabas: since VS 2017 it's actually OK by using visual studio installer, not the mess it used to be
<Barabas> Yeah it got better
<Barabas> Still they manage to put vcvars in a different magical place every time, and finding the version of the compiler is ehm... well just use the command line :P
tencho has quit [Quit: WeeChat 1.4]
<tgschultz> samtebbs: there is also serializer/deserializer in the standard library for more precise control and handling things like differing endianess.
shachaf has quit [Ping timeout: 245 seconds]
shachaf has joined #zig
kllr_sbstn has joined #zig
rifkik has quit [Read error: Connection reset by peer]
kenaryn has joined #zig
<kenaryn> Hello, my good people.
<kenaryn> Please, is there any difference in time (i.d. microprocessor cycles) and/or space (i.d. memory) between a std.testing.except and a std.debug.assert instruction?
<kenaryn> testing.expect*
<kenaryn> I'm asking because both have some use cases in common.
kllr_sbstn has quit [Ping timeout: 264 seconds]
kllr_sbstn has joined #zig
<dingenskirchen> expect calls the panic handler, but assert invokes safety checked UB
<dingenskirchen> ie you can't rely on assert in release modes
<dingenskirchen> in debug mode it shouldn't make a difference since unreachable code (assert) just jumps to the panic handler too
<fengb> You can in release-safe
<dingenskirchen> true.
<kenaryn> What does it mean UB?
<kllr_sbstn> UB = undefined behaviour
<fengb> Undefined behavior
<fengb> Fancy way of saying the optimizer can do whatever it wants to
<kenaryn> Allright, thank you dingenskirchen, fengb and kllr_sbstn
<fengb> Assert is preferable in normal code if it’s a developer error
<fengb> And if it’s an actual error case, it should be handled with an error return
<kenaryn> Duly noted in a knowledge base. :)
_Vi has quit [Ping timeout: 276 seconds]
kllr_sbstn has left #zig ["WeeChat 2.6"]
drazan4 has quit [Remote host closed the connection]
<kenaryn> I would like to add there is a discrepancy between undefined and unspecified. The former one deals with invalid data construct or invalid data input while the second one deals with valid data construct or valid data input (see: But in Zig, the terms are used in a interchangeable way: see 'undefined' primitive value in the official documentation:
<fengb> I’m curious how many of these issues Zig’s debug allocator can catch at dev time
kenaryn has left #zig ["WeeChat 2.3"]
halosghost has joined #zig
_Vi has joined #zig
traviss has quit [Read error: Connection reset by peer]
<_Vi> How do I make u32 enum of various "recognized" values, but also with support of custom values that has no official variant? Like `union(enum) { Variant1 = 0x1234, Variant2 = 0x5544, ..., Unknown: u32,}`, without exceeding u32?
waleee-cl has joined #zig
<_Vi> Also how do I fill in large enum variants in comptime?
samtebbs has joined #zig
kllr_sbstn has joined #zig
kllr_sbstn has left #zig [#zig]
doublex has quit [Ping timeout: 245 seconds]
samtebbs has quit [Ping timeout: 268 seconds]
<_Vi> How do I include one Zig source file into another (without creating a struct wrapper)? Like `const content = [_]u32 = { @include("content.zig") };`?
<mq32> _Vi, what do you want to achieve?
<mq32> @import already returns you a struct type (which is used as a namespace)
<_Vi> mq32, Include a generated part (based on information from network) without using trailer/footer in the source file.
<mq32> i would recommend a precompiler step
<andrewrk> Sahnvour, we can downgrade to MSVC 2017 if you think that's a good idea
<andrewrk> I'll have to rebuild the windows tarball and update all the wiki instructions
doublex has joined #zig
sarahzrf has joined #zig
<sarahzrf> hi
<sarahzrf> im having trouble trying to do what essentially amounts to an algebraic data type
<sarahzrf> i think the problem is actually visible in the minimal case of just a binary tree with empty leaves, so—how would you write down that type in zig?
<sarahzrf> basically, it seems like if i try to do a self-referential tagged union where one of the variants needs to be an aggregate containing the self-reference, such as in a branch node of a binary tree, i have two options, both of which cause problems:
<sarahzrf> 1. try to factor out the aggregate—in which case i get an error about there being a dependency loop;
<sarahzrf> 2. use an anonymous struct type—in which case, how do i construct values?
<mq32> sarahzrf, you can use something like this:
<sarahzrf> i suppose in the simple case of a binary tree you could get away with nullable pointers, but that won't cut it for me, since i have a bunch of variants
<mq32> const Tree = struct { const Self = @This(); left : ?*Self, right : ?*Self };
<mq32> @This() allows self-referencing
<sarahzrf> ooh, if i make a local definition in terms of @This() instead of in terms of Tree, will that get rid of the dependency loop error
<sarahzrf> nope, it didn't :
<sarahzrf> nope, it didn't :|
<sarahzrf> mq32: that's not what my problem is, though
<sarahzrf> here, i can post my actual type for clarity if you like
<Cadey> how would I do memory-mapped I/O in zig?
<Cadey> assume no OS
<Cadey> like writing and reading to arbitrary addresses
<sarahzrf> what ive pasted up there works fine, but im not sure how to actually /construct/ values of that type, since i dont have names for the fields of the Tens, Par, etc variants
<andrewrk> Cadey, if memory has side effects (e.g. MMIO) then you want volatile.
<tgschultz> _Vi, if you're including binary data (an array of u32s) you can generate it as actualy binary data and use @embedFile `const content = @bytesToSlice(u32, @embedFile("content.bin"))`. This assumes the same endianess of course.
<sarahzrf> *names for the types of the fields
<andrewrk> Cadey, there are a bunch of great bare metal zig projects to look at if you get stuck
samtebbs has joined #zig
<andrewrk> also #osdev is nice
<_Vi> tgschultz, Is it a good idea to generate functions and types based on `@embedFile` content in comptime? E.g. embed a `*.proto` Protobuf file and generate serializable Zig struct for it.
<samtebbs> mikdusan: Congrats on joining zig :)
<Cadey> andrewrk: thanks!
<mq32> sarahzrf: just name your struct types ;)
<andrewrk> Ah yes, please everybody welcome mikdusan as the newest Zig core team member!
<mq32> TensTerm instead of literal type
<halosghost> :D
<halosghost> mikdusan: congratulations!
<sarahzrf> mq32: as i said when i initially asked my question, that creates a dependency loop error
<konv> mikdusan, congrats!
<sarahzrf> at least, whatever it is that i've attempted does
<sarahzrf> so if you know a way of naming them that won't cause that error, please show me the actual code :)
<mq32> sarahzrf, give me a second
<andrewrk> sarahzrf, if you have a small code example that has a dependency loop error, and it seems like a false positive, can you open an issue for that? I recently introduced this concept "Lazy Values" to break such dependency cycles, but I don't think I covered everything
<sarahzrf> aaaaaaa
<tgschultz> _Vi The issue you will have is that there is no way to create a new struct at comtime with a dynamic number of fields. I created the PseudoStruct as a demonstration of how to do the same thing in userland code though.
<sarahzrf> maybe later...
<sarahzrf> btw, how much inlining does zig do
<sarahzrf> of function calls, sorry
<andrewrk> sarahzrf, you can semantically force inlining at the callsite or at the function definition. After that, nothing is semantically guaranteed by the language; it's up to codegen (which is LLVM in this case) how much inlining it does
<tgschultz> _Vi: I should clarify *effectively* the same. By necessity the access pattern is more like a hashmap than a native struct, but it will compile down to the same code.
<andrewrk> sarahzrf, in other words, it's state-of-the-art inlining
<sarahzrf> hrm
<sarahzrf> im currently rewriting a small C file into zig, 1/2 because i would rather be using rust but im using pointers in a way that rust is not meant for and zig is an ok compromise, and 1/2 because im wondering if i can fine tune the inlining of some of it
<sarahzrf> so if clang wasnt already inlining something, it probably wont in zig if i dont ask it to with the @
<sarahzrf> ?
<sarahzrf> mq32: wait, i couldve sworn i tried that!
<sarahzrf> what the heck
<mq32> also works with BinaryTerm outside of the term definition
<mq32> are you on 0.5.0?
<mq32> brb
<sarahzrf> oh
<sarahzrf> no, i'm on 0.4.0
<sarahzrf> i guess that explains it ;A;
<mq32> re
<sarahzrf> well, no, it doesn't, because i changed it to 0.4.0 on godbolt and it still compiled
<sarahzrf> hmm
<sarahzrf> oh wait what on earth
<sarahzrf> okay, i figured it out
<sarahzrf> the problem is that what i tried was actually a more thorough version of what you posted
<sarahzrf> with a few more definitions
<sarahzrf> and the dependency loop error was coming from a different one
<sarahzrf> namely: i was defining Node inside Term, and using it for Link and so on
<sarahzrf> and *that* was unacceptable, i guess
<sarahzrf> ??
<sarahzrf> but defining it inside Term and then using it to define Nodes and then using Nodes is fine
<sarahzrf> yall got a weird language
<sarahzrf> oh no wait it's not fine to use it to define Nodes
<sarahzrf> but it /is/ fine to use it to define BinaryTerm
<sarahzrf> ¯\_(ツ)_/¯
<sarahzrf> oic, is struct {} lazy but * isn't?
konv_ has joined #zig
konv_ has quit [Remote host closed the connection]
LargeEpsilon has quit [Ping timeout: 240 seconds]
konv has quit [Ping timeout: 268 seconds]
doublex has quit [Ping timeout: 240 seconds]
Tetralux has quit [Ping timeout: 245 seconds]
LargeEpsilon has joined #zig
ntgg has joined #zig
<Sahnvour> mikdusan: congrats !
<Sahnvour> andrewrk: are we sure we hit the same bug as the ticket linked in ?
<andrewrk> Sahnvour, I can't be completely sure, but reading the thread it does seem to match
<Sahnvour> disabling optimizations on buffer.cpp doesn't make the bug disappear, so I doubt it's linked to the fnv hash
<Sahnvour> let's see what RelWithDebInfo has to say
<Sahnvour> build passes ... great. maybe CMake is doing a bit more than just enabling debug info in this target
<_Vi> Is it OK to use `type` as identifier?
<scientes> no
<scientes> _Vi, type is a keyword
<_Vi> It seems to be accepted without warnings.
<mq32> afaik type is not a keyboard, but just a name
<_Vi> `fn type()void{}` `struct { type : u32 }`
<mq32> (as type is a type variable)
<scientes> hmm, there were some changes
<scientes> of semi-keywords
<_Vi> If no, what to use instead?
<scientes> much as you can name a variable "true" in C
<_Vi> `type_`, `typ`, `typee`, `typE`?
<Sahnvour> _Vi: keywords can be used as identifiers with the @"" operator, for example @"fn"
<andrewrk> convention is to make names of types TitleCase
<scientes> ^
<andrewrk> so, Type or even T is pretty OK
<_Vi> Is `@"type"` a recommended variant for naming a function or struct field that denotes some sort of type?
<Sahnvour> probably not
<andrewrk> also related: counterintuitively, zig might benefit from making more things keywords, because then we can use @"syntax"
<Sahnvour> iirc it's mostly needed for interfacing with C where identifiers can exist that are reserved in zig
<_Vi> In Rust it is OK to use similar feature (`r#some_name`) not only for compatibility, but also for naming things without workarounds.
<_Vi> So I don't expect it to be very wrong to just use `var @"test" = "content of the test";`.
<_Vi> What other keywords or semi-keywords in Zig are full words, not abbreviations?
<_Vi> `error: declaration shadows primitive type 'type'`. Looks like unlike struct fields, functions are not OK...
<_Vi> How do name it then? `get_type`?
LargeEpsilon has quit [Ping timeout: 264 seconds]
Tetralux has joined #zig
Snektron has joined #zig
meheleventyone has joined #zig
doublex has joined #zig
porky11 has joined #zig
<tgschultz> functions are usually named like `getType()` unless they return a type, then they're named like types, i.e. `GetType()`
_Vi has quit [Ping timeout: 276 seconds]
<tgschultz> I often use `kind` in place of `type` as a name.
<tgschultz> or `x_type` where x is some meaningful descriptor.
<nrdmn> I've named a few struct members 'type' where the original specification called them 'type'
<nrdmn> should I change this?
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andrewrk> nrdmn, I think sticking to the spec names is good
<Sahnvour> I don't understand cmake. I modified CMakeLists.txt but need to wipe the build dir, reinvoke cmake from scratch, otherwise it wasn't taken into account when invoking ninja
<andrewrk> I'm not a fan of cmake
<andrewrk> the main feature of cmake is ubiquity
<Sahnvour> as I understand it, it's just becoming actually usable in the recent versions
<andrewrk> it still won't let us run `zig build` on `make install` :-(
<Sahnvour> if I had time I'd probably write fastbuild scripts and use that to build zig on my machine
<Tetralux> What's that?
<Cadey> wait, why would you build during make install?
<Sahnvour> Tetralux: a build system,
<Tetralux> Cadey: My money's on stage 2; andrewrk?
<torque> clearly rewrite your cmake build system in meson
<torque> that definitely won't cause insanity
<Cadey> torque: are you implying our entire industry isn't insanity?
<Tetralux> How about you rewrite it in C++ - one language then xD
<Cadey> oh jesus
<Cadey> andrewrk: also slightly related, why is the standard library named with the same acronym as sexually transmitted disease?
<andrewrk> just to keep people on their toes
<Cadey> xD
* Tetralux laughs
<Tetralux> I always read 'std' as 'standard' anyway xP
<companion_cube> aren't a lot of stdlibs… "std"libs?
<Tetralux> companion_cube: Which I read as "standard libs" x)
<Tetralux> Just like 'ptr'; I always read it 'pointer' and not "pudder"
<fengb> pooter
<Tetralux> Yours is worse xD
<Tetralux> Also - stupid question - why do people feel the need to even have a build system?
<Tetralux> Why not just make a compile-time program that does it all?
<Cadey> god died?
<Tetralux> Like, really.
<fengb> Because C compilation is hard and not solved well
<companion_cube> Tetralux: isn't it exactly build.zig?
<Tetralux> Cadey: That implies they we ever alive ;P
<Tetralux> companion_cube: Yes and no; not imperative code.
<torque> because there are an insane number of bizarre and broken system configurations and it's easier to let the build system try to wrangle that mess
<Cadey> Tetralux: C's lack of a build system out of the gate is what killed god
<Cadey> tbh
<companion_cube> writing imperative code for the build? :/
<companion_cube> makes parallel/incremental build basically impossible…
<scientes> Cadey, it had a build system, things like ports
<Tetralux> companion_cube: Incremental introduces a whole class of problems that are hard to detect and easy to avoid.
<scientes> before the internet was very different
<companion_cube> except when you want stuff to build quickly…
<Tetralux> Parallel building isn't that hard with imperative code.
<Tetralux> But more to the point
<companion_cube> also, you need to handle dependencies manually…
<Tetralux> You don't really need it if your compiler is intelligently designed to be fast.
<Cadey> Tetralux: it's a surprisingly hard problem regardless
<Cadey> if you have a better idea, i'd challenge you to make it a reality
<companion_cube> somehow I doubt zig will always compile quickly, given the existence of comptime
<andrewrk> I have a lot of tricks up my sleeve
<andrewrk> I won't give up on the fast compilation goal
<companion_cube> I mean, in non incremental settings :D
<Cadey> i wonder what the kubernetes sized codebase in zig is going to be
<companion_cube> if there's an expensive comptime computation, hard to not do it ^^
<companion_cube> Cadey: llvm in zig, obviously :°
<fengb> If Go can write their own backend, why can't we?
<andrewrk> compiler backend in zig is inevitable. people want more backends than llvm provides, and also llvm is slow
<Tetralux> companion_cube: Yeah, but you're smart enough to understand that if you try to simulate the universe at comptime that it might impact your compiles times ;)
<companion_cube> for -O0 or -O1, sure
<companion_cube> Tetralux: yeah but incremental compilation can help there ;)
<fengb> Increment the universe 🤔
<Tetralux> companion_cube: I'd rather just be able to compile at 1 MLoc/s.
<Cadey> Tetralux: let's leave that metric to V
<companion_cube> give a try to V ;)
<Cadey> lol
<companion_cube> heh 😂
<Tetralux> Cadey: I was thinking more of Jai, but :)
<Cadey> companion_cube: i reran my million lines of code benchmark on V recently
<Cadey> double-free segfault
<andrewrk> Cadey, they removed "wip" from the speed claims regarding compilation perf, is it accurate?
<companion_cube> does it segfault under a second though?
<Cadey> andrewrk: i can't replicate their benchmakrs on any hardware i have
<Tetralux> I consider V to be an early-access at best.
<Cadey> hold on let me rerun it to be sure
<Tetralux> Definitely not worth writing anything in yet.
<companion_cube> or ever
ntgg has quit [Ping timeout: 240 seconds]
<Sahnvour> hooray, managed to overide cmake's default optimization flags, now onto debugging
<andrewrk> sorry Sahnvour :(
<Tetralux> IMO, Jai has more promise, in spite of not being available - that should tell you something about how I feel about the situation./
<torque> on the other hand, Jai isn't even real so it makes even less sense as a point of comparison
<fengb> Isn't the compiler just converting the code to C?
<andrewrk> if you decide that it would be best to go back to 2017, I'll do the related chores
<andrewrk> Sahnvour, ^
<Cadey> it doesn't double-free anymore, but it does fail at 50,000 statements 2 seconds into the compile
<torque> you're going to build a time machine???
<Sahnvour> andrewrk: I hope we won't have to resort to this and can workaround/have MS fix it quickly
<andrewrk> torque, yes a time machine to back when MSVC compiled zig correctly
<Sahnvour> now that uninstalling VS is easy I'd rather not have multiple versions of it :p
<Cadey> at least on kahless (Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz)
<Tetralux> I really hate it when people say "This ain't real" - that's not how English works - you mean "I haven't [been able to] use it yet."
<Cadey> i can check my mac when i get home
<Tetralux> Like c'mon - you _can_ do better than that xD
<andrewrk> Cadey, but like give them the benefit, do the 50,000 multiplied out to a million or whatever
<andrewrk> the question is what's the actual perf
ave_ has joined #zig
<fengb> Maybe it's IO bound
<Cadey> andrewrk: i need to refind the lobsters thread that had a better generated file
<Tetralux> andrewrk: Question, why _don't_ we use clang on windows?
<Tetralux> Or is that a stupid question?
<torque> no, I mean it isn't real, but it's not worth arguing the semantics about
<fengb> No such thing as stupid questions
<Tetralux> fengb: +100.
<fengb> But sometimes we have stupid people asking questions 🙃
<ave_> Heya
<Sahnvour> Tetralux: it does already work
<andrewrk> Tetralux, clang support on windows is in scope too, but I haven't the time & energy yet to provide support
<Tetralux> andrewrk: I ask, because it's easier than using VC.
<andrewrk> the point of stage1 is to be able to get built by a large variety of systems. then self-hosted only has to be able to get built by stage1
<Tetralux> And since I already using clang on Linux anyway to build Zig...
<Cadey> it's over a second and it's still chugging
<Tetralux> One might say..
<Tetralux> That's it's a local maximum to resort to the likes of VC on Windows ;)
<andrewrk> Cadey, I don't even know how speed of compilation is on the table when it's *adding* a layer on top of C
<Cadey> at least using this benchmark to make a file:
<Cadey> andrewrk: my car can fly with the power of lies
* Cadey doesn't even have a car
<Tetralux> andrewrk: I believe the idea, based on the intro, was that 1Mloc/s will be achieved by a custom x64-generating backend.
<andrewrk> Tetralux, but they removed the "wip" label
<Cadey> gcc is currently very confused compiling it
<Tetralux> Does `v -x64 file.v` work now or something then?
<fengb> This thread makes my brain hurt and I'm 1 comment in
<Cadey> yeah it's been over a minute and it's still not built
<THFKA4> let's extend this for maximum overmemes
<andrewrk> ok. I don't think V is an interesting language, if we talk about it, it's just going to be circle jerking, and that's not what #zig is for
<THFKA4> maybe we can reach 3M loc/s
<fengb> I'm so happy that gitdab is a thing
<Cadey> sent details in DM to companion_cube
<Cadey> (of the bench)
<companion_cube> wtf is gitdab? :DD
<andrewrk> it has a dark mode, I'm into that
<companion_cube> and thus started the great migration
<Cadey> ah gitea <3
<companion_cube> I want to see this vig be better than V, tbh
<lunamn_> I don't plan on writing more on vig because it's cursed, lol
<Cadey> lunamn_: let's be honest
<Cadey> cursed computing is the most fun
<tgschultz> re build systems: is it really the system configurations that are broken if the build system isn't able to keep its state separate from the system's?
<ave_> Cadey: I can agree with that
<andrewrk> tgschultz, I probably agree with you, but not sure what you're referring to
<tgschultz> expecting an entire system to conform to your idea of what a build environment should be strikes me as madness.
<tgschultz> the cmake discussion from earlier.
<tgschultz> this is why containers are now popular for building things
<Cadey> "It works on your machine? Let's ship your machine!"
<companion_cube> tbh seems like static builds are not possible at all on arch, for example :/
<companion_cube> so, alpine+docker
<Tetralux> .. except that if the language provides enough comptime code to build a program.... ;)
<andrewrk> companion_cube, why are static builds not possible on arch?
<Cadey> is this the glibc ns resolver fun?
<companion_cube> because libraries don't ship with a .a, only a .so
<andrewrk> does the zig linux binary from work on arch?
<tgschultz> yeah, I'm explicitly blaming the way C building has evolved
<companion_cube> I mean, it's possible, if you recompile all the deps
<Cadey> lollll
<companion_cube> I didn't mean for Zig, but in general
<andrewrk> ah
<andrewrk> zig can create viable static binaries on arch
<andrewrk> but yeah if you want the glibc ns resolver, you have to target glibc
<companion_cube> unless you want to link gmp or something, hmm ? :D
<tgschultz> one of zig's best features: I just need zig to build zig stuff.
<andrewrk> companion_cube, well that's the thing, we'll be able to create a zig package for gmp
<companion_cube> yeah, taht's cool
<andrewrk> if you're willing to sit through a gmp build (at least it's cached), then you have gmp independent from any system
<companion_cube> (the system gmp won't do though, and it's ok)
<andrewrk> I think we'll probably end up with a way do prefer a system dep, and fall back to compiling from source
<tgschultz> I can have multiple versions of zig on the same system, anywhere I want, and they all can still build stuff without conflict.
<companion_cube> builds should be per-project, it's a nightmare to have a global state for a package manager
<andrewrk> companion_cube, 100% agreed. any global state is just caching, with proper invalidation
<andrewrk> `zig id` shows you the cache id for the compiler binary itself
<andrewrk> this is a different concept than zig version
<andrewrk> if zig dynamically links libc, and you fix a bug in the system libc's memcpy, `zig id` will be different.
<companion_cube> daaaamn tcc builds 1Mloc in .67s
<andrewrk> yeah, now there is an interesting project
<andrewrk> we're not competing with vaporware, we're competing with tcc
* Tetralux raises eyebrows.
* Tetralux shakes his head and smiles.
<Tetralux> tcc is C-only, correct?
* Cadey idly considers making a multi-language benchmark of files full of millions of instances of "hello, world"
<companion_cube> with a simple native backend, zig could aim at that, yeah
<halosghost> Tetralux: yes
<Cadey> i wish i knew C++ enough to make a native webassembly backend for zig
<companion_cube> hmm, gitea seems cool, I wonder why wasn't built on it?
<halosghost> companion_cube: because sircmpwm has NIH
<companion_cube> :D
<companion_cube> oh well
<halosghost> (which is not to suggest that that's a bad thing)
<halosghost> (or that I don't also have it)
<halosghost> tcc is incredible
<Tetralux> sircmpwm?
<companion_cube> tcc is from the same guy as qemu… :o
<halosghost> in fact, I'm planning on it being the only C compiler I have installed full time on my next machine
<halosghost> companion_cube: indeed
<Sahnvour> competing with tcc is quite some goal :)
<ave_> that name is weirdly familiar, sircmpwm I mean
<halosghost> Tetralux: the author of sourcehut, and various other projects (including wlroots)
<halosghost> ave_: ^
<companion_cube> and aerc
<andrewrk> Cadey, do it in pure zig. the parser is already in the std lib
<Cadey> andrewrk: interesting
<companion_cube> bootstrapping from wasi… ;)
<Cadey> actually
<Cadey> tbh
<Cadey> i think that's a better idea than people think
<Cadey> it's like
<companion_cube> I think it's a great idea :p
<Cadey> what's it called
<companion_cube> OCaml bootstraps from its own bytecode
<mq32> <companion_cube> tcc is from the same guy as qemu… :o
<mq32> companion_cube: and from the same guy as ffmpeg
<Cadey> i forget what it's called
<companion_cube> mq32: godamn
<Cadey> ah i'm thinking of ocaml yeah
<mq32> yeah, bellard is one bad ass coder
<Tetralux> WAIT
<Tetralux> The same guy made tcc, qemu, ffmpeg?
<ave_> Oh wow, this person did a lot.
<ave_> I think I know them from sway.
<companion_cube> now that's the good kind of NIH
<mq32> Tetralux, companion_cube:
<companion_cube> yeah I remember having seen that on HN some time ago
<mq32> (and BPG image format)
<Cadey> and quickjs
<Tetralux> How on earth have I only heard of this person's name once?
<companion_cube> The TCCBOOT boot loader demonstrate the speed of TCC by compiling and launching a Linux kernel in less than 15 seconds. <----- excuse me but what
<ave_> what
NotNite has joined #zig
<andrewrk> wait, tcc can build linux?
<companion_cube> might just be the bootloader, not sure
<mq32> andrewrk, it can BOOT linux :D
<Tetralux> Now THAT's a goal to strive for...
<mq32> from source
<NotNite> ello
<Cadey> that's getting into templeos levels of bootstrapping
<Cadey> hi NotNite
<ave_> I think I'm in love with tcc
<mq32> <companion_cube> The TCCBOOT … less than 15 seconds. <----- excuse me but what
<companion_cube> just zig translate-c tcc, and you get your native backend ;)
<mq32> this is on a kernel on version 1.* or 2.* afaik
<halosghost> andrewrk: I'm not sure if that's still true
<mq32> not on a modern, billion-lines-of-code-kernel
<halosghost> but it used to be able to :)
<halosghost> tcc is phenomenal
<companion_cube> mq32: :D ok, but still
<halosghost> and I'm slowly transitioning my personal projects to be able to be compiled using tcc :)
NotNite has quit [Client Quit]
<Cadey> we almost need a #zig-offtopic
<Cadey> heck
<Cadey> i just made it
<lunamn_> what is going to be the Next Thing(TM) now that 0.5.0 is released?
<Cadey> i've wanted to make a nanokernel in zig for a while, but i lack hands
<andrewrk> there's lots of exciting stuff to do to the std lib now that async/await is relatively stable
<andrewrk> first iteration of package manager is expected this cycle
<Cadey> is there a spec for the package manager yet?
<andrewrk> no
<andrewrk> I promised that a while ago and haven't delivered yet
<Tetralux> Can we please stop calling that kind of cast an "implicit" cast.
<Tetralux> It is so blantantly not an _implicit_ cast.
<andrewrk> Tetralux, yes, the moment that we have a better name
<andrewrk> Cadey, there are some prerequisites - networking in the std lib, deflate, tarball support, etc
<Tetralux> Cast? (Just a kind of cast)
<andrewrk> no spec needed to know those need to be done
<Tetralux> Explicit cast (since you give the dest type)
<Tetralux> .. which would make sense if you did it with @cast.
<andrewrk> Tetralux, ok but how do you disambiguate from the other explicit casts?
<andrewrk> @ptrToInt is an explicit cast as well
<andrewrk> also implicit casts are implicit. var x: i32 = not_an_i32;
<andrewrk> and i32(not_an_i32) is exactly equivalent
<Tetralux> The first one - that's coercision.
<Tetralux> (or however you spell it)
<Tetralux> T(x) is an explicit kind of cast by definition.
<Tetralux> (You are naming the type.)
<andrewrk> type coersion, that's a good name, can you propose that?
<andrewrk> *coercion
<Tetralux> ptrToInt is little more than @cast(usize, ptr) -- it's just that you want to make that clear so that you don't do it by accident.
<Tetralux> So yes, it's an explicit cast.
<Tetralux> They all are.
<Tetralux> Except
<Tetralux> In the coersion case.
<Tetralux> :)
<tgschultz> explicit coersion then
<Tetralux> No.
<Tetralux> Expicit coersion is explicit casting.
<Tetralux> Coersion is not the same.
<torque> type coercion is an existing concept in e.g. javascript where it means "the language mangles everything as hard as possible to try to not throw errors"
<Tetralux> torque: JS is stupid :)
<torque> it's kind of a loaded term
<Tetralux> ... and not worth citing for anything.
<andrewrk> let's talk about it on the proposal that Tetralux is opening
<torque> the point is that people are likely to have an existing understanding of the terminology
<Tetralux> .. And they'll not be far off.
<Tetralux> It's just that it's better.
<Tetralux> In some many obvious ways.
<Tetralux> At least if I have anything to do with it.
<Tetralux> (Or anyone else who's competent, for that matter.) xD
<Tetralux> Short version: if you are naming the dest type of a cast - then it's an explicit cast of some sort.
<Tetralux> If you are not, it's an implicit cast of some sort.
<Tetralux> In the case of `var x: i32 = not_an_i32` -- presumably the value would be a smaller-sized signed integer, like i16.
<Tetralux> So a narrowing cast.
<Tetralux> This is one example of an implicit cast.
doublex has quit [Ping timeout: 245 seconds]
<mikdusan> Sahnvour: thanks!
<tgschultz> function definitions as expressions will be a nice QoL improvement for comptime code returning functions.
<mq32> tgschultz, yeah it's my favourite coming change besides saturation arithmetics
doublex has joined #zig
<andrewrk> it might be nice to reconsider `let` vs `const` before doing fn defs as exprs
Ichorio has joined #zig
<mq32> hm, i'm not used to let, but i can understand that typing 60% less per declaration is a nice feature
<andrewrk> `zig fmt` would auto correct for an entire release cycle
<mq32> i just took that for granted :D
<andrewrk> oh that reminds me, I can delete `use` now
<Cadey> andrewrk: i'm really glad you're combining `go fix` and `go fmt` into `zig fmt`
<andrewrk> what does go fix do?
<andrewrk> whitespace?
<Cadey> it was used pre go 1.0 to update code for the backwards incompatible changes
<andrewrk> ah
<mq32> andrewrk: you're doing your work very properly, i just assumed zig fmt will fix that for the release cycle :D
<tgschultz> I'm not sure I get the reasoning for using `let` vs `const`.
<Cadey> let is the same length as var
<mq32> yep
<tgschultz> so?
<mq32> combine {typing "var" is easier than "let"} and {people are lazy}
<Sahnvour> andrewrk: regarding the msvc bug, garbage occurs while building the builtin_fn table ; there's an easy and temporary workaround but we can't be sure there aren't other bugs/places affected.
<andrewrk> tgschultz, I have noticed that people have incorrectly been preferring `var` to `const`
<tgschultz> then lets make then `v` and `c`
<andrewrk> v and c are common variable names and have no precedence in other langs
<tgschultz> I think that's just old habit though.
<andrewrk> Sahnvour, it's for sure an MSVC codegen bug then?
<mq32> non-serious proposal: just infer variable type on "first assignment". if assigned with =, it is a constant, if assigned with := it is a variable: { a = 10; b := 20; }
<andrewrk> can I see the workaround diff out of curiosity?
<tgschultz> yeah, that was a toung-in-cheek dismissal of the 'it's shorter to type' reasoning. Which I will note is almost antithetical to one of zig's goals.
<Sahnvour> looks like it, don't know exactly what is going on but the hashtable is corrupted while growing
<mq32> it's one of the things that bug me in c++ a lot: "auto static constexpr a = 1;" for "i just want a constant"
<Sahnvour> andrewrk: the easiest way is to `#pragma otpimize("", off)` around `create_builtin_fn` or `define_builtin_fns` when on msvc
<andrewrk> Sahnvour, ah, got it, thanks
<fengb> We should replace all keywords with a smiley. That'd be shorter
<andrewrk> Sahnvour, wait, that's not even in the hash table code?
<Sahnvour> I believe it might have to do with the hash table code getting inlined and optimized wrong
<andrewrk> I see
<Cadey> fengb: does zig allow for emoji variable names?
<tgschultz> no carriage returns, but you can name things using the poop emoji. That doesn't seem right to me
<Cadey> i love it
<andrewrk> you can have carriage returns in names
<mq32> just name your variable "\r"
<mq32> :D
<andrewrk> const @"\r" = 42;
<mq32> i think this will break the assembler :D
<andrewrk> zig is a DSL for machine code; object files don't have restrictions on symbol names
<tgschultz> that's fair. I was so offended by the idea that I failed to notice it required the @"". Objection withdrawn.
<Tetralux> This is the most fire-hose-at-a-page I've ever written, so
<Tetralux> You have been warned.
ntgg has joined #zig
<andrewrk> thanks Tetralux
<Tetralux> Welcome
<Tetralux> This terminology has long-since bugged me xP
<doublex> *coercion, though, fwiw
<andrewrk> it's true, I checked the dictionary. english is dumb
<andrewrk> english is the cmake of languages
<doublex> parser's probably more complicated than perl's
<Tetralux> [`coersion -> coercion` complete.]
<Tetralux> Though honestly, I'm inclined to ignore that wierdness.
<Tetralux> "How else are we meant to make things better?"
* Tetralux smiles.
<Tetralux> It's not like people won't know what the word means.
<fengb> andrew already nixes some terms because Brits and Muricans can't agree
<doublex> I'm more of a Haskell guy, and to me "coerce" sounds like "reinterpret the bits" whereas "try to represent (morally) the same value" is called "convert."
<halosghost> heh
<halosghost> morally
<halosghost> doublex: I like that
<mq32> doublex, i like the term "reinterpret" for this more
<andrewrk> "canceled" vs "cancelled" is unfortunate. Nobody should have to read docs just to figure out which spelling of the word is being used
<Tetralux> I like "coersion" for this kind of behavior, because that's what it is.
<Tetralux> Sure, you're converting from one type to another - but it's simpler than converting.
<Tetralux> There's no complicated work going on here.
<Tetralux> And, it either succeeds or compile errors.
<Tetralux> And coerce has a connotation of "[read in a menacing voice] Yes, you will do this."
<tgschultz> "canceled" vs "cancelled" isn't so bad. They're the same word with two different spellings. Sometimes we have words like "affect" and "effect", both of which can act as nouns or verbs but are subtly different.
<Tetralux> For cancelled, I'd assume two Ls.
<Tetralux> The first time I ever saw anyone spell it with one was in your demo, andrewrk. xD
<fengb> It's a lot more common in murica
<doublex> i think the shed should be blue
<Tetralux> Simplest solution: Pick one, compile error the other with a message telling you to use the other one :)
<tgschultz> there's no way that could be worse than tabs/spaces and \n/\r\n
<tgschultz> I'm ok with it, is what I'm saying
* Tetralux grins
<mq32> doublex, such discussions seem like bikeshedding but wording is important for understanding-at-first-glance and that's a primary goal of zig code
<fengb> There's a (joke) language that deletes your file if there's a compile error 🙃
<andrewrk> whenever someone suggests adding iterators to zig this is what I'm imagining will happen
<ceymard> where is the .evented field from in this example : `pub const io_mode = .evented` ?
<andrewrk> ceymard, you can find out by changing it to a bogus name, I believe
<andrewrk> but the answer is
<mq32> andrewrk, correct me if i'm wrong, but ".evented" is a "enum literal", so a value that is of "unspecified enum type" and will only be comparable to enums of that contain such a field
<andrewrk> mq32, correct
<mq32> ha! so it's "comptime_enum_member" or something like that :D
<ceymard> I did not get that :-|
<mq32> ceymard: ".evented" has a similar type as "comptime_int", but for enum values
<ceymard> ok
<mq32> so io_mode isn't of a specific enumeration type but "contains" an enum member that can be compared to any enum type that contains a value "evented"
<ceymard> ok
<mq32> so you could compare that to enum{evented,timed} as well as the IoMode
<ceymard> yes ok
<ceymard> so it's contextual ?
<andrewrk> yes that is one way to put it
<ceymard> does it depend on being like for example inside an enum { } declaration or a switch
<andrewrk> it's analagous to integer literals, which can be coerced to any integer type
<mq32> it's interesting how much you start to understand programming languages when you have designed one :D
<ceymard> are there other rules to the way the name is resolved besides the two I cited
<andrewrk> the only rule is casting related.
<Sahnvour> andrewrk: 100% sure it's a codegen bug, but maybe not the one affecting memcpy. for every builtin the compiler generates the same pattern every time, and at some point it changes and stomps the memory where the builtin Buf data lies, so no wonder querying the hashtable fails afterwards
<andrewrk> Sahnvour, it's a rather severe bug, pretty strange that zig's codebase is affected. we barely use 1% of C++ features
<Sahnvour> building it* fails, because the name contains garbage just before we insert it into the table
<Sahnvour> ime msvc codegen bugs affect optimization passes, not necessarily linked to arcane c++ features
mahmudov has joined #zig
kllr_sbstn has joined #zig
<Cadey> how do you convert little endian bytes to an integer in zig?
<andrewrk> Cadey, std.mem.readIntLittle
<Cadey> ah, thanks
itsMontoya has joined #zig
<itsMontoya> Hey andrewrk - Is there plans to clean-up simplify the async stuff?
<itsMontoya> I've been thinking a lot about it all over the last few days
<itsMontoya> More specifically, I was thinking about how there aren't interfaces or traits in zig yet
<itsMontoya> but I see something like interfaces being very powerful for something like this
<itsMontoya> interface Poller {}
<itsMontoya> poll() bool
<itsMontoya> Could make it very easy to make async control structures instead of the current approach
<itsMontoya> Under the hood, the system could handle the suspend/resumes
<itsMontoya> I've been playing around with rust async quite a bit since their latest beta release. There are a lot of aspects about it I don't like, some things I like though!
samtebbs has quit [Quit: Lost terminal]
itsMontoya has quit [Ping timeout: 250 seconds]
<Tetralux> itsMontoya: One item of note is the ability to specify easily whether the interface relies on runtime fn ptrs or static fn calls.
<Tetralux> One way perhaps would be to mark a fn argument that is an interface type be either comptime or non-comptime to indicate "should these interface fns be statically resolved during compilation"
waleee-cl has quit [Quit: Connection closed for inactivity]
Barabas has quit [Ping timeout: 260 seconds]
traviss has joined #zig
waleee-cl has joined #zig
ave_ has quit [Quit: Connection closed for inactivity]
halosghost has quit [Quit: WeeChat 2.6]
hasanyasin has joined #zig
<hasanyasin> Newbie question: When I have a function where I create and return a struct, it returns the exact same instance. I guess this is the expected behavior as mentioned in the documentation, i.e. "Functions called at compile-time are memoized."
<hasanyasin> How can I create separate instances of a struct with every call of a function? Is there some way of saying non-compiletime? Or am I missing something totally different?
<andrewrk> hasanyasin, to better understand your use case: what's the problem with what is currently happening?
<andrewrk> how does this behavior manifest in an issue that prevents your use case?
<hasanyasin> I want to initialize struct instances with a function like "fn NewNode() *Node" or maybe "Node.New() *Node" where Node was defined as const Node = struct { ... }
<mq32> you want to build a linked list at comptime?
<hasanyasin> No, I don't want this to run at comptime, actually. I don't know how to make it run on runtime only. --so embarrassed.
<mq32> you need to use an allocator to create a new node
<hasanyasin> Thank you. I will try to figure that out.
<hasanyasin> I was actually trying to implement a kinda-interface-like setup. I got the idea from *Allocator _"interface"_ actually. :D
<hasanyasin> Node is a struct with only methods calling actual methods. ElementNode, TextNode, DocumentNode, etc will be implementations of this interface.
<hasanyasin> Thank you all. :)
ntgg has quit [Ping timeout: 276 seconds]
<Tetralux> hasanyasin: `return &d.node`
<Tetralux> You're returning a ptr to stack memory?
<hasanyasin> Sorry, I now realized that. No garbage collection, no automatic allocation.. This is not go. :D
<Tetralux> Do `var e = allocator.create(ElementNode); e.* = ElementNode{ ... }; return e;` instead.
* Tetralux grins
<hasanyasin> Thank you so much!
<Tetralux> It's okay; returning stack memory is planned to be a compile error in the future.
<Tetralux> :xp
<hasanyasin> Other than this, do you find the interface-y approach correct?
<Tetralux> Seems generally alright.
<hasanyasin> Each implementing struct will have Node (interface) as a field and methods will access the implementing structs via @fieldParentPtr.
<Tetralux> I'd have to try using it to really know for sure - but it shows promise.
<Tetralux> You should check if the fn calls are inlined or not.
<hasanyasin> I will share it again once working.
<Tetralux> If not, there's not too much you'd actually wanna use it work.
<Tetralux> wanna use it for*
<hasanyasin> As you might have guessed, I am not that low-level yet. I don't mind if there is some performance penalty. In the worst case it will work way faster than any scripting language and probably Go as well.
<fengb> If you're doing everything on the heap, it may not run as fast as Go
<hasanyasin> I know Zig doesn't target web and even probably network service developers, but I enjoy this experience of walking in a very different jungle so much.
<Tetralux> Fair play - it's just worth noting that for production code, you don't want dynamic calls with fn ptrs if you expect to call them often. There's a _lot_ of performance that would be left on the table.
<hasanyasin> Thank you for the good suggestions. Both are noted and I will try to get to those once I have something working no matter how slow. :)
<Tetralux> Though I should note, I like the general approach and I would like something more supported by the language that is like this.
<Tetralux> And yes - that's a truly invaluable mindset to have.
<hasanyasin> I am trying to create a small compiler for a web templating system.
<hasanyasin> My invention. :D
<Tetralux> The hackiest possible way is the fast-to-build way - and is good for showing you what you actually need in the end :)
<hasanyasin> Yes, couldn't say it better.
<Tetralux> I'm happy you think so xD
<Tetralux> I wish you luck :p
<hasanyasin> Thank you so much!
<hasanyasin> It is 1:30am here (Finland) and I still enjoy the work.
<Tetralux> The sign of a true enthuiast xP
porky11 has quit [Quit: Leaving]
<hasanyasin> I build web-based systems as my profession. I have recently been thinking of a web framework built around a templating engine, compiling various components into different platforms such as html/js/css for browser and Nodejs and Go source code for server.
<Tetralux> Worth noting that Zig can compile for wasm which may help there.
<hasanyasin> Then I wanted to code it in a different language. Tried Nim but felt too weird because everything changes everything and modules add methods to other modules' data structures, etc. Maybe I misunderstood it completely, but documentation also felt untidy and carelessly written.
<fengb> No docs are better than mess docs? 🙃
<hasanyasin> Rust takes so long to type and I dislike the Ruby-like culture. Maybe my personal tastelessness, I don't know.
<hasanyasin> Yes, no docs situation is actually better than incompatible documentation.
<hasanyasin> Not saying anything is always better than lying. :D
<hasanyasin> I funnily found V and it looked too good to be true.
<hasanyasin> While reading about V, I found out about Zig.
<hasanyasin> Very weird way to find Zig, I guess.
<hasanyasin> Wasm target (LLVM backend) was also attractive @Tetralux, I totally agree with that point too.
<Tetralux> I'd suggest investigating that over outputting JS :p
<Tetralux> Though both my be valuable in the short term.
<fengb> I wasn’t smart enough to learn Rust >_>
itsMontoya has joined #zig
<andrewrk> same
<Tetralux> I tried using it for a project - got part way there. I found it to have too much friction for my liking;
myfreeweb has joined #zig
<Tetralux> As well as finding lifetimes a little awkward to understand.
<Tetralux> As well as having them infect all my code the moment I needed them.
<presiden> I find it fascinating actually
<presiden> once you grok it, it kinda stick with you
<Tetralux> They focused on the wrong thing.
<presiden> there's also that article about the orignal idea in cyclone
<Tetralux> There's some interesting ideas in there though.
<fengb> I think it’s fine for what it is. But it also isn’t my thing
<Tetralux> Thing is, it would be a heckuva lot nicer if it was just relatively slightly different.
<Tetralux> - Improve error messages.
<Tetralux> - Remove the borrow checker or make it sigificantly better.
<Tetralux> Among others.
<andrewrk> suggesting to remove the borrow checker from rust is trolling. please don't do that
<andrewrk> I don't care if it's intentional or not
* Tetralux raises eyebrows.
<Tetralux> That's odd.
ltriant has joined #zig
<Tetralux> Please don't do that either.
<Tetralux> Like I respect you, but really now xD
<hasanyasin> Borrow checker is Rust's definition almost. Some people like it, some people can't accept if the approach is viable for anything.
<hasanyasin> Zig is nice for some, but there is a big population who would just leave the page once they see you need to manage memory yourself while some others would find it the most attractive part.
<hasanyasin> Variety is beautiful.
<scientes> That would be cool if there was a way to combine code from multiple languages that use llvm
<scientes> without using the C ABI
<itsMontoya> I like the borrow checker
<itsMontoya> I just hate how in flux the language is
<fengb> Yeah the argument I keep hearing against Zig is that it’s not 100% memory safe
<hasanyasin> And Tetralux, thank you so much for the snippet. I just copy&pasted and now my experimental thing works perfectly. :D
<itsMontoya> Yea, memory safe is the new hotness
<scientes> safety is impossible
<itsMontoya> Rust
<itsMontoya> Now D
<scientes> its turing complete
<itsMontoya> "safe"
<itsMontoya> Safer than C
<scientes> anyways, that's totally differnt
<scientes> i'd rather a language that doesn't get in my way
<scientes> and zig is already better than C in that respect
<presiden> Cyclone really has a rippling impact for a never heard of language
<Tetralux> andrewrk: In a world where memory safety is the focus of Rust, and in a world where an intense focus on it does not actually help all that much - calling it trolling is honestly kind of insulting. Please don't do that. Like - I think I understand what you are getting at, but really.
<fengb> I’d like to see a real study on how often different modes of safety helps
<scientes> I think fully proven code is hot
<scientes> like seL4
myfreeweb has left #zig [#zig]
<scientes> but other than that, please get out of my way, thx
<mq32> scientes, yeah, but: at what cost?
<scientes> mq32, cheaper than fuzzing, which doesn't get out all the bugs
<fengb> Like I’d expect 90% of bad memory errors to be buffer overruns, and Zig is quite safe from that
<Tetralux> There's more of a case for it in things like rockets that go to mars or whatever, but...... you can do it without being mind-numbing.
<companion_cube> Tetralux: removing the borrow checker from rust makes it a totally different language
<mq32> scientes, yeah but we can get a lot of errors by reading code as well
<scientes> I'm not saying its the only way, but its pretty interesting
<presiden> buffer overrun? not double free/use after free?
Tetralux was banned on #zig by ChanServ [*!*@]
Tetralux was kicked from #zig by ChanServ [Banned: the channel is taking a 1 week break from you !T 7d]
<mq32> yeah, that's true
<scientes> its also kinda the "perfectionist" attitude zig
<companion_cube> damn
<fengb> I also want to see Zig’s debug allocator in action. See if it can catch most double frees or use after frees
<presiden> ^
<scientes> ALL
<mq32> fengb: it should, at least in theory
<andrewrk> fengb, yeah I should work to get that merged soon
<mq32> shouldn't be that hard anyways to implement this with mmap
<andrewrk> it's also the basis for language safety experiments that I want to do
<fengb> Can’t catch all because tests can’t possibly hit 100% real coverage
<fengb> Unless you deploy with debug allocator, which I suppose is possible :P
<fengb> But could it be good enough
<fengb> shows out of bounds to be #1 and #5. I’ve no idea what the benchmark is
<itsMontoya> Why did Tetralux get banned?
<scientes> he needs to cool off
<itsMontoya> fengb: Are you saying the debug allocator will catch double frees?
<itsMontoya> I'm wondering if there is a way to abstract the async code into a struct
<itsMontoya> Like a Promise/Future type item
<itsMontoya> With easily usable methods
<jmiven> itsMontoya: it is catching double frees :-)
<mq32> itsMontoya, the async frames are futures
<mq32> in my understanding at least
<itsMontoya> jmiven: That's amazing. Let me read more into it before I ask follow up questions. I don't want to waste peoples time
<fengb> itsMontoya: yes it’s the main goal to detect all the memory errors
<itsMontoya> mq32: I think you are correct, but it still feels very bare bones. I totally get why it was done this way though
<itsMontoya> Being able to set the frame and such is super interesting
<itsMontoya> Gives a ton of granularity
<itsMontoya> but I think for 95% use cases it's overkill
<presiden> and speaking of combining allocator and region-based memory management, there's also Cone language
<fengb> I think one of the unsung killer features in Zig is to seamlessly swap allocators
<presiden> Cyclone really inspire many people :)
<itsMontoya> fengb: That's a great point
<itsMontoya> For one controller I might want ref counting
<itsMontoya> but another I might want raw manual management
<itsMontoya> andrewrk: If I were to build a convenience layer around async. Do you think I would have more luck approaching as a macro? Or as a struct with methods?
<itsMontoya> I'm hoping for the latter
<mq32> <itsMontoya> For one controller I might want ref counting
<mq32> ref counting doesn't work by changing the allocator
<mq32> you still have to implement that 100% manually in zig
<companion_cube> who said "RAII"? :-°
<itsMontoya> Right, but technically couldn't a ref counting allocator be built?
<mq32> nope
<itsMontoya> Ah, fair
<itsMontoya> I guess it would have to be on the structure level
<mq32> the allocator has always "two" functions: free and malloc
<mq32> you can use refcounting on top of that
<itsMontoya> OH yes yes, totally
<fengb> Jimmi has a proof of concept GC. I’ve been meaning to see how that works
<itsMontoya> I was talking about memory management layer. And somehow I said allocator
<itsMontoya> It's been a long day, I apologize
<itsMontoya> GC, ref counting, etc all need an allocator under the hood
<itsMontoya> To actually allocate and free, totally
<itsMontoya> Zig's async is eager, correct?
<itsMontoya> Or is it lazy?
wilsonk has quit [Ping timeout: 265 seconds]
<mq32> itsMontoya, what do you mean by eager/lazy?
<itsMontoya> Rust's async is lazy, doesn't start anything until await is called on it
<itsMontoya> Javascripts async is eager, it is called instantly
<mq32> i think that's an implementation detail in userspace
<itsMontoya> True
<itsMontoya> But there are a few that will be lang level
<itsMontoya> I/O
<itsMontoya> Is an example
<mq32> I/O is also user space, not lang level ;) *nitpicking*
<itsMontoya> I suppose you are correct
<itsMontoya> I'll sit in the corner now
<itsMontoya> How do I declare a func as a type?
<itsMontoya> val: i32;
<itsMontoya> func: fn() void;
<itsMontoya> Second one is giving me an error
<mq32> const FunType = fn() void;
hasanyasin has quit []
<itsMontoya> within a struct though?
<itsMontoya> Sorry I didn't specify that
<mq32> as a member field or static var?
<itsMontoya> OH oh oh!
<itsMontoya> It's compiling
<andrewrk> translate_c.cpp now exclusively uses the same C API that the self-hosted version uses. shaved off 5 seconds from compiling zig
<andrewrk> it would be nice to delete these 5,162 lines of C++ code in this release cycle and replace them with self-hosted code
<itsMontoya> :)
<itsMontoya> Fucking amazing
<andrewrk> scientes, I also haven't given up on merging a SIMD commit today
<scientes> I've got my natural exponent double precision implementation working compiled 5 different way
<scientes> x86_64 2, 4, and 8 wide, arm64, and arm32
<scientes> and its performing as fast as the libmvec versions
mahmudov has quit [Ping timeout: 245 seconds]
wilsonk has joined #zig
<itsMontoya> So I think I have an idea to get something that will feel similar to goroutines
<itsMontoya> Thread pool, which can spawn coroutines
<scientes> yeah goroutines can be build on top of async
<itsMontoya> :)
<scientes> buf using a global thread pool has *many* problems
<itsMontoya> I know it does with gaming
<itsMontoya> Would it with backend server programming?
<scientes> everything that go is used for today
<itsMontoya> Is that the main issue though?
<itsMontoya> GPU programming
<itsMontoya> Or is there another issue I'm not thinking of?
<mq32> pool with 4 elements and 4 tasks that block
<mq32> => not async anymore
waleee-cl has quit [Quit: Connection closed for inactivity]
mahmudov has joined #zig